[bug] Subagent sessions orphaned by a force-killed harness restart shown as green — no interruption marker, indistinguishable from completed

[qyz7438]

Status: 子代理会话异常残留显示为绿色——harness 被强制终止后无法区分正常完成与异常残留

现象

DSH harness 曾被手动强制终止（并行运行约 18 个 agent 时出现死循环卡死，用户手动杀进程），随后重新启动。

重启后，GUI 中子代理目录里的部分子代理会话没有正常结束，却显示为绿色（done），与真正正常完成的会话视觉上完全无法区分。用户无法分辨"真正完成"与"异常残留（孤儿/仅存档）"。

• 当前有约 39 个子代理会话为 ready 态（定义为：仅存在于存储中、可续接、非终态、不是等待收集的结果），1 个 running。
• 这些由强制终止留下的孤儿会话，经重启加载后显示为绿色，像正常活跃/完成一样。

环境

• 仓库：deepseek-ai/deepseek-harness（id R_kgDOT3T1gw）
• HEAD：47f943859b（Merge pull request #2519 from deepseek-harness/feat/npm-public）
• 触发条件：进程被强制 kill（死循环卡死），非正常关闭。

根因链（三问三答）

1) 会话持久化是否记录"异常中断"标记？—— 记录，但只落在会话日志。

持久层在加载/准备一个"冷"（已存档）会话、且其最后一个 turn 未闭合时，会合成并持久提交 turn/end {kind: 'interrupted'}：

• packages/core/session/src/repair.ts:131 —— interruptedTurnClosers() push 出一个 { type: 'turn/end', …, data: { turn, reason: { kind: 'interrupted' } } }。
• packages/session/session-persistence/src/coordinator.ts:944-945 —— commitPrepared() 在存在 closers 时调用 backend.commitRepair(...) 将这组合成事件落盘。

所以强制 kill 后，孤儿子代理的会话日志里确实存在 turn/end {interrupted} 标记。

2) 重启/恢复时孤儿会话如何加载与显示？—— 加载成 inactive，interrupted 标记从不被读取。

• 重启后 ctx.sessions 为空，孤儿会话是"冷"候选，走 list-children.ts 的持久化折叠路径。
• packages/subagent/subagent/src/list-children.ts:376 / :408 —— 冷子代理一律 activity: 'inactive'；:274 live 才 'running'。
• childRow()（:412-435）只接收 activity: 'running' | 'inactive'，从不检查该子代理日志尾部的 turn/end {interrupted|aborted|completed}。
• SubagentListEntry 的 JSDoc（:49-55）明确：store snapshot activity "inactive means it exists only in persistence. Neither encodes a durable outcome"。

即：暴露给 GUI 的状态枚举只有 running/inactive（服务端）/ ready/idle/running（模型端 list_agents，tool-subagent-control/src/list-agents.ts:59-63），没有 interrupted/aborted/completed。孤儿会话的 interrupted 标记停在日志里，到不了状态枚举。

3) UI 颜色映射是否区分终态与孤儿态？—— 不区分；但同仓已有正确范例。

• 子代理目录映射：packages/client/ui-subagent/src/client/SubagentCatalogAction.tsx:348：

  <StateDot state={entry.activity === 'running' ? 'ongoing' : 'done'} />

  所有非 running（含孤儿/中断/失败残留）→ done（绿）。:202（加载占位）、:586（触发点）同理。
• 颜色令牌：packages/client/ui-primitives/src/StateDot.module.css — done→绿 :33-35，ongoing→蓝 :49-52，error→红 :41-43（目录中从未使用）。
• 对照：同一仓库的 workflow-run 面板已有完整终态/中断取色：
  • packages/client/ui-workflow-run/src/client/WorkflowRunPanel.tsx:33-43：running→ongoing、completed→done、failed→error、cancelled/interrupted→warning。
  • packages/client/ui-workflow-run/src/client/workflow-definition.ts:12：WorkflowRunStatus = 'running' | 'completed' | 'failed' | 'cancelled' | 'interrupted'，由 statusFromStopReason（:63）驱动。

即"中断/失败应有明显区分色"的基础设施已经存在，只是没有被接入子代理状态。

根因定级

1. SubagentListEntry.activity 只有 running/inactive，不含终态结局（list-children.ts:49-55、:274/376/408/412-435）——孤儿/中断/失败统一塌缩为 inactive。这是最底层成因（数据契约缺陷），现象上"重启后孤儿会话没有被打上任何中断标记"。
2. 子代理目录把一切非 running 渲染为绿色 done（SubagentCatalogAction.tsx:348）——孤儿与正常完成同色。
3. 中断标记存在但未上浮到状态枚举：持久层已持久 turn/end {interrupted}（repair.ts:131、coordinator.ts:944-945），但 list-children 从不读取它；客户端 manager.ts:930 又把任何 disengage 折叠为 inactive。

（三者是同一根因的三个层面：状态空间定义 → UI 取色分支 → 中断信息传播。与 workflow-run 面板的成熟行为形成直接反差。）

期望行为

• 正常完成 → 绿色 done（现状保留）。
• 运行中 → 蓝色 ongoing（现状保留）。
• 异常残留 / 中断 / 强制终止后孤儿 → 非绿色、明显区分：参考 workflow-run，interrupted/cancelled 用 amber warning 或独立灰色存档色；failed 用红 error。
• ready（仅存档、可续接、非终态）→ 灰色/存档色，不能与"完成"同色。
• 目录行正文也应标注结局（如"已中断 / 已完成 / 仅存档"），而不只是圆点颜色。

建议

1. 在数据层补一个可序列化的终态/结局字段：在 SubagentListEntry（或新增 subagent/outcome 类 projection）上暴露 running/idle/ready/completed/failed/interrupted，来源直接读子代理日志尾部的 turn/end（kind: completed/max-tokens/interrupted/aborted/error/disposed；可复用 sdkStopReason / subagent-dsh-sdk 的终态映射惯例）。
2. 前端取色改为枚举分支：SubagentCatalogAction.tsx:348（及 :202、:586）由二分 running/inactive 扩展为多态取色，把 error、warning 真正路由到 StateDot；与 WorkflowRunPanel.tsx:33-43 对齐为统一规则。
3. 中断/孤儿信息上浮：list-children.ts 的 childRow（:412-435）在冷折叠时读取事件尾部的 turn/end reason，把 interrupted 映射为可表达的状态；客户端 manager.ts:930 保留失败/中断通道，避免 disengage 即塌缩为 inactive。
4. 对应更新 ui-subagent/README.md:33（"The catalog has no durable outcome"已知限制）与组件级快照/单测，覆盖各结局颜色。

未确认项

• 仅静态源码分析与用户现象对照；未运行 pnpm run test:gui / 实机落盘复现（只读调研，不改动）。
• "孤儿会话是否会在强制 kill 后由后端启动时对每个冷会话触发 commitRepair（从而真正落盘 interrupted），还是仅在用户打开该会话时加载修复"——这一时序细节未在本次只读调查中逐一行验证（影响：重启后立刻展示时 interrupted 标记是否已经落盘并由 list-children 可见）。
• 希望采纳的 ready/孤儿视觉方案（灰 vs amber vs 独立徽标）由维护者/设计定夺。