Bug: dsh-llm-deepseek 偶发把工具参数拼成非法 JSON ⇒ MALFORMED_RESPONSE 硬终止（无重试、无原文）

[lanex2000]

DSH issue · 工具参数 JSON 损坏（tool input is invalid JSON）

现象

模型返回的工具调用，其参数偶尔不是合法 JSON，宿主直接抛硬错：

DeepSeek Messages stream: tool input is invalid JSON
（code = MALFORMED_RESPONSE）

该轮就此终止，没有重试，报错也不带原始参数原文。

复现（普通消息即可，无需任何打断）

1. 起 自研 TUI profile（provider=deepseek-official，model=deepseek-flash）
2. 发一条普通用户消息，例如：读一下当前目录的 README.md，把第一行告诉我
3. 该轮报 tool input is invalid JSON

网页端（provider=deepseek-account，model=deepseek-flash）同样中；
真 TTY 探针（stdout 留控制台、stderr 落文件）也能稳定复现 ⇒ 与 TUI 渲染无关，是适配器层。

定位

app.asar 内的 DeepSeek Messages 适配器：对每个 tool-call 块执行 JSON.parse(content.arguments)，
失败即抛 MALFORMED_RESPONSE：

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

实测（2026-10-11，本机会话件可查）

• 12:0x 长格 pane0（official 路由）：一轮之内出现无效参数，工具调用未落地
• 04:2x 网页端本席（account 路由）：一次直接报该错；另一次是命令参数里混进了助手自己的正文片段，PowerShell 因此报 ParserError（同源损坏）

用例说明（防误读）

上面那条消息本身毫无异常：纯中文、一条指令、无插话、无特殊字符、约 25 字。
不是必现（偶发）；当天本机已复现 ≥4 次。换任何要求工具调用的普通消息都可能中 ⇒
该句只作现场定格，不是触发条件。

建议（代价从低到高）

1. 容错解析（适配器内）：仍待裁 —— llm/stream 外层包不住（解析跑在适配器内部块状态上）
   2. 报错带原文 —— 已澄清：原文本就落在会话记录的 assistant/attempt.stream（tool-call-chunks），缺的只是错误信息不回显
   3. 并入可重试类 —— 已澄清：retryPolicy.retryableCodes 是 provider route 的受支持字段，配置即可、不用改码（整表替换）
   4. 不入档 —— 已澄清：失败的 attempt 从不提交成 assistant/message，本就成立

环境

实际跑该 TUI 的 CLI：@deepseek-ai/dsh 0.1.7-rc.2（node 22.23.2；该版本的重试策略源码在 dsh-llm/lib/types/retry-policy.js——默认可重试码正是 EMPTY_RESPONSE／RATE_LIMIT／SERVER／TIMEOUT／TRANSPORT 五个，retryableCodes 是整表替换）；桌面壳另为 0.2.0-rc.2（自带内嵌 runtime）；
app.asar 115.7 MB（app.asar.unpacked 只有 node_modules，外部改不了）

相关上游（提之前先看，避免重复）

• deepseek-ai/deepseek-harness Discussion Bug: streamed tool calls assembled with empty name/callId when continuation deltas carry explicit id:""/name:null (dsh-llm-deepseek, rc.6 & rc.7) #3281：流式工具调用拼装（空 name/callId，dsh-llm-deepseek，rc.6/rc.7）
• ranxianglei/billion-context Issue [插件分享] dsh-plugin-dit：一条命令接入 DIT，29 个 Chat 模型 + 10 个 Messages 模型 #2605：要求把 MALFORMED_RESPONSE 纳入重试名单（与本件建议③同）
• xerrors/Yuxi PR dsh-polling — cron-driven polling/scheduled tasks for DeepSeek Harness（轮询任务/定时任务插件：自然语言创建 + Web 管理） #1006：净化 invalid_tool_call 与孤儿 ToolMessage，规避 DeepSeek 报错

[argszero]

Thanks for the precise report — the whole chain is traceable in the tree, and your four suggestions turn out to have three different owners. Two of them are already reachable today without a code change.

Where it is thrown, exactly

packages/llm/llm-deepseek/src/translate.ts, in the message_stop branch, and only when the finish reason is not max-tokens:

if (reason.kind !== 'max-tokens') {
  for (const { content } of blocks.values()) {
    if (content.type !== 'tool-call') continue
    let parsed: unknown
    try { parsed = JSON.parse(content.arguments) } catch (_invalidProviderToolJson) { return malformed('tool input is invalid JSON') }
    object(parsed)
  }
}

malformed() is throw new LlmError(\DeepSeek Messages stream: ${detail}`, 'MALFORMED_RESPONSE'). object()rejects *any* parse result that is not a plain record, sonull`, a bare string or a number fails here too.

One detail worth keeping: the block itself has already been delivered. The tool call's block-end chunk is yielded when content_block_stop arrives, i.e. before this parse. So this is a complete response whose tool JSON is corrupt — not a truncated one. Truncation is the max-tokens branch, which is deliberately skipped here and pruned by the shared assembler.

Why nothing retries (and why suggestion ③ needs no code)

The throw happens inside the adapter's own stream iteration, so LlmRuntime.adapterStream catches it and converts it into the stream protocol's terminal outcome — a { type: 'finish', reason: { kind: 'error', failure } } chunk (packages/llm/llm/src/index.ts, adapterFailureChunk), with normalizeLlmFailure preserving code: 'MALFORMED_RESPONSE'. From there the ordinary path runs: the agent loop's finish.kind === 'error' branch (packages/core/agent-loop/src/agent.ts) dispatches agent/request-error with the serving route's policy, and dsh-llm-retry decides on one fact only:

} else if (!policy.retryableCodes.includes(failure.code)) {
  return next()
}

MALFORMED_RESPONSE is not in DEFAULT_RETRYABLE_CODES (packages/llm/llm/src/retry-policy.ts = EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT), so the step delegates downstream and the turn ends. The code is not "hard-coded terminal" — it is simply outside the default table.

retryPolicy is a supported field on the provider route (packages/llm/llm-deepseek/src/config.ts, RetryPolicySchema), and dsh-llm-retry is part of the base bundle (packages/bundle/base/cordis.patch.yml), so the executor is mounted in every shipped profile. One trap: retryableCodes replaces the default list, it does not extend it.

- name: '@deepseek-ai/dsh-llm-deepseek-api-key'   # the route instance serving the failing calls
  config:
    retryPolicy:
      mode: normal
      maxRetries: 5
      retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT, MALFORMED_RESPONSE]

Each retry is another billed provider request; the configuration shape is documented in packages/llm/llm-retry/README.md.

Suggestion ② is half satisfied already, and ④ already holds

The raw arguments are durable today, in the session log. The attempt's chunks are compacted per delta run by AssistantStreamAccumulator — a tool call becomes one { type: 'tool-call-chunks', id, name, args: [...] } record (packages/llm/llm/src/assistant-stream.ts) — and the loop commits that stream as assistant/attempt.stream before rethrowing (agent.ts: the catch block runs live.settle('assistant/attempt', …)). So the exact invalid arguments string is recoverable from the failed attempt; what is missing is only that the error message does not echo it.

And ④ holds by construction: a failed attempt is never committed as an assistant/message, so no damaged call ever reaches the message history or a later request. Nothing needs to be excluded — the exclusion is the default.

The other two belong to the adapter

• ① tolerant parsing has to happen where the harness decides what the model meant. A repair pass at the llm/stream seam cannot make such a turn succeed: the adapter's own JSON.parse runs on its internal block state, not on the chunks an outer wrapper can rewrite, so the throw still fires at message_stop — a wrapper could only synthesize a different finish, which would fabricate a message whose content the provider never validated. Tolerant parsing (or a documented decision not to do it) is the adapter's call.
• The error's surface is one template line (translate.ts: \DeepSeek Messages stream: ${detail}`). Echoing a truncated content.arguments` there is a one-line change with no policy implications.

Two notes for whoever picks this up

• MALFORMED_RESPONSE has five producers in this adapter (sse.ts ×2 for the envelope, translate.ts ×2 for typed fields, plus the tool-JSON one). Only the last is about tool arguments; the others are envelope-level corruptions. A retry keyed on the code alone therefore also repeats those — which happens to be safe (a failed attempt commits nothing durable either way), but it explains why the code is not "about the tool call".
• If a retry is wanted with a narrower trigger than "every MALFORMED_RESPONSE", that seam exists: a plugin wrapping llm/stream sees both the tool-call block-end chunks and the terminal error finish, so it can gate the widening on the structural fact (every tool-call block's arguments fails to parse, nothing else durable in the attempt) rather than on the code. That is what I am adding as a fourth recognition to @argszero/cordis-plugin-empty-response-retry (source-level reports [llm-pi-ai] Upstream "Provider returned an empty response" (OpenRouter) falls through classifyPiAiError to non-retryable PI_AI_ERROR #8321, [Bug] 未分类的空 body HTTP 400 被判为 INVALID_REQUEST，导致长会话被永久锁死 #9352, [Bug] llm-pi-ai 将上游重试缓冲错误归为 PI_AI_ERROR，跳过自动重试 #9397); I will post the version here when it lands.

[lanex2000]

感谢定位，逐条对齐（这条只谈 tool input is invalid JSON 这一支）：

• 我们按你的说明把 retryPolicy.retryableCodes（整表替换，六个码写全）接进自研 TUI profile 的 patch，重启生效——这类轮次先不再一枪打死。
• 原帖「建议」已按你的澄清加删除线：② 报错带原文（原文已在 assistant/attempt.stream 的 tool-call-chunks 里）／③ 并入可重试类（retryPolicy 配置即可）／④ 不入档（失败的 attempt 从不提交成 assistant/message）⇒ 只剩 ①（适配器内容错解析）待裁。
• 你那个窄触发重试插件（cordis-plugin-empty-response-retry）落地后，麻烦在这个贴里说一声。

（另有一支工具调用标记漏进正文的问题，与这条是两个出口，我另起一条评论分开记，避免混线。）

[lanex2000]

完整现场：工具调用标记漏进正文（DSML）——与上面那支 tool input is invalid JSON 是两个出口，分开记。

形态：assistant/message 的 text 块里，工具调用被整段写成内部标记（｜＝全角竖线）。命令内容用示例，形态与实测一致：

<｜｜DSML｜｜ calls>
<｜｜DSML｜｜ invoke name="bash">
<｜｜DSML｜｜ parameter name="command" string="true">ls -la /tmp</｜｜DSML｜｜ parameter>
<｜｜DSML｜｜ parameter name="description" string="true">list files</｜｜DSML｜｜ parameter>
</｜｜DSML｜｜ invoke>
</｜｜DSML｜｜ calls>

这段标记落在正文、不是结构化 tool_call ⇒ 该轮没有可用的工具参数、也没有正常工具结果。

与模型侧已知报告的异同（供判断）：

• 模型侧已有两条同源报告：deepseek-ai/DeepSeek-V3 issue DSH | dsh-roleplay-preset | DeepSeek 深度调校的角色扮演预设（零工具纯对话 + 文件记忆库） #1678（未带 tools 数组时 deepseek-flash 把 DSML 写进 content，[BUG] deepseek-flash emits internal DSML tool-call markup in content when tools array is omitted but history carries tool_calls DeepSeek-V3#1678 ）、【Bug】达到最大输出长度时会话被永久写坏：后续每轮都报 invalid pi-ai replay state: block count does not match assistant content #1244（V4-Pro 偶发把 tool call 写成正文，[Bug] DeepSeek-V4-Pro intermittently emits tool calls as plain text in content instead of tool_calls field DeepSeek-V3#1244 ）。
• 我们这边请求头里 tools 是齐的（27 个工具）仍会漏 ⇒ 在"已声明 tools"的前提下同样会发生。
  想问的（先不要方案，只确认真能不能治、该在哪治）：这类"工具调用走正文通道"能否在模型侧收敛？若不宜在模型侧治，在 DSH 侧（识别／剔除／不入档）是否在你们的范围内？

（我们本机在自己的文本清洗层做了兜底，但那只管上屏与后续文本流，改不了已经写进历史记录的部分。）

[argszero]

Following up this report with an implementation, released today.

@argszero/cordis-plugin-empty-response-retry@0.4.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-empty-response-retry

For the shape you described: the Tool call's arguments never became JSON, so dsh-llm-deepseek throws at message_stop with MALFORMED_RESPONSE — a code that appears in no retryable table, so the step is terminal. The plugin observes the public llm/stream waterfall and rewrites that finish's failure.code to EMPTY_RESPONSE, which DEFAULT_RETRYABLE_CODES already carries, so dsh-llm-retry repeats the attempt on its own unchanged gate.

It is deliberately narrower than listing MALFORMED_RESPONSE in a route's retryableCodes. The code only admits the recognition; a shape gate then requires that (a) at least one Tool call was assembled, (b) every one of them is one the adapter cannot read — the adapter's own two demands, JSON.parse then a plain record, so null, an array, a string and a number count as unreadable just as a syntax error does, and (c) no text or reasoning arrived beside them. A MALFORMED_RESPONSE from an undecodable SSE envelope, or from a turn that also assembled a readable call, keeps the adapter's code.

On your other ask: the raw arguments are not lost. The attempt is recorded before the failure, so the corrupt input_json_delta stays durable in assistant/attempt.stream — the retry does not overwrite the evidence.

Install and mount:

npm install @argszero/cordis-plugin-empty-response-retry

# in a profile
- insert:
    - id: empty-response-retry
      name: '@argszero/cordis-plugin-empty-response-retry'

Start with mode: warn to measure how often it fires on your traffic before letting it change behaviour; the warning names the route, the adapter's code and the provider's message. The package is independent of the harness — a listener on a documented waterfall, so removing it restores the previous behaviour exactly.

[argszero]

0.5.0 is on npm — @argszero/cordis-plugin-empty-response-retry@0.5.0 (https://www.npmjs.com/package/@argszero/cordis-plugin-empty-response-retry).

Mount and go — add to your profile:

- insert:
    - id: empty-response-retry
      name: '@argszero/cordis-plugin-empty-response-retry'

Nothing about the #9402 rewrite changed in this release. What changed is what the package can prove about it. The three supported lines do not run the same pi-ai: the 0.1.6 / 0.1.7 lines resolve 0.85.1 and the 0.2.0-rc line resolves 0.87.1, and the two retry tables differ by exactly two alternatives (0.87.x adds currently experiencing high demand and a bare 520). The shipped transientMessages defaults and the gap floor had both been derived from 0.87.1, so on the two oldest lines one default could not be re-derived and one floor came up short.

A third arm failed for an unrelated reason worth recording, because it is the kind of failure that hides rather than announces itself: the fixture that wires the installed adapter named the credential hook resolveAuth (headers), which only the newest line reads — the two oldest lines still call it resolveApiKey (the key). The adapter therefore resolved its own credential function as undefined, the request died inside the transport wrapper as TRANSPORT, one layer above the MALFORMED_RESPONSE refusal that suite is about, and every arm gated on measuring that refusal went quiet instead of failing loudly. Three arms, two causes, all of them the suite asking a question that had only ever been answered about the newest line.

0.5.0 fixes the suite rather than the claim: the defaults are split into the wordings every supported line's table carries and NEWER_LINE_TRANSIENT_MESSAGES (the entry upstream added at 0.87.0, which stays in the runtime default), the wording arms now assert provenance per installed line, the gap floor is the smallest gap across the lines (23, at 0.85.1), and the adapter fixture supplies the credential hook under both spellings. npm run test:probe-lines passes on all three lines (0.1.6-alpha.2, 0.1.7-rc.2, 0.2.0-rc.2), and the 97 tests plus 36 mutation arms stay green.

The one place the rewrite is wider than the installed table, stated plainly: on a 0.1.x line a failure worded currently experiencing high demand is not one that line's pi-ai would retry, and this plugin makes it retryable anyway — deliberately, because upstream reached the same judgement one minor later about the same server-overload class, and the recognition's gate is the code and the wording rather than the emission. An operator who would rather stay strictly inside their own line's table passes transientMessages without that entry; the export is NEWER_LINE_TRANSIENT_MESSAGES.

[lanex2000]

Thanks — 0.5.0 noted. We are on the 0.1.7-rc.2 line, and our side already handles this shape through a wholesale retryPolicy.retryableCodes table, so the retry itself is not what we are after here: your narrower gate is, since a bare table entry also admits the shapes you keep out.

Once we mount it I can post what pi-ai resolves on our line, and whether the raw input_json_delta in assistant/attempt.stream survives the retry.

[hh9527]

补一台机器的独立复现，并建议把 ①（适配器内容错解析）作为正解——理由在最后。

三件可以补的事实

1. 量化：低频，但跨会话复现，且默认表确实从未覆盖它。
另一台机器（0.2.0-rc.2 / Linux / deepseek-official / deepseek-flash）：全部会话 444 轮里 2 轮以错误结束，
两轮都是 MALFORMED_RESPONSE；llm/retry 事件 0 条——与上面 @argszero 的定位一致：不是"硬编码终点"，
只是不在默认表里。

2. 长度不是阈值，但长参数是放大器。
两次的现场：一次是一个工具参数里塞进一整份带内联图块的 markdown（流已累计 12.4KB 仍在增长），
另一次最大只有 531 字符。⇒ 小参数也会中；但把巨型 JSON 放进单个参数会显著提高概率。
这一点对插件/工具作者是可行动的：我们随后把那份报告改成"引用已经落盘的图"，
参数从 10.6KB 降到约 7.5KB（工具参数的形状是插件能控制的，宿主替不了）。

3. 一处我先说错、核实后更正的观察：失败"看得见"，但没有一句能读的话。
我原以为是完全静默，核了 UI 之后是：0.2.0-rc.2 的会话界面会给这一轮打上「失败」
（message.turnProcess.failed），但失败原因只在轨迹视图里，会话正文没有对应消息
（会话件里 turn/end {reason:{kind:"error"}} 之后既无 assistant/message 也无 system/message）。
现场表现是：用户看到"失败"，不知道是模型把参数写坏了，也不知道只要回一句"继续"就能接上——
他那一步打了个「？」才把它唤醒，随后同一轮以 src 引用重写、7 秒完成。

为什么建议走 ①，而不是"把码加进默认重试表"

配置层（retryPolicy.retryableCodes，@argszero 已确认无需改码）与更窄的插件门控今天都能用，
但它们都是重发整个请求，共同代价有三条，而这三条恰好都不是这个失败的形状：

• 失败只是模型的一次书写失误（@argszero 已确认：块已经交付、不是截断），重发是赌下一次采样；
• 重发作废整个 step，会把同一步里正常的那些调用一起丢掉（本次现场就是一步两个调用：一个坏、一个好）；
• 它把"模型能看见自己写坏了"这件事抹掉了——反馈才是修，重采样不是。

① 的形状（提出来讨论，不当下结论）：

1. 适配器在 message_stop 不再抛致命错，而是把该块标成参数不可解析（原文保留、截断后再回给模型）；
2. 循环层把这一块当一次工具失败回给模型（"你对 X 的调用参数不是合法 JSON"），同一轮里可读的调用照常执行；
3. 给它一个独立的、非致命 code（例如 MALFORMED_TOOL_ARGUMENTS），使它既不落进 retryPolicy 的整轮重试，
   又能被"同一步内最多自纠一次"的预算兜住；
4. 兜底：若该步没有任何可读调用，退回整步重试——也就是配置层今天能做到的那件事。

另外无论 ① 怎么裁，第 3 点那条建议都值得单独做：把失败原因与下一步（"回一句继续即可"）放进会话正文，
而不是只留在轨迹视图里。

[lanex2000]

Correction to the read above, on our side: we do not run a fix here, only the config-table route, and it is not in effect at this moment — the profile carries the wholesale retryableCodes including MALFORMED_RESPONSE, the plugin is not mounted, and nothing has been restarted since the patch landed. Treat the earlier line as an intent, not a measured result.

The argument that stands is yours: a whole-step retry discards the readable calls in the same step. That is also why the config table is only a stopgap — it removes the dead turn without touching the cause, since the block is written badly and the model never hears about it.

So we back ①: keep the block, hand it back as a tool failure with its own non-fatal code, and fall back to a step retry only when nothing readable remains — plus the separate change of putting the failure reason and the next step into the conversation body.