多 Agent 协作是能力升级，还是复杂度陷阱

多 Agent 协作只有在任务确实能拆开，而且拆分收益大于通信、协调、评测和排错成本时，才是能力升级。把一个 Agent 改成「规划者、研究员、执行者、审核员」四个名字，并不会自动提高质量；如果它们反复转述同一份材料，系统只是用更多调用完成原来的一件事。

这里的多 Agent，指多个具有独立任务上下文或工具权限的 Agent，由调度规则分工、交换结果并共同完成一个目标。它不是多人聊天界面的视觉效果，也不等于把固定步骤拆成多个程序节点。若连单个 Agent 与普通自动化的边界还不清楚，可先读AI Agent 是什么。

评审多 Agent 方案，先画出单 Agent 基线

假设任务是制作一份供应商评估报告：读取内部需求，收集候选资料，对比能力与风险，形成建议并复核引用。单 Agent 可以按顺序完成；多 Agent 方案可能让资料收集、内部需求整理和风险复核分别运行，再由一个协调者合并。后者看起来更像团队，但是否更好，必须和前者在同一批任务上比较，而不是只看一次演示。

基线至少要记录任务成功率、人工修订量、总耗时、调用成本和失败后的恢复难度。若单 Agent 已稳定满足要求，多 Agent 需要证明自己解决了一个可指认的瓶颈：等待时间太长、上下文互相干扰、工具权限无法隔离，或某类检查持续漏掉。没有基线，所谓协作收益通常只是架构观感。

任务拆分在四种情况下可能产生净价值

第一种是可并行的独立子任务，例如多个候选对象分别收集资料，彼此几乎没有依赖。第二种是工具或权限天然分隔：读取财务数据的角色不应拥有对外发送能力，外部研究角色也不必接触内部敏感资料。第三种是上下文隔离，不同专业材料各自在较小工作区处理，避免所有信息挤进一个 Agent。第四种是有意引入独立复核，让审核者在不知道原始推理过程的情况下按证据检查结果。

四种情况都有一个共同前提：子任务有清楚的输入、输出和完成标准。若每个角色都要持续读取全部历史、反复询问其他角色才知道下一步，拆分就没有形成真正边界。还要确认问题需要的是 Agent，而不是固定工作流里的普通函数或并行任务；AI 工作流和 AI Agent 怎么选中的确定性判断，在这里仍然适用。

• 并行价值：子任务能同时开始，合并点明确，等待时间确实会缩短。
• 专业价值：角色使用不同资料、工具或评价标准，不只是换一段角色提示词。
• 隔离价值：数据和权限按职责收窄，任一角色出错时影响范围更小。
• 复核价值：审核角色能依据独立标准发现错误，而不是礼貌地重复前一角色结论。

通信与协调会收走一部分拆分收益

Agent 之间不能像经验丰富的同事那样凭默契补全含义。一个角色把结果交给另一个角色时，必须把关键事实压缩成消息；压缩可能丢掉证据、适用条件和未解决问题，完整转交又会增加上下文与成本。角色越多，交接次数越多，同一个术语被不同角色理解成不同含义的机会也越多。

因此交接需要合同式结构：任务编号、输入版本、已完成事项、结论、证据引用、假设、不确定项和允许的下一步。接收方要能拒绝不完整交付，而不是猜测后继续。通信成本不能只按消息字数计算，还包括为了澄清而重跑、因为摘要失真而返工，以及协调者为合并冲突结果消耗的调用。

协调则处理依赖顺序、超时、重试、取消和重复执行。两个 Agent 同时修改一份候选名单，谁的版本为准；上游超时后下游是否继续；协调者重试时，已完成的外部动作会不会再做一遍。这些都是分布式任务管理问题，不会因为参与者叫 Agent 就消失。多 Agent 项目必须指定唯一任务状态、对象所有者和版本规则；AI Agent 的五层记忆与状态边界可帮助区分共享任务状态、长期记忆与日志。

评测从「答案好不好」变成一组组合题

单 Agent 可以先看最终任务是否完成，再检查步骤质量。多 Agent 还要增加三层评测：每个角色是否完成自己的子任务，交接是否满足合同，组合后是否达成端到端目标。某个研究角色准确率提高，不代表整套系统更好；如果它输出太慢、格式不稳定或让协调者频繁返工，局部提升可能降低整体成功率。

把局部能力与端到端结果分开测

角色级测试使用固定输入，检查证据完整性、格式和权限边界；交接测试故意缺字段、给冲突版本或制造超时，观察系统是否停在正确位置；端到端测试则使用代表性任务集，比较成功率、成本、延迟、人工介入次数和恢复能力。不要只测角色们顺利合作的一次路径。验收指标可沿用把 AI 试点写成可检验条件的思路，并为协作失败增加独立指标。

评测还有归因难题：最终报告漏了一项，是规划者没分配、研究者没找到、交接时被摘要掉，还是合并者删错？如果只给最终答案打分，团队知道系统失败，却不知道该改哪个角色。每一层都要保留自己的输入、输出和校验结果，才能把整体分数落到可行动的问题上。

排错成本更像查一条链，而不是改一句提示词

多 Agent 故障常表现为最终结果不对，根因却可能早在几步之前：规划错误导致任务漏分，旧状态被当成新版本，工具返回异常没有上报，交接摘要删掉限制条件，审核角色又只检查格式。修复最后一个角色的提示词，可能暂时遮住问题，下次换一种输入仍会复发。

没有贯穿全链路的记录，就无法稳定复现

每次运行需要一个贯穿父任务与子任务的标识，并记录角色版本、输入引用、输出、工具调用、状态变化、重试、审批与耗时。排错人员才能从最终异常向上游追踪，并在隔离环境重放某个交接点。日志不是越多越好：要能定位决策与副作用，同时避免把敏感内容无差别复制到所有角色。

权限也会增加组合复杂度。每个角色只应获得子任务所需工具，协调者负责派单不代表拥有所有业务操作权，审核者能退回结果也不代表能直接改生产数据。具体动作仍应经过读取、生成、修改、执行与外发的分级闸门，详见AI Agent 权限、审批与人工接管边界。否则一次错误计划会沿着多个角色的权限迅速放大。

这些条件出现时，不要使用多 Agent

任务短而线性、每一步都依赖上一段完整上下文时，单 Agent 或固定工作流通常更合适。所有角色使用相同资料、相同工具和相同评价标准时，角色拆分只是重复读取。最终产出需要整体语气与综合判断，而子结果很难独立验收时，合并成本也会高于专业分工收益。

同样，不要在以下情况下上多 Agent：单 Agent 还没有做过基线优化；团队无法定义交接格式；没有端到端任务集和失败样本；业务要求极低延迟或严格成本上限；系统缺少全链路状态与日志；高风险动作又没有清楚的责任人与审批点。无法评测和排错的协作，不是更强的系统，而是更难证明正确的系统。

合理路径是一次只拆一个有证据的瓶颈

选型可以从一份小型架构论证开始，而不是从角色名单开始。先让单 Agent 在代表性任务集上运行，找出主要失败来源；再判断该问题能否通过更清楚的工具、检索、工作流或提示解决。只有当瓶颈确实来自并行等待、专业上下文冲突、权限隔离或独立复核，才增加一个角色，并保持其他条件不变做对照。

1. 这两个子任务能否独立定义完成标准，并在很少来回沟通的情况下交接？
2. 新角色是否拥有真正不同的资料、工具、权限或评价标准？
3. 拆分预计改善哪个基线指标，增加的调用、延迟和运维成本上限是多少？
4. 交接缺失、角色超时、结果冲突和重复执行时，系统是否有确定处理规则？
5. 团队能否分别评测角色、交接与端到端结果，并从日志定位责任步骤？
6. 移除这个角色后，质量或速度是否显著下降？若没有，角色就不该保留。

多 Agent 的成熟标志不是架构图上有多少圆圈，而是每次拆分都能说清净收益，也能在收益不成立时删回去。先把一个 Agent 做成可测、可控、可排错的系统，再让第二个角色解决已经被证据确认的问题；这比从「模拟一支 AI 团队」出发，更接近企业真正需要的协作。