多智能体不是银弹：编排、通信与成本取舍

去年有段时间，多智能体特别火。我们也没忍住，拉了一个“研究小组”：一个规划者、一个检索者、一个分析师、一个写作者，再加一个审查者。五个 Agent，听起来分工明确。

实际跑起来是这样的：规划者把任务拆得太细，检索者找回来一堆重复资料，分析师和写作者对“结论应该是什么”产生了分歧，审查者最后把所有东西打回来重做。二十分钟过去，它们还在讨论谁该先说话。

最后交上来的方案，还不如一个单 Agent 加两个工具。

这次失败之后，我对多智能体的态度冷静了很多。它不是不能做，是很多团队做早了。

多 Agent 最常见的失败，是协调成本超过任务本身

多智能体的宣传往往强调“分工”和“并行”，但很少提协调成本。

每增加一个 Agent，就多一份上下文、多一轮通信、多一个可能失败或误解的环节。协调者要汇总信息，worker 要理解任务，结果还要合并、去重、解决冲突。这些开销在 demo 里看不出来，在长任务里会迅速累积。

更麻烦的是调试。单 Agent 出了问题，你看一条轨迹；多 Agent 出了问题，你要在几条交错的轨迹里找因果。很多时候，你甚至不知道是哪个 Agent 先偏的。

所以我现在判断要不要上多 Agent，先问一句：这个任务的分工，是不是天然存在？

什么时候真的需要

我见过真正适合多智能体的场景，大概有三类。

第一类是可以并行的子任务。比如同时检索多个数据源，或者对一批文档分别做抽取，最后汇总。各干各的，互不依赖。

第二类是工具和权限差异很大。比如一个 Agent 只能读公开资料，另一个能访问内部数据库，还有一个能执行写操作。用权限边界把角色分开，比让一个 Agent 什么都能干更安全。

第三类是需要独立验证。一个 Agent 生成，另一个 Agent 专门挑错，最好用不同的模型或不同的上下文，避免“自己审自己”。

除了这三类，很多所谓的多 Agent 需求，其实单 Agent 加工具就能解决。任务步骤多，不等于需要多个角色；上下文长，不等于需要多个大脑。

拓扑不是越复杂越好

常见的多智能体拓扑有主管式、层级式、对等式、辩论式和市场式。

主管式是一个协调者分派任务给 worker，结构清晰，最容易控制。层级式适合大型任务，但层级越多，信息损耗越大。对等式灵活，但容易出现死循环和重复工作。辩论式适合高风险决策，但成本高，而且不保证收敛。市场式听起来很先进，工程上通常不值那个复杂度。

对大多数团队，主管式加两三个 worker 是性价比最高的起点。先把一个协调者和两个明确分工的 worker 跑稳，再考虑扩展。

辩论式我一般会劝退。除非任务真的需要多角度对抗，否则它只是把一次推理变成五次，还不一定更准。

通信要有 schema

多智能体系统里，最容易被低估的是通信。

Agent 之间传什么、怎么传、传丢了怎么办，如果没有约定，系统很快就会变成一团乱麻。我见过用自然语言互相喊话的实现，最后连“任务完成了没有”都判断不了。

比较稳的做法是：任务状态放共享存储，Agent 之间只传事件和引用；消息有固定 schema，带 run ID、task ID、发送方、接收方、类型、载荷、截止时间和重试次数；大对象放对象存储，消息里只放 ID。

还要处理冲突和死锁。明确谁有最终决策权，设置超时和最大轮次，对共享资源加锁或串行化，检测循环依赖和重复任务。

这些听起来像分布式系统的基础课，因为它本来就是。多智能体不是新魔法，它只是把分布式系统的问题搬到了模型之间。

成本会放大

多智能体的 token 消耗，不是简单的加法。

每个 Agent 都有自己的系统提示和上下文，协调者要汇总和转发大量信息，辩论和审查会产生多轮重复推理，通信失败和重试还会增加调用次数。

我一般会盯一个指标：协调开销占总成本的比例。如果超过三成，通常说明拓扑太复杂，或者分工不清晰。

另一个指标是每次成功任务的总成本。多 Agent 如果只是把成功率提高了两个点，成本却翻了三倍，那这笔账很难算得过来。

还有一个隐形成本：评测和调试。单 Agent 的失败轨迹是一条线，多 Agent 的失败轨迹是一张网。你要判断是哪个 Agent 先偏的、消息在哪一步丢的、状态被谁覆盖的，往往要花几倍时间。这个成本不会出现在 token 账单上，但会出现在工程师的加班时间里。

单 Agent 往往更好

很多“多智能体”的需求，用单 Agent 可以解决得更好：

把上下文工程做好，让模型在正确的信息上推理；把工具边界划清楚，让每个工具只做一件事；用结构化输出和校验，减少格式错误；把固定流程做成工作流，而不是让 Agent 自由发挥。

单 Agent 的优势是状态集中、调试简单、成本可控、行为一致。这些优势在 production 里比“看起来更像一个团队”重要得多。

一次五 Agent 会议的复盘

那次实验结束后，我把日志翻出来算了一笔账。

五个 Agent，二十分钟，一共产生了 140 多条消息。其中真正推进任务的不到三分之一，其余是确认、复述、等待和重复提问。协调者花了大量 token 在汇总上，两个 worker 对同一个概念使用了不同的定义，审查者最后推翻的方案，其实是规划者最早提出的那一版。

成本大约是单 Agent 方案的六倍，任务成功率还低了一点。

我们后来把它拆了。先用一个单 Agent 加检索和写文件两个工具，把主流程跑通；只把“独立审查”拆成第二个 Agent，用不同的模型和上下文，专门挑错。消息从 140 条降到 20 多条，成功率反而上去了。

这次复盘让我对“角色越多越像团队”这种说法彻底祛魅。Agent 的数量不是能力指标，能少一个就少一个。

主管式怎么落地

如果非要用多 Agent，我会从主管式开始。

主管只做三件事：拆任务、分派、汇总。它不直接调业务工具，也不参与具体执行。

每个 worker 有明确的输入和输出契约：给它什么状态，期望它返回什么结构，超时多久，失败怎么上报。worker 之间不直接通信，所有信息通过共享状态和主管转交。

停止条件也要写死：最大轮次、总预算、每个子任务的截止时间。主管发现某个 worker 连续失败，就跳过它或者转人工，而不是一直重试。

这套结构不新鲜，但它可控。多 Agent 的问题往往不是不够聪明，而是没人负责踩刹车。

别急着加 Agent

多智能体是一种架构选择，不是能力证明。

我现在判断一个多 Agent 系统是否合理，会看它有没有单 Agent 基线，能不能证明多出来的 Agent 带来了可测量的收益。如果答不上来，那大概率是为了架构而架构。

先让一个 Agent 把活干明白，再考虑给它找同事。