当一个 AI 完成任务不够快或结果不够好时，最直觉的想法是：再启动几个 AI，让它们一起做。
于是，同一个问题被同时交给三个 Agent。过一会儿，我们得到三份结构相似、观点略有差异的答案，还需要自己重新核对事实、消除重复、处理冲突并拼成最终版本。计算量增加了，工作却没有真正减少。
这不是多 Agent 协作，只是把同一项工作重复了几遍。
多 Agent 的价值不来自数量，而来自任务能否被合理拆分、每个 Agent 是否拥有清楚边界，以及最终结果能否被可靠合并。
多 Agent 真正增加了什么
单个 Agent 通常在一个上下文中依次理解问题、查找资料、执行操作并形成答案。多 Agent 则把部分工作交给拥有独立上下文的执行者，使它们可以并行探索不同方向，或由不同角色依次检查同一产物。
这里真正增加的不是“更多聪明”，而是三种系统能力：
- 隔离上下文：每个 Agent 只接收与自身任务相关的材料，减少无关信息干扰。
- 明确所有权：不同子任务由不同 Agent 负责，避免所有人都做一半。
- 并行或交叉验证：独立任务可以同时推进，关键结论也可以由另一角色复核。
代价同样明显：需要编写委托、同步状态、处理重复、解决冲突并检查最终合并。子任务越模糊，这些协调成本越高。
什么任务适合拆成多个 Agent
| 任务特征 | 是否适合 | 原因 |
|---|---|---|
| 多个子问题彼此独立 | 适合 | 可以并行完成，互相等待较少 |
| 需要不同资料、工具或专业视角 | 适合 | 可以按能力和证据范围分工 |
| 结论需要独立复核 | 适合 | 生成与验证可以由不同角色承担 |
| 任务很小且步骤高度连续 | 不适合 | 委托和合并成本可能超过执行本身 |
| 多人必须同时修改同一文件 | 通常不适合 | 容易发生覆盖、冲突和结构漂移 |
| 目标本身仍然模糊 | 不适合 | 模糊会被复制到每个子任务中 |
一个简单判断是：如果不能用一句话说明每个 Agent 应交付什么，就还没有准备好并行。
一次可靠拆分需要四个部分
1. 任务边界
每个 Agent 需要知道自己解决哪个问题，以及明确不解决什么。让一个 Agent “研究一下相关内容”通常会得到范围重叠的长报告；让它“只核对三项关键结论的一手来源，并输出来源、原文依据和不确定项”，结果更容易被使用。
2. 输入边界
不同角色不一定需要看到全部材料。检索 Agent 需要关键词和来源要求，写作 Agent 需要已经核验过的证据卡片，验证 Agent 则需要成稿、验收规则和原始证据。
把所有上下文复制给所有 Agent，看似省事，实际会增加成本，也让无关材料更容易影响判断。
3. 输出契约
子 Agent 的输出应当可以被直接检查和合并。最小输出契约通常包括：结论、证据、适用范围、不确定项和产物位置。
如果一个 Agent 只返回“已经研究完成，整体可行”，主 Agent 几乎无法判断它做了什么；如果它返回结构化证据清单，后续写作和核验就有了稳定接口。
4. 合并权威
多个 Agent 得出不同结论时，需要有人决定如何处理。这个角色可以是主 Agent，也可以是专门的验证者，但不能依靠简单多数票。
三个 Agent 重复了同一个错误，仍然是错误。冲突应回到证据、任务规则和来源权威，而不是看哪种表述出现次数更多。
一个基本的协作结构
图中的中心不是 Agent 数量，而是“共享产物—验证—统一合并”这条链。如果缺少合并门，多个子任务只会生成更多需要人工整理的材料。
多 Agent 最容易浪费在协调上
多 Agent 系统常见的失败，并不是某个 Agent 完全不会做任务，而是协作过程中出现了结构性损耗。
第一是重复劳动。多个 Agent 使用相同关键词、读取相同材料并输出相似摘要，名义上并行，实际上没有增加覆盖面。
第二是前提不一致。一个 Agent 使用最新版本，另一个使用历史文档；一个按公开读者写作，另一个按学术论文组织，最终结果无法直接合并。
第三是状态过期。子任务发出后，主任务的目标或材料已经变化，但子 Agent 仍根据旧上下文继续工作。
第四是写入冲突。多个 Agent 同时修改同一文件，很容易覆盖彼此内容，或者让标题、术语和论证结构不断漂移。
第五是合并失真。主 Agent 为了压缩输出，只保留各子任务的结论，却丢失了证据边界和未解决问题。
这些成本说明，多 Agent 不是免费的并行计算。它更像组织一个临时团队：成员越多，越需要清楚的角色、接口和决策机制。
以一份研究报告为例
假设要撰写一份“AI Agent 数据安全风险”报告，可以这样分工：
- 证据 Agent只负责查找一手来源，输出事件、日期、原文与核验状态。
- 机制 Agent只负责把案例归纳为权限继承、提示注入、外部发送和日志残留等风险链。
- 治理 Agent只负责整理现有制度能够覆盖什么、尚不能直接推出什么。
- 验证 Agent检查正文中的每项事实能否回到来源，标题是否强于证据。
- 主 Agent决定文章结构、处理冲突，并形成统一文风的最终版本。
这种拆法的价值在于不同角色拥有不同责任。证据 Agent 不负责写漂亮结论，写作角色也不能自行补造来源。只要输出契约清楚，多个 Agent 才能真正降低主任务的认知负担。
让 Agent 交接产物，不要交接整段对话
Agent 之间最稳定的交接对象，通常不是长篇聊天记录，而是可以验证的产物。一个简单的交接卡片可以写成：
任务：本 Agent 负责的问题。 结论：已经得到的有限结论。 证据：来源、文件或实际运行结果。 边界：结论成立的条件和未覆盖范围。 待处理：需要下一个角色继续解决的问题。 产物：保存位置或可复现入口。这种方式不会消除所有信息损失，但能够让接收者快速区分事实、解释和待办。如果确实需要了解推理过程，也应当回到相关证据和中间产物，而不是默认转发全部对话。
三个常见误区
第一，认为 Agent 越多，答案越可靠。相同模型、相同材料和相同提示可能产生高度相关的错误，数量不能替代独立证据。
第二，把所有任务都并行化。存在明确依赖关系的步骤应当顺序执行，例如必须先确认数据口径，才能开始统计和写结论。
第三，让每个 Agent 都交付完整终稿。完整终稿最难合并；明确的证据清单、对照表、检查结果和局部草稿通常更有复用价值。
启动多个 Agent 前的 30 秒检查
- 这个任务是否真的包含可以独立推进的子问题？
- 每个 Agent 的输入、输出和禁止范围是否清楚？
- 不同 Agent 是否会同时修改同一份产物？
- 子任务之间有哪些依赖，哪些可以并行？
- 结论冲突时，依据什么规则和证据裁决？
- 谁负责最终合并，并检查遗漏、重复和文风一致性？
- 并行带来的时间收益，是否大于委托和整合成本？
多 Agent 不是把一个问题复制给更多模型，而是把复杂任务设计成一组边界明确、能够交接、可以验证的工作单元。
真正重要的不是有多少 Agent 在运行，而是它们完成的工作能否在最后汇聚成一个可信结果。
