多 Agent 的坑

系列入口：如何使用 Agent。本篇是 M5 多 Agent 编排模块的收尾，配合 Orchestrator-Worker、Planner-Coder-Reviewer 和并行子 Agent 阅读。

一、先说结论：多 Agent 不是银弹

很多人一接触多 Agent，会觉得「Agent 越多越强、越自动化越好」。但现实恰好相反：Agent 数量增加，协调成本、不确定性和调试难度都会上升，质量不一定提升，账单却几乎一定变大。 这也是整个工程界反复强调的一条务实原则——能用单个 Agent + 良好工具设计解决的，就不要上多 Agent。

这篇不唱赞歌，专门盘点多 Agent 最容易翻车的四类问题，并给出可操作的对策。理解了这些坑，你才能在真正需要多 Agent 时用得稳，而不是在简单任务上徒增复杂度。

二、第一类：错误级联（Error Cascading）

问题表现：上游 Agent 犯了一个小错或理解偏差，下游 Agent 建立在这个错误结果上继续工作，错误被层层放大。等到最后暴露时，已经很难分清最初是哪一环、哪一步错了。

这是多 Agent 最隐蔽也最危险的坑，因为它利用了「后一个 Agent 默认信任前一个结果」这一点。一个 Planner 对需求的细微误读，会被 Coder 完整实现，再被一个同样建立在错误前提上的 Reviewer「确认通过」，直到上线才暴露。

对策：

• 在关键交接处设置校验，而不是等最后：上游结论交下游前，先确认是否成立，越早拦截代价越小。
• 让下游保持适度质疑：给下游 Agent 的指令里可以要求它先核对输入是否自洽，发现矛盾就停下，而不是无脑承接。
• 重要前提显式化：把任务所依赖的关键假设写清楚，便于任何一环发现假设不成立时及时喊停。
• 必要时用独立校验者：让一个没参与上游推理的 Agent 直接核对原始材料，打破「基于错误前提自我合理化」的链条。

三、第二类：上下文在交接中丢失

问题表现：子 Agent 默认上下文隔离，这本是优点；但如果主 Agent 在派活时没把必要背景、约束或已确认的决定传过去，子 Agent 就会因信息缺失而做偏，或者自行「脑补」出一个与项目实际不符的假设。

典型征兆：子 Agent 反复问本该已知的信息、产出和已有约定冲突、在报告里出现「我假设……」而这个假设其实早就被排除了。

对策：

• 派活时把所需上下文显式、精简地传全：背景、范围、已确认的决定、判据，一个都不能省。隔离不等于「不给信息」，而是「只给它真正需要的部分」。
• 统一交接格式：用固定结构交接（目标、上下文、约束、产出格式），减少信息遗漏。
• 让子 Agent 交回前先复述理解：它对任务和约束的理解如果有偏差，在动手前就能被发现。
• 共享决定要落到规则或记忆文件：避免关键约定只存在于某一次对话里，导致后续 Agent 看不到。

四、第三类：出问题难以调试

问题表现：多个 Agent 在各自隔离的上下文里工作，过程不透明。最终结果出错时，你很难追溯到底是哪个 Agent、在哪一步、基于什么信息做了错误决定。链路越长、嵌套越深，定位越难。

对策：

• 让每个 Agent 简要记录它读了什么、依据什么判断：不必带回全部过程，但要保留可追溯的关键信息。
• 保持结构扁平、职责单一：能两层解决就不要三层层层嵌套；每个 Agent 只负责一类清晰的事，问题更容易定位到具体环节。
• 先在小任务上验证编排再放大：链路用小而真实的任务跑通过，再用于复杂场景，避免一上来就在黑盒里迷路。
• 一次只改一处：排查时像定位普通 bug 一样，缩小范围、隔离变量，而不是同时重跑整条链路。

一个朴素但有效的做法是：当结果异常时，先沿着交接链路从后往前核对每一环的输入是否正确——最终环的输入对不对？它上游交回的结论对不对？这样逐层回溯，往往能快速锁定出错的那一环，而不必盯着最终错误干着急。

五、第四类：成本爆炸

问题表现：多 Agent 的 token 消耗是各 Agent 之和，并行扇出太多、Agent 反复重试、编排不断派新任务，都会让成本快速上涨；更糟的是可能花了钱、结果还更差。

对策：

• 模型分级：简单、模式化的子任务用便宜模型，只有真正需要复杂推理的环节才用强模型。
• 限制并发与嵌套深度：一次扇出数量保持在合理范围，过多则分批跑；避免多层 Agent 互相派生。
• 设上限、盯失控信号：给任务设置步数或成本上限；某个 Agent 反复重试、不断扩大范围时及时单独叫停。
• 先问「是否真的需要多 Agent」：这是最根本的省钱手段。很多看似复杂的任务，用一个 Agent 配合清晰上下文和脚本就能很好完成。

六、更根本的对策：先判断该不该上多 Agent

以上四类坑有一个共同的根源——在不需要多 Agent 的场景上了多 Agent。 所以在动手前，先用下面几个问题自检：

• 这个任务用单个 Agent + 组织良好的上下文能完成吗？能，就不要拆分。
• 子任务之间是否高度耦合、需要频繁共享状态？若是，强行拆分会制造比解决更多的问题。
• 我能否清楚说出每个 Agent 的单一职责和交接物？说不清，说明拆分还不成熟。
• 增加的可靠性，是否足以抵消额外的协调与成本？若收益不明显，就不值得。

一个经验法则：从单个 Agent 开始，只有当你在实践中遇到具体、明确的痛点（比如主窗口反复被撑爆、确实需要并行、单一 Agent 在重要任务上质量不稳）时，才引入对应的多 Agent 模式。 让复杂度由真实需求驱动，而不是被「多就是好」的想象驱动。这也和数据应用领域的共识一致——确定性的工作流编排往往比全自动多 Agent 更可靠、更可控。

七、多 Agent 翻车征兆速查

征兆	更可能是哪类坑	优先动作
结论明显基于错误前提，且一路没人发现	错误级联	在交接处加校验，让下游核对输入
子 Agent 反复「我假设……」、与约定冲突	上下文丢失	派活时补全背景与已确认决定
结果错了，但说不清谁的责任	调试困难	补可追溯记录，简化嵌套结构
账单陡增、Agent 反复重试	成本爆炸	模型分级、限并发、设上限、叫停
任务其实很简单却被拆得七零八落	过度编排	退回单 Agent 方案

八、常见问题

Q：既然坑这么多，是不是干脆别用多 Agent？ 不是。多 Agent 在「需要上下文隔离保护主窗口、可并行提速、重要任务需要独立把关」时确实有价值。关键是按需、克制地使用，而不是一律拒绝或一律铺开。

Q：多 Agent 和多步骤的单 Agent 有什么本质区别？ 多步骤的单 Agent 共享同一上下文，过程连贯但容易被撑爆；多 Agent 各自隔离、能并行和专门化，但要付出协调、交接和调试成本。按任务对隔离和并行的真实需求来选。

Q：错误级联和普通的单 Agent 错误有何不同？ 单 Agent 的错通常局限在一条思路内；错误级联是错误被后续 Agent 当作正确输入继承、层层放大，因此更隐蔽、更难追溯，必须靠交接处校验来切断。

Q：我该怎么把成本控制在可预期范围？ 模型分级、限制并发与嵌套、给步数和花费设上限，并在任务开始前估算大致用量；发现某个 Agent 失控立即单独叫停，避免它在并行里悄悄烧钱。

九、用一张「复杂度预算」管住多 Agent

面对四类坑，一个个去打补丁往往顾此失彼。更系统的做法，是在动手编排前先做一份「复杂度预算」——像管理金钱一样，预先决定你愿意为这次任务引入多少额外的协调复杂度，然后在整个过程中不超支。

这份预算可以从几个具体维度去想。第一是角色数量：这次到底需要几个 Agent，每个是否都有不可替代的单一职责？每增加一个角色，交接、对齐、潜在的级联和调试成本都会增加，因此角色数应取「能完成任务的最小值」，而不是越多越显得先进。第二是嵌套深度：Agent 是否还要派生 Agent？层数越深，过程越不透明、错误越难追溯，大多数任务其实两层（编排者 + 执行者）足矣。第三是交接次数：成果要在多少个环节之间流转？每一次交接都是信息可能丢失、错误可能传递的关口，能减少就减少。

做这份预算的真正意义，是逼你在享受多 Agent 收益前，先正视它的代价。很多糟糕的多 Agent 设计，问题不在某个环节做错，而在一开始就无意识地引入了远超任务所需的复杂度。当你习惯先问「这次我愿意付多少协调成本、最少需要几个角色和几层嵌套」，你会自然地倾向更简单的方案——而简单，恰恰是可靠和可控的前提。

预算定好后还要在执行中守住：当编排者想临时加角色、加层级时，对照预算判断是否真有必要，超出预算的扩张应先停下对齐。把复杂度当成一种需要被显式管理、且天然倾向膨胀的稀缺资源，你就从源头上压住了四类坑滋生的土壤。

十、一个判断框架：从「单 Agent」平滑长到「多 Agent」

最后给你一个可以长期使用的判断框架，帮助你既不盲目排斥多 Agent，也不过早过度编排——核心是让多 Agent 作为一种「被痛点触发的渐进升级」，而不是一个一上来就追求的目标形态。

起点永远是单 Agent。当你面对一个任务，先用一个 Agent 配合清晰的上下文、合适的工具和必要的脚本来完成。这个默认选择很重要，因为它把系统保持在最简单、最可控、最容易调试的状态。接下来，你只需要在实践中留意几个明确的「升级信号」：如果你反复看到主窗口被大体量的过程信息撑爆、影响后续判断，这是在提示你需要上下文隔离，可以引入子 Agent；如果你发现多个子任务确实彼此独立、串行耗时明显，这是在提示你可以并行扇出；如果单个 Agent 在重要任务上质量不稳、自己审不出自己的错，这是在提示你加一道独立校验。

关键在于：每一次升级都应由一个具体、反复出现的痛点驱动，并且只引入解决这个痛点所需的那一点复杂度。 需要隔离时才加子代理，需要并行时才扇出，需要把关时才加校验，而不是一次性把所有角色、层级、门禁都堆上。这样长出来的多 Agent 结构，每一部分都对应着真实需求，因而既不会多余，也更易于理解和维护。

这个框架还隐含一条退路：如果某次升级后发现协调成本超过了收益，完全可以退回更简单的形态。多 Agent 不是只能单向增加的承诺，而是一个可以随任务规模伸缩的工具集。当你建立起「默认单 Agent、按痛点渐进升级、随时可以收回」这套心智，你就真正掌握了多 Agent 的使用分寸——在它能创造价值的地方果断使用，在它只会制造麻烦的地方保持克制。这，正是从新手走向工程化使用者最重要的一道分水岭，也是 M5 模块希望留给你的最终能力。

十一、把四类坑连起来看：它们共享同一条病根

分开讲了四类坑之后，最后值得把它们连起来观察，你会发现一个更深刻的事实——这些看似不同的翻车，背后往往共享同一条病根：系统的复杂度超出了人能够理解和掌控的程度。 看清这一点，对策才会从「四处灭火」升级为「从根上控制复杂度」。

错误级联为什么会发生？因为链路一长，早期错误被层层传递，人已经无法在每一环都保持清醒的核对；上下文为什么会丢失？因为交接点一多，哪些信息必须随成果流动这件事，超出了凭记忆能稳定保证的范围；调试为什么困难？因为过程被切割、分散在多个不透明的上下文里，出问题时你脑中已无法重建完整因果；成本为什么爆炸？因为并行和嵌套让总体消耗不再直观可见，失控得以隐藏。四者的共同底色，都是复杂度增长的速度，超过了理解力和掌控力增长的速度。

这个洞察带来一个重要的态度转变：不要把多 Agent 翻车简单归咎于「某个 Agent 不够聪明」或「某句提示没写好」，而要先问「这套结构是不是已经复杂到没人真正说得清它在如何运转」。如果答案是肯定的，那么再强的单个 Agent、再精雕细琢的提示，也救不回一个整体不可理解的系统；真正有效的，是主动做减法——减少角色、压平嵌套、缩短交接、让每一步都可见。

这也呼应了贯穿整个系列的驾驶员心智：你驾驭一个系统的前提，是你能理解它。 多 Agent 的力量来自分工，危险也来自分工带来的不透明，而你作为编排者的核心职责，就是始终把系统保持在「你能在脑中重建其运转方式」的复杂度之内。当你学会用「可理解性」作为是否引入更多 Agent 的最终标尺，四类坑就不再是需要逐一背诵的清单，而是同一条原则在不同环节的提醒。守住系统的简单与透明，比任何具体技巧都更能让你在多 Agent 的世界里行稳致远——这也是 M5 模块最想留给你的一句话。

十二、一份可以直接用的排错路径

理论讲完，最后给你一份当多 Agent 真的出问题时，可以照着走的排错路径。它的价值在于把「无从下手」变成「有步骤可循」，即使链路复杂，也能一步步收敛。

第一步，先看最终产出，明确「错的是什么」。 不要急着追责到某个 Agent，先用一两句话把异常本身界定清楚：是结论错了、缺了东西、还是自相矛盾？把问题说准，后面才不会乱找。

第二步，沿交接链从后往前，逐环核对输入。 最终环节拿到的输入对不对？如果输入就错了，问题在它上游；再核对上一环交回的结论是否成立，如此逐层回溯。大多数问题会在某一环暴露出「它收到的是对的、交回的却是错的」，出错环节就此锁定。

第三步，针对锁定的环节，判断属于哪类坑。 它是基于错误前提（级联）、缺了必要信息（上下文丢失）、还是在反复重试（成本）？对照前面的征兆表归类，对策也就明确了。

第四步，小范围修复并验证，而不是整条重跑。 只修正出问题的那一环及其下游，用真实任务确认改动生效；同时问一句「这个环节以后如何更早暴露」，把对应的校验或可追溯记录补上，避免重蹈覆辙。

走完这四步，你不仅解决了眼前的问题，还在每次排错中加固了整个编排。把这份路径当作多 Agent 调试的默认动作，再配合始终克制复杂度的习惯，你会发现多 Agent 虽然不简单，却完全可以被稳定地理解、掌控和驾驭。

总结

多 Agent 不是银弹：要警惕错误级联、上下文交接丢失、链路难调试和成本爆炸这四类坑，对策是在关键交接处校验、把上下文显式传全、保持结构扁平可追溯、用模型分级和上限控成本——而最根本的一条是先判断任务是否真的需要多 Agent，能单 Agent 解决就别过度编排。