一个 Agent 不够用时，自然会想到用多个 Agent 分工合作。多 Agent 架构确实能解决一些单 Agent 解决不了的问题，但它也是最容易被滥用的模式。这一篇讲清楚它的价值和代价。
一、常见的多 Agent 模式
1. 主从模式（Orchestrator-Worker）
一个主 Agent 负责理解任务、拆分子任务、分派给子 Agent，再汇总结果。子 Agent 各自完成分到的部分，把结论返回给主 Agent。
主 Agent：调研三家竞品的定价策略
├─ 子 Agent A：调研竞品 1 → 返回定价摘要
├─ 子 Agent B：调研竞品 2 → 返回定价摘要
└─ 子 Agent C：调研竞品 3 → 返回定价摘要
主 Agent：对比三份摘要，写出分析报告这是最常用、也最实用的多 Agent 模式。
2. 流水线模式
每个 Agent 负责一个固定环节，前一个的输出是后一个的输入。比如：收集资料 → 撰写初稿 → 审核修改。本质上是一个工作流，每个环节用 Agent 实现。
3. 角色协作模式
多个 Agent 扮演不同角色，比如「产品经理」「工程师」「测试」，互相对话完成任务。看起来很热闹，但在实际生产中效果往往不如前两种稳定。
二、为什么要用子 Agent
1. 上下文隔离
这是最重要的理由。一个调研子任务可能要搜索十几次、读几十个网页，产生大量中间内容。如果都放在主 Agent 的上下文里，很快就会被塞满（第 07 篇讲过的问题）。交给子 Agent 后，这些中间内容留在子 Agent 自己的上下文里，主 Agent 只收到一段精简的结论。
2. 并行
互相独立的子任务可以同时执行，总耗时从各任务之和变成最长那个任务的耗时。上面调研三家竞品的例子，并行能快三倍左右。
3. 专门化
不同子 Agent 可以有不同的 System Prompt、不同的工具，甚至用不同的模型。比如简单的资料整理用更快更便宜的模型，关键的分析用更强的模型。
三、多 Agent 的代价
- 成本成倍增加：每个子 Agent 都要独立建立上下文，重复加载 System Prompt 和工具定义，总 token 消耗可能是单 Agent 的数倍。
- 交接信息丢失：子 Agent 看不到主 Agent 的完整上下文，它只知道你交给它的那段任务描述。描述不完整，它就会做错或做偏。
- 协调复杂：子任务之间有依赖时，需要处理顺序、冲突、结果合并。
- 调试困难：出了问题，需要追踪多个 Agent 的执行记录才能定位。
四、交接：多 Agent 成败的关键
主 Agent 给子 Agent 的任务描述，决定了子 Agent 能否做对。好的交接应该包含：
- 目标：要完成什么，以及这个结果会被用来做什么。
- 背景：子 Agent 需要知道的上下文，比如已经排除了哪些可能。
- 范围：做什么、不做什么，避免越界或重复。
- 输出格式：结果以什么形式返回，方便主 Agent 汇总。
对比：
| 差的交接 | 好的交接 |
|---|---|
| 调研竞品 1 的定价 | 调研竞品 1 的会员定价策略，用于和我们的方案对比。重点：各档位价格、包含的功能、近一年是否调价。不需要调研免费版。用表格返回各档位信息，最后用两三句话总结其定价思路。 |
五、什么时候用单 Agent 就够
多 Agent 不是升级版，而是一种有代价的工具。以下情况优先用单 Agent：
- 任务步骤之间强依赖，后一步必须基于前一步的全部细节；
- 任务规模不大，单个上下文装得下；
- 对成本敏感；
- 需要整体一致性，比如写一篇风格统一的文章。
判断标准：子任务能否独立完成，并且只需要返回一个简短的结论？如果能，适合拆给子 Agent；如果子任务需要频繁和主任务交换细节，就不要拆。
本篇小结
- 常见模式：主从、流水线、角色协作，主从最实用。
- 子 Agent 的价值：上下文隔离、并行、专门化。
- 代价：成本增加、交接信息丢失、协调与调试复杂。
- 交接要讲清目标、背景、范围、输出格式。
- 子任务能独立完成且只需返回简短结论时，才适合拆分。
思考与练习
- 什么情况下单 Agent 比多 Agent 更好？举两个具体例子。
- 为「分析过去一周三个业务线的异常指标」设计一个主从结构，写出主 Agent 给子 Agent 的交接描述。
上一篇：AI Agent原理篇10：规划、反思与任务分解
下一篇：AI Agent原理篇12：MCP 协议原理
返回系列总目录