多智能体不是把多个大模型调用堆在一起。用 LangGraph 的图状态机把任务拆成节点、共享状态、条件路由，多 Agent 才能在线上稳定协作。下面用一组内部基准数据讲清 4 种架构模式怎么选、3 类常见故障怎么排查。
本文要点
- StateGraph 把任务变成节点 + 边 + 共享状态
- 四种模式：顺序管道、监督者、平等协商、分层委托
- 实测：4 个专职智能体完成率 67% → 94%，P50 2.3s
- 三类故障：消息丢失、Token 超限、死循环
- 上线前必做：LangSmith tracing + 优雅降级
为什么值得上多智能体？LangChain 官方在 《Multi-Agent Workflows》 中给出的判断是：职责拆开后，每个智能体的工具集更小、提示词更聚焦，单个子任务的成功率更高，整体链路才更稳；每个子任务还能独立评估、独立调优。这套思路落到图编排框架上，就是「一个节点一段逻辑、边决定控制流、共享状态负责通信」。
LangGraph 的 StateGraph、条件边和状态合并是怎么配合的？
结论：把任务画成节点 + 边 + 共享状态的有向图；StateGraph 提供 reducers 合并状态更新、条件边按当前状态选择下一节点、checkpointer 把每一步落盘。
官方把它定位为「面向可靠 AI Agent 的编排框架」，执行模型借鉴了 Google Pregel 的图计算思路：可并行的节点在同一超步内执行，再统一把结果写回状态。节点是任一段逻辑——一次模型调用、一个工具、一个子任务；边决定执行顺序；状态是节点之间传递信息的唯一通道。三个容易踩坑的细节：
- reducers 合并：同一个 key 被多个节点写入时，必须声明合并策略，比如 messages 用 append 而不是覆盖，否则后写覆盖先写。
- 条件边：返回一个路由目标，比如监督者根据子节点输出决定下一步交给谁；这是多智能体「动态决策」的基础。
- recursion limit：官方文档建议显式设置递归上限，否则含循环的图在异常条件下可能无限执行。
具体 API 细节以 Graph API 官方文档 为准。
4 种多智能体架构模式怎么选？
结论：步骤固定选顺序管道；需要主控分派选监督者（Supervisor）；对等协作选平等协商；组织层级复杂选分层委托。没有银弹，按控制复杂度和延迟预算选。
结合官方示例与 2026 年社区实践，常见形态有四类：
| 模式 | 典型场景 | 控制复杂度 | 延迟代价 |
|---|---|---|---|
| 顺序管道 | 质检 → 清洗 → 生成的固定流水线 | 低 | 低 |
| 监督者（Supervisor） | 有明确调度者、任务可分派 | 中 | 中 |
| 平等协商（Network / Swarm） | 对等协作、成员可动态插拔 | 高 | 高 |
| 分层委托（Hierarchical） | 大团队、多级分工 | 高 | 高 |
顺序管道最简单：前一个节点的输出是后一个节点的输入，状态只在相邻节点间传递，适合流水线任务。监督者由一个中央协调节点决定「下一步交给谁」，子节点干完活把结果写回共享状态；这是生产项目里最常见的形态，2026 年的社区教程也把它列为多智能体入门首选。平等协商没有中心节点，多个对等节点互相移交（handoff），灵活但控制流难追踪。分层委托顶层协调节点管中层、中层再管底层执行，适合大团队，但延迟与 Token 会随层级叠加。
一个用监督者模式编排搜索、代码生成、数据分析三类任务的实战案例，见站内《多智能体开发实战：用 LangGraph 编排搜索+代码生成+数据分析》。
4 个专职智能体比 1 个慢一倍，还值得吗？
结论：值不值看成功率。优码云一组内部基准：同一任务集下，单个全能智能体完成率 67%，换成 4 个专职智能体后完成率 94%，代价是 P50 延迟从 1.1s 升到 2.3s。
慢约一倍，完成率提升 27 个百分点——对自动化率要求高的场景这笔账划算；但如果任务本来就简单、失败一次的成本很低，单智能体 + 重试更省钱。多智能体的真实成本是三层叠加：延迟、Token 消耗、状态管理复杂度。上多智能体前先算三笔账：任务能否拆成可独立验证的子任务？失败一次的成本有多高？SLA 允许多慢？三条都过，再拆。
多智能体上线后最常见的 3 类故障怎么排查？
结论：消息丢失查 reducer 与状态写入；Token 超限做消息裁剪；死循环设 recursion limit 并留熔断出口。
- 消息丢失：子节点的返回没有写进共享状态，或写到了错误的 key。用 LangSmith 对比每个超步前后的状态差异，确认节点 return 的字段名与 reducer 一致。
- 状态膨胀 / Token 超限：共享 messages 默认是 append 式累积，长会话会越滚越大。解法：裁剪历史消息、让子节点只回传结构化摘要、给循环设最大步数。
- 死循环：条件边把流程送回同一个节点。设置 recursion limit、全局超时，并在条件边上显式留一个「已达最大迭代次数」的出口。
上生产前的部署 Checklist
结论：至少做四件事：全链路 tracing、checkpointer 持久化、失败降级、超时与限流。
- LangSmith tracing：每个节点、每次模型调用、每步状态变化都可回放，是排障的第一手段。
- Checkpointer 持久化：状态落库后支持断点续跑与人工介入（human-in-the-loop），审核完再继续。
- 优雅降级：某个子智能体连续失败时降级为单智能体直接回答，或返回明确兜底文案，别让整条链路崩掉。
- 超时 / 重试 / 限流：每个节点设超时，外部 API 加重试与退避，防止雪崩。
优码云在给客户做 AI Agent 项目时，通常建议从监督者模式起步、先把 tracing 和降级做好再扩规模；从传统团队过渡到多智能体协作的路径，可参考《企业 AI 应用开发：90 天从传统团队到 AICoding 协同转型路线》。
常见问题
LangGraph 和 LangChain 是什么关系？
LangChain 是通用框架，图编排运行时负责状态、循环、条件分支和多智能体编排，二者均开源；它的定位是低层控制，官方对它的描述是「面向可靠场景的编排框架」。
什么时候不应该用多智能体？
任务线性、步骤少、失败成本低时，单智能体 + 重试通常更省。多智能体只在任务可拆、且拆分后收益能通过评测集验证时有意义。
多智能体是不是一定更贵？
不一定，但通常更高：多轮路由会放大 Token 消耗与延迟。先在评测集上对比单个智能体与多个智能体的完成率与成本，再决定值不值。
共享状态会不会越滚越大？
会。默认 messages 是 append 式累积，生产环境必须配消息裁剪或摘要压缩，否则长会话必然超限。