多智能体协同作战图设计指南：从单Agent瓶颈到军团协作

这两年我越来越笃定一件事单打独斗的 Agent 已经过时了。不是说单个智能体没用而是当你真正把一个任务丢给它让它从帮你写一段代码变成替你扛一个完整的业务流时单 Agent 很快就会暴露出一堆问题上下文塞爆、角色混乱、出错后没人纠偏。于是我开始把目光转向智能体军团——让多个各司其职的 Agent 组成一张协同作战图像排兵布阵一样去拆解任务。这篇文章就是我搭过几个多智能体系统之后对协同作战图到底该怎么设计的完整复盘。适合那些已经跑通过单 Agent Demo、正准备往真实业务场景落地的开发者也适合想搞清楚多 Agent 协作到底比单 Agent 强在哪里的产品和技术负责人。1. 为什么单枪匹马的 Agent 总在关键时刻掉链子先聊点真实的。我最早做 AI 应用的时候思路特别简单把所有需求都塞进一个 Agent 里指望它能者多劳。比如让它既要做信息检索又要做数据分析还要负责最后的文案输出。做个 Demo 给朋友演示效果确实惊艳。可一旦把场景换成每天生产真实内容、处理真实数据问题就一个接一个冒出来。这些坑不是模型不够聪明而是单 Agent 的架构上限就在那里。1.1 单 Agent 的三大死穴上下文、工具边界、错误放大第一个死穴是上下文窗口有限。大模型的上下文是稀缺资源当任务链条很长中间过程会产生大量中间结果这些结果全堆在同一个上下文里很快就把窗口撑爆。更麻烦的是前面的信息会污染后面的推理。比如检索回来 20 篇文档Agent 在处理到第 15 篇的时候可能已经忘了第 1 篇在讲什么于是产生幻觉。这不是提示词工程能救回来的这是信息过载的物理限制。第二个死穴是工具边界模糊。真实业务流往往需要多种能力检索、计算、调用外部 API、生成结构化数据、做质量校验。你把所有工具都挂在同一个 Agent 上它会频繁地在不同工具之间切换。而每切换一次都意味着一次上下文重写、一次注意力分散。我见过某个 Agent 在检索——分析——写入数据库这个链条上反复横跳最后把一段应该写入金额字段的内容写进了日期字段。它并不是不懂只是角色的连续一致性在长链路里维持不住。第三个死穴是错误会被放大而不是收敛。单 Agent 链条里如果一个环节出了问题后续所有环节都会基于错误继续执行。更棘手的是单 Agent 没有自我纠偏的天然机制——它一边干活一边检查自己的产出等于让运动员兼任裁判效果可想而知。你只能靠外部再加一层校验逻辑可这样你自己就变成了那个第二 Agent。1.2 多智能体协同的本质分工、交接、校验搞明白单 Agent 的瓶颈再看多智能体就顺了。所谓智能体军团协同作战图本质上做三件事分工把一个大任务拆成若干小任务每个小任务对应一个专职 Agent交接定义清楚 Agent 之间的输入输出接口让信息像流水线一样有序流转校验让独立的 Agent 或规则去检查关键产出质量不达标就退回重做。打一个最朴素的比方单 Agent 像一个小工作室一个人包揽策划、写稿、排版、设计听着全能实际产能被严重限制多智能体像一个正规内容团队策划、写手、编辑、设计各管一摊每道工序之间有明确交接物和验收标准。一个人改稿改十遍不如让写手和编辑互相盯一眼这就是校验的价值。有一点必须强调多智能体绝不是让几个 Agent 多轮聊天。很多人一上来就让两个 Agent 你一言我一语地对话以为这就是协作了。但自由对话没有结构没有接口规范没有终止条件最后通常会陷入两个结果要么无限循环要么跑题。真正的协同作战图第一步就是把聊天变成结构化协作。1.3 什么场景才值得搞军团在动手设计协同图之前建议先对号入座。以下三类场景是最典型的适合搞军团一是研究分析类比如搜集 20 个来源的信息→交叉验证→输出一份带引用的分析报告。这类任务天然有检索、筛选、整合、生成的阶段划分拆成多个 Agent 后每个环节都可以用最合适的模型策略来处理。二是内容生产类比如每天基于一批新闻素材产出公众号长文 微博短文案 内部摘要。同一个素材要适应三种不同风格和长度要求用三个专职 Agent 分别处理比一个 Agent 来回变换人设要稳定得多。三是批量化处理类比如批量读取客户工单→分类→标记优先级→起草回复→质检后发送。这类任务串行阶段多每个阶段的需求都很明确非常适合流水线式协同。反过来如果只是简单的知识问答、单轮翻译、摘要生成单 Agent 完全够用强行拆成军团只是自找麻烦。这一点后面我会专门展开先记住多智能体是手段不是目的。2. 先分清阵型再谈协作五种常见的智能体协同拓扑协同作战图这四个字设计的核心其实是图——也就是节点和边的关系。节点是 Agent边是消息流转。在我画过和复盘过的项目里多智能体的协作关系基本跑不出五种基础拓扑。每种拓扑解决一类问题也各有代价。搞清楚这五种拓扑你画图的时候才不会拍脑袋。2.1 主管-下属模式一个掌控者拆解全局任务这是最经典、也是新手最容易上手的拓扑。整体结构是一个主管 AgentSupervisor对着一群专职下属 Agent。主管负责理解用户的总目标把目标拆成子任务然后一个个派发给合适的下属下属完成后把结果交回主管再汇总、决策下一步。这其实就是一个项目经理 团队的结构。主管并不直接干活它负责的是调度和整合。我见过很多成功的案例比如某个研究报告生成系统主管先派出资料员去搜资料然后派分析师去出框架再派写手去扩写最后派校对员去查重。主管在每个环节都看结果、拍板是否进入下一步。这个拓扑的优点是职责清晰、可控性强主管可以在任何环节截停防止任务跑偏缺点是主管会成为瓶颈所有信息都要过它这一手复杂度上升后主管的上下文也会紧张。适合任务边界清晰、子任务划分明确的场景。2.2 流水线模式上一站的产出就是下一站的原料流水线拓扑很好理解Agent 按顺序排成一条线前一个 Agent 的输出经过程序化处理变成后一个 Agent 的输入。每一步只做一件事做深做透然后传给下一棒。整个过程不回流、不向上汇报像工厂生产线。我经常用流水线处理内容生产场景第一个 Agent 做素材采集把原始信息清洗成结构化条目第二个 Agent 做数据分析找出关键数字和趋势第三个 Agent 做内容生成把数据改写成可读的文案最后交给质检 Agent做格式和事实校验。每个 Agent 的职责被压缩到很小因此指令精度可以提得很高。流水线的优点是效率高、逻辑简单缺点是灵活性差如果有一步需要回溯或者旁路处理流水线的表达能力就不够了。所以流水线适合那些输入稳定、流程固定的批处理任务。2.3 辩论与对抗模式让不同立场互相找茬这个拓扑最近很火。思路是让两个或多个 Agent 站在不同立场对同一个问题分别给出答案或判断再由一个评审 Agent或规则模块做最终裁决。典型的用法有一个 Agent 写方案一个 Agent 找方案的漏洞或者两个 Agent 分别基于不同数据源做分析再把结果对比验证。我折腾过最实用的一种是在内容审校场景里一个 Agent 担任流量派负责从选题吸引力的角度挑毛病另一个 Agent 担任严谨派负责从事实准确性的角度挑毛病。两个 Agent 各自输出一批问题清单最后由一个评审 Agent 汇总去重决定哪些修改必须做、哪些可以忽略。对抗模式的优点是显著提高产出质量尤其适合容错率低的场景缺点是成本翻倍而且如果缺少有力的裁决机制容易陷入互怼循环。切记对抗不是目的让第三方做决策才是目的。2.4 网状协商模式Agent 之间自由协作网状拓扑是最多智能体的多智能体所有 Agent 互相可见可以自由发送消息、请求帮助、交换信息没有中心化的主管。这种结构像一张合作网理论上最灵活Agent 之间可以形成动态的临时协作关系。但这种拓扑也是最危险的。没有中心调度意味着没有全局视角Agent 之间的协作路径不可预期很容易出现A 请求 BB 又请求 A的循环或者某个 Agent 被大量消息淹没。我现在的建议是除非团队里有非常强的可观测性基础设施建设否则不要轻易上全局网状结构。即便要上也建议先加一个消息中央路由限制 Agent 之间的直连让所有协作都经过可控的通道。2.5 市场与路由模式让任务动态找到专家最后一种拓扑本质上是一种动态路由。系统里挂着一堆专家 Agent每个 Agent 注册自己的技能标签和能力描述。当任务进来时由一个路由器 Agent或规则匹配器判断这个任务应该交给哪个专家如果任务比较复杂则可能拆解后在多个专家之间流转。这个模式有点像打车平台乘客任务发出需求平台路由器匹配最合适的司机专家 Agent。它的优势是扩展性好新增一个专家只需要注册不需要改动全局逻辑缺点是路由器本身需要做得足够聪明且对专家 Agent 的能力描述要非常准确否则会频繁派错单。2.6 五种拓扑怎么选一个很朴素的判断逻辑画协同图之前先问自己三个问题任务的前后顺序重不重要如果重要考虑流水线任务的子任务之间需不需要相互校验如果需要加对抗任务是不是需要一个总负责人持续拍板那就上主管-下属。网状拓扑不是不能用它更适合做内部探索型应用但真到了生产环境我建议先从其余四种里选。下表是我自己在选型时常用的快速对照拓扑核心特征最适配场景主要风险上手难度主管-下属中心调度、全局决策任务边界清晰、需要全局把控主管上下文瓶颈低流水线顺序流转、职责单一批处理、固定流程灵活性差低辩论-对抗多元视角、交叉验证审校、方案评审循环与成本中网状协商自由协作、动态组合探索型任务、小规模系统失控与循环高市场路由动态分配、专家注册专家多、任务类型杂路由准确率中配合使用也很常见我自己最常用的是主管-下属 流水线混搭主管负责拆任务每个子任务内部再走一段流水线。图不一定要纯粹关键是每一条边你都说得清楚为什么要这样连。3. 把协同图画清楚的三个核心设计要素角色、消息、裁决拓扑是骨架真正让协同图跑起来的是三个设计要素角色定义、消息通信、裁决机制。很多人的协同图画出来花里胡哨一跑就崩问题基本都出在这三件事没做好。3.1 角色卡片每个 Agent 的职责边界要写到什么程度画协同图的第一步不是连线而是先把每个 Agent 的角色卡片写出来。我写角色卡片一般包含五个字段岗位名称、核心目标、输入内容、输出内容、可用工具。限制越明确Agent 越不容易越界。举个例子在一个内容生产协同图里我会这样定义角色角色核心目标主要输入必须输出可用工具采集官拿到最新原始素材资讯源、行业关键词结构化素材列表含来源、时间、摘要搜索接口、RSS 读取器分析师找出素材中的数据亮点结构化素材列表分析结论与数据表格代码解释器、统计函数写手把结论改写成可读文案分析结论初稿正文无纯生成质检官校验事实与格式初稿正文、原始素材问题清单或通过标记事实比对工具写完角色卡片你会发现自己对每个 Agent 的提示词都变得特别精准因为你不需要再告诉它你是一个无所不能的助手你只需要告诉它你负责接收结构化素材列表只做一件事找出其中最突出的三个数据亮点输出一份分析结论。职责边界还有一个隐性作用它能帮你控制成本。每个 Agent 只携带与它职责相关的少量上下文模型推理时注意力更聚焦token 消耗也更可控。3.2 消息协议别让 Agent 之间说人话多智能体系统最容易犯的一个错误是让 Agent 之间用自然语言互相聊天。问题是自然语言高度冗余、信息密度低、不可枚举导致下游 Agent 需要花大量上下文去解析对方的模糊表达。正确的做法是在 Agent 之间传递结构化消息。我设计消息结构时常用的最小字段集是这样{ message_id: c7f33a1e-9b21-4a12-8d42-1d8a5f00f3a1, sender: collector_agent, receiver: analyst_agent, task_type: analyze_trends, payload: { materials: [ {title: ..., source: ..., content: ..., collected_at: ...} ] }, status: success, trace_id: task_0821_01 }这里必须保留的字段是trace_id和status。trace_id解决可观测性一次完整任务的链路追踪全靠它status解决失败传递下游 Agent 收到status: failed的任务时可以直接跳过或启动补偿逻辑而不是傻乎乎地继续处理一堆空数据。在具体实现上消息可以走两类通道一是中心化状态所有 Agent 读写同一个 State 对象适合用图编排框架直接管理二是消息队列Agent 之间通过队列收发消息适合更松耦合的系统。前者更简单、更容易追踪后者更灵活但需要额外处理消息消费和重试。我的经验是在项目早期选中心化状态就够了别一上来就上消息队列那是在给自己加复杂度。3.3 裁决机制质量闸门和返工回路协同图里不能只有干活的 Agent必须要有验收的机制。我把这个机制叫做质量闸门Quality Gate。每个闸门有两个选项通过则任务流向下一节点不通过则回到上游某节点返工或直接转人工。裁决的实现方式有几种按成本从低到高排列规则闸门比如检查输出 JSON 是否合法、字段是否完整、字数是否达标模型闸门用一个评分 Agent 对产出打分人工闸门关键节点直接插入人工审批。生产环境通常吃混合方案低风险环节用规则高风险环节上模型关键决策点上人。这里有个很关键的参数返工最大轮次。如果不设上限一个写手 Agent 和质检 Agent 可以无限循环下去成本直接爆掉。我常用的策略是返工最多两轮两轮之后无论质量如何直接提交给人处理。因为从实际经验看第三轮及以后的返工边际收益极低Agent 往往只是在同一个圈子里打转与其让它继续改不如把球踢给人类。4. 实战把一张内容生产战情室协同图跑到能上线前面讲的都是方法论这一节上一个完整案例。我称它为某内容生产战情室是我做过的一个模拟项目目标很简单每天自动基于最新资讯产出三样东西——一份行业日报、一份周度趋势分析、若干条社交平台短文案。听起来不大但你要是试图用单 Agent 搞定会发现它要同时扮演编辑、分析师、写手、标题党早早就精神分裂了。我们用多智能体协同图来解决。4.1 场景设定与基础选型先看战情室要处理的原始输入一批资讯源链接、若干行业关键词以及用户指定的当日关注主题。输出端是三类产品日报严肃、结构化、周报偏深度分析、短文案活泼、碎片化。这个场景天然适合主管-下属 流水线的混搭拓扑。技术选型上我没有重度依赖某个特定框架用的是当前主流的图编排框架思路状态共享 节点函数。简单说整个系统维护一个全局状态 dict每个 Agent 节点是一个函数读取上游写入状态的字段处理后写回新字段然后根据状态中的标记决定下一步走到哪个节点。这么做的好处是逻辑透明挂了可以直接看状态在哪一步断的。4.2 战情室里的 Agent 角色编排战情室里设了五个角色采集官从资讯源抓取内容清洗 HTML抽取出标题、正文、时间、来源输出结构化素材列表。分析师接收素材列表围绕用户关注主题做数据统计和趋势归纳输出观点结论。写手日报线基于分析结论生成正式日报要求语言克制、提供数据引用。写手社媒线基于同一份分析结论生成 5 条不同风格的短文案要求口语化、有传播性。质检官检查日报和短文案是否存在事实错误对照素材原文、是否缺失关键数据、格式是否符合发布规范。画成协同图大概是这样的执行顺序采集官先跑 → 分析师再跑 → 两条写手线并行执行 → 质检官统一验收 → 不合格返工合格输出。这里有一个典型的扇出再扇入结构分析师产出同一份结论喂给两个不同的写手最后汇总到同一个质检官。这类结构在图编排框架里实现起来特别顺手。4.3 核心代码逻辑状态、节点、边我简化一下核心逻辑。首先是状态定义class BattleRoomState: materials: list # 采集官的产出 analysis: dict # 分析师的观点结论 daily_report: str # 日报线写手的产出 social_posts: list # 社媒线写手的产出 quality_report: dict # 质检官的验收结果 current_step: str # 当前走到哪个环节然后是把每个 Agent 封装成节点函数。这里我只贴关键的调度部分让协同关系的逻辑更清楚def run_pipeline(state): # 第一站采集 state.materials collector_agent.run(source_urlsconfig.SOURCES) state.current_step collector_done # 第二站分析 state.analysis analyst_agent.run( materialsstate.materials, focusconfig.FOCUS_TOPIC ) state.current_step analyst_done # 第三站两条写手线并行可以同时执行 from concurrent.futures import ThreadPoolExecutor with ThreadPoolExecutor(max_workers2) as pool: f_daily pool.submit(daily_writer.run, state.analysis) f_social pool.submit(social_writer.run, state.analysis) state.daily_report f_daily.result() state.social_posts f_social.result() state.current_step writers_done # 第四站质检闸门 state.quality_report qa_agent.run( daily_reportstate.daily_report, social_postsstate.social_posts, original_materialsstate.materials ) if state.quality_report[passed]: state.current_step done else: state.current_step needs_fix return state这个结构里有一个值得注意的设计采集官的输出是结构化素材列表分析师接收的是结构列表而不是原始正文。这样分析师就不需要反复读全文只需要基于已经抽好的要点做归纳。省 token 还在其次关键是避免了分析师被素材细节带跑的风险。4.4 跑出来的效果和必须做的两个改进我拿这个模拟系统跑过大概一百个任务印象最深的是质检官节点对整体质量的兜底作用。前面几版没有质检官时偶尔会产出看起来通顺但数据对不上原文的报告混在正常产出里特别难发现。加上质检官并配置事实比对逻辑后这类硬伤基本能在输出前被拦截住。另外一个必须做的是人工审批闸门。尤其是日报这类对外可见度高的产出我最后在质检官之后加了一个人工确认节点属于批次发布前的最后一道关卡。所谓自动化不一定是全无人化在关键节点保留人工权限才是对自动化能力的尊重。战情室运行中真实的人工介入率最终压到了两成左右且大都发生在重大数据发布的当天。这个比例完全可以接受。5. 协同图落地时绕不开的五个坑方法再好落地时该踩的坑一个都不会少。我挑五个最有共性的问题展开讲每一个都是我一度被搞到头皮发麻的实战经历。5.1 坑一循环依赖与死锁编出来的图走不通多智能体系统里最隐蔽的问题不是某一步报错而是整个图卡住不动。典型情况是Agent A 要等 Agent B 的结果Agent B 又要等 Agent A 的结果两个节点互相等待谁也没法先开工。还有一种更隐蔽的是间接循环A 依赖 BB 依赖 CC 又依赖 A三四个节点串成一个环画图时根本察觉不到。解法分两层。第一层靠设计画完图后强制检查一遍有向边确保整体是一个有向无环图DAG至少主干链路不能有环。如果确实需要反复修改这样的回路不能把它画成原路返回的闭环而是用一个单独的返工计数状态来标记返工节点重新触发时走的是一个新的执行分支。第二层靠兜底在调度器层面设置每轮执行的最大节点数和超时时间一旦超过宁可任务失败也不能让它悄悄跑一晚上消耗 token。5.2 坑二上下文污染A 的记忆串到了 B 的大脑里在图编排框架中多个 Agent 共享同一个全局状态。这本来是方便但也容易变成灾难。比如采集官把原始素材写进了状态写手生成文案时不光读了分析结论还把采集官的原始素材捞出来直接当成自己的输出素材于是写出来的段落黏着大量原文碎片。这就是上下文污染下游 Agent 收到了过量、与它当前职责无关的信息被带偏了。我的对策是每一个 Agent 节点在接收输入前先做一次字段级的过滤只把它该看到的字段放进它的上下文。采集官看不到质检报告写手看不到其他写手的初稿分析师只需要结构化的素材列表。核心原则就一句各 Agent 之间只传递完成当前任务所必需的最小信息集。宁可多定义几个中间字段也别把所有半成品都堆在一个共享大状态里。5.3 坑三成本失控智能体军团变成了烧钱黑洞多 Agent 系统的推理成本不是简单的加法而是乘数。因为每多一个 Agent就多一份独立的上下文和多轮推理再加上总控节点的调用、质检节点的评分、返工循环的迭代一笔任务跑下来账单很吓人。我见过某个任务链条光主链路就调用了十几次大模型还是不同规模的模型各调各的。控制成本要从三个角度同时使劲。第一能用小模型的地方不上大模型路由判断、字段提取、格式检查这类轻量任务用便宜的小模型完全够第二限制返工和重试次数这是最有效的止损手段第三凡是程序能做的校验不要用模型去做比如 JSON 格式检查、字段存在性校验写几行正则就完了完全不需要再问一次大模型。5.4 坑四责任推诿质检官说改写手改完还是不行多 Agent 系统里有一种特别让人抓狂的现象质检官提出修改意见写手改完交回来质检官又说不行再改再说不行的循环就这样反复出现。从我的观察看原因通常不是两个 Agent 在互相找茬而是质检标准没有被形式化。质检官靠感觉判断写手靠感觉修改标准一直漂移永远对不上。解法是把质量闸门从主观评分改成清单校验。我在质检节点里维护一份显式的检查清单每一项是布尔判断是否包含至少三个数据来源是否有引用来源字段所有数字是否与素材原文一致每条短文案是否超过 50 字质检官每次输出这份清单的勾选结果写手拿到清单后照着补就行。返工轮次的收敛效果立竿见影。5.5 坑五故障定位难任务挂了你不知道去找谁单 Agent 出问题报错信息就在那一个调用里好查。多 Agent 系统出问题可能是采集环节源头数据格式变了可能是分析师模型抽风可能是质检规则误判也可能只是某个中间字段没传对。没有可观测性的话排查一次故障能把人耗到崩溃。所以我有两条硬规矩。第一每个 Agent 节点入口和出口都打日志记录入参摘要、出参摘要、耗时、token 消耗以及最重要的trace_id。第二所有节点共享同一个trace_id这样任何一次失败的任务都可以按 trace_id 把整个链路的日志捞出来快速定位卡在哪一个环节。很多智能体框架自带 tracing 能力一定要在项目初期就把它开起来别等到出了问题再补。6. 什么时候该收手不要为了多智能体而多智能体聊了这么多怎么把军团建起来最后我得泼一盆冷水。多智能体是手段不是目的。在我身边已经能看到一种现象有开发者为了让项目听起来高级不管什么场景都强行拆出四五个 Agent结果系统变慢、变贵、变难维护产出质量还没有单 Agent 直接跑得好。这种为了多智能体而多智能体的倾向才是这个领域最大的坑。6.1 单 Agent 依然够用的几个信号你自己判断一下如果下面几条里命中三条以上我建议你老老实实先把单 Agent 用透不要动拆分的念头。第一任务链条短整个流程不超过三四个操作步骤上下文不会膨胀。比如把这段录音转成文字并润色两步搞定拆成两个 Agent 纯属脱裤子放屁。第二角色不需要多次切换整个任务始终是同一个视角。比如根据这篇论文写一份摘要从头到尾都是读者视角不需要变成批评者、再变成改写者。第三你目前最痛的是单次生成质量不够而不是流程复杂。这种情况应该先去调提示词、补示例、做检索增强而不是拆 Agent。质量问题很多时候不是人不够而是工具不够或数据不够。第四成本敏感。多 Agent 系统对个人开发者和中小团队来说是一个持续性的成本负担。如果你的付费能力有限那先单 Agent 工具链是你性价比最高的方案。6.2 渐进式改造从单 Agent 工具开始长出征兆如果你判断下来确实需要多智能体也建议不要一把梭走渐进式路径。第一步先把工具做好让单 Agent 有能力去调用检索、计算、写库第二步加一个质检 Agent只负责对主 Agent 的产出做检查这是最简单、收益最明显的多 Agent 改造第三步把主流程拆成两个阶段比如先分析再生成让每个 Agent 专注一个阶段最后在上面的基础上再按需要加入主管、路由、人工闸门。我用这个顺序迭代过好几个项目每一次都踩在刚好需要的节点上没有一次是因为面子工程硬上架构。做技术最忌讳的是拿架构复杂度来证明自己很专业。真正的专业是让系统在自己该有的复杂度上运行多一分浪费少一分不稳定。说到底智能体军团协同作战图不是一张挂在墙上的气势恢宏的蓝图它就是一份工程图纸。节点定得越清晰、边画得越克制、闸门设得越明确你的军团就越能打。画图之前用笔在纸上把角色、消息、裁决列出来能帮你躲掉九成的返工。以后你回头看自己设计的那些协同图最成功的大概率不是编排得最花哨的那张而是每个 Agent 都知道自己该干什么、不该干什么的那张。