疑似：prepare 抛错后不写 tool/result，会话历史残留未配对的 tool_calls，之后每轮都被上游 400 拒绝

[silicon-sbt]

现象：某个会话在某一轮工具调用时报错，之后每次发消息都失败。底层错误是 DeepSeek API 返回的 400：

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)

环境：Windows 10，dsh 0.1.0-rc.7，deepseek-official / deepseek-v4-flash。

出问题的那一轮事件序列：

assistant/message   # tool-call：pwsh Get-Content 读日志
tool/call
step/end
turn/end             # reason:{kind:"error", error:{message:"Cannot read properties of undefined (reading 'prepare')", code:"UNKNOWN"}}

tool/call 写了，没有 tool/result。全会话这是唯一一次缺配对的（session.history 拉全量统计）。这轮之后每次发消息都 400。

怀疑在 dsh-agent-loop/lib/index.js 的 startCall：

callSeqs[index] = appendToolCall(session, turn, step, call.block);   // 先写 tool/call
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);  // 这里抛错

TOOL_RUNTIME_SCHEDULER 是 Symbol。ctx.tools[Symbol] 为 undefined 时 .prepare 抛的 TypeError，和 turn/end 的错误逐字一致。appendToolResult 是唯一写 tool/result 的地方，抛错路径没有兜底，残缺序列留在历史里，之后每轮都原样发给上游被 400。

我环境里触发原因是 dsh-tools 双副本（Symbol 不匹配，推断）。profile 里 dsh-tools 的 junction 建于 8/19 22:49，出事在 22:46，junction 建好后新会话正常。这条是环境问题，干净环境不一定会出现；但不管触发原因是什么，prepare 抛错不写 result 都会把会话弄坏，这个跟环境无关。

复现：curl 构造同样残缺的序列打 DeepSeek API 返回逐字相同的 400，佐证 400 是上游校验。dsh 侧未稳定复现，也没抓实际请求体。

建议：

1. startCall 里 appendToolCall 之后用 try/catch 兜住，抛错时补一条 tool_call_id 对应、content 为错误描述的 tool/result；若回滚 tool/call，必须连带去掉 assistant 消息里的 tool_calls 声明。
2. 构造请求时发现未配对的 tool_calls，丢弃整条 assistant 消息并连带后面配对的 tool 消息，用于恢复已污染的旧会话。

如需更多信息（完整事件流、会话文件）：2632530353@qq.com

[zoahdev]

你的判断两层都成立，而且两层我们都有已核验的分析：

1. prepare undefined 的触发原因：正是 Bug: installing any plugin that depends on @deepseek-ai/dsh-tools breaks every tool call (Cannot read properties of undefined (reading 'prepare')) #1697 的双实例 unique-symbol 问题——ctx.tools[Symbol] 在 dsh-tools 双副本时取不到调度器，TypeError 与 turn/end 错误逐字一致。官方仍 open，但补丁已就绪：fix/tool-runtime-scheduler-symbol-for（Symbol.for + TOOL_RUNTIME_SCHEDULER_PROTOCOL_VERSION 协议守卫 + 三态回归测试），你的 junction 场景建好后新会话正常也与此吻合（同一符号面）。

2. prepare 抛错后不写 tool/result 的缺口：这与我们 [Bug Report] Streamed tool-call arguments with truncated JSON are persisted, then every subsequent turn fails with `400 INVALID_REQUEST: Unterminated string ...` in the same session forever #3234 核验的六步链同源——tool-call 已落盘后执行器抛错，结果写入路径被吞、会话残留未配对 tool_calls，之后每轮原样重发被上游 400。这个"坏就坏在把已落盘的调用序列原样重放"的缺口与触发原因无关，正如你所说：干净环境同样会踩。

建议落地顺序与你的三点一致：

• startCall 在 appendToolCall 之后 try/catch，失败时补写一条 content=错误描述的 tool/result（保留调用但给出可消费结果）；
• 若选择回滚，必须连带删除 assistant 消息里的 tool_calls 声明，否则仍会 400；
• 对已污染的旧会话，load 时做确定性修复（我们 [Bug Report] Streamed tool-call arguments with truncated JSON are persisted, then every subsequent turn fails with `400 INVALID_REQUEST: Unterminated string ...` in the same session forever #3234 里建议过：检测未配对 tool_calls → 补 error result 或丢弃该 assistant+配套 tool 消息）。

已并入 bug 家族图谱"工具结果可信度/截断调用"族，方便以后直接引用。

[DON738110198]

我在当前干净的 dsh-v0.1.0-rc.8 / master（基线 141eb6fef83422698aef7a981029e843e8161534）上把第二层缺口做成了确定性回归测试，确认它不依赖双副本触发条件：

1. mock adapter 产生一个工具调用；
2. 在 appendToolCall 之后让 scheduler prepare() 抛出 prepare exploded；
3. 工具主体没有启动；
4. 未修复时持久事件有 1 个 tool/call、0 个 tool/result，测试按预期失败；
5. turn/end 已正常以原始错误关闭，因此现有 open-tail repair 不会修复它。

我准备的防止新污染会话的补丁在这里：

https://github.com/DON738110198/deepseek-harness/tree/fix/scheduler-failure-tool-results

补丁没有把所有情况都伪装成普通“工具执行失败”，而是保留了副作用边界：

• 确认尚未 dispatch：补 TOOL_SCHEDULER_FAILED_BEFORE_DISPATCH，可按需重试；
• 已 dispatch、但结果未持久提交：补 TOOL_SCHEDULER_OUTCOME_UNKNOWN，要求先核验外部状态，不能盲目重试；
• 仍以首个 scheduler failure 关闭本轮；
• drain 后不重新 dispatch，也不重复运行 finalize hook；
• 每个已记录调用最终都有按模型顺序写入、引用原 tool/call seq 的 tool/result。

验证结果：

packages/core/agent-loop/tests/tool-calls.spec.ts: 22 passed
pnpm run lint:contracts-ready: passed
verify-translation-pairing: 2 named pairs consistent
git diff --check: passed
doc-sync: 27/28 passed

doc-sync 唯一失败发生在 Windows 测试进程无权创建测试 symlink（EPERM: operation not permitted, symlink ...），不是本补丁的断言失败。补丁也包含中英文 README 与官方要求的 implemented Agent Note。

另外，为了在 core 修复合入前发现已污染/潜在污染会话，我发布了诊断与非破坏性恢复插件 dsh-session-integrity，它不会自动改写历史，也不会记录 prompt、tool 参数/结果或原始 session/call id：

• 插件展示：[Plugin] dsh-session-integrity: diagnose and safely continue poisoned sessions #3555
• 仓库：https://github.com/DON738110198/dsh-session-integrity
• release：https://github.com/DON738110198/dsh-session-integrity/releases/tag/v0.2.1

插件 v0.2.1 已用官方 rc.8 CLI 从打包产物安装到隔离 Web profile：Host 插件处于 active，boot manifest 能发现浏览器 bundle，服务端能返回注册 recovery action 的 client.js。它新增离线安全边界规划，以及历史 assistant 消息上的“从这里继续”：调用官方 Session fork、打开子会话、保留原会话不变，并在当前轮仍运行时拒绝操作。它仍不做原地回滚、硬删除、自动归档或工具盲重试。23 个测试、语法检查与 packed-tarball 安装检查均通过。