LangGraph 深度解析：用"图"思维构建有状态的多 Agent 系统

上周有个做企业 SaaS 的朋友找我吐槽：

"我用 LangChain 搭了一个客服 Agent，Demo 效果挺好。但一上线就出问题——用户问了三句话之后，Agent 完全忘了前面说过什么。客户问'那个订单怎么样了'，它反问'您说的是哪个订单？'……"

我问他："你的 Agent 有状态管理吗？"

他愣了一下："什么叫状态管理？我不是每次都把聊天记录传进去了吗？"

"那你的 Agent 能中途暂停、等人审批、然后接着执行吗？"

"……不能。"

"能在执行到一半崩溃后，从断点恢复吗？"

"……也不能。"

"那你做的不叫 Agent，叫一个循环调用 API 的脚本。"

这不是个例。2026 年了，绝大多数人搭建的 "Agent" 依然是无状态的。它们看起来在"思考"，实际上每一步都在从零开始。就像一条只有 7 秒记忆的金鱼，永远活在当下这一刻。

LangGraph，就是 LangChain 团队给出的答案——让 Agent 拥有真正的"记忆"和"流程控制"。

但它不只是给 Agent 加了个记忆模块那么简单。它背后的设计哲学、架构选择，甚至它借鉴的那个 Google 内部系统，都值得好好聊聊。

---

为什么你的 Agent 总是"失忆"？

要理解 LangGraph 解决了什么问题，你得先明白现有方案"不够用"在哪。

最早的 LLM 应用模式很简单：用户输入 → 模型输出。一问一答，干干净净。

后来人们想让 AI 做更复杂的事，于是有了"链"（Chain）的概念——把多个步骤串起来。先搜索，再总结，最后回答。LangChain 最初就是干这个的，名字里的 "Chain" 就说明了一切。

但问题来了。

链是线性的。它就像工厂流水线——原料从一端进去，产品从另一端出来。中间不能回头，不能分叉，不能暂停。

真实世界的任务不是这样的。

想象一下你在公司处理一个客户投诉：你先查订单，发现需要退款，退款需要经理审批，经理可能批也可能驳回，驳回了你还得跟客户解释，客户不满意你可能要升级处理……这是一个有分支、有循环、有等待、有状态的过程。

用"链"能实现吗？硬编码可以，但代码会变成一坨意大利面。更要命的是——如果处理到一半服务挂了呢？从头来过？客户会疯的。

这就是 LangGraph 诞生的背景。LangChain 团队自己也意识到了："链"这个抽象太弱了，它无法表达真实世界任务的复杂性。

他们需要一个更强大的抽象。而答案，藏在一个看似与 AI 无关的领域——图计算。

Agent 的瓶颈从来不是"不够聪明"，而是"记不住"。

LangGraph 的核心思想是什么？

一句话：把 Agent 的执行流程建模成一张"图"（Graph），让状态在图中流转。

等等，"图"是什么？

你可以把它想象成地铁线路图。每个站点是一个"节点"（Node），站点之间的连接是"边"（Edge）。你从 A 站出发，可以换乘到 B 线，也可以直接坐到终点站。具体走哪条路，取决于当前的"状态"——比如你要去哪、这趟车到不到。

LangGraph 就是给 AI Agent 画了这么一张地铁图。

三个核心概念

节点（Node）——做事的人。每个节点是一个 Python 函数，负责一个具体任务：调用 LLM、执行工具、处理数据……它接收当前状态，干完活后返回更新后的状态。

边（Edge）——决定下一步去哪。边分两种：普通边（固定走向）和条件边（根据状态动态决定走向）。条件边是魔法所在——它让 Agent 能"思考"该走哪条路。

状态（State）——Agent 的"记忆"。一个贯穿整个图的共享数据结构，所有节点都能读取和更新它。它不是简单的聊天记录，而是整个任务的上下文快照。

看到关键区别了吗？

传统的 Chain 是一条直线：A → B → C → 结束。

LangGraph 是一张图：A → B →（条件判断）→ C 或 D → 可能回到 B → 最终到 E。

这意味着你的 Agent 可以循环（反复尝试直到成功）、可以分支（根据情况走不同路径）、可以并行（同时执行多个节点）。

代码长什么样？比你想象的简单：

from langgraph.graph import StateGraph, START, END

# 定义状态结构
class AgentState(TypedDict):
    messages: list
    next_action: str

# 创建图
graph = StateGraph(AgentState)

# 添加节点
graph.add_node("analyze", analyze_intent)
graph.add_node("use_tool", call_tool)
graph.add_node("respond", generate_response)

# 添加边
graph.add_edge(START, "analyze")
graph.add_conditional_edges("analyze", route_decision)
graph.add_edge("use_tool", "respond")
graph.add_edge("respond", END)

# 编译并运行
app = graph.compile()
result = app.invoke({"messages": ["查一下我的订单状态"]})

关键在第 13 行的 add_conditional_edges。route_decision 是一个普通的 Python 函数，它看一眼当前状态，然后决定下一步去哪个节点。就这么简单。

有意思的是，LangGraph 的底层架构借鉴了 Google 2010 年发表的 Pregel 论文——一个专门处理大规模图计算的系统。Pregel 的核心思想是"超步"（Superstep）：图中的节点分批执行，每一批叫一个超步，同一超步内的节点可以并行跑。

LangChain 团队把这套思想搬到了 Agent 编排领域。结果就是：你的 Agent 不再是一个"跑一次就完"的脚本，而是一个可以暂停、恢复、分支、循环的状态机。

用图来编排 Agent，就是给 AI 一张可以反复走的地图。而不是一条只能走一遍的单行道。

状态管理到底怎么玩？

如果说图结构是 LangGraph 的骨架，那状态管理就是它的灵魂。

为什么这么说？因为在实际生产中，Agent 面临的最大挑战不是"怎么调 LLM"，而是——

执行到一半，怎么办？

用户关了浏览器怎么办？服务器重启了怎么办？需要等人工审批怎么办？Agent 跑了 10 分钟还没完，中间状态存哪？

LangGraph 给出了一套完整的答案，核心机制叫 Checkpoint（检查点）。

Checkpoint：Agent 的"游戏存档"

你玩过游戏存档吧？打 Boss 前存一个档，死了可以读档重来。

LangGraph 的 Checkpoint 干的是同样的事。每执行完一个"超步"（Superstep），LangGraph 自动保存当前状态的完整快照。这个快照包括：所有节点的输出、消息历史、自定义状态字段、执行到了哪一步。

这意味着什么？

• 崩溃恢复：服务挂了？重启后从最近的 Checkpoint 继续，不用从头来
• Human-in-the-loop：执行到需要人工审批的节点，自动暂停，等人操作完再继续
• 时间旅行调试：出了 bug？回溯到任意一个 Checkpoint，查看当时的完整状态
• 分支探索：从同一个 Checkpoint 出发，尝试不同的路径

from langgraph.checkpoint.memory import MemorySaver

# 创建检查点存储
checkpointer = MemorySaver()

# 编译图时传入 checkpointer
app = graph.compile(checkpointer=checkpointer)

# 用 thread_id 标识一次对话
config = {"configurable": {"thread_id": "user-123"}}

# 第一次调用
result = app.invoke({"messages": ["帮我查订单"]}, config)

# 下一次调用自动接续上次的状态
result = app.invoke({"messages": ["就是上周买的那个"]}, config)

注意第 11 行的 thread_id。这是 LangGraph 管理会话状态的方式——同一个 thread_id 的调用共享同一条状态链。下次调用时，LangGraph 自动加载最新的 Checkpoint，Agent 就能"记住"之前发生了什么。

生产环境不用 MemorySaver（它把数据存在内存里），而是用持久化存储，比如 PostgreSQL 或 Redis。LangGraph 提供了开箱即用的存储后端。

短期记忆 vs 长期记忆

LangGraph 把 Agent 的记忆分成两层：

短期记忆（Thread-level）：一次对话内的上下文。就像你跟一个人面对面聊天，他记得你五分钟前说的话。这是通过 Checkpoint + thread_id 实现的。

长期记忆（Cross-thread）：跨对话的持久化知识。就像你的私人助理，记得你的偏好、历史决策、常用联系人。LangGraph 通过一个独立的 Store API 实现，数据按 namespace 隔离。

这两层记忆的组合，让 Agent 既能在当前对话中保持连贯，又能在多次对话间积累"经验"。

状态是 Agent 的记忆，Checkpoint 是 Agent 的存档点。没有存档的游戏，你敢玩吗？

多 Agent 协作长什么样？

一个 Agent 能做的事有限。真正有意思的，是让多个 Agent 协作。

但"多 Agent 协作"这个词被用烂了。什么才算真正的协作？

我给你讲个故事。

去年我帮一家电商公司做了个"智能客服系统"。最初的方案很朴素：一个大而全的 Agent，既能查订单、又能处理退款、还能推荐商品。结果呢？它什么都能干，但什么都干不好。查订单时经常幻觉出错误的数据，推荐商品时又忘了用户刚说要退款——情绪管理约等于零。

后来我们重新设计：拆成四个专精 Agent——订单查询、退款处理、商品推荐、情绪安抚。上面再加一个"主管 Agent"（Supervisor），负责判断当前该把任务分配给谁。

效果立竿见影。每个 Agent 的 prompt 精简到原来的 1/4，准确率提升了 40%，而且用户满意度上去了——因为当用户情绪激动时，情绪安抚 Agent 会先介入，而不是机械地回答"请问您的订单号是？"

这就是 LangGraph 擅长的领域。

三种主流协作模式

模式一：Supervisor（主管模式）

一个"主管"Agent 坐镇中央，接到任务后决定分配给哪个"下属"Agent。下属完成后把结果交回主管，主管决定下一步。

就像一个项目经理带着几个工程师。客户说"我要一个网站"，项目经理拆成前端、后端、设计三个任务，分别分配，收到结果后整合交付。

模式二：Handoff（交接模式）

没有中央主管，Agent 之间直接交接任务。A 做完了，觉得下一步该 B 来，就把状态传给 B。就像接力赛跑，棒子一个一个传。

这种模式更灵活，但也更危险——如果 Agent 判断错了该交给谁，任务就可能在几个 Agent 之间"踢皮球"。

模式三：Hierarchical（层级模式）

Supervisor 的升级版。最上面一个总监，下面几个经理，经理下面还有执行者。适合超复杂的系统。

但说实话，大多数场景用 Supervisor 就够了。

状态共享的两种哲学

多 Agent 系统还有一个关键设计决策：Agent 之间共享多少信息？

全共享：所有 Agent 能看到彼此的完整思考过程。好处是信息透明，坏处是 token 消耗大、容易互相干扰。

最小共享：每个 Agent 有自己的"草稿纸"，只把最终结果分享给其他人。好处是干净高效，坏处是可能丢失上下文。

LangGraph 两种都支持。我的建议是：Agent 数量少于 4 个用全共享，超过 4 个用最小共享。这是实践中踩出来的经验——Agent 一多，全共享的 token 成本会指数增长。

好的多 Agent 系统不是一群天才在开会，而是一个好教练带着一群专才各司其职。

跟 CrewAI、AutoGen 比，该选谁？

这是我被问得最多的问题。三个框架我都用过，直接给你我的判断。

先打个比方。

CrewAI 是宜家家具。说明书清晰，零件齐全，按步骤组装就行。你不需要懂木工，30 分钟就能搭出一个还不错的书架。但如果你想在书架上加一个异形抽屉，抱歉，改不了。

AutoGen 是一群人坐在会议室里自由讨论。你设定好每个人的角色和议题，然后让他们聊。讨论过程很"智能"，但也可能跑偏、吵架、浪费时间。结果好不好，取决于运气和角色设定。

LangGraph 是乐高积木。没有说明书，没有预设形态。你得自己设计蓝图、选零件、一块一块搭。费时间，但你能搭出任何你想要的东西。

维度	LangGraph	CrewAI	AutoGen
核心抽象	图（Graph）	角色（Role）	对话（Conversation）
学习曲线	陡峭	平缓	中等
控制精度	极细粒度	粗粒度	中等
状态管理	内置 Checkpoint	基础支持	对话历史
生产就绪	最成熟	良好	改善中
Token 效率	最优	中等	最高开销
适合场景	复杂生产系统	快速原型	研究探索

所以我的选择标准很简单：

• 如果你在做 Demo 或 PoC：选 CrewAI。30 分钟出活，给老板看够了
• 如果你在做研究或探索：选 AutoGen。对话式交互更灵活，适合开放性问题
• 如果你要上生产：选 LangGraph。别犹豫

有意思的是，2026 年 MCP（Model Context Protocol）成为工具调用的事实标准后，LangGraph 是三者中集成最深的——MCP 工具可以直接变成图中的节点，支持完整的流式传输。这不是偶然，而是架构上的先天优势：图结构天然适合表达"连接外部工具"这件事。

当然，这不是说 LangGraph 完美无缺。它最大的问题就是学习曲线陡峭。你需要理解图论基础、状态管理、Pregel 执行模型……这些概念对很多开发者来说是全新的。CrewAI 半小时上手，LangGraph 可能得花两三天。

但我认为这个投入是值得的。因为——

CrewAI 让你快速搭出一个能跑的 Demo，LangGraph 让你搭出一个能扛住生产流量的系统。前者是起点，后者是终点。

---

写在最后：三个预测

聊了这么多，我对 LangGraph 和多 Agent 系统的未来有三个判断：

预测一：到 2026 年底，"图编排"会成为 Agent 框架的标配。

不只是 LangGraph。CrewAI 已经在往图结构上靠了，微软新发布的 Agent Framework 1.0 也采用了类似的 DAG 编排。"链"的时代结束了，"图"的时代刚刚开始。就像 Web 开发从 jQuery 走向 React——大家最终会收敛到同一个范式上。

预测二：到 2027 年 Q1，LangGraph 的 Checkpoint 机制会被至少 3 个主流云平台原生集成。

AWS 已经有 LangGraph 的官方集成教程了。当越来越多的企业发现"Agent 需要持久化状态"这个刚需时，云平台会把 Checkpoint 存储作为基础设施提供——就像今天的消息队列和对象存储一样。

预测三：真正改变游戏规则的不是模型能力的提升，而是 Agent 运行时（Runtime）的成熟。

过去三年，所有人的注意力都在"模型更聪明"上。但 2026 年的实践告诉我们：一个 70B 参数的模型配上好的编排框架，能打过一个 400B 的模型跑裸 prompt。模型是引擎，运行时是底盘和变速箱。引擎再强，没有好底盘也跑不稳。

LangGraph 就是这个"底盘"。

半年后回来看看，我说得对不对。