最近在做一套内部评测我特意把同样的需求分别用单Agent和Multi-Agent Team各跑了一遍。结果出乎意料又在情理之中一组5个Agent协作完成的“轻量级数据整理任务”耗时是单个Agent直接处理的32倍Token消耗直接飙到13倍最后交上来的结果反而还出现了事实性错误。这个结果差点让我推翻自己的工程选型方向。不是标题党也不是测试环境出bug。“多智能体协作更强大”这个叙事确实很诱人但它隐含的成本和反效果被严重低估了。这篇不聊宏大理念就聊聊我这个反例是怎么产生的为什么会出现32倍时间和13倍Token这种“负优化”以及在实际项目里什么时候该用多Agent、什么时候千万别用怎么快速判断你的场景属于哪一种。1. 盲目堆Agent之前先看清“多Agent热”背后的认知陷阱1.1 为什么大家一窝蜂涌向Multi-Agent Team现在的技术社区和行业论坛里Multi-Agent几乎成了“智能”的代名词。哪个团队不说自己在做多Agent协作好像就显得技术栈不够前沿。这个趋势本身有合理性复杂任务确实可以拆解成多个子任务每个Agent专注一个环节并通过相互调用、结果传递来逼近全局目标。这个思路借鉴了人类团队分工协作的模式理论上无懈可击。但问题恰恰出在这个“理论上”。我见过不少团队把原本一个Agent就能做好的事强行拆成“规划Agent 执行Agent 审查Agent 汇总Agent 质检Agent”五个角色。理由是规划更专业、执行更纯粹、审查更客观。听起来分工明确实际跑起来却在疯狂烧Token和时间。我这次测试就是这个套路一个简单的数据清洗与格式转换任务硬是套了五层协作。核心认知陷阱在于我们混淆了两个完全不同的概念工具复杂度和任务复杂度。Multi-Agent Team是一套工具它解决的是任务复杂度——多个专业能力各司其职。但工具复杂度本身也会引入新的开销。当一个任务的复杂度根本不需要那么高的工具复杂度时多Agent就是在给系统强加熵增。1.2 分工协作的直觉在这里不成立人类团队协作是高效的那是建立在我们能够低成本共享语境、能够通过语气表情快速同步信息、能够容忍模糊沟通并自行补全的基础之上。大语言模型之间的通信完全不是这样。大模型Agent之间传递信息本质上是把上下文从一次推理中抽取出来序列化成文本注入到另一次推理的上下文窗口中。这个过程有几个硬成本序列化成本把结构化的数据、中间推理过程、工具调用结果转成自然语言这本身就要消耗Token。重复理解成本下一个Agent必须从头阅读并理解前一个Agent产生的全部输出而不是像人类那样“你大概说下就行我知道你什么意思”。全量重算成本自回归模型每次生成都要处理完整上下文。多轮协作下每一轮都在整个上下文累积之上做全量计算。所以“分工”在Agent世界里不是免费的午餐而是每一棒都要付费的接力赛。人类接力的损耗是运动员的体力消耗Agent接力的损耗是重新读完全部交底材料的算力和Token消耗。任务越简单接力损耗相对任务本身就越沉重。1.3 一个被我忽略了很久的朴素事实在跑崩这个测试之前我其实一直默认一个假设多个Agent一起工作至少不会比单个Agent差。这个假设毫无依据只是被“群体智慧”这个流行叙事带偏了。冷静下来想就很清楚如果任务上下文只有几千Token单个Agent一次推理就能cover全局为什么要把这几千Token复制粘贴五遍每个Agent都要把这几千Token重新读一遍然后再增加自己的输出Token。多Agent不但不能提升决策质量反而会因为“中间人解释”而丢失信息保真度。这就是我这次实测中“结果反而更差”的直接原因。2. 反例复盘我是怎么测出32倍时间和13倍Token的2.1 这次对比测试的方案设计为了让对比有说服力我特意选了一个业务上非常常见的轻量级任务给一份内部调研记录的原始文本做结构化整理提取关键字段、纠正明显错别字、按固定JSON格式输出未来打算做自动化入库。单Agent方案非常直接一个Agent系统提示词里写明输出格式要求调用一次模型完成整理直接输出JSON。Multi-Agent Team方案设计了五个角色分析Agent通读全文提炼要点输出一份要点清单。清洁Agent负责识别并修正错别字、明显的数据错误。结构化Agent将清洁结果映射到目标JSON结构。审查Agent检查JSON格式及字段完整性。汇总Agent整合所有中间结果输出最终交付物。每个Agent都用同一个基础模型同一个服务商、同一版本温度也保持一致排除模型差异的干扰。唯一变量就是“是否采用多Agent串联协作”。测试样本是5份相同类型的原始文本每份原文大概1200字左右。我取了5份结果的平均数作为对比基准。2.2 数据对比时间、Token、质量三重打击直接上数据。表格里是5份任务的平均表现指标单Agent直接处理5-Agent Team协作恶化倍数总耗时秒24.6787.3约32倍总Token消耗含输入输出8,720113,36013倍输出JSON准确性5/5 全部通过3/5 通过质量下降内容事实性错误0处2处劣化我没法在这里贴真实截图但所有日志我都留了可以说明数据来源。耗时是从第一条请求发出到最后一条响应完全结束的墙钟时间。Token数是调用接口返回的usage字段精确累计求和的。看到这个数据我第一反应是哪里有问题仔细查了调用链日志才发现时间主要消耗在Agent之间的串行等待上。五个Agent是链式调用关系分析Agent跑完清洁Agent才能开始。每一个都要重新读取前面所有Agent的完整输出。到了第五个汇总Agent时它的上下文里已经塞进了前四个Agent的全部产出其中大量是重复的原文摘录和中间推理。2.3 质量下降的直接证据比起时间和成本的爆炸质量下降更值得警惕。单Agent方案下5份样本全部输出了规范、准确的JSON。多Agent方案中有两份出现了字段信息篡改。具体原因是结构化Agent在把清洁Agent的文本映射到JSON时发现某个字段在原文中语义模糊于是它“脑补”了一个值。这个脑补值在审查Agent那里没有被识别为错误因为审查Agent只看了结构化Agent的输出没有回看原始文本。而汇总Agent只负责整合同样没有比对原文的权力。这就形成了一条“幻觉产生—幻觉传播—幻觉固化”的链路。单个Agent面对模糊信息时更倾向于保留原文表述或明确要求补充信息但多Agent链路中每个中间环节都想“出活”都倾向于推进流程而不是停下来澄清反而把模糊性脑补包装成了确定结论。2.4 为什么串行链路是性能杀手很多人以为多Agent就是并行执行但现实中绝大多数Multi-Agent Team是串行管道A的输出是B的输入B的输出是C的输入。这导致两个直接后果第一整体延迟等于各环节延迟之和。每个环节的延迟又和它的输入上下文长度正相关。越往后的Agent输入上下文越臃肿推理速度越慢等待时间越长。这个效应是滚雪球式的。第二早期环节的错误会在后期环节被放大。早期Agent的一个小幻觉后期Agent会当作既定事实继续加工。人类团队中后期的执行者如果发现上游有问题可以及时反馈但Agent链路中没有这种即时反馈通道错误只能带着走。3. 深挖技术根源为什么多Agent又慢又贵还更差3.1 上下文重复计费Token开销的根本来源先聊聊Token消耗为什么会达到13倍。很多做工程的朋友对Token消耗的理解还停留在“输入多少字、输出多少字”但这个理解漏掉了大模型推理的核心机制自回归生成中每个输出Token的生成都需要把前文全部“重新过一遍”。更准确地说在目前主流的Transformer架构下模型生成第N个Token时要对前置N-1个Token都做一次注意力计算。虽然工程上有KV Cache的优化手段但对于一个全新序列Agent之间传递的文本会形成新的序列前缀缓存命中率很低。所以Token消耗的膨胀不只是“字多”而是字多引发的注意力计算叠加。上下文越长的Agent其后续每个Token的生成代价越高。多Agent链路中每个Agent的输入都比前一个更长这就导致越到后面越贵。实操中可以通过一个简单公式估算成本增幅假设每个Agent的输出长度为Ln个Agent串联最后一个Agent的输入上下文长度为nL忽略重叠部分与系统提示词而单个Agent的上下文基本就是任务原文本长度S。当n5、L大于S时最后那个Agent的上下文就是5倍于原文本的长度。每一步的KV计算量都在这个基础上累积Token总量呈平方级增长趋势。这就是13倍Token的实际来源。3.2 “每人都读全文”带来的隐性重复劳动这个现象我给它起了个名字全员通读效应。人类团队开会时如果所有人都需要完整阅读一份100页的报告才能发表意见会议效率一定惨不忍睹。好的协作方式应该是一个人通读报告并提炼摘要其他人只读摘要。但Agent协作恰恰相反因为每个Agent要做“全局正确”的判断往往会把全文或全部中间结果塞进自己的上下文里。在我这套五Agent链路中分析Agent先通读原文输出要点清洁Agent又读了一遍原文要点结构化Agent再读原文要点清洁结果审查Agent则读原文所有中间产出汇总Agent干脆把前面的全部输出又融合了一遍。这就像五个人各自从头到尾读了一整份报告每个人都做了完整的通读劳动。这种冗余完全可以通过设计规避比如固定上下文传递策略第一个Agent只传摘要给后续环节而不是把全文都带上。但多数开源框架和快速实现的Demo默认就是累加式传递结果就是Token爆炸。3.3 注意力稀释长链路协作的信息衰减比钱更值钱的是模型输出质量。多Agent链式协作的结果往往不如单Agent核心原因之一是长上下文引入的注意力稀释。当上下文塞满了多个Agent的中间产物真正关键的原始信息占比会被严重压缩。模型注意力在大量中间推理文字之间分散对原始事实的关注度反而降低。这个现象在学术界和工程界都有讨论模型在长上下文中更容易忽略早期或中部的细节。但我这个案例里还有个隐藏因素中间推理文字往往比原始文本更有“表面说服力”。结构化Agent会把模糊信息包装成确定结论审查Agent面对这些“看起来很专业”的中间产物时更倾向于通过而不是质疑。于是“幻觉经过层层包装后反而被当作高置信信息”。3.4 评估闭环缺失没有“人”在关键节点把关人类协作能够纠错靠的是每个环节都清楚自己的验收标准并有权对上游说不。但我在设计的这个Multi-Agent Team里每个Agent都被设定成“执行者”而不是“质疑者”。审查Agent看似在把关但实际上它审查的是结构完整性JSON格式、字段齐全而不是内容真实性是否忠于原文。两者之间有巨大的真空地带。这就是我认为多Agent系统设计里最危险的陷阱看似有审查环节实则审查逻辑只是验证格式规范根本没有建立内容一致性校验。要真做内容级校验审查Agent必须重新通读原文并交叉比对这又把Token消耗推高一个量级而且审查Agent本身也可能出现幻觉。所以很多团队的多Agent协作流程看上去层层把关实际上每一层都在做自己闭眼想象里的“正确”没有人对最终结果与原始输入之间的一致性负责。这是结果反而不如单Agent的结构性原因。3.5 反向对比单Agent为什么在这种任务上更有优势回到测试结果单Agent仅凭一次推理就完成了清洗、提取、格式化全过程。原因很简单这个任务的全部信息都在一份不超过两三千Token的文本里单次推理的上下文窗口完全可以容纳模型能同时看到输入和输出格式要求一步到位完成映射。单Agent的优势在这个场景下体现为信息保真度高、无中间解释损耗、决策路径短。它不需要把原文提炼成摘要再还原成字段值而是直接完成从原始文本到目标结构的转换。任何两次转换之间的信息损失都被避免了。这也解释了为什么我推荐先用单Agent把任务做到极限再评估是否真的细节多到需要多Agent切分。大多数任务数据清洗、信息提取、单文档总结、代码单文件改写、文案改写实际上都是单上下文可覆盖的多Agent属于纯浪费。4. 不是一棍子打死什么场景下Multi-Agent Team才值得上4.1 需要用多Agent的两个必要非充分条件虽然我这次踩了大坑但我依然认为Multi-Agent Team在某些场景下是正确选择。关键是找到它真正胜负手所在的场景。第一任务必须强并行。也就是子任务之间几乎没有顺序依赖可以同时推进。比如市场分析报告里的多个独立章节、代码重构中多个互不依赖的模块分析、多来源资料各自独立研读。这种场景下多Agent的耗时不是串联相加而是基本等于单个最慢环节的耗时时间账才划算。第二每个子任务需要配置不同的工具链或不同的知识侧重。比如一个Agent专门调数据库工具查库存另一个Agent专门调天气接口再有Agent专门处理图像输入。这些能力如果堆在单Agent的系统提示词里会急剧膨胀上下文拖慢每次推理。拆成多个各带专有工具的Agent反而让每个Agent的上下文更精简。4.2 我后来验证过的相对理想的多Agent形态在吃了大亏之后我重新设计了一个多Agent方案跑了一个跨模块的合规审查任务效果还算满意。但这个设计跟最开始的五层串行链路有本质区别每个Agent拿到的是同一个原始材料的不同切片而不是前一个Agent的输出。各Agent之间没有调用关系全部独立执行然后由一个汇总器合并结果。汇总器只做“拼接”和“定位冲突”不做内容二次生成。这个形态下Token消耗约等于N个Agent各自读取局部上下文 汇总器读取全部结果。整体Token消耗大概是单Agent处理全部内容的2到3倍而不是13倍。时间消耗接近单个最慢Agent。质量因为有局部专注可能在细分分析上更深但汇总阶段仍然需要人工检查冲突点。4.3 边界条件什么时候千万别用多Agent以下情况请尽量别上Multi-Agent Team除非你有专门的处理机制任务总上下文不超过模型单次上下文窗口的50%。这种任务单Agent绝对够用多Agent纯属给自己找麻烦。子任务之间有强前后依赖。比如上一步的结论会直接影响下一步的输入口径串行链路会把错误和延迟都放得很大。最终结果要求忠实于原始输入。任何中间提取和再生成环节都是质量风险点宁可单Agent一步到位也别拆出多层解释。对延迟敏感。多Agent串行的墙钟时间普遍是单Agent的数倍到数十倍这个物理事实绕不开。5. 实操建议优化Multi-Agent系统时必须盯住的六个关键点5.1 先算Token账再动手写代码任何Multi-Agent方案投入开发前先按下述公式估算Token。设原任务输入为S模型单次最大输出为O每个Agent的输入上下文为Ci输出上下文为Oi。串联链路下总Token消耗约等于TotalTokens ≈ Σ(Ci Oi)其中对于链式协作Ci S Σ(Oj)j i。也就是后面的Agent的输入包含之前所有Agent的输出。当系统有n个环节且每个环节的输出约为O那么最后一个Agent的输入就是S (n-1)O。假设S2000O1500n5TotalTokens ≈ 2000 (20001500) (20003000) (20004500) (20006000) 各输出光输入就要37750 Token而单Agent只需要2000 Token输入。这还没算输出Token本身就接近7500。这个估算还没用五分钟我就明白为什么第一版会跑到13倍Token了。5.2 动手审计上下文传递策略多Agent系统最常见的膨胀点就是无脑把所有中间结果都传给下游。需要立即检查你的Agent调用工具或代码里传递参数是不是每次都把完整上下文塞进去了。合理的做法是给每个Agent定义明确的输入摘要接口上游Agent只输出“下游需要的结构化数据”不输出任何无关的分析过程。如果下游确实需要参考某些细节再单独提供局部引用而不是整段搬运。这个习惯能直接把Token消耗拉下一大截。5.3 给链路加“事实锚点”我这次踩坑最深的是“结构化Agent脑补数据”。要防住这个问题在所有Agent的系统提示里明确加一条“不得编造任何原文中不存在的信息如原始信息缺失或模糊必须输出null并备注原因。”并且要求每个Agent在输出最终结果时附一行“数据来源索引”标明自己输出的某个字段对应原始文本的哪一行或哪个段落描述。这样即使后续环节做交叉校验也有据可查。5.4 能用Router模式解决的就别上多Agent有一种比多Agent轻量得多的模式Router路由分发。一个主控Agent负责理解用户需求然后把任务路由到专门工具或专用Prompt去执行执行结果直接返回主控中间没有多余Agent的“解读”。Router本质上仍是单Agent的主控逻辑只是它调用了多个工具或子流程。因为没有“多个Agent之间的互相传递上下文”Token开销和错误传播都被限制在可控范围。我后来在好几个项目里都把原本的Multi-Agent方案改成了Router方案效果出奇好。5.5 每一次变更都要做A/B对比不要凭感觉判断“加上这个环节更好”。我在多Agent优化过程中每加一个角色、每改一次传递策略都会跑同样的5个测试用例对比Token、耗时、结果一致性三个指标。哪个环节是正收益、哪个环节是纯负担数据一眼就知道。这里给一个实测有效的判断标准如果新增环节让总耗时增加超过自己可控预算的20%或者Token增长超过2倍但正确率提升不到2个百分点这个环节就该砍掉。审视一下你系统里每一个“审查Agent”多数情况下它们只是在重复消费算力。5.6 日志和观测系统必须穿透到Agent内部没有观测就没有优化。我在这次测试里就是依靠完整的日志记录才看清了时间消耗在每个Agent上的分布。具体记录项应包括每个Agent的输入Token数、输出Token数、墙钟时间、调用失败或重试次数、最终输出内容与原文的一致性抽检结果。如果你用的是开源框架直接在配置文件里勾选Agent数量一定要确认该框架是否暴露了Token使用明细。有的框架只显示总Token消耗不显示每个环节的消耗那你就拿不到优化依据。我现在用的方案会自己加一层日志装饰器在每个模型调用前后自动打印usage字段累积起来做结构化分析。6. 经验复盘从这次反例里总结出的选型决策清单6.1 深入思考后我个人的选型决策路径这条路径我建议你在规划任何Agent系统时先过一遍把这个任务用单Agent清晰Prompt必要工具先跑通拿到性能基底数据。评估这个任务是否满足两个条件强并行、子任务需要异构工具链。不满足就用单Agent方案不要为了架构好看而加复杂度。如果必须多Agent优先选“各读各的原始切片统一汇总”的形态不选串行传递中间输出的形态。每个Agent的输出都要求带来源索引并设置不一致标记机制。上线前跑至少5组代表性样本对比A/B数据把Token、耗时、正确率记录下来存档。6.2 那些没人告诉你但很重要的工程实践细节几个小的工程细节算是这次实践里挫出来的经验。一个Agent内部也可以有“多步思考”。比如让同一个Agent在回答前先列出“提取字段—对照原文—检查格式—输出结果”四步它其实能做得很好。你已经拥有的能力别急着拆给别人。异步并行要搭配超时控制。如果你确实用了并行多Agent每个分支必须设置超时和降级预案。一个Agent卡住可能导致整个系统等待比串行还可怕。结果一致性校验优先级永远高于流程完整性。我见过很多团队花了大力气让流程跑通Agent之间接得严丝合缝却忘了最终产物是否准确。这是本末倒置。多Agent只是手段准确性才是目的。校验最终输出时一定要追溯到最早的原始输入而不是只看流程是否走通。6.3 给正在做技术选型的朋友的一段话技术圈最贵的成本是跟风。多Agent协作本身是个好东西但它的适用面比我们想象的要窄很多。用不好它就会像我这次一样得到32倍时间和13倍Token这种反向指标。如果读到这里你已经心里发虚赶紧用本文的方法算算自己项目的Token账跑一组A/B对比数据会告诉你该不该用多Agent、该在哪一层收敛复杂度。最后再分享一个小技巧我现在每评估一个Agent架构都会在会议室白板上先画一条“Token流向图”标出每个环节的输入从哪里来、输出到哪里去。只要看到同一条信息被重复画进三个以上环节的输入框立刻就能意识到这里有隐患。这个习惯帮我避掉了很多伪需求。希望你也试试这个方法。