Bug: 多步规划执行任务完成（对话结束），但主分支任务状态仍显示「执行中」

[xianyu-sheng]

环境

• DeepSeek Harness Web GUI (http://127.0.0.1:3080)
• 主分支（非子代理）执行多步规划任务

现象

用户在当前页面发起多步规划执行任务，任务执行过程中用户可以持续与 Agent 对话。

当 Agent 完成所有步骤、给出最终答案、对话自然结束时：

• 对话已结束（用户看到完整输出，Agent 停止响应）
• 但主分支任务状态仍在「执行中」，未自动转为「已完成」

期望行为

对话结束（Agent 输出最终答案且不再等待用户输入）应触发主分支任务状态的更新，将任务标记为「已完成」或「已结束」。

影响

• 用户无法从任务列表/状态栏直观判断任务是否真正结束
• 可能导致后续任务调度、资源回收等逻辑异常
• 与用户直觉不符：对话已结束，任务状态却仍在运行

补充

此问题不涉及子代理（subagent），是在主分支的普通多步规划执行中观察到的行为。

感谢反馈！

[argszero]

对着 master（47f943859b）把「任务状态」的完整链路追了一遍——正常情况下它必然会被清掉，所以「对话结束仍显示执行中」有三种可能，各自指向不同的修复点。先给链路，再给判别方法。

状态链路（源码确认，正常路径是通的）

1. host agent 必然回 idle：kick() 循环（core/agent-loop/src/agent.ts:212-221）while (await this.turn()) {} 退出后，finally 里 if (this.phase.kind === 'running') setPhase({kind:'idle'})——最终回答输出完、turn() 返回 falsy，agent 一定转 idle（除非 turn() 永不返回）。
2. 每个状态变化都发帧：api-proxy.ts:3561 ctx.on('agent/status', ...) → host/session-status { running: status === 'running' }。
3. 客户端收到帧就清：manager.ts:863-870 host/session-status → recordMutation + handleRunning(running) → 对话视图的运行指示（ChatView.tsx:156,403）消失。

三种可能（按你说的"对话自然结束"来筛）

A. 客户端漏帧——已实例化会话的 running 位只有帧能改（这是我查到的最具体缺口）
对话视图的 running 位只由 host/session-status 帧驱动。get()（manager.ts:270-300）只在新实例化时从 list 快照同步 running；mux 重连基线 subscribeSession（api-proxy.ts:480-482）只重放 session/subscribed，不重放 status。所以：如果那条 running:false 帧在客户端短暂离线/重连窗口里丢了，已打开会话的对话视图会一直显示执行中，直到下一次状态变化；列表行却是对的（list 刷新带权威 running）。判别：刷新页面（重新打开会话）后是否恢复？ 恢复 → 就是这个（新实例化会从 summary 同步）。修复点明确：每次 list 刷新/重连基线把权威 running 回写到已实例化会话。

B. host agent 真卡在 running（已知家族 #466/#1363）
如果 turn() 里有东西永不返回（#1607 的 cordis_inspect_query 无超时挂起就是典型——pending 工具永不 resolve，turn 永不结束），agent 不会出最终答案。你描述的"已给出完整输出"不太符合——但如果你观察到的"执行中"其实发生在最后一轮输出后、某次后台继续，这条要查 agent 状态。判别：刷新后列表行是否仍显示运行中？ 仍显示 → 是这条（agent 真 running），需要走 #466 家族的诊断（pending 工具/未闭合轮）。

C. 你看到的是 GoalBar（对话头部目标任务栏），不是运行指示
如果"任务状态"是头部那个目标任务栏（ui-goal GoalBar）：goal 的 phase 只有显式 goal_update complete 才会转 complete（goal/src/index.ts:331-343；工具描述明确 "Mark complete only when the objective is actually achieved"）——对话自然结束不会自动 complete 它，active 阶段标签（执行中）会一直挂着。这是设计使然，但确实是 UX 缺口：判别：刷新后是否仍在？ 在 → 这条（goal 状态持久化，刷新不清）。

请补充一个关键信息

「执行中」具体是哪个元素：① 最后一条消息下方的运行指示、② 对话头部目标任务栏（GoalBar）、③ 侧边栏会话列表行的状态？以及刷新页面后是否消失？

• ① + 刷新消失 → 机制 A（客户端漏帧，修复点如上）；
• ③ + 刷新仍在 → 机制 B（host 卡 running）；
• ② → 机制 C（goal 未 complete，可建议：轮次 wrapup 报 complete 时自动 complete，或在 UI 给"标记完成"入口——后者配合 goal_update 现有语义）。

[xianyu-sheng]

@argszero 感谢详细分析！
我补充关键信息：

1. 「执行中」具体是：对话头部目标任务栏（GoalBar）——那个显示"多步规划执行 / 问题1: status_bar 吞异常"且带进度指示的区域。侧边栏会话列表行的状态也是"执行中"。

2. 刷新页面后仍在，列表行和头部任务栏都保持"执行中"状态。

3. 确认是主分支（非子代理）发起的多步规划任务。任务规划是：

   • 问题1: status_bar 吞异常
   • 问题2: memory locking release 吞异常
   • 问题3: repl_input 异常处理
     对话自然结束时，Agent 已完成所有步骤并给出最终答案，但 GoalBar 的 active 阶段仍停留在"问题1"，未推进到完成。

4. 关于 A/B/C 三种可能：

   • 如果是 A（客户端漏帧），刷新后应恢复，但实际刷新后仍在
   • 如果是 B（host agent 卡 running），列表行应显示运行中——列表行确实显示运行中
   • 如果是 C（goal 未 complete），刷新后仍在——这与我观察到的完全一致

[argszero]

@xianyu-sheng 你的判别信息 + @yun520-1 的三状态视角合起来，现在可以收敛了——你观察到的其实是两个独立问题叠加，各自有确凿的源码归属：

列表行"执行中" = host agent 真的还卡在 running（机制 B，你的判别已指向它）

列表行的 running 位不是持久化字段，也不是 goal 派生——它是 list 时从 live agent 实时算的：summarize(session, agent?.status === 'running')（api-proxy.ts:1735，agent?.status 来自 agent.ts:99-100：phase.kind === 'idle' ? 'idle' : 'running'）。冷会话（不在内存）一律 running: false（:1740）。

所以刷新后列表行仍"执行中" = 这个 agent 的 phase 还挂在 running 态——不是客户端缓存、不是漏帧。这直接命中机制 B：kick()（agent.ts:212-221）的 while (await this.turn()) {} 没有退出，即有一轮 turn 没返回。你看到"对话已自然结束"（模型输出完），但 agent 的 phase 没归 idle——最常见的来源就是有一个 pending 的工具调用永不 resolve（#1607 的 cordis_inspect_query 无超时挂起、#466/#1363 家族同款），turn 等它，模型侧已经无话可说但循环没结束。@yun520-1 的"完成判定必须在生成循环之外"完全正确——而且这里正是生成循环本身没退出。

判别确认：在 host 进程里查一下有没有未 resolve 的 pending 调用（日志里最后一次 tool/call 之后没有对应的 tool/result）；或直接看 dsh web 进程的 CPU/堆（真卡 running 的 agent 通常还有活跃的等待）。如果有一个悬空 tool/call，这就是 #466 家族的又一个实例，修复方向与 #1607 相同（超时/fail-fast）。

GoalBar"执行中" = goal 未 complete（机制 C，独立于上面的 B）

GoalBar 显示的是 goal 投影（ui-goal GoalBar.tsx），phase: 'active' 的标签就是"执行中"。goal 只有显式 goal_update complete 才会转 complete（tool-goal/src/index.ts:308 是全仓库唯一调用 ctx.goals.complete 的地方——driver 没有任何自动 complete 路径）。你看到的"问题1"是 objective 文本（goal 域只有 roundsStarted 计数，没有 step 指针——domain.ts:29），停在"问题1"是因为目标从一开始就是"多步规划执行/问题1…"整段 objective，从未被标记完成。

即使 agent 正常归 idle，goal 也不会自动 complete——这是设计使然（工具描述明示 "Mark complete only when the objective is actually achieved"），但对"多步规划"这种用完即弃的目标确实是 UX 缺口：模型答完不会记得调 goal_update，用户也没处点"标记完成"。

结论与修复方向（分开治）

• B（列表行）：查悬空 tool/call → 走 cordis_inspect_query client-platform queries hang forever when no page responds, freezing the agent #1607 的 timeout/fail-fast 方向（或 [Bug Report] 宿主被沙箱内 agent 重启杀死后，会话日志留下未闭合的 turn——冷启动无协调闭合，会话永久"运行中" #466 家族的 write-behind/恢复修复）。
• C（GoalBar）：两个可选方向——① driver 在「模型明确交付最终答案且不再驱动新轮次」时自动 complete（需要定义"最终答案"的可信信号，避免误 complete 真实未完成目标）；② 更稳妥：UI 给一个"标记完成"入口（调用现有 goal_update complete 语义）。② 对产品侵入最小，① 要小心自动判定。

@yun520-1 的"三个独立状态源分开追"判断完全正确——这次恰好是两个状态源都指向了真实问题：agent phase 卡 running（B）+ goal 未 complete（C）。

[Sutera-Diffusus]

argszero 和 yun520-1 的分析很透彻。补一个判别旁证:装一个任务完成 OS 弹窗(我们 dsh-windows-notify)——若完成时弹窗正常触发,说明后端完成事件发了,卡的是 UI 状态机(B/C 场景);若弹窗也没触发,则是后端事件源头的问题。用「事件到了哪一层」来定位,比肉眼看 UI 快。仓库:https://github.com/Sutera-Diffusus/dsh-windows-notify