[BUG] 工具执行中途崩溃后会话永久卡死：DeepSeek 400 "insufficient tool messages"（rc.6）

[2661027052]

问题描述

1. 某轮对话中，助手刚输出一个工具调用（todo_write），工具执行阶段随即崩溃，该轮报错：

   Cannot read properties of undefined (reading 'prepare')
   

2. 崩溃之后这个会话彻底废了：之后无论发什么消息，每一轮都在第一步直接失败，报：

   An assistant message with 'tool_calls' must be followed by tool messages
   responding to each 'tool_call_id'.
   (insufficient tool messages following tool_calls message)
   HTTP 400 INVALID_REQUEST
   

   一次中途崩溃 = 会话永久卡死，只能放弃该会话。

复现步骤

1. dsh web 开启会话，正常跑任务（环境：Windows 11 / Node v24.15.0 / 模型 deepseek-v4-pro）
2. 会话运行期间，在同一个 dsh 实例上安装社区插件（热加载，未重启 dsh）
3. 安装活动之后的下一个工具调用即崩溃（undefined.prepare），该轮以 UNKNOWN 错误结束
4. 在同一会话继续发任意消息 → 每轮都报上面的 400 错误，100% 复现（连续 3 轮验证）

实际行为

崩溃后会话历史里残留一条没有工具结果的 assistant tool_calls，dsh 不做任何修复（不补合成结果、不裁剪悬空消息），把残缺历史原样发给 API，DeepSeek 严格校验直接 400，会话永久无法继续。

期望行为

崩溃后会话应当可恢复：为未应答的工具调用补一条合成错误结果（类似已有的 "tool call aborted before dispatch" 处理），或裁剪悬空的 assistant 消息。至少后续消息不应再触发 API 400。

环境信息

项	值
dsh 版本	0.1.0-rc.6（npm 全局安装）
操作系统	Windows 11
Node 版本	v24.15.0
使用方式	dsh web
模型	deepseek-v4-pro（reasoningEffort: max）
社区插件	continual-evolve、fail-logger、at-file、better-sidebar、distill、automation、genui、modlens

日志与证据

崩溃那一轮（step 1）的会话事件序列：

seq	事件	说明
128939	assistant/message	助手消息含 reasoning + tool_calls
128940	tool/call	callId: call_00_BNK32bokg9LKRgMdRwlY8298，name: todo_write
128941	step/end	—
128942	turn/end	reason: {"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}

注意：该 todo_write 调用自始至终没有对应的 tool/result 事件。

之后连续三轮（25、26、27）每轮都是同一模式：

seq	事件	说明
128944	turn/start	第 25 轮
128947	user/message	新消息追加在悬空的 tool_calls 之后
128948	assistant/chunk	finish 即错误：INVALID_REQUEST、status: 400
128950	turn/end	同样的 400 错误

根因分析（AI 分析）

以下分析由 AI 辅助完成，不保证准确，仅作为排查线索提供：

1. 触发缺陷：undefined.prepare 对应 dsh-agent-loop 中 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...)。同一时刻 ctx.tools.executionMode() 正常，说明 tools 服务还在，但 Symbol 键的调度器属性变成 undefined。崩溃发生在运行中热加载插件之后，怀疑 HMR 模块重载后 dsh-agent-loop 与 ToolRuntime 之间的 Symbol 引用对不上。
2. 致命缺陷：崩溃后会话表面不做修复（appendSkippedToolCall 的合成结果逻辑只覆盖中止场景，不覆盖调度器抛异常场景），悬空的 tool_calls 被 dsh-llm-deepseek 原样序列化发给 API。

[denial123789]

这个分析基本吻合源码，而且这里其实是两个独立缺陷叠加：

1. 热加载后的运行时缺陷：agent-loop/src/tool-calls.ts 确实直接读取 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...)。如果 HMR 后 ToolRuntime 实例与调用方持有的 unique symbol 来自不同模块实例，该属性会变成 undefined，而普通的 ctx.tools.executionMode() 仍可能正常，所以现象与 Symbol identity mismatch 很一致。
2. 活会话没有被修复：appendSkippedToolCall() 只覆盖“取消导致尚未 dispatch”的调用；prepare() 自身抛错时，当前路径没有为该 tool call 写入对应的失败 tool/result。

有一个值得尝试的、比放弃会话更安全的恢复步骤：

1. 先备份 $DSH_HOME（Windows 通常是用户目录下的 .dsh）。
2. 完整停止当前 dsh 进程，不要只刷新 Web 页面。
3. 重新启动 dsh web，再恢复原会话。

原因是上游 persistence contract 明确区分了 live 与 cold session：

• live session/HMR adoption 不会关闭正在活动的 turn；
• cold session 在 prepare/load 时会执行 crash repair，补齐缺失 tool errors、开放的 step/turn 边界，并以 synthetic turn/end { reason: { kind: "interrupted" } } 关闭中断轮次。

也就是说，仅发送下一条消息不会修复；完整进程退出让该 session 变成 cold，重新恢复时才有机会走 repair。不要手工删除 JSONL/SQLite 记录，否则容易破坏连续 seq 与校验信息。

如果完整重启后仍然 400，建议补充两项证据：

• 重启后第一次 resume/load 的日志；
• 修复后该尾部是否新增了合成 tool/result、step/end 和 turn/end(interrupted)。

长期修复建议同时覆盖两层：

• tool scheduler 应避免依赖会被 HMR 复制的模块私有 Symbol identity，或在调用前做显式 invariant 并报告可诊断错误；
• prepare/dispatch 进入失败路径后，也必须为每个已记录的 tool call 写入一一对应的合成失败结果，再结束 step/turn。

在修复发布前，建议不要在有 active turn 的 dsh 实例上安装/热加载社区插件；先让 agent idle，最好重启后再继续。

源码参考：tool-calls.ts、docs/subsystems/persistence.md。如果需要按“session/continuation”边界逐步收集证据，也可以使用 Handbook 的 interactive failure router。

[2661027052]

感谢确认！按您建议的恢复流程实测了一遍，结果仍然 400，附上您要的两项证据：

说明：本人是 dsh 新手，本次测试操作、日志解读与本回复均由 AI 辅助完成。分析类结论已单独标注"AI 分析"，事实类内容（事件序列、报错原文）均为实测记录，可直接核对。

执行流程

1. 已完整备份 $DSH_HOME
2. 完整停止 dsh 进程（taskkill 杀掉 node 进程，非刷新页面）
3. 重新启动 dsh web，在 UI 中打开原会话，发送新消息

证据 1：恢复后尾部事件（无修复痕迹）

原会话（session-73f2bb3d）恢复后的新增事件序列：

seq	事件	说明
128967	session/end-seed	—
128969	turn/start	恢复后新开第 28 轮
128972	user/message	新消息
128973	request/header	—
128974	assistant/chunk	finish 即错误：INVALID_REQUEST、status: 400（同一条 insufficient tool messages）
128976	turn/end	同样的 400 错误

关键观察：恢复后没有出现合成 tool/result，也没有 turn/end(interrupted)——第 24 轮悬空的 tool call（call_00_BNK32bokg9LKRgMdRwlY8298）依旧没有补结果，crash repair 没有触发。

证据 2：resume 日志

dsh web 的日志仅输出到终端 stdout（未发现落盘的日志文件，$TEMP/dsh-spill-* 目录为空），无法提供文本日志。如需该日志，请告知日志落盘方式，我可以重跑一次并保存 stdout。

一个补充观察（供排查）

（AI 分析，未经官方验证）该会话中每一轮都有闭合的 turn/end 标记（包括出错的 24~27 轮），session 结构上是"干净关闭"的。怀疑 loader 的 crash repair 只处理"进程退出时 turn 未闭合"的场景，而本案例的悬空 tool_calls 是语义层面的一致性缺陷（turn 闭合了、tool call 没结果），不会被识别为 crash。若如此，修复点可能需要前移到请求组装处：buildRequest 前校验 surface 末尾是否存在未应答的 assistant tool_calls，补合成结果或裁剪。

补充复现信息

同一损坏实例上新建的第二个会话（session-36df5dd4）在第 1 轮就复现了 undefined.prepare 崩溃（Unknown 错误），随后同样卡死在 400。说明 HMR 缺陷在进程重启前对所有新会话生效，重启进程后新会话正常。

[denial123789]

感谢实测，这组证据把边界确认清楚了，也修正了我上一条里过宽的判断：完整重启不能修复这个会话。

你对原因的判断是对的。interruptedTurnClosers() 扫描到任意 turn/end 时会立即：

openTurn = null
openStep = null
pendingCalls.clear()

最后只有 openTurn !== null 才会生成 synthetic tool/result / step/end / turn/end(interrupted)。因此它处理的是“物理尾部存在开放 turn”的 crash tail，不会处理本例这种：

• assistant/message 含 tool call；
• tool/call 已记录；
• tool/result 缺失；
• 但错误路径仍写入了 step/end 和 turn/end(error)。

这是一份结构已闭合、provider transcript 语义不完整的日志，cold repair 会把它视为 balanced。重启后直接复现 400 正是当前代码的预期结果，而不是操作步骤问题。

更准确的修复点应有两道防线：

1. 写入侧：startCall() 已 append tool/call 后，如果 scheduler prepare/dispatch/finalize 抛错，必须 append 同 callId 的合成错误 tool/result，然后才能关闭 step/turn。
2. 请求派生侧：在交给 provider adapter 前验证每个 assistant tool call 都有一一对应的 tool result；遇到历史遗留的不完整 pair 时，拒绝并给出可操作的 session-repair 错误，或通过显式迁移流程补齐。这里不宜静默裁剪，因为已启动的工具可能有外部副作用。

你补充的“同一损坏实例中新会话也崩、完整重启后新会话恢复”也进一步支持 HMR 后模块级 Symbol identity 失配是触发器；旧会话仍 400 则是第二个持久化语义缺陷。

我已经把这次验证作为 Handbook #16 的失败样本跟踪。谢谢你保留了精确 seq 和事件类型，这比泛化日志更有诊断价值。