[Bug] TOOL_OUTCOME_UNKNOWN / TOOL_NOT_STARTED 合成结果缺少恢复语义：用户与模型都误判为真实工具失败（0.1.5-rc.1）

[buddha68]

崩溃恢复合成的工具结果缺少「恢复」语义：用户与模型都误判为真实工具失败

环境

• dsh 0.1.5-rc.1（npm 全局安装，Windows 11）
• 会话形态：Web UI 会话 + ACP / headless 引擎会话
• 本机会话库：~/.dsh/sessions/，共 1212 个会话文件

一、现象

引擎在工具执行期间非正常退出后，用户下次打开该会话，时间线里会出现「工具调用被中断」的失败卡片：

The tool call was interrupted after it was recorded, but no result was durably recorded. Its outcome is unknown. Decide whether to retry from the tool semantics: retry only if the operation is read-only or idempotent; if it may have side effects, first verify external state or ask the user. Do not retry blindly.

The tool call was interrupted before the Harness recorded it as started. Retry it if it is still needed.

用户没有点过停止，也没有网络异常。卡片与普通工具失败长得一样，于是被理解成「工具坏了」。

本机实证：同一用户在 3 小时内两次把这些卡片原样复制出来追问原因（13:14 一次、13:55 一次），第二次甚至直接当成 Harness 的缺陷上报。界面上没有任何「引擎曾异常退出」的信号，用户无从判断该查什么。

二、机制（一手读码，非猜测）

出处：@deepseek-ai/dsh-session/lib/types/repair.js。模块注释原文：

Crash-recovery repair for an interrupted session log. It preserves a fully written final turn and supplies the missing tool, step, and turn boundaries needed to resume with a provider-valid transcript.

interruptedTurnClosers() 在加载崩溃遗留日志时合成收尾事件：

情况	合成文本	error 字段
已持久 tool/call、无结果	TOOL_OUTCOME_UNKNOWN 文案	{name:"ToolOutcomeUnknownError", code:"TOOL_OUTCOME_UNKNOWN"}
assistant 请求了工具、但 tool/call 未落盘	TOOL_NOT_STARTED 文案	{name:"ToolNotStartedError", code:"TOOL_NOT_STARTED"}

关键实现细节（repair.js:78-82）：

// The last real event supplies the seq base and the timestamp for the
// synthetic closers (reusing the last timestamp keeps them deterministic and
// never invents a "future" time).
let seq = last.seq + 1;
const time = last.time;

即：合成结果的时间戳 = 崩溃前最后一个真实事件的时间，而不是恢复发生的时间；并且合成结果走 tool/result + isError: true 的同一条渲染路径。

README.zh.md:152 印证了这两段文案，但未提及时间戳语义。

三、影响

1. 用户把「引擎崩溃」读成「工具失败」

墓碑在事件层与真实工具结果同形（tool/result、isError: true）。用户看到「网页搜索 / 查看 失败」，第一反应是工具或网络出问题——而真正需要知道的是「Harness 刚才异常退出了，该查它为什么退出」。

2. 模型按「重试」处理，但真问题不是重试能解决的

墓碑文本本身在引导模型「判断要不要重试」；而实际需要的是「引擎崩过」。两条处置路径完全不同，按前者走还会把崩溃本身掩盖掉。

3. 时间戳是假的，排查会被带偏

本机实例（会话 7ec895fd-634c-4d9f-9251-647ae4dc6719，cwd F:\agenttalk-core）：

seq	事件	时间
35	tool/call（pwsh）	12:23:47
36	合成 tool/result（TOOL_OUTCOME_UNKNOWN）	12:23:47（复用）
37	合成 step/end	12:23:47（复用）
38	合成 turn/end {reason:{kind:"interrupted"}}	12:23:47（复用）
39	session/end-seed（真实恢复时刻）	12:27:29

按墓碑时间会得出「工具刚被记录就同一毫秒被杀」的结论；实际恢复发生在 3 分 42 秒之后。本机第一次排查确实被这个时间戳带偏过。

4. 规模

本机 1212 个会话文件中，21 个会话含此类合成墓碑、共 31 个事件（2026-08-15 ~ 2026-09-10）。不是冷路径。

四、建议（供参考）

1. UI 层区分：合成墓碑与真实工具结果做视觉区分，并给一句显式提示，例如「该会话曾在工具执行期间中断，以下结果为崩溃恢复合成」。
2. 文本带上恢复语义：在保持 provider-valid 的前提下，把「崩溃恢复」写进合成文本，让模型与用户都能区分「运行时中断」与「事后考古」。
3. 结构化暴露：把 error.code（或新增 recovered / cause 标记）透出给 UI 与插件，便于宿主自定义呈现。
4. 文档补一句：恢复章节注明「合成事件的时间戳取自最后一条真实事件，不代表中断时刻」。

补充：崩溃恢复机制本身是正确且必要的（这次恢复也让会话能继续使用）——本条只反馈呈现层缺少「这是恢复合成」的信号这一点。

[buddha68]

补充一组本机分布数据，用于缩小范围（同一批 1212 个会话文件，按 cwd 项目分组）：

项目（cwd）	会话数	含墓碑会话	墓碑率
ACP 引擎工作区（acp-server/workspace）	58	4	6.9%
ACP 网关驱动的项目（agenttalk-core）	36	3	8.3%
无人值守班次工作区（workbench）	53	3	5.7%
日常交互工作区（dsh-work）	604	5	0.8%
其余 9 个项目	47	0	0%

即：由外部程序驱动的会话（ACP / 无人值守）墓碑率约 6–8%，日常交互会话 0.8%，相差约 6–10 倍。

另一个更精确的模式：墓碑只出现在「需要等待」的工具上。全部 31 个墓碑对应的工具：

工具	墓碑数
pwsh（长命令）	12
subagent_*（等子代理）	9
mcp__argo__argo_fetch（等网络）	4
job_output（等后台任务）	3
ask_user_question（等人回答）	2

反例（同一次并行调用内的对照）：某会话一次 assistant 同时发起 argo_fetch + read ×3，3 个 read 正常返回，只有等待网络的 argo_fetch 变成墓碑。

结论：进程在等待时被终止，正在等待的那个工具留下墓碑，瞬时完成的工具不受影响。也就是说，墓碑与「外部终止进程」强相关（在 ACP / 网关场景下尤其频繁），不是工具自身失败——正因如此，把它呈现为普通「工具失败」的代价更大：使用者会去查工具和网络，而真正该查的是「谁终止了引擎进程」。

[argszero]

我把这条链路从 repair 一路读到 client，三个源级确认，外加一个作者没提到的、能一次闭合「建议 1 + 建议 3」的落点。

一、机制确认，补两个边界

1. packages/core/session/src/repair.ts:29 interruptedTurnClosers() 确实与真实结果同形（tool/result + isError: true），判别符在 :119-121。

2. 时间戳复用最后一条真实事件（repair.ts:84-88）是刻意的，不是省事。注释那句 deterministic 背后有一条硬约束：session-format-v0-to-v1/src/relationships.ts:383-401 的 isExactToolNotStartedRepair() 会把 message.id === interrupted-tool-result-${callId}-${event.seq} 当作逐字段精确判别式（v2→v3 的 payload.ts:87 isRepairIdentity 是同一套 id 前缀规则）。合成 id 必须由当时的 seq 决定，换任何时间戳都会让旧日志再也认不出自己的墓碑。

   → 所以「让 time 说实话」这条路不可行，但「让恢复时刻可读」完全可行（见第四节）。

3. 有两条路径，行为不同，排查时要分开：agent-loop resume 会落盘（packages/core/agent-loop/src/index.ts:891-892 handle.append(closers)），而 cold read 只内存合成、不写回（packages/session-query/session-query/src/cold-read.ts:16 原文 "nothing is written back"，:55）。你库里 31 个事件里，有一部分可能只在 UI 打开时存在过、日志里并没有。

二、建议 2 的真实成本（比「改文案」重）

现在被逐字符锁死的不只是 id：

relationships.ts:393-400 要求同时满足 error.name === 'ToolNotStartedError'、code === 'TOOL_NOT_STARTED'、sourceEventSeqs === undefined、id 精确匹配、以及 repairContent[0].text === 'The tool call was interrupted before the Harness recorded it as started. Retry it if it is still needed.'。

也就是说这句文案是会话格式迁移判别契约的一部分，不是一个可以随手润色的字符串 —— 改它必须连带出一个新 format 世代。（顺带修正一处细节：TOOL_OUTCOME_UNKNOWN 那条在 repair.ts:124 带 sourceEventSeqs: [callSeq]，TOOL_NOT_STARTED 那条明确不带 —— 这正是上面那条精确判别式的另一半。）

三、作者漏掉的：判别符早就在了，只是没人消费

packages/core/session/src/types.ts:200-222 的 TurnEndReasonMap 已经有 interrupted: { kind: 'interrupted' }，JSDoc 原文就写着 "A crash-orphaned turn was closed after the fact"。repair 也确实在 repair.ts:133 把它写进了 turn/end。

问题是没有任何呈现层消费它。我 grep 了整个 packages：只有 core/agent、session-query、acp、subagent 这类非呈现路径读这个 reason；client 侧三个 turn/end 派发点 —— turn-error.ts:32 认 error、turn-max-tokens.ts:42 认 max-tokens、turn-tail.ts:141 只认 error —— 一个都不认 interrupted。

而没有 turn/start 的孤儿工具调用，client 会合成 { name: 'Interrupted', code: 'interrupted' }（packages/client/ui-chat/src/client/conversation-nodes/tool.ts:201），下游 ui-tool（tool-call-model.ts:225）、ui-deliverables（PresentRow.tsx:30）、ui-cordis（card-model.ts:81）都会把它渲染成 "stopped" 而不是 "error"。

即：「这是被中断，不是失败」这个信号在客户端早就存在、已有三个渲染器认它，只有崩溃恢复这一支没接上。

→ 因此建议 1 与建议 3 是同一件事：把它做成一条沿节点传播的中断标记，而不是往合成文本里塞说明。你建议里那句「（或新增 recovered / cause 标记）透出给 UI 与插件」是成本最低、且与现有设计一致的一条。

四、字段级落点

• repair 已经在 tool/result 上写了 error.code，不需要新字段就能判别；真正的缺口是它没进入 chat 节点的投影。

• ConversationNodeDefinition 的回调只能拿到自己的 Context（start match / matches / location / state），拿不到同 turn 内另一个节点的投影结果 —— 所以「工具行自己去看这一 turn 是否 interrupted」在插件面走不通。

• 但能力在引擎里：ConversationNodeContext.start.location 是 { kind: 'turn', turn: TurnLocation }，而 TurnLocation（packages/client/ui-conversation/src/client/contract/conversation.ts:92-100）带着 end: SessionEvent<'turn/end'>。「这一 turn 的 end reason 是不是 interrupted」在装配层是已知量，只是没成为节点输出的一部分。

• 于是核心改动很小：tool.ts 里 projectBlock() 本来就有 interruptedAt 形参（:168-206），让它在中断场景把 error 写成 { name: 'Interrupted', code: 'interrupted' }，就与既有的 "stopped" 链路自动接上；turn/end 的 reason 为 interrupted 时再补一条 turn 级提示节点（turn-error.ts 是现成模板）。

五、一条对排查有用的推论

因为 cold read 不落盘，判断「这个会话曾被恢复过」的唯一可靠依据是日志里有没有那条合成的 turn/end {kind:'interrupted'}，而不是有没有 TOOL_* 结果 —— 后者在只读浏览过的会话里根本不存在。这又落回同一处：那个 reason 变体是所有分支唯一的共同锚点，用它比用 error.code 更稳。

如果你需要，我可以把本机含墓碑的会话按「有落盘 closer / 只有 cold-read 合成」分成两类取个比例，用来看这个改动的收益面。

[buddha68]

再补一条同一段文案的第二条产生路径：读取路径也会凭空合成这段文本——而此时根本没有任何中断。

一、现象（本机实证）

2026-09-10 19:38 一个由外部程序（ACP 引擎，经网关投递）驱动的回合，在 Web GUI 里被显示为「工具调用失败」：

The tool call was interrupted after it was recorded, but no result was durably recorded. Its outcome is unknown. …

但该回合在磁盘上完整跑完，全程无异常：

时间	事件	内容
19:38:15	tool/call	pwsh Start-Sleep -Seconds 330
19:43:47	tool/result	isError:false，(no output)
19:43:49	assistant/message	正常产出文本
19:43:49	turn/end	{kind:"completed"}

按该次调用的唯一 callId 扫描本机全部 1232 个会话文件（含备份）：只有「tool/call + 成功结果」两处，不存在任何墓碑。

二、机制（一手读码）

@deepseek-ai/dsh-session-query/lib/index.js：

• readColdSessionLog()（第 33 行）→ 第 51 行：events: [...events, ...interruptedTurnClosers(events)]
• SessionObservationReader.read()（第 346–393 行）判「会话是否活着」只看本进程注册表：const live = this.ctx.sessions.get(sessionId)（第 350 行）

因此：由其他进程持有的会话，对本进程一律是「冷日志」。读到「已有 tool/call、尚无 tool/result」（＝回合正在执行）时，读取方把它当成崩溃现场，当场合成墓碑；README.zh.md:107 原文：「写入者在轮次中途崩溃的冷日志用 interruptedTurnClosers 在内存中补齐 —— 读取从不修改持久化」。Web GUI 的会话读取走的正是这条路径（dsh-api-session-controller/lib/types/history.js:272 sourceFor() → ctx.sessionQuery.observeSession()）。

三、本机复现（与 GUI 显示逐字一致）

把该会话截到「tool/call 已落盘、tool/result 未落盘」的瞬间，喂给 interruptedTurnClosers()，输出 3 条合成事件（tool/result + step/end + turn/end {interrupted}），其中失败文本与 GUI 显示逐字相同，且时间戳复用最后一条真实事件（19:38:15）；喂完整日志 → 输出 0 条。

四、影响（比原报告更重）

1. 无辜：健康、正在执行的回合被显示成「工具失败」，使用者会立刻去查工具、网络、权限——全都不是问题所在；
2. 不可分辨：与落盘墓碑的文案、事件形状完全相同，仅凭界面无法区分「真的崩过」与「只是还在跑」；
3. 时序误导：合成事件复用最后一条真实事件的时间戳，界面看不出「这是读取时补的」。

五、判别口径（本机现用，供参考）

• 真墓碑：落盘（重启后仍在），其后必有一次恢复痕迹（session/end-seed 或后续新回合）；
• 只读配平：不落盘，刷新即消失，其后无任何恢复痕迹。

六、建议

1. 冷读配平宜只在能确认写入者已不在时启用（写句柄租约/锁失效、或显式的「非活跃」标记）；读取方拿不到该信息时，宁可不补墓碑，只做「回合尚未闭合」的中性呈现；
2. 若必须补：给合成事件加可辨识标记（如 recovered: true，或把 error.code 透出），并在 UI 上与真实失败区分；
3. 文档补一句：「只读观察方也会在内存中补齐 closer，其出现不代表发生过崩溃」。