加了更多Agent，产出却更慢了？这不是错觉。我去年在做某跨平台系统Demo时，把团队从一个Agent加到五个，结果每天的可用产出反而缩水，光排查它们之间的“协调故障”就耗掉一大半精力。圈子里很多人都在吹多Agent编排，但真正跑过几轮的人都会发现：Agent数量不等于效率，规模上去之后，新的瓶颈全在你当初没想过的地方。这篇文章是系列第二篇，重点不是讲怎么搭多Agent系统，而是想聊聊反直觉的另一面：为什么在“真刀真枪”的任务流里，加更多Agent常常会让工作效率更差。我会把踩过坑的原因、一次完整的工作流复盘、以及我后来调整流程的具体做法都整理出来。如果你正打算把Agent从“单兵作战”升级成“小分队”，或者已经感觉到多Agent流程有点不对劲，这篇值得看完再动手。1. 多Agent协同效率不升反降，问题到底出在哪我最初以为多Agent效率低是因为模型能力不够，后来才发现根本不是这样。真正的麻烦集中在四个地方：上下文被切碎、协作信息靠转述、任务串行等待严重、Agent自纠正循环失控。这四个问题叠加起来，会让整体产出出现指数级的退化。1.1 上下文被切碎，全局视野成了奢侈品单Agent执行长任务时，大模型可以持续看到完整的上下文窗口，所有步骤都在同一个记忆体系里演进。但一旦拆给多个Agent，每个Agent只拿得到分配给自己的片段，两个Agent之间并没有真正的共享记忆，它们对“全局目标”的理解完全靠上游传给下游的摘要。举个我实际遇到的例子：需求Agent梳理出10条产品需求，把它压缩成3条摘要传给开发Agent；开发Agent又根据这3条摘要生成代码，再把改动记录压缩成几行文字传给测试Agent。每一层转述都像玩传话游戏，细节丢失不说，还可能添油加醋。到最后测试Agent拿到的“完整需求”，和最初的真实需求已经对不上号了。而由于每个Agent都只看到了局部信息，它们都认为自己没有错，于是错得理直气壮。这不是某个框架的Bug，而是所有基于上下文窗口的多Agent协作都会遇到的结构性问题。上下文一旦被切分，全局信息就变成隐性的，Agent之间再多的消息互通也补不回来。你会发现，最后的产出常常是一个“看起来各部分都很合理，但整体方向跑偏”的东西。注意：任何多Agent方案，如果缺少一个能随时读取全量上下文的“中央记忆层”，就一定会在某个环节出现上下文失真。这是排查效率问题时要最先怀疑的地方。1.2 Agent之间靠“转述”协作，而不是“共享”状态很多人以为多Agent协作就像群里讨论，大家都能看到同一个聊天记录。但绝大多数实现里，Agent之间传递的是生成的文本消息，不是结构化状态。这意味着下游Agent拿到的是上游Agent对信息的“二次加工”，而不是原始事实。我来打个比方：单Agent方案里，写代码的人和看代码的人共享同一个工作台，所有文件、命令行输出、历史改动都摆在桌面上。而多Agent方案里，每个Agent有自己的小隔间，只能通过门缝递纸条沟通。纸条上写什么完全取决于递纸条的人有没有理解准确。于是你经常看到的结果是：负责测试的Agent说“我没收到这个功能的说明”，负责开发的Agent说“我明明写清楚了”，两边开始互相打太极，而真相早就丢在了中间某条消息里。这种“协作开销”不仅没有增值，反而给流程注入大量噪音。每一次跨Agent的消息传递，都相当于一次无监督的摘要生成；而摘要生成正是当前大模型最容易出错的环节之一。消息一来一回，错上加错，等到第三个Agent接手时，原始信息可能已经被“美化”或者“篡改”得面目全非。1.3 串行等待和重复调度，被严重低估多Agent看起来是并行，但实际业务里大量依赖关系决定了它们不得不串行：需求没定，开发没法动；开发没完，测试没法跑。真正常规的“可并行”部分，往往只在团队刚启动和最终合并两处出现。换句话说，你组建了五个人的小队，但大部分时间只有一个人在干活，其他人都在排队等输入。串行等待最可怕的地方不是“慢”，而是延迟的累积效应。假设单Agent完成一个大型任务需要跑10次大模型调用，每次耗时1分钟，那么总耗时约10分钟。如果拆成5个Agent，每个Agent仍要跑5到10次调用，而且每次跨Agent传递还要额外消耗两到三次调用来格式化、汇总、交接。累计下来，总调用次数可能膨胀到原来的三倍以上，总耗时反而变成20到40分钟。更扎心的是，为了表现“团队协作”，很多框架还会加入调度、规划、审批这类中间Agent，它们看起来在帮忙，实际上只是把任务又转述了一遍。规划Agent说“我建议先做A再做B”，执行Agent等着被具体指派，结果真正动手的Agent反而少了。整个系统忙忙碌碌，生产出最多的东西是“会议纪要”。1.4 自纠正循环进入死胡同，成本飙升让Agent干活容易出小错，大家自然想到再加一个“审查Agent”来把关。于是开发Agent产出代码，Review Agent提出修改意见，再退回给开发Agent修改，改完再Review……理论上这是个正向的闭环，现实里却很容变成一个无底洞。大模型本身有随机性和敏感性问题，同一个问题换个角度表述，不同次运行给出的判断就不一样。Review Agent今天说“这个函数需要拆得太细，建议合并”，明天可能对同一段代码说“这个函数太长，建议拆分”。开发Agent夹在中间，只能反复横跳。一次审查、一轮修改，通常要消耗几千甚至上万Token；如果来回五轮，那成本就非常可观了。自纠正的另一个隐患是“目标漂移”。修正意见本身是人类写的还有模糊性，更别说由另一个LLM生成的意见。修改着修改着，代码渐渐偏离最初的业务要求，最后连最初的目标都被遗忘了。这也是我后来反复强调“必须有人工检查点”的原因，因为让两个Agent互相纠错，无异于让两个路痴互相带路。2. 一次真实的多Agent工作流复盘光说原理有点干，我把之前跑过的一轮很典型的多Agent流程摊开来讲。它不一定是你当前场景，但里面暴露的问题，绝大多数多Agent系统都躲不掉。2.1 最初架构：一眼看上去相当合理当时我接到一个模拟项目X：需要产出一个功能原型，包含需求分析、后端接口、前端页面、测试用例和操作文档五个部分。我做了一张很漂亮的编排图：需求Agent：负责把用户输入拆成功能清单和验收标准。后端Agent：根据功能清单生成接口和服务代码。前端Agent：根据功能清单和接口文档生成页面。测试Agent：根据验收标准生成测试用例并执行。文档Agent：收集所有过程信息，最后输出操作手册。为了让它们“合作”，我又加了一个编排调度层，负责把上一环节的结果往下一环节送。当时我觉得自己站在了效率的巅峰，事实证明这只是灾难的开头。2.2 实际运行数据：Token和时间的双重爆炸那一次流程总共跑了大概一个半小时，消耗Token比单Agent方案多出将近四倍。我整理了一下当时的记录：环节Agent数量实际执行轮次消耗Token（约）花费时间（约）需求拆解与验收标准生成1625K9分钟信息转述与调度（3次跳转）31230K11分钟后端代码生成与自省修改1845K16分钟前端代码生成（依赖后端接口）11050K18分钟测试用例生成与修正21235K14分钟文档汇总与重述2928K12分钟人工干预和调试人工7次0（但占用我本人时间）约40分钟看到没？真正的大头不是Agent工作本身，而是转述、调度、重复修正和人工救火。我在旁边等它跑完的时间，比自己动手做还长。最讽刺的是，那40分钟人工调试，很大一部分是在修复Agent之间因为信息不对等造成的“沟通事故”。2.3 三个最典型的翻车环节第一个翻车点是“接口文档”前后端不一致。后端Agent生成的接口一开始命名很合理，但中途它为了自洽修改了两处参数名，测试Agent从需求Agent那里拿到的还是老版本，于是测试脚本报了五个接口全挂。其实代码没坏，纯粹是信息同步没跟上。第二个翻车点是需求Agent过度发挥。它为了“对齐目标”，自动脑补了一个“用户需要数据导出功能”，但这个需求用户从来没提过。等到测试Agent生成用例时，这个子虚乌有的功能混进了验收清单，开发Agent还一本正经把它实现了。最后整个流程多干了大约15%的工作，产出却是错的。第三个翻车点是文档Agent的“过度圆场”。它在汇总时为了逻辑通顺，把之前来回修改的异常过程包装成了“正常迭代流程”，导致我后来回看记录时完全找不到真实决策痕迹。对一个以结果交付为目的的项目来说，这种“过于流畅的文档”反而让后期维护变得异常困难。2.4 复盘后总结出的几条硬道理多Agent模式只有在“每个Agent都消耗了大量不可并行时间”的时候才可能划算。如果完成一个环节只需要几分钟，强行拆分只会把时间浪费在交接上。每个跨Agent数据交接口，都应该保留一份带版本的原始输出，便于核对。不要让下游Agent只看“被转述后的摘要”。不要指望Agent之间能自动达成共识，人类必须设定明确的验收门槛。谁驳回、谁放行，必须一开始就写清楚。自动化链条越长，调试复杂度越高，最后浪费的时间一定大于省下的时间。这些道理说起来简单，但没踩过坑的人很难有体感。尤其是“转述损耗”这种东西，在你只有一两个Agent时会完全隐形，一旦Agent超过三个，就会瞬间变成整个系统的主要矛盾。3. 分清场景：什么时候该上多Agent，什么时候该忍住“多Agent效率低”不意味着它一无是处。我后来试过几种新的组合方式，也逐渐摸清了它的边界。关键不在于“用不用多Agent”，而在于“在哪个环节用、用几个、怎么用”。大部分团队踩坑，是因为把多Agent当成一种默认状态，而不是一种有针对性选择的临时手段。3.1 单Agent能打的时候，千万别组队很多日常工作，本质上是同一个人从头到尾负责的连续过程：写一篇文章、调一个接口、修一个Bug、分析一个数据集。这种任务的最优路径是在一个足够长的上下文窗口里持续对话，让模型不断基于前面的输出继续演进。你强行拆成“需求Agent”“执行Agent”“检查Agent”，只会人为切断上下文，制造出大量无意义的协调成本。我现在的判断标准很简单：如果一个人类员工可以在不叫同事帮忙的情况下完成，那就应该先用单Agent做完，而不是一开始就设计一个流水线。等到单Agent方案明显出现瓶颈（比如单窗口太长、单轮产出质量不可控、任务确实可以并行分块），再考虑拆Agent。3.2 值得上多Agent的三个硬性前提第一个前提是“子任务之间确实没有强依赖”。如果A的输出要等B的输入才能继续，那就不是并行，是串行排队。只有真正没有依赖的子任务，比如“同时做市场调研”和“同时做代码框架搭建”，放到两个Agent手里才不会形成等待。第二个前提是“单个子任务的执行时间足够长”。拆分的交接收支点，至少要能弥补转换造成的额外消耗。我个人的经验阈值是：如果某个子任务在单Agent模式下要跑20分钟以上，拆出去才可能产生净收益；如果只需要5分钟，拆出去就是在纯亏。第三个前提是“有明确的结构化验收标准”。比如后端接口跑完测试用例必须通过，文档必须覆盖指定章节。只有验收标准足够客观，Agent之间不容易扯皮，你才不需要频繁人工介入。如果验收标准是“感觉差不多就行”，那请放弃多Agent，因为你会成为每一个临界点的裁判和救火员。3.3 更值得尝试的多Agent形态：少而精真正给我带来效率提升的，不是让五个Agent一起干一个任务，而是“一个主管Agent带两个专项Agent”的小规模模式。主管负责理解全局目标、拆分任务、汇总结果；专项Agent只负责执行具体子任务，比如代码生成、数据清洗，做完就交回主管统一收口。这种形态踩中的关键点是：主管Agent拥有完整的全局上下文，每个专项Agent只需要处理高度垂直的局部任务，交回结果后再由主管做一致性整合。消息传递只发生在一个界面，不像“网格化协作”那样到处飞。它的总Token消耗虽然比纯单Agent高，但因为边界清晰，极少出现无休止的互相纠错，反而整体跑得更快。我也尝试过“并行独立任务”模式，比如同时让三个Agent分别调研三份资料，最后由人工汇总。这种模式很舒服，因为子任务之间完全不耦合，也不需要它们彼此理解。如果你一定要展现多Agent的威力，这种模式是风险最低的。经验之谈：多Agent最大的价值在于“并行执行真正独立的工作”，而不是“让Agent之间互相协作”。协作越密切，沟通成本越失控。4. 把混乱流程拽回正轨的六个实操动作如果你已经搭了一个多Agent流程正在受苦，别急着全删。照着下面六个步骤调整，通常两天内就能看到明显的效率回血。这些动作都不需要重写架构，纯粹是在既有方案上做减法、做收口。4.1 先加可观测性，再谈优化多Agent流程最大的黑盒在于：你只知道它最终给出了什么，不知道它中途为什么这么做。所以调整的第一步，是给每个Agent加上日志、Token计数、耗时统计和任务流转记录。不要嫌麻烦，这些埋点是你判断优化方向的唯一依据。实际操作里，我会把每个Agent的输入摘要和输出摘要都落盘，并且强制记录它调用了哪些工具、修改了哪些文件。这样当产出出错时，我能在几分钟内定位到是上游信息不准、还是某个Agent执行环节跑偏，而不是像之前一样对着最终结果猜原因。4.2 砍掉冗余的“规划型Agent”，让执行Agent自己规划我见过最没用的角色，就是“规划Agent”。它是一种听起来很高级、实际净添乱的存在：把任务从人工手里接过来，转述成一段漂亮的计划，再交给另一个Agent执行。这个过程中，规划本身没有产生任何具体产出，却额外消耗一轮Token，还增加了一次信息失真机会。更合理的做法是：把规划指令直接写进执行Agent的Prompt里，让它在收到任务时自行拆解。真正需要“规划Agent”的场景非常少，除非你要处理的是高度复杂、需要动态调整强度的研究型任务。对绝大多数常规流程，多一个规划层只是多加一道风险。4.3 把可并行和必须串行，切成两条独立通道很多流程翻车，是把“必须串行”的部分错配到多Agent框架里。我后来把所有任务先画成一张依赖清单：哪些子任务必须拿到上一环节结果才能开始，哪些子任务完全独立。依赖清单画完之后，通常会发现真正的并行空间只有两三条线，其余全是串行。然后我按依赖关系把流程改成“一组串行主线 + 一个并行分支池”。串行主线用单一Agent跑，确保上下文连续；并行分支池只处理可并行的代理任务，完成后统一回归主线。这样既享受了并行加速，又不破坏主线的上下文完整性。4.4 把校验变成一等公民，而不是靠Agent互相审用Agent审Agent的问题是角色重合、标准不透明、容易陷入无限循环。我现在的做法是：在流程里设置显式检查节点，用“规则化校验”代替“LLM互评”。凡是能写进脚本的判断，比如接口返回结构、代码是否可以编译、测试用例是否通过，一律用脚本跑；只有真正需要语义判断的部分，才让LLM参与。这样做的最大好处是成本可控且决策可复现。脚本校验说失败就失败，不会因为换了一种问法而放过错误。比起让“Review Agent”以聊天的形式提意见，这种校验才真正贴近工程实践。4.5 设计可重入的幂等流程，支持随时重跑多Agent流程跑久了，迟早会碰上某一步失败或者产出不符合预期。如果整个流程没有“可以从任意检查点重新执行”的能力，你就只能从头再跑一遍，时间成本直接翻倍。优化方向是让每个子任务都具备短小、幂等、方便单独调用的特点。比如后端Agent的产出是接口代码和接口文档，那我可以只重新运行后端模块，而不触动需求模块。为了做到这一点，每个模块的输出都要保存到独立文件，并且提供明确的输入输出契约。一旦某个子任务变了，下游只需从该契约重新消费结果，不用全链路重演。4.6 分阶段设检查点，避免一把梭跑到底越长的Agent链路，越需要人工“踩刹车”。我每次跑到业务流程的40%和80%时，会强制检查一次中间产物，而不是等全部跑完再惊讶地发现方向错了。这两个检查点通常各花十分钟，但可能帮你省下后面一个多小时的重跑时间。当然，如果任务本身就属于“开放探索型”，很难定义中期明确产出，那这种检查点不太好设。但至少你可以要求Agent在每一步结束时用几句话说明“目前完成了什么、为什么这样做”，把隐性的思考过程变成显性的决策痕迹。这些痕迹在后续调试和复盘时价值极高。5. 多Agent效率问题排查速查表最后整理一张我在实操中反复用到的排查表。遇到效率问题时，先对照症状找原因，再按原因看解法，基本不会跑偏。症状可能原因直接解法多个Agent都在忙，但产出很少大量时间花在跨Agent转述和格式整理上减少中间层，让结果直接落盘，减少转述下游Agent总说信息不一致上下文被切碎，依赖动态生成的摘要引入共享数据层，保留下游读取原始输出流程时间比单Agent还长表面并行实际串行，链路过长画依赖图，把真正独立的子任务挑出来并行Review来回拉锯，改不到头两个LLM互相提模糊意见换成脚本化校验和固定人工检查点同一个任务每次结果差很多大模型随机性在多Agent中被逐层放大缩短链路，固定输入分段，并增加版本控制人工介入时间暴增缺少清晰验收标准和中间产物检查点设定结构化验收开关，规定在哪些环节必须人审总Token消耗远超预期重复转述、重复纠正、无边界自省给Agent设定明确的“做一次就交”规则，禁止自动返工流程跑完但结果没法交付早期需求在转述中漂移，后期无人发现用一份全局需求基线文件贯穿所有Agent这张表的背后其实是一个统一原则：所有效率问题的根源，几乎都可以归结为“信息在传递中被扭曲，或者时间在等待中被浪费”。抓准这两点，治理方向就错不了。我个人在实际操作中还有一个体会：Agent数量并不是衡量工作流成熟度的指标。一个团队给人的专业感，从来不取决于它有多少人开会，而取决于它能不能用最少的人、在最紧要的节点交出最可靠的结果。Agent也一样。与其追求“全员就位”的场面感，不如老老实实把单点能力磨到极致，在真正需要的地方开一条窄而深的并行支线。如果你也经常控制不住想往流程里加Agent，试着先问自己一句：这一加，是在解决问题，还是在制造新的协调工作？答案会非常诚实。
加了更多Agent，产出却更慢了？这不是错觉。我去年在做某跨平台系统Demo时，把团队从一个Agent加到五个，结果每天的可用产出反而缩水，光排查它们之间的“协调故障”就耗掉一大半精力。圈子里很多人都在吹多Agent编排，但真正跑过几轮的人都会发现：Agent数量不等于效率，规模上去之后，新的瓶颈全在你当初没想过的地方。这篇文章是系列第二篇，重点不是讲怎么搭多Agent系统，而是想聊聊反直觉的另一面：为什么在“真刀真枪”的任务流里，加更多Agent常常会让工作效率更差。我会把踩过坑的原因、一次完整的工作流复盘、以及我后来调整流程的具体做法都整理出来。如果你正打算把Agent从“单兵作战”升级成“小分队”，或者已经感觉到多Agent流程有点不对劲，这篇值得看完再动手。1. 多Agent协同效率不升反降，问题到底出在哪我最初以为多Agent效率低是因为模型能力不够，后来才发现根本不是这样。真正的麻烦集中在四个地方：上下文被切碎、协作信息靠转述、任务串行等待严重、Agent自纠正循环失控。这四个问题叠加起来，会让整体产出出现指数级的退化。1.1 上下文被切碎，全局视野成了奢侈品单Agent执行长任务时，大模型可以持续看到完整的上下文窗口，所有步骤都在同一个记忆体系里演进。但一旦拆给多个Agent，每个Agent只拿得到分配给自己的片段，两个Agent之间并没有真正的共享记忆，它们对“全局目标”的理解完全靠上游传给下游的摘要。举个我实际遇到的例子：需求Agent梳理出10条产品需求，把它压缩成3条摘要传给开发Agent；开发Agent又根据这3条摘要生成代码，再把改动记录压缩成几行文字传给测试Agent。每一层转述都像玩传话游戏，细节丢失不说，还可能添油加醋。到最后测试Agent拿到的“完整需求”，和最初的真实需求已经对不上号了。而由于每个Agent都只看到了局部信息，它们都认为自己没有错，于是错得理直气壮。这不是某个框架的Bug，而是所有基于上下文窗口的多Agent协作都会遇到的结构性问题。上下文一旦被切分，全局信息就变成隐性的，Agent之间再多的消息互通也补不回来。你会发现，最后的产出常常是一个“看起来各部分都很合理，但整体方向跑偏”的东西。注意：任何多Agent方案，如果缺少一个能随时读取全量上下文的“中央记忆层”，就一定会在某个环节出现上下文失真。这是排查效率问题时要最先怀疑的地方。1.2 Agent之间靠“转述”协作，而不是“共享”状态很多人以为多Agent协作就像群里讨论，大家都能看到同一个聊天记录。但绝大多数实现里，Agent之间传递的是生成的文本消息，不是结构化状态。这意味着下游Agent拿到的是上游Agent对信息的“二次加工”，而不是原始事实。我来打个比方：单Agent方案里，写代码的人和看代码的人共享同一个工作台，所有文件、命令行输出、历史改动都摆在桌面上。而多Agent方案里，每个Agent有自己的小隔间，只能通过门缝递纸条沟通。纸条上写什么完全取决于递纸条的人有没有理解准确。于是你经常看到的结果是：负责测试的Agent说“我没收到这个功能的说明”，负责开发的Agent说“我明明写清楚了”，两边开始互相打太极，而真相早就丢在了中间某条消息里。这种“协作开销”不仅没有增值，反而给流程注入大量噪音。每一次跨Agent的消息传递，都相当于一次无监督的摘要生成；而摘要生成正是当前大模型最容易出错的环节之一。消息一来一回，错上加错，等到第三个Agent接手时，原始信息可能已经被“美化”或者“篡改”得面目全非。1.3 串行等待和重复调度，被严重低估多Agent看起来是并行，但实际业务里大量依赖关系决定了它们不得不串行：需求没定，开发没法动；开发没完，测试没法跑。真正常规的“可并行”部分，往往只在团队刚启动和最终合并两处出现。换句话说，你组建了五个人的小队，但大部分时间只有一个人在干活，其他人都在排队等输入。串行等待最可怕的地方不是“慢”，而是延迟的累积效应。假设单Agent完成一个大型任务需要跑10次大模型调用，每次耗时1分钟，那么总耗时约10分钟。如果拆成5个Agent，每个Agent仍要跑5到10次调用，而且每次跨Agent传递还要额外消耗两到三次调用来格式化、汇总、交接。累计下来，总调用次数可能膨胀到原来的三倍以上，总耗时反而变成20到40分钟。更扎心的是，为了表现“团队协作”，很多框架还会加入调度、规划、审批这类中间Agent，它们看起来在帮忙，实际上只是把任务又转述了一遍。规划Agent说“我建议先做A再做B”，执行Agent等着被具体指派，结果真正动手的Agent反而少了。整个系统忙忙碌碌，生产出最多的东西是“会议纪要”。1.4 自纠正循环进入死胡同，成本飙升让Agent干活容易出小错，大家自然想到再加一个“审查Agent”来把关。于是开发Agent产出代码，Review Agent提出修改意见，再退回给开发Agent修改，改完再Review……理论上这是个正向的闭环，现实里却很容变成一个无底洞。大模型本身有随机性和敏感性问题，同一个问题换个角度表述，不同次运行给出的判断就不一样。Review Agent今天说“这个函数需要拆得太细，建议合并”，明天可能对同一段代码说“这个函数太长，建议拆分”。开发Agent夹在中间，只能反复横跳。一次审查、一轮修改，通常要消耗几千甚至上万Token；如果来回五轮，那成本就非常可观了。自纠正的另一个隐患是“目标漂移”。修正意见本身是人类写的还有模糊性，更别说由另一个LLM生成的意见。修改着修改着，代码渐渐偏离最初的业务要求，最后连最初的目标都被遗忘了。这也是我后来反复强调“必须有人工检查点”的原因，因为让两个Agent互相纠错，无异于让两个路痴互相带路。2. 一次真实的多Agent工作流复盘光说原理有点干，我把之前跑过的一轮很典型的多Agent流程摊开来讲。它不一定是你当前场景，但里面暴露的问题，绝大多数多Agent系统都躲不掉。2.1 最初架构：一眼看上去相当合理当时我接到一个模拟项目X：需要产出一个功能原型，包含需求分析、后端接口、前端页面、测试用例和操作文档五个部分。我做了一张很漂亮的编排图：需求Agent：负责把用户输入拆成功能清单和验收标准。后端Agent：根据功能清单生成接口和服务代码。前端Agent：根据功能清单和接口文档生成页面。测试Agent：根据验收标准生成测试用例并执行。文档Agent：收集所有过程信息，最后输出操作手册。为了让它们“合作”，我又加了一个编排调度层，负责把上一环节的结果往下一环节送。当时我觉得自己站在了效率的巅峰，事实证明这只是灾难的开头。2.2 实际运行数据：Token和时间的双重爆炸那一次流程总共跑了大概一个半小时，消耗Token比单Agent方案多出将近四倍。我整理了一下当时的记录：环节Agent数量实际执行轮次消耗Token（约）花费时间（约）需求拆解与验收标准生成1625K9分钟信息转述与调度（3次跳转）31230K11分钟后端代码生成与自省修改1845K16分钟前端代码生成（依赖后端接口）11050K18分钟测试用例生成与修正21235K14分钟文档汇总与重述2928K12分钟人工干预和调试人工7次0（但占用我本人时间）约40分钟看到没？真正的大头不是Agent工作本身，而是转述、调度、重复修正和人工救火。我在旁边等它跑完的时间，比自己动手做还长。最讽刺的是，那40分钟人工调试，很大一部分是在修复Agent之间因为信息不对等造成的“沟通事故”。2.3 三个最典型的翻车环节第一个翻车点是“接口文档”前后端不一致。后端Agent生成的接口一开始命名很合理，但中途它为了自洽修改了两处参数名，测试Agent从需求Agent那里拿到的还是老版本，于是测试脚本报了五个接口全挂。其实代码没坏，纯粹是信息同步没跟上。第二个翻车点是需求Agent过度发挥。它为了“对齐目标”，自动脑补了一个“用户需要数据导出功能”，但这个需求用户从来没提过。等到测试Agent生成用例时，这个子虚乌有的功能混进了验收清单，开发Agent还一本正经把它实现了。最后整个流程多干了大约15%的工作，产出却是错的。第三个翻车点是文档Agent的“过度圆场”。它在汇总时为了逻辑通顺，把之前来回修改的异常过程包装成了“正常迭代流程”，导致我后来回看记录时完全找不到真实决策痕迹。对一个以结果交付为目的的项目来说，这种“过于流畅的文档”反而让后期维护变得异常困难。2.4 复盘后总结出的几条硬道理多Agent模式只有在“每个Agent都消耗了大量不可并行时间”的时候才可能划算。如果完成一个环节只需要几分钟，强行拆分只会把时间浪费在交接上。每个跨Agent数据交接口，都应该保留一份带版本的原始输出，便于核对。不要让下游Agent只看“被转述后的摘要”。不要指望Agent之间能自动达成共识，人类必须设定明确的验收门槛。谁驳回、谁放行，必须一开始就写清楚。自动化链条越长，调试复杂度越高，最后浪费的时间一定大于省下的时间。这些道理说起来简单，但没踩过坑的人很难有体感。尤其是“转述损耗”这种东西，在你只有一两个Agent时会完全隐形，一旦Agent超过三个，就会瞬间变成整个系统的主要矛盾。3. 分清场景：什么时候该上多Agent，什么时候该忍住“多Agent效率低”不意味着它一无是处。我后来试过几种新的组合方式，也逐渐摸清了它的边界。关键不在于“用不用多Agent”，而在于“在哪个环节用、用几个、怎么用”。大部分团队踩坑，是因为把多Agent当成一种默认状态，而不是一种有针对性选择的临时手段。3.1 单Agent能打的时候，千万别组队很多日常工作，本质上是同一个人从头到尾负责的连续过程：写一篇文章、调一个接口、修一个Bug、分析一个数据集。这种任务的最优路径是在一个足够长的上下文窗口里持续对话，让模型不断基于前面的输出继续演进。你强行拆成“需求Agent”“执行Agent”“检查Agent”，只会人为切断上下文，制造出大量无意义的协调成本。我现在的判断标准很简单：如果一个人类员工可以在不叫同事帮忙的情况下完成，那就应该先用单Agent做完，而不是一开始就设计一个流水线。等到单Agent方案明显出现瓶颈（比如单窗口太长、单轮产出质量不可控、任务确实可以并行分块），再考虑拆Agent。3.2 值得上多Agent的三个硬性前提第一个前提是“子任务之间确实没有强依赖”。如果A的输出要等B的输入才能继续，那就不是并行，是串行排队。只有真正没有依赖的子任务，比如“同时做市场调研”和“同时做代码框架搭建”，放到两个Agent手里才不会形成等待。第二个前提是“单个子任务的执行时间足够长”。拆分的交接收支点，至少要能弥补转换造成的额外消耗。我个人的经验阈值是：如果某个子任务在单Agent模式下要跑20分钟以上，拆出去才可能产生净收益；如果只需要5分钟，拆出去就是在纯亏。第三个前提是“有明确的结构化验收标准”。比如后端接口跑完测试用例必须通过，文档必须覆盖指定章节。只有验收标准足够客观，Agent之间不容易扯皮，你才不需要频繁人工介入。如果验收标准是“感觉差不多就行”，那请放弃多Agent，因为你会成为每一个临界点的裁判和救火员。3.3 更值得尝试的多Agent形态：少而精真正给我带来效率提升的，不是让五个Agent一起干一个任务，而是“一个主管Agent带两个专项Agent”的小规模模式。主管负责理解全局目标、拆分任务、汇总结果；专项Agent只负责执行具体子任务，比如代码生成、数据清洗，做完就交回主管统一收口。这种形态踩中的关键点是：主管Agent拥有完整的全局上下文，每个专项Agent只需要处理高度垂直的局部任务，交回结果后再由主管做一致性整合。消息传递只发生在一个界面，不像“网格化协作”那样到处飞。它的总Token消耗虽然比纯单Agent高，但因为边界清晰，极少出现无休止的互相纠错，反而整体跑得更快。我也尝试过“并行独立任务”模式，比如同时让三个Agent分别调研三份资料，最后由人工汇总。这种模式很舒服，因为子任务之间完全不耦合，也不需要它们彼此理解。如果你一定要展现多Agent的威力，这种模式是风险最低的。经验之谈：多Agent最大的价值在于“并行执行真正独立的工作”，而不是“让Agent之间互相协作”。协作越密切，沟通成本越失控。4. 把混乱流程拽回正轨的六个实操动作如果你已经搭了一个多Agent流程正在受苦，别急着全删。照着下面六个步骤调整，通常两天内就能看到明显的效率回血。这些动作都不需要重写架构，纯粹是在既有方案上做减法、做收口。4.1 先加可观测性，再谈优化多Agent流程最大的黑盒在于：你只知道它最终给出了什么，不知道它中途为什么这么做。所以调整的第一步，是给每个Agent加上日志、Token计数、耗时统计和任务流转记录。不要嫌麻烦，这些埋点是你判断优化方向的唯一依据。实际操作里，我会把每个Agent的输入摘要和输出摘要都落盘，并且强制记录它调用了哪些工具、修改了哪些文件。这样当产出出错时，我能在几分钟内定位到是上游信息不准、还是某个Agent执行环节跑偏，而不是像之前一样对着最终结果猜原因。4.2 砍掉冗余的“规划型Agent”，让执行Agent自己规划我见过最没用的角色，就是“规划Agent”。它是一种听起来很高级、实际净添乱的存在：把任务从人工手里接过来，转述成一段漂亮的计划，再交给另一个Agent执行。这个过程中，规划本身没有产生任何具体产出，却额外消耗一轮Token，还增加了一次信息失真机会。更合理的做法是：把规划指令直接写进执行Agent的Prompt里，让它在收到任务时自行拆解。真正需要“规划Agent”的场景非常少，除非你要处理的是高度复杂、需要动态调整强度的研究型任务。对绝大多数常规流程，多一个规划层只是多加一道风险。4.3 把可并行和必须串行，切成两条独立通道很多流程翻车，是把“必须串行”的部分错配到多Agent框架里。我后来把所有任务先画成一张依赖清单：哪些子任务必须拿到上一环节结果才能开始，哪些子任务完全独立。依赖清单画完之后，通常会发现真正的并行空间只有两三条线，其余全是串行。然后我按依赖关系把流程改成“一组串行主线 + 一个并行分支池”。串行主线用单一Agent跑，确保上下文连续；并行分支池只处理可并行的代理任务，完成后统一回归主线。这样既享受了并行加速，又不破坏主线的上下文完整性。4.4 把校验变成一等公民，而不是靠Agent互相审用Agent审Agent的问题是角色重合、标准不透明、容易陷入无限循环。我现在的做法是：在流程里设置显式检查节点，用“规则化校验”代替“LLM互评”。凡是能写进脚本的判断，比如接口返回结构、代码是否可以编译、测试用例是否通过，一律用脚本跑；只有真正需要语义判断的部分，才让LLM参与。这样做的最大好处是成本可控且决策可复现。脚本校验说失败就失败，不会因为换了一种问法而放过错误。比起让“Review Agent”以聊天的形式提意见，这种校验才真正贴近工程实践。4.5 设计可重入的幂等流程，支持随时重跑多Agent流程跑久了，迟早会碰上某一步失败或者产出不符合预期。如果整个流程没有“可以从任意检查点重新执行”的能力，你就只能从头再跑一遍，时间成本直接翻倍。优化方向是让每个子任务都具备短小、幂等、方便单独调用的特点。比如后端Agent的产出是接口代码和接口文档，那我可以只重新运行后端模块，而不触动需求模块。为了做到这一点，每个模块的输出都要保存到独立文件，并且提供明确的输入输出契约。一旦某个子任务变了，下游只需从该契约重新消费结果，不用全链路重演。4.6 分阶段设检查点，避免一把梭跑到底越长的Agent链路，越需要人工“踩刹车”。我每次跑到业务流程的40%和80%时，会强制检查一次中间产物，而不是等全部跑完再惊讶地发现方向错了。这两个检查点通常各花十分钟，但可能帮你省下后面一个多小时的重跑时间。当然，如果任务本身就属于“开放探索型”，很难定义中期明确产出，那这种检查点不太好设。但至少你可以要求Agent在每一步结束时用几句话说明“目前完成了什么、为什么这样做”，把隐性的思考过程变成显性的决策痕迹。这些痕迹在后续调试和复盘时价值极高。5. 多Agent效率问题排查速查表最后整理一张我在实操中反复用到的排查表。遇到效率问题时，先对照症状找原因，再按原因看解法，基本不会跑偏。症状可能原因直接解法多个Agent都在忙，但产出很少大量时间花在跨Agent转述和格式整理上减少中间层，让结果直接落盘，减少转述下游Agent总说信息不一致上下文被切碎，依赖动态生成的摘要引入共享数据层，保留下游读取原始输出流程时间比单Agent还长表面并行实际串行，链路过长画依赖图，把真正独立的子任务挑出来并行Review来回拉锯，改不到头两个LLM互相提模糊意见换成脚本化校验和固定人工检查点同一个任务每次结果差很多大模型随机性在多Agent中被逐层放大缩短链路，固定输入分段，并增加版本控制人工介入时间暴增缺少清晰验收标准和中间产物检查点设定结构化验收开关，规定在哪些环节必须人审总Token消耗远超预期重复转述、重复纠正、无边界自省给Agent设定明确的“做一次就交”规则，禁止自动返工流程跑完但结果没法交付早期需求在转述中漂移，后期无人发现用一份全局需求基线文件贯穿所有Agent这张表的背后其实是一个统一原则：所有效率问题的根源，几乎都可以归结为“信息在传递中被扭曲，或者时间在等待中被浪费”。抓准这两点，治理方向就错不了。我个人在实际操作中还有一个体会：Agent数量并不是衡量工作流成熟度的指标。一个团队给人的专业感，从来不取决于它有多少人开会，而取决于它能不能用最少的人、在最紧要的节点交出最可靠的结果。Agent也一样。与其追求“全员就位”的场面感，不如老老实实把单点能力磨到极致，在真正需要的地方开一条窄而深的并行支线。如果你也经常控制不住想往流程里加Agent，试着先问自己一句：这一加，是在解决问题，还是在制造新的协调工作？答案会非常诚实。