[Bug] empty tool-call id/name from Anthropic Messages gateway → "format v4 tool/result requires toolCallId matching its tool source" crash (fix provided)

[leo-liushuhong]

摘要

当 DeepSeek 模型通过第三方网关（wdtrip-gateway）以 Anthropic Messages 协议（api: "anthropic-messages"）对外提供、并由 harness 的 pi-ai 适配器（kind: "pi-ai", version: 2）消费时，网关偶尔会下发一个 id 与 name 均为空字符串的 tool_use 块（模型在 reasoning 里输出 DSML 标记、网关误判为工具调用所致）。

llm-pi-ai 适配器把这个空 id/name 原样透传成 harness 的 tool-call 块，于是：

1. tool/call 事件携带 callId: ""；
2. 派发失败（unknown tool ""），ToolCallRecovery 生成 tool/result 时 toolCallId 也为空字符串；
3. V4 会话格式校验 assertV4ToolResultMessage 拒绝 toolCallId.length === 0，报错 format v4 tool/result at seq N requires toolCallId matching its tool source，该 tool/result 事件无法写入会话，本轮强制终止。

关键点：llm-deepseek 适配器早已对空工具身份做了防御（if (!content.id || !content.name) return malformed('empty tool identity')），但 llm-pi-ai 适配器缺失同一道防线——这是两个适配器之间的不一致，正是本次崩溃的根因。

修复代码见 fork 分支：leo-liushuhong/deepseek-harness@fix/reject-empty-tool-identity

复现条件

项	值
网关 / 协议	wdtrip-gateway，api: "anthropic-messages"
适配器	kind: "pi-ai", version: 2
模型	deepseek-v4-pro-huoshan[1m]（响应模型 deepseek-v4-pro-ga-260813）
会话	session-20fc753c-164e-48af-bf2a-b742355cec42

表现症状（证据）

会话日志尾部（seq 112 → 119）展示了「占位名不崩、空 id 才崩」的精确对照：

• seq 112 assistant/message 含 tool-call id="call_8uwxpajwomekefw1vnwkofrj" name="tool_name"（占位名 tool_name、真实非空 id）；
• seq 113 tool/call callId="call_8uwxpajwomekefw1vnwkofrj" name="tool_name"；
• seq 114 tool/result toolCallId="call_8uwxpajwomekefw1vnwkofrj"，content 为 Error: unknown tool "tool_name" —— 非空 id 时正常走「未知工具」路径，不崩溃；
• seq 117 assistant/message 含 tool-call id="" name=""（空 id 与空 name）；
• seq 118 tool/call callId="" name=""；
• seq 119 的 tool/result 缺失——写入被 assertV4ToolResultMessage 拒绝，没有 step/end、没有 turn/end，会话在此强制终止。

错误信息在本会话中出现 41 次：format v4 tool/result at seq … requires toolCallId matching its tool source。

根因分析

崩溃链路（全部在官方 master 上确认）：

1. pi-ai 适配器不校验工具身份：packages/llm/llm-pi-ai/src/stream.ts 的 toolcall_end 分支直接把 event.toolCall.id / event.toolCall.name 原样写入 harness 的 tool-call 块，id 可以为空字符串。
2. assembler 的兜底 ?? 拦不住空串：packages/llm/llm/src/assembler.ts 里 id: partial.toolCallId ?? brandString(\call-${index}`)用??，只拦 undefined，**不拦空字符串 ""**（??与||的差异）；且block-end路径直接返回partial.block`，完全绕过该兜底。
3. agent-loop 沿用空 id：packages/core/agent-loop/src/tool-calls.ts 的 callId = block.id、ToolCallRecovery 的 toolCallId = callId 都直接继承空 id。
4. V4 校验拒绝空 id：packages/session/session-format-v3-to-v4/src/tool-role.ts 的 assertV4ToolResultMessage 里 toolCallId.length === 0 抛 SessionFormatError——报错文案「requires toolCallId matching its tool source」其实是由空 id 分支触发的，具有误导性。

不一致点（关键）：packages/llm/llm-deepseek/src/translate.ts 在 tool_use 分支已有 if (!content.id || !content.name) return malformed('empty tool identity')（抛 MALFORMED_RESPONSE，且该 code 不在默认重试清单内，不会被重试放大成循环）。llm-pi-ai 缺失同一防线，导致同样类别的畸形响应一个被拒、一个崩溃。

对话证据摘录（真实负载）

seq 117 assistant 消息的真实内容块（JSON 视图）：

{"type": "assistant/message", "seq": 117,
 "data": {"message": {"role": "assistant",
   "content": [
     {"type": "reasoning", "text": "I need to stop trying to write these tags. The environment intercepts my tool-call-like syntax. …"},
     {"type": "tool-call", "id": "", "name": "", "arguments": "{}"}
   ]}}}

紧随其后的 seq 118：

{"type": "tool/call", "seq": 118, "data": {"callId": "", "name": ""}}

可见网关把模型 reasoning 里的 DSML 标记误判成了 tool_use，且下发的 id/name 为空。

修复方案

修复位置：llm-pi-ai 适配器（与 llm-deepseek 对齐），而非 assembler 层打补丁

选择在 packages/llm/llm-pi-ai/src/stream.ts 的 toolcall_end 分支加校验，理由：

1. 与既有防线对齐。llm-deepseek 已在同一语义位置（tool_use 块落地处）拒绝空工具身份；把 llm-pi-ai 补齐到一致，消除两个适配器之间的行为分歧，而不是在 provider 中立层再加一道掩盖 provider 缺陷的兜底。
2. 在 wire 边界拒绝畸形输入。空 id/name 来自网关下发的 wire 载荷，属于「协议违规」；在适配器翻译边界以 MALFORMED_RESPONSE 拒绝，语义与 deepseek 一致，且该 code 不在默认重试清单（retryableCodes = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]），不会把畸形响应放大成重试循环。
3. 根因在源头，不在会话写入。若只放宽 assertV4ToolResultMessage 或让 assembler 用 || 兜底，只会把空 id 换成 call-${index} 再往下传，name 仍为空、依旧 unknown tool ""——治标不治本。

实现要点

在 toolcall_end 分支 yield block-end 之前：

if (event.toolCall.id.length === 0 || event.toolCall.name.length === 0) {
  throw new LlmError('pi-ai tool call has empty tool identity', 'MALFORMED_RESPONSE')
}

并同步更新 toStreamChunks 的 JSDoc @returns（MALFORMED_RESPONSE 抛出口），与既有的 STREAM_CLOSED 抛出口并列。

修复后的验证

1. 单元测试（packages/llm/llm-pi-ai/tests/convert.spec.ts）：新增 it.each 两例（空 id、空 name）断言抛 MALFORMED_RESPONSE；整文件 vitest run → 85 例全部通过（新增 2 + 原有 83 无回归）。
2. 静态检查：tsc --noEmit 对 llm-pi-ai 包无类型错误（strict 模式、无 any、无 as unknown）；oxlint 对两个改动文件 0 warning / 0 error。
3. 提交：90d8d6a7，pre-commit 门（staged lint、whitespace、vendor manifest）全部通过。

附件

完整会话日志（session-20fc753c-164e-48af-bf2a-b742355cec42，session.v4.jsonl.zstd 约 90KB）包含崩溃全程与上述对照证据；如需，我可另行提供。