后台子代理主动回报：流式等待机制升级

近期，一条关于后台子代理（Background Subagents）机制更新的消息在开发者社区引发讨论。核心变化在于：子代理不再只是“发后即忘”，而是会在完成后将结果回传给父代理，并以同一运行中的后续轮次（follow-up turn）形式返回。这意味着 stream() 和 wait() 调用能够贯穿整个子代理生命周期，直到所有子代理全部结束。

从“发射后不管”到“闭环回报”

在多代理系统中，父代理常常需要派出子代理并行处理子任务——比如检索、代码生成、数据校验。过去，这类后台子代理的结果回收往往依赖轮询或独立回调，父代理的流式输出可能在子代理完成前就提前关闭，造成结果丢失或需要额外状态管理。

新机制把子代理的返回结果绑定为同一 run 的后续轮次。父代理调用 stream() 时，流不会在父代理自身输出结束后立即终止，而是继续等待子代理回传；wait() 同样会阻塞到所有子代理完成。对于需要聚合多路结果的场景，这减少了手动编排的复杂度。

子代理（Subagent） 是多代理架构中的一种分工模式：一个主控代理（父代理）将可拆分的子任务委派给若干受控代理实例，由它们各自携带独立上下文执行，再把结果汇总回父代理。这种结构常见于检索增强、代码生成与多步校验流水线。

早期实现多采用「发后即忘」语义：父代理只负责派发，子代理的结果通过轮询、回调或独立会话通道回收，父子之间不存在共享的运行轨迹。其代价是父代理必须自行维护任务状态表、完成计数与结果聚合逻辑，一旦流式连接提前关闭，尚未返回的结果就可能丢失。新机制把子代理纳入父代理的同一次运行，本质上是用运行时状态管理替代了应用层的手动编排。

技术细节：同一 run 的后续轮次

“同一 run 的 follow-up turn”这一表述值得拆解。它意味着子代理的结果并非作为独立会话注入，而是被视为父代理运行轨迹的延续。好处是上下文保持连贯：父代理在后续轮次中可以直接基于子代理返回的内容继续推理，无需重新建立状态。

这也对运行时提出了要求——调度器需要跟踪每个子代理的完成状态，并在流式通道上按序或按完成顺序插入轮次。对于并发子代理，结果返回顺序可能与派发顺序不同，开发者需要关注聚合逻辑是否对顺序敏感。

run（运行）与 turn（轮次） 是代理运行时的两级概念。一次 run 代表从用户发起请求到最终答复的完整生命周期，其中可包含多个 turn：每个 turn 是一次「模型推理—工具调用—结果回填」的循环。把子代理结果作为同一 run 的 follow-up turn 插入，意味着它复用了父代理已有的消息历史与工具调用轨迹，而不是另起一个会话。

与之相对，若结果以独立会话注入，父代理需要在上下文中重新声明任务背景，且两套状态容易不一致。需要注意的是，同一 run 内插入轮次要求流式通道支持多段输出的有序拼接，调度器通常以完成顺序而非派发顺序写入，因此聚合逻辑若假设「先派发先返回」就可能出错。

对开发者的实际影响

最直接的变化是流式接口的语义扩展。以往 stream() 的结束往往被理解为“本轮任务结束”，现在则需要理解为“本次 run 及其全部子代理结束”。在构建前端实时展示或日志系统时，这一差异会影响加载状态的判定。

其次，wait() 的阻塞时间可能变长。如果子代理中存在耗时任务，父代理的等待周期会相应延长。对超时设置和取消机制的设计需要重新评估，避免因个别子代理卡住而拖垮整体流程。

流式接口的终止语义在这里发生了变化。传统 stream() 的结束信号（如流关闭或结束标记）对应「本次生成完毕」；而当子代理被纳入同一 run 后，该信号的实际含义扩展为「本次 run 内所有挂起任务均已结算」。前端加载状态、进度条与日志切分若仍以旧语义判定，会出现「界面已显示完成但结果随后才到达」的错位。

配套地，wait() 的阻塞语义也从「等待父代理本轮输出」变为「等待整棵子代理树结算」。实践中通常需要引入分层超时：为单个子代理设置独立时限，为整体 run 设置总时限，并提供取消传播机制，使父代理中止时能连带终止仍在运行的子代理，避免孤儿任务占用资源。

仍需观察的问题

当前公开信息较为简短，尚未说明子代理失败时的回报行为、结果大小限制、以及嵌套子代理（子代理再派生子代理）是否同样适用该机制。这些细节将直接影响生产环境中的可靠性设计。

总体来看，这一更新让后台子代理从“异步旁路”走向“运行闭环”，是多代理编排向更自然语义迈进的一步。