子会话与任务编排：破解复杂Agent任务的上下文失控难题

接手这个系列的时候，我就一直有预感，第五篇会是一个分水岭。前面几篇讲工具调用、单轮记忆维护的时候，很多人还能靠“堆上下文”硬扛过去，但一旦任务复杂起来——比如“看完这20份文件，按竞品维度写一份分析报告”——单个Agent的上下文窗口和注意力机制就集体失守了。要么写到一半忘了最初的问题，要么收集资料阶段就把上下文撑爆，要么把两个竞品的内容搅在一起。我这一篇要聊的，就是解决这类问题的机制：子会话（Sub-agent）和任务编排。

子会话不是一个“多开聊天窗口”这么简单的东西。它本质上是一种任务边界的划分方式——把一次复杂任务拆成多个带有独立上下文、独立指令、独立运行边界的执行单元，再由一个主控方把它们组织起来。做得好，你的Agent系统就是一个可以并行、可以回滚、可以局部重试的工程系统；做得不好，就是一场上下文失控的烟花秀。这篇的内容按标题编号来说是“05”，但如果你没看过前面四篇，也可以直接读——我会把子会话的原理、编排模式、代码示例、踩坑经验全部讲透。

1. 子会话不是“多开窗口”：它在解决任务边界问题

1.1 单会话为什么总会翻车

我在没有引入子会话之前，做Agent任务分解的方式非常粗暴：把所有要求塞进一个System Prompt，然后让Agent“一步一步想”。简单任务还好，任务一多就出问题。

举个真实场景：一个“竞品动态分析”任务，我需要让Agent收集三家公司近三个月的新品动态，然后交叉对比，最后产出一份PDF报告。如果用一个会话从头跑到尾，会发生三件事：

• 收集资料阶段会累积大量网页正文、笔记、临时摘要，这些内容会逐渐把上下文窗口占满。等到真正需要写报告的时候，Agent能记住的只剩最后两三家来源，早期的信息被“挤”出了有效注意力范围。
• 阶段性任务之间会互相干扰。Agent在“收集竞品A”的时候，脑子里还残留着“竞品B”的大量细节，写出来的分析会串味。
• 任何一个环节出错，比如某个网页抓取失败，Agent可能重试到把预算烧光，因为单一会话里没有一个清晰的“任务终点”。

这个问题的根源不是模型不够聪明，而是任务边界不清晰。一个会话承载了太多职责，模型需要在“广泛收集”和“聚焦写作”这两种认知模式之间反复横跳，结果两头都不讨好。

1.2 子会话的本质是“一个带独立上下文的执行单元”

子会话的做法，是把不同职责的干活过程拆开，每个子会话拥有自己的System Prompt、自己的人设、自己的输入输出协议，以及自己的运行预算。

用一句话概括：子会话 = 一个只负责一件事、只能看到局部信息、按约定格式交结果的独立执行单元。

它跟“一个Agent跑很多轮”最大的区别，就是上下文隔离。子会话内部不管聊了多少轮、积攒了多少中间信息，结束之后只把最终结果吐出来。主控会话拿到的是一份“干净的交付物”，而不是一大坨对话历史。

我之前在线上项目里用过一个比喻：单会话像一个全能员工坐在一个堆满文件的大办公室里干活，资料越堆越多，他越来越难找到关键文件；子会话则像一个项目组，每个人坐在独立的小隔间里，分别负责一块任务，最后把各自的交付物交到项目经理手上。项目经理不需要看每个人的草稿，只需要看他们提交的最终结论。

1.3 什么任务值得拆成子会话

子会话不是银弹，拆得过碎反而会带来额外的调度开销。我自己的判断标准是三条，至少满足两条我才会拆：

• 任务涉及多个不同的知识领域或信息来源，比如“既要做技术调研，又要做市场分析”；
• 任务存在明显的阶段性，后一段的结果依赖前一段的产出；
• 单次执行的信息量可能超过上下文窗口的合理承载范围，比如要读几十份长文档。

如果任务只是“写一封邮件”“做一份会议纪要”，单会话直接做完就好，拆子系统反而得不偿失。

2. 四种编排模式的选择逻辑：串行、并行、汇合、动态路由

任务编排就是把多个子会话按一定顺序和结构组织起来。这里没有万能的银弹，只有四种基础模式，理解了它们的取舍，你就能自由组合。

2.1 串行编排：前一个的输出，是后一个的输入

串行是最自然的编排方式：子会话A处理原始输入，产出中间结果；子会话B拿到这个结果继续处理；子会话C再基于B的产出做最终输出。数据流是一条线。

典型场景是内容生产流水线：“资料收集子会话”先提取事实，传给“数据分析子会话”做归纳，再传给“文案子会话”写报告。每个环节任务单一，Prompt可以写得非常具体。

串行的优点是好理解、好调试、好加缓存，任何一个环节失败，重跑那个环节就行。缺点是总耗时会累加，如果每个子会话都要跑几十秒，串行链路就会显得很慢。

我在实际项目中会在两种条件下优先选串行：一是任务本身有严格的因果依赖，必须等上一步结果；二是为了省成本，很多中间结果可以缓存复用。

2.2 并行编排：能并行的任务别串着跑

并行编排适合那些彼此没有依赖的子任务。比如竞品分析场景里，“调研竞品A”和“调研竞品B”之间没有任何依赖，它们完全可以同时跑。

并行带来两个直接收益。第一是延迟下降，如果三个子任务各自需要15秒，并行执行总耗时就只有15秒，而不是45秒。第二是隔离性更好，一个子任务失败不会影响其他子任务的状态，最后在汇总阶段统一处理部分失败的情况。

但并行也有代价。最大的代价是并发限流，很多模型API接口有每分钟请求次数限制（RPM），同时开8个子会话很容易触发429限流。我在生产环境里的经验是：默认并发控制在3到5个，根据上游API配额动态调整。

2.3 汇合编排：什么时候必须停下来等一等

并行子任务全部跑完后，必须有一个“汇合点”（join），把各个子会话的结果汇总起来。可以汇合后直接输出，也可以再交给一个新的子会话做综合整理。

汇合点