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 时间成本的拆解先看时间数据。三类任务的平均端到端时间如下表所示任务类型单Agent耗时多Agent耗时倍数单点信息提取与改写8.2秒262.4秒32.0倍多步骤推理与计算21.5秒387.6秒18.0倍开放式方案设计34.8秒452.1秒13.0倍32倍这个数字来自第一类任务。为什么单点任务的时间膨胀最严重因为单点任务本身耗时短而多Agent的固定开销规划、通信、审核是相对恒定的。单Agent 8秒能做完的事多Agent光规划就要花几十秒审核再花几十秒通信再来回几轮时间就被拉爆了。多步骤推理任务的18倍膨胀稍微好一点因为单Agent本身耗时变长了固定开销的占比相对下降。开放式方案设计的13倍膨胀是最低的但绝对值仍然惊人——单Agent 35秒能出的方案多Agent要跑7分半。这里有个反直觉的点任务越简单多Agent的相对时间成本越高。因为简单任务的单Agent基线时间短而多Agent的固定开销不变比值自然就大了。很多人以为多Agent适合处理简单任务因为分工明确实际情况恰恰相反。3.2 Token消耗的拆解Token数据更值得细看。平均Token消耗如下任务类型单Agent Token多Agent Token倍数单点信息提取与改写1,24016,12013.0倍多步骤推理与计算3,58032,9409.2倍开放式方案设计6,72048,3847.2倍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的消耗不是1113而是可能到10以上。3.3 质量评分的真相如果多Agent用32倍时间和13倍Token换来了明显更好的质量那这笔账还能算得过来。但质量数据是这样的任务类型单Agent质量分多Agent质量分差异单点信息提取与改写4.34.1-0.2多步骤推理与计算3.63.80.2开放式方案设计3.43.70.3单点任务上多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 失败模式的速查表把上面这些失败模式整理成一张速查表方便对照排查失败模式典型表现根因缓解方向过度拆解子任务数量远超必要规划者Prompt鼓励细拆改为必要且充分上下文污染执行者引用错误信息中间产物堆叠上下文裁剪审核过度干预正确结果被改错审核标准不明确明确审核清单通信轮次膨胀轮次远超预期无硬上限设2轮上限角色职责重叠多个Agent做同一件事角色定义模糊明确职责边界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协作是个好概念但好概念不等于好方案更不等于适合你的方案。