交互式主会话不应因 subagent_wait 持续阻塞

[tt-a1i]

问题

当前 subagent_spawn 本身是后台执行，但主 Agent 在没有其他可做工作、后续步骤又依赖子 Agent 结果时，可能主动调用 subagent_wait。这会让交互式主会话一直保持 Working... / Waiting for ...，直到所有子 Agent 完成。

底层等待是事件驱动的，并非轮询；但从用户体验看，主会话仍被一个长时间工具调用占住。用户此时更希望主 Agent 结束当前轮、恢复可交互状态，而不是为了稍后的汇总持续阻塞。

当前行为

1. 主 Agent 启动一个或多个后台子 Agent。
2. 模型判断“下一步必须依赖结果”，于是调用 subagent_wait。
3. 当前主 Agent 轮次一直挂起。
4. 子 Agent 完成后，等待工具返回，主 Agent 才继续汇总。

现有提示词虽然强调不要仅为了空等而调用 subagent_wait，但同时允许“下一步确实依赖结果且暂无其他工作”时等待。这个例外覆盖了常见的并行实现、审查、合并场景，因此模型仍容易选择同步阻塞。

期望行为

在有 UI 的交互式主会话中，默认采用真正的后台语义：

1. 启动子 Agent 后，主 Agent完成当前可做工作。
2. 如果没有其他独立工作，向用户简短说明任务正在后台执行并结束本轮。
3. 主会话进入 idle，可立即接收和处理新的用户消息。
4. 子 Agent 完成后，通过现有自动结果投递机制唤醒主 Agent，由它继续汇总或执行后续步骤。
5. 如果主 Agent 当时正在处理另一条用户消息，结果不应打断当前回复，而应进入合适的后续轮次上下文。

建议方案

• 收紧 SUBAGENT_WAIT_TOOL_DESCRIPTION 和父 Agent 提示词：在交互式会话中，不应仅因为“下一步依赖结果”或“没有其他工作”而调用 subagent_wait。
• 将“结束本轮，等待自动投递后重新唤醒”设为交互场景的强默认。
• 保留 subagent_wait 作为显式同步屏障，但限制在以下情况：
  • 用户明确要求当前回复必须等所有子 Agent 完成；
  • 无 UI / 自动化执行，需要在同一调用中产生完整结果；
  • 内部工作流具有真正不可拆分的同步语义。
• 不改变子 Agent 的事件驱动完成通知，也不引入状态轮询。

验收条件

• 交互式会话中，模型启动后台子 Agent 后，在无其他独立工作时默认结束当前轮，而不是调用 subagent_wait。
• 等待期间主会话处于 idle，用户可以立即发送并获得对新请求的响应。
• 子 Agent 完成后仍会自动投递结果并唤醒主 Agent 继续处理。
• 子 Agent 在主 Agent 忙碌期间完成时，不打断当前回复，且结果不会丢失或出现在错误的时间线位置。
• 用户明确要求同步等待时，subagent_wait 仍然可用。
• 增加提示词/工具描述测试，防止策略回退为“没别的事就同步等待”。

相关

• Subagent 延迟结果显示在下一条用户消息之后，造成时间线错位 #29 修复了延迟子 Agent 结果显示在下一条用户消息之后的时间线错位。
• fix: keep deferred subagent results in timeline order #30 实现了可见时间线条目与模型上下文投递分离，为后台完成后的正确回传提供了基础。