LangGraph：把 Agent 画成一张图——低层编排框架是什么、解决什么问题
LangChain 官方低层编排框架全解析：State / Node / Edge 三概念、确定性步骤与 agentic 步骤的混搭、checkpointer 持久化、human-in-the-loop 人工接管，以及它在 LangChain 三层架构（Deep Agents → LangChain → LangGraph）里的位置。
Agent 这个概念，在 2026 年已经被讲得足够多了——Karpathy 讲 LLM，Andrew Ng 讲四种设计模式， 前面几篇还聊了Superpowers、ECC 这些给编码代理的"工作环境"。 但如果你真的想把一个 Agent 从 demo 变成生产系统，会撞上一类很少被讲清楚的问题： 怎么描述"Agent 内部到底怎么流转"？怎么让它跑几小时不断、崩了能续、关键时刻让人插一手？ 这篇要讲的 LangGraph， 就是 LangChain 官方给这些问题准备的答案——一个把 Agent 画成一张图的低层编排框架。
一、它是什么：把 Agent 的执行流程画成一张图
LangGraph 是 LangChain 出的一个低层编排框架与运行时， 专门用来构建、管理、部署"跑得久、带状态"的 Agent。 它不做模型抽象、不做工具集成（那是 LangChain 的事），它只专注一件事：Agent 的执行流程怎么组织。官方文档点名的使用方包括 Klarna、Uber、摩根大通—— 说明它已经过了"玩具"阶段，正在被真正扛生产流量的公司用。
它的核心理念，是把 Agent 的执行流程画成一张有向图。核心只有三个概念：
| 概念 | 作用 |
|---|---|
| 状态 State | 流过整张图的数据。示例里是 MessagesState——一个消息列表，每跑一步就追加一条。 |
| 节点 Node | 图上的一个处理单元，一个普通函数：输入状态，返回状态的更新。最典型的节点就是一次 LLM 调用。 |
| 边 Edge | 连接节点、START 与 END，决定执行顺序——谁跑完、轮到谁。 |
官方给了一个最小的 "hello world" 示例，装好包、建个图：
pip install -U langgraphfrom langgraph.graph import StateGraph, MessagesState, START, END
def mock_llm(state: MessagesState):
return {"messages": [{"role": "ai", "content": "hello world"}]}
graph = StateGraph(MessagesState)
graph.add_node(mock_llm)
graph.add_edge(START, "mock_llm")
graph.add_edge("mock_llm", END)
graph = graph.compile()
graph.invoke({"messages": [{"role": "user", "content": "hi!"}]})这个例子虽然小，但结构是完整的：定义状态类型 → 加节点 → 连边 → 编译 → 调用。 真实 Agent 只是把"一次 LLM 调用"的节点，换成"判断 + 调工具 + 再调 LLM"的循环而已。
二、为什么需要它：让"确定性"和"智能"在同一张图里共存
LangGraph 官方反复强调的一个点，也是它最核心的设计动机：你可以在同一张图里，混合"手写死的确定性步骤"和"由 LLM 驱动的 agentic 步骤"。
为什么要这样？因为真实业务里，不是每一步都该让模型自由发挥：
- 有些步骤要完全可预测、可审计——比如数据校验、金额计算、权限检查，写死比问模型靠谱；
- 有些步骤要保持灵活——比如"下一步该调哪个工具"，这恰恰是 LLM 的强项。
过去这两类逻辑往往被硬拆成两个系统。LangGraph 把它们放进同一张图，该写死的地方写死，该智能的地方智能，每一个节点都看得见、可单测、可审计。这是它和"纯 prompt 流"、"纯工作流引擎"都不同的地方。
三、它解决的核心问题：让 Agent "跑得久、记得住、可接管"
这是 LangGraph 和大多数"agent 框架"最不一样的地方，也是它存在的理由。
1. 持久化：崩了从断点续跑
真实 Agent 不是跑一次就完：可能跑几个小时，中间服务重启、网络抖动、模型超时。 LangGraph 的 checkpointer（检查点）把状态持久化下来， Agent 遇到故障后可以从上次中断的地方恢复，而不是从头再来。 官方原话：持久化让 Agent 可以"运行很长时间，并从它离开的地方继续"。
2. Human-in-the-loop：随时插一手
生产环境里，你通常不想让 Agent 完全自主。LangGraph 允许在任意时刻检查、修改 Agent 的状态—— 在它要花大钱、删数据、或者需要审批的时候，人可以介入、改状态、再放它继续。 这让"人工把关"从"事后补救"变成了流程里的一等公民。
3. 记忆：短期 + 长期
短期记忆是"正在进行的推理"——当前这个任务的上下文，跟着图的状态走； 长期记忆是跨会话记住的东西——下一次对话还能用上，而不是每次从零开始。
4. 流式输出
长任务的每一步结果都可以流式吐出来，而不是憋到最后一次性给—— 这对"跑很久的 Agent"尤其重要，用户至少能看到它进行到哪了。
四、它在 LangChain 生态里的位置：一张三层架构图
LangGraph 官方文档把 LangChain 生态画成了三层，顺着这张图能一次看清它和邻居们的关系：
| 层 | 定位 |
|---|---|
| Deep Agents | 开箱即用的 Agent——自带上下文压缩、虚拟文件系统、子代理，面向"不想折腾就用"。 |
| LangChain（create_agent） | 高度可配置的 Agent 框架——模型、工具、agent 循环的抽象与集成。 |
| LangGraph | 低层编排框架与运行时——画节点、连边、管状态、持久化。 |
几个关键点：
- LangGraph 是最底层、最接近"执行引擎"的那一层：Deep Agents 建立在 LangChain 之上，而 LangChain 又建立在 LangGraph 之上；
- LangGraph 可以独立使用，不依赖 LangChain——你甚至可以完全不用它的模型抽象，自己管模型调用；
- 旁边还有 LangSmith 做可观测性与部署：打开
LANGSMITH_TRACING=true，就能看到每一条执行路径、状态迁移与运行时指标，出了 bug 能顺着图查。
顺带一提设计血统：LangGraph 的灵感来自 Google 的 Pregel 和 Apache Beam（分布式图计算与批流处理），公共接口则参考了 NetworkX（Python 图网络库）—— 所以它天生是为"大图、可扩展、可恢复"设计的，不是事后补的持久化。
我的收获
- Agent 的工程化，答案不是"更聪明的 prompt"，而是"可编程的控制流"——LangGraph 把 Agent 从"一段对话"变成了"一张可以编译、可以持久化、可以调试的图"，这是从 demo 到生产的质变。
- "确定性与智能的混搭"是个被低估的洞察——真正的系统，不该是"全让模型说了算"或"全写死"，而是两者在同一个结构里各司其职、互相可见。
- 持久化和 human-in-the-loop，才是"生产级 Agent"的分水岭——很多框架 demo 很惊艳，但一提到崩溃恢复、人工审批就露馅。LangGraph 把这两件事当成一等公民。
- 和之前几篇正好串成一条线——CS230 讲原理，Agentic AI 讲模式，Superpowers / ECC 讲给 Agent 的"工作环境"，LangGraph 讲的是把这些落地成"可运行、可维护的系统"的底层骨架。
想深入了解，官方文档在docs.langchain.com/oss/python/langgraph/overview， 配着 LangChain 的三层架构图一起看，是理解整个生态最快的一条路。