要把多个 Agent 串成一条能跑的生产链路,关键不是堆 Agent 数量,而是先把编排模式选对。在 2025 年的企业 AI 项目里,多 Agent 系统已经变成默认选项——但同样的 Agent 池,套上不同的编排骨架,产出质量、token 成本、调试难度会差出一个量级。下面把 4 大主流编排范式拆开讲清,重点放在工程团队尤为在意的”什么时候该用谁”。
一、4 大编排范式的全景视图
当下能落地的多 Agent 编排,基本可以归到 4 类:主管—专家(Supervisor)、流水线(Pipeline)、并行群智(Swarm / Debate)、动态交接(Handoff)。它们背后分别对应一种控制权分布:中心化、顺序化、扁平化、动态化。先用一张表给整体印象,后面逐个拆解。
| 范式 | 控制权分布 | 典型框架 | 适合的任务 | 主要代价 |
|---|---|---|---|---|
| 主管—专家 | 中心化 | LangGraph Supervisor、CrewAI Hierarchical、AutoGen GroupChat | 任务可被清晰拆解、需要统一审计 | 主管成瓶颈,单点故障 |
| 流水线 | 顺序化 | LangGraph StateGraph、CrewAI Sequential、MetaGPT | 线性工作流、阶段契约清晰 | 不擅长回环、并行收益低 |
| 并行群智 | 扁平化 | AutoGen、CAMEL、ChatEval、多 Agent Debate | 评审、辩论、需要多视角 | 通信开销大,token 重复高 |
| 动态交接 | 动态化 | OpenAI Agents SDK、Google ADK Agent Transfer | 客服路由、专业域切换 | 状态追踪复杂,易”丢上下文” |
这张表不是”哪个更优”的排序,而是一张选型地图。生产里见过太多团队一上来就堆 Swarm,结果 5 个 Agent 互相 hand off 200 轮,token 烧光却没出活——根因就是任务本身是线性可拆的,根本不需要群智。架构—任务对齐,比”团队大小”重要得多。
二、主管—专家模式:中心化编排的事实标准
主管—专家(Supervisor / Orchestrator-Worker)是当前生产环境出现频率很高的范式。它的骨架很朴素:一个主管 Agent 接收请求、拆任务、把子任务分发给若干专家 Agent、回收结果再做汇总。Anthropic 的 Claude Research 用的就是这一骨架——一个 Lead Agent 配 3~5 个并行 Sub-agent;Salesforce Agentforce、Microsoft Magentic-One、LangChain Deep Agents 走的是同一思路,只是拆任务的粒度、并行度、容错策略不同。
这种范式之所以成为事实标准,核心是它有 3 个工程友好属性:
- 审计链清晰——所有决定都从主管发出来,合规与回放都只盯一条主线;
- 可分层降本——主管用大模型做规划,专家用小模型甚至本地模型执行,成本结构可控;
- 故障隔离简单——某个专家 Agent 翻车,只需要替换或重试它,主管不用动。
代价同样明显:主管 Agent 自己也是 LLM,它会做出错误的路由决策;任务并发度拉高时,主管的”上下文压力”会迅速上升。在内部一个 20+ 节点的客服系统里实测过,主管单点吞掉的 token 占整条链路的 15%~45%,如果不做分层降本,账单会很疼。
下面是一段基于 LangGraph 的最小化主管—专家骨架,展示”如何把专家注册成可被主管调用的工具”:
# supervisor.py
from typing import Annotated, Literal
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o")
# 专家 Agent:各自只做一件事
researcher = create_react_agent(llm, tools=[search_tool])
writer = create_react_agent(llm, tools=[])
reviewer = create_react_agent(llm, tools=[])
# 把专家包装成主管可调用的"节点"
def research_node(state):
result = researcher.invoke({"messages": state["messages"]})
return {"messages": [result["messages"][-1]]}
def write_node(state):
result = writer.invoke({"messages": state["messages"]})
return {"messages": [result["messages"][-1]]}
# 主管自己也是一个 Agent,负责路由
supervisor_agent = create_react_agent(
llm,
tools=[research_node, write_node, reviewer_node],
)
graph = StateGraph(MessagesState)
graph.add_node("supervisor", supervisor_agent)
graph.add_edge(START, "supervisor")
graph.add_edge("supervisor", END)
app = graph.compile()这段代码体现了主管—专家的精髓:专家 Agent 本身不直接与用户交互,它们被包装成主管可以”调用”的工具,主管的 system prompt 里写明”遇到研究类问题调 researchnode,遇到写作类问题调 writenode”。效果上,任何一次执行都能在 Langfuse 之类的可观测平台里看到一条完整 trace,失败回放、token 拆账都顺。注意点:专家之间的数据要通过状态(State)显式传递,不要让专家直接读写主管的 messages,否则主管会被噪声淹没。
三、流水线模式:线性工作流的天然解
流水线(Pipeline / Chain-of-Agents)把任务拆成固定的若干阶段,每个 Agent 干一个阶段,产物按顺序往下传。它和主管—专家的差别在于:流水线没有”会思考”的主管,阶段之间是确定性数据流。MetaGPT 把 SOP 编码成 prompt 序列,ChatDev 把开发流程拆成 Design → Coding → Testing,Uber 的 AI Coding Agent 拿 LangGraph 搭出测试流水线,这些都属于这一范式。
流水线的优势是工程化友好:每个阶段有清晰输入输出契约,可以独立评估、独立替换;整条链路的成本与时延是确定的,适合做 SLA 承诺;支持 checkpoint 与 time-travel debug(LangGraph 的 PostgresSaver + time travel),出问题时能逐段回放。劣势是遇到”上一阶段错了需要回到第三阶段重做”这类回环,流水线会变得笨拙,通常要在边上加条件分支或异常路径来补。
3.1 流水线落地步骤
把一个线性业务流程改造成 Agent 流水线,通常按下面 4 步走:
- 拆阶段:把业务画成 DAG,挑出必须按顺序执行的强依赖路径,弱依赖的环节合并或并行;
- 定契约:为每个阶段定义输入 schema、输出 schema 与”完成判定条件”,契约清晰才能独立替换;
- 选 Agent:每阶段一个 Agent,系统提示只描述本阶段职责,避免一个 Agent 兼顾多职;
- 接观测:用 Langfuse / OpenTelemetry 把每次跨阶段调用打成一个 span,失败能定位到具体阶段。
第 4 步经常被跳过,但恰恰是流水线出问题时唯一能快速定位的手段。
四、并行群智模式:多视角对抗的代价与收益
并行群智(Swarm / Multi-Agent Debate)的核心思想是:让多个 Agent 独立或半独立地处理同一任务,再通过投票、辩论或评分聚合结论。它适合两类场景——评审类(代码评审、文本质量评估)和对抗类(提议 + 批评循环)。Multi-Agent Debate 的研究显示,在推理与事实性任务上多 Agent 投票明显优于单 Agent;但 FREE-MAD 进一步发现,完全无共识的”评分决策”在单轮内就能反超多轮共识,关键是不要把 Agent 锁死在”必须达成一致”的循环里。
群智的代价非常高:每个 Agent 都吃独立 token,MetaGPT 实测 token 重复率约 72%,CAMEL 约 86%,AgentVerse 约 53%——这是行业公开的观察数据。生产里如果用 5 个 Agent 做群智,实际成本接近单 Agent 的 5 倍,而质量提升往往只有两位数百分比。结论是:群智是”问题足够难、视角确实不同”的场景才值得上,而不是”Agent 多就显得高大上”。
五、动态交接模式:控制权转移的边界设计
动态交接(Handoff / Agent Transfer)来自 OpenAI Swarm 与 Google ADK Agent Transfer。它把”调用子 Agent”拆成两类——Agent as Tool(root Agent 把子 Agent 当函数调用,子 Agent 拿不到历史)与 Agent Transfer(控制权完全移交,子 Agent 继承 session 视图)。前者适合”主流程稳定、子任务封闭”的场景,后者适合”用户意图多变、需要切换专家域”的场景,比如多业务线客服。
设计这一范式时,核心在于边界协议:子 Agent 拿到上下文后能干什么、不能干什么、结束后回到哪个根 Agent,这些规则必须显式写在 system prompt 或工具描述里;否则容易出现”子 Agent 改了根 Agent 的状态””子 Agent 之间互相循环交接”的事故。OpenAI Agents SDK 提供了 handoff 抽象,把交接动作收编成一个结构化原语;Google ADK 的 Agent Transfer 配套 include_contents 参数,用来控制子 Agent 看到多少父上下文。
六、选型对比与落地路径
把 4 类范式放一起,可以提炼出一张决策表:
| 决策维度 | 主管—专家 | 流水线 | 并行群智 | 动态交接 |
|---|---|---|---|---|
| 任务可拆性 | 中—高 | 高 | 中 | 低—中 |
| 审计与合规要求 | 高 | 中 | 低 | 中 |
| 并行收益 | 中 | 低 | 高 | 低 |
| 调试难度 | 中 | 低 | 高 | 中 |
| 成本控制 | 中 | 高 | 低 | 中 |
落地建议按这个顺序推进:
- 画流程:把业务画成流程图,标出强依赖、弱依赖、回环点;
- 选范式:线性 → 流水线;有清晰树形 → 主管—专家;需要多视角 → 群智;意图多变 → 动态交接;
- 跑小流量:用 50~100 条真实样本验证链路,盯 token、时延、错误率 3 个指标;
- 加观测:多 Agent 的 trace 必须能跨 Agent 串起来,否则事后定位等于盲人摸象;
- 设硬预算:max turns、max tokens、max calls 必须写进编排器,避免 Agent 跑飞。
到这里,4 大编排范式的边界、代价与选型路径就完整了。下一步要做的,不是选”看起来强大”的那一个,而是按任务拓扑把骨架搭对——这是多 Agent 系统能不能从 demo 走到生产的分水岭。
常见问题(FAQ)
Q1：4 种范式能不能混用？
能。主管—专家的专家节点本身可以是流水线,流水线之间也可以用动态交接切换。
Q2：主管—专家的主管 Agent 怎么避免变瓶颈？
分层降本是关键,主管用大模型,专家用小模型或本地模型,降低主管的 token 占比。
Q3：群智模式为什么容易烧 token？
每个 Agent 独立吃 token,5 个 Agent 成本接近单 Agent 的 5 倍,质量提升往往只有两位数。
