多智能体协作真实成本：32倍时间与13倍Token消耗的对照实验

1. 多智能体协作的真实成本账：从一次翻车实验说起

多智能体协作这两年热度一直居高不下，各种框架层出不穷，演示视频里一群Agent你一言我一语，分工明确、配合默契，看起来像是把一支高效团队塞进了服务器。但我自己带着团队做了一轮对照实验之后，得出的结论相当反直觉：在相当多的任务场景下，多智能体协作消耗的时间是单Agent的32倍，Token消耗是13倍，而最终产出质量不但没有提升，反而在某些维度上出现了明显退化。

这个结论不是拍脑袋得出来的。我们设计了一组可复现的对照实验，用同一个基座模型、同一套任务集、同一套评分标准，分别跑单Agent直出和多Agent协作两条链路，记录时间、Token、质量三个维度的数据。跑完之后我把数据摊在桌上看了很久，心情比较复杂——因为过去大半年我们在这个方向上投入了不少精力，而数据告诉我们，至少在当前的技术条件下，多智能体协作的收益被严重高估了。

这篇文章适合两类人看。一类是正在考虑要不要上多Agent架构的开发者，你可能被各种演示效果吸引，但还没算过真实的成本账；另一类是已经在多Agent上踩过坑、想搞清楚问题到底出在哪里的同行。我会把实验设计、数据、失败模式、以及我后来总结出来的适用边界都摊开讲，不藏私，也不美化。核心关键词就三个：多智能体协作、时间成本、Token消耗，全文围绕这三个词展开，但不会只停留在概念层面，而是落到具体的数字和可复现的操作上。

先说结论的方向：多Agent不是不能用，而是不能滥用。它有一套非常窄的适用条件，条件不满足的时候，强行上多Agent就是在用32倍的时间换一个更差的结果。下面我把这套逻辑拆开讲。

2. 实验设计与对照方法：怎么把账算清楚

2.1 任务集的选择逻辑

要比较单Agent和多Agent，任务集的选择是第一个关键决策。如果选的任务本身就需要多角色协作，那多Agent赢是理所当然的，这种对比没有意义。所以我刻意选了三类任务，覆盖从"完全不需要协作"到"理论上需要协作"的整个光谱。

第一类是单点信息提取与改写，比如给一段结构化文本，要求提取指定字段并按要求重新组织输出。这类任务逻辑链短、不需要多轮推理，理论上单Agent直出就够了。

第二类是多步骤推理与计算，比如给一组带约束条件的排班需求，要求输出满足所有约束的排班表。这类任务需要多步推理，中间步骤容易出错，理论上多Agent可以通过分工降低单点压力。

第三类是开放式方案设计，比如给定一个业务场景，要求输出一套完整的技术方案，包含架构、选型、风险点。这类任务没有唯一正确答案，评分主观性较强，理论上多Agent可以通过多视角讨论提升方案质量。

三类任务各准备20个样本，共60个样本。每个样本都用单Agent和多Agent各跑一遍，共120次运行。为了减少随机性，每个配置跑3次取中位数。

2.2 单Agent基线的配置

单Agent基线用的是一个通用对话模型，温度设为0.3，最大输出长度设为4096 Token。Prompt采用标准的"角色+任务+约束+输出格式"四段式结构，没有做任何特殊优化。这么设计的原因是：如果单Agent基线被刻意削弱，那对比就不公平了。我要的是一个"正常水平"的单Agent，而不是一个"被故意做差"的单Agent。

单Agent的执行流程很简单：接收任务描述，直接生成结果，结束。没有中间步骤，没有自我反思，没有工具调用。这是最朴素的基线，也是大多数开发者实际会用的方式。

2.3 多Agent协作链路的配置

多Agent这边我用的是一个典型的三角色架构：规划者、执行者、审核者。规划者负责拆解任务、分配子任务；执行者负责具体执行；审核者负责检查执行结果并给出修改意见。三个角色之间通过消息传递协作，最多允许3轮审核循环。

这个架构不是我随便搭的，它是目前市面上大多数多Agent框架的默认范式。我选它作为代表，是因为它最能反映"主流多Agent实践"的真实表现。如果我用一个精心调优的架构去对比一个粗糙的单Agent，那结论就没有参考价值了。

每个角色的Prompt都做了针对性设计，规划者有任务拆解模板，执行者有执行规范，审核者有检查清单。三个角色共用同一个基座模型，没有用不同模型来制造差异。

2.4 度量指标的定义

时间成本的定义是端到端墙钟时间，从任务输入到最终结果输出，包含所有Agent之间的通信开销。Token消耗的定义是所有Agent的输入Token加输出Token的总和，不是单个Agent的消耗。质量评分采用三维度打分：准确性、完整性、可用性，每个维度1到5分，由两个独立评分者盲评，取平均分。

这里有个细节要说明：多Agent的Token消耗之所以要算总和，是因为在实际部署中，每个Agent的调用都是要花钱的。规划者消耗的Token、执行者消耗的Token、审核者消耗的Token，加起来才是真实成本。只算某一个Agent的消耗，是在自欺欺人。

提示：做这类对照实验时，一定要把通信开销算进去。多Agent的通信开销往往比执行开销还大，这是最容易被忽略的成本项。

3. 数据摊开看：32倍时间和13倍Token是怎么来的

3.1 时间成本的拆解

先看时间数据。三类任务的平均端到端时间如下表所示：

32倍这个数字来自第一类任务。为什么单点任务的时间膨胀最严重？因为单点任务本身耗时短，而多Agent的固定开销（规划、通信、审核）是相对恒定的。单Agent 8秒能做完的事，多Agent光规划就要花几十秒，审核再花几十秒，通信再来回几轮，时间就被拉爆了。

多步骤推理任务的18倍膨胀稍微好一点，因为单Agent本身耗时变长了，固定开销的占比相对下降。开放式方案设计的13倍膨胀是最低的，但绝对值仍然惊人——单Agent 35秒能出的方案，多Agent要跑7分半。

这里有个反直觉的点：任务越简单，多Agent的相对时间成本越高。因为简单任务的单Agent基线时间短，而多Agent的固定开销不变，比值自然就大了。很多人以为多Agent适合处理简单任务因为"分工明确"，实际情况恰恰相反。

3.2 Token消耗的拆解

Token数据更值得细看。平均Token消耗如下：

13倍这个数字同样来自第一类任务。Token膨胀的来源有三个：规划者的拆解输出、Agent之间的消息传递、审核者的反馈与修改。其中消息传递是大头，因为每一轮协作都要把上下文重新传一遍，上下文越长，重复传递的浪费越大。

我拆过一次单点任务的Token明细：规划者输入320 Token、输出480 Token；执行者输入1,200 Token（包含规划者的输出）、输出560 Token；审核者输入2,400 Token（包含前两者的输出）、输出380 Token；然后审核不通过，再来一轮，又重复一遍。三轮下来，Token就堆到了16,000以上。

注意：多Agent的Token消耗是超线性增长的。每增加一个Agent，不仅增加该Agent自身的消耗，还增加所有下游Agent的上下文长度。三个Agent的消耗不是1+1+1=3，而是可能到10以上。

3.3 质量评分的真相

如果多Agent用32倍时间和13倍Token换来了明显更好的质量，那这笔账还能算得过来。但质量数据是这样的：

单点任务上，多Agent的质量反而下降了0.2分。我仔细看了失败案例，主要问题是审核者过度修改，把原本正确的结果改错了。审核者为了"体现价值"，倾向于挑刺，而有些挑刺是无效的，改完之后反而引入了新错误。

多步骤推理和开放式方案设计上，多Agent有微弱优势，分别是+0.2和+0.3。但这个优势在统计上并不显著，而且考虑到32倍的时间和13倍的Token，这个微弱优势的性价比极低。

3.4 成本效益的临界点

把时间和质量放在一起看，可以算出一个粗略的"效益比"：质量提升幅度除以成本增加倍数。多步骤推理任务的效益比是0.2除以18，约等于0.011；开放式方案设计是0.3除以13，约等于0.023。这两个数字都低得可怜。

换句话说，你多花13到18倍的成本，只换来0.2到0.3分的质量提升，而且这个提升还不一定稳定。从工程角度看，这个投入产出比是不合格的。除非任务本身对质量极度敏感、且成本完全不敏感，否则没有理由上多Agent。

那有没有临界点？我的经验是：当单Agent的质量分低于3.0，且失败模式是"单点能力不足"而非"任务理解偏差"时，多Agent才可能有正收益。因为这种情况下，多Agent的分工确实能弥补单点能力的不足。但如果单Agent质量分已经在3.5以上，多Agent的边际收益就非常有限了。

4. 失败模式实录：多Agent到底在哪里翻车

4.1 规划者的拆解偏差

规划者是整条链路的第一个环节，它的输出质量直接决定后续所有环节的上限。我观察到的最典型问题是过度拆解：规划者把一个本来可以一步完成的任务拆成五六个子任务，每个子任务都要单独调用执行者，调用次数上去了，时间和Token自然就上去了。

比如一个"提取合同中的甲方名称和签约日期"的任务，规划者拆成了：识别合同类型、定位甲方信息段落、提取甲方名称、定位日期段落、提取签约日期、格式化输出。六个子任务，每个都要走一遍执行者调用。而单Agent直接一步就能输出结果。

过度拆解的根源是规划者的Prompt里写了"请将任务拆解为尽可能细的子任务"。这句话是我自己写的，本意是让拆解更充分，结果适得其反。后来我把"尽可能细"改成了"拆解为必要且充分的子任务，能一步完成的不要拆成两步"，过度拆解的问题才缓解。

4.2 执行者的上下文污染

执行者在多Agent链路里是"干活的人"，但它接收到的上下文往往包含大量无关信息。规划者的拆解说明、前序子任务的输出、审核者的历史反馈，全都堆在上下文里。上下文越长，执行者越容易"跑偏"。

我遇到过一个典型案例：执行者被要求提取一个日期，但上下文里前面几个子任务的输出里也包含日期，执行者把前面子任务的日期当成了目标日期，提取错了。这个错误单Agent不会犯，因为单Agent的上下文里只有原始任务描述，没有中间产物干扰。

上下文污染是多Agent的固有缺陷。只要Agent之间有消息传递，就必然有上下文堆叠，就必然有污染风险。缓解办法是给每个Agent做上下文裁剪，只传必要信息，但这又增加了工程复杂度。

4.3 审核者的过度干预

审核者这个角色是最容易"帮倒忙"的。它的职责是检查执行结果，但检查标准如果不够明确，审核者就会基于自己的理解去挑刺。有些挑刺是合理的，有些是无效的，还有些是把对的改成错的。

我统计了一下单点任务上的审核干预情况：审核者提出修改意见的比例是68%，其中有效修改占32%，无效修改占48%，有害修改占20%。也就是说，审核者的干预有三分之二是不产生正收益的，五分之一是产生负收益的。

有害修改的典型模式是：执行者输出"2024年3月15日"，审核者认为"日期格式应该统一为YYYY-MM-DD"，改成"2024-03-15"。这个修改本身没错，但原始任务并没有要求特定格式，审核者是在自行加戏。更糟的是，有些审核者会把正确的数值改错，比如把"15日"改成"16日"，理由是"看起来更合理"。

4.4 通信轮次的指数膨胀

多Agent协作的通信轮次不是线性增长的。三个Agent两两通信，理论上有6条通信链路。如果允许审核循环，每循环一轮，通信次数就翻倍。我设的最大审核轮次是3轮，实际跑下来，平均通信轮次是4.7轮，最复杂的案例跑了9轮。

每一轮通信都要重新传递上下文，Token消耗随之膨胀。而且通信轮次越多，累积的上下文越长，后面轮次的单次通信成本越高。这是一个正反馈循环：轮次多导致上下文长，上下文长导致单次成本高，单次成本高导致总成本爆炸。

提示：如果你非要用多Agent，一定要给通信轮次设硬上限。我的经验是最多2轮审核，超过2轮之后边际收益基本为零，纯粹是在烧钱。

4.5 失败模式的速查表

把上面这些失败模式整理成一张速查表，方便对照排查：

5. 什么情况下多Agent才真正值得用

5.1 适用条件的三个硬指标

踩完这些坑之后，我总结出多Agent真正适用的三个硬指标，必须同时满足：

第一，单Agent的质量分低于3.0，且失败原因是能力不足而非理解偏差。如果单Agent是因为没理解任务而失败，多Agent也救不了，因为规划者同样可能理解错。只有当单Agent理解了任务但能力不够时，多Agent的分工才有意义。

第二，任务可以自然分解为低耦合的子任务。子任务之间的依赖越少，多Agent的通信开销越低。如果子任务之间高度耦合，每个子任务都要依赖前序结果，那多Agent的通信轮次会爆炸。

第三，成本不敏感或质量极度敏感。多Agent的成本是单Agent的10倍以上，这个成本必须由质量收益来覆盖。如果任务本身对成本敏感，或者质量要求没那么高，多Agent就不划算。

5.2 一个正收益的案例

我确实遇到过多Agent正收益的案例，是一个多约束排班问题。单Agent在这个任务上的质量分只有2.4，主要问题是约束条件太多，单Agent顾此失彼，满足了A约束就违反B约束。多Agent把约束分成三组，每组由一个执行者负责，最后审核者做交叉检查。质量分提升到了3.9，提升幅度1.5分，成本增加约11倍。

这个案例满足三个硬指标：单Agent质量低（2.4）、任务可分解（约束分组）、质量敏感（排班错误代价高）。所以多Agent在这里是划算的。但要注意，这个案例里我做了大量定制化工作，包括约束分组策略、交叉检查清单、冲突消解规则，不是开箱即用的默认配置。

5.3 一个反例的复盘

反过来，我见过一个团队在文案改写任务上上多Agent，结果惨不忍睹。文案改写本身单Agent质量分就有4.2，多Agent跑完变成4.0，时间从12秒变成340秒，Token从1,800变成21,000。这个团队的问题在于，他们看到多Agent的演示效果就上了，没有做对照实验，也没有算成本账。

复盘下来，文案改写任务不满足任何一个硬指标：单Agent质量高（4.2）、任务不可自然分解（改写是整体性的）、成本敏感（文案量大）。三个条件全不满足，多Agent必然是负收益。

5.4 决策流程图（文字版）

如果你不想记那么多条件，可以走这个简化决策流程：

第一步，先跑单Agent基线，记录质量分。第二步，如果质量分高于3.5，直接用单Agent，不要考虑多Agent。第三步，如果质量分低于3.0，检查失败原因，如果是理解偏差，优化Prompt而不是上多Agent。第四步，如果是能力不足，检查任务是否可自然分解，不可分解就放弃多Agent。第五步，如果可分解，做小规模对照实验，确认质量提升幅度是否覆盖成本增加。第六步，只有确认正收益，才上多Agent，并且设硬性轮次上限。

这个流程看起来繁琐，但比盲目上多Agent然后翻车要省事得多。我自己的团队现在就是按这个流程走的，新任务先跑单Agent基线，基线不达标才考虑多Agent，而且必须做对照实验才能上线。

6. 如果非要用多Agent，这几条经验能帮你少踩坑

6.1 角色数量控制在三个以内

角色越多，通信链路越多，Token消耗增长越快。三个角色（规划、执行、审核）是性价比最高的配置。超过三个角色，边际收益急剧下降，而成本线性上升。我试过五个角色的配置，质量分比三个角色只高了0.1，但Token消耗翻了一倍多。

如果任务确实复杂，宁可让一个角色承担多个职责，也不要增加角色数量。比如让执行者同时承担部分审核职责，比单独设一个审核者要划算。

6.2 给每个角色写死输出格式

角色之间的消息传递如果格式不固定，解析成本会很高，而且容易出错。我的做法是给每个角色的输出定义严格的JSON Schema，规划者输出子任务列表，执行者输出执行结果，审核者输出审核意见。格式固定之后，解析逻辑简单了，上下文长度也可控了。

{ "role": "planner", "subtasks": [ {"id": 1, "desc": "提取甲方名称", "depends_on": []}, {"id": 2, "desc": "提取签约日期", "depends_on": []} ], "reasoning": "任务可并行拆解为两个独立子任务" }

这个Schema看起来简单，但它把规划者的输出限制在了可控范围内，避免了自由文本带来的解析歧义和上下文膨胀。

6.3 上下文裁剪要主动做

不要指望模型自己忽略无关上下文，它做不到。每个Agent调用前，都要主动裁剪上下文，只传必要信息。我的做法是维护一个"上下文白名单"，每个Agent只接收白名单内的字段，白名单外的字段一律不传。

比如执行者只需要原始任务描述和分配给它的子任务，不需要知道其他子任务的执行结果，也不需要知道审核者的历史反馈。把这些信息裁掉之后，执行者的上下文长度能减少60%以上，Token消耗随之下降。

6.4 审核轮次设硬上限

审核轮次是Token消耗的最大变量。我设的是2轮，超过2轮直接强制结束，输出当前结果。实测下来，第3轮审核的边际收益基本为零，有时候还会因为过度修改导致质量下降。

设硬上限的另一个好处是防止死循环。我遇到过审核者和执行者来回扯皮的情况，审核者说改，执行者改了，审核者又说改回去，来回好几轮。有了硬上限，这种情况最多持续2轮就被强制终止。

6.5 监控每个Agent的Token消耗

多Agent的Token消耗是分散的，如果不做监控，很容易在某个Agent上出现异常消耗。我的做法是给每个Agent的调用打点，记录输入Token、输出Token、调用次数，汇总成日报。一旦某个Agent的消耗异常，能快速定位。

监控数据还帮我发现了一个反直觉的现象：规划者的Token消耗往往不是最高的，审核者才是。因为审核者要接收前面所有Agent的输出，上下文最长，单次调用成本最高。优化审核者的上下文，是降低整体Token消耗的关键。

6.6 准备降级方案

多Agent链路比单Agent链路长，出错的概率也更高。任何一个环节出错，整条链路都可能失败。所以一定要准备降级方案：当多Agent链路失败或超时时，自动降级到单Agent直出。

降级方案的价值在于兜底。多Agent链路跑成功了固然好，跑失败了也不至于让用户干等。我的降级触发条件是：链路超时超过60秒，或者任意Agent连续报错3次，自动降级到单Agent。

提示：降级方案要在上线前就做好，不要等出了问题再补。多Agent链路的故障率比单Agent高一个数量级，没有降级方案就是在裸奔。

7. 我个人的几点体会

做这轮实验之前，我对多Agent是抱有期待的。毕竟从直觉上讲，多个Agent分工协作应该比单个Agent单打独斗更强。但数据打脸打得很彻底：在大多数任务上，多Agent的收益远远覆盖不了它的成本。

我现在对多Agent的态度是：它是一个特定场景下的专用工具，不是一个通用架构。就像你不会用起重机去拧螺丝一样，你也不应该用多Agent去处理单Agent就能做好的任务。判断标准很简单：先跑单Agent基线，基线不达标再考虑多Agent，而且必须做对照实验确认正收益。

还有一个体会是关于"演示效果"的。网上很多多Agent的演示看起来很惊艳，但演示往往是精心挑选的案例，成本数据不公开，失败案例不展示。如果你被演示效果吸引想上多Agent，建议先自己跑一轮对照实验，把时间和Token数据记录下来，再决定要不要上。数据不会骗人，演示会。

最后分享一个我踩过的坑：我曾经在一个项目里为了"技术先进性"上了多Agent，结果项目延期了两周，成本超预算三倍，最终质量还不如单Agent版本。后来我把多Agent链路拆掉，换回单Agent，项目一周就上线了。这个教训让我明白，技术选型要看实际收益，不要看概念热度。多Agent协作是个好概念，但好概念不等于好方案，更不等于适合你的方案。