企业官网建设流程全解析

上周我又处理了一类听起来很“AI”的线上事故：一个多智能体系统里的两个AI agent互相聊了四十多个来回，任务目标从“写一份市场调研报告”偏移成了“挑剔对方用词”，最终产出一堆没人敢用的结论。这不是个例，凡是做过AI应用架构的人都大概率遇到过类似的场面——多个agent一开始各自分工明确，跑着跑着就变成了高成本的空转。作为AI应用架构师，如何设计一个稳定而不是碰运气的多智能体系统，已经不只是一个技术问题，而是项目能不能交付的底线问题。接下来我想用一次完整的设计复盘来聊聊这件事，内容包括任务拆解、角色设计、协作模式、状态与记忆管理、可观测性、故障恢复和排查实录。适合正在搭建AI应用、想让多AI协作真正落地的架构师和技术负责人，也适合备考系统架构师、但被大模型系统折腾得有点头晕的同学。

1. 先拆掉神秘感：多智能体系统到底在解决什么

1.1 别把多智能体当成“一群AI开茶话会”

多智能体系统这个词这几年被聊得很多，但很多人理解偏了，以为把几个AI agent丢到一起，给个目标，它们就会“自己商量着把事情办了”。做AI应用架构的人如果真按这个思路设计方案，上线后大概率会翻车。

多智能体系统本质上是一个软件系统，由多个AI agent围绕一个明确的业务目标进行分工协作。这里的agent不是聊天机器人，而是一个具备感知、决策、执行能力的计算单元，内部通常由大模型调用、工具调用、规则判断、记忆读写共同组成。传统单Agent调用是把prompt交给大模型，拿到输出就算完事；多智能体系统则要额外处理agent之间的调用关系、数据传递、职责边界、失败传播等问题。换句话说，难点不在单个模型有多聪明，而在于一群模型能不能像一个组织结构严密的公司那样各司其职地协作。

这个类比很关键。一家公司为什么能稳定产出产品？不是因为员工都很全能，而是因为岗位有分工、流程有边界、信息有格式、责任有Owner。多智能体系统也一样。如果只给每个agent说“你很聪明，你去解决这个问题”，那和你临时拉一群实习生在会议室里头脑风暴，几乎一样没有确定性。AI编程就是一个常见场景：需求分析Agent、代码生成Agent、代码审查Agent、测试设计Agent分别处理一个环节，谁产出什么、谁校验谁、错误反馈给谁，必须在架构里提前定义清楚。

很多准备系统架构师考试的同学跑来问我，多智能体系统算不算分布式系统的一种。我的答案是：算，而且是难度更高的那种——它把分布式系统里的通信、一致性、故障恢复，和大模型本身的概率性揉在了一起。认清这一点，就不会再用“Prompt写得好就能稳定运行”的思路来设计系统了。

1.2 那些“看起来在干活，其实在空转”的不稳定形态

先列几个我在生产环境里真实见过的故障表现，你再对照自己的项目，大概率能对号入座。

第一种是无限循环。两个agent发现对方结论里有漏洞，就开始一轮接一轮地“你说得对，但是……”，谁都不愿意先结束，最终消耗完预算和token，任务却没有任何进展。第二种是任务漂移。初始目标明明是从某份文档里提取关键字段，agent聊着聊着突然开始优化对方的文风，最后产出的内容和原始需求毫无关系。第三种是幻觉被放大。单个agent出错不可怕，可怕的是这个错误结果被下一个agent当成既定事实继续加工，错误就像滚雪球一样被层层放大。第四种是任务悬空。有的agent生成了结果，但没有任何机制确认下游是否消费了这个结果，最终输出躺在数据库里，用户看到的还是“处理中”。第五种是上下文污染。某个agent不小心把别人的历史、无关的分析过程全部塞进了自己的上下文，于是产出的结论混杂了大量干扰信息。

这些问题的根因高度一致：第一，大模型是概率系统，同一个输入在不同时间可能给出不同结果；第二，每个agent只看到了局部目标，无法感知全局目标；第三，缺少终止条件、状态同步和全局校验；第四，把上下文当成一个公共垃圾桶，谁都能往里扔东西，却没人负责清理。

架构师真正要做的事情，就是把“一群概率性的个体”放进“一个确定性的工程框架”。不要让agent之间用无限自由的语言互相影响，而是用明确的流程、接口、协议和检查点把它们连接起来。稳定不是说每个agent每次都要完美，而是无论agent中间怎么波动，系统最终都能回到正轨。

2. 稳定性的底层逻辑：能确定的流程，绝不交给大模型

2.1 把智能留给必要的节点，把流程还给代码

我见过很多架构师在搭建多智能体系统时，第一反应就是增加agent的数量和自由发挥空间：让agent自己决定先做什么后做什么，让agent自己判断该调用哪个工具，甚至让agent自己决定要不要把任务交给另一个agent。这种设计玩demo很爽，一到生产环境就变得极其难控。

核心原则其实只有一条：能通过代码和规则确定下来的东西，就不要用大模型来做。任务怎么拆、步骤顺序是什么、数据格式长什么样、哪一类异常该走哪条分支，这些都是确定性逻辑，交给代码；而文本理解、语义判断、内容生成、模糊推理这些非确定性的部分，才交给大模型。这就像导航系统：路径是算法规划好的，司机只在遇到突发路况时才做判断，不需要每次转弯都重新发明一遍交通规则。

反例我也见过不少。有些团队把所有决策都交给主控Agent去做，连“接下来调用哪个子Agent”都由大模型自由决定。这种设计意味着架构师放弃了控制权，把系统稳定性交给了模型当前的状态。模型状态好，系统就顺；模型状态差，整个任务就会开始原地打转。

我能理解这种设计冲动：因为大模型看起来确实很聪明，能干很多事。但生产系统的评价标准不是“聪明”，而是“可预测”。尤其是专利检索辅助、合规摘要这种容错率极低的场景，流程上每一步都必须可靠，AI只能负责理解、提炼和生成，绝不能负责“决定要不要执行这一步”。

2.2 五条设计原则，先背下来再谈创新

如果你现在正准备设计多智能体系统，我建议先把这五条原则写在架构文档第一页。

第一，单一职责。每个agent只负责一个明确的能力域，不要让需求分析Agent顺便干代码审查，更不要出现一个“什么都能干”的超级Agent。职责越单一，出了问题越容易定位。第二，最小通信面。两个agent之间只传递必要的信息，不要开放“全量上下文”，更不要允许agent之间进行无边界闲聊。第三，显式状态。全局状态放在统一的存储里，任何agent读写状态都要走明确定义的接口，谁写了什么，谁应该消费什么，记录得清清楚楚。第四，可回滚。每个关键步骤产生的结果都要留checkpoint，失败了至少能退回到上一个稳定状态重新执行，而不是只能从头再来。第五，可观测。每一次agent调用、每一次工具调用、每一次状态变更都要有日志，这是后面所有排查工作的前提。

我把这五条设计原则和它们解决的问题整理成一张表，方便你在方案评审时逐条自查：

这些原则单独看都不难，难的是在每一个设计决策里都坚持执行。比如设计Agent之间的消息结构时，多一个人为了“以后可能会用到”而塞进一个字段，就是违背“最小通信面”。又比如为了让演示效果更流畅，允许agent直接读取另一个agent的全部历史输出，就是违背“显式状态”。这些看似微小的妥协，最终都会变成线上事故的一部分。

2.3 稳定性等级：不同场景配不同的自由度

不是所有业务场景都需要同等程度的稳定性，也不是所有场景都适合用最严格的流程来限制agent。我在实际项目中习惯把多智能体系统的自由度分成四个等级，先判定业务属于哪一级，再决定agent自由发挥的空间有多大。

L0是完全规则化，所有分支判断都由代码完成，大模型只做一些固定语义的理解，比如短文本分类、关键词抽取。L1是单Agent低风险决策，在极有限的输出范围内让大模型做一次判断，比如根据模板生成一段摘要。L2是多Agent编排执行，任务由多个agent按固定工作流协作完成，每一步的流程是确定的，agent只负责自己环节内的高质量生成。L3是开放式协商，多Agent之间可以讨论、反驳、产生新方案，典型场景是创意策划、头脑风暴。

判断业务场景适合哪一个等级，主要看两点：一个是业务容错率，另一个是任务结构清晰度。容错率越低，越要往L0和L1靠；任务结构越清晰，越可以用L2的编排模式去实现高产出。反过来，如果业务本身就是探索性的，比如给某个新品牌起名、生成视频创意脚本，那也不要强行做L0，否则只会让系统产出极其平庸。稳定不等于死板，作为架构师，你的任务是给合适的业务匹配合适的稳定等级。

3. 任务分解与角色设计：先把组织结构图画出来

3.1 先用DAG把任务编排画出来，再谈Agent

很多多智能体项目失败的起点，不是Agent不够强，而是任务本身没有拆清楚。需求方只说“帮我做一个内容生成平台”，架构师就急着选模型、写Prompt，最后agent之间怎么配合完全靠“临场发挥”。这里我强烈建议先画一张有向无环图，也就是DAG：把一个大目标拆成若干个子任务，标明每个子任务的输入、输出、前后依赖关系，确保图上没有回环。有了这张图，Agent只是“执行某个子任务的工人”，而不是“决定整个流程的指挥者”。

做AI短剧或AI视频生成流水线就是一个很好的例子。一个完整的“脚本生成—分镜设计—视频片段渲染—配音合成—质检合成”流程，必须先由架构师定义清楚每一步的产物格式和传递方式。脚本Agent输出的是结构化的分场表，分镜Agent消费分场表输出镜头列表，渲染Agent消费镜头列表生成片段，质检Agent再对片段做检查。每一步都是前后依赖的直线关系，而不是让所有Agent一起在一个群里自由讨论。

任务清单落到工程代码里，至少需要一个类似这样的结构化定义：

{ "workflow": "video_generation", "tasks": [ { "task_id": "script_agent", "type": "llm_agent", "input_schema": "brief", "output_schema": "scene_list", "next": ["storyboard_agent"] }, { "task_id": "storyboard_agent", "type": "llm_agent", "input_schema": "scene_list", "output_schema": "shot_list", "next": ["render_agent"] }, { "task_id": "render_agent", "type": "tool_agent", "input_schema": "shot_list", "output_schema": "video_segments", "next": ["qa_agent"] } ] }

这张图一旦固定下来，每个Agent能“自作主张”的范围就被天然限制住了。它不能跳过前面的步骤，不能任意增加步骤，不能跑着跑着换目标。稳定性，从这一步开始就有了根基。

3.2 角色卡：给每个智能体立一份岗位说明书

任务画完，接下来要做的不是立刻写Prompt，而是先设计角色卡。角色卡相当于每个agent的岗位说明书，它规定了这个agent能做什么、不能做什么、必须产出什么格式、遇到什么情况应该停止或上报。没有角色卡，你就等于给一个员工分配了岗位，却不告诉他职责边界，那他不乱跑才怪。

我设计角色卡时一般包含这几块内容：职责范围、输入输出Schema、禁止行为、可用工具、升级与终止条件、风格要求。以代码审查Agent为例，职责范围是“对代码变更做静态审查与逻辑检查”，输入是“代码diff和需求描述”，输出是“问题列表JSON”；禁止行为包括“直接修改代码”“与开发者讨论产品需求”“引入未经验证的依赖”；终止条件是“清单不足以支撑审查时，明确请求补充材料，最多请求一次，然后结束本轮”。

这里必须强调输出Schema的重要性。很多团队的角色卡只写“你是一个资深的代码审查专家”，然后让agent自由输出Markdown。下游解析时一团乱麻。正确做法是规定输出字段名、字段类型、必须存在的字段，再用代码做一次校验。agent输出不满足Schema时，宁可让它重新生成一版，也不要抱着侥幸心态继续往下游传。

角色卡写完后，最好让两个不同工程师背靠背独立阅读，再看看能不能用同一句话描述清楚这个agent的职责。如果两个人描述出来的职责有出入，那说明角色卡写得还不够清晰。一个清晰的agent角色，不应该是“理解文档并回答问题”，而应该是“读取指定文档中的字段A、字段B，输出一个包含字段C、字段D的JSON对象，字段E缺失时标记为unknown”。

3.3 Agent粒度怎么切，才不至于拆崩掉

任务拆解和角色设计过程中，最常被问到的问题就是：一个Agent到底应该多大？拆得太粗，又会走回“全能Agent”的老路；拆得太细，每个环节都在调用大模型，延迟和成本急剧上升，信息在传递中不断失真。这个问题没有标准答案，但我有一条实践了多次的经验：以“一次独立的智能判断”为最小粒度。

什么叫做一次独立的智能判断？就是“给定某类输入，AI能自行完成的一个完整、可验证的判断动作”。例如，把一段需求文本拆成结构化需求列表，这是一次独立判断；根据某个需求生成测试用例，这也是一次独立判断。但“把需求梳理清晰后顺便把代码也写了把测试也补了”就不算，因为这里混了三类判断，也对应了三个可以独立验证的产物。

经验是先粗后细，不要一次拆到底。第一版先跑一个最小闭环，哪怕只有两个Agent，先验证流程是否走得通，再逐渐把大的Agent拆成细的。每次拆分都应该有明确理由：要么是原Agent输出质量不稳定，要么是某一职责需要单独复用，要么是某个环节需要独立的观测点。如果拆分后并没有让系统更可控，那说明这次拆分只是为了“看起来架构更漂亮”，属于过度设计。

4. 协作模式选型：不同协作方式，稳定等级不同

4.1 三种主流协作模式，稳定度天差地别

任务拆出来后，紧接着要回答一个问题：这些Agent之间到底怎么配合？常见的协作模式可以归成三类，它们带来的稳定度、实现成本和适用场景差别非常大。

第一种是编排模式，也叫主从模式。主控Agent或代码调度器负责拆解任务、分配任务、汇总结果，执行Agent只负责完成分配给自己的那一份工作，彼此之间不直接通信。这种模式的稳定度最高，因为控制流集中，哪里有异常，主控一看就知道。缺点是主控可能成为瓶颈，如果主控本身也是一个Agent，它的判断质量会直接影响全局。第二种是管道模式。Agent按固定顺序串联，前一个输出变成后一个输入，就像流水线一样。这种模式结构清晰、并发控制简单，适合内容审核、数据处理、代码生成等流程固定的场景。缺点是流水线上任何一环出了问题，整条流水线都会停下来，所以每一环都需要单独校验。第三种是协商模式，多个Agent就同一议题轮流发表意见、互相点评、最后投票或汇总。这类模式在处理开放性问题时效果好，比如方案评审、需求澄清、创意发散，但它也是最难稳定的，对话轮数、立场冲突、舆论偏见都可能导致结果发散。

以AI测试开发为例，如果想要让一个Agent生成测试用例、另一个Agent执行测试并分析失败原因，采用管道模式就非常合适，因为执行结果必须依赖用例生成结果，两步之间有强先后关系。但如果是要对一份软件需求文档进行“需求歧义消解”，让需求Agent、产品Agent、测试Agent一起讨论歧义点，那协商模式反而更能暴露问题。

4.2 按任务特征选模式，别凭感觉排兵布阵

选择协作模式不能凭直觉，要看几个硬指标。第一个指标是任务依赖关系：如果子任务之间存在严格的先后顺序和输入输出依赖，优先选管道模式；如果任务可以并行分发，优先选编排模式；如果任务本身就是多视角论证型的，再考虑协商模式。第二个指标是容错能力：每一环错误造成的后果是否可接受。不可接受的话，选编排模式，因为主控可以在每一环结束后做校验。第三个指标是对延迟和成本的敏感度：协商模式会产生大量token消耗和较长延迟，不适合实时性要求高的场景。

我把判断对照表也放在这里，方便你评审时快速做决定：

实际操作里，一个完整系统往往是三种模式的组合。比如一个AI建站系统，可以用编排模式来处理“用户需求解析”，用管道模式处理“页面生成—样式渲染—内容校验”，再用协商模式来处理“文案A/B方案评审”。关键是每个局部都能说清楚自己采用的是哪一种模式，而不是整条流程混成一锅粥。

4.3 通信协议做小做严，拒绝无边界闲聊

多智能体系统稳定性差，还有一个非常重要的原因：Agent之间用的是自然语言闲聊。自然语言天然有歧义、冗余、环境依赖，同一句话在对话进行到第5轮和第20轮的时候，语义可能已经完全不一样。两个Agent一旦用自然语言“聊开了”，很快就没人记得真正要交付什么结果。

所以我在设计通信协议时，坚持用结构化消息而不是自由文本。每个agent之间的消息至少包含：sender（发送方）、receiver（接收方）、intent（意图，比如request、response、error）、payload（结构化数据）、request_id（请求唯一标识）、expect（期望的返回类型）。消息体里的payload字段必须是明确的JSON，而不是一大段自然语言描述。agent接收到消息后，第一件事是校验消息结构，而不是直接读内容。

同时要限制对话轮数。即使是协商模式，也必须在协议里写死最大轮次，比如双方最多各发表三轮观点，然后进入投票或汇总阶段。我在系统里一般设置一个“对话熔断器”，当某一对agent之间的往来消息超过N条，自动停止它们之间的直接通信，并把未决问题升级到主控或人工。这个机制成本极低，但能避免绝大多数“AI聊到失控”的事故。

5. 状态管理与记忆：稳定系统的“记忆中枢”

5.1 全局状态和局部状态：谁的数据谁来写

多智能体系统跑起来之后，一定会面临一个分布式系统里的经典问题：状态存哪里、谁更新、谁读取。如果不在一开始就定义清楚，就会出现两个agent同时修改同一个业务字段，导致数据互相覆盖；或者某个agent写了一份重要产出，但没有任何标记告诉下游“这份产出已经就绪”，下游还在傻等。

我的做法是引入一个全局工作区，用键值存储的方式保存每个任务节点的状态。这个全局工作区相当于项目协作里的共享文档库，agent不直接互相读写内存，而是通过工作区读写自己有权访问的key。例如，脚本Agent产出“scene_list”后写入workflow_state.scene_list，分镜Agent只读取这个key，渲染Agent再读取分镜输出的“shot_list”。每个key都登记Owner和Reader，Owner是唯一允许写入的Agent，Reader是允许读取的Agent名单，其他agent无权访问。

这种做法带来的好处很直接：状态的所有权清晰，数据冲突被消灭在结构层面；任务的中间过程能被随时检查，哪个环节成功、哪个环节失败一目了然；系统重启后，agent可以从工作区恢复现场，而不需要从头再来。你会发现这和分布式系统里的共享存储设计是同一个道理，只是这里的数据单元从“表记录”变成了“Agent产出物”。

5.2 上下文管理：不要什么都塞进这段对话

大模型上下文窗口是有限的，动不动把全部历史、全部中间结果、全部业务规则塞给每个agent，后续一定会遇到性能下降和输出质量恶化的问题。上下文膨胀不是“多花点钱”的问题，而是agent会逐渐被无用信息淹没，开始关注错误重点。

我需要把信息分成三层来管理。第一层是短期上下文，也就是当前步骤需要的最小信息集，例如生成代码时只需要相关的需求片段和接口定义，不需要整个项目的所有文档。第二层是工作记忆，指整个工作流运行过程中产生的中间状态和结论，这部分放进全局工作区，只在相关步骤被读取，用完即可释放。第三层是长期记忆，指与业务相关的静态知识库，例如编码规范、产品说明、历史常见问题，这部分应该通过检索按需注入，而不是把整个知识库都复制到每个agent的上下文里。

很多团队的产品已经有“AI聊天记录”功能，如果你在做多智能体系统，千万别把这种聊天记录原封不动地当作多Agent的上下文。聊天记录是给人看的，它包含大量无结构信息；而agent的输入应该是对应任务Schema所要求的最小字段集合。我通常会在每个agent前面加一个“上下文打包器”，专门负责从工作区中提取它需要的字段，再交给大模型。打包器本身是一段确定性代码，而不是另一个自由发挥的Agent。

5.3 中间产物物化与幂等：让失败可以从头再来

多智能体系统跑了十几分钟，最后一步失败，如果意味着要全部重来，这种设计在生产环境根本不可用。更合理的方式是让每一步的产出物都“落盘”，也就是物化。无论是大模型输出的一段文本、一个JSON、一张图片，还是工具调用的结果文件，都在生成后写入持久化存储，并记录状态。

有了物化的中间产物，重试就变成了局部操作而不是全局操作。比如管道模式里，步骤3失败了，步骤1和步骤2的结果还在，那么我们只需要重新执行步骤3，而不需要重新调用步骤1和步骤2的Agent。这一步看似简单，却在复杂任务里能替你省下大量时间和成本。

同时必须考虑幂等性问题。如果步骤3因为网络超时重试了两次，那么步骤3的产物应该只生成一份，而不是三份重复结果。我的做法是为每个任务节点生成一个request_id，写入结果时检查这个request_id是否已经存在，存在就跳过写入。Agent读到时，如果发现当前节点状态已经是success，就直接返回上一版结果。多智能体系统里只要有写入动作，就必须考虑幂等，这和我们在订单系统里防重复支付的逻辑一模一样。

6. 可观测性与故障恢复：让系统坏得明明白白

6.1 给每次智能体调用一张贯穿始终的身份证

多智能体系统调试起来极其痛苦，因为一个任务可能经过十几个Agent、几十次大模型调用，如果每次调用之间没有关联标识，出了问题想定位是哪一环，简直像大海捞针。我强烈建议从系统设计第一天就引入trace_id，贯穿整个工作流的所有关键路径。

每次业务请求进入系统时，生成一个全局唯一的trace_id，后续所有Agent调用、工具调用、状态更新、日志记录都把这个trace_id带在身上。日志内容不仅要有大模型的输入输出，还要记录模型名称、版本、prompt模板版本、温度参数、token消耗、调用耗时、返回状态码。日志的格式要尽量标准化，至少能够被日志系统一键过滤出某个trace_id下的全部事件。

我甚至建议连prompt内容都保存起来，因为多智能体系统的prompt是运行时动态拼装的，如果只保存“最终生成结果”而不保存prompt版本，后续排查“为什么这次输出和上次不一样”时，只能靠猜。记录prompt版本和模型版本，等于给每个Agent的状态打上了指纹，再配合trace_id，整个系统的行为就变得可回放、可验证。

6.2 超时、熔断、限流、降级：一套完整的失败预案

多智能体系统里的Agent调用大模型时，可能遇到延迟、超时、限流、乱码、拒绝回答、返回空内容等异常。如果每个异常都要人工介入，那系统基本没法跑。必须在架构层面准备好一套完整的失败预案。

超时策略比较容易理解：每次Agent调用设置一个最大等待时间，超过阈值就按失败处理。重试策略要考虑重试次数和退避策略，遇到瞬时抖动可以快速重试，但连续失败超过两次之后，应该停止盲目重试，进入降级流程。降级方案取决于业务场景：如果Agent只是生成文案，可以退回到更简单的模板；如果Agent是负责内容审核，可以跳过它的自动结论，改为人工审核队列；如果Agent是负责自动翻译，可以先返回原文并标记“待翻译”。

如果系统里同时有多个Agent在并发调用同一个大模型，还需要限流。大模型API有QPS限制，超了会被拒绝或拖慢。架构师必须为每个Agent配置独立的限流阈值，防止某一个Agent突发任务占满所有配额，饿死其他环节。我在项目里一般会给高优先级Agent预留专属配额，保证核心链路不被边缘任务拖垮。

再来一张降级策略参考表，方便你对照设计：

6.3 用AI测AI：在真实任务里做稳定性验证

很多人写完多智能体系统就上线，等线上出事故再开始补监控，这种做法我吃过亏。多智能体系统的稳定性不是调出来的，而是测出来的。与其等线上跑翻车，不如提前把故障注入进去。

具体做法有几种。第一是准备一套回归数据集，尽量采集真实业务请求，以及人工标注的“预期输出关键字段”，每次系统迭代后都用这套数据集跑一遍，对比输出是否稳定。第二是做边界测试，可以专门让一个AI测试Agent生成一些反常识、信息缺失、格式混乱的输入，用来验证系统面对坏数据时会不会崩溃。第三是模拟故障，比如让一个Agent随机返回超时或空结果，观察整个工作流会不会卡死、能不能自动降级、告警有没有触发。

这里有一个容易被忽略的点：多智能体系统测试不只要看“最终输出对不对”，还要看“路径是否稳定”。同一个任务，上上次是通过编排Agent走A路线完成的，上次却因为某个条件变化绕了半天B路线。虽然结果都是success，但这不是好现象。稳定的系统，应该是在给定相同输入的情况下，尽量走相同的路径。测试结果里如果发现路径漂移频繁，说明系统里可能混入了太多的“自由决策”，架构师需要把这些决策替换回确定性逻辑。

7. 常见故障与排查实录

7.1 两个Agent陷入无限循环对话

这是我接手过最多的故障类型，现象也很典型：Agent A说“你的方案有一个逻辑漏洞”，Agent B说“你说得有道理，但我认为原方案依然可行”，Agent A又说“在你的解释中我发现了新的问题”，Agent B又回复……如此往复。从日志看，两个agent的对话轮数已经达到几十轮，每轮都在调用大模型，成本在燃烧，任务没有任何实质产出。

排查时建议先看两点。一点是它们之间传递的消息是否真的在推动任务；另一点是它们的意图是否已经偏离原始请求。修复手段有几个：一是给每对agent设置最大对话轮数上限，超过直接强制仲裁；二是在消息intent字段里约定，同一个intent不允许重复发送超过两次；三是引入终止条件，任何一轮对话如果产出了新的结构化信息就继续，如果只是“观点重申”就强制停止。后续再升级的话，可以让一个独立裁判Agent介入，负责在对话陷入僵局时给出裁决。

7.2 任务漂移：聊着聊着目标就丢了

任务漂移比聊天死循环更隐蔽，因为系统表面上还在运行，每个agent也都在“干活”，但你最后拿到的东西根本不符合原始需求。我遇到过一个案例：系统目标是让AI Agent从客户邮件里抽取售后问题分类，结果跑了几个小时后，中间环节的Agent开始对邮件原文做情感分析，然后整个流程慢慢被改造成了“客户情绪洞察”，业务完全走偏。

根本原因在于agent的上下文里没有保持“原始目标锚点”。当任务执行到中后期，上下文充斥着各类中间结果，初始目标反而不显眼，模型就倾向于跟着上下文里的“局部兴趣点”走。解决办法是设计一个固定的“目标信息块”，每个Agent在生成输出之前，都先读取当前任务的原始目标、已完成步骤、当前步骤清单，再决定本轮输出。目标信息块不能放在很长的上下文中间，要作为消息结构里的一个固定字段反复出现。另外，在每一步结束后做一次“目标一致性校验”，让一个轻量Agent或规则脚本判断当前输出与原始目标之间的相关性分数，低到阈值就触发提醒。

7.3 上下文膨胀：系统越跑越慢，输出越来越水

多智能体系统跑了一段时间后，会遇到一种缓慢变坏的情况：latency不断升高，输出质量开始变得平庸，甚至出现回复内容自动重复。检查日志时发现，每个Agent的输入里都包含了极长的历史记录，有些甚至是几十轮之前其他Agent的中间思考。这不是大模型变笨了，而是你给它塞了太多无关信息。

解决上下文膨胀的办法不复杂：每次给Agent组输入之前，明确设置上下文窗口内容的最大长度；超过长度就自动做摘要，把旧信息压缩成几条关键结论；把真正的原始长文本放到外部存储，只有当Agent明确需要检索时按需取用。长期运行的系统，还应该定期清理全局工作区里已经消费过的临时状态，避免存储层无限增长。记住一句话：Agent的注意力是稀缺资源，别让它浪费在旧闻上。

7.4 输出格式漂移：下游解析越来越不可靠

这个故障几乎每个团队都会遇到：Agent第一次输出严格的JSON，第二次就可能输出带Markdown注释的代码块，第三次可能直接在JSON后面加了一段总结文字。即使prompt里写死了“只输出JSON”，模型在不同上下文长度、不同任务复杂度下也可能出现格式漂移。下游如果用正则或JSON.parse直接解析，系统就会频繁报错。

解决思路不是指望模型“更听话”，而是加一层硬校验。每次Agent输出后，先用代码校验格式和Schema；解析失败时，自动把错误信息和原始输出返回给Agent，要求它重新生成一版；如果重试两次还是失败，就转入修复Agent或人工处理。还可以在输出阶段给Agent配置一个“输出格式化工具”，把模型输出经过工具强制转成JSON后再传给下游。格式化工具是确定性的，不依赖模型的自觉，稳定性自然好很多。

8. 落地时候的几条“厨房经验”

8.1 第一版最多先跑两个Agent

很多架构师拿到多智能体系统需求后，第一版就规划出七八个Agent，看起来体系很完整，实际上调试复杂度会指数级上升。别高估模型在链条里的稳定表现，也别低估状态同步的难度。我的建议是第一版哪怕只跑“一个主控Agent加一个执行Agent”，也要先把流程走通，再慢慢加角色。两个Agent的系统里，排查问题只用看两边；五个Agent的系统里，你连失败是谁引起的都不一定能查清楚。多智能体系统是迭代出来的，不是规划出来的。

8.2 为换模型留好接口，别被一家模型绑死

大模型市场变化太快，今天用得顺手的模型，下个月可能出了新版本，也可能因为某个业务场景表现不佳要被替换。如果系统把模型调用直接散落在各个Agent里，换模型的时候就是一场灾难。我在项目中会封装一个LLMProvider接口，所有Agent都通过这个接口调用大模型，接口层负责记录日志、处理重试、监测版本、切换模型。这样换模型时只需要新增一个Provider实现，然后改配置就能生效，不需要动Agent代码。

8.3 一定要留一个人工回退的通道

自动化和自主性再强，也要保留“人工介入”的后门。我在架构里总会设计一个审批或编辑节点，当某个Agent的输出置信度不高，或者连续两次校验失败，工作流会停在某个中间态，等待人工编辑或确认。这不是向大模型能力妥协，而是给系统托底。多智能体系统上线初期，人工回退通道几乎是救命稻草。它让业务团队敢用自动流程，也让架构师有充足时间去打磨自动环节。

8.4 别为了多智能体而多智能体

最后一条经验是反常识的：不是所有任务都值得做成多智能体系统。如果一个简单问题用一个Agent加一套确定性规则就能解决，那就不要硬上多Agent。有些项目里的Agent之间根本没有真正的协作关系，只是把一个本来能串行完成的任务，硬拆成了多个模型调用，结果既不稳定，还更贵更慢。多智能体系统的价值在于处理真正复杂的、需要多角色专业能力配合的业务场景。如果业务不复杂，用最简单可靠的方案把事情做好，反而是架构师更成熟的表现。

从我自己的实践来看，设计稳定多智能体系统，本质上就是不断和“概率性”以及“复杂度”较劲的过程。我踩过的每一个坑都在提醒我：多做一层校验、多写一个超时、多留一份日志，远比多给Agent一次自由发挥的机会更实在。如果你正准备搭一套多Agent系统，建议先别急着写Prompt，而是拿白板把任务拆解、角色边界、协作模式和失败预案画一遍。最后分享一个小技巧：每次迭代都拿上一版真实请求回放一遍，用自动化脚本对比输出路径和结果，这比团队里任何“我觉得比之前稳定了”的口头判断都靠谱。