[Bug][0.2.1-rc.5] 单条 tool_use 参数非法即整轮硬失败：MALFORMED_RESPONSE 仍不在默认重试码（汇总 #7705/#8920/#8976/#9402/#9503/#10406，附 rc.5 复现与补丁建议）

[hoyin-law]

TL;DR (EN) — On the latest release line (@deepseek-ai/dsh 0.2.1-rc.5 / Desktop 2.0.17), one malformed tool_use arguments string still aborts the entire turn with MALFORMED_RESPONSE and no retry, because MALFORMED_RESPONSE is still missing from DEFAULT_RETRYABLE_CODES. This is the same defect as #7705 (2026-09-24), #8920, #8976, #9402, #9503 and #10406 — five weeks, six threads and three released versions later, packages/llm/llm-deepseek/src/translate.ts and packages/llm/llm/src/retry-policy.ts are unchanged. A ready patch has existed in a public fork since 2026-10-06 (#8976). Please prioritize this / commit to a target version. rc.5 evidence (Windows 11, 2026-10-28 → 10-30), exact code paths and two fix options (short-term retryable code; proper fix = non-fatal tool error + model self-correction) are below.

环境

• DSH Desktop 2.0.17，核心 0.2.1-rc.5，Windows 11 x64，直连 api.deepseek.com（无代理）
• provider deepseek-official（@deepseek-ai/dsh-llm-deepseek-api-key），model deepseek-flash（DeepSeek-V4.1-Flash），thinking 开，contextWindow 1,048,576，maxTokens 131,072
• 未安装 billion-context（本轮运行失败DeepSeek Messages stream: tool input is invalid JSON #7705 的初步归因已在该帖后续评论与 [Ideas] One malformed tool-call argument kills the whole turn: MALFORMED_RESPONSE/STREAM_CLOSED are not default-retryable (46 turns lost in production audit) #8976 中被证伪）

rc.5 复现（Windows，2026-10-28 → 10-30）

统计方式：~/.dsh/sessions 下 394 个会话日志逐 zstd 帧解码后全文扫描（日志是多帧 zstd，普通 zstd 解只出第一帧，容易漏）。

本地时间（UTC+8）	会话	位置	错误	现场
2026-10-29 01:52	Bot 工作区 session-695b…	turn 9 / step 8	tool input is invalid JSON	ask_user，395 字符参数，末尾多一个 }；JSON.parse 报 Unexpected non-whitespace character after JSON at position 394
2026-10-30 18:35	Spider1.5 session-1854…	turn 15 / step 57	tool input is invalid JSON	memory，485 字符；长中文串尾部错位（内容已脱敏）：实际 …exit 0。".target": "daily"}，应为 …exit 0。", "target": "daily"}
2026-10-30 16:36	同一 session-1854…	turn 12 / step 6	duplicate message_start	只产出 reasoning block，translate.ts#L111 抛 MALFORMED_RESPONSE

对照实验（同一会话、同一天）：turn 11 / step 53 连续 5 次 Service is too busy（SERVER）被 dsh-llm-retry 自动重试并恢复（llm/retry 事件 5 条）；上面两个参数错误前后 0 条 llm/retry。⇒ 重试器没坏，是错误码不在白名单。

另：失败的 assistant/attempt.stream 里 tool-call 的 block-end 已经产出（参数完整交付），所以这不是“流被截断”，而是模型把参数写坏 / 上游 SSE 事件异常。两次坏格式都是长中文自由文本参数的尾部错位（多括号、引号/逗号错位），与 #9402（hh9527、LDyty 的取证）和 #9503（未转义引号、截断）的形态一致。

根因（master 现状，2026-10-30）

• packages/llm/llm-deepseek/src/translate.ts#L148-L158（message_stop 分支，非 max-tokens）：每个 tool-call 都 JSON.parse(content.arguments)，失败即 malformed('tool input is invalid JSON') → MALFORMED_RESPONSE（L26）。
• packages/llm/llm/src/retry-policy.ts#L18-L24：DEFAULT_RETRYABLE_CODES = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT] —— 没有 MALFORMED_RESPONSE，也没有 STREAM_CLOSED；schema 默认值 L90。
• @deepseek-ai/dsh-llm-retry 只在 policy.retryableCodes.includes(failure.code) 时重试 ⇒ 该失败即终点。
• 不对称点在自己注释里：Truncated tool JSON is retained in the stream, then pruned by the shared assembler —— 只有 max-tokens 被豁免；"写完整但写错"这一类没有走同一条容错路。
• 工具层其实是容忍的：packages/core/tools/src/batch.ts#L98-L103 的 parseArguments 解析失败会保留原文、交给工具 schema 报可纠正错误；但 translate 在它之前就硬失败了。

建议修复

短期（最小，可今天就合）

把 MALFORMED_RESPONSE + STREAM_CLOSED 加进 DEFAULT_RETRYABLE_CODES（或新增更窄的 INVALID_TOOL_INPUT_JSON，只在“全部 tool-call 参数不可读且无 text/reasoning 伴随”时可重试）。

• 现成补丁：Frank2015a/deepseek-harness@fix/default-retry-stream-failures（d719982，2026-10-06，改 retry-policy.ts + tests/retry-policy.spec.ts#L16）。master 的 retry-policy.ts 自 2026-08-18 未变，补丁应仍可直接应用。
• 作者实测：修复后同日 2 次真实错误均被重试并成功收尾（[Ideas] One malformed tool-call argument kills the whole turn: MALFORMED_RESPONSE/STREAM_CLOSED are not default-retryable (46 turns lost in production audit) #8976）。
• 已知代价：整步重试会连坐同一步里其它正常调用（Bug: dsh-llm-deepseek 偶发把工具参数拼成非法 JSON ⇒ MALFORMED_RESPONSE 硬终止（无重试、无原文） #9402），所以仍需正解。

正解（建议排期）

1. 不要 fail-fast：解析失败的 tool-call 保留并标记“参数不可解析”（原文 + 错误位置），交给工具层 → 作为 isError 工具结果回给模型，让模型在同轮重写该调用；仅当没有可读调用时才按可重试错误处理。参考 Vercel AI SDK repairToolCall / opencode 的 repair-then-retry（How other agent platforms handle malformed tool-call arguments — and the two layers this repo is missing #9503 已做跨平台调研），也与 batch.ts::parseArguments 的容忍行为一致。
2. 可诊断：错误信息带 tool name/index、JSON.parse position、参数尾部片段、provider request-id；并把失败原因写进会话正文（现在只在轨迹/日志里，用户只看到“本轮失败”，不知道回“继续”能恢复——Bug: dsh-llm-deepseek 偶发把工具参数拼成非法 JSON ⇒ MALFORMED_RESPONSE 硬终止（无重试、无原文） #9402）。
3. 回归测试：合成 SSE（input_json_delta 拼出非法 JSON / 重复 message_start）覆盖：可重试或可恢复、不得整轮静默失败、duplicate message_start 有明确分类。

为什么现在必须提（催促）

• 首次报告 本轮运行失败DeepSeek Messages stream: tool input is invalid JSON #7705 是 2026-09-24；10-06 [Ideas] One malformed tool-call argument kills the whole turn: MALFORMED_RESPONSE/STREAM_CLOSED are not default-retryable (46 turns lost in production audit) #8976 已有生产审计（961 份日志 / 43 会话 / 220 次）和现成补丁；10-11 Bug: dsh-llm-deepseek 偶发把工具参数拼成非法 JSON ⇒ MALFORMED_RESPONSE 硬终止（无重试、无原文） #9402 有逐行源码定位与重试策略分析；10-20 [bug] 单条 tool-call 的 arguments 非法即整轮失败（MALFORMED_RESPONSE），建议隔离坏调用或自动重试 #10406；10-24 How other agent platforms handle malformed tool-call arguments — and the two layers this repo is missing #9503 给出跨平台调研。
• 今天（0.2.1-rc.5）默认表仍未包含该码，相关代码路径未变；至少 0.1.7-rc.2 / 0.2.0-rc.2 / 0.2.1-rc.5 三个已发布版本连续复现。
• 对长任务/自动化用户，这不是“偶发弹窗”，而是每一轮都可能中断 + 必须人工发“继续”，直接破坏无人值守流程。
• 请求维护者：给出修复目标版本与时间表；若短期不能改默认策略，至少 (a) 把该码加入默认重试，(b) 在 release notes 明确说明，(c) 在 Settings 暴露官方开关。不要让每个用户靠自写插件或改 cordis.patch.yml 兜底。

用户侧临时兜底（不算修复）

在 ~/.dsh/profiles/desktop/cordis.patch.yml 的 - id: llm-deepseek（及 llm-deepseek-account）config 追加：

retryPolicy:
  mode: normal
  maxRetries: 3
  retryableCodes:
    - EMPTY_RESPONSE
    - RATE_LIMIT
    - SERVER
    - TIMEOUT
    - TRANSPORT
    - MALFORMED_RESPONSE
    - STREAM_CLOSED

重启 DSH 生效。更窄的社区方案：@argszero/cordis-plugin-empty-response-retry（#9402）。

相关： #7705 #8920 #8976 #9402 #9503 #10406

[NachoGPT7007]

补一个数据点。我在 0.2.2-alpha.2（主帖是 0.2.1-rc.5，两代都有）遇到同款，Windows + WSL2，web profile，官方 API。20 天出现了 13 次，全是长 tool-call 场景。截断都断在 arguments 字符串中间，单条 176～7935 字符不等，断的位置没什么规律，不太像超 token，更像流式中途断的。

翻了翻 translate.ts 150 行附近：注释里说截断的 JSON 应该由 assembler 剪掉，但实际代码是先 JSON.parse，然后非 max-tokens 的截断原因直接 malformed 抛错：

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

剪枝路径一直在，就是这一步没走到。和 #11598 的 .kind 裸读应该是同一片代码。

我本地把非 max-tokens 的截断改走已有的 max-tokens 剪枝路径，之后就没再复现。代价是那一轮 tool-call 会整体丢掉，不过比整轮失败连上下文一起丢强。所以比起把 MALFORMED_RESPONSE 塞进 DEFAULT_RETRYABLE_CODES，走现成剪枝路径改动面更小。

[cloveric]

Adding an independent macOS arm64 / Node 24.19.0 / dsh 0.2.1-rc.4 reproduction and a credential-free minimal fixture.

What we observed

A completed worker handed back an artifact path. The coordinating agent then successfully inspected the artifact and read three preview images. On its next model step, it proposed two tool calls:

• One delivery call with an extra trailing } in its JSON arguments (975 Unicode characters, not a huge payload).
• One other call with syntactically valid JSON.

The persisted assistant/attempt.stream contains both complete block-end events. The first call's argument deltas concatenate exactly to the malformed argument string; the final deltas are ", }, }. The turn ends with:

MALFORMED_RESPONSE
DeepSeek Messages stream: tool input is invalid JSON

There are no tool/call events for either proposed call in that failed step. Earlier successful tool results remain present and the generated files still exist. Emitting a block-end is not evidence that a tool has executed.

This points to malformed generated tool arguments plus terminal failure handling, not demonstrated stream-fragment corruption. We did not retain the original HTTP/SSE bytes, so the journal reconstruction is not a raw-wire replay.

Isolated verification

The unmodified installed DeepSeekAdapter rejects the malformed fixture below at SSE byte chunk sizes 1, 31, and 65536. Removing only the extra trailing brace in the test fixture succeeds at all three sizes. Both emitted tool-argument strings are preserved exactly in all six cases.

6/6 assertions passed; no API key, live model request, network request, or tool execution. This is an adapter/parser test, not an agent-loop recovery test.

Current master inspected: ce7073d51254c26cd63b22a60835b8f948deb447. The same JSON-validation branch is still in translate.ts, and the default retry codes do not include this failure. This master observation is a source inspection, not a claim that the full current source tree was built/tested.

Suggested recovery boundary

Please keep rejecting invalid arguments. Prefer a narrowly classified invalid-tool-arguments path, with bounded model correction or failed-step regeneration only when the execution layer guarantees no call in that step has started. Preserve earlier successful steps, cancellation and retry limits. Do not silently fix punctuation and execute the result, substitute {}, pass malformed raw input to an arbitrary tool, or replay the whole user task.

Regression coverage should distinguish this from malformed SSE framing, cover a mixed valid/invalid batch, exhaustion/cancellation, and verify that previously completed side effects are never repeated. User-facing diagnostics can name the tool/block without exposing argument contents; the private journal already retained useful diagnostic evidence in this case.

Minimal sanitized offline reproduction (repro.mjs)

Run with Node 24 against the installed provider's entry point:

node repro.mjs /path/to/@deepseek-ai/dsh-llm-deepseek/lib/index.js

Or run without an argument where @deepseek-ai/dsh-llm-deepseek is resolvable. The fetch mock below never forwards to the network.

import assert from 'node:assert/strict';

// Pass a path/URL to the installed dsh-llm-deepseek/lib/index.js, or run
// where @deepseek-ai/dsh-llm-deepseek is resolvable. No API key is needed.
const { DeepSeekAdapter } = await import(process.argv[2] ?? '@deepseek-ai/dsh-llm-deepseek');
const config = {
  baseURL: 'https://fixture.invalid', defaults: { thinking: 'disabled' },
  maxTokens: 4096, defaultContextWindow: 100000, models: [],
  streamIdleTimeoutMs: 10000, maxRequestFilesBytes: 1000000,
  maxInlineRequestImageBytes: 1000000, maxImagesPerRequest: 5,
  imageOffloadByteQuantum: 1000, inlineImageOffloadByteQuantum: 1000,
  imageOffloadCountQuantum: 1, filesApiTimeoutMs: 1000,
  filePolicy: {}, retryPolicy: {},
};
let responseBytes;
let chunkSize;
let fetchCount = 0;
globalThis.fetch = async (url) => {
  assert.equal(String(url), 'https://fixture.invalid/v1/messages');
  fetchCount++;
  const body = new ReadableStream({ start(controller) {
    for (let i = 0; i < responseBytes.length; i += chunkSize) {
      controller.enqueue(responseBytes.slice(i, i + chunkSize));
    }
    controller.close();
  } });
  return new Response(body, { headers: { 'content-type': 'text/event-stream' } });
};
const adapter = new DeepSeekAdapter({
  options: () => config, resolveFiles: () => ({}),
  resolveAuth: async () => ({ headers: {} }), resolveUserId: () => 'fixture',
  prepareExtensions: async () => ({ fields: {}, accept: async () => {} }),
});
for (const extraBrace of [true, false]) {
  const args = ['{"caption":"演示"}' + (extraBrace ? '}' : ''), '{"ok":true}'];
  const events = [{ type: 'message_start', message: { usage: { input_tokens: 1, output_tokens: 0 } } }];
  for (let index = 0; index < args.length; index++) {
    events.push({ type: 'content_block_start', index, content_block: {
      type: 'tool_use', id: `call_${index}`, name: `example_${index}`, input: {},
    } });
    // Separate argument deltas; also split SSE bytes independently below.
    for (const partial_json of args[index]) {
      events.push({ type: 'content_block_delta', index,
        delta: { type: 'input_json_delta', partial_json } });
    }
    events.push({ type: 'content_block_stop', index });
  }
  events.push({ type: 'message_delta', delta: { stop_reason: 'tool_use' }, usage: { output_tokens: 10 } },
    { type: 'message_stop' });
  responseBytes = new TextEncoder().encode(events.map(e =>
    `event: ${e.type}\ndata: ${JSON.stringify(e)}\n\n`).join(''));
  for (chunkSize of [1, 31, 65536]) {
    const chunks = [];
    let failure;
    try {
      for await (const chunk of adapter.stream({ provider: 'deepseek', model: 'fixture',
        messages: [{ role: 'user', content: [{ type: 'text', text: 'Parser fixture' }] }],
      })) chunks.push(chunk);
    } catch (error) { failure = { code: error.code, message: error.message }; }
    const blocks = chunks.filter(c => c.type === 'block-end');
    assert.deepEqual(blocks.map(c => c.block.arguments), args);
    if (extraBrace) {
      assert.deepEqual(failure, { code: 'MALFORMED_RESPONSE',
        message: 'DeepSeek Messages stream: tool input is invalid JSON' });
      assert.equal(chunks.some(c => c.type === 'finish'), false);
    } else {
      assert.equal(failure, undefined);
      assert.equal(chunks.at(-1).reason.kind, 'tool-calls');
    }
    console.log(JSON.stringify({ extraBrace, chunkSize, passed: true, failure }));
  }
}
assert.equal(fetchCount, 6);
console.log('6/6 parser fixtures passed; network requests=0; tools executed=0');

[Roshenn]

补充一个字符级定位的案例，以及一条此前没在本帖记录的证据：运行时已有的 JSON 修复层救不了这类错误，所以「顺手修一下 JSON」不是可选项。

环境

• Windows 11 x64，DSH Desktop（bundled 安装版）
• provider enrigin（@deepseek-ai/dsh-llm-pi-ai，anthropic-messages 协议）
• model deepseek-flash，thinking 开
• 不是 deepseek-official 路由，所以这条缺陷跨 adapter：报错文本是 pi-ai 的 argumentsError 形式（Tool call "<name>": <message>），而 llm-deepseek 会写成 tool input is invalid JSON；两条路径最后都走到 throw new LlmError(..., "MALFORMED_RESPONSE")，且同样只豁免 stopReason === "length"。

现象

一个普通对话轮的第 10 步，模型产出的工具入参不是合法 JSON：

Tool call "ask_user_question": Expected ',' or '}' after property value in JSON at position 481 (line 1 column 482)

turn/end 直接 reason.kind = "error"、code = MALFORMED_RESPONSE，前 9 步的读码与 skill 加载全部作废，全程没有重试 attempt。

字符级定位（业务内容已脱敏）

位置	字符	说明
480	" (U+0022)	长字符串里一个未转义的 ASCII 双引号
481	「别」	解析器已把 480 当成字符串结束，481 不满足 ,/} 语法

• 入参全长 3185 字符、单行；内容引号 33 个（32 个正确转义，1 个裸 "）；\n 转义 43 个。
• 入参完整（以 ]} 收尾），不是截断，也不是流式分片拼接的问题。
• 反向验证：截断会报 Unterminated string，裸控制字符会报 Bad control character in string literal，都不是本次的报错文本。

也就是说：这是模型生成时的局部转义失手，不是流损坏。任何「修 assembler / 修 SSE 分片」的方向都覆盖不到它。

新证据：已有的 repair 层必然失败

调用链 parseToolCallArguments() → parseJsonWithRepair() → repairJson()（packages/**/utils/json-parse.ts）：

• repairJson 只做两件事：转义字符串内的裸控制字符、把非法转义符前的反斜杠翻倍；
• 一个裸 " 在语法上是合法的字符串结束符，无法区分「作者想强调」还是「字符串到此为止」；
• 我把该算法原样应用到原始 payload 跑了一遍：repair changed? false，重解析仍报同一句错，于是 parseJsonWithRepair 原样抛出。

所以只剩两条路：可重试，或非致命错误 + 模型同轮自我修订。

与 #8976 补丁的关系

赞同那个补丁的方向，补两条支持论据：

1. 这类失败发生在任何工具执行之前。失败 session 里 tool/call 事件为 0，整步重试不会重复副作用 —— Bug: dsh-llm-deepseek 偶发把工具参数拼成非法 JSON ⇒ MALFORMED_RESPONSE 硬终止（无重试、无原文） #9402 担心的「连坐同一步其它工具调用」在这种形态下不成立。
2. retryableCodes 是 per-provider 配置，不必等内核改动即可生效：

retryPolicy:
  mode: normal
  retryableCodes:
    - EMPTY_RESPONSE
    - RATE_LIMIT
    - SERVER
    - TIMEOUT
    - TRANSPORT
    - MALFORMED_RESPONSE
    - STREAM_CLOSED

但默认值仍然只有 5 个码，等于每个新用户都要自己踩一次才知道要加 —— 这大概也是本帖跨 5 周、多个帖子仍持续有人报的原因。

建议

1. 短期：把 MALFORMED_RESPONSE（以及同类的 STREAM_CLOSED）纳入默认重试码；
2. 正解：采用 [Bug][0.2.1-rc.5] 单条 tool_use 参数非法即整轮硬失败：MALFORMED_RESPONSE 仍不在默认重试码（汇总 #7705/#8920/#8976/#9402/#9503/#10406，附 rc.5 复现与补丁建议） #11577 已提出的「非致命工具错误 + 模型同轮自我修订」，重试只作兜底（重新采样有成本，也可能复现）；
3. 若担心整步重试范围过大，可以只在「本步全部 tool-call 参数均不可解析，且无 text/reasoning 产出」时重试。

恳请给一个目标版本或里程碑。

[pidongqianqian]

TL;DR (EN) — Independent macOS reproduction on the newest release line (@deepseek-ai/dsh 0.2.2-rc.1 / Desktop 2.0.22-next): 3 malformed tool-call argument streams in 154 model steps (~2%/step), all three corrupted at the same syntactic point, and all three killed the turn with no llm/retry event. It is a DSML-token leak into the JSON argument string, same as #9848, but with a rate measurement that explains why long turns fail almost every time.

环境

• DSH Desktop 2.0.22-next，核心 0.2.2-rc.1，macOS arm64，Electron 44.7.0 / Node 24.21.0
• provider deepseek-official（@deepseek-ai/dsh-llm-deepseek-api-key），model deepseek-flash
• reasoningEffort: max，contextWindow 1,048,576，maxTokens 256,000
• 会话 session-59a8ece1-…，cwd 是一个普通业务仓库，未装 billion-context 之类插件

频率：2%/步，这才是"总是失败"的来源

该会话切到这条路由后共 154 个模型步，坏 3 次（1.9%）：

turn	失败在	参数长度	JSON.parse 报错
15	step 16	1765	Invalid control character at: line 1 column 1729
16	step 1	613	Invalid control character at: line 1 column 527
17	step 43	831	Invalid control character at: line 1 column 746

三次落在完全不同的位置（step 16 / step 1 / step 43），并且紧接着的 turn 在同一份 history 下重发"继续"就成功、之后连跑 42 步。按 2%/步算，40 步的 turn 约 55% 会踩中一次 —— 用户侧的感受就是"这个会话每轮都失败"，而它其实是概率性的。

字符级证据：DSML 标记泄漏进 arguments

三次都发生在 bash 调用的同一处：紧接 "justification": "" 之后，本来该写 "sandbox_permissions": "danger-full-access" 的位置，模型吐出了自己的原生工具调用标记：

…, "justification": "", "danger-full-access</｜｜DSML｜｜ parameter>\n</｜｜DSML｜｜ invoke>\n</｜｜DSML｜｜ calls>

另两次是同一形态的混合体，DSML 片段把下一个键名整个吃掉，只剩值：

…, "justification": "", "danger-full-access</｜｜DSML｜｜ parameter>\n<｜｜DSML｜｜ parameter name=": 10000, "workdir": "<repo>"}
…, "login": true, "run_in_background": false, "danger-full-access</｜｜DSML｜｜ parameter>\n<｜｜DSML｜｜ parameter name=": 1000, "workdir": "<repo>"}

所以坏法有两个：字符串里出现裸换行（Invalid control character），以及结构错位（timeoutMs 的键被 DSML 片段替换，只剩 : 10000）。

三次坏点都集中在 justification / sandbox_permissions 这组"提权"参数上（该会话 412 次 bash 调用里有 89 次带 justification），看起来模型在写这组参数时会退回到自己的训练格式。这条与 #9848 的 DSML 结论一致，那里是 deepseek-flash 的同类泄漏。

关键点：SSE 信封是完好的。 message_start → content_block_delta → message_stop 全部一致，stop_reason 是 tool_use，所以 translate.ts 里 reason.kind !== 'max-tokens' 的豁免不适用 —— 这不是截断，也不是协议违规，只是模型内容质量。

与主帖结论一致的三点复核

1. 坏的那条 assistant 消息没有写进 session log（失败 step 无 assistant/message 事件），history 保持干净 —— 也就是这个 step 在持久边界上是可以直接重跑的。
2. 失败前后 llm/retry 事件 0 条，直接 turn/end {"reason":{"kind":"error", "error":{"code":"MALFORMED_RESPONSE"}}}。
3. 上游 master 今天仍是 return malformed('tool input is invalid JSON')，DEFAULT_RETRYABLE_CODES 仍是 5 个码 —— 0.2.2-rc.1 没有修，与 [Ideas] One malformed tool-call argument kills the whole turn: MALFORMED_RESPONSE/STREAM_CLOSED are not default-retryable (46 turns lost in production audit) #8976 那个公开补丁分支的判断一致。

现阶段的绕过方式（每台机器自己打，不替代上游修复）

profile patch 里给两条 DeepSeek 路由显式扩码，MALFORMED_RESPONSE + STREAM_CLOSED 就会在 step 边界原地重试（失败的部分输出不进模型上下文）：

- id: llm-deepseek
  config:
    retryPolicy:
      mode: normal
      maxRetries: 5
      retryableCodes:
        [MALFORMED_RESPONSE, STREAM_CLOSED, EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]

（llm-deepseek-account 同理；mode: always 能覆盖但会无限重试、连永久错误一起重试。）

这只能由用户自己发现并手工配置 —— 也正因如此，主帖和 #8976 的诉求是对的：把可恢复的那一类分类进默认重试集合（或给它一个独立 code，如 INVALID_TOOL_ARGUMENTS），而不是让每一台机器各自打补丁。

[mistyhey]

补一个「尾部截断」变体（provider ark-beijing，协议 openai-completions），与主帖里「参数写坏但有 block-end」不同：这次的坏调用连 block-end 都没产出。

环境：DSH Desktop / 核心 0.2.2-rc.1，macOS arm64；provider ark-beijing（@deepseek-ai/dsh-llm-pi-ai，api: openai-completions，base URL https://ark.cn-beijing.volces.com/api/plan/v3），model deepseek-v4.1-flash（响应 deepseek-v4-1-flash-261017），pi-ai 1.3.0。

现场（2026-11-12 14:31:48 +08:00，turn 1 / step 19）：一条 assistant 消息两个 bash 调用。

• call #1：75 个 toolcall_delta，拼接完整（213 字符），末尾是 " 后跟单独一个 }；
• call #2：48 个 toolcall_delta，拼到 ...2>/dev/null" 停止（103 字符），} 和必填 description 都没出现；
• 紧接着同一毫秒 usage + finish，stopReason = toolUse（不是 length），usage output 1961。

结果：pi-ai 的 toolcall_end 带 argumentsError，adapter 在 done 处抛 MALFORMED_RESPONSE（dsh-llm-pi-ai/lib/index.js:1656），该码不在默认重试集合，llm/retry 0 条，整轮终止。

两点补充：

1. 这条路径走不到「截断剪枝」——现有豁免只对 stopReason === "length" 生效，这里是 toolUse + 参数确实没写完；
2. 不是同一步全部调用都不可读：call #1 完全合法，只有最后一个坏了。按「短期=重试 / 正解=非致命工具错误」两案，这种情况更适合把坏调用转成 isError 工具结果回给模型，而不是重跑整步（避免连坐 call #1）。

频率：本机 4 天内 3 次（2 次 messages 端点、1 次 completions 端点），全部整轮失败。

这条是否已包含在 #11577 的修复范围里？