上周我又处理了一类听起来很“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只处理一种类型任务定义清晰的输入输出最小通信面上下文污染、无关信息干扰判断结构化消息只携带必要字段禁止传递全量历史显式状态状态所有权混乱、任务悬空全局状态统一存储读写走接口记录状态归属可回滚失败后无法恢复、只能推倒重来关键步骤保存产出物支持跳过和重放可观测出了问题找不到原因全链路trace_id、日志、指标、耗时记录这些原则单独看都不难难的是在每一个设计决策里都坚持执行。比如设计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消耗和较长延迟不适合实时性要求高的场景。我把判断对照表也放在这里方便你评审时快速做决定协作模式稳定等级适用场景典型风险编排模式高任务并行、需集中校验、长流程主控单点故障、主控Agent误判管道模式高固定顺序、依赖明确、流程可校验单环节失败阻断整条链路协商模式低-中开放创意、多视角评审、歧义消解对话发散、立场固化、成本不可控实际操作里一个完整系统往往是三种模式的组合。比如一个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和ReaderOwner是唯一允许写入的AgentReader是允许读取的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预留专属配额保证核心链路不被边缘任务拖垮。再来一张降级策略参考表方便你对照设计故障类型常见表现应对策略示例调用超时Agent迟迟不给结果超时后重试最多2次文案生成超时后换备用模型连续失败Agent多次返回错误熔断并降级审核Agent降级为人工审核大模型限流429错误、排队变长限流排队降级低优先级任务转入慢队列输出格式不合规缺字段、类型错误Schema校验重试重试第2次后强制走修复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而是拿白板把任务拆解、角色边界、协作模式和失败预案画一遍。最后分享一个小技巧每次迭代都拿上一版真实请求回放一遍用自动化脚本对比输出路径和结果这比团队里任何“我觉得比之前稳定了”的口头判断都靠谱。