LangGraph 到底是不是 Agent Runtime？
这个问题最近很容易吵起来。
有人说 LangGraph 就是 Agent Runtime。
有人说它只是 workflow graph。
也有人说 Runtime 这个词被框架营销用烂了。
我自己的判断是：
LangGraph 是一种 Agent Orchestration Runtime。
但它不是你系统里的全部 Runtime 责任。
这句话听着绕，拆开就清楚了。
先看 LangGraph 自己怎么说
LangGraph 官方文档把它描述为一个 low-level orchestration framework and runtime，用来构建、管理和部署 long-running、stateful agents。它强调的核心能力包括 durable execution、streaming、human-in-the-loop、persistence，以及把确定性步骤和 LLM 驱动步骤放在同一个 graph 里。
这不是普通'链式调用库'的定位。
它确实在处理 Runtime 问题：
状态如何流转
节点如何调度
长任务如何恢复
人类如何介入
图执行如何持久化
agent 和 workflow 如何混合
所以如果有人问'LangGraph 是不是 Runtime'，答案不能简单说不是。
但如果问题换成'用了 LangGraph，是不是就拥有了生产级 Agent Runtime'，答案也不能简单说是。
Runtime 有两层含义
技术讨论里，Runtime 至少有两层意思。
第一层是执行编排 Runtime。
它关心：
下一步跑哪个节点？
state 怎么传？
失败后能不能从 checkpoint 恢复？
人类能不能暂停、修改、继续？
图执行路径能不能被追踪？
LangGraph 很强地落在这一层。
第二层是产品级 Agent Runtime。
它还要关心：
用户能不能调用这个工具？
工具参数是否越过业务边界？
MCP Server 是不是可信？
shell / browser / file write 是否进 sandbox？
一次 run 的成本谁负责？
不可重放副作用怎么记录？
用户中途改了文件，resume 会不会覆盖？
trace 能不能定位到错误归因？
线上失败能不能沉淀成 eval？
这层不是某个 graph 引擎自动替你解决的。
它需要产品权限、组织策略、基础设施、工具治理和事故流程一起配合。
一个更准确的比喻
把 LangGraph 当成数据库，不太准确。
更像一个可持久化的状态机执行引擎，里面可以有普通节点，也可以有模型节点和工具节点。
它帮你解决'流程怎么跑、状态怎么存、怎么暂停恢复'。
但你还是要决定：
表结构怎么设计
哪些字段是敏感数据
谁有读写权限
事务边界在哪里
错误怎么补偿
日志保留多久
线上怎么审计
换到 Agent 语境，就是：
LangGraph 可以承载执行图。
但工具权限、沙箱边界、业务风控、成本预算、审计策略，仍然要由你的应用和 Runtime 层来定义。
它解决了 Loop 的哪些问题
如果你从 100 行 Agent Loop 开始写，LangGraph 最先帮你解决的是状态和编排。
最小 Loop 通常是这样的：
while (step < maxSteps) {
const response = await model.complete(messages, tools);
const results = await executeToolCalls(response.toolCalls);
messages.push(...results);
}
这个写法越长越痛苦。
LangGraph 把执行过程变成 graph：
node: build_context
node: call_model
node: route_response
node: execute_tool
node: human_review
node: final_answer
edge: 根据 state 决定下一步
好处很明显：
状态显式
分支显式
暂停点显式
人类介入点显式
恢复点显式
这对 long-running agent 很重要。
因为长任务不是一口气跑完的。它会暂停、失败、等待用户、换节点、恢复、重放一部分确定性逻辑。
靠一个手写 while 也能做，但你很快会重新发明一套简陋 LangGraph。
它没有自动解决 Tool Runtime
接下来是容易误判的地方。
你把工具节点放进 LangGraph，不代表 Tool Runtime 已经完成。
生产级 Tool Runtime 至少要回答：
工具 schema 谁校验？
路径是否限制在 workspace 内？
命令是否允许执行？
网络访问是否需要审批？
工具输出过大如何进入上下文？
工具失败如何变成结构化 observation？
工具是否幂等？
工具 started 但没有 completed 时如何 resume？
这些责任可以写在 LangGraph 节点里，也可以写成你自己的工具层，再由 LangGraph 调度。
但它们不会因为'节点在图里'就自动存在。
很多线上事故恰好发生在这里：graph 很优雅，节点也能恢复，但节点里面的工具调用仍然是裸奔的。
比如：
execute_shell_node(command)
write_file_node(path, content)
call_mcp_tool_node(server, tool, input)
如果这几个节点内部没有 permission、risk、timeout、output policy、idempotency、ledger，你只是把危险函数从 while loop 搬到了 graph node 里。
危险没消失，只是换了房间。
Persistence 也不等于完整 Checkpoint
LangGraph 文档把 persistence 分成 checkpointer 和 store。
checkpointer 保存 thread-scoped graph state，适合 conversation continuity、human-in-the-loop、time travel、fault tolerance。store 保存跨 thread 的长期数据，比如用户偏好、事实和共享知识。
这个划分很有用。
但在 coding agent 或有副作用的业务 agent 里，我们还要继续追问：
工具调用账本保存了吗？
不可重放工具的状态保存了吗？
文件写入前后的 hash 保存了吗？
审批记录保存了吗？
外部 API 已经发出但响应丢失时，状态是 failed 还是 uncertain？
graph state persistence 是恢复的基础。
但恢复是否安全，要看你在 state 里保存了什么。
如果 state 只有 messages 和下一步节点，恢复后仍然可能重复发请求、重复写文件、重复创建订单。
这不是 LangGraph 的错。
这是 Runtime 设计没有把副作用当成一等状态。
Human-in-the-loop 也不等于权限系统
LangGraph 支持 human-in-the-loop，这对生产 Agent 很重要。
但 human-in-the-loop 是能力，权限系统是策略。
能力是：
可以暂停
可以让人看 state
可以让人修改
可以继续执行
策略是：
什么工具必须问
什么用户能批准
什么环境默认拒绝
审批结果保存多久
恢复后审批是否仍有效
权限拒绝后模型能不能换路绕过
很多系统会把'需要人工确认'写成一个 UI 弹窗。
这只是最浅的一层。
真正的 Permission Runtime 要有 risk classification、policy evaluation、approval ledger、preview、audit log，还要和 tenant、workspace、role、environment 绑定。
LangGraph 可以让这个流程更好接入图执行，但策略本身要你自己写清楚。
LangGraph 更像 Runtime Kernel
如果一定要给它找一个位置，我会把 LangGraph 放在这里：
Product / App
├─ User auth
├─ Workspace / Tenant
├─ Billing / Quota
├─ Admin policy
│
Agent Runtime
├─ Permission Runtime
├─ Tool Runtime
├─ Context Runtime
├─ Checkpoint / Trace / Eval
│
Orchestration Runtime
└─ LangGraph
├─ StateGraph
├─ Nodes / Edges
├─ Persistence
├─ Human-in-the-loop
└─ Durable execution
它像一个 Runtime Kernel。
负责状态图和执行推进。
你的生产级 Agent Runtime 还要在它外面包一层产品和治理边界。
当然，你也可以反过来做：把很多 Runtime 责任写成 LangGraph 节点、中间件或工具 wrapper。这样也可以。
关键不是目录怎么分。
关键是这些责任有没有存在。
什么时候适合用 LangGraph
我会在这些情况下认真考虑 LangGraph：
任务会跨多步执行
需要确定性流程和模型决策混合
需要暂停等待人工审批
需要保存和恢复 graph state
需要把 agent 行为做成可观察路径
多个节点之间共享状态很复杂
比如：
代码修复 agent
客服工单处理 agent
研究报告 agent
数据分析 agent
运维排障 agent
企业内部审批 assistant
这些任务不是简单一次问答。
它们有状态，有分支，有人类介入，有失败恢复，有审计需求。
这就是 LangGraph 的舒适区。
什么时候不用急着上
如果你的需求只是：
一次模型调用
RAG 问答
固定三步 prompt chain
简单 tool calling demo
低风险内部脚本
那不必为了'看起来像 Agent Runtime'而上 graph。
Anthropic 那篇《Building effective agents》里有个判断我很认同：先用最简单的方案，只有复杂度真的必要时再加。
很多团队的问题不是框架太少，而是过早把简单业务塞进复杂框架，然后连 prompt、tool input、state 变化都看不清了。
框架不是成熟的证明。
能把复杂度控制在问题需要的地方，才是成熟。
一个简单的判断表
下次有人问'LangGraph 是不是 Agent Runtime'，可以用这张表判断：
| 问题 | LangGraph 覆盖度 | 还需要你补什么 |
|---|---|---|
| 多步骤状态流转 | 很强 | 业务 state 设计 |
| 持久化和恢复 | 很强 | 副作用 ledger、恢复策略 |
| 人机协同 | 很强 | 权限策略和审批审计 |
| 工具调用 | 可承载 | 工具校验、风险、沙箱 |
| 观测 | 可配合 LangSmith | 事故归因口径、eval 回流 |
| 成本预算 | 部分可做 | 产品 quota、token/tool/wall-clock policy |
| MCP 工具治理 | 需要你设计 | namespace、trust、schema drift、approval |
| 多租户安全 | 应用责任 | auth、tenant isolation、data retention |
所以我的答案是：
LangGraph 是 Agent Runtime 的重要实现路线之一。
更准确地说，它是 orchestration runtime。
但生产级 Agent Runtime 不是一个包名，它是一组工程责任。
如果这些责任没有落地，你用了 LangGraph，也只是拥有了一个很好的图执行底座。
如果这些责任落地了，哪怕你暂时没有用 LangGraph，你也已经在写自己的 Runtime。
