LangGraph 深度拆解：把 Agent 的状态、暂停和恢复做成可编排流程

先给结论：LangGraph 是一个偏底层的 Agent 与长流程编排库，核心抽象是“有状态的计算图”：应用把模型调用、工具和决策拆成节点，用边定义执行顺序或条件分支，再把每轮运行的状态传给下一步。与只封装一次模型请求的高级 Agent 框架相比，它给开发者更直接的恢复点、人工审批点和跨步骤状态控制；代价是要自己设计状态模型、持久化、重试和可观测性。它适合需要跨多轮或长时间运行的业务流程，不是装上依赖就自动拥有生产级 Agent。

Graph API 的运行方式

官方 Quickstart 用一个计算器 Agent 展示基本路径：定义工具和模型、建立包含消息历史的 State、写模型节点和工具节点、增加条件边，再编译 StateGraph。模型输出 tool call 时，条件边把流程导向工具节点；工具结果追加到状态后，流程回到模型节点，直到最终回答。State 的 reducer 决定新消息是追加还是替换，程序还可将调用次数、审批结果和业务对象 ID 放进状态。对于偏好函数式写法的项目，LangGraph 也提供 Functional API。

LangGraph 不要求一定使用 LangChain 的模型接口或托管服务，仓库说明它可独立使用；不过 Quickstart 示例通过 LangChain 的模型和工具包装函数展示。实际选择需评估当前 LLM provider、工具 schema、流式输出和 tracing 生态。部署、LangSmith 观测和 Agent Server 属于可选生态能力；核心开源库不会替企业自动准备数据库、身份服务或人工审批界面。

持久化分两层

持久化文档把 checkpointer 和 store 分开：checkpointer 按 thread_id 保存当前图的 state 快照，适合继续对话、故障恢复、人工介入和时间旅行；Store 用于跨 thread 的用户偏好、事实或共享资料。开发时可用内存 saver，但文档明确指出进程重启会丢失数据，长期运行需接 SQLite 或 Postgres 等持久后端，并制定 checkpoint 清理策略，否则长对话状态会持续增加并影响存储和延迟。

interrupt 是状态图中的动态暂停点。节点可暂停等待外部输入，checkpoint 保存后再以同一 thread_id 恢复；审批回复会作为 interrupt() 的返回值交给节点。安全场景可以在发送邮件、修改数据库或调用重要 API 前停下来给人审核。但恢复时节点会从头重新运行，不会从 Python 行号继续，因此中断前的外部副作用必须幂等，或移动到审批之后并使用去重键。忘记 checkpointer、换了 thread_id、或把 interrupt() 包在宽泛异常捕获里，都会让暂停和恢复产生意外行为。

当前版本和评估建议

GitHub 最新 Release 为 1.2.19（2026 年 10 月 30 日），当次更新修复 LangGraph 的 trace_policy、消息事件命名空间、subgraph streaming 和工具暂停状态等问题；仓库在 11 月 3 日仍有提交。对近期版本的使用者，升级后应该重放自己的流式运行、工具暂停、checkpoint 恢复和 subgraph 用例，而不是只做一次简单问答。可以将同一组任务分别以普通函数、简单有向图和持久化 Agent 实现，再比较中断恢复正确性、状态复杂度、错误恢复时间和数据库运维负担。

结论：LangGraph 的核心价值是可显式控制复杂 Agent 如何推进、保存和等待人工，而不是“多 Agent”本身。若流程只有一个模型回答加一两个工具，轻量函数循环更简单；若要可恢复、可审核、长时间执行的流程，图状态和 interrupts 值得评估。MIT 许可降低了源码使用门槛，但 checkpointer 后端、幂等外部操作、模型成本和对 Agent 输出的验证仍是应用方责任。

参考来源

1. langchain-ai/langgraph repository
2. LangGraph README
3. LangGraph Quickstart
4. LangGraph Persistence guide
5. LangGraph Interrupts guide
6. LangGraph 1.2.19 release notes
7. LangGraph MIT license