Agent Teams 下用 subagent 并行委派缺少 join 原语：主模型在子代理返回前就下结论，之后再补充和更正

[CuFe-hust]

环境

• DSH Desktop 0.2.0-rc.2（macOS arm64，构建于 2026-09-29）；本机另装有 dsh CLI 0.1.5-rc.2
• profile：web/desktop，已启用 @deepseek-ai/dsh-experimental-agent-team-profile（Agent Teams）
• 模型：deepseek-flash，reasoning effort max
• 会话记录：~/.dsh/sessions/<workspace>/<session-id>/session.v4.jsonl.zstd（session format v4）

一、摘要

在启用 Agent Teams profile 的会话里，如果模型用 subagent（而不是 spawn_teammate）做并行委派，它没有任何办法等待这些子代理：wait_agent 立刻返回 noProgress / no-active-peer，list_agents 看不到它们，send_message 也联系不上。

于是主模型只能结束当前 turn，给出一个看起来已经完成的结论；随后每个子代理的 settle notice 各自开启一个新的 turn，逐条产出「补充」，有时是「更正」。用户看到的就是：先给结论 → 再补充 → 再更正。

本机 191 份会话记录里，10 个会话用过子代理/队友；其中 3 个会话出现「仍有后台子代理在跑，主模型已给出 ≥1.9k 字符的结论」，2 个会话随后明确更正了先前的结论（其中一次的原话是「我上一轮给你的总结里有一个结论是错的，必须收回」）。

与 #7642 / #7087 相关但不重复：那两条讲的是子代理对 Team 工具不可见；这条讲的是由此产生的回答时序与结论质量问题。

二、Lead 拿到后台子代理时发生什么

同一步里发起 3 个 subagent 调用（没有传 run_in_background 参数），每个都立刻返回：

tool/call   subagent {"description": "...", "prompt": "..."}   ×3   @16:03:54
tool/result        "started subagent a5d000a5-…"               @16:03:54
tool/result        "started subagent 68d21d51-…"               @16:03:54
tool/result        "started subagent efa121dd-…"               @16:03:54

这些 call id 之后再也没有第二条 tool/result：唯一的完成信号，是每个子代理停止时投递的 subagent-settled 收件箱通知。

三、Lead 尝试等待时拿到什么

wait_agent 是工具集里唯一的阻塞原语，但它的作用域是 Team。在三个 subagent 子代理都还在跑时调用，它立刻返回：

{"timedOut":false,"noProgress":{"reason":"no-active-peer",
 "message":"No other Team member is running or provisioning. wait_agent cannot make progress or wake inactive teammates. Re-list with list_agents and team_task_list, then use send_message to wake each required inactive teammate before waiting again."}}

另一个会话（15:00:05）结果相同。在所有用 subagent 委派的会话里，wait_agent 没有一次真正阻塞过。

四、最终的回答时序（单个会话，已脱敏，本地时间）

时间	事件
16:03:54	启动 3 个后台子代理
16:08:06	子代理 #1 结算
16:11:04	主模型输出 1,961 字回答——子代理 #2、#3 仍在运行
16:12:10	子代理 #2 的报告到达 → 开启新 turn
16:13:08	主模型输出 1,981 字补充（「第 2 路的完整报告到了，这是增量」）
16:16:27	用户：「请你总结一下刚刚的调研结果，分段说让我有些迷糊」
16:16:37	主模型输出 3,286 字「总结」，其中包含一条否定性结论——子代理 #3 仍在运行
16:33:26	子代理 #3 才报告，其结论与上面那条相反
16:35:48	主模型输出 3,800 字更正：「我上一轮给你的总结里有一个结论是错的，必须收回……我没有等它就把否定结论写成了定论，这是我的判断失误」

也就是说，用户看到的顺序不是渲染假象：这些 assistant 消息确实在子代理报告之前就已产出，而之后每个子代理的消息都会开启一个新 turn，再产出一条新消息。

五、本机历史记录里的规模

方法：解压 ~/.dsh/sessions 下所有 session.v4.jsonl.zstd（共 191 个会话），把 subagent / spawn_teammate 调用与对应的 subagent-settled / team/message/delivered 事件配对，再和「含文本且无工具调用」的 assistant 消息比对时间戳。

• 10 个会话用过委派；其中 3 个会话存在「≥1.9k 字符的回答产出时，仍有 ≥1 个后台子代理在跑」；其中 2 个会话随后包含明确的自我更正。
• 本机全部 16 次 wait_agent 调用：11 次发生在 spawn_teammate 会话中，正常阻塞（例如 338 秒、104 秒、399 秒）并在下一条 teammate 事件时返回；2 次发生在 subagent 委派会话中，立即返回 noProgress/no-active-peer。

换句话说：用 spawn_teammate 时 Lead 能等、也确实等了全部队友；用 subagent 时它等不了，「最终回答 → 补充 → 更正」的模式随之出现。

六、为什么我认为这不只是「模型自己选择得不好」

Team 的提示词要求的，恰好是模型做不到的事：

"The Lead must wait for required teammates before giving the final answer."
（packages/experimental/tool-agent-team/src/index.ts）

但保留下来的委派工具并不属于 Team 作用域：

• subagent 子代理不是 Team 成员，list_agents 永远不列它们，send_message 也到不了它们（[Bug] Agent Teams bundle 在 Web/Desktop 未禁用 subagent：子代理不在 Team roster，list_agents/send_message 找不到也联系不上 #7642、[Bug] Duplicate tool names across scopes: Teams' `send_message` shadows `tool-subagent-control`'s, breaking plain continuable subagents #7087）；
• Agent Teams profile 用 Team 作用域的同名工具替换了 continuable-child 的控制工具（agent-team-profile/README.md），但 subagent / subagent_fork 仍然暴露；
• wait_agent 只观察 Team 的 roster / mailbox / task 边，因此拒绝为这些子代理等待。

于是 Lead 处在一个矛盾状态：提示词禁止它下最终结论，但没有任何工具能让它等待。用当前最好的结论结束 turn 是一个局部合理的选择，代价则落在用户身上，表现为一轮轮更正。

七、最小复现

1. 启用 @deepseek-ai/dsh-experimental-agent-team-profile（web 或 desktop）。
2. 新开一个会话，提出一个需要外部检索的任务，让模型用 subagent 并行派 3 个子代理（不要提 Agent Teams）。
3. 让其中一个子代理明显更慢（例如抓取大量页面）。
4. 观察：该子代理仍在跑时，Lead 的 turn 已经以一个看起来完整的回答结束；wait_agent 返回 noProgress/no-active-peer；之后每个子代理的 settle notice 开启新 turn，产出补充或更正。

八、可选方案（不互斥）

• A. 让 wait_agent 覆盖 continuable 后台子代理：把每个在跑子代理的 settle 边注册进同一个等待集合，让 Lead 能一直阻塞到自己启动的子代理都报告为止。
• B. 提供显式的 join：例如 wait_agent({ targets: [...] })，或 wait_subagents({ ids, mode: "all" })，在列出的子代理全部结算后返回（带单次调用的时间预算）。
• C. 让不一致无法发生：如果 profile 有意禁用 continuable-child 的控制工具，那就把会产生「无法 join 的子代理」的委派工具一并撤下（这正是 [Bug] Agent Teams bundle 在 Web/Desktop 未禁用 subagent：子代理不在 Team roster，list_agents/send_message 找不到也联系不上 #7642 的建议，也是社区 guard 插件的做法）。
• D. 如果 A、B 都不做：至少把这个状态如实暴露给模型，并把提示词改成它做得到的要求——告诉 Lead 当前有多少个子代理尚未结算、在它们结算前不允许给确定性结论，而不是给一条它无工具可满足的「必须等待」。

如果需要，我可以拿同一批会话记录验证上述任一方案；也可以提供原始事件序列（id/时间戳，正文脱敏）。