[bug] 单条 tool-call 的 arguments 非法即整轮失败（MALFORMED_RESPONSE），建议隔离坏调用或自动重试

[C-002]

环境

• dsh 0.2.1-alpha.4，web profile，Windows x64
• 模型 deepseek-official / deepseek-flash，reasoningEffort: high，maxTokens: 256000
• 该请求 43 个工具、工具定义约 39 KB

现象

一轮直接失败，turn/end 记录：

{"type":"turn/end","seq":19,"data":{"turn":1,
 "reason":{"kind":"error","error":{
   "message":"DeepSeek Messages stream: tool input is invalid JSON",
   "code":"MALFORMED_RESPONSE"}}}}

用户侧只看到「本轮运行失败」，拿不到任何部分结果。

复现证据：坏的只有一条调用

同一 step 里模型并行发起了两个 tool-call，其中一条完全合法：

块	工具	arguments	结果
2	ops_bash	{"command": "ls", "description": "List workspace contents"}	✅
3	ops_glob	{"pattern": **/example*/**/*.cpp}	❌ 值未加引号

块 3 的真实 glob 已脱敏为 **/example*/**/*.cpp；关键是形态——值没有引号、也不是数组。

流末尾：

{"type":"finish","reason":{"kind":"error","failure":{
  "message":"DeepSeek Messages stream: tool input is invalid JSON",
  "code":"MALFORMED_RESPONSE"}}}

即：一条语法坏的调用，让整轮（含那条合法调用）全部作废。

相关代码（dsh-llm-deepseek）

// message_stop 处逐条校验 tool-call 的 arguments
if (reason.kind !== "max-tokens") for (const { content } of blocks.values()) {
  if (content.type !== "tool-call") continue
  let parsed
  try {
    parsed = JSON.parse(content.arguments)
  } catch (_invalidProviderToolJson) {
    return malformed("tool input is invalid JSON")   // ← 整轮失败
  }
  object(parsed)
}

function malformed(detail) {
  throw new LlmError(`DeepSeek Messages stream: ${detail}`, "MALFORMED_RESPONSE")
}

为什么值得改

1. 已对"不完整"宽容，但只针对 max-tokens：if (reason.kind !== "max-tokens") 说明截断场景被考虑过；语法坏 JSON 没有同等宽容，直接整轮失败。
2. 这是随机性错误：同一模型对同一问题重发一次通常就合法，整轮失败把一次偶发变成用户可见的硬失败。
3. 代价与收益不成比例：坏的是 1 条调用，丢掉的是整轮推理、其它并行调用和用户的等待。
4. 错误信息不可诊断：tool input is invalid JSON 不带工具名、不带片段、不带字节位置，用户和开发者都无从定位。

建议

1. 隔离坏调用（首选）：解析失败的那条转成「参数无效」的工具结果（带工具名 + 原始 arguments 片段）回灌给模型让它重发；其余合法调用照常执行。
2. 或自动重试一次：检测到 tool input is invalid JSON 时丢弃该响应、以同样请求重试 1–2 次（计入 usage，并设上限避免循环）。
3. 最低限度：把诊断信息补进错误，例如

   DeepSeek Messages stream: tool input is invalid JSON (tool "ops_glob", at byte 12: expected '"')
   

   对用户自助排查和上游 issue 都有决定性帮助。
4. 可选：对常见可修复情形（结尾多余逗号、未加引号的裸值）先做一次宽松修复再 parse，但必须显式记录「已修复」告警，不要静默通过。

影响范围（供参考，说明是低频）

同一台机器 31 个会话、数百次 tool-call 中只出现 1 次；但一旦发生就是整轮失败，用户体感很差。

[PerryLink]

一条坏调用能拖垮整轮，是因为解析发生在流翻译内部，抛的是 LlmError，而这条路径上没有"部分成功"。

packages/llm/llm-deepseek/src/translate.ts:155：

try { parsed = JSON.parse(content.arguments) } catch (_invalidProviderToolJson) { return malformed('tool input is invalid JSON') }

malformed 在 :25-26 直接 throw new LlmError(..., 'MALFORMED_RESPONSE')。这个解析发生在 message_stop 分支里（:148 先要求所有 block 都已 closed），而不是在逐个 delta 到达时。所以顺序是这样的：你那条合法的 ops_bash 已经执行完了（你表里的 ✅ 就是证据），随后 message_stop 校验所有 tool-call 的 arguments，撞到坏的那条就抛，:160-161 的 usage 和 finish 都不会发出，整轮按错误结束——已经执行完的结果因此到不了用户手上（"拿不到任何部分结果"）。

所以不是重试逻辑没生效，是这条路径上没有"部分成功"的分支：校验在收尾时对所有 block 一次性做，任何一条失败即整条流失败。

改法就在这个 catch 里：把"某条调用的 arguments 坏了"和"流本身坏了"分开，给该 block 记一个 invalid-arguments 标记让 turn 继续，由工具层把这条调用当 invalid input 回给模型，模型下一轮可以重发。catch 的形参名 _invalidProviderToolJson 说明这种输入是被预料到的，只是当时选了让整轮失败。

版本上核过一遍：你报的是 0.2.1-alpha.4，我对着 687f282（0.2.1-rc.2）读的 :155，形态没变，所以这不是已经修掉的旧问题。