大模型应用开发实战（13）——多 Agent 真的有必要吗？LangGraph 背后的分工逻辑拆解
🤵♂️ 个人主页：小李同学_LSH的主页
✍🏻 作者简介：LLM学习者
🐋 希望大家多多支持，我们一起进步！😄
如果文章对你有帮助的话，
欢迎评论 💬点赞👍🏻 收藏 📂加关注+
目录
一、先给结论：多 Agent 不是“更高级”，而是“更适合某些任务结构”
二、为什么很多“看起来该上多 Agent”的系统，其实单 Agent 就够了
一个很实用的判断标准
三、那什么时候多 Agent 真有价值？
典型值得上多 Agent 的场景
1. 深度研究 / 情报整合
2. 复杂开发代理
3. 企业流程自动化
四、LangGraph 为什么特别适合讲“分工逻辑”？
为什么这很重要？
多 Agent 真正有效的前提
六、LangGraph 里的两种经典分工逻辑：Supervisor 和 Subgraph
1. Supervisor 模式
2. Subgraph 模式
七、OpenAI 视角下的多 Agent：handoff 和 agents-as-tools
用 handoff 的场景
用 agents-as-tools 的场景
这两年，一提到 Agent，很多人下意识就会往“多 Agent 协作”上想：
一个规划、一个检索、一个写代码、一个审查、一个总结，最后像一个小团队一样把任务做完。
听起来很高级，但真正做项目时，最先遇到的问题往往不是“怎么把 Agent 拆得更多”，而是：
这个任务真的需要多 Agent 吗？
LangChain 官方文档其实已经把这个问题说得很直白：多 Agent 模式特别适合单个 Agent 拥有太多工具、容易做出糟糕工具选择，或者任务需要不同专业能力和严格顺序约束的时候
而 Anthropic 的工程实践也强调，很多场景应该先从更简单、可组合的 workflow 开始，而不是一上来就堆出复杂的 agent 系统。
LangGraph 官方则把自己定位为一个构建长运行、状态化 Agent 和 Workflow 的低层编排框架，重点在“编排”和“状态”，而不是替你决定必须上单 Agent 还是多 Agent。
所以这篇文章只回答一个问题：
多 Agent 到底什么时候值得上？LangGraph 背后的分工逻辑又是什么？
一、先给结论：多 Agent 不是“更高级”，而是“更适合某些任务结构”
如果一句话总结：
- 单 Agent更适合中小复杂度、工具数不多、上下文可以统一管理的任务。
- 多 Agent更适合任务天然可以分工、上下文容易互相污染、工具太多、或不同步骤需要完全不同能力边界的任务。
换句话说，多 Agent 不是为了“看起来更智能”，而是为了处理下面这些结构性问题：
- 一个 Agent 工具太多，容易乱选
- 一个 Agent 上下文太杂，容易思维漂移
- 不同步骤需要不同角色、不同提示词、不同权限
- 任务本身就是天然可拆的多阶段流程
二、为什么很多“看起来该上多 Agent”的系统，其实单 Agent 就够了
这是第一个必须讲清楚的地方。
Anthropic 在《Building Effective AI Agents》里把workflow和agent明确区分开了：
- workflow：预定义代码路径，按既定顺序执行
- agent：模型动态决定过程和工具使用方式
而他们的工程建议是：先从最简单可行的模式出发，只有在确实需要灵活决策时，再增加 agentic 能力。
这意味着，很多看起来“像多 Agent”的东西，其实更适合写成：
- 固定顺序 workflow
- 路由 + 子流程
- 主 Agent + 工具
- 单 Agent + 明确状态机
而不是一上来就拆成好几个会对话、会推理、会互相交接的独立代理。(anthropic.com, )
一个很实用的判断标准
如果你的任务满足下面三条，大概率先别上多 Agent：
- 流程顺序基本固定
- 每一步职责很明确
- 不需要多角色长期维持不同上下文
这种任务更适合写成workflow或单 Agent + 工具链，而不是多 Agent。LangGraph 官方的“Workflows and agents”文档也强调了：workflow 是预定义代码路径，agent 是动态过程。
三、那什么时候多 Agent 真有价值？
LangChain 官方对多 Agent 的价值给出了三个非常实用的信号：
- 单个 Agent 有太多工具，导致工具选择质量下降
- 任务需要不同专业能力，并且这些能力各自需要大量上下文或专门工具
- 你需要明确的顺序约束，某些能力只有在前置条件满足后才能解锁。
这三条其实已经很接近真实工程。
典型值得上多 Agent 的场景
1. 深度研究 / 情报整合
例如：
- 一个代理负责检索资料
- 一个代理负责筛选和去重
- 一个代理负责总结
- 一个代理负责引用核验
这类任务天然有“分工协作”属性，而且每个角色需要的上下文和工具差异很大。OpenAI 的一些多 Agent 编排文档也把 research workflow 当作典型案例。
2. 复杂开发代理
例如：
- 代码探索代理
- 规划代理
- 实现代理
- 测试/审查代理
这类模式和 Claude Code 里的 subagents 思路其实很像：通过角色分工减少上下文污染，提高每个代理的专注度。(docs.langchain.com, )
3. 企业流程自动化
例如：
- 客服代理负责理解问题
- 退款代理处理退款规则
- 工单代理对接内部系统
- 汇总代理输出最终用户回复
这种系统如果硬塞给单 Agent，很容易把工具、规则、权限和上下文搅成一锅粥。OpenAI Agents SDK 文档里也明确区分了handoffs和agents as tools两种多 Agent 编排方式。
| 任务类型 | 为什么适合多 Agent | 单 Agent 的常见问题 |
|---|---|---|
| 深度研究 | 检索、筛选、总结、核验天然可拆 | 上下文过长，步骤容易混 |
| 复杂编程代理 | 探索、规划、实现、审查职责不同 | 一个代理既要读代码又要改代码又要验收，容易乱 |
| 企业流程自动化 | 各步骤对应不同规则和系统 | 权限、工具、提示词全塞一起 |
| 长链路知识工作 | 每一步都需要不同上下文 | 主会话上下文污染严重 |
四、LangGraph 为什么特别适合讲“分工逻辑”？
因为 LangGraph 的核心不是“帮你造一个现成 Agent”，而是把 Agent 工作流显式建模成一个图。
官方 Graph API 文档写得很清楚：LangGraph 的核心组件是：
- State：共享状态
- Nodes：执行逻辑的节点
- Edges：决定下一步去哪个节点的边
这和一般“把几个 Agent 互相 call 来 call 去”的方式不一样。
LangGraph 的优势恰恰在于：它把分工逻辑、状态流转和控制路径显式化了。
为什么这很重要？
因为多 Agent 一旦复杂起来，真正难的就不是“有没有第二个 Agent”，而是：
- 谁看什么上下文
- 哪一步之后交接
- 中间状态怎么保存
- 出错后回到哪里
- 哪个代理对最终答案负责
而这些，正是 LangGraph 这种“图式编排”最擅长处理的问题。
多 Agent 设计的核心在于 context engineering——决定每个代理看到什么信息。
因为很多系统拆了多个 Agent，却依然失败，原因不是拆得不够多，而是：
- 每个代理看到的信息几乎一样
- 每个代理拿到的工具也几乎一样
- 每个代理都在重复做相似思考
- 没有真正做到上下文隔离
于是系统表面上是多 Agent，实际上只是“同一个 Agent 换了几个名字”。
多 Agent 真正有效的前提
多 Agent 只有在下面这些条件成立时才会明显变强：
- 不同代理看到不同信息
- 不同代理拿不同工具
- 不同代理有不同职责
- 交接规则清晰
- 主状态可追踪
所以从工程角度看，多 Agent 的关键不是数量，而是：
六、LangGraph 里的两种经典分工逻辑：Supervisor 和 Subgraph
在 LangChain / LangGraph 体系里，和多 Agent 最相关的两类模式特别值得记住。
1. Supervisor 模式
官方“Build a personal assistant with subagents”教程明确写到：supervisor pattern 是一种多 Agent 架构，由中心 supervisor 协调多个专门 worker agents。这种模式特别适合不同步骤需要不同专业能力的任务。
它的特点是：
- 有一个中心代理保持全局视角
- 专门代理各自处理窄任务
- 交接逻辑集中化
2. Subgraph 模式
LangGraph 官方文档把subgraph定义成“一个图作为另一个图里的节点”。这特别适合把复杂流程模块化，比如把“研究流程”“审批流程”“报告生成流程”都封装成可复用子图。
它的特点是：
- 更适合模块化复用
- 更适合把复杂流程封装成一个黑盒节点
- 不一定每个子图都必须是“独立人格 Agent”
这也是为什么“多 Agent”不一定总是“多个聊天人格互相对话”，也可以是多个子图 / 多个专门节点的协作。
| 模式 | 更像什么 | 适合什么场景 | 关键特点 |
|---|---|---|---|
| Router | 分类分流器 | 一步判断后分派 | 简单、快、状态弱 |
| Supervisor | 主管调度 | 多轮协作、多角色任务 | 中心化协调、上下文强 |
| Subgraph | 子流程模块 | 复杂流程复用 | 模块化、结构清晰 |
其中 Router 和 Supervisor 的区别，LangChain 文档也专门强调过：supervisor 是完整 agent，会跨多轮维持上下文并决定调用哪个 subagent；router 通常只是一次分类分发。
七、OpenAI 视角下的多 Agent：handoff 和 agents-as-tools
OpenAI Agents SDK 的编排文档也给了一个非常值得借鉴的判断框架：
- handoffs：某个分支任务应该由专门代理接管后续对话
- agents as tools：主代理保持控制权，把别的代理当成受限能力来调用。
这个区分非常适合你理解“多 Agent 是否真的有必要”。
用 handoff 的场景
当某个专门代理需要“拥有后续会话”，比如：
- 退款代理接管退款流程
- 安全审查代理接管安全检查
- 深度研究代理接管研究过程
用 agents-as-tools 的场景
当主代理仍然应该负责最终输出，只是临时调用专家能力，比如：
- 摘要代理
- SQL 代理
- 翻译代理
- 校验代理
这说明多 Agent 编排并不是只有一种“大家平等聊天协作”的形态，而是至少有两种经典分工逻辑：
多 Agent 的真正价值，不是“多几个脑子”，而是“把不同脑子放到最该出现的位置”。