LangGraph 实现多 Agent 开发主要有5 种主流模式

Logintern09

383人浏览 · 2026-08-09 22:22:35

Logintern09 · 2026-08-09 22:22:35 发布

LangGraph 实现多 Agent 开发主要有 5 种主流模式，每种模式对应不同的协作拓扑和适用场景。

Supervisor 模式（主管模式）—— 最常用

一个"主管"Agent 负责决策调度，多个"专家"Agent 各司其职，所有通信都经过主管。

        Supervisor（主管）
       ↙    ↓    ↘
  Agent A  Agent B  Agent C
       ↖    ↑    ↙
        结果回传主管

核心机制：Supervisor 是一个 LLM 调用，通过 llm.bind_tools 输出结构化的路由决策，决定下一步调用哪个 Agent；子 Agent 完成后 Command(goto="supervisor") 回到主管，主管再决定是继续分发还是输出最终结果。

适用场景：客服系统、研究助手、内容生成管道等需要集中调度的场景。

优缺点：控制逻辑集中、易于理解和维护；但 Supervisor 是单点瓶颈，决策质量依赖 Prompt 质量，可能产生路由幻觉。

Swarm 模式（群组/移交模式）

没有中央管理者，Agent 之间平等，通过 Handoff（移交） 传递控制权。类似客服转接——“这个问题我处理不了，转给技术部门”。

Agent A ──handoff──▶ Agent B ──handoff──▶ Agent C
  ▲                                           │
  └──────────── handoff ──────────────────────┘

核心机制：每个 Agent 自己决定是否需要 handoff 以及交给谁，底层通过 Command(goto="target_agent", graph=Command.PARENT) 实现转移，对话历史随 handoff 传递，接手的 Agent 能看到完整上下文。

适用场景：流程灵活、Agent 之间需要动态协作的场景，如多步骤工作流（规划 → 预订 → 确认 → 客服）。

优缺点：去中心化、可扩展性强，Agent 可热插拔；但协调复杂，缺乏收敛机制时可能产生消息风暴或无限循环。

Handoffs 模式（接力模式）

多个 Agent 按顺序依次处理同一个任务，每个 Agent 完成自己的步骤后显式"交接"给下一个 Agent。

搜索Agent → 抽取Agent → 综合Agent → 生成Agent

核心机制：通过 interrupt 节点与 Command(resume=...) 机制实现，每个 Agent 更新状态中的 next_agent 字段，通过条件边进入下一个节点。

适用场景：多跳问答（搜索 → 抽取 → 综合 → 生成）、渐进式内容审核（初审 → 复审 → 终审）、带人工介入的自动化流程。

Hierarchical 模式（层级嵌套模式）

多层 Supervisor 嵌套，形成类似企业组织架构的层级结构。每一层只关心自己的下属，不需要了解全局。

          总监 Agent
        ↙          ↘
   研究主管        执行主管
   ↙  ↓  ↘        ↙  ↓  ↘
 搜索  分析  编码  测试  部署  监控

核心机制：用 LangGraph 的 Subgraph（子图） 实现——每个"主管+下属"是一个独立的子图，父图只看到子图的输入/输出接口，内部实现对父图透明。

适用场景：大规模 Agent 系统（10+ 个 Agent）、企业级多部门协作、需要权限隔离的场景。

Map-Reduce 模式（并行分发模式）

将一个大任务拆分为多个独立子任务，并行执行后汇总结果。这正是你之前问的并发执行最典型的应用。

     分发器（Map）
   ↙    ↓    ↘
 子任务  子任务  子任务  ← 并行执行
   ↖    ↑    ↙
     汇总器（Reduce）

核心机制：通过 Send() API 实现动态并行——运行时决定生成多少个并行分支，汇总器等待所有分支完成后才执行，每个分支独立 checkpoint，单个失败不影响其他分支。

适用场景：批量文档处理、多源信息采集、并行研究多个子主题。

模式选择决策指南

维度	Supervisor	Swarm	Handoffs	Hierarchical	Map-Reduce
控制方式	中央集中	分布式	顺序接力	多层嵌套	并行分发
适用规模	5-10 个 Agent	3-5 个 Agent	流程明确的串行	10+ 个 Agent	动态数量
灵活性	中	高	低	高	中
可维护性	高	低	高	高	中

快速决策：

你的任务需要多个 Agent 吗？
├── 否 → 单 Agent + 多工具就够了
└── 是 → Agent 之间有层级关系吗？
    ├── 有明确的"老板" → Supervisor 模式
    │   └── 需要多层管理？ → Hierarchical 模式
    ├── 平等协作，按专长转接 → Swarm 模式
    ├── 流程有明确阶段顺序 → Handoffs 模式
    └── 同一任务可拆分为独立子任务 → Map-Reduce 模式

实际项目中，这些模式往往混合使用——比如外层用 Supervisor 做全局调度，内部某个分支用 Map-Reduce 做并行处理，再用 Subgraph 封装成子图嵌入主图。理解每种模式的特点后，就可以像搭积木一样灵活组合。

需要我针对其中某种模式写一个完整的代码示例吗？