这两年跟多agent系统打交道多了一个感受越来越强烈单个agent是玩具多个agent协作才是工程。说句实话多agent系统是那种“听着很酷、做着很痛”的方向市面上讲demo、讲概念的文章一大堆但真正能落到生产环境、能承受线上流量和业务复杂度的方案少之又少。我最近刚把我们内部一个工单分诊场景从单agent重构为多agent协作架构整个过程走下来从架构设计到治理体系踩坑无数也沉淀了一套自己用起来比较顺的方法论。这篇就把这些经验完整梳理一遍给正在做多agent平台、或者正准备把多个agent接入生产系统的团队一个参考——尤其适合那些已经过了“单agent能跑通”阶段开始被协作、状态、可观测性等问题卡住的同学。1. 多agent系统为什么难落地先想清楚这三个问题1.1 多agent和单agent本质上是两种物种很多人以为多agent系统就是把几个agent堆在一起互相调用就行。这个理解是最大的坑。单agent的本质是一个闭环输入进来模型推理调用工具输出结果。你只需要关注这个环路的准确性。但多agent系统面对的是一个意图网络——任务进来之后要拆解成子任务分发给不同的agent收集结果再汇合、再判断整个过程是动态分叉的。我常用一个类比解释这种差异单agent就像一个全能型自由职业者一个人包揽需求分析、设计、开发、测试多agent系统则是一个项目组有人做产品、有人写代码、有人做QA。项目组的难点从来不是单个人强不强而是信息怎么同步、任务边界怎么划、风险谁来兜底。代码写挂了自由职业者自己修项目组里得先搞清楚是哪个环节掉的链子。这个差异直接决定了你在技术选型和架构设计上的思路完全不同。单agent你可以把逻辑都塞进一个prompt里让它自己规划多agent则必须面对“任务派发”、“节点间通信”、“状态一致性”、“分布式链路追踪”这些原本属于后端工程的问题。换句话说多agent系统首先是分布式系统然后才是AI系统。这个认知不建立起来后面的路会很难走。1.2 落地前必须想清楚的三个问题我见过不少团队一上来就搞了七八个agent结果跑不起来。根本原因是在动手前有几个关键问题没想透第一个问题你需要的到底是“多agent”还是“多流程”这是最容易混淆的。如果一个系统只是同一个模型配了多套prompt模板根据不同的输入走不同的分支那它其实是多流程单agent不是多agent系统。多agent的核心特征是每个agent有自己的状态、工具、决策权限并且它们之间存在真正的双向信息交互。判断标准很简单——如果业务上只是“不同场景给不同prompt”那就老老实实做单agent别为了架构噱头增加复杂度。第二个问题协作是必要的吗很多时候任务完全可以用一个精心设计的prompt完成强行拆成多agent只会引入大量无效的通信开销和不确定性。我之前见过一个知识问答场景团队拆了“搜索agent”“总结agent”“审核agent”三个角色跑一轮要调用三次模型中间还有信息丢失的风险。实际上同一个模型拿到搜索工具一步就能完成大部分需求。多agent应该用在任务本身存在清晰边界、不同步骤需要不同专业背景或不同工具集的场景而不是为了用而用。第三个问题失败成本有多高每个agent节点都意味着一次模型调用而模型调用是有概率失败的——可能输出格式不对、可能超时、可能跑飞进入死循环。节点越多失败的概率就越大而且失败会沿着链路传播。如果系统承载的是高频高并发的生产流量每个环节都需要做重试、降级、兜底。这个成本在设计之初就要算进资源预算里否则上线后会发现模型调用费用暴涨、响应时间不可控。2. 架构设计拓扑选型、消息协议与状态管理2.1 三类拓扑结构星型、链型和网格型多agent系统的架构设计第一件事是选拓扑结构。我把它归纳为三类星型、链型、网格型。星型拓扑也叫orchestrator-worker模式是生产环境中用得最多的。一个中心调度者orchestrator负责接收用户请求、拆解任务、分配子任务给各个worker agent、再汇总各worker的结果进行最终输出。这种模式的好处是控制权集中调度逻辑清晰方便做超时控制、重试和兜底。坏处是orchestrator本身容易变成瓶颈而且如果拆解逻辑写得不好中心节点就成了单点故障。链型拓扑也叫pipeline模式适合数据处理流。任务按固定顺序经过一个个agent每个agent处理完一个阶段就传给下一个。比如“信息抽取agent → 情感分析agent → 摘要生成agent”。这种模式好处是链路简单每个节点职责单一方便单独优化坏处是链路中任何一个节点出错后面就没法继续而且信息在传递过程中容易损耗。网格型拓扑各agent之间可以自由通信、互相调用。理论上最灵活符合“多agent自主协作”的理想图景但实际落地我强烈建议避开——自由通信意味着不可预测性呈指数级上升根本无法控制Agent A什么时候调用Agent B状态不一致和死循环的问题会让你崩溃。我的建议很直接生产系统超过80%的场景用星型拓扑剩下不到20%用链型。网格型少碰除非你的团队有极强的可观测性基建兜底并且业务本身对不确定性有很高的容忍度。2.2 消息协议多agent系统的通信契约既然多agent系统本质是分布式系统那agent之间的消息就得有明确的契约。我刚开始做的时候吃过亏——让两个agent直接传原始对话文本结果上下文越滚越大token费用暴涨效果还变差了。后来我总结了一套比较稳妥的消息结构每个agent间传递的消息都遵循这个格式{ session_id: uuid-xxxx, message_id: uuid-yyyy, agent_id: intent-router, message_type: task_assign, payload: { task_type: knowledge_retrieval, query: 用户提交的原始问题, context: { user_id: u_12345, department: 售后, priority: high } }, timestamp: 2024-06-18T10:30:00Z, trace_id: trace-uuid-zzzz }这套结构解决了我最头疼的几个问题session_id保证了同一个用户请求的所有agent协作属于一个会话message_type让每个agent知道自己收到的是一个任务派发、一个结果回传还是一次状态查询payload里只传必要信息不把整个对话历史塞进去trace_id是后面做可观测性的基础没有它线上出了问题你连查都查不了。这里有个关键设计原则agent之间传递的是结构化数据不是自然语言长文本。很多新手喜欢让agent直接用“人话”互相沟通看起来智能实际上非常脆弱——模型输出稍微有点歧义下游agent就理解错了。结构化payload可以降低这种歧义同时方便做日志审计和错误排查。2.3 状态管理别把上下文当成万能解法多agent系统中状态管理是最容易被低估的一环。每个agent在执行任务时都有自己的“记忆”——它看到了什么、做了什么、得出了什么结论。如果所有状态都靠上下文传递系统很快就会膨胀到不可维护。我实践下来的做法是把状态分成两层。第一层是全局状态放在中心存储比如Redis或数据库记录整个会话的进展——当前在哪个阶段、已经完成哪些子任务、收获了哪些关键信息。第二层是局部状态只存在于单个agent的执行周期内任务结束就丢弃。举个例子工单分诊场景里全局状态记录的是“用户的问题是什么、当前分诊到哪个部门、紧急程度如何”局部状态则是“意图识别agent在分析时参考了哪几条历史工单”。这样一来即使某个agent执行失败需要重试只需要重置局部状态不会影响整个会话的进展。还有一点很关键任何状态下发到agent之前都要设置一个大小上限。我一般控制在2k~4k token以内超出就截断或做摘要绝不让上下文无限膨胀。这个习惯帮我省下了大量token成本也让响应速度稳定了很多。3. 治理体系多agent系统能不能长期跑的真正分水岭3.1 可观测性没有Trace多agent故障就是“薛定谔的猫”多agent系统最折磨人的地方在于它的bug往往是概率性的、非确定性的。同一个请求上午跑是好的下午就错了参数一模一样的两次调用结果可能完全不同。这种情况如果没有一套完备的可观测性体系排查问题无异于大海捞针。我给多agent系统做的可观测性包含三个层次全链路Trace、结构化日志、运行指标。全链路Trace是整个体系的基石。每个请求都有一个trace_id贯穿所有agent调用。这样线上出了问题我可以直接查到这个请求经历了哪几个agent、每个agent的输入输出是什么、在哪一步耗时最长、在哪一步出现了异常。我通常会把每个agent的调用、每工具的执行都记录成一帧span挂在同一个trace下一眼就能看到完整的调用链。结构化日志是Trace的补充。每个agent执行完都会输出一条结构化的日志包含当前agent的id、输入摘要、输出摘要、调用的工具、用时、token消耗、错误信息。这些日志既用于事后排查也用于后续的离线分析和效果评估。运行指标则是宏观视角。我至少会盯四个指标任务成功率整个多agent流程完整走通的概率、单次任务平均耗时、模型调用token消耗量、各agent节点的失败率分布。这四个指标能帮助我快速发现系统的劣化趋势——比如某个worker agent的失败率突然从1%涨到10%那大概率是模型行为漂移或者输入数据分布变了需要及时干预。3.2 版本管理与回归测试让agent工程也告别“玄学开发”多agent系统的效果很大程度取决于prompt、模型参数和工具定义的组合。这三样东西任何一个变动都可能导致系统行为变化。但现实是很多团队还在用“改了prompt → 线上看看效果 → 不对再改”这种原始方式这是完全没有工程化的状态。我推荐的做法是建立一套类似软件工程的版本管理体系。prompt要有版本号工具定义要有版本号模型参数配置要有版本号。每一次改动都记录是谁改的、改了啥、为什么改、在哪个环境验证过。上线前必须经过回归测试——准备一组覆盖主要场景的测试用例集比如100条典型的用户问题跑一遍多agent流程比较结果和基准版本的区别。这里分享一个实操技巧回归测试不一定要人工判断输出质量可以先做机械化校验——检查流程是否走通、每个agent是否成功执行、是否有异常重试、token消耗是否在可接受范围。机械化校验过了再做人工抽检评判输出质量。这样可以大幅降低回归成本让版本发布更加频繁和安全。3.3 权限、安全与成本生产环境的硬约束多agent系统落到生产环境就不能只考虑“能不能跑”还要考虑“跑得安不安全、跑不跑得起”。这里有三件事需要从第一天就规划好。权限控制方面每个agent能够调用的工具必须明确区分。比如“数据库查询agent”只能访问数据库“企业微信发送agent”只能调用企业微信接口。工具调用要有白名单机制Agent绝不能拥有超出其职责范围的工具访问权限。这一点尤其重要因为一旦某个agent被prompt injection攻击权限隔离能限制攻击的影响面。数据隔离方面不同租户、不同用户的数据不能在agent之间无差别流动。以工单系统为例客户A的agent不能读取到客户B的工单信息。这个约束必须在架构层面实现而不是靠prompt里写“不要泄露其他用户信息”——模型在复杂场景下很容易被诱导不能寄希望于它的自觉性。成本控制方面多agent系统是真正的token消耗大户。一个请求可能触发5次、10次甚至更多次模型调用成本不容小觑。我的做法是给每个会话设置token预算超预算自动截断或者降级同时做模型路由简单任务用小模型复杂任务才用大模型再配合限流控制并发调用数避免某个瞬间调用量过大导致费用爆炸。4. 实操环节从零搭建一个工单分诊多agent系统4.1 场景定义与agent角色划分理论讲再多不如动手做一遍。我用最近实际落地的“工单分诊”场景完整走一遍流程。这个场景的背景是企业内部每天有大量用户报修的工单需要快速识别问题类型、找到对应的处理部门、判断紧急程度并自动回复用户初步处理进展。我们对任务做了拆解设计了四个agent意图识别agent接收用户原始描述提取问题类型、紧急程度、涉及的系统或设备。知识检索agent根据意图识别结果在企业知识库中检索解决方案或历史工单。工单处理agent负责创建工单、分配处理部门、设置优先级。质检审核agent对前三个agent的输出做最终校验检查信息完整性、部门分配合理性、回复话术质量。这里有个设计细节值得说质检审核agent不是可选的而是必须的。它是整个系统的安全网。多agent链路中的任何一个节点出错最终都可能被质检agent发现并拦截。它扮演的是“测试工程师”的角色——生产代码agent可能出bug但要保证交付给用户的不是bug。4.2 基于星型拓扑的编排流程这四个agent不是自由协作而是由中心orchestrator统一调度。整个流程是这样的第一步orchestrator接收用户报修信息生成session_id和trace_id把任务派发给意图识别agent。第二步意图识别agent返回结构化结果比如问题类型是“网络故障”、紧急程度是“高”。第三步orchestrator拿着这个结构化结果去调知识检索agent查询是否有已知解决方案。第四步知识检索agent返回匹配的解决方案和参考工单。第五步orchestrator汇总前两步的结果交给工单处理agent去创建正式工单。第六步工单处理agent返回工单编号和分配部门。最后orchestrator把所有信息打包给质检审核agent审核通过后才把最终回复展示给用户。采用星型拓扑而不是链型的原因很简单链型拓扑里每个agent只能看到前一个agent的输出如果一个早期阶段的判断有偏差错误会一路传导下去而且中间无法干预。而星型拓扑让orchestrator全程掌握全局信息可以在任意节点之间做信息回溯也可以针对某个节点单独重试。4.3 关键参数与兜底策略系统能跑通只是第一步线上稳不稳靠的是细节参数和兜底策略。先说模型参数。意图识别agent和知识检索agent的temperature设置在0.1~0.2之间保证输出稳定减少“发挥”的成分。质检审核agent的temperature设置在0完全确定性输出。工单处理agent因为是结构化操作同样用低temperature0.1左右。多agent系统里想象力值钱但稳定性更值钱——每一个随机的输出都意味着下游节点要处理多一分不确定性。超时和重试方面每个agent调用设置10秒超时超时后自动重试一次重试仍失败则触发降级策略。这里要特别说明重试机制的坑模型调用不是天生幂等的同一个请求重试两次可能产生两个不同的结果。所以重试前需要判断operations的类型——如果是查询类操作重试安全如果是创建工单这类写操作必须等第一次调用明确返回失败才重试否则可能重复提交。最后是兜底策略也就是“所有agent都挂了怎么办”。我会在orchestrator层设置最终兜底如果经过两轮重试仍无法完成全流程直接把用户的请求接入人工客服通道并出具一份中间诊断报告。这份兜底策略可以保证即使AI链路彻底不可用用户的诉求仍然会被受理。对一个生产系统来说永远要有plan B。5. 常见问题与排查技巧实录症状可能原因排查方法解决方案agent空转反复执行相同操作目标不明确或上下文缺失查看Trace中该agent的输入输出确认是否死循环在orchestrator层设置最大轮次限制超过自动终止上下文污染后续agent被无关信息干扰上下文传递过多、未做剪枝检查每个节点的输入上下文大小设置上下文上限只传结构化摘要链式传递中信息丢失结构化payload字段不一致对比各节点日志的payload结构统一消息协议增加payload格式校验并发任务互相争抢资源共享状态未加锁或未隔离检查状态存储层是否并发安全引入分布式锁或按session_id做数据分片模型行为漂移效果突然变差prompt被改动、模型更新或输入分布变化对比近期版本回归测试结果建立版本管理及时回滚5.1 一个典型的死循环排查案例有一次线上反馈某个工单请求的响应时间异常跑了一个多小时没结束。我打开Trace一看发现质检审核agent在反复调用工单处理agent——“审核不通过请重新分配部门”然后工单处理agent重新分配了一个部门质检又认为不合理又打回。这个循环整整转了几十轮。根因是什么工单处理agent在分配部门时参考的知识库比较老旧经常分配到一个已经不存在的“旧部门”质检agent的知识库里有新部门信息所以每次都判定不合格。两个agent的知识库不同步导致互相矛盾。这个案例让我意识到两个问题一是agent之间对同一概念的认知必须要一致最好共享同一个知识源或者在设计阶段就明确各自的知识边界二是系统必须要有最大循环次数限制绝对不能允许无限循环。后来我在orchestrator层加了硬性约束——任何一个子任务最多执行3轮超过直接转人工。这个改动上线后再也没有出现过“跑一个多小时不结束”的线上事故。5.2 排查多agent问题的通用思路踩了这么多坑之后我总结了一套多agent问题的通用排查思路可以套用在大多数场景。第一步先看Trace确认问题发生在哪个节点。多agent系统的故障是沿着链路传播的表面上的“症状点”往往不是“根因点”。比如用户收到的最终回复是“工单创建失败”问题可能在工单处理agent也可能是意图识别agent一开始就把信息提取错了导致后面全部跟着错。第二步对比“输入”和“输出”。对于排查中的那个节点先看它的输入信息是否完整正确再看它基于这些输入产出的输出是否合理。如果输入正确、输出错误那是这个agent自身的问题如果输入已经错了那就往上游找。第三步检查“重试次数”和“降级路径”。看这个请求在链路中是否触发过重试、是否走过降级分支。很多问题不是正常流程下的逻辑错误而是异常处理路径没有被充分测试。这套思路看起来简单但很实用——它逼着你从“全局视角”去定位问题而不是盯着某一个agent的输出发呆。每次落地多agent系统都是一次对工程能力的全面体检做完这个工单分诊系统我最大的体会是多agent系统真正考验的不是你对大模型的理解而是你对软件工程基础功的掌握程度。消息协议、状态管理、可观测性、版本控制、权限隔离、成本预算——这些恰恰是传统后端开发里最“无聊”的部分却是多agent系统能否长期稳定运行的决定性因素。再分享一个小技巧作为收尾如果你现在准备从单agent迁移到多agent别急着把场景做大先挑一个你业务中流程最清晰、边界最明确的小任务试水。跑通之后再逐步扩展。这个方法让我少走了很多弯路——多agent系统最怕一开始就摊大饼复杂度和不确定性叠加起来出了问题你都分不清是架构问题、模型问题还是prompt问题。从小场景建立自己的方法论再放大到更复杂的业务里你会感谢当初自己的克制。
这两年跟多agent系统打交道多了一个感受越来越强烈单个agent是玩具多个agent协作才是工程。说句实话多agent系统是那种“听着很酷、做着很痛”的方向市面上讲demo、讲概念的文章一大堆但真正能落到生产环境、能承受线上流量和业务复杂度的方案少之又少。我最近刚把我们内部一个工单分诊场景从单agent重构为多agent协作架构整个过程走下来从架构设计到治理体系踩坑无数也沉淀了一套自己用起来比较顺的方法论。这篇就把这些经验完整梳理一遍给正在做多agent平台、或者正准备把多个agent接入生产系统的团队一个参考——尤其适合那些已经过了“单agent能跑通”阶段开始被协作、状态、可观测性等问题卡住的同学。1. 多agent系统为什么难落地先想清楚这三个问题1.1 多agent和单agent本质上是两种物种很多人以为多agent系统就是把几个agent堆在一起互相调用就行。这个理解是最大的坑。单agent的本质是一个闭环输入进来模型推理调用工具输出结果。你只需要关注这个环路的准确性。但多agent系统面对的是一个意图网络——任务进来之后要拆解成子任务分发给不同的agent收集结果再汇合、再判断整个过程是动态分叉的。我常用一个类比解释这种差异单agent就像一个全能型自由职业者一个人包揽需求分析、设计、开发、测试多agent系统则是一个项目组有人做产品、有人写代码、有人做QA。项目组的难点从来不是单个人强不强而是信息怎么同步、任务边界怎么划、风险谁来兜底。代码写挂了自由职业者自己修项目组里得先搞清楚是哪个环节掉的链子。这个差异直接决定了你在技术选型和架构设计上的思路完全不同。单agent你可以把逻辑都塞进一个prompt里让它自己规划多agent则必须面对“任务派发”、“节点间通信”、“状态一致性”、“分布式链路追踪”这些原本属于后端工程的问题。换句话说多agent系统首先是分布式系统然后才是AI系统。这个认知不建立起来后面的路会很难走。1.2 落地前必须想清楚的三个问题我见过不少团队一上来就搞了七八个agent结果跑不起来。根本原因是在动手前有几个关键问题没想透第一个问题你需要的到底是“多agent”还是“多流程”这是最容易混淆的。如果一个系统只是同一个模型配了多套prompt模板根据不同的输入走不同的分支那它其实是多流程单agent不是多agent系统。多agent的核心特征是每个agent有自己的状态、工具、决策权限并且它们之间存在真正的双向信息交互。判断标准很简单——如果业务上只是“不同场景给不同prompt”那就老老实实做单agent别为了架构噱头增加复杂度。第二个问题协作是必要的吗很多时候任务完全可以用一个精心设计的prompt完成强行拆成多agent只会引入大量无效的通信开销和不确定性。我之前见过一个知识问答场景团队拆了“搜索agent”“总结agent”“审核agent”三个角色跑一轮要调用三次模型中间还有信息丢失的风险。实际上同一个模型拿到搜索工具一步就能完成大部分需求。多agent应该用在任务本身存在清晰边界、不同步骤需要不同专业背景或不同工具集的场景而不是为了用而用。第三个问题失败成本有多高每个agent节点都意味着一次模型调用而模型调用是有概率失败的——可能输出格式不对、可能超时、可能跑飞进入死循环。节点越多失败的概率就越大而且失败会沿着链路传播。如果系统承载的是高频高并发的生产流量每个环节都需要做重试、降级、兜底。这个成本在设计之初就要算进资源预算里否则上线后会发现模型调用费用暴涨、响应时间不可控。2. 架构设计拓扑选型、消息协议与状态管理2.1 三类拓扑结构星型、链型和网格型多agent系统的架构设计第一件事是选拓扑结构。我把它归纳为三类星型、链型、网格型。星型拓扑也叫orchestrator-worker模式是生产环境中用得最多的。一个中心调度者orchestrator负责接收用户请求、拆解任务、分配子任务给各个worker agent、再汇总各worker的结果进行最终输出。这种模式的好处是控制权集中调度逻辑清晰方便做超时控制、重试和兜底。坏处是orchestrator本身容易变成瓶颈而且如果拆解逻辑写得不好中心节点就成了单点故障。链型拓扑也叫pipeline模式适合数据处理流。任务按固定顺序经过一个个agent每个agent处理完一个阶段就传给下一个。比如“信息抽取agent → 情感分析agent → 摘要生成agent”。这种模式好处是链路简单每个节点职责单一方便单独优化坏处是链路中任何一个节点出错后面就没法继续而且信息在传递过程中容易损耗。网格型拓扑各agent之间可以自由通信、互相调用。理论上最灵活符合“多agent自主协作”的理想图景但实际落地我强烈建议避开——自由通信意味着不可预测性呈指数级上升根本无法控制Agent A什么时候调用Agent B状态不一致和死循环的问题会让你崩溃。我的建议很直接生产系统超过80%的场景用星型拓扑剩下不到20%用链型。网格型少碰除非你的团队有极强的可观测性基建兜底并且业务本身对不确定性有很高的容忍度。2.2 消息协议多agent系统的通信契约既然多agent系统本质是分布式系统那agent之间的消息就得有明确的契约。我刚开始做的时候吃过亏——让两个agent直接传原始对话文本结果上下文越滚越大token费用暴涨效果还变差了。后来我总结了一套比较稳妥的消息结构每个agent间传递的消息都遵循这个格式{ session_id: uuid-xxxx, message_id: uuid-yyyy, agent_id: intent-router, message_type: task_assign, payload: { task_type: knowledge_retrieval, query: 用户提交的原始问题, context: { user_id: u_12345, department: 售后, priority: high } }, timestamp: 2024-06-18T10:30:00Z, trace_id: trace-uuid-zzzz }这套结构解决了我最头疼的几个问题session_id保证了同一个用户请求的所有agent协作属于一个会话message_type让每个agent知道自己收到的是一个任务派发、一个结果回传还是一次状态查询payload里只传必要信息不把整个对话历史塞进去trace_id是后面做可观测性的基础没有它线上出了问题你连查都查不了。这里有个关键设计原则agent之间传递的是结构化数据不是自然语言长文本。很多新手喜欢让agent直接用“人话”互相沟通看起来智能实际上非常脆弱——模型输出稍微有点歧义下游agent就理解错了。结构化payload可以降低这种歧义同时方便做日志审计和错误排查。2.3 状态管理别把上下文当成万能解法多agent系统中状态管理是最容易被低估的一环。每个agent在执行任务时都有自己的“记忆”——它看到了什么、做了什么、得出了什么结论。如果所有状态都靠上下文传递系统很快就会膨胀到不可维护。我实践下来的做法是把状态分成两层。第一层是全局状态放在中心存储比如Redis或数据库记录整个会话的进展——当前在哪个阶段、已经完成哪些子任务、收获了哪些关键信息。第二层是局部状态只存在于单个agent的执行周期内任务结束就丢弃。举个例子工单分诊场景里全局状态记录的是“用户的问题是什么、当前分诊到哪个部门、紧急程度如何”局部状态则是“意图识别agent在分析时参考了哪几条历史工单”。这样一来即使某个agent执行失败需要重试只需要重置局部状态不会影响整个会话的进展。还有一点很关键任何状态下发到agent之前都要设置一个大小上限。我一般控制在2k~4k token以内超出就截断或做摘要绝不让上下文无限膨胀。这个习惯帮我省下了大量token成本也让响应速度稳定了很多。3. 治理体系多agent系统能不能长期跑的真正分水岭3.1 可观测性没有Trace多agent故障就是“薛定谔的猫”多agent系统最折磨人的地方在于它的bug往往是概率性的、非确定性的。同一个请求上午跑是好的下午就错了参数一模一样的两次调用结果可能完全不同。这种情况如果没有一套完备的可观测性体系排查问题无异于大海捞针。我给多agent系统做的可观测性包含三个层次全链路Trace、结构化日志、运行指标。全链路Trace是整个体系的基石。每个请求都有一个trace_id贯穿所有agent调用。这样线上出了问题我可以直接查到这个请求经历了哪几个agent、每个agent的输入输出是什么、在哪一步耗时最长、在哪一步出现了异常。我通常会把每个agent的调用、每工具的执行都记录成一帧span挂在同一个trace下一眼就能看到完整的调用链。结构化日志是Trace的补充。每个agent执行完都会输出一条结构化的日志包含当前agent的id、输入摘要、输出摘要、调用的工具、用时、token消耗、错误信息。这些日志既用于事后排查也用于后续的离线分析和效果评估。运行指标则是宏观视角。我至少会盯四个指标任务成功率整个多agent流程完整走通的概率、单次任务平均耗时、模型调用token消耗量、各agent节点的失败率分布。这四个指标能帮助我快速发现系统的劣化趋势——比如某个worker agent的失败率突然从1%涨到10%那大概率是模型行为漂移或者输入数据分布变了需要及时干预。3.2 版本管理与回归测试让agent工程也告别“玄学开发”多agent系统的效果很大程度取决于prompt、模型参数和工具定义的组合。这三样东西任何一个变动都可能导致系统行为变化。但现实是很多团队还在用“改了prompt → 线上看看效果 → 不对再改”这种原始方式这是完全没有工程化的状态。我推荐的做法是建立一套类似软件工程的版本管理体系。prompt要有版本号工具定义要有版本号模型参数配置要有版本号。每一次改动都记录是谁改的、改了啥、为什么改、在哪个环境验证过。上线前必须经过回归测试——准备一组覆盖主要场景的测试用例集比如100条典型的用户问题跑一遍多agent流程比较结果和基准版本的区别。这里分享一个实操技巧回归测试不一定要人工判断输出质量可以先做机械化校验——检查流程是否走通、每个agent是否成功执行、是否有异常重试、token消耗是否在可接受范围。机械化校验过了再做人工抽检评判输出质量。这样可以大幅降低回归成本让版本发布更加频繁和安全。3.3 权限、安全与成本生产环境的硬约束多agent系统落到生产环境就不能只考虑“能不能跑”还要考虑“跑得安不安全、跑不跑得起”。这里有三件事需要从第一天就规划好。权限控制方面每个agent能够调用的工具必须明确区分。比如“数据库查询agent”只能访问数据库“企业微信发送agent”只能调用企业微信接口。工具调用要有白名单机制Agent绝不能拥有超出其职责范围的工具访问权限。这一点尤其重要因为一旦某个agent被prompt injection攻击权限隔离能限制攻击的影响面。数据隔离方面不同租户、不同用户的数据不能在agent之间无差别流动。以工单系统为例客户A的agent不能读取到客户B的工单信息。这个约束必须在架构层面实现而不是靠prompt里写“不要泄露其他用户信息”——模型在复杂场景下很容易被诱导不能寄希望于它的自觉性。成本控制方面多agent系统是真正的token消耗大户。一个请求可能触发5次、10次甚至更多次模型调用成本不容小觑。我的做法是给每个会话设置token预算超预算自动截断或者降级同时做模型路由简单任务用小模型复杂任务才用大模型再配合限流控制并发调用数避免某个瞬间调用量过大导致费用爆炸。4. 实操环节从零搭建一个工单分诊多agent系统4.1 场景定义与agent角色划分理论讲再多不如动手做一遍。我用最近实际落地的“工单分诊”场景完整走一遍流程。这个场景的背景是企业内部每天有大量用户报修的工单需要快速识别问题类型、找到对应的处理部门、判断紧急程度并自动回复用户初步处理进展。我们对任务做了拆解设计了四个agent意图识别agent接收用户原始描述提取问题类型、紧急程度、涉及的系统或设备。知识检索agent根据意图识别结果在企业知识库中检索解决方案或历史工单。工单处理agent负责创建工单、分配处理部门、设置优先级。质检审核agent对前三个agent的输出做最终校验检查信息完整性、部门分配合理性、回复话术质量。这里有个设计细节值得说质检审核agent不是可选的而是必须的。它是整个系统的安全网。多agent链路中的任何一个节点出错最终都可能被质检agent发现并拦截。它扮演的是“测试工程师”的角色——生产代码agent可能出bug但要保证交付给用户的不是bug。4.2 基于星型拓扑的编排流程这四个agent不是自由协作而是由中心orchestrator统一调度。整个流程是这样的第一步orchestrator接收用户报修信息生成session_id和trace_id把任务派发给意图识别agent。第二步意图识别agent返回结构化结果比如问题类型是“网络故障”、紧急程度是“高”。第三步orchestrator拿着这个结构化结果去调知识检索agent查询是否有已知解决方案。第四步知识检索agent返回匹配的解决方案和参考工单。第五步orchestrator汇总前两步的结果交给工单处理agent去创建正式工单。第六步工单处理agent返回工单编号和分配部门。最后orchestrator把所有信息打包给质检审核agent审核通过后才把最终回复展示给用户。采用星型拓扑而不是链型的原因很简单链型拓扑里每个agent只能看到前一个agent的输出如果一个早期阶段的判断有偏差错误会一路传导下去而且中间无法干预。而星型拓扑让orchestrator全程掌握全局信息可以在任意节点之间做信息回溯也可以针对某个节点单独重试。4.3 关键参数与兜底策略系统能跑通只是第一步线上稳不稳靠的是细节参数和兜底策略。先说模型参数。意图识别agent和知识检索agent的temperature设置在0.1~0.2之间保证输出稳定减少“发挥”的成分。质检审核agent的temperature设置在0完全确定性输出。工单处理agent因为是结构化操作同样用低temperature0.1左右。多agent系统里想象力值钱但稳定性更值钱——每一个随机的输出都意味着下游节点要处理多一分不确定性。超时和重试方面每个agent调用设置10秒超时超时后自动重试一次重试仍失败则触发降级策略。这里要特别说明重试机制的坑模型调用不是天生幂等的同一个请求重试两次可能产生两个不同的结果。所以重试前需要判断operations的类型——如果是查询类操作重试安全如果是创建工单这类写操作必须等第一次调用明确返回失败才重试否则可能重复提交。最后是兜底策略也就是“所有agent都挂了怎么办”。我会在orchestrator层设置最终兜底如果经过两轮重试仍无法完成全流程直接把用户的请求接入人工客服通道并出具一份中间诊断报告。这份兜底策略可以保证即使AI链路彻底不可用用户的诉求仍然会被受理。对一个生产系统来说永远要有plan B。5. 常见问题与排查技巧实录症状可能原因排查方法解决方案agent空转反复执行相同操作目标不明确或上下文缺失查看Trace中该agent的输入输出确认是否死循环在orchestrator层设置最大轮次限制超过自动终止上下文污染后续agent被无关信息干扰上下文传递过多、未做剪枝检查每个节点的输入上下文大小设置上下文上限只传结构化摘要链式传递中信息丢失结构化payload字段不一致对比各节点日志的payload结构统一消息协议增加payload格式校验并发任务互相争抢资源共享状态未加锁或未隔离检查状态存储层是否并发安全引入分布式锁或按session_id做数据分片模型行为漂移效果突然变差prompt被改动、模型更新或输入分布变化对比近期版本回归测试结果建立版本管理及时回滚5.1 一个典型的死循环排查案例有一次线上反馈某个工单请求的响应时间异常跑了一个多小时没结束。我打开Trace一看发现质检审核agent在反复调用工单处理agent——“审核不通过请重新分配部门”然后工单处理agent重新分配了一个部门质检又认为不合理又打回。这个循环整整转了几十轮。根因是什么工单处理agent在分配部门时参考的知识库比较老旧经常分配到一个已经不存在的“旧部门”质检agent的知识库里有新部门信息所以每次都判定不合格。两个agent的知识库不同步导致互相矛盾。这个案例让我意识到两个问题一是agent之间对同一概念的认知必须要一致最好共享同一个知识源或者在设计阶段就明确各自的知识边界二是系统必须要有最大循环次数限制绝对不能允许无限循环。后来我在orchestrator层加了硬性约束——任何一个子任务最多执行3轮超过直接转人工。这个改动上线后再也没有出现过“跑一个多小时不结束”的线上事故。5.2 排查多agent问题的通用思路踩了这么多坑之后我总结了一套多agent问题的通用排查思路可以套用在大多数场景。第一步先看Trace确认问题发生在哪个节点。多agent系统的故障是沿着链路传播的表面上的“症状点”往往不是“根因点”。比如用户收到的最终回复是“工单创建失败”问题可能在工单处理agent也可能是意图识别agent一开始就把信息提取错了导致后面全部跟着错。第二步对比“输入”和“输出”。对于排查中的那个节点先看它的输入信息是否完整正确再看它基于这些输入产出的输出是否合理。如果输入正确、输出错误那是这个agent自身的问题如果输入已经错了那就往上游找。第三步检查“重试次数”和“降级路径”。看这个请求在链路中是否触发过重试、是否走过降级分支。很多问题不是正常流程下的逻辑错误而是异常处理路径没有被充分测试。这套思路看起来简单但很实用——它逼着你从“全局视角”去定位问题而不是盯着某一个agent的输出发呆。每次落地多agent系统都是一次对工程能力的全面体检做完这个工单分诊系统我最大的体会是多agent系统真正考验的不是你对大模型的理解而是你对软件工程基础功的掌握程度。消息协议、状态管理、可观测性、版本控制、权限隔离、成本预算——这些恰恰是传统后端开发里最“无聊”的部分却是多agent系统能否长期稳定运行的决定性因素。再分享一个小技巧作为收尾如果你现在准备从单agent迁移到多agent别急着把场景做大先挑一个你业务中流程最清晰、边界最明确的小任务试水。跑通之后再逐步扩展。这个方法让我少走了很多弯路——多agent系统最怕一开始就摊大饼复杂度和不确定性叠加起来出了问题你都分不清是架构问题、模型问题还是prompt问题。从小场景建立自己的方法论再放大到更复杂的业务里你会感谢当初自己的克制。
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
