上周还在帮一个团队看他们的Agent编排设计。需求本身不复杂从不同渠道收集用户反馈归类、提炼共性、再生成一份周报。但架构上愣是拆了五个Agent——采集Agent、清洗Agent、分类Agent、总结Agent、报告Agent。我问为什么要拆这么多对方回了一句“现在不都这样吗复杂任务就得靠多Agent才能搞定。”这个回答我太熟了。过去大半年几乎每次聊到Agent应用最后都会落到同一个问题上要不要再加一个Agent。也正因为大家都在用“加Agent”来解决问题所以当某家头部科技公司的AI工程团队放出一份实测总结——用180种配置系统性地对比了多Agent系统的效果——结论却是“加Agent不一定有用”的时候社区里一下就炸开了锅。这份实验我断断续续研究了好几遍又把里面的结论拿到我自己项目里做了验证。今天就把里头的门道、跟实际项目的印证、还有过程中踩过的坑一起写出来。1. 为什么“加Agent”成了默认动作我拆了三个思维定势这个问题背后其实是三股非常常见的直觉在推动。它们单独看都有道理组合在一起却很容易把架构带偏。1.1 链路越长越像“深度思考”很多人在设计Agent系统时会有一种感觉如果让一个Agent从头做到尾那跟直接问一次大模型有什么区别只有派多个Agent接力每个负责一小步才能算真正的“应用架构”。这个想法本身不坏但它混淆了“分工”和“深度推理”。单Agent连续处理一个任务时相关信息都挤在同一个上下文窗口里模型可以跨段落建立联系后面写到结论时会自然回看前面的中间结果。但一旦拆给多个Agent前一个Agent的输出就变成后一个Agent的Prompt中间一旦发生信息丢失、语气偏移、格式错乱后面全都跟着被带偏。实验报告中有一个非常稳的现象在绝大多数简单和中等复杂度的任务上单Agent的表现和3个Agent的表现几乎持平甚至单Agent略优。这背后的原因并不玄学——大模型本身的上下文注意力已经足够支撑连续推理多Agent不但没有增加“思考深度”反而引入了传递损耗。这种损耗特别隐蔽。只看最终正确率单Agent和3个Agent可能差不多但细看输出内容会发现链式传递后丢失了不少细节比如原始数值的精度、需求里某个限定条件、之前已经确定过的口径。所以“链路长思考深”这个等式在Agent系统里并不成立。1.2 分工一定会带来专业度提升这也是一个常见误会。分工能提升专业度的前提是每个环节存在足够强的领域隔离。比如“写代码”和“写测试用例”可以拆开但拆开之后两个Agent都需要把代码上下文各自重读一遍不共享就重复读共享的话“分工”的价值又被打折。实验中有一组对照特别典型同样是多步骤数据分析任务把“数据清洗”和“建模分析”拆给两个Agent效果远不如一个Agent连续完成。因为清洗阶段的字段口径、缺失值处理方式、临时改动的意图这些信息很难用几行结构化字段完整传递。第二个Agent拿到的只是一个“已经清洗好的表”它不知道哪些列被合并过、哪些异常值被删掉了后续分析很容易基于不完整的认知做出偏颇结论。我自己做项目时也发现凡是子任务共享大量前置语境的拆开几乎都是负收益。真正的专业分工必须建立在“上下游只需要结构化交接不需要理解对方为什么这么干”的前提下。如果你的需求里没有这种清晰的专业边界拆出来的Agent只是在给系统加噪音。1.3 Agent数量代表系统能力上限“不够就加机器”这是系统架构时代留下的条件反射。但Agent不是机器多加一个Agent不只是多一份算力更是多了一个可能错误地改写信息的节点。实验数据里有个值得记住的规律Agent数量从1到3时成本大约上升2到3倍任务成功率却只提升几个百分点从3再往上加成本继续递增成功率在不少任务上反而回落。因为每多一个Agent整个链路的失败概率就多乘一次。假设每个Agent的成功率都是95%一条链路传5次最终成功率只有77%左右——这个账一算就明白了。真正决定系统能力的不是Agent数量而是任务结构是否天然支持拆分。如果任务天生适合并行采集、天生需要多个专业工具接力那么多Agent是合理选择如果只是为了看起来更“智能”那就是在给系统叠包袱。2. 那场180种配置的实测到底在跑什么实验设计拆解既然要讨论“加Agent有没有用”就不能只看结论得先搞明白实验是怎么设计的。那次实验最值得学习的地方是它没有把“Agent数量”当唯一变量去跑曲线而是把它放进了组合矩阵。2.1 核心变量数量、拓扑、记忆、协议实验的核心变量可以压成四组Agent数量、拓扑结构、记忆策略、消息协议。再叠加任务类型和模型档位两个条件就构成了180种配置。变量档位为什么控制它Agent数量1 / 3 / 5 / 8观察数量递增带来的边际收益和边际成本拓扑结构链式、星型、全互联、层级分组不同的连接方式决定信息传播路径和误差累积方式记忆策略完全共享上下文、完全独立、共享摘要隔离细节上下文隔离程度直接影响信息损耗量消息协议自然语言自由对话、结构化JSON字段、混合协议协议越结构化下游解析成本越低任务类型单步任务、多步工具调用、长文综合分析验证不同拆分策略在不同任务难度下的收益模型档位轻量档、顶配档判断多Agent是模型能力的补偿还是放大器四档数量、四种拓扑、三种记忆策略、三种消息协议交叉后是144种基础组合再结合任务类型与模型档位的筛选实验最终实际记录的配置数是180种。这背后的设计逻辑是正交拆解每次只让一部分变量组合生效才能定位到底是哪个因素在影响结果。2.2 评测指标准确率之外还看“经济性”和“稳定性”评测如果只看成功率很容易得出“多Agent更好”的结论。因为多Agent系统为了提升那一点点准确率可能烧掉几十倍的Token。实验里至少同时记录了三个指标任务成功率、单位成本效率、输出方差。任务成功率好理解。单位成本效率指的是每提升1%成功率需要多花多少Token这个指标直接决定方案能不能落地。输出方差则是同一套配置跑多次之后结果的波动程度它比平均准确率更接近真实工程体验——有些配置平均分不错但时好时坏这类系统在业务方眼里比稳定略差更令人头疼。印象最深的是输出方差在链式拓扑下的表现。连续传5个Agent之后即使每个Agent的失败率都很低最终错误率也会被逐级放大。反过来如果某个Agent的输出格式不稳定后面每个Agent都要额外花上下文去“理解”它方差会被进一步放大。这解释了一个现象很多实验组合里成功率低根本不是模型能力问题而是编排方式把误差放大了。2.3 任务难度与模型档次越强的模型越不需要堆Agent还有一组非常关键的数据在顶配模型下单Agent的性能已经接近同组最优加上更多Agent几乎没有正收益部分场景甚至因为“过度分工”导致性能下降。而在轻量模型下适当增加Agent数量可以带来一定提升尤其当拆分粒度刚好契合任务步骤时。这个结论对工程选型影响很大。如果你用的是最聪明的模型那么多Agent不是手段反而是一个风险放大器。如果你因为成本限制必须用轻量模型合理的Agent拆分可能真有帮助但前提是拆分位置必须贴合任务天然边界而不是随便切成几段。换句话说加Agent更像是给弱模型的补偿不是给强模型的加成。2.4 实验的边界这套结论不是万能真理也要说清楚这个实验虽然规模大但结论有边界。它的任务集偏向文本分析和工具调用规划对需要多模态输入、需要长时间实时交互的Agent场景覆盖有限评测指标的权重也偏向“成功率成本效率”如果业务更看重稳定低延迟结论可能又会不一样。所以引用这类实验时不要无限外推。正确姿势是把它当作一套方法论先立变量、再定指标、最后跑交叉组合用同样的路子去测自己的任务。180种配置的结论不一定适用你的场景但“先定义变量再跑对照”这个思路放之四海皆准。3. 三个最反直觉的结果原来“加Agent”在一些场景直接是负优化结果最反直觉的部分不在于“多Agent没有明显优势”而在于“某些场景下多Agent确实在帮倒忙”。3.1 简单任务在3个Agent以上时准确率反而下滑实验给出的第一个反直觉结果发生在最简单的一类任务上3个Agent的配置比1个Agent的准确率平均低5%左右5个Agent更是低了接近10%。原因并不玄妙——简单任务的信息本来就少拆分后每个Agent拿到的上下文高度碎片化而中间的传递又需要额外的概括、转述、格式化这一来一回信息熵早就增大了。可以类比流水线如果每个工位只加工一个螺丝却要经过五道白手套交接每一道都要写交接单出错概率大概率比一个人从头拧完更高。在简单任务上“人多力量大”完全不成立交接成本占了大头。3.2 “审查Agent”带来的收益不如保留一个高质量提示词很多团队喜欢加一个“审查Agent”让第二个Agent检查第一个Agent的输出。实验对比里这个配置在长文任务上确实有一定收益但在代码生成类任务上经常帮倒忙。审查Agent往往并不比执行Agent更高明它只是换了一套Prompt去读同一份输出。面对同样模糊的需求它给出的“修改意见”有时是纯粹的噪音而执行Agent拿到噪音后还会真诚道歉并照做最终输出比第一版还差。实验里有一个相当反直觉的对照与其让另一个Agent来审查不如在原Agent的Prompt里加上一句“请自行批判性检查你的答案找出薄弱点并修正”效果几乎相当成本却低一大截。模型本身已经具备自我修正能力重读一遍自己的输出往往比等另一个Agent来反馈更高效。3.3 并行Agent的本质是“概率自我PK”不是稳定增益180种配置里有一组并行方案多个Agent各自独立完成同一个任务再让其中一个汇总或投票。这类方式在准确率上确实比单Agent略高但高得有限成本却是单Agent的N倍。本质上这种“并行投票”并没有引入新知识它只是把同一个模型的不同随机性平均掉了。模型能力本身不足时这种纠错有一定价值模型越强收益越小。而且并行方案的延迟会拉高到最慢的那个Agent的水平实时性要求一上来这种设计从收益到体验都是负的。真正值得做并行的是多个Agent具备完全不同的工具、连接完全不同的数据源、或者存在天然的并行等待场景而不是单纯“多问几遍取平均”。3.4 那么什么配置下“加Agent”真的有用实验里表现最好的一组配置几乎都满足三个条件任务可以分解为顺序强依赖的多个专业步骤每一步使用不同且互补的工具或模型最后有明确的汇总环节并且用结构化协议传递中间结果。换句话说有用的是“结构化的专业分工高效协议”而不是“多加一个对话对象”。如果任务里没有天然的专业边界加Agent只是在给自己加戏。4. 回到工程项目怎么判断你的任务该不该拆给多Agent看完实验最重要的不是记住“加Agent没用”而是把判断方法带回去。以下几点是我在项目评审中实际在用的评估框架。4.1 先做一个最小成本的自测清单任何架构改动都应该有数据支撑而不是靠感觉。我在决定一个任务要不要拆给多Agent之前会先过一遍下面的清单检查项判断方式单Agent基线当前任务用最好的模型单Agent直接跑成功率和成本分别是多少任务边界审计任务能否按专业工具、数据源、输出格式天然分成几段边界是否清晰失败容忍度业务上允许失败重试吗能容忍的最高Token成本是多少现有Prompt空间当前单Agent的Prompt是否已经充分调优还是只是随便写了版如果单Agent成功率与需求差距不大优先做Prompt工程优化如果差距巨大再看任务边界是否清晰只有边界清晰、拆分确实能降低单步复杂度时才值得考虑多Agent。4.2 用“三问法”替代拍脑袋我经常在评审会上用三个问题帮团队做判断每个问题都能挡掉不少“为了拆而拆”的需求。第一问这个子任务让同一个Agent多等一轮循环来处理会发生什么如果只是多转一圈就能解决那拆分就不是刚需。第二问两个子任务之间需要传递的是结构化数据还是模糊语气、前文意图如果主要是后者拆开大概率亏。第三问下游是否需要真正并行地做采样或调用比如同时请求多个API如果有拆分就有了物理层面的理由。三问都通过才进入多Agent设计。核心逻辑很简单Agent拆分只有在能降低单步复杂度、且不增加太多交接成本时才划算。4.3 从1个到3个的最小增量验证法真的决定上多Agent也不建议一步到位铺开大网格。我常用的节奏是先保留单Agent版本做基线然后只增加一个专门负责某一步骤的Agent在同一批测试集上对比成功率、成本、方差三项指标。如果这一步没有正收益就停下如果有再考虑下一步。小规模增量验证比全量重构安全得多也更容易定位问题。曾经我在一个模拟项目X上把单Agent改成“解析Agent执行Agent”两层准确率确实从71%涨到76%但成本涨了1.8倍后来在解析Agent的Prompt里塞了一版JSON Schema定义成本直接降回1.2倍准确率还稳定在77%。这段经历说明很多时候问题不是“要不要拆”而是“怎么拆、怎么定义接口”。5. 那些实验报告不会写、但工程里躲不掉的坑理论归理论工程归工程。下面这些坑是实验报告里很难写清楚、但实际落地时几乎每次都会碰到的。5.1 Prompt风格差异会让评测方差大到你怀疑实验实验里的Agent Prompt大多是统一模板生成的工程里每个人写的子Agent提示词却五花八门。有的爱用口语有的强行指定“你是一位专家”有的规定必须逐条输出。风格不统一评测结果根本不可比。我之前遇到过一次很典型的翻车把某个子Agent的Prompt从“自由对话式”改成“强约束JSON输出式”之后端到端准确率直接涨了8个点方差也明显变小。不是模型变了是接口定义清晰了。多Agent系统里每个子Agent的Prompt本质上就是它的接口文档不用结构化方式把它钉死后面排查起来会痛不欲生。5.2 级联错误最怕的是“高情商圆谎”多Agent链路里下游Agent往往默认上游是对的。当上游输出置信度不高但语气笃定时下游很少质疑反而会顺着错误信息继续加工最后产出一个看起来很合理、实际错得离谱的结果。应对办法有两个。一个是在结构化协议里带上“置信度”字段让下游知道哪一步不可信另一个是明确给下游Agent“质疑权”——当它发现输入与常识冲突时可以直接终止并把上游打回。后者效果很好代价是通信协议稍微复杂一点但比起排错成本这复杂度完全值得。5.3 上下文隔离可能是伪命题很多方案宣称每个Agent只看到自己的上下文隔离得干干净净。但如果所有Agent共享同一个外部记忆库或者共享同一份全局摘要那所谓隔离根本不存在。实验结果给出的最优解是“共享摘要隔离细节”每个Agent能读到上一个环节的关键结论但看不到无关的原始记录。这个配置兼顾了信息完整性和隔离性工程落地也不难无非是在每轮传递时多生成一份简短摘要并把原始数据放到独立存储里。5.4 排障成本从“看日志”升级成“看谱系”单Agent出问题翻一段完整对话就能定位。多Agent系统出问题你得追踪一条消息经过哪些Agent、被改写成什么样、最终在哪个节点引入错误。没有链路追踪能力就上多Agent等于蒙眼开车。建议第一个方案就把每个Agent的输入输出快照、路由ID、耗时指标全部打出来宁可日志丑一点也不能没有。不要相信任何人说的“Agent自己会兜底”排障的第一步永远是数据和观测。5.5 预算失控往往是设计问题不是用量问题多Agent系统的Token消耗不是加法是乘法。同一段上下文可能被每个Agent各读一遍结构化数据还可能被重复序列化。如果上线前没做成本模拟第一个月的账单会吓到你。我习惯在路由层设一个兜底阈值如果某轮任务累计消耗超过预设值就直接返回单Agent简化结果或者提示用户确认是否继续。另外每一轮都记录每个Agent的Token消耗周会上一看就能发现哪个环节在空转。成本失控背后大概率不是用量问题而是设计上做了太多无效信息传递。6. 我的实操结论多Agent是手段不是勋章最后回到整体判断。我梳理了自己最近一年的项目发现“加Agent真有用”的场景其实高度集中需要真正并行采集外部信息任务步骤之间有强工具边界需要分阶段给用户中间反馈。而“加Agent反而更糟”的场景也很清晰需求模糊但整体连贯、强依赖隐性语境的创作型任务以及那些已经有良好单Agent基线的任务。在这些场景里强行拆Agent只会让错误更多、成本更高、排障更难。如果要上多Agent我建议从最小可行配置开始数量控制在2到3个拓扑优先链式或星型消息协议用结构化字段而不是自由文本记忆策略选共享摘要加隔离细节同时给每个Agent配独立日志ID与Token统计。这个配置是我验证过很多次之后成本、效果、可维护性之间的平衡点。等跑出明确的收益信号再逐步增加Agent而不是先把大网格铺好寄希望于效果自己变好。我在反复复现这类实验后最大的感受是多Agent系统确实能处理很多单Agent做不好的事但它比大家想象的更依赖任务结构、接口设计和观测能力。那些看起来“很聪明”的Agent编排绝大多数时候靠的不是Agent数量多而是每一步的职责、协议和异常处理足够清楚。别让Agent数量变成一套勋章让它变成真正解决问题的工具。