多智能体协作范式对比：Supervisor、Swarm 与 Graph

当单个 Agent 无法应对复杂任务时，多智能体（Multi-Agent）协作就成为必然选择。但"多 Agent"本身并不等于"更强大"——选择错误的协作范式往往比单 Agent 表现更差、成本更高、可维护性更糟。本文从工程实战出发，系统对比三种主流多 Agent 协作范式：Supervisor（监督者）、Swarm（群体）、Graph（图），给出可落地的选型决策和实现模板。

为什么需要多智能体

单个 LLM Agent 在三类任务上会力不从心：

第一，需要深度专业分工的任务。一个"研究 + 写代码 + 写文档"的复合任务，让一个 Agent 同时处理三个领域，每个领域都会做得平庸。多 Agent 模式让"研究员 Agent""程序员 Agent""技术写作 Agent"各司其职，每个 Agent 在自己的子任务上达到最优。

第二，状态空间爆炸的任务。当 Agent 需要在多个工具、多个数据源、多个步骤间反复切换时，上下文会迅速膨胀。拆分成多 Agent 后，每个 Agent 维护自己的状态空间，主 Agent 只传递"摘要 + 决策"。

第三，需要审计和权限边界的任务。在企业场景中，"数据查询 Agent"和"操作执行 Agent"应该由不同身份、不同权限、不同审计链路完成。多 Agent 模式天然支持这种隔离。

但多 Agent 也有显著代价：额外的协调开销、调试复杂度、token 成本。在引入前必须明确收益大于成本。

范式 1：Supervisor（监督者模式）

Supervisor 模式是最经典的多 Agent 架构：有一个"总指挥" Agent 负责任务拆解、子 Agent 调度、结果聚合。子 Agent 各自独立，只向 Supervisor 汇报。

Supervisor 通过一个状态机和 LLM 决策函数决定下一步派给谁，以下是基于 LangGraph 的核心实现骨架：

from langgraph.graph import StateGraph, END
from typing_extensions import TypedDict
from langchain_core.messages import BaseMessage, AIMessage, SystemMessage

class SupervisorState(TypedDict):
    messages: list[BaseMessage]
    next_agent: str
    final_answer: str | None

def supervisor_router(state: SupervisorState) -> str:
    response = supervisor_llm.invoke([
        SystemMessage(content=(
            "You are a supervisor managing three agents: "
            "researcher (web search), coder (code execution), writer (technical writing). "
            "Reply with one of: researcher, coder, writer, FINISH."
        )),
        *state["messages"]
    ])
    decision = response.content.strip()
    if decision == "FINISH":
        return END
    return decision

def researcher_node(state: SupervisorState):
    result = researcher_agent.invoke(state["messages"])
    state["messages"].append(AIMessage(content=f"[Researcher] {result}"))
    return state

def coder_node(state: SupervisorState):
    result = coder_agent.invoke(state["messages"])
    state["messages"].append(AIMessage(content=f"[Coder] {result}"))
    return state

def writer_node(state: SupervisorState):
    result = writer_agent.invoke(state["messages"])
    state["messages"].append(AIMessage(content=f"[Writer] {result}"))
    return state

workflow = StateGraph(SupervisorState)
workflow.add_node("supervisor", supervisor_router)
workflow.add_node("researcher", researcher_node)
workflow.add_node("coder", coder_node)
workflow.add_node("writer", writer_node)

workflow.add_conditional_edges(
    "supervisor",
    lambda state: state["next_agent"],
    {"researcher": "researcher", "coder": "coder", "writer": "writer", END: END}
)
for n in ["researcher", "coder", "writer"]:
    workflow.add_edge(n, "supervisor")
workflow.set_entry_point("supervisor")
app = workflow.compile()

Supervisor 模式的优势：

• 中心化决策：所有调度逻辑在一个节点，便于审计
• 易于理解：传统"主-从"模式，符合大多数人的心智模型
• 可观测性好：所有对话都经过 Supervisor，trace 清晰
• 状态管理简单：全局状态单一，避免子 Agent 状态不一致

Supervisor 模式的痛点：

• Supervisor 是单点瓶颈：所有决策都通过 LLM 调度，延迟和成本叠加
• 上下文膨胀：Supervisor 需要保留所有子 Agent 的对话历史
• 错误传播：Supervisor 一次错误的派工，会让整个任务走偏
• 难以扩展：每加一个 sub-agent，Supervisor 的 prompt 就需要重写

适合场景：

• 任务结构相对清晰，子任务边界明确
• 需要强审计链路（金融、医疗、政务）
• 调试和可观测性优先

范式 2：Swarm（群体模式）

Swarm 模式是 OpenAI 在 2024 年提出的轻量级多 Agent 范式：取消 Supervisor，Agent 之间直接 Handoff。每个 Agent 决定是否"传递"任务给另一个 Agent。

from openai_agents import Agent, handoff

triage_agent = Agent(
    name="Triage Agent",
    instructions=(
        "You are the entry point. Based on the user's request, "
        "either answer directly or hand off to the appropriate specialist. "
        "Use handoff() when the request requires specialized handling."
    ),
    handoffs=[
        handoff(billing_agent, condition="When user asks about billing, invoices, or refunds"),
        handoff(tech_support_agent, condition="When user reports a technical issue or asks how-to questions"),
        handoff(sales_agent, condition="When user wants to upgrade, purchase, or learn about pricing"),
    ]
)

Swarm 模式的核心机制：

• 每个 Agent 自己决定是否交接（基于 prompt 中的"交接条件"）
• 交接时传递完整对话历史
• 没有中央协调者，Agent 之间形成有向图

Swarm 模式的优势：

• 低延迟：没有 Supervisor 调度开销
• 自然分工：每个 Agent 决定自己"不擅长"什么
• 易于扩展：加新 Agent 只需在目标 Agent 的 handoffs 列表里添加
• 实现简单：几十行代码就能跑起来

Swarm 模式的痛点：

• 缺乏全局视角：没有"总指挥"知道整体任务进度
• 容易陷入循环：Agent A 交接给 B，B 又交接回 A
• 调试困难：决策分散在多个 Agent 中，trace 不直观
• 状态不一致：每个 Agent 维护自己的上下文，跨 Agent 状态合并复杂

适合场景：

• 客服分流（triage → 多个专家）
• 任务粒度均匀、Agent 之间无强依赖
• 简单任务，需要快速搭建原型

范式 3：Graph（图模式）

Graph 模式是 LangGraph 等框架提出的"状态机式"多 Agent 架构：把整个系统建模为有向图，节点是 Agent 或函数，边是条件路由。和 Supervisor 模式不同，Graph 不需要中心化的"决策者"，路由规则可以由代码、prompt 或 learned model 共同决定。

from langgraph.graph import StateGraph, END
from typing_extensions import TypedDict

class ResearchState(TypedDict):
    query: str
    research_result: str | None
    verified_facts: list[str]
    code: str | None
    test_results: dict | None
    final_summary: str | None

def research_node(state: ResearchState):
    return {"research_result": research_agent.invoke(state["query"])}

def verify_node(state: ResearchState):
    return {"verified_facts": fact_checker_agent.invoke(state["research_result"])}

def should_retry_research(state: ResearchState) -> str:
    return "research" if len(state["verified_facts"]) < 3 else "code"

def code_node(state: ResearchState):
    return {"code": coder_agent.invoke(state["verified_facts"])}

def test_node(state: ResearchState):
    return {"test_results": test_runner.run(state["code"])}

def should_fix_code(state: ResearchState) -> str:
    return "code" if state["test_results"]["failed"] > 0 else "summarize"

def summarize_node(state: ResearchState):
    return {"final_summary": writer_agent.invoke({
        "research": state["research_result"],
        "code": state["code"],
        "tests": state["test_results"],
    })}

workflow = StateGraph(ResearchState)
workflow.add_node("research", research_node)
workflow.add_node("verify", verify_node)
workflow.add_node("code", code_node)
workflow.add_node("test", test_node)
workflow.add_node("summarize", summarize_node)

workflow.set_entry_point("research")
workflow.add_edge("research", "verify")
workflow.add_conditional_edges("verify", should_retry_research, {"research": "research", "code": "code"})
workflow.add_edge("code", "test")
workflow.add_conditional_edges("test", should_fix_code, {"code": "code", "summarize": "summarize"})
workflow.add_edge("summarize", END)

app = workflow.compile()

Graph 模式的优势：

• 强表达力：支持条件路由、循环、并行、超时等复杂控制流
• 确定性高：路由规则由代码控制，行为可预测
• 可观测性极佳：图的执行就是 trace，每个节点的输入输出都明确
• 天然支持人机协作：可以在任意节点插入 human-in-the-loop
• 支持持久化：图状态可序列化，支持断点续传

Graph 模式的痛点：

• 实现复杂：需要设计状态 schema、节点、路由
• 前期设计成本高：图的形状需要预先规划
• 灵活度低：固定路径的图难以应对"完全没见过"的任务
• 学习曲线陡：需要理解状态机、有向图等概念

适合场景：

• 流程明确、有清晰阶段划分的任务
• 需要 human-in-the-loop
• 复杂业务逻辑（合规、审批流）
• 长期维护的生产系统

三种范式对比

维度	Supervisor	Swarm	Graph
决策中心化	中心（Supervisor）	去中心（每个 Agent 自决）	中心 + 条件路由
实现复杂度	中	低	高
调试难度	中（trace 清晰）	高（决策分散）	低（图本身就是 trace）
扩展性	中（Supervisor 需改 prompt）	高（加 handoff 即可）	中（需改图结构）
适合任务	结构化、强审计	简单分流、客服	复杂流程、生产系统
上下文管理	单一全局	每 Agent 独立	显式状态 schema
循环风险	低	高（Agent 间死锁）	极低（代码控制）
典型框架	LangGraph、CrewAI、Agno	OpenAI Swarm、Agno Swarm	LangGraph、Agno

实战建议

从 Supervisor 开始。如果你的多 Agent 任务不超过 5 个子 Agent，Supervisor 模式是最容易理解、最容易调试的起点。即使后期发现 Supervisor 成为瓶颈，迁移到 Graph 模式也比直接上 Graph 简单。

Swarm 适合"分流型"场景。如果你的多 Agent 本质上是一个 triage + 几个 specialist 的模式（客服、工单分发、lead routing），Swarm 模式比 Supervisor 更轻量。但不要在 Swarm 中加入"任务进度跟踪"逻辑——这会破坏 Swarm 的"无中心"优势。

复杂流程必用 Graph。当你的任务包含循环（生成-验证-重试）、并行（多研究员同时调研）、条件分支（根据中间结果选择下一步）时，Graph 是唯一能优雅表达的范式。Graph 模式是"可维护的多 Agent 系统的终极形态"。

混合使用。现代多 Agent 框架（LangGraph、Agno）允许在 Graph 节点内部嵌入 Supervisor 或 Swarm 子图，发挥各自优势。例如：顶层 Graph 控制整体流程（研究 → 实现 → 测试），单个"实现"节点内部是 Supervisor 调度多个子 Agent。

实施清单

定义任务边界：

• 拆解成 ≤ 5 个子任务的，Supervisor 足够
• 拆解成 5-20 个子任务、需要循环/分支的，Graph
• 简单的"分流+专家"模式，Swarm

选择框架：

• LangGraph：Graph 模式首选，LangChain 生态
• CrewAI：角色扮演式 Supervisor，简化角色定义
• Agno：轻量级，多范式支持
• OpenAI Swarm：教学性质的 Swarm 框架

关键设计：

• 给每个 Agent 明确的"边界"——什么该它做、什么不该它做
• 维护清晰的"交接协议"——交接时传递什么状态、什么历史
• 设计"回退路径"——Agent 失败时如何降级
• 限制上下文窗口——长会话必须压缩或截断
• 监控每个 Agent 的 token 消耗——某个 Agent 失控是常见故障

总结

多 Agent 协作不是"越多越好"，而是"在合适的任务上用合适的范式"。Supervisor 适合结构化任务，Swarm 适合分流场景，Graph 适合复杂生产系统。三者不是互斥的，可以在 Graph 中嵌入 Supervisor 子图，发挥各自优势。

选错范式的代价远高于"先用单 Agent"——先评估单 Agent 是否真的不够，再选择最简的多 Agent 范式。

参考框架：CrewAI（角色扮演式多 Agent）、AG2 (AutoGen)（对话式多 Agent）、LangGraph（Graph 模式的事实标准）、OpenAI Swarm（轻量级 Swarm 范式）和 Agno（多范式多 Agent 框架）覆盖了三种主要范式的工程实现。