1. 先别急着搭系统，想清楚大家口中的 Multi-Agent 到底指什么
最近在技术社区和线下交流里，我明显感觉到一个风向：单 Agent 的 Demo 跑通了之后，几乎所有人都会接着问一句“那什么时候上 Multi-Agent”。这个问题的潜台词往往是——既然一个能干的智能体已经能做不少事，那把好几个放到一起，任务拆分得更细，效率不就应该翻倍吗？
我一开始也是这么想的。直到我真正在一个内部项目里，把一个用于数据处理和报告生成的功能从单 Agent 改造成多 Agent 协作之后，我才意识到这个想法的天真之处。跑通一个单 Agent 其实只相当于培养了一个靠谱的实习生，他能听懂你的指令、能独立完成大部分常规任务、出了小错能自己修正。而 Multi-Agent 本质上变成了让你去管理一支团队，这支团队里的每个成员能力上可能都没有问题，但协作起来却会遇到大量与“能力”无关的问题：谁先做、做到什么程度算完、信息怎么交接、碰到冲突听谁的、某个人搞砸了会不会拖垮整个流程。这些问题在单 Agent 时代根本不存在，因为所有事情都是一个人从头做到尾，而现在全都变成了你作为“架构师”必须亲自设计的事情。
所以这篇文章，我想用自己做项目时真实踩过的坑，把“为什么 Multi-Agent 比单 Agent 更难”这个命题拆开讲透。不是为了泼冷水，而是希望大家在上这个架构之前，先看清楚自己要为哪些额外的复杂度买单。
需要先明确一个前提：我这里讨论的 Multi-Agent，指的是多个由大模型驱动的智能体通过消息、工具调用或共享存储进行协作，共同完成一个复杂任务的系统。一个 Agent 调几个工具函数不算多 Agent，一个 Agent 在循环里多跑几轮也不算。真正的 Multi-Agent 至少要有两个决策节点互相传递信息，并且彼此的输入输出会互相影响。有了这个前提，下面讲的每一层难度才有讨论的意义。
2. 第一层难度：Agent 之间用自然语言沟通，等于在流沙上盖楼
2.1 你以为在传参数，其实在做“同声传译”
单 Agent 系统里，数据在程序逻辑和模型之间的流转基本是受控的。你写一段 Python 代码，调用一个函数，传入一个 JSON 结构，返回值是确定的——这是软件工程里最基础的契约。但在多 Agent 系统里，Agent A 要把结果交给 Agent B 时，最自然的做法是什么？是让它用自然语言输出一段总结，再把这段文本塞给 B。
听起来很灵活，但问题恰恰出在“灵活”上。我做过一个内容生产管线的实验：Agent A 负责从文档中抽取关键信息，Agent B 负责把这些信息整理成表格。单跑 A 的时候，它输出的是“客户姓名：张三；合同金额：两万元整；签署日期：2024年3月15日”这样的文本。B 解析起来似乎不费劲。但当我换了一份格式完全不同的源文档，A 的输出风格也跟着变了，有时候会用“合同签署日期为2024年3月15日”这种自然语句，有时候会把金额写成“￥20,000.00”，B 面对这些变体时开始频繁出错，甚至把日期和金额搞混。
这里的问题不是某个模型能力差，而是自然语言本身就不是一个稳定的接口契约。程序里的接口定义好就固定了，字段名、类型、取值范围一目了然。而 Agent 之间的文本输出，每次都在做一次“同声传译”，传译的准确性取决于模型当时的理解、上下文长度、甚至 Prompt 里的措辞习惯，你没法用一个单元测试把它钉死。
2.2 结构化协议不是万能解药
后来我学乖了，强制要求每个 Agent 在特定节点输出 JSON。这不就回到熟悉的接口范式了吗？并没有。新的问题又冒出来了：Agent 不是机器，它输出的 JSON 时有格式错误，有时字段名写错，更麻烦的是当任务本身很复杂、Agent 需要在 JSON 里表达一些模糊判断时，它会把本该放在“备注”里的东西硬塞进一个固定字段，导致下游 Agent 对内容的可信度产生误判。
我在这个环节试过很多方案，最后相对靠谱的是两层策略。第一层：在 Prompt 里给出严格的目标结构和示例值，并明确要求“不要输出任何示例之外的字段”；第二层：在代码层解析 JSON 时做 Schema 校验和自动修复，像常见的漏逗号、多余逗号、单引号包裹这类小毛病，用解析库处理掉。这套组合能把格式问题控制在一定范围内，但它依然只能缓解，不能根除。
真正的实操心得是：不要在 Agent 之间传大段自由文本。如果一定要传自然语言，就要在接收方加一道“结构化提取”的工序，让接收方先把自己理解到的字段抽出来，再进入正式逻辑。这相当于在不同子系统之间加了一个防腐层，虽然多跑了一次模型调用，但换来的是下游稳定性的大幅提升。
2.3 信任问题：调用另一个 Agent 的“函数”不等于调用本地函数
还有一种协作方式是 Agent A 直接调用 Agent B 暴露出来的工具函数，这在很多框架里被包装成类似“让 Agent 拥有调用其他 Agent 的能力”。表面上看起来，这确实像一个函数调用，B 返回的是一个 JSON，而不是自然语言。但这里藏着另一个坑：B 的执行过程是内部的大模型推理，它不是确定性的，同样的输入，两次可能给出不同的结果，而且不会告诉你它内部做了什么、依据是什么。
在我自己的实践里，这种“伪函数调用”最危险的地方在于，你很难判断一次失败到底是因为 B 这个工具本身不稳定，还是因为 A 传过来的参数有问题，抑或是 B 内部推理时遇到了上下文过长的问题。单 Agent 系统里，工具失败是很好排查的，堆栈一打就能看到；多 Agent 系统里，这种排查成本会成倍增加，因为你不再是对着一个进程，而是对着一条由模型决策组成的责任链。
3. 第二层难度：职责划分不是把任务切成几块那么简单
3.1 你以为的边界清晰，在任务面前全是模糊地带
网上各种 Multi-Agent 教程里，最常见的图示就是用一个框把 CEO Agent 放在上面，下面并列着产品、技术、市场几个 Agent，看起来漂亮极了。但等你真正拿到一个任务，试着把它塞进这个框的时候，就会发现现实根本不长这样。
举一个我自己经历过的例子。当时我参与一个数据分析平台的功能设计，想把“从原始数据到最终可视化报表”这个流程做成多 Agent 协作。一开始的分工很自然：数据清洗 Agent、统计分析 Agent、报表生成 Agent。听起来边界清清楚楚。
但第一轮跑下来就翻了车。清洗 Agent 认为某些字段是无效的、可以丢弃；分析 Agent 却认为这些字段在交叉统计里有价值，觉得清洗过度了。这种分歧单靠 Prompt 是没法消除的，因为“什么样的数据算有用”本身就是一个需要业务上下文才能判断的问题，而两个 Agent 看到的上下文不一样，判断自然就不一样。最后不得不退回到单 Agent 先把数据预处理方案完整跑一遍，有了确定性的中间产物之后，才敢让下游 Agent 介入。
这个经历给我的教训是：多 Agent 的职责划分不是按“流程步骤”切，而是按“决策域”切。一个理性的判断是，只有当两个环节之间的输入输出可以极其明确地定义、彼此不需要额外上下文时，才适合拆成两个 Agent。否则，拆出来的不是协作，是矛盾。
3.2 “做完”这个词，在单 Agent 和多 Agent 里是两个意思
单 Agent 模式下，你让它做一份报告，它从头做到尾，做完了交给你，这个过程你对质量负责的对象只有一个。多 Agent 模式下，每个 Agent 完成自己那部分之后，都面临着“如何向别人说明自己做完了”的问题。这话听起来很抽象，落在实践里就是：谁负责写交接文档？交接文档的标准是什么？如果交接文档里少了某个隐含条件，下游 Agent 是否会发现？
我之前做内容审核方向的一个模块时，在 Agent A（识别敏感点）与 Agent B（输出处理建议）之间，规定 A 必须输出“问题类型 + 原文定位 + 建议级别”。看似足够清楚，但实际运行中经常出现一种情况：A 识别出“疑似隐私泄露”，但它没有在交接文本里说明“这部分内容需要人工复核”，B 拿到之后就按自动处理的路径继续推进了。你看，问题的根源不是某项能力不足，而是 Agent 之间缺乏对“完成度”的共同认定标准。
现在我会在写每个 Agent 的 System Prompt 时，专门加一段“输出交接说明”的强制要求，里面明确哪些情况必须标注“requires_review”，哪些情况需要附带完整的决策依据。这不是什么高级技巧，但确实能减少很多无谓的扯皮。本质上，你是在用工程手段为模型补上“项目管理”的常识。
3.3 分工越细，Prompt 越难写，系统越难调
还有一个很多人后知后觉才意识到的问题：把一个大任务拆成五个小 Agent，意味着你同时要维护五份高质量的系统提示词。每份提示词不仅要定义角色本身的能力边界，还要定义它和其他角色的协作规则、交接格式、异常处理方式。
我见过太多团队在单 Agent 时代只维护一份还不错的 Prompt，到了多 Agent 之后，每个人的提示词各写各的，风格不统一、协作规则互相打架。结果就是：单看每个 Agent 都还挺像那么回事，合在一起跑一个复杂任务时，怎么调都别扭，改 A 的输出格式，B 跟着出问题；改 B 的判断逻辑，C 不满意。这种“牵一发动全身”的耦合度，是单 Agent 系统里绝对不会遇到的。它意味着你不再是一个“提示词工程师”，你得是一个“组织架构师”。
4. 第三层难度：共享状态是必须面对的泥潭，躲都躲不掉
4.1 多 Agent 必然涉及状态一致性问题
单 Agent 系统里，状态通常只存在于一个上下文窗口里。一个小助手类的应用，聊了几十轮，你能直接从头看到尾，排查问题也基本是顺着对话历史找。但多 Agent 系统里，每个 Agent 都有自己独立的一段上下文，但它们又需要共享关于任务的进度、中间结果、历史决策。怎么共享？这是整个多 Agent 架构里最容易被低估的难点。
我在一个跨语言翻译审校的任务中尝试让三个 Agent 分别处理“初译—审校—润色”，共享同一个任务记录表。头几轮流程走得很顺，但到了第 20 轮左右，问题开始出现了：审校 Agent 基于的是旧版本中的某一句翻译，而初译 Agent 已经根据新指令改掉了那句；两边对“当前版本”的理解不一致，导致后面润色 Agent 反复在审校 Agent 提供的旧基础上做优化，怎么改都改不对。
这种问题在单 Agent 系统里几乎不会发生，因为模型总是站在最新上下文之上工作。而在多 Agent 里，如果你的状态管理设计得不够好，每个 Agent 实际上都在过时的信息上做决策，系统表现得就像一群谁都不看会议纪要的人。
4.2 三个层级的状态管理，我建议这样设
在我自己的项目里，我倾向于把状态分成三个层级，每层有不同的管理策略。
第一层是临时状态，只存在于单个 Agent 的执行周期内，比如它自己内部思考用的草稿、临时拆解步骤。这层状态不需要跨 Agent 共享，也不建议共享，因为会把其他 Agent 的上下文搞得很脏。我一般会提示模型在最终输出时只给结论，不给内部推理过程，除非有特殊要求。
第二层是会话状态，也就是多个 Agent 在同一个任务的几轮交互中需要共用的信息，比如“当前处理到第几步”“用户刚修改了哪个字段”。这层状态我会要求 Agent 在输出结构化内容时，必须携带当前进度字段，接收方首先检查进度，再决定自己是否要继续执行。
第三层是持久化状态，一般放在外部存储里，比如向量数据库、关系型数据库或者 JSON 文件。这层是所有 Agent 需要做长期决策时查询的依据。它的关键问题是：什么时候写入、什么时候读取、谁有权更新。如果这个写读时机设计不好，就会出现“旧数据覆盖新数据”“读到了中间态未提交的数据”等低级但破坏力极大的故障。
4.3 上下文污染：每个 Agent 的“记忆”都会影响全局
还有一个更隐蔽的问题叫上下文污染。在单 Agent 系统里，你只需要关心一份上下文的长度和质量；多 Agent 系统里，每个 Agent 的上下文都是独立维护的，但如果你在编排层不够小心，很容易把本不该共享的上下文塞给某个 Agent，导致它的判断被无关信息带偏。
我印象最深的一个事故是：一个“总结提炼”Agent 在汇总多个 Agent 的中间产物时，因为编排层把另一个任务的脏数据也一并放入了上下文，导致它在总结时莫名其妙加入了一条与该任务完全无关的信息，而且由于这条信息在上下文中出现多次，它甚至把它当作主信息来写。排查了很长时间，最后定位到是状态存储的键设计冲突，两个任务的数据 hash 到了同一个键上。这个问题的核心不是模型能力，而是你对数据生命周期的管理不够精细。在 Multi-Agent 里，上下文不是无限的，每一段对话历史、每一个工具返回，都是一份需要小心的资产，你不能做甩手掌柜。
5. 第四层难度：错误一旦开始传播，就不再是简单的“重试一次”
5.1 单 Agent 的错是点状，多 Agent 的错是链式
单 Agent 系统出现问题时，不管哪个环节，你面对的基本都是单个失败点。模型输出不够好？换 Prompt 再试。工具调用失败？捕获异常重试一次。这是因为所有的处理逻辑都在一个控制流里，错误的影响范围是局部的、可控的。
但多 Agent 协同链路里，错误会沿着传递链不断放大。我曾经做过一个四阶段的自动化流程：采集信息、清洗分类、提取要点、生成摘要。在单 Agent 版本里，每个阶段如果出错，重新跑一次就完事了。但在多 Agent 版本里，采集 Agent 偶尔会漏掉一部分原始内容，它自己并不会报错，而是会“正常”地把缺失数据打包传给清洗 Agent。清洗 Agent 拿到缺失数据后照常处理，生成一份结构正常但内容残缺的中间结果。然后要点提取 Agent 在这个残缺结果上继续“顺理成章”地提炼，最后摘要 Agent 生成了一份看起来完整、实则核心信息全丢的报告。
如果所有 Agent 都在自己的局部视角里判断“我这一步没问题”，那么这个链路里就没有人会发现数据源头已经缺失了。错误从第一个节点开始，像滚雪球一样滚到最后，等你在最终输出上发现问题时，你根本不知道到底哪一步出的错。这就是链式传播最恐怖的地方：它不是某个单一节点的失败，而是整个链路对该错误视而不见的“合谋”。
5.2 重试机制在这里变得非常难做
单 Agent 系统里遇到一次调用失败，你可以直接重试整个 Agent，反正它没有对外状态。多 Agent 系统就麻烦了——如果 Agent B 已经基于 Agent A 的错误输出做了一部分工作，B 的内部状态和它写入到共享存储的数据已经更新了。这时你重跑 A，得到的是一个正确的新结果，但 B 还停留在旧结果上思考，新结果和旧结果之间的差异又会产生新的冲突。
我见过最离谱的场景是：重试流程触发后，Agent A 生成了两份不同的结果，Agent B 和 Agent C 分别基于不同版本往下走，最终两边的产出同时写入了共享存储，然后下游 Agent 拿到同一任务的两份互相矛盾的资料时，直接“精神分裂”了。
所以，在设计多 Agent 系统时，我强烈建议为每个 Agent 加上“输入版本号”的概念。任何 Agent 在写入中间结果时，必须带上它依赖的输入版本，下游 Agent 在消费前要检查版本一致性。如果版本不一致，宁可停下来请求重新生成，也不要带着错误继续往下走。这套机制在工程上倒不难实现，难的是你提前意识到这是必要的。
5.3 更复杂的是“部分成功”的中间态
绝大多数时候，一个多 Agent 任务不会是全成功或全失败，而是处于一种“部分成功”的中间态。比如五个 Agent 里三个完成了，两个还在跑；或者三个完成了但其中一个的结果质量明显有问题，需要返工。这种中间态在单 Agent 系统里基本不存在，因为它的执行是线性的、同步的。
但在多 Agent 系统里，尤其是并行化程度比较高的场景下，“部分成功”非常常见。而这种状态怎么处理，是一个大问题。我自己的处理策略是：引入一个人工确认节点，在所有关键任务的汇合处，把“状态汇总”展示给调用方或者一个监督 Agent，由它决定是继续、重跑部分模块，还是整体终止。这个监督者的角色不一定是人类，它可以是一个独立的、不参与业务分析的 Agent，职责就是检查各分支产物的完整性和一致性。为什么这个角色一定要独立？因为任何参与具体业务的 Agent 都会有立场和盲点，只有站在流程外部的人才看得清全局。
6. 第五层难度：验证一个多 Agent 系统，比构建它本身更让人头疼
6.1 单 Agent 还能手动测，多 Agent 根本测不过来
单 Agent 应用上线前，你可以把主要使用路径列出来，手工写几条测试用例，然后一遍遍去跑，基本能覆盖到绝大部分问题。模型不在正文里，不用直接在正文里面提这个，这部分就是在解释多 agent 和单 agent 的区别。多 Agent 系统的测试复杂度是指数上升的：任务类型可以有无数种，每个 Agent 的输出质量在不同组合下有无数种，再加状态组合、模型随机性、并发时序，你根本不可能用有限的用例集去逼近真实表现。
我在实际项目中，多 Agent 系统上线后在线上翻车的问题，绝大多数在测试阶段都没有出现过。因为你在测试环境里跑的那几条 happy path 太顺利了，根本没有覆盖到多个 Agent 相互干扰的阴暗面。后来我调整了思路：不再追求“测试覆盖全部可能”，而是把重心放在“如何让系统在未知场景下不彻底崩盘”。也就是说，比起穷举用例，我更关注 Agent 之间的交互协议是否严谨，编排层的护栏是否到位。
6.2 请一个“裁判 Agent”来帮忙，但别全信它
多 Agent 系统的输出验证，现在主流思路是让一个额外的“裁判”Agent 用大模型来评判另一个/另一组 Agent 的产物。这个思路在单 Agent 评测里其实是好用的，因为通常只是评价一份回答够不够好。但在多 Agent 场景里，裁判 Agent 会面临一个额外的难题：它自己也受到上下文长度的限制，没法同时看到所有 Agent 的完整输入输出。
最典型的情况是：裁判 Agent 只拿到了最终汇总结果，看不到中间环节的取舍过程，于是它对一次“有意为之但暂时违背用户原话”的处理会产生误判。比如，一个内容转换场景里，中间 Agent 为了统一格式，主动把用户原文中不规范的编号改成了标准序号。裁判 Agent 只看最终输出，觉得“咦，怎么跟用户原文不完全一致”，给出差评。但它不知道这正是中间 Agent 的设计职责所在。
所以现在我在评测多 Agent 系统时，倾向把裁判 Agent 的输入做成一份结构化的“推理轨迹”，不仅包含最终输出，还包括关键中间决策及其理由。这么做之后，误判率会降低不少，但仍然不要全信。多 Agent 系统评测本身就是一门需要慢慢积累经验的功课。
6.3 回归测试：改了一个 Agent，整个链路都跟着变
多 Agent 系统还有一个让人头皮发麻的特性：你只改了其中一个 Agent 的 Prompt，另一个 Agent 的输出就可能跟着变化。原因很简单——A 的输出格式略微变了，B 的输入就变了，B 的输出自然会变。这在单 Agent 系统里是不可想象的，因为修改的影响半径通常只在一个上下文窗口内。
我后来为这种问题专门建了一份“输出差异回归清单”，每次调整任何一个 Agent 后，都要跑一遍固定的测试集，把每个 Agent 的关键环节输出做 diff。这个步骤可能并不高效，但如果跳过，你迟早会在线上遇到“我觉得我哪都没改，但结果怎么不一样了”的灵异事件。
7. 那到底要不要上 Multi-Agent？我的判断标准
7.1 先回答三个问题
在经历了这么多层层叠叠的复杂度之后，我的态度不是“不要用多 Agent”，而是“不要为了用多 Agent 而用多 Agent”。每次你决定从单 Agent 迁移或者新建多 Agent 系统前，先回答三个问题：
第一个问题：这个任务真的需要多个角色同时持有不同的视角吗？如果只需要把一个长流程顺序执行完，那用工作流编排的效果大概率比多 Agent 更好。这不是因为我偏爱单 Agent，而是因为工作流的每一步之间交互是确定性的，不需要模型去做“上下文切换”和“意图理解”。
第二个问题：你能为每个 Agent 定义足够清晰、稳定的边界吗？如果边界模糊，拆出来只会让问题更复杂。一个有效的判断方法是：拿五个真实任务，试着把每个任务从开始到结束在纸上画一遍，看每个阶段之间的输入输出是否可以用固定的数据结构表达。如果有某个环节做不到，那就是不适合拆分的提示。
第三个问题：你的团队能承受调试这种系统的时间成本吗？多 Agent 的问题排查往往不是看一份日志就能解决的，你需要把每个 Agent 的调用链、中间结果、共享状态全部串起来才能定位问题。这个成本比单 Agent 高得多，如果你做的只是一个内部小工具，没必要让自己陷入这个泥潭。
7.2 降级方案：可以用“伪多 Agent”绕开大部分痛点
如果你认真分析了之后，发现某个任务确实需要类似“多角色协作”的效果，但又不想承担上面这些复杂度，可以考虑一个折中方案——伪多 Agent。所谓伪多 Agent，是指在同一个 Agent 里通过工作流编排和工具调用，把原本多 Agent 承担的职责用函数和固定流程实现。整个执行过程仍然只有一个大模型上下文，但内部可以有多个明确不同的任务阶段。
举个例子，一个“收集资料—整理提纲—撰写文稿—自动配图”的内容生成流程，你可以让同一个 Agent 依次执行这四步，每一步通过特定的工具函数和输出模板来保证格式稳定。看起来它确实做了多个角色的工作，但因为没有多个独立的决策上下文，所以天然避开了上下文污染、状态同步、错误链式传播这几个大坑。
我自己的经验是，80% 号称需要上多 Agent 的常见业务场景，用这种“单 Agent + 强流程”的方式都能解决。代价是一部分灵活性，但换来的是复杂度的大幅下降、可调试性的显著提升。对于绝大多数产品而言，这个交换非常划算。
7.3 如果非上不可，我建议的架构防御姿势
如果你的任务已经通过了前面三问，确实需要多 Agent 的灵活性和并行能力，那我也有一套防御性的架构建议。
第一，隔离上下文。每个 Agent 的共享上下文必须通过显式数据结构传递，不要隐性地把所有历史一口气塞进去。我的做法是在编排层有一个统一的“消息总线”，每个 Agent 的输入和输出都走这个总线，总线只保存结构化消息，不存原始对话记录。
第二，显式中间产物。每个关键 Agent 在处理完自己那部分后，必须把产物落库，并附上产物版本号。任何下游 Agent 在消费时，都必须检查版本号，防止基于过期数据做决策。
第三，引入监督者角色。不要让所有 Agent 处于一个完全自治的平面结构。设置一个独立的协调/监督 Agent，专门负责检查全局一致性、冲突检测和异常上报。它不负责具体执行，只做裁判和调度。
第四，可观测性。从第一天就要记录所有 Agent 的输入输出摘要、耗时、错误信息和状态变化。这不是可选项，而是多 Agent 系统上线后你唯一的救命稻草。没有这些日志，一次复杂任务的问题排查可能要花掉你一整天。
8. 最后聊几句真实的避坑体会
说了这么多，其实最简单的一句话是：Multi-Agent 真正的难点不在“让 AI 更聪明”，而在于“让多个 AI 像一个好团队那样协作”，而后者是一个典型的组织问题、工程问题，不是模型问题。
我在多 Agent 项目上的真实体感是：如果单 Agent 版本的完成时间是 1 倍，多 Agent 版本的开发调试时间是 2 倍以上，维护和排查问题是 3 到 5 倍。这些额外的时间不一定能换来对应的体验提升，除非你的任务真的有足够复杂的认知分工和并行需求。
所以，给和我一样每天都在追新架构的朋友一个建议：先别急着重构，把你当前的单 Agent 压榨到极限，看看它到底在哪个环节真正卡住了你。很多时候你会发现，卡住你的往往不是“一个 Agent 不够”，而是你的输入处理、状态组织和 Prompt 设计出了问题。这些问题不解决，哪怕换成十个 Agent 也照样卡。
如果你认真评估后确实要上 Multi-Agent，那就从最小的规模开始——两个 Agent 协作，跑通一个端到端场景，先把通信协议、状态管理、错误传播的机制都建好。两到三个 Agent 的复杂度和五个以上完全不是一个量级，先把小规模跑稳了，再去想大规模编排的事。这条路没有捷径，但走通之后积累出来的工程经验，是任何框架教程都给不了你的。
