后台子代理完整汇报晚于最终答复送达，导致最终答复后出现一串追加确认回合

[Zn070515]

背景

后台子代理完整汇报（subagent-report relay）晚于主 agent 的最终答复送达。主 agent 在收到全部 subagent-settled 通知后即交付最终答复，随后每个迟到的完整汇报 relay 触发一个确认回合，最终答复之后出现一连串追加回复，会话阅读混乱。

复现

1. 用 subagent 工具以 run_in_background: true 派多个子代理做深读任务
2. 主 agent 在收到全部 subagent-settled 通知后直接写最终答复，不显式调用 tool-subagent-report 收齐汇报
3. 等待各子代理汇报正文以 subagent-report relay 异步送达

实际结果

主 agent 在 turn 1 交付最终汇报后，turn 2–7 各收到一条 subagent-report relay（基础设施 / 数据身份 / 能力族 B / 能力族 A / 外部接口 / 文档），每条都唤醒主 agent 生成一条「收到…完整汇报」确认回合，六条追加回复排在交付物之后。会话 session-4cae51a3-0455-4f16-b503-e32befbb232f 完整可回放。

期望（建议方向，满足其一）

• (a) 主 agent 交付最终答复前能感知「完整汇报仍在途」并须先收齐
• (b) loop 识别「父 agent 已交付最终答复」，将迟到的 relay 合并为单条非交互通知，不再逐条生成确认回合

环境

dsh 0.1.0-rc（源码 pnpm dsh web），deepseek-v4-flash via deepseek-official，Windows 11。

[C-git-qok]

补充一个同场景的真实案例（2026-08-14，deepseek-v4-flash via deepseek-official，主 agent + 4 个后台子代理四域并行审计）。除帖内已述的「追加确认回合」外，新增 4 个观察：

1. 即使主 agent 已正确收齐，迟到的 relay 仍渲染为「最终答复之后的顶级消息」——人类读者无法区分「重复通知」与「未汇入的新结果」
本案例主 agent 在输出最终汇总报告前已等到全部子代理完成（手动 sleep + list_agents 轮询），汇总包含全部 4 个域的结果。但最终答复渲染后，2 条 subagent 完成通知仍作为顶级消息出现在对话流中。用户因此质疑「汇总是否漏掉了子代理结果」——实际无遗漏，但没有任何机制让读者验证。建议：迟到的 relay 渲染为折叠/次级区块并标注「arrived after final answer」；或主 agent 答复附带「N/N subagents settled」徽标。

2. 工具层缺「阻塞等待全部子代理结算」的原语——收尾靠碰运气
job_output(wait: true) 仅适用于 bash job；子代理只有 list_agents（状态快照，无阻塞等待）。主 agent 要收齐结果只能手动轮询或 sleep——本案例向未完成子代理发 send_message 要求收尾 + sleep 才等到，纯属运气；若直接输出最终答复，汇总将真实缺失一个域的结果且无任何警告。建议：提供 wait_for_subagents() 类原语，或让 settled 通知可被显式 await。

3. 「已收齐后的重复送达」与「未收齐」是两回事
帖内 (b) 期望聚焦「未收齐时的追加确认回合」；本案例证明：即使主 agent 已收齐（结果已并入最终答复），relay 通知仍会在最终答复后到达并渲染——需要 relay 去重或「已消费通知不渲染」机制。

4. 差点发生的真实遗漏（机制必要性证据）
4 个子代理中第 4 个（UI 域）在最终答复前仍在运行——若主 agent 未手动等待，最终汇总将缺 UI 域 12 项发现且用户无从察觉。这是帖内期望 (a)「交付前感知完整汇报仍在途」的必要性实证。

补充建议（在 a/b 之外）：
(c) 最终答复附带子代理结算状态徽标（N/N settled + 迟到标记）
(d) relay 通知在父 agent 已交付最终答复后合并为单条非交互通知（同 (b)，但补「已消费去重」）

[weijiafu14]

你给的两个方向里，(a) 今天有机制、(b) 没有——但我认为 (b) 才是对的修法，先把话说全。

(a)「交付前先收齐」有机制，但那是模型纪律不是 loop 保证

@tintinweb/pi-subagents（经 pi2dsh 装）提供的 get_subagent_result 带一个 wait: true：父代理的这次工具调用会阻塞到子代理真正结束，结果作为正常的工具结果回来，而不是靠 settle 通知 + 事后 relay 两条路各走各的。用它编排的话，父代理在交付最终答复之前就已经拿到全部正文了，你描述的"六条追加确认回合"从形状上不会出现。

这条我在真 DSH loop 上端到端跑过（干净 DSH_HOME、stock CLI、stock 包、真模型，断言是坏掉就会失败的那种）。

但必须说清它的性质：这是给模型一个能等的工具，不是让 loop 强制它等。模型仍然可以选择不调 get_subagent_result 就直接写最终答复——那时候你还是会遇到同类问题。你原帖 (a) 的措辞是"须先收齐"，那个"须"字我给不了。

(b)「loop 识别父代理已交付、把迟到 relay 合并成单条非交互通知」——这个我们做不了，而且它更好

这是投递调度层的事，在 DSH 自己的 agent loop 里，外部插件够不着。

而且我觉得 (b) 比 (a) 更该做：(a) 依赖模型每次都记得先收齐，(b) 是结构性的。你这个场景（并行深读、每个子代理正文都很长）恰恰是模型最容易"觉得 settled 通知够用了"的场景。@C-git-qok 补的那个四域并行审计案例是同一形状的第二份证据。

顺带：#2192 报的是同一投递体系的另一面——settle notice 与 report relay 内容相同但走两条路、顺序反转、零去重。你这条和那条合起来看，问题不只是"晚到"，是两条投递路径本来就没有统一的调度与去重。建议维护者一起看。

边界

我们不修 DSH 的子代理投递链路。上面 (a) 是并排的另一套子代理运行时，换它是个不小的动作——如果你只是偶尔遇到，等 (b) 被官方接可能更划算。

利益相关：我维护 pi2dsh，@tintinweb/pi-subagents 不是我的包。