多智能体真正的收益常常被误读成”并行加速”。实际排在第一位的是上下文隔离：一个子智能体翻五十个文件、烧掉自己整个上下文窗口，最后只给编排者三句话结论——脏活留在里面，主线始终清醒。
子智能体到底是什么
子智能体是编排者派出去干一件具体事的子进程，拥有自己的上下文窗口、自己的工具集、自己的任务描述，干完把结果交回来。它和”多轮对话”最大的区别是：它有独立的记忆边界，天然不知道主线之前聊过什么。
这既是优点也是陷阱——优点是不污染主线，陷阱是它什么都不知道，只能靠你给的简报。
为什么隔离比并行更重要
一个智能体同时做所有事会撞上三堵墙，子智能体解决的是前两堵：
| 瓶颈 | 表现 | 子智能体怎么解决 |
|---|---|---|
| 上下文过载 | 会话越长，早期关键信息越被稀释 | 探索过程消耗子智能体的窗口，主线只收结论 |
| 角色不专 | 一个模型同时处理数据层、接口层、前端、测试 | 每个子智能体只持有自己领域的上下文与工具 |
| 无法协作 | 多个助手之间没有共享任务列表与依赖管理 | 需要额外的编排机制，仅靠子智能体不够 |
完全串行的子智能体调用也值得做。哪怕一次只派一个，只要把探索过程挡在主线之外，主会话的有效寿命就会显著变长。
角色分解：规划者、执行者、评审者
- 规划者：用最强的模型把目标拆成若干可独立验收的任务，每个任务带明确的验收标准。
- 执行者：一个任务一个子智能体，拿到自包含的完整简报。简报质量等于结果质量，因为它冷启动、看不到主线、中途也问不了。
- 评审者：另起一批子智能体按验收标准检查。必须由新上下文来做——让执行者自查会共享它自己的盲区。
- 汇总：编排者收集结果，处理冲突与缺口，决定是否需要下一轮。
四种常用编排形状
- 扇出后汇总：把一张工作清单（待迁移的文件、待审计的模块）映射给 N 个并行子智能体，再聚合结果。最常用，加个并发上限就能扩展到几百项。
- 流水线：查找、验证、修复多阶段，每个条目独立流转，不要在阶段之间设屏障，否则快条目要等最慢的。
- 评审团：同一任务从多个角度各出一版，并行打分后采纳最优。适合方案空间很大的场合。
- 对抗验证：对每个结论派专门的”反驳者”去推翻，活下来的才放行。这是对付”看着对其实是错的”最有效的过滤器。
子智能体该返回什么
报告就是产品
- 返回提炼后的结构化结论：发现、文件与行号、判定，而不是”我看了哪些东西”的流水账。
- 能校验结构就校验，格式化的输出比自由文本更容易聚合。
- 明确给出置信度与不确定的地方，让编排者知道该不该复派。
- 不知道就如实说”没找到”，不要为了完成任务编一个答案。
控制流用代码，判断用模型
成熟的编排会把循环、扇出、聚合、重试策略写进脚本，只把”逐个条目的推理”留给模型。这样做的好处是可复现、可断点续跑，而且能像普通代码一样被评审。让编排模型临时决定什么时候派谁，灵活但每次都不一样，出问题难复现。
和现有实践怎么接
子智能体是多智能体编排里最基础的一层，往上还要解决任务共享与依赖管理。子智能体常被用于长任务，配合跨上下文窗口的长时运行设计才能真正撑住小时级任务。
回到根子上，派子智能体本质也是上下文分配决策，和上下文工程的取舍同源：给太少会冷启动跑偏，给太多就失去了隔离的意义。
延伸阅读：多智能体编排什么时候不该拆子智能体？
单步就能完成的任务、需要沿用中间过程的任务、以及拆分带来的开销大于收益的小活。另外上下文依赖很强、环环相扣的线性改动也不适合。
并行几个合适？
常见建议是 3 到 5 个。再多不会有线性收益，反而增加聚合冲突和协调成本。
子智能体需要继承主线对话吗？
默认不需要，隔离正是目的。只有当任务是继续主线已经做过的工作时才需要，这时可以用会继承上下文的模式，代价是提示词缓存可能失效。
多个子智能体结论冲突怎么办？
先检查任务简报是否一致、验收标准是否明确。多数冲突源于简报含糊；仍有分歧就派评审角色按原始标准裁决，不要简单取多数。
评论 (0)