当一个 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 使用相同关键词、读取相同材料并输出相似摘要名义上并行实际上没有增加覆盖面。第二是前提不一致。一个 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 在运行而是它们完成的工作能否在最后汇聚成一个可信结果。