Multi-Agent 的四种协作模式：Supervisor、Swarm、网状、流水线，怎么选？

你搭了一个 Agent，起初跑得挺好。后来需求升级了，调研+写作+事实核查全压在一个 Agent 上。结果上线后发现：系统提示词膨胀到 800 字，工具列表里有 15 个工具，Agent 开始选错工具、忘记自己设定的规则，偶尔一步出错后面全错。你在想，是不是我的 Prompt 写得不够好？

不是 Prompt 的问题。是单个 Agent 扛不住「又要调研、又要写作、又要核查」这种多角色任务的根本性矛盾。

解法是：多个 Agent 协作，每个只干一件事。

但协作本身是有结构的。乱搭一通不等于 Multi-Agent，是 Multi-Chaos。

这篇我把 Multi-Agent 的四种主流协作模式逐一拆透：Supervisor（主管模式）、Swarm（蜂群模式）、网状（Mesh）、流水线（Pipeline）。每种模式的原理、代码、优缺点、以及适合什么场景——读完你就知道自己该选哪个。

01 为什么单 Agent 会撞墙

先说清楚「为什么要多 Agent」，不然后面的架构选型没有判断基础。

单 Agent 的三个典型死法：

第一死：上下文窗口污染

一个 Agent 挂了 12 个工具，每个工具的描述就占几百个 token。任务执行到第 7 步，第 2 步的关键信息已经被挤出上下文或稀释掉了。Agent 开始「失忆」。

第二死：角色混乱

一个 Agent 被要求「调研 + 写代码 + 写总结」。系统提示词里三组指令互相抢占优先级。调研没完整就开始写代码，写代码时又用写作语气。结果三件事都干得不够好。

第三死：故障扩散

第 3 步出错，第 4 到 10 步全部污染，没有隔离层，没有独立校验。出了问题只能整条链路重跑。

Multi-Agent 的解法很直接：每个 Agent 只干一件事，用清晰的接口对话，出错只影响一个节点。

但协作方式不同，系统的灵活性、可控性、调试难度差别很大。下面逐一拆解。

02 Supervisor 模式：一个指挥，多个专家

核心思想：一个中央 Supervisor Agent 接收用户请求，决定派给哪个 Worker，收到结果后再决定下一步——直到任务完成。

数据流：User → Supervisor → Researcher/Writer/Fact-Checker → Supervisor → Final Answer。Workers 之间互相不认识，所有信息都经过 Supervisor，它是路由层也是汇聚层。

用 LangGraph TypeScript 实现：

importChatOpenAIfrom"@langchain/openai"importfrom"@langchain/langgraph/prebuilt"importfrom"@langchain/langgraph-supervisor"importfrom"@langchain/core/tools"importfrom"zod"constnewChatOpenAImodel"gpt-4o-mini"temperature0consttoolasyncquerystring`Search results for: ${query}`name"search_web"description"Search the web for information"schemaobjectquerystringconsttoolasynccontentstring`# Report\n\n${content}`name"write_report"description"Format findings into a structured report"schemaobjectcontentstring// 每个 Worker 只有自己需要的工具，prompt 精简聚焦constcreateReactAgentllmtoolsname"researcher"prompt"You are a research specialist. Search for information and return factual summaries."constcreateReactAgentllmtoolsname"writer"prompt"You are a writing specialist. Format research findings into clear reports."// Supervisor 绑定所有 Worker，统一调度constawaitcreateSupervisorllmagentsprompt"You are a team supervisor. Delegate research to researcher first, then writing to writer."compileconstawaitinvokemessagesrole"user"content"Research LangGraph and write a report."consolelogmessagesat1content

Supervisor 的优势在于可控性强：路由逻辑集中在一处，哪个 Worker 出错一眼就能追到。代价是 Supervisor 本身容易成为瓶颈——如果任务分解出了问题，下游每个 Worker 都拿到错误的指令。

适合的场景：客服工单路由、内容生成流水线、代码审查工作流——子任务边界清晰、需要中央协调的场景。

03 Swarm 模式：没有指挥，Agent 互相传球

Swarm 的逻辑完全不同：没有中央 Supervisor，Agent 之间直接 handoff（交接）。

Agent A 做完自己的部分，判断「下一步应该由 B 来做」，就把控制权连同上下文一起传给 B。流程从这些 handoff 里「生长」出来，不是预先规划好的——User → Triage → Billing（账单问题） 或 Tech（技术问题） → Final Answer。

TypeScript 实现：

importfrom"@langchain/langgraph-swarm"importfrom"@langchain/langgraph/prebuilt"constcreateReactAgentllmtoolscreateHandoffToolagentName"billing_agent"description"Transfer to billing for payment issues"createHandoffToolagentName"tech_agent"description"Transfer to tech support for technical issues"name"triage_agent"prompt`You are a triage agent.- Billing/payment issues → handoff to billing_agent- Technical problems → handoff to tech_agent- General questions → handle directly`constcreateReactAgentllmtoolscreateHandoffToolagentName"triage_agent"description"Return to triage"name"billing_agent"prompt"You are a billing specialist. Return to triage if off-topic."constcreateReactAgentllmtoolscreateHandoffToolagentName"triage_agent"description"Return to triage"name"tech_agent"prompt"You are a technical support specialist. Return to triage if off-topic."// 生产必须设递归上限，防 handoff 死循环！constcreateSwarmagentsdefaultActiveAgent"triage_agent"compilerecursionLimit25constawaitinvokemessagesrole"user"content"My payment failed but system shows it succeeded."

核心是createHandoffTool——Agent 通过调用它来转交控制权，上下文一起传递不会断。

最大的坑：无限循环。Agent A 认为该转给 B，B 觉得该回给 A，来回互踢。recursionLimit: 25是生产必须加的保险丝。

适合的场景：对话流向不可预测的客服系统、路由场景——「我不知道用户下一步会问什么」的情况。

04 流水线模式：线性流水，每步只管下一步

流水线是四种里最简单也最容易预测的。Agent 串成一条链：Raw Data → Extractor → Enricher → Analyzer → Reporter → Output。每个节点只看上游的输出，没有反向通信，没有跳步。

importStateGraphSTARTENDfrom"@langchain/langgraph"interfacePipelineStaterawTextstringextractedEntitiesstringenrichedDataRecordstringunknownanalysisstringfinalReportstringasyncfunctionextractorNodestate: PipelineStatePromisePartialPipelineStateconstawaitinvokerole"system"content"Extract key entities. Return as JSON array."role"user"contentrawTextconstJSONparsecontentasstringreturnextractedEntitiesasyncfunctionenricherNodestate: PipelineStatePromisePartialPipelineState// ⚠️ 上游输出完整性校验，这是防错误传播的关键ifextractedEntitieslengththrownewError"Extraction failed: no entities. Pipeline stopped."constextractedEntitiesmap(entity) =>context`Enriched data for: ${entity}`returnenrichedDataasyncfunctionanalyzerNodestate: PipelineStatePromisePartialPipelineStateconstawaitinvokerole"system"content"Analyze patterns and identify key insights."role"user"contentJSONstringifyenrichedDatareturnanalysiscontentasstringasyncfunctionreporterNodestate: PipelineStatePromisePartialPipelineStateconstawaitinvokerole"system"content"Generate a human-readable report."role"user"contentanalysisreturnfinalReportcontentasstringconstnewStateGraphPipelineStatechannels/* ... */addNode"extractor"addNode"enricher"addNode"analyzer"addNode"reporter"addEdgeSTART"extractor"addEdge"extractor""enricher"addEdge"enricher""analyzer"addEdge"analyzer""reporter"addEdge"reporter"ENDcompile

流水线的最大问题是错误传播：第一步出了错，后面步骤全部受污染，但 Agent 不知道上游数据有问题。所以每个节点间必须加完整性校验——就像enricherNode开头那段一样，上游空了就直接抛错停流水线，不要让问题悄悄流过去。

适合的场景：ETL 数据处理、文档批量加工、「第 N 步输出就是第 N+1 步输入」的确定性流程。

05 网状模式（Mesh）：任意互联，最自由也最难驾驭

网状是四种里最灵活也最难控制的。任何 Agent 都能在任何时刻调用任何其他 Agent，没有预设的顺序——Research ↔ Writer ↔ Fact-Checker ↔ Summarizer，谁在任何时候都可以呼叫谁。

LangGraph 里通过Command对象实现动态路由：

importCommandStateGraphMessagesStateSTARTENDfrom"@langchain/langgraph"asyncfunctionresearchNodestate: MessagesStatePromiseCommandconstawaitinvokerole"system"content`You are a research agent.After research, decide who handles next.Reply with: NEXT: writer_agent | NEXT: fact_checker | NEXT: END`messagesconstcontentasstringconstmatch/NEXT:\s*(\w+)/const1ENDreturnnewCommandupdatemessagesgoto"END"ENDasyncfunctionwriterNodestate: MessagesStatePromiseCommandconstawaitinvokerole"system"content`You are a writer. Write based on research.After writing, route as needed: NEXT: fact_checker | NEXT: summarizer | NEXT: END`messagesconstcontentasstringconstmatch/NEXT:\s*(\w+)/const1ENDreturnnewCommandupdatemessagesgoto"END"END// Mesh 必须设递归上限，动态路由可能形成环constnewStateGraphMessagesStateaddNode"research_agent"ends"writer_agent""fact_checker"ENDaddNode"writer_agent"ends"fact_checker""summarizer"ENDaddEdgeSTART"research_agent"compilerecursionLimit50

网状的真实优势是处理「任务中途需要动态决策」的场景——写到一半发现需要补充调研，调研完发现需要核查，核查完再返回写作。没有预设的顺序，能适应动态需求。

但代价是：调试极度痛苦。执行路径不可预测，12 次 LLM 调用里找 bug 就像读一本少了好几章的悬疑小说。生产环境必须接好 LangSmith Tracing，这是基础设施，不是可选项。

适合的场景：复杂的创意协作、研究任务、「执行过程中才知道下一步要什么」的动态任务。

06 四种模式横向对比

选型决策思路：先看任务是不是线性的——是就用 Pipeline，最简单，不引入不必要复杂度。任务有分支但分支可预测，选 Supervisor，好维护好追问题。任务流向由用户驱动、对话走向不可预测，选 Swarm。只有在「真的需要任意 Agent 之间动态协作」时，才用 Mesh——并且做好完善的 Tracing 基础设施。

07 常见坑

坑 1：Supervisor 成为新的单体 Agent

所有任务都经过 Supervisor，Supervisor 的 prompt 越写越长，最终它本身成了新的单体 Agent。解法：Supervisor 只做路由决策，不做业务处理。Supervisor prompt 超过 300 字，说明业务逻辑放错地方了。

坑 2：Swarm 的 handoff 死循环

Agent A 认为该 B 处理，B 觉得该回给 A，来回互踢。生产环境必须设recursionLimit: 25，另外给每个 Agent 明确的「我不处理什么」指令。

坑 3：Pipeline 的「部分成功」假象

研究 Agent 返回了 5 个字段里的 4 个，下游 Agent 基于不完整数据生成了看起来合理的输出，校验通过，上线，然后那个缺失字段引发故障。解法：每个 Pipeline 节点校验输出完整性，不只是格式，还要校验关键字段是否都存在。

坑 4：成本爆炸没感觉

一次 Supervisor 调用 + 三次 Worker 调用 = 至少四次 LLM 请求。加上重试可能是十次。解法：Supervisor 用强模型，Worker 用便宜模型；按 Agent 打 tag 追踪 token 消耗，月账单超标前就能预警。

坑 5：Mesh 里没有 Tracing

12 次 LLM 调用，4 个 Agent，没有关联 ID，出了问题无从定位。任何 Multi-Agent 系统上生产前，先把 LangSmith Tracing 接好——这是基础设施，不是可选项。

总结

Supervisor 是默认起点：控制权集中，路由逻辑清晰，出问题好追，大多数场景优先考虑。

Swarm 适合对话不可预测的路由场景：handoff 是核心机制，但必须设递归上限防死循环。

Pipeline 是最简单的选择：线性任务不要引入多余复杂度，每个节点加完整性校验防错误传播。

Mesh 最灵活也最危险：动态协作强，但调试代价高，没有完善 Tracing 不建议上生产。

成本随模式复杂度倍增：Supervisor 用强模型，Worker 用弱模型；按 Agent 追踪成本，上生产前先做压测。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】