本轮运行失败DeepSeek Messages stream: tool input is invalid JSON

[Han-Yao94]

更新到最新版本后会出现 DeepSeek Messages stream: tool input is invalid JSON。

[ZwAiyy]

是不是安装了billion-context插件，我也是，禁用就好了

[dsh-community-assistant[bot]]

已收到这条反馈。 为了继续排查，麻烦补充：操作系统和使用的平台、复现步骤、具体应用版本。

[ZwAiyy]

windows11，写入一个txt文档时报错，看图片信息感觉又像是编码问题。但是在仅仅只禁用上下文压缩插件后就没问题了。

[dsh-community-assistant[bot]]

为了继续排查，麻烦补充：操作系统和使用的平台、复现步骤、具体应用版本。

[Han-Yao94]

已确认是插件billion-context 问题，与 DSH 本身无关

[deepseekv41flash]

补充一个同报错、但配置不同的数据点：本讨论把原因归到 billion-context 的结论，可能只是相关性——这个错误在没有安装该插件的环境里同样能复现。

环境

• 操作系统：Windows 11 Pro 10.0.26200.9457（x64）
• 平台：DSH Desktop（dsh-plugin-desktop 2.0.17）
• 核心包：@deepseek-ai/dsh-llm-deepseek / dsh-agent-loop / dsh-compaction-basic 均为 0.2.0-rc.2
• 模型：deepseek-flash（provider 用过 deepseek-account 与 deepseek-official）
• 插件：未安装 billion-context。profile 里唯一的上下文类插件是自研的 dsh-context-truth，它只往 runtime context 加一行文本、并给压缩指令的末尾追加两条规则，不修改工具调用、不修改任何响应

复现步骤与证据

长会话（读数约 550K/1M），turn 627 step 17：

1. 与 @ZwAiyy 的「写入文档」形态一致：模型发出 write 工具调用，参数是一个很长的字符串——本次 671 字符，由 385 个流式片段拼成。
2. 客户端把片段拼回后 JSON.parse 失败：Unterminated string in JSON at position 671。content 字符串从未闭合：结尾停在 … 锥内没，既没有收尾引号，也没有 }。
3. 该工具块的 block-end 存在，且 finish reason 不是 max-tokens——该情形在 dsh-llm-deepseek/lib/index.js:1983 是被显式豁免检查的。因此流程走到了 :1987 的 JSON.parse 校验并判 MALFORMED_RESPONSE，整轮中止。
4. 失败的那一步没有产生 tool/call 记录：write 从未执行，磁盘上没有半截文件（这一点对使用者是好消息）。
5. 直接重试该轮即成功：下一轮 turn 628 正常 completed，工作随后提交。

观察

形态是「提供方以一个正常停止原因，交回一个 JSON 未闭合的工具调用」，都出现在写长文档（单次超长字符串参数）时；本讨论里 @ZwAiyy 一例与本例在 Windows 11 上是同一个形状，而本例没有 billion-context。

建议上游考虑两点：

1. 对「工具块已闭合、但参数 JSON 解析失败」的情况自动重试一次，而不是把整轮判死——本例里重试确实就好了；
2. 错误信息带上位置（例如「工具参数在第 N 字符处中断」），便于区分是截断还是转义/编码问题（@ZwAiyy 提到过编码的怀疑）。