LangGraph:把 agent 当成必须可持久、可中断、可恢复的长运行进程

一句话定位

LangGraph 官方给自己的定义是「构建有状态智能体的底层编排框架」,MIT 协议,Python(另有 LangGraph.js 对应 JS/TS),README 里点名的生产用户包括 Klarna、Replit、Elastic。它不是「又一个 agent SDK」,而是把 agent 当成一个需要持久化、可中断、可恢复的长运行进程来对待的那一层。

它的血统写在致谢里:灵感来自 Google 的 Pregel 与 Apache Beam,对外接口借鉴 NetworkX。这不是随手贴的引用——Pregel 是图计算的 BSP(整体同步并行)模型,顶点在超步之间交换消息、状态被显式管理。把这套模型搬到 agent 上,得到的正是「节点 = 一次模型调用或工具执行,边 = 控制流,状态 = 显式对象」的结构。LangChain 出品,但可脱离 LangChain 单独使用。

它真正解决的问题:长运行 agent 是个分布式系统问题

大多数 agent 框架停在「循环调用模型 + 工具」这一层,而这一层在演示里够用、在生产里不够。生产环境的三个失败模式,都不是提示词能修的:

README 列出的能力	它对应的真实故障	为什么必须在运行时层解决
持久化执行(Durable execution)	进程崩了、容器被杀、机器重启,一个跑了四十分钟的任务全部丢失	需要把每一步的状态落盘,并从中断处精确续跑而不是重来;这是检查点机制,不是提示词技巧
人在环中(interrupts)	agent 要执行「删库」「发款」「对外发邮件」,必须有人批	等待人类审批可能持续数小时甚至数天,执行图必须能被无限期挂起再唤醒,而内存里的调用栈做不到
短期 + 长期记忆	上下文窗口装不下整个会话;跨会话又要记住项目规则	工作记忆与持久记忆是两套不同的存储与生命周期,要由框架分别管理
LangSmith 可观测	多分支、多子图的执行路径,出错了没人知道走了哪条	需要执行路径追踪与状态转移快照,这是插桩,不是日志打印

把这四条放在一起看,LangGraph 的实际主张是:agent 的可靠性问题在运行时,不在模型。模型再强,一个跑三小时、中途要人批一次、崩溃后要能续上的工作流,靠的是检查点、状态机与可恢复执行——这套东西与 LLM 无关,是几十年的分布式系统经验。这也解释了它为什么自称「底层」:它不替你做决策,它负责让决策过程可持久、可中断、可重放。

它在 LangChain 栈里的位置

官方给了三层关系,值得原样记下来,因为很多团队在这里选错层:

• LangGraph 是图运行时。当「agent 循环」这个形状本身不合适、你需要自定义控制流(分支、子图、并行、回退)时,下到这一层。
• LangChain 的 create_agent 是它之上的最小 agent 骨架,不带捆绑中间件。
• Deep Agents(本站另有独立条目)是更有主见的 harness,把文件系统、子智能体、上下文管理、Skills 一并打包。

三层是可组合的:任何 LangGraph 编译出的 CompiledStateGraph 都能作为子智能体传给上层 Deep Agent。这意味着选层不是二选一,而是「默认用高层,遇到不合适的那一段下沉到图层重写,再把重写结果装回高层」。

边界与取舍

• 抽象有学习成本:图、节点、边、状态、检查点是五个必须理解的概念,写一个简单 agent 会觉得重。它换来的是复杂流程的可控性,不是入门速度。
• 生态绑定是软的但存在:可脱离 LangChain 使用,但要拿到追踪、评测、部署的完整体验,自然会被引向 LangSmith(商业产品)。自建可观测的团队要自己接。
• 状态设计仍是你的活:框架给你持久化机制,但状态对象的形状、哪些字段进检查点、如何做版本迁移,都得自己设计。状态 schema 变更导致旧检查点读不出来,是这一类系统的常见事故。
• 不解决模型层的不确定性:可恢复执行不等于结果正确。重试与续跑能救「崩了」,救不了「跑歪了」。

在 agientry 里的位置

本站的 harness / 编排层同时收了 Orca、herdr、multica、paperclip 这几条,它们与 LangGraph 不在同一个平面上:那几条编排的是已经在跑的 agent 进程与工作目录(谁的分支、谁的终端、谁的看板),LangGraph 编排的是一个 agent 内部的执行图。前者是多智能体的调度问题,后者是单智能体的运行时问题,两者可以叠着用。用户点名要收 LangGraph 是对的——它是这一层里星标最高、生产用户最多的那条主线。

本页事实来自项目 README(实读全文)与官方文档链接;星标、协议、语言取自 GitHub API。我们没有跑过 LangGraph,也没有做基准或复现测试,持久化恢复的实际行为(崩溃后状态一致性、检查点迁移)未经我们验证,因此这一条记为待复现。