1. 从一个朴素问题说起

过去构建大模型应用，很多团队习惯写“线性 Prompt 链”：先让模型总结，再把总结传给下一段提示词，最后得到输出。这种写法在简单场景下没问题，但一旦需求变成“先判断、再调用工具、失败后重试、遇到高风险操作要人工确认”，线性链很快就会失控。

举个常见例子：我们要做一个“订单退款客服 Agent”。它的流程不是一句“帮我写退款规定”就能完成的，而是需要：

• 先判断用户是否有订单、是否在可退款时间内；
• 查询订单系统和支付系统；
• 根据查询结果决定是直接退款、转人工，还是要求补充凭证；
• 如果工具调用失败，要重试或降级；
• 退款金额超过阈值时，必须暂停并等待人工审批；
• 整个过程还要记录日志，便于事后审计。

如果用线性链来实现，开发者要么把所有逻辑塞进一个巨大的 Prompt，要么自己维护一堆 if-else 和临时变量。需求每变一次，代码都会更脆弱。

我们需要的不是一个更长的 Prompt，而是一个能组织、调度、记录并恢复整个 Agent 执行过程的运行时。LangGraph 就是在做这件事。

2. LangGraph 是什么

LangGraph 是 LangChain 团队推出的一套底层编排框架，用来构建有状态、可持久化、可循环执行的大模型应用。

它把一次 AI 任务拆成一张“图”，图中的每个部分都有明确的职责：

• Node / 节点：一次具体计算，例如调用大模型、调用工具、执行代码或挂起人工审批。
• Edge / 边：节点之间的控制流，决定当前节点执行完后下一步去哪里。
• Conditional Edge / 条件边：根据当前状态动态选择下一个节点。
• State / 状态：在整张图之间共享的类型化数据，类似 Agent 的“工作内存”。
• Checkpointer / 检查点：把执行到某一步的状态持久化下来，用于断点续跑、回溯和审计。
• Interrupt / 中断：让图运行到某个节点时暂停，等待外部输入或人工确认后再继续。

可以类比成一个工作流系统：State 是流转中的文件，Node 是处理步骤，Edge 是步骤之间的流转规则，Checkpointer 是每一阶段之后的保存点，Interrupt 则是流程中的人工关卡。

所以 LangGraph 不是简单的 Prompt 链，也不是只能做单轮工具调用的封装。它的本质更接近一个 Agent 执行运行时。

3. 为什么它越来越像 AI Agent 时代的“操作系统”

“操作系统”这个比喻并不是说 LangGraph 管理 CPU、内存和硬件，而是说它在 AI Agent 世界中承担了很多操作系统级别的责任：

操作系统的职责	LangGraph 中的对应能力
进程调度	图执行引擎负责顺序、条件、循环和并行调度
内存与持久化	State + Checkpointer 维护运行中的状态与历史快照
中断与恢复	Interrupt / Resume 可以暂停流程，处理完外部事件后继续
设备驱动与系统调用	工具节点可以被注册、替换、限流和统一管理
日志与监控	Tracing、调试、执行路径可视化提供可观测性
用户态生态	LangGraph Platform、Studio、Server 提供部署、权限、API 与持久化生态

更进一步看，这些能力并不是孤立存在的：

• 调度意味着 Agent 不再是一条直线跑到底，而是可以在节点之间跳转、循环，甚至并发执行，路径可以由条件边动态决定。
• 持久化意味着状态能够跨请求、跨会话甚至跨进程保存，这让长时间任务成为可能。
• 中断与恢复意味着系统可以主动停下来等待人，而不是只能一次性生成答案。
• 工具管理意味着模型调用的外部能力可以被统一封装、替换和治理。
• 可观测性意味着你可以回放一次 Agent 任务，看到它在哪一步调用了什么工具、状态如何变化、为什么失败。

这一整套能力组合起来，让 Agent 从“一次请求、一次响应”的服务，变成一个可以长期运行、可暂停、可恢复、可观测的工作流。

4. 从“框架”变成“运行时”是关键转折

传统 Agent 框架解决的问题通常是：怎么把模型、工具和提示词串起来。LangGraph 解决的问题更接近：当一次 Agent 任务需要跨多个节点、多轮循环、可能失败重试、可能等待人工时，整个系统应当如何运行。

例如下面这个最短的 ReAct 循环：

这个循环看似简单，但真正落地的难点在于：

• 循环边界在哪里？
• 每一步的状态如何保存？
• 工具调用失败后如何回退？
• 某些步骤如何暂停等待人工审批？
• 如何看到整条执行路径？

这些问题在“框架思维”里往往需要开发者自己解决：手动维护循环变量、手动设计重试逻辑、手动拼接上下文。而 LangGraph 用图、状态和检查点给出了统一的运行时答案：

• 循环通过条件边来定义，边界由条件函数决定。
• 每一轮的状态由 State 承载，Checkpointer 负责持久化。
• 失败重试可以在节点或边层面配置，而不必把错误处理散布在业务代码里。
• 人工审批通过 Interrupt 机制显式暂停。
• 执行路径通过 LangSmith、Studio 或图可视化工具进行追踪。

这些正是 LangGraph 作为运行时逐渐承担起来的职责。因此它越来越不像一个“库”，而更像一个 Agent 应用运行所需的基础设施。

5. 一段最小示例

下面的代码展示了一个带有循环控制和终止条件的 LangGraph 应用：

from typing import TypedDict
from langgraph.graph import StateGraph, START, END

class AgentState(TypedDict):
    attempts: int

def agent(state: AgentState) -> AgentState:
    print(f"执行 Agent，当前尝试次数: {state['attempts']}")
    return {"attempts": state["attempts"] + 1}

def should_continue(state: AgentState) -> str:
    # 达到 3 次后结束，否则继续循环
    return "end" if state["attempts"] >= 3 else "agent"

g = StateGraph(AgentState)
g.add_node("agent", agent)
g.add_edge(START, "agent")
g.add_conditional_edges(
    "agent",
    should_continue,
    {
        "agent": "agent",
        "end": END,
    },
)

app = g.compile()
result = app.invoke({"attempts": 0})
print(result)

逐步拆解这段代码：

• AgentState：定义共享状态的类型。这里只有一个 attempts 字段，表示已经尝试的次数。
• agent()：节点函数。每次执行时读取 attempts，将其加 1，表示一次“Agent 循环”完成。
• should_continue()：条件边函数。根据当前状态决定下一步：达到 3 次就进入 end，否则回到 agent 节点继续循环。
• StateGraph：构建图对象，并以 AgentState 作为状态类型。
• add_node() / add_edge() / add_conditional_edges()：分别注册节点、固定边和条件边。
• compile()：编译成可执行的 App。
• invoke()：从初始状态 {"attempts": 0} 开始运行，直到图到达 END。

这个例子很小，但已经体现了“操作系统”味道的核心：有状态、有循环、有条件终止，并且整个执行过程可以被检查和记录。

6. 哪些场景让它更像“操作系统”

LangGraph 的“操作系统”属性在复杂 Agent 应用中尤其明显：

• 长流程任务：搜索、阅读、反思、再搜索，可能需要循环很多轮。例如调研类 Agent 会反复调用搜索工具，阅读结果并追加到状态中，直到信息足够充分才总结输出。
• 人机协同：写代码、发邮件、发布内容前需要人工批准。例如内容发布 Agent 在生成文章后，先暂停等待编辑确认，确认后再继续发布流程。
• 多 Agent 协作：多个专家 Agent 像进程一样被调度，彼此传递状态。例如一个“产品经理 Agent”产出需求，转给“开发 Agent”实现，再由“测试 Agent”验证，每个角色都是图中的节点。
• 工具编排：模型可以调用搜索、数据库、API 等不同工具，并统一管理失败与超时。LangGraph 中的工具节点可以统一处理异常、限流和降级。
• 断点恢复与审计：长时间运行的任务可以暂停保存，之后从检查点继续。某个节点执行失败后，不需要从头重跑整条流程。

这些需求一旦叠加，普通“单次请求响应”的 Agent 框架就很难胜任，而图编排加状态持久化的运行时优势就会体现出来。

7. 与常见 Agent 框架的对比

为了更直观地理解 LangGraph 与“框架”的区别，可以和几类常见方案做个对比：

方案	代表	特点	局限
固定 Prompt 链	手工串联的 LangChain Chain	结构简单、上手快	难以表达循环、分支和人机协同
自主 Agent 循环	AutoGPT、AgentGPT 等	能自主规划与调用工具	可控性差、成本高、难以追踪
传统 ReAct 循环	LangChain AgentExecutor	支持工具调用和推理循环	状态管理、持久化和人工中断能力较弱
图编排运行时	LangGraph	显式建模节点、边、条件、状态与检查点	学习成本略高，需要理解图编程模型

可以看出，LangGraph 的核心优势不是“让模型更聪明”，而是让 Agent 的执行流程变得可控、可恢复、可观测。它适合那些不能接受“一次出错就重来”的生产级场景。

8. 深入理解 State 与 Checkpointer

State 和 Checkpointer 是 LangGraph 区别于普通 Prompt 链最关键的两个概念。

State 是图中的共享数据结构。所有节点都可以读取并更新它，相当于 Agent 在工作过程中不断积累的上下文。例如在一个搜索型 Agent 中，State 可以包含：

class ResearchState(TypedDict):
    question: str
    search_results: list[str]
    notes: str
    final_answer: str

每一步搜索都会往 search_results 追加结果，反思节点可以在此基础上更新 notes，最后总结节点将其合成 final_answer。这样，图的不同节点就不再依赖“传参”来交换数据，而是共享同一份类型化状态。

Checkpointer 则负责保存状态快照。没有检查点，图虽然能运行，但一旦结束状态就丢失；加入 Checkpointer 后，每执行完一个节点都会生成一个检查点，应用可以：

• 在某个检查点重新启动，继续执行未完成的部分；
• 查看历史状态，追溯 Agent 当时的决策依据；
• 实现多会话、异步续跑等长期运行能力。

一个最简的带检查点的例子如下：

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import MemorySaver

class State(TypedDict):
    count: int

def add(state: State) -> State:
    return {"count": state["count"] + 1}

g = StateGraph(State)
g.add_node("add", add)
g.add_edge(START, "add")
g.add_edge("add", END)

checkpointer = MemorySaver()
app = g.compile(checkpointer=checkpointer)

# 使用 thread_id 标识同一会话
config = {"configurable": {"thread_id": "task-001"}}
app.invoke({"count": 0}, config)

这里 MemorySaver 只是内存版实现，生产环境可以替换为数据库支持的 Checkpointer。有了检查点，长任务就不再是“一次性”的执行，而是一个可以持久化、恢复和回放的过程。

9. 人机协同：把“暂停”变成一等能力

很多 Agent 应用不能完全自动运行。比如：

• 批量发工资前需要财务确认；
• 代码提交生产环境前需要技术负责人审批；
• 对外发送邮件前需要人工复核措辞。

这类需求在传统“一路跑到尾”的 Agent 里很难优雅地实现，而 LangGraph 原生支持 Interrupt：图运行到指定节点时可以暂停，等待外部输入后继续。

一个最简单的示意：

from langgraph.types import interrupt

def publish_review(state):
    decision = interrupt({
        "prompt": "文章已生成，是否允许发布？",
        "options": ["approve", "reject"],
    })
    return {"decision": decision}

当执行到 publish_review 时，图会停下来，前端可以拿到暂停原因并向用户展示确认界面；用户选择后，图再带着新的状态恢复执行。实际使用时需要为图配置 Checkpointer，以便持久化中断状态。这样，审批、改稿、人工兜底等人机协同流程就从“额外开发功能”变成了图执行模型里的一等能力。

10. 生产落地时还需要关注什么

如果把 LangGraph 应用真正推到生产环境，除了图本身，还需要关注几个工程化问题：

• 状态存储：Checkpointer 要从内存实现换成可靠的持久化存储，并考虑并发、事务和数据生命周期。
• 可观测性：接入 Tracing 系统，记录每个节点的输入输出、耗时和工具调用，方便排障。
• 部署形态：可以选择 LangGraph Server / Platform 部署为 API 服务，也可以把图嵌入自己的后端应用。
• 权限与安全：工具调用涉及敏感系统时要做权限校验、参数校验和审计。
• 成本控制：循环次数、模型调用次数和上下文窗口需要设置上限，避免失控。

也就是说，LangGraph 提供了 Agent 运行时的基础能力，但生产级系统仍需要围绕它做好工程配套。这也正像操作系统提供了进程和文件管理，但应用仍要考虑资源配额、权限和监控。

11. 总结

LangGraph 首先是一个构建有状态 AI Agent 的图编排框架。它用节点、边、状态和检查点来描述一次 Agent 任务的完整执行过程。

它之所以越来越像一个“AI Agent 时代的操作系统”，是因为它不再只负责“生成回答”，而是开始负责 Agent 的调度、状态管理、工具调用、中断恢复、可观测性与长期运行。虽然它并不直接管理计算机硬件，但在 AI 应用这一层，它正在扮演类似“中间层操作系统”的角色：向上支撑复杂 Agent 应用，向下屏蔽执行细节。

从演示走向生产的过程中，Agent 应用的难点往往不在“模型能不能回答好”，而在“流程能不能可靠运行”。未来随着越来越多的 Agent 进入真实业务，谁能提供更可靠的运行时、更好的状态管理和更完整的生态，谁就更接近成为 AI Agent 时代的底层基础设施。