goal 模式：子 agent 未完成最终产物核验时，主 agent 提前宣布 complete

[whyself]

goal 模式：子 agent 未完成最终产物核验时，主 agent 提前宣布 complete

问题描述

在 goal 模式下，主 agent 会派发后台子 agent（如独立核验 reviewer）对最终产物进行核验。但子 agent 尚在运行、核验结论尚未返回时，主 agent 就可以调用 update_goal（action=complete）将 goal 标记为已完成。goal 进入 complete 阶段后自动续跑立即停止，子 agent 的核验结果（可能包含发现的问题）永远不会被主 agent 处理。

复现步骤

1. 以某个需要产物核验的长期任务创建 goal（例如「构建 X 并由独立子 agent 核验」）。
2. 主 agent 以 run_in_background 方式派发一个子 agent 执行最终产物核验。
3. 子 agent 仍在运行（running）、尚未返回核验结论时，主 agent 在本轮调用 update_goal（action=complete）。
4. 工具调用成功，goal 进入 complete；后续子 agent 返回的核验结果不再被消费。

实际行为

• 主 agent 在子 agent 核验未完成时即可宣布 goal 完成，核验结论被丢弃，甚至可能掩盖子 agent 发现的问题。

期望行为

• 存在尚未返回的派生子 agent（或主 agent 尚未读取其核验结果）时，goal 不应被标记为 complete；应等待子 agent settle 并纳入其结论后再完成，或直接拒绝该次 complete 并提示模型先收集子 agent 结果。

根因分析（基于 master 分支源码）

1. completionAuthority()（packages/goal/tool-goal/src/authority.ts）对 complete 的权限校验只检查「当前 turn 含直接人类输入」或「当前 turn 恰为当前 goal 的 round」，完全不检查该主 agent 派生树中是否仍有 running 的子 agent。
2. readyToDrive()（packages/goal/goal-round-driver/src/index.ts）只依据主 agent 自身 status === 'idle' 驱动下一轮，与子 agent 运行状态无关：主 agent 派发后台子 agent 后自身 idle，即可进入下一轮并宣布 complete。
3. complete 成功后 renderWrapupContext()（packages/goal/tool-goal/src/wrapup.ts）注入「Do not call any more tools in this run」的收尾指令，且 goal-round-driver 因 phase 不再是 active 而停止驱动——此后子 agent 返回的核验结果没有任何消费方。
4. goal round 提示（packages/goal/goal-round-driver/src/prompt.ts）仅以自然语言要求「Before claiming completion, gather evidence」，没有任何等待子 agent 的硬性约束，模型容易在核验进行中提前宣布完成。

建议修复方向

1. 机制护栏（推荐）：在 update_goal 的 complete 路径（completionAuthority 或 GoalService.complete）中检查 agent 注册表里该主 agent 的派生子 agent；若存在 running 子 agent，拒绝 complete 并返回结构化错误（如 GOAL_SUBAGENT_PENDING），提示模型先等待/收集子 agent 结果后再 complete。
2. 提示层兜底：在 renderGoalRoundPrompt 中显式增加规则——若已派发核验子 agent，必须收到其结果后才能 claim completion。
3. 或为 complete 增加「等待 pending 子 agent settle」的语义（类似 job 机制），settle 后再判定。

环境信息

• 包版本：@deepseek-ai/dsh 0.1.0-rc.6（npm 安装，Web GUI）
• 仓库分支：master

[whyself]

提示词：

/goal 绘制15种不同风格的网页前端，主题你自己定

现象：

子agent进入代码审查阶段，主agent宣布任务已完成

对话记录：

dsh-session-session-ed0e3ea9-cbdd-45d2-96a5-d34a02baa513.zip

[whyself]

补充：已在实际 session 日志中完整复现该问题，附时间线证据。

场景：goal 目标「绘制15种不同风格的网页前端」（maxGoalRounds=256）。主 agent 并行派发 3 个后台子 agent（A/B/C 组），各自编写并核对 5 个风格页面，主 agent 另写 validate.cjs 做统一验证。

时间线（2026-08-13，本地时间）：

时刻	事件
23:00:30	主 agent 派发 3 个后台子 agent（A/B/C 组）
23:06:33	C 组报告并 settle（complete 之前，被正常处理）
23:08:54.277	主 agent 调用 update_goal(action=complete)，goal 进入 complete 阶段（roundsStarted=16）
23:08:54.303	<goal_complete> 收尾指令注入
23:09:39.482	B 组的核对报告才到达主 agent（complete 后 +45.2 秒）
23:10:15.372	B 组 settle 通知到达（complete 后 +81.1 秒）
23:11:36 / 23:12:21	A 组仍在运行（仍有新 step 与推理输出），且 A 组的报告从未被主 agent 接收

主 agent 在 complete 后收到 B 组延迟报告时的 reasoning 原话：

任务已经在上一轮标记 complete。这只是背景通知，我简短确认即可，不需要调用工具。

结论：complete 时刻（23:08:54）仍有两个子 agent（A/B 组）未完成最终核对与报告，completionAuthority 未做任何拦截，complete 成功；随后 B 组的核对结论在 complete 后 45~81 秒才到达，主 agent 因 <goal_complete> 的「不再调用工具」指令放弃进一步处理，A 组报告则完全未被消费。与报告描述一致，机制性护栏缺失得到实际复现。

补充建议：除「complete 前存在 running 子 agent 时拒绝/等待」外，goal_complete 收尾阶段也应考虑对 complete 之后才到达的子 agent 报告做一次消费（或至少提示存在未处理的核验结论），否则即使加了前置拦截，子 agent 在 complete 提交后、收尾前的竞态窗口内返回的结论仍会被丢弃。

[1052326311]

我按这里的真实 session 时间线做了一个可安装的 userland guard，专门拦 update_goal(action=complete)，不接管 subagent 调度。\n\ndsh-goal-quiescence 会记录当前 active goal 下公开的 subagent/start / subagent/end 生命周期：\n\n- 仍有 running run 时拒绝 complete；\n- run settle 后仍拒绝 complete，直到父 agent 调用 goal_quiescence_ack(runId)；\n- ack 工具会把保存的终态 assistant 输出作为自身 tool result 返回给父 agent 上下文，避免“结果已到但未纳入证据”的情况。\n\n集成测试使用真实 ToolRuntime、GoalService、SubagentRuntime 和 lifecycle scope，依次验证 running 拒绝、settled-but-unacknowledged 拒绝、终态输出实际出现在 ack 的模型可见 content、确认后同一 goal revision 才能 complete。发布制品已在干净 DSH_HOME 用 dsh plugin --profile web add 安装，并启动 Web profile 到 HTTP 200。\n\n边界也写明了：这是一层进程内、工具调用路径的 policy，不声称跨重启、直接 service 调用或 start/complete 极窄竞态的原子保证；若要完全原子，仍需要 core 提供生命周期 permit。希望它至少能先覆盖这个报告里实际发生的主路径，也欢迎用你附的 session 复测。