摘要：很多同学使用 LangChain 做 Agent，写 Demo 很顺畅，一旦上生产就各种踩坑：流程不可控、状态混乱、服务重启任务丢失、缺少人工审批。本文讲解为什么需要 LangGraph，剖析传统 AgentExecutor 的痛点，详解State、Node、Edge、Checkpointer核心概念，附带可直接运行最小 Demo，带你理解生产级智能体编排思想。

前言

学习 LangGraph 之前，先要理解一个问题：

已经有 LangChain、工具调用、RAG，为什么还需要 LangGraph？

答案很简单：真实生产环境的 Agent，不只是 “让大模型调用几个工具”。 它是一套需要状态、流程、记忆、故障恢复、人工介入、可观测性的复杂系统。 LangGraph 诞生的背景，就是 LLM 应用从玩具 Demo，落地为企业生产系统。

1 Agent 基础概念

1.1 从普通 LLM 应用到 Agent

普通大模型调用链路非常简单：

用户输入 → Prompt → LLM → 模型输出

适合场景：文本生成、翻译、摘要、简单问答、内容改写。

但它有明显短板：模型只能基于输入输出文本，无法自主完成多步骤复杂任务。

举个业务例子：

帮我查一下订单状态，如果还没发货就提醒客服加急。

这件事不是简单生成一段文字，完整链路：

1. 理解用户意图
2. 查询订单系统
3. 判断订单状态
4. 条件满足则调用客服系统
5. 组装回复给用户
6. 记录操作日志

这类多步骤任务，就进入了Agent 智能体的场景。

1.1.1 Agent 是什么

Agent：能够根据目标，自主决定下一步动作，调用外部工具完成任务的智能程序。

经典 Agent 循环（ReAct 范式：Reason + Act）

用户目标
  ↓
思考下一步 Think
  ↓
选择工具，执行动作 Act
  ↓
接收工具返回结果 Observe
  ↓
回到思考，循环 / 任务结束

Think → Act → Observe 循环拆解：

1. Think（思考）：Agent 结合当前全部信息做推理，决定下一步动作。例：信息不足，需要调用外部工具查询。
2. Act（行动）：执行动作，调用工具、调用 API、运行逻辑、调用子智能体。
3. Observe（观察）：拿到工具返回结果，把观测数据写入全局状态。

执行完成后再次回到 Think，往复循环直到任务结束。

1.1.2 Agent 对比普通 LLM 应用复杂在哪

普通 LLM：单次输入输出。 Agent：多轮往复 LLM → Tool → LLM → Tool → LLM → 最终答案。

随之带来一系列工程难题：

表格

问题	说明
状态管理	每一步执行结果保存在哪里
流程控制	下一步跳转到哪个业务节点
工具容错	工具调用失败如何处理
循环控制	如何避免无限循环
人工介入	高风险操作是否需要人工审批
持久化	服务重启，任务能否继续执行
可观测性	出错如何追溯执行链路

这些工程问题，仅仅靠写 Prompt 无法彻底解决。

2 传统 AgentExecutor 的局限

LangGraph 出现之前，大家开发 Agent 大多使用AgentExecutor，底层就是一个 while 循环。 伪代码：

while not finished:
    LLM决定下一步
    调用工具
    把工具结果追加到消息历史

写 Demo 非常方便，但落地生产会暴露出大量短板。

2.1 控制流完全交给模型，业务不可控

下一步调用什么工具、要不要继续、什么时候结束，全部由大模型自主决定。

• 很难保证固定执行顺序
• 很难插入硬性业务规则
• 复杂分支逻辑难以实现
• 企业审批流程不好表达
• 调试困难：不知道为什么走到这条执行路径

举例企业退款流程：

查询订单 → 判断金额大于 5000 → 需要主管审批 → 审批通过执行退款

这种强业务规则流程，不能完全交给模型自由发挥，需要显式定义 Workflow 工作流。

2.2 状态管理混乱，全部塞进 messages

早期 Agent 把所有内容全部堆入消息列表 messages：用户提问、工具调用、工具返回、中间判断、最终回答。

带来问题：

• messages 越来越长，token 开销暴涨
• 状态结构模糊，中间变量不好提取校验
• 工具执行结果难以复用

生产项目更需要结构化 State 状态：

python

运行

{
    "user_input": "...",
    "intent": "query_order",
    "order_id": "10086",
    "order_status": "pending",
    "need_human_review": True,
    "final_answer": "..."
}

LangGraph 核心思想之一：把 Agent 运行过程变成显式可读写的 State 状态对象。

2.3 缺少持久化，中断无法恢复

真实业务 Agent 任务可能耗时很长：撰写调研报告、批量处理文档、等待人工审批、多智能体协同任务。 如果服务重启，传统 Agent 循环直接丢失全部上下文，任务只能从头再来。

生产系统需要知道：执行到哪一步、当前状态快照、下一个执行节点、支持断点续跑。 LangGraph 依靠Checkpointer快照机制解决该痛点。

2.4 Human‑in‑the‑Loop 人工介入实现很别扭

退款、发邮件、修改数据库、提交合同等高风险操作，不允许 Agent 全自动执行，必须人工确认。

旧 Agent 要实现人工暂停，只能临时写一堆 if 判断； LangGraph 原生提供interrupt / resume，支持暂停、保存状态、外部审批、恢复执行，自带审计记录。

2.5 多 Agent 协作实现困难

复杂任务需要多个智能体分工：调研 Agent、代码 Agent、审核 Agent。 传统单循环 Agent 很难表达：谁先运行、谁负责审核、什么时候切回上一个 Agent、多个 Agent 如何共享状态、子 Agent 如何封装复用。 LangGraph 通过 Graph、Subgraph、Command 等能力，把多智能体转化为可编排图结构。

3 LangGraph 核心思想

LangGraph = Lang + Graph，把 Agent 应用建模成一张有状态的有向图。

它不是 Prompt 调优框架，它是 Agent 编排运行时，解决流程、状态、持久化、中断恢复、人机协同、多 Agent 协作问题CSDN博...。

3.1 图的基础组成：Node + Edge + State

表格

概念	含义
Node 节点	执行单元，可以是普通函数、LLM 调用、工具调用、子图
Edge 边	节点之间跳转规则，定义执行顺序
State 状态	整张图全局共享的数据容器
Reducer	多个节点同时修改同一字段时的合并策略
Checkpoint	每一步执行完成的状态快照，用于持久化恢复

简单图示例：

START → classify_intent → 【条件路由】
                    ├─ query_order
                    ├─ query_logistics
                    └─ human_handoff
→ final_answer → END

3.2 为什么用图来描述 Agent

Agent 天然不是简单线性流水线，业务里充斥大量：

• 条件分支
• 循环重试
• 工具调用循环
• 人工审批暂停
• 并行任务
• 子流程复用
• 多 Agent 协同

图结构可以非常自然表达以上逻辑。

💡区分：

• LangChain：模型、Prompt、工具、Runnable 组件库，偏向能力组件。
• LangGraph：有状态 Agent 编排运行时，偏向流程调度、状态管控。

现在新版本 LangChain Agent 底层已经大量复用 LangGraph 运行能力。

4 LangGraph 六大核心能力

4.1 State：显式结构化状态管理

使用TypedDict定义状态结构体，强类型提示，所有节点读取并返回状态更新字典，不需要返回完整 state。

python

运行

from typing_extensions import TypedDict

class State(TypedDict):
    user_input: str      # 用户原始输入
    intent: str          # 识别意图
    order_id: str        # 订单编号
    final_answer: str    # 最终回复

节点函数示例：

python

运行

def classify_intent(state: State):
    if "订单" in state["user_input"]:
        return {"intent": "order"}
    return {"intent": "general"}

节点只返回需要更新的字段，LangGraph 内部合并更新全局 State。

4.2 Control Flow：可控的流程编排

普通边固定跳转；条件边add_conditional_edges根据状态动态路由节点，不再完全由模型决定走向。

python

运行

builder.add_conditional_edges(
    "classify",
    route_by_intent,
    {
        "order": "query_order",
        "general": "general_answer",
    }
)

4.3 Persistence：Checkpointer 持久化快照

支持保存每一步状态快照，内存实现InMemorySaver适合开发调试；生产环境替换为 Redis / Postgres 存储。

python

运行

from langgraph.checkpoint.memory import InMemorySaver

graph = builder.compile(
    checkpointer=InMemorySaver()
)

获得能力：保存执行快照、查看历史、中断恢复、多轮会话、支持人工介入。

4.4 Human‑in‑the‑Loop 原生人工介入

关键节点使用interrupt()暂停整张图，等待外部审批，审批完成resume()从断点继续运行。

python

运行

from langgraph.types import interrupt

def approve_refund(state):
    decision = interrupt({
        "question": "是否批准退款？",
        "order_id": state["order_id"],
    })
    return {"approved": decision}

4.5 Streaming 流式输出

支持多种流式模式，可以实时看到当前执行节点、模型 token、工具调用进度、状态变更，适配前端聊天 UI，方便调试。

python

运行

for chunk in graph.stream(inputs, config=config, stream_mode="updates"):
    print(chunk)

4.6 Subgraph 模块化 + Multi‑Agent 多智能体

复杂业务拆分为子图：RAG 子图、审批子图、工具调用子图，代码复用易维护。 支持 Supervisor 管理者模式，调度 Research Agent、Code Agent、Review Agent 多个智能体协同工作。

5 LangGraph 适用与不适用场景

✅ 适合使用 LangGraph

表格

场景	原因
多轮对话 Agent	需要 thread 会话、checkpoint 记忆
复杂工具调用 Agent	需要精细控制工具循环
企业客服 Agent	意图识别、工具查询、人工转接
RAG‑Agent	检索、重排、校验引用、多步骤生成
Deep Research 深度调研	搜索、迭代总结、报告生成
Multi‑Agent 多智能体系统	多个 Agent 分工协作
审批类业务	Human‑in‑the‑Loop 人工审核
长耗时任务	中断、任务恢复

❌ 不一定需要 LangGraph

简单单次问答、普通 Prompt、简单 RAG，没有分支循环、不需要持久化、不需要人工审批、不需要多 Agent。 直接调用模型 API 或者 LCEL 链式即可，不要为了技术炫技强行引入 LangGraph 增加项目复杂度。

📋 是否选型 LangGraph 自检清单

1. 是否存在多个业务步骤？
2. 是否有条件分支逻辑？
3. 是否需要循环重试？
4. 是否需要保存执行状态？
5. 是否需要人工审批介入？
6. 是否需要任务中断恢复？
7. 是否需要多个 Agent 协同？
8. 是否需要实时观测执行过程？

多个问题回答为是，就适合引入 LangGraph。

6 最小可运行 LangGraph 示例

安装依赖

bash

pip install -U langgraph langchain python-dotenv

完整代码：

python

运行

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

# 1.定义状态State
class State(TypedDict):
    message: str
    answer: str

# 2.定义节点，接收state，返回状态更新字典
def chatbot(state: State):
    return {
        "answer": f"你刚才说的是：{state['message']}"
    }

# 3.构建图
builder = StateGraph(State)
builder.add_node("chatbot", chatbot)

# 4.配置边，定义流转路径
builder.add_edge(START, "chatbot")
builder.add_edge("chatbot", END)

# 5.编译图得到可执行对象
graph = builder.compile()

# 6.调用执行
result = graph.invoke({
    "message": "你好 LangGraph",
    "answer": ""
})

print(result["answer"])

执行链路：

plaintext

START → chatbot → END

最小 Demo 包含 LangGraph 三大基础元素：State、Node、Edge。

本章小结

LangGraph 诞生的根源：Agent 项目走向生产环境，单纯依赖 Prompt 与简单 while 循环 Agent 已经不足以应对工程挑战。

生产级 Agent 需要：可控流程、显式状态、持久化快照、中断恢复、人工审批、流式可观测、多 Agent 协作。

LangGraph 采用图编程范式：State + Node + Edge 构建有状态 Agent 工作流，把 Agent 从 “模型自由循环调用工具” 升级为可编排、可恢复、可调试、可扩展的企业级系统。

后续章节会继续讲解条件路由、Checkpointer 持久化、Human‑in‑the‑Loop、工具调用 Agent、子图与多智能体实战。