1. 动手前先说清楚你的场景真的需要多Agent吗先说一个我踩过的坑有一段时间我特别迷多Agent总觉得一个Agent干活太孤单给它安排了三四个角色让它们“协作”完成一个本来很简单的任务。结果怎么样响应时间长了Token消耗翻了三倍最离谱的是两个“专家”Agent在互相质疑对方的输出把整个流程给卡死了。那之后我明白了一件事多Agent是一个拿来解决问题的架构方案不是用来炫技的装饰品。如果你还没想清楚“为什么要拆”就先把“拆了再说”落到代码里后面多半要返工。1.1 单Agent瓶颈与多Agent的适用边界单Agent在很多场景下其实已经够用了。比如让一个Agent去总结文档、改写标题、生成一段代码它自己就能干得不错。真正逼着你往多Agent方向走的通常是三类问题。第一类是“上下文不够塞”。当一个任务需要同时参考几十份文档、保持长时间的多轮交互状态或者要在同一轮里推理多个完全不同领域的知识时单个Agent的上下文窗口就成了硬约束。物理上放不下强行塞进去就是早期的丢细节、后期的幻觉。这时候把“看文档”和“写代码”拆给两个Agent让每个Agent各管一段上下文是合理的解题思路。第二类是“角色职责互相冲突”。同一个Agent既要当“严谨的审查员”又要当“天马行空的创意脑”提示词怎么写都会打架。比如你让它先批判性地评审方案再让它放飞想象力补全细节最后出来的东西往往两头不讨好。拆成独立的“评审Agent”和“创意Agent”用流程去约束先后关系反而更干净。第三类是“任务边界天然清晰”。比如一个负责代码生成一个负责代码审查一个负责测试用例生成这种Pipeline式的分工用多Agent实现几乎不需要额外设计本质上是把不同Prompt模板封装成了不同函数只是它们有了独立的对话记忆和工具权限。这类场景最容易见效也最容易上手。我遇到过最典型的反面案例是某个模拟项目X只需要把用户留言分类成“投诉”和“咨询”团队愣是设计了“理解Agent”和“决策Agent”两个角色最后跑出来的准确率和单Agent一模一样还多花了一次模型调用的钱。功能边界模糊、上下文又不紧张、一个Prompt就能写完的活儿强行拆成多个Agent只会增加延迟和成本不会有任何质量收益。1.2 不适合多Agent的三种场景第一种任务本身只有一步。比如“把这段文本翻译成英文”一个Agent一条Prompt就能完成没有任何中间产物也没有多领域知识需要交叉拆成多Agent纯属脱裤子放屁。我见过有人为了“可扩展”把翻译拆成“理解意图Agent”和“润色Agent”结果润色Agent经常把专业术语改成不准确的口语化表达还得靠最后一步强制校验拉回来。第二种决策链路要求绝对一致。如果整个流程里每个步骤必须基于同一个全局决策结果拆分出去反而要在每一步传递状态快照加大了不一致的风险。举个典型例子一个Agent负责生成JSON格式的配置另一个Agent负责把这个配置渲染成界面。只要生成配置的Agent改了字段名渲染的Agent立刻跟不上。这种强耦合场景让一个Agent边生成边渲染反而更稳。第三种没有明确的评价标准。多Agent最大的价值之一是互相校验但前提是你知道“什么算好”。如果任务结果根本无法自动化评估比如“写一首有诗意的现代诗”你让“评价Agent”去打分它给出的分数往往没有什么复现性甚至会影响主线任务的输出质量。这种主观性很强的任务单Agent加人工校验就够了。1.3 判断是否拆分的四步清单我现在做技术方案时会先过一遍这个清单不满足就老老实实用单Agent你能否一句话说清每个Agent的输入、输出和成功标准说不清就别拆。各个Agent的职责是否完全不重叠如果两个Agent都在“做一遍整体分析”那它们只会互相干扰。是否有明确的执行顺序或依赖关系完全没有依赖链的多个Agent并行并不是多Agent只是并发发几次请求。拆完之后单个Agent的提示词是否比原来更短、更聚焦如果拆完之后每个Agent的Prompt还是又臭又长那拆分就没有意义。这套清单是我和几个做AI应用的朋友总结出来的。我们自己手头的大部分真实场景其实根本用不着多Agent。真正需要多Agent的往往是那种要跑几十个工具调用、要读一批不同领域的文档、要生成一份综合报告的综合任务。只有把“为什么要拆”想透了后面聊的架构、通信、记忆才有意义。2. 架构选型编排式、协商式、混合式怎么挑确定要拆了接下来就是选架构。多Agent的协作方式说穿了就三种骨架编排式、协商式、混合式。很多人一上来就研究复杂的Agent通信协议或者搞什么“自治协调”结果把简单问题复杂化。我自己的经验是先选对协作骨架再谈细节。2.1 编排式把项目经理写死在流程里编排式最像现实中的“项目经理指挥干活”。一个中心调度Agent负责接收用户需求把任务拆成若干子步骤挨个交给对应的执行Agent再把结果收回来按顺序或并行逻辑组装成最终输出。执行Agent之间不直接通信所有信息都通过调度者中转。这种架构的好处是可控性极强。每一层的输入输出都可预期出了问题你能直接定位到是哪个执行Agent的哪一步出了错。调试和追踪都简单。坏处是中心Agent容易变成瓶颈而且整套流程的灵活性取决于你预先写好的Schedule。如果任务类型变化快调度逻辑会越写越臃肿。我用编排式实现过一个内部提效工具输入一份产品需求文档先由“需求分析Agent”抽结构化要点再由“方案设计Agent”生成技术方案然后由“代码框架Agent”输出核心代码骨架最后由“评审Agent”给出改进建议。这些Agent之间完全没有直接通信全靠调度器的一条状态机串联。效果非常稳后来还加了超时重试和断点续跑生产环境连续跑了一个月没出过岔子。这个例子里最关键的是我们允许每个Agent看到之前环节的部分输出但禁止它们修改中间结果。编排者的职责就是把“分别干活”变成“流水线干活”。如果你希望系统能动态调整流程就得在编排者里加一套“任务路由”逻辑让它根据子任务结果决定下一步给谁这其实已经是混合式了。2.2 协商式让Agent自己聊出一个结果协商式没有强制的中心节点多个Agent平级它们通过互相发送消息、互相质疑、逐步达成一致的方式来推进任务。这种架构典型应用包括“多个Agent做观点辩论”“多方参与方案评审”“不同专家角色一起做决策”。我试过用协商式做一个“模拟评审会”一个Agent当方案提出方一个当技术风险专家一个当业务方代表。三者围绕一个技术选型问题来回讨论最后再由另一个“决策汇总Agent”把共识整理成结论。讨论过程确实很有看头能暴露出很多单Agent想不到的风险点。但问题也一样明显时间不可控。如果某个Agent钻进了逻辑死胡同或者几个Agent各执己见谁也不服谁整个对话会无限拉长Token成本直线上升。协商式的工程化难度比编排式高得多。你得考虑怎么控制轮次上限、怎么在观点僵持时强制收敛、怎么过滤掉重复或无意义的对话。我测试时发现最简单的办法是给协商过程加一个“时间盒”和“结论模板”——无论聊得多热闹到时间或者到轮次必须输出一个固定结构的结论不能无限聊下去。同时需要一个“裁判”角色通常是用更高层次的Prompt或人工介入来打断僵局。2.3 混合式的实际取舍与典型案例真正可扩展的多Agent系统几乎都是混合式。核心思路是用编排式保证主干流程稳定用协商式处理局部的分歧或需要多角度判断的环节。举个例子我们做一个模拟的多源信息整合工具主干是编排式检索Agent拉资料、筛选Agent过滤噪音、整合Agent写报告。在筛选环节容易出现不同信息源互相矛盾的情况我们就在这一层加了一个“仲裁Agent”——说白了就是让三个来源Agent各自陈述理由再由仲裁Agent根据可信度权重投票输出一个统一的筛选结果。主干流程没有被协商拖慢局部决策质量却提高了不少。混合式对设计者的要求更高因为你要时刻清楚“哪一层该自治哪一层该控制”。我的经验法则是不确定怎么选的时候先全上编排式跑通再局部改造。先把主线打通用户看到的永远是一个稳定入口内部怎么协商随时可以调。千万别一开始就搞全自治的协商系统除非你已经把大量边缘情况都考虑进去。2.4 选型时的关键问题清单选架构不能凭感觉我一般会先回答下面几个问题任务流程是固定的还是动态变化的固定优先编排动态优先混合。出现分歧时能接受机器协商吗能明确“最优解”就协商不能就人工仲裁。你更在乎“每次结果一致”还是“结果有创造性”前者选编排后者可以试试协商。出故障时你希望快速回滚到某个稳定版本还是可以接受重新协商这决定了你的状态管理复杂度。老实说市面上很多号称“自主协商”的多Agent框架看演示很惊艳真正放到企业级场景里大多数都收敛不了。我自己最终选型的偏好比较保守能用编排解决的绝不上协商必须协商的只在最底层、影响最小的环节做。3. 通信与信息流转别让Agent之间讲“黑话”架构骨架定了之后面对的具体问题就是Agent之间怎么讲话这里的“讲话”不只是网络层面怎么传输而是业务层面用什么语言、什么格式、什么粒度交换信息。Communication design决定你的系统是清爽还是混乱。3.1 三种主流通信方式的取舍多Agent之间的通信目前主流做法有三种直接消息传递、共享黑板、函数调用式。直接消息传递是最直觉的A给B发一条消息B处理后回一条。它的优点是简单逻辑链路清晰缺点是消息多了容易变成蜘蛛网而且每个Agent都得知道“该发给谁”。如果某个Agent换了名字或者职责变了所有发消息的地方都得改。共享黑板是指把所有中间状态写到一个公共区域Agent自己决定什么时候读、写什么。这像现实中一群人围着一块白板讨论只要有人更新了白板其他人就能看到。优点在于Agent之间解耦不需要精确知道对方是谁缺点是“读脏数据”和“写冲突”的问题很烦人而且白板上的内容如果没有版本管理一天到晚会出现“这个数据是谁改的”这种灵魂拷问。函数调用式是我最推荐的方式。它本质上把其他Agent暴露成一个个有明确输入输出Schema的函数。计划Agent或调度Agent直接“调用”一个执行Agent传参和拿返回值都跟调一个普通函数一样。这种方式对代码工程化最友好因为你可以做类型校验、超时控制、熔断降级几乎复用你已有的后端服务治理经验。很多成熟的Agent团队表面上是“多Agent”底层其实就是一系列带Prompt和工具的微服务只不过入口是自然语言接口。这三者没有绝对优劣。我看到很多开源项目采用共享黑板是因为它特别适合表达“广播式”协作比如多个Agent都在往同一个事件流里写事件。但自己写业务系统我更偏向函数调用式至少第一阶段先用函数调用式把链路跑起来等到Agent数量超过10个、交互图变得复杂之后再考虑引入事件流或黑板作为补充。3.2 消息格式设计的实战细节不管选哪种通信方式消息本身的格式都值得花心思设计。我见过不少半路翻车的项目最后发现是“Agent之间说的根本不是一件事”。比如A说“任务完成”它指的是已经写完初稿B听到“任务完成”就以为可以交付了结果拿着未校验的稿子直接发给用户。我现在的做法是给每个Agent定义严格的输入输出协议形式上可以是JSON Schema内容上要有几个固定字段request_id用于追踪、agent_id发送方、task_status枚举值以及payload真正的业务数据body里再放一个result_summary和confidence。举个实际的Schema片段我们做某内容整合系统的传递格式大概是这样的{ request_id: a1b2c3, from: planner, to: retriever, type: fetch_documents, payload: { query: 多Agent系统设计模式, max_results: 5 }, meta: { deadline: 60, priority: high } }响应消息对应会有{ request_id: a1b2c3, from: retriever, to: planner, type: fetch_documents_result, payload: { documents: [ {title: ..., snippet: ..., score: 0.92} ], truncated: false }, meta: { duration_ms: 5120, error: null } }设计这类格式时有一个原则宁可多写十个字段也不要在后续调试时靠猜。比如“confidence”这个字段一开始我觉得多余后来发现当检索Agent没找到东西时它会返回一些低置信度的结果如果没有置信度字段下游Agent就会把低质量结果当成可靠内容写进报告。加了置信度之后下游Agent可以自动丢弃低于0.6的素材明显降低了幻觉率。另外消息里必须带deadline或TTL。多Agent系统跑长了一定会遇到某个Agent卡死的情况。没有过期机制整个流程会一直等最后超时有了deadline接收方可以选择跳过、重发或者走降级策略。这是我们踩过坑之后补上的补完之后线上稳定性提升了一个台阶。3.3 上下文隔离与共享黑板的边界除了消息格式还有一件事容易忽略Agent之间该共享多少上下文我见过一个项目为了让“评审Agent”更理解“方案Agent”的意图直接把方案Agent的完整Prompt、历史对话和所有工具调用记录全塞给评审Agent。结果评审Agent的上下文里塞了一堆无关信息反而把真正要评审的重点给忘了。正确做法是给每个Agent定义一个“需要知道”的最小信息集。A只需知道B的结论就不给A看B的中间推理B只需要读取某几个字段就不给它整个数据仓库的访问权限。上下文隔离能显著降低串扰也让每个Agent更聚焦。真正需要跨Agent共享的东西才写进共享黑板。我们一个模拟项目X有两个Agent同时处理一份文档的不同章节一个做术语统一一个做格式排版。它们之间需要共享“术语对照表”但不共享各自生成的章节内容。这种情况下共享黑板只放一张术语表并加上“谁最后修改”“修改时间”字段Agent在每次读写前检查版本号就足够了。4. 任务拆解与结果聚合多Agent最容易翻车的地方通信解决的是“怎么讲话”接下来这个环节才真正决定系统上限任务拆解和结果聚合。这一块做得不好多Agent就是一场各干各的灾难。“拆不细、合不拢”是新手最容易踩的两大坑。4.1 自顶向下拆解的粒度控制任务拆解最核心的问题是“每个Agent的活儿该多大”。太粗了Agent工作量不均有的忙死有的闲死太细了Agent之间产生大量交接成本每个交接点都是潜在的信息损耗和延迟。我常用的拆解思路是“写代码等价物”你设想这个任务如果交给一个团队里的几个程序员你会怎么分配你会让一个程序员同时负责需求分析、数据库设计、前端页面、后端逻辑吗多半不会。同样一个Agent如果既要理解用户意图又要检索资料还要写结构化报告那它本质上还是一个“巨型Agent”并没有通过拆分获得聚焦优势。好的拆解粒度应该是每个子任务完成后能产生一个可验证的中间产物。比如“抽取文档中的关键实体”这个子任务产物是一份实体列表“判断产品建议的可行性”这个子任务产物是“可行/不可行理由”。如果子任务完成后你只能得到一句“我做了”而没有一个结构化的东西那说明粒度还太粗要继续拆直到每个Agent的输出都能被后续环节直接使用。另外任务拆解最好由专门的“规划Agent”来做而不是用手工写死在代码里。但规划Agent要做两件事第一它输出的是一个DAG有向无环图形式的任务列表包含任务ID、依赖关系、输入来源、输出去向第二它必须给每个子任务标注“预期资源”比如“需要调用工具X”“需要参考Y文档”。有了DAG后面做并行调度和结果聚合才有依据。4.2 并行与串行的依赖关系判断拆出多个子任务后下一步是决定哪些能并行、哪些必须串行。并行能大幅缩短总耗时但也会引入资源共享和结果一致性的问题。我的判断方法是画依赖图如果B的输入依赖于A的输出A和B就必须串行如果A和B互不依赖就可以并行执行。但这个“互不依赖”要小心有时候表面上不依赖实际上共享了同一个外部资源比如同一个数据库的同一张表、同一个文件系统里的同一个目录。如果并发写同一个资源会有脏写风险。所以我们除了看数据依赖还会检查“资源依赖”有资源依赖的Agent要么排队要么锁资源。处理依赖关系的另一个经验是尽量把可并行的任务包合并成一个批次。假设一个任务拆出了10个子任务其中3个没有依赖另7个有依赖链我会先让这三个并行跑跑完后合并结果再送入依赖链起点。这样既享受了并行收益又不会因为某些任务跑得慢而让整个链路上的后续任务一直等待。串行链上还有个容易忽视的点信息衰减。A输出长文本给BB只摘取其中一段给C到了D那里原始信息可能已经面目全非。我的对策是在DAG上定义“必须完整传递的关键信息”比如原始需求文本必须原样传入每个下游Agent过程中的中间观点只是辅助。这样即使某个环节做了压缩也不会丢失最核心的输入。4.3 结果冲突怎么办裁决与融合策略多个Agent同时工作必然会出现结果不一致的情况。最常见的冲突场景是两个Agent针对同一问题给出了不同答案而你最后只能输出一个。这时候不能随便选一个也不能让另一个Agent强行“综合一下”因为综合出来的东西往往两边都不讨好。我测试过几种冲突处理策略按推荐顺序排列置信度优先每个Agent在输出结果时附带confdence分数分数高的一方胜出。前提是置信度要足够靠谱不能被Agent乱填。优先级策略给Agent设定静态优先级。比如“权威资料Agent”的结论永远优先于“网络摘要Agent”冲突时无脑选高优先级。适合有明确信息源偏好度的场景。仲裁Agent多个Agent把各自结果和论据给一个中立的仲裁Agent由仲裁Agent根据规则或逻辑推导选定一个或者提取它们的共识点。仲裁Agent的Prompt需要特别设计强调只看证据、不能和稀泥。人工介入兜底如果冲突无法自动解决并且影响重大直接挂起任务把冲突内容推给人工决策。别怕这个流程慢总比系统自动输出一个错的结果强。我处理过一个具体案例两个Agent分别负责从财务系统和非财务系统抓数据结果同一指标数值对不上。各自都认为自己的来源可靠置信度都填了0.9。最后仲裁Agent引入了“数据更新时间”字段发现财务系统的数据比非财务系统晚更新一天于是选择非财务系统作为主数据并在报告中标注了差异说明。这个案例告诉我们仲裁规则最好基于可验证的元数据而不是模型中拍脑袋的“直觉”。结果融合不只是选一个有时候也需要把多个结果拼接成一个整体。比如让“内容生成Agent”写正文、“配图Agent”生成配图建议最后需要一个聚合模块把正文和配图建议按固定模板组装成HTML。这里的聚合不应该是让一个Agent自由发挥而是写一个确定的模板渲染器把每个Agent的输出塞进预留插槽。能用代码实现的“确定性融合”就不要丢给LLM否则又会产生新的幻觉。5. 记忆与状态管理比单Agent难一个量级单Agent记住自己的对话历史就够了多Agent系统里的记忆却要考虑“谁记得什么”“什么时候共享”“重启之后还在不在”。我见过太多项目在Agent协作上花了大量功夫最后败在记忆状态上——用户问一句“刚才你提到的第二个方案能再详细点吗”系统一脸茫然因为方案细节在另一个Agent的上下文里主入口Agent根本不知道。5.1 Agent的短期工作记忆与长期记忆分层每个Agent内部至少要有两层记忆短期工作记忆和长期记忆。短期工作记忆就是当前任务上下文包括用户输入、当前子任务的输入输出、中间推理过程。它通常放在内存里直接作为Prompt的一部分传给模型。这里要注意控制长度不能无限累积。一个Agent执行了非常多的中间步骤但产出结果只需要其中几个关键参数其他过程文本就该被丢弃或者存到日志里而不是一直占着上下文窗口。长期记忆则可以包括该Agent在历史任务中学到的偏好、总结过的方法论、用户的历史习惯等通常用向量数据库或结构化存储来保存。但多Agent场景下长期记忆不能默认每个Agent各自保留独立的记忆库因为A总结出的行业术语表B很可能也需要。此时就要引入“共享长期记忆”。我见过一个失败设计每个Agent都存一份完整的历史对话系统每次调用Agent时把历史全部加载进来。看起来没什么问题但Agent数量一多每个Agent的记忆库都膨胀得很快最终调用时上下文超长费用高、速度慢、结果还变差。后来改成“只加载当前任务相关的记忆片段”问题才缓解。5.2 状态一致性与可恢复性设计多Agent系统的状态一致性是个繁琐问题。设想一个场景一个Agent已经根据某个中间结果生成了报告但后来你发现那个中间结果其实是错的另一个Agent修正过。这时候报告已经发出去了怎么办如果你没有“状态版本号”的概念根本不可能定位到“这份报告依赖的是旧版本数据”。我自己的做法是给每个任务的中间产物都打上version和data_source字段。产物被下游Agent读取时会校验version如果version过期可以选择重新拉取或者向上游发一个invalid消息。这个机制有点像代码版本管理里的分支合并。实现并不复杂但必须在一开始就做否则后期数据污染了排查成本极高。另一个工程化措施是可恢复性。多Agent流程动辄要跑几十次LLM调用中间任何一步网络超时或模型报错都可能导致整个流程挂掉。有朋友在做这类系统时会加“断点续跑”把每个子任务的状态写到数据库里如果整个流程意外中断下次启动时从数据库读取已完成子任务的结果只重新执行未完成的部分。这样既省成本又让系统显得“靠谱”了很多。5.3 跨Agent记忆共享的三种实用做法跨Agent记忆共享我试过很多花样最后沉淀下来三种实用做法按通用程度排序中心化知识库所有Agent共享同一个外部知识存储谁都可以读写。这是最直观的但要注意给每个Agent设置读写权限和命名空间避免A清理了B正在用的数据。事件日志重放Agent之间不直接改对方状态而是把“已发生的事件”写入一个只追加的事件流。某个Agent如果需要知道之前发生了什么就去读事件流并按自己的逻辑重建状态。这种方式非常适合做解耦和审计。共享上下文信封为每个任务创建一个“信封”信封里放任务背景、目标、关键约束、历史决策记录。每个Agent在工作前先读信封工作后把本环节的新结论追加进信封再传给下一个Agent。这个信封就是跨Agent的连续记忆比直接共享整个长期记忆库要轻便得多。我个人的项目里信封模式用得最多。它有点像一个随任务流转的“旅行日志”每个Agent只写自己负责的那一页不修改别人写的内容。天然支持并发读写冲突的概率也低因为每个Agent写的是不同字段。如果下一个Agent发现某段记录缺漏它会主动请求补齐而不是自己瞎猜。6. 从原型到生产稳定性、可观测性与成本很多多Agent项目在Demo阶段跑得飞起一上生产就现原形。不是因为模型不够聪明而是工程化没跟上。这一章我集中聊聊把多Agent系统推上线时容易忽略的三个关键点稳定性、可观测性和成本控制。6.1 重试、超时、流控一个都不能少这套东西单Agent调用的时候很多人觉得没必要但多Agent系统里任何一次子调用出问题都可能引发蝴蝶效应。你单独请求一个LLM超时了重试一下就行在多Agent链路里A卡住十秒后面的B、C、D全在干等最终用户感受到的延迟是指数级放大的。所以第一步是给每个Agent调用单独设置超时。不能整条链路共享同一个超时时间而应该是每个子任务都有独立的deadline并且deadline要传导。比如说主任务总超时60秒规划阶段给了8秒执行阶段每个子任务给了20秒聚合阶段给了10秒加起来刚好卡在预算内。任何一个环节超了立即触发其自身的降级逻辑比如返回提前完成的缓存结果或者跳过这个环节跳到下一环节。重试策略也要分级。对于“模型返回格式错误”“网络抖动”这类可重试错误可以尝试重试一次对于“Agent逻辑死循环”“内容被审查拒绝”这类重试也解决不了的问题应该直接终止该分支并给出提示。我吃过一个亏一个Agent因为提示词写错了导致输出永远是“我不确定”我们傻傻地重试了三次三次都是同一个错误白白浪费了Token和时间。后来加了“连续失败计数”超过两次就转人工。流控Rate Limit很容易被人忽略。当你让十个Agent并行调用同一个底层模型接口时很可能直接触发平台的并发限制然后一大片429错误飞过来。我在生产环境里就遇到过某次促销活动流量激增我们的多Agent系统把同一供应商的QPS打到了上限结果所有Agent集体报错。后来我们在每个Agent调用外面包了一层令牌桶限制全局并发数才把问题压下去。别小看并发多Agent系统天然会把模型调用并发放大几倍流控必须做。6.2 每一步都留Trace可观测性设计多Agent系统调试起来比单Agent恶心得多因为一个结果可能是十几次调用之后才出来的中间任何一步产生偏差你都不知道是哪一环带偏的。传统微服务那套“看日志”根本不够因为日志只能告诉你“调了哪个接口”而多Agent系统里最关键的是“模型当时读到了什么上下文、输出了什么中间判断”。我的做法是给每个Agent调用都埋一个trace结构至少包含request_id贯穿全链路agent_id和阶段名称这个Agent收到的完整输入包括Prompt关键片段、之前环节的产物摘要模型返回的原始输出后处理之后的实际使用字段本次调用的延迟和Token消耗如果触发了重试保留每一次尝试的记录这些trace可以存到数据库或日志系统里但一定要结构化。调试时我习惯先把一次完整流程的trace导出成一个JSON文件用脚本检查其中每个Agent的输出是否满足下游J阶段的输入要求。十有八九问题都出在“某个Agent返回的字段名和下游对不上”这种低级错误上。除了追踪单个任务还要做“横向对比”。比方说你优化了某个Agent的Prompt到底是让结果变好了还是变差了把优化前后的trace放在一起对比看中间输出的结构完整度、下游采纳率、最终结果质量。没有这套可观测性你所谓的“优化”就是玄学。6.3 成本与性能的平衡技巧多Agent系统成本高的主要原因不是Agent数量多而是“无效调用”太多。一个任务来回聊天聊了十轮其中七轮都只是在纠正上一轮的错。控制成本的关键在于减少无效交互提高一次调用的成功率。我的几个实测有效的降本技巧能不用LLM就不用LLM解析JSON、修改字段、格式转换这类确定性工作用代码库里的解析器或正则处理不要丢给模型。很多“Agent工具调用”完全可以用普通函数实现只有需要理解语义的地方才调用模型。优先用小模型处理简单子任务分类、抽取关键词、模板填空这类任务用一个参数量较小的模型就够了没必要每个Agent都用最强的旗舰模型。我自己的项目里编排者Agent用更强的模型执行Agent大多用中等模型资深评审Agent才用旗舰模型整体成本能降40%效果损失很小。开启上下文缓存多Agent系统里很多Agent收到的基础背景是相同的比如产品介绍、用户需求。如果底层API支持Prompt缓存把这些公共部分缓存起来能省不少Token费用。结果缓存对于同样的子任务输入如果结果已经存在且没有过期直接复用缓存结果不要再调用模型。这个在一轮多轮对话里特别管用。比如用户问了两次相似的问题第一次的全链路结果缓存下来第二次直接返回。性能上的另一个坑是“串行优化不够”。有时候你刚跑通一个六步串行的多Agent流程单次体验要十几秒用户一定觉得卡。实际上只要上游步骤的A和B之间没有依赖关系就能并行。但并行会带来吞吐压力和并发导致的新问题。我通常采取“局部并行总体串行”的策略——先把最耗时的几个独立步骤并行跑掉再进入串行关键路径。比如一次检索任务里多个搜索源之间可以并行但写报告必须在所有检索完成后才开始。说到底多Agent不是为了显得高级才存在的。它能帮你做单Agent做不了的事更长的上下文处理、更清晰的分工协作、更可靠的多角度校验。但它也带来了通信、状态、成本三座大山。别被演示Demo忽悠了先想清楚拆不拆、怎么串、怎么合并再动手写代码。这一套组合拳打下来你的多Agent才是真正解决问题的架构而不是给模型加班的理由。