多Agent系统的工程落地，最尴尬的阶段往往不是写不出代码，而是demo做得风生水起，一上生产就四面漏风。我见过不少团队，单体Agent跑通了几十条工具调用链，自认为已经把大模型用得炉火纯青，结果一拆多Agent，立刻掉进上下文污染、责任边界模糊、日志难追、评测无从下手的泥潭。这恰恰说明：多Agent系统真正的难点从来不在“Agent”本身，而在工程化组织——你如何定义它们的分工，如何让它们协作，如何在失控时兜底，以及如何持续证明这套系统还在做对的事。这篇内容不聊paper，聊的是我从架构选型到治理体系搭建过程中沉淀下来的完整方法论，适合那些已经跑过单Agent、正在规划或已经上线多Agent系统的架构师、技术负责人和一线开发。
1. Agent单干 vs 团队协作：认清多Agent系统的真实边界
1.1 从“把一切塞给一个Agent”到“多个各司其职的Agent”
很多团队在起步时都是同一个思路：既然大模型什么都能干，那把业务规则、工具调用、甚至数据权限全部写进一个Agent的提示词里不就行了？短期看确实可行，但一旦业务复杂度上来，这种单体的“大力神Agent”就会表现出典型的力不从心。
举个最常见的例子——问数智能体（Text-to-SQL）。让一个Agent同时负责语义理解、SQL生成、数据权限判断、结果归因解释，它确实能在几十个问题里表现得非常聪明。但当你接入几百张表、几十种权限策略、多轮追问场景时，问题就暴露了：提示词膨胀到上万字，改一个工具说明都可能引发SQL生成策略的漂移；模型在长上下文里被大量无关指令干扰，原本稳定的能力开始劣化；更麻烦的是，一旦结果出错，你分不清到底错在哪个环节。
从系统设计角度讲，这其实就是“单点职责过载”。一个Agent如果把所有能力都装进同一个上下文和同一套工具集里，它就不是在“做决策”，而是在一个巨大的、互相干扰的指令空间里猜你的意图。生活里也很好理解：你不可能让一个人同时当客服、财务、法务还兼着数据工程师，真这么干，这个人很快会出错。Agent也一样，它的工作记忆和注意力是有限的，职责越单一、边界越清晰，行为才可能越稳定。
1.2 多Agent解决了什么，又带来了什么
多Agent系统解决的核心问题，不是让系统“看起来更智能”，而是把复杂任务按职责拆分，让每个Agent在有限的上下文和工具集合下专注做好一件事。我们团队当时拆完问数智能体后，实际的收益非常具体：每个Agent的提示词从八千字降到一千五，Prompt修改后对系统其他部分的影响完全可控；SQL生成Agent、意图澄清Agent、数据权限Agent可以独立测试、独立发版；某个Agent出了问题，只替换对应模块，而不是推倒重来。
但代价同样具体。最明显的是通信和协作成本：Agent与Agent之间的消息传递不再是简单的一次函数调用，你要处理异步、超时、消息格式、路由失败；状态一致性变得极其难缠，两个Agent同时操作同一个业务数据时，你必须有锁或者补偿机制；排障成本指数上涨——你不再是看一个Prompt的调用栈，而是追踪一条跨越多个Agent、多次工具调用的完整链路。
所以我的判断标准一直很简单：只有当系统里真的存在多个职责边界清晰、可以独立演进、并且各自有独立工具或数据访问范围的“职责域”时，才值得拆多Agent。纯粹为了架构上的“整齐”而拆，只会让团队给自己制造一堆运维负担。
1.3 什么时候不应该上多Agent
我也得泼盆冷水：相当一部分场景不需要多Agent。如果你的业务流程是固定的顺序——比如“提取关键信息—调用API—返回结果”，或者只是一些单轮、只涉及一个知识领域的问答，那么单Agent加上工具函数就已经是效率最高的方案了。多Agent不是银弹，它带来的每一分协作能力，都同时引入了额外的延迟、成本和故障点。
我见过一个团队把三个Agent配置在一个客服工单系统里，其中一个Agent只是把上一层的输出格式化一遍再传下去，完全没有独立决策能力。这种“为了拆而拆”的做法，除了让系统变慢、让运维变难，几乎没有带来任何质量提升。务实一点讲：如果你的业务只需要一个LLM调用就能完成，那就别为了简历好看而强行上多Agent。多Agent的收益来自“可扩展的规模化协作”，不是来自“听起来高级的架构名词”。这一点，在这个领域尤其值得反复对自己说。
2. 架构设计的核心分叉：选择编排模式，再做角色与生命周期建模
2.1 三种通信范式：编排、协作与群体竞争
多Agent之间的交互模式，决定了整个系统的松耦合程度和容错方式。我把它归类为三种范式，虽然网上会有各种花哨的叫法，但底层思路殊途同归。
编排模式（Orchestration）：有一个中心化的编排器（Orchestrator）负责任务拆解、结果汇总和流程控制，其他Agent都是执行单元，听命行事。优点是流程可控、责任清晰、排障简单；缺点是编排器本身可能成为瓶颈和单点。这种模式最适合有明确SOP的业务，比如问数智能体的“意图解析—生成SQL—执行查数—结果归因”这条链路，每一步都有明确的输入输出，编排器就像项目经理，定方向、查进度、验收结果。
协作模式（Collaboration）：没有绝对的中央控制，多个Agent围绕同一个目标互相协商、互相补充信息。这种模式适合开放式探索场景，比如几个Agent一起做行业研究，一个负责找数据，一个负责写报告，一个负责质检，彼此之间是同行合作关系。它的优点是灵活、能处理不确定性更高的任务；缺点是行为不可预测性上升，必须有很强的约束机制，否则Agent之间来回对话就是灾难。
竞争模式（Competition）：多个Agent各自独立尝试回答同一个问题，然后通过投票、评分或评审机制选出最优结果。典型用途包括代码生成、文案生成、策略建议这类“需要多样性再收敛”的场景。用多个Agent生成多版候选方案，再让一个独立的评测Agent做裁决——这其实和“多个专家会诊”是一个逻辑。
三种模式的取舍，我用一句话总结：能编排就编排，因为可控；必须协作时才协作，因为任务本身是开放式的；竞争投票用在“质量比延迟重要”的场景。实际生产系统往往是混合的，比如主链路用编排，某个环节内部用竞争，关键节点用协作补充信息。架构上没有绝对的对错，只有组织方式与业务特性是否匹配。
2.2 编排器的设计细节：路由、重试与终止条件
编排器是多Agent系统里最接近“业务大脑”的组件，但它不该是一个充满硬编码if-else的“上帝类”。我们实践下来，编排器最核心的设计点是三个：路由策略、动作重试和终止条件。
路由策略：不要用大模型直接判断“这个任务该发给谁”，生产环境中它会出错。更可靠的做法是让每个Agent对外提供带语义描述的能力注册表，然后用“语义检索+规则兜底”的方式做路由。问数智能体里，用户问“这个季度华东区的销售数据”，先由路由组件检索到“SQL生成Agent”和“数据权限Agent”，再结合业务规则决定调用顺序。纯语义路由会有模糊地带，所以兜底规则必须存在——当我们无法判断意图时，直接转人工澄清，而不是盲目转给某个Agent。
重试与幂等：多Agent系统里失败是常态，LLM调用超时、工具返回异常、下游服务抖动都会触发重试。因此每个Agent的执行动作必须是幂等的——重复执行不能产生副作用。我在设计工具接口时有一个硬性要求：写操作必须带操作ID，读操作不做缓存写回，这样重试才安全。不然一个Agent因为超时重试，结果插了两条订单记录，那可不是组件层面能解释清楚的事。
终止条件：没有终止条件的编排器，是生产事故的温床。每个任务都要定义最大Agent交互轮数、总耗时上限、以及关键节点的置信度阈值。比如问数智能体，最多允许三次澄清追问，超过就强制转人工；SQL生成Agent如果两次生成结果都未能通过语法校验，就停止执行并给出失败报告。硬性终止条件能有效避免Agent陷入“自说自话”的循环，是治理体系的第一层安全网。
2.3 角色建模方法：职责、技能、工具与记忆范围四件套
每个Agent在注册进系统之前，必须回答四个问题：它负责什么（职责边界）、它能用哪些模型能力（技能）、它能调用哪些外部系统（工具）、它能读写哪些数据（记忆与权限范围）。我把这四项称为Agent的“角色四件套”，是搭建多Agent系统时最需要花时间打磨的部分。
这和4A架构设计里的思路是相通的——先画业务能力域，再做技术实现。很多团队在Agent角色建模时容易犯的毛病是“按系统模块分”，比如“订单Agent”“库存Agent”，但Agent不是微服务，它是“具有决策能力的业务角色”。正确的拆分方式是按业务职责域分：比如“客服接待Agent”可以访问订单和库存系统的只读接口，但它的职责是沟通和判断，不是直接执行扣库存；真正确认扣库存动作的是“交易执行Agent”，且它需要收到客服Agent带明确参数的指令才会动手。
记忆范围尤其要克制。每个Agent能访问什么数据，直接决定了它的行为边界。如果所有Agent都能访问全部历史对话和全量业务库，那你等于又变回了一个能互相传递信息的“超级单体Agent”，只是把输入从一条Prompt变成了几十条Prompt。角色四件套的产出物不是一份文档，而是注册中心里的结构化配置——每个Agent的能力、工具、记忆域都明确登记在案，既方便编排器做路由，也方便后续做权限审计。这一步做扎实，后面的治理体系才有根基。
3. 建模范式选型：ReAct、Plan-and-Execute与“反思—自愈”闭环
3.1 三种主流范式的本质区别
多Agent系统里每个Agent的“思考方式”并不是同一个模子刻出来的。我一般会在生产环境里混用三种建模范式：ReAct、Plan-and-Execute和反思式。
ReAct（Reason + Act）：核心是“边想边做”的循环——模型先根据当前观察推理下一步动作，调用工具，拿到新观察后再推理，直到完成任务。它非常灵活，适合执行层Agent，比如“SQL生成Agent”先看表结构、再写查询、再看执行结果、然后迭代修正。生活化的类比是一个开车的人：盯着路况，随时调整方向，不预设死路线。
Plan-and-Execute：核心是“先规划后执行”——一个Plan Agent先把大任务拆解成有序的子步骤，再由执行Agent按步骤完成。它的优势是过程可控、便于追踪，也适合需要遵守SOP的流程，比如合同审核、工单处理。类比是先看地图定好路线，再照着走，走的过程中只做必要微调。
反思—自愈（Reflection）：在Agent完成输出后，由一个独立的质检Agent（也就是“Evaluation智能体”）对结果进行审查，发现异常后把反馈重新交给执行Agent修正。这有点像一个写手交稿、编辑打回修改的过程。代价是额外的模型调用成本和延迟，但如果任务容错率低（比如SQL结果要用于经营决策），这笔额外开销非常值得。
3.2 工程落地时如何混合使用
实际工程项目里，我几乎从不在一个Agent里只用单一范式。典型的分层是：顶层用Plan-and-Execute做任务拆解，中层执行Agent用ReAct做工具调用和迭代，底层或旁路挂一个反思Agent做质量把关。
拿问数智能体作为例子：用户问“对比去年同期和今年的销售增长，并解释主要变化因素”。Plan Agent先把任务拆成“取数”“算增长”“归因分析”三步；取数阶段由SQL生成Agent用ReAct模式迭代查询；生成结果后，质检Agent会独立检查SQL是否走了正确的时间口径、数字是否与报表系统一致；发现口径错误就带着具体反馈打回执行层重跑。这样一个混合链路，既保留了ReAct的灵活性，又通过Plan保证了流程的可追踪性，最终还有反思层为结果兜底。
需要提醒的是：反思Agent本身也是模型，也会出现判断偏差。所以我们要求质检Agent的反馈必须结构化——“问题类型、证据、修改建议”，而不是给一句模糊的“请再检查一下”。这样执行Agent才能有效理解并修正，也方便后续复盘时分析质检质量。
3.3 一个不可忽视的问题：Agent循环的失控风险
范式选得再好，也拦不住Agent在某些输入下陷入循环。我遇到过的典型失控场景包括：ReAct Agent反复执行同一个无意义的工具调用、反思Agent和生成Agent之间互相踢皮球、Plan Agent拆分出冗余的子任务导致执行数量暴涨。
工程防护上，我建议至少设置四道闸门：第一，最大步数限制，任何Agent执行超过预设步数直接终止并报警；第二，预算控制，按token消耗、工具调用次数做费用上限，超出后走人工审批；第三，冗余观察检测，如果Agent连续N轮的工具调用和输出高度相似，就判定为“空转”，强制中断；第四，关键节点人工审批，涉及写操作、发消息、删除数据等高危动作，编排器必须停下来等待人工确认。说到底，多Agent系统的“智能”永远需要确定性安全的骨架撑着，骨架断了，智能就是灾难。
4. 上下文与状态治理：多Agent最容易翻车的地方
4.1 上下文窗口的本质限制
我把上下文窗口比作一张办公桌：模型能同时处理的信息，不可能超过桌面能摊开的文件量。很多团队在多Agent系统中翻车，不是因为某个Agent的能力不够，而是因为没有管理“桌面上到底放了什么”。
多Agent场景下，上下文污染尤其致命。一个用户在问答过程中产生的历史信息、中间结果、无关工具调用日志，如果被复制进了另一个Agent的Prompt，轻则让模型注意力分散，重则直接改变决策。我们踩过一次很深的坑：问数智能体在处理长对话时，把上一轮SQL中间结果当作本轮的表结构提示词传给后续Agent，结果模型按照错误的结构生成了完全不存在的字段查询，连续报错。
因此我坚持“最小上下文原则”：每个Agent只接收完成任务所必需的信息，不把共享上下文当默认选项。跨Agent传递信息时，宁可多定义几条明确的消息字段，也不要图省事直接把整包信息塞过去。比如“意图澄清Agent”只需要把“用户确认后的业务条件”转递给SQL生成Agent，前面几轮澄清过程的历史对话一个字都别带过去。
4.2 记忆分级与存储策略
既然不能把所有东西都塞进上下文，记忆就需要分级管理。我把多Agent系统的记忆分为三层：执行记忆、工作记忆和长期记忆。
执行记忆指单次任务运行过程中的中间状态，比如“当前拆解到第几步”“执行结果暂存区”。这类记忆存在运行时数据流里，任务结束即释放，绝不做持久化。工作记忆指一个任务会话内需要在多个Agent间共享的业务上下文，比如用户画像、业务筛选条件、已经确认的口径规则。这类记忆通常存进会话级的Redis或状态存储，并且有TTL（过期时间）。长期记忆指跨会话复用的知识，包括业务知识库、历史案例库、用户偏好，这类信息量巨大，不能直接塞Prompt，必须通过向量检索或规则检索按需提取。
记忆分级的核心道理是：让Agent永远只看到该层的记忆。这也是治理体系里“记忆权限”的一部分——长期记忆的统一出口是一个记忆服务，任何Agent要读取，必须通过API并按权限过滤，而不是直接连数据库翻历史记录。我在一次架构评审里看到某个Agent直接读取了全量历史工单的原始文本，单是token费用就高得离谱，更别说隐私风险有多大。
4.3 状态一致性与竞态问题
多Agent并行处理同一业务实体，是工程上最容易遇到竞态的环节。两个Agent同时给同一个客户创建工单、更新状态、写备注，如果没有约束，数据大概率会乱。
我们的处理方案有三个层次。第一层：写操作收口，Agent不能直接写业务库，只能调用统一的领域服务，由服务层做并发控制。第二层：版本号或乐观锁，写操作必须携带预期版本，版本不一致就拒绝并回到编排器重新同步状态。第三层：Saga补偿，当多步操作在中途失败时，由小组件定义补偿动作把系统恢复到一致状态。这套思路和分布式事务类似，但Agent引入的不确定性更高，因为“下一步该做什么”是由模型决定的，不是一个固定的状态机。所以我会额外要求每个Agent的状态转移记录可审计，谁在什么时候基于什么输入修改了什么数据，必须全程留痕。可审计是治理的前提，没有状态可追溯，后面出了事故连复盘都无从谈起。
5. 治理体系的设计清单：可观测性、安全边界与评测门禁
5.1 可观测性：给Agent装黑匣子
多Agent系统的排障难度比单体高一个量级，所以可观测性不是附加功能，而是第一优先级的基础设施。我们把它拆成三个日志层次：运行日志、推理日志和行为日志。
运行日志记录Agent的启动、结束、资源消耗、调用延迟，定位性能问题时看这层。推理日志记录每个Agent收到和生成的完整Prompt与响应，包括token数、模型版本、温度等参数，复现模型行为问题时看这层。行为日志记录每个Agent做出的关键决策动作——调用了哪个工具、传了什么参数、返回了什么结果、是否触发重试或终止条件，审计和业务合规时看这层。
三层日志必须通过同一个Trace ID串起来。一次用户请求经过“意图解析Agent→数据权限Agent→SQL生成Agent→执行Agent→质检Agent”，五层链路必须能通过一个ID全部关联，否则排障就是在猜谜。我见过不少团队，日志倒是打了，但每个Agent一个独立的request_id，跨Agent追踪靠肉眼匹配文本，那基本等于没有可观测性。实操上我们直接给Agent框架层注入日志，而不是靠每个Agent开发者自己记得打日志——框架统一记录，业务只需关注业务数据。
5.2 安全与权限：工具调用边界、数据脱敏与代码执行沙箱
多Agent系统把“模型的能力”和“业务的操作权”连接到一起，权限控制必须比传统系统更严格，因为大模型偶尔会突发性地“误解指令”或者被提示词注入。
工具权限矩阵是第一道防线。每个Agent只能调用注册表里登记过的工具，而且工具级权限还能细分——比如“SQL生成Agent”只允许查询元数据表和生成SQL文本，“数据访问Agent”才能执行只读查询，“数据导出Agent”才拥有写文件权限。整个链条上没有任何一个Agent拥有跨全链路的完整权限。“权限最小化”不是保守，而是对多Agent系统安全性的基本尊重。
数据脱敏必须在进入Prompt之前完成。我们的原则是，大模型不需要看到的数据，就绝不放进上下文。用户手机号、证件号、内部薪酬字段，如果在Agent执行过程中确实需要，也要先经过脱敏转换——比如只给后四位，或者只在专门的受控服务里传递加密令牌。另一个高风险点是代码执行。任何让Agent生成并执行的代码（SQL、Python脚本）都必须放进沙箱，限制网络访问、文件系统只允许指定目录写，并且执行超时强制杀掉。我们线上环境里发生过Agent生成的SQL因为计算量巨大差点拖垮数据库的事故，从那以后所有SQL执行都走了查询超时控制和资源限制，这个必须做死。
5.3 评测与回归：多Agent的“考试制度”
治理体系里最容易被忽略、也最不该被忽略的，是Agent系统的评测与回归。没有评测，你就没有办法回答“这次改动是变好了还是变坏了”这个问题。
我把评测分为三个层次：单Agent技能评测、多Agent协作评测、端到端业务评测。单Agent评测针对具体能力，比如SQL生成Agent的正确率、归因解释Agent的回答是否完整；多Agent评测关注协作行为，比如一个携带金额确认条件的请求能否正确路由到权限Agent而不需要重复问用户；端到端评测覆盖完整业务链路，模拟真实用户的完整会话流程。
评测数据集是这套体系的核心资产。我会刻意把线上真实用例过录下来作为种子集，再分成三组：正常输入、边界输入（含糊请求、超大请求、敏感请求）和对抗输入（提示词注入、诱导越权）。每次修改完任何Agent的Prompt或架构配置，都必须跑一遍完整评测，对比正确率、流程合规率、平均耗时和token消耗。这其实也就是常说的Evaluation智能体的应用思路：把质检Agent做成评测闭环的一等公民，而不是事后补丁。只有建立了这种“改一下—跑评测—看回归”的循环，多Agent系统才不是一座持续积累技术债的纸牌屋。
6. 从单体到多Agent的迁移路径：演进顺序与组织保障
6.1 渐进式改造：不要一步到位
多Agent系统的迁移我坚持“渐进式改造”，反对一步到位的所谓“Big Bang重构”。最稳妥的路径分四步走。
第一步，单Agent加工具库，同时补齐统一日志和基础可观测性。先摸清楚现有系统里哪些环节最不稳定、哪些能力可以独立抽出，这一步是摸底。第二步，引入编排器，把最核心的一个职责拆成两个Agent——比如先拆一个“规划Agent”和一个“执行Agent”。跑通这一条最小协作链路，你才真正体会到通信、路由、状态同步的工程细节，也才能制定出后续的拆件规范。第三步，沉淀共用基础设施——Agent注册中心、统一记忆接口、统一评测框架，这些事情不一定要第一天全做，但第二阶段跑通后必须补上，否则Agent多了根本管不过来。第四步才是规模化扩展，按已经跑通的模式复制到更多业务域。
我见过一个团队试图一次性把所有业务线都Agent化，两个月后光Agent数量就到了30多个，结果互相之间消息乱飞、权限交错、评测也没跟上，最后被迫回退。渐进式改造的本质是允许你在小范围内犯错、学习、修正，而不是在一个尚未被验证的架构上豪赌一把。
6.2 团队角色与能力建设
多Agent工程落地，本质上是团队建模方式的重构。纯粹的开发团队如果不改变工作模式，很容易陷入“人人都在调Prompt、却没人对系统整体负责”的混乱状态。
我建议至少设置四类角色：架构师负责Agent边界和协作模式的定义，这是系统的“总设计师”；提示词工程师负责每个Agent的Prompt版本和工具说明维护，把Prompt当代码一样做版本管理和评审；可靠性工程师负责可观测性、监控告警、沙箱和权限模块；评测工程师负责评测数据集维护和回归分析。规模小的团队可以让一人兼任多职，但职责划分必须明确。
这里我想特别强调一下：Prompt和Agent配置必须纳入Git管理。一个Agent的行为不光由代码决定，还由提示词、工具描述、记忆策略、模型参数共同决定，这一整套配置要能回溯到任何一个历史版本。很多公司的架构方法论文档写了一堆漂亮话（HR共享盘里那些“架构设计方法.pptx”就是典型），但真正让系统变好的，不是某一次顶层设计，而是每天“改配置—跑评测—看Trace—调角色边界”这个枯燥循环的持续积累。方法论要落地，靠的是这个循环，不是一叠评审PPT。
6.3 平台化展望：Agent运行时、注册中心与统一网关
当系统里的Agent数量超过十几二十个，平台化建设就会成为必然需求。Agent运行时、注册中心和统一网关这三件套，是规模化演进的大方向，但不建议第一天就上。
Agent运行时主要解决生命周期问题——Agent的启停、扩缩容、优雅下线、版本热切换。注册中心维护每个Agent的“角色四件套”元数据和健康状态，让编排器能够动态发现可用的Agent，而不是写死调用地址。统一网关承担统一的鉴权、限流、可观测性接入和审计日志，所有Agent之间的通信都经由网关，而不是点对点直连。我个人的建议是：先把日志、Trace和基础评测做扎实，再逐步引入这三件套。没有统一日志和评测体系打底，平台化建设越早、越大概率是给混乱的系统再加一层抽象，而不是真正的治理。
这一周的实际体会是，多Agent系统成功的标志不是“Agent数量很多”，而是“系统在保持智能性的同时，依然可以被理解、被预期、被修正”。换句话说，一个治理良好的多Agent系统，应该像一支配合默契的团队——每个人只知道自己的职责和最相关的信息，但整体产出高质量的结果；而不是一个所有人把所有信息都共享给彼此的会议室，热闹但无序。
如果要我给一个最具体的起步建议，那就是：从两个Agent开始，跑通一条真实的业务链路。先把编排、路由、日志、评测这四个环节的闭环建立起来，再考虑第三个Agent应该拆谁。还有一个小技巧：设计评测用例时，把一个Agent原本可以独立完成的任务故意拆成多Agent协作题，用来测协作链路是否真的在增值，而不是在拖慢系统。这套方法，不保证让你成为架构大师，但能让你在工程落地的路上少踩几个真正的坑。
