LangGraph 1.2 安装与使用指南 —— 从状态图到生产级有状态 Agent

2026 年 8 月 11 日，LangGraph 发布 1.2.11。它是 LangChain 官方出品的「低层编排框架」——不抽象你的 Prompt 和架构，只负责一件事：让长时间运行、有状态的 Agent 应用稳定跑起来。持久化执行、流式输出、人工介入（Human-in-the-loop）、记忆管理，这些生产环境最难啃的骨头，LangGraph 都给你打好了地基。

本文基于官方文档，从零开始完整介绍：安装、核心概念（State / Nodes / Edges / 超级步）、reducers、ReAct 实战、持久化与检查点、Human-in-the-loop、流式输出（含 1.2 全新的 event streaming）、时间旅行，以及 Studio 可视化调试与生产部署，全程配官方示意图与 Mermaid 流程图。

一、LangGraph 是什么？先看生态全景

LangChain 官方对 LangGraph 的定位很明确：

LangGraph is a low-level orchestration framework for building, managing, and deploying long-running, stateful agents.

翻译过来就是：低层编排框架 + 运行时，管理长期运行、有状态的 Agent。它被 Klarna、Replit、Elastic、Uber、J.P. Morgan 等公司用于生产环境，GitHub 星标已超 4 万。

关键理解：LangGraph 只管「编排」，不管「怎么写 Prompt、怎么选模型」，所以它可以脱离 LangChain 独立使用。官方生态各层分工如下：

flowchart TB
    APP[你的应用 / 产品]
    subgraph HIGH[上层封装]
        DA[Deep Agents · 规划 / 子代理 / 文件系统]
        LC[LangChain create_agent · 高层 Agent 框架]
    end
    subgraph RUNTIME[LangGraph · 低层编排运行时]
        SG[StateGraph 状态图]
        CP[持久化 / 检查点]
        ST[流式输出]
        HL[Human-in-the-loop]
    end
    LS[LangSmith · 追踪 · 评估 · 部署]
    APP --> DA
    APP --> LC
    DA --> RUNTIME
    LC --> RUNTIME
    RUNTIME --> LS

LangChain：Agent 框架（模型 / 工具 / 标准 Agent 循环的抽象）；
LangGraph：编排运行时（持久化执行、流式、人工介入、状态管理）；
Deep Agents：构建在 LangGraph 之上的「Agent Harness」，自带规划、子代理、文件系统工具；
LangSmith：追踪、评估、部署，覆盖整个技术栈。

什么时候该用 LangGraph？ 当你有「高级需求」时：

需要把确定性代码（固定步骤、可审计）和 LLM 驱动步骤混合在同一个流程里；
需要持久化执行——进程崩溃、重启后从断点续跑；
需要Human-in-the-loop——关键操作前停下来等人工审批；
需要短期/长期记忆、时间旅行调试、精细的流式控制。

架构层面，LangGraph 的实现受 Google Pregel 与 Apache Beam 启发，公共接口借鉴了 NetworkX——本质是「图计算 + 消息传递」，只是被用在了 Agent 上。

二、安装与第一个图

2.1 环境要求与安装

Python 3.10 ~ 3.13（PyPI 官方支持矩阵），或使用 JS/TS 版 LangGraph.js；
pip 或 uv 均可。

# 方式一：uv（官方推荐）
uv add langgraph

# 方式二：pip
pip install -U langgraph

验证：

python -c "import langgraph; print(langgraph.__version__)"
# 1.2.11

2.2 第一个图：Hello World

LangGraph 用 StateGraph 建模工作流，三要素：State（状态）、Nodes（节点）、Edges（边）。先看一个最小例子：

from langgraph.graph import StateGraph, MessagesState, START, END

def mock_llm(state: MessagesState):
    return {"messages": [{"role": "ai", "content": "hello world"}]}

graph = StateGraph(MessagesState)
graph.add_node(mock_llm)
graph.add_edge(START, "mock_llm")
graph.add_edge("mock_llm", END)
graph = graph.compile()

graph.invoke({"messages": [{"role": "user", "content": "hi!"}]})

编译后，这个图的结构是这样的：

官方文档中的图结构渲染：__start__ → mock_llm → __end__

几个关键点：

StateGraph(MessagesState)：用状态 Schema 参数化图。MessagesState 是内置的「消息列表」状态，做对话类应用最常用；
add_node / add_edge：注册节点和固定跳转边；START / END 是虚拟的起点/终点；
必须 compile() 后才能运行——编译时会做结构检查（如孤立节点），也是指定 checkpointer 等运行参数的入口；
节点和边都只是函数：节点里可以放 LLM，也可以放普通代码。

三、核心概念：State、Nodes、Edges 与「超级步」

LangGraph 的运行模型可以总结成一句话：节点干活，边指路（nodes do the work, edges tell what to do next）。

底层采用消息传递（message passing）：节点完成操作后，把消息沿边传给后续节点，程序按离散的「超级步（super-step）」推进。

一个超级步 ≈ 图节点的一轮迭代；
并行执行的节点属于同一个超级步，顺序执行的节点分属不同超级步；
执行开始时所有节点都是 inactive；收到消息的节点变 active 并执行；超级步结束时没有消息的节点「投票」停止；所有节点都不活跃且没有消息在途中时，图执行结束。

flowchart LR
    START((START))
    subgraph S1[超级步 1 · 并行执行]
        A[node a]
        B[node b]
    end
    subgraph S2[超级步 2]
        C[node c]
    end
    START --> A
    START --> B
    A --> C
    B --> C
    C --> END((END))

并行与汇聚的结构在官方文档里长这样——多个分支跑完后再汇聚到同一节点：

a 扇出到 b、c 并行执行，再汇聚到 d 继续

3.1 State：图的共享状态

State 是图的共享数据结构，是所有节点和边的输入 Schema，通常用 TypedDict 定义（也支持 dataclass、Pydantic）。节点不需要返回完整状态，只返回「更新」——未提及的键保持不变。

from typing_extensions import TypedDict

class State(TypedDict):
    topic: str      # 主题
    score: int      # 评分

多 Schema（进阶）：可以给图定义 input_schema / output_schema 控制对外输入输出，节点还能写「私有通道」做内部通信：

builder = StateGraph(OverallState, input_schema=InputState, output_schema=OutputState)

⚠️ 注意：私有通道只在 invoke() 返回时被过滤掉，用 stream_mode="values" 流式输出时依然可见（默认发出全部状态通道）。需要限制时传 output_keys=["graph_output"]。

3.2 Reducers：状态的合并规则

每个状态键都有独立的 reducer 函数，决定节点更新如何写入。理解 reducer 是理解 LangGraph 状态管理的关键：

默认 reducer：直接覆盖（用新值替换旧值）；
Annotated 指定自定义 reducer：比如 operator.add 做列表追加。

from operator import add
from typing import Annotated
from typing_extensions import TypedDict

class State(TypedDict):
    foo: int                          # 默认：覆盖
    bar: Annotated[list[str], add]    # 追加合并

假设状态是 {"foo": 1, "bar": ["hi"]}，节点返回 {"bar": ["bye"]}，合并后是 {"bar": ["hi", "bye"]}——新列表被追加，而不是替换。

两个常见坑：

想清空带合并 reducer 的字段？返回空值没用——空列表被「合并」进去，旧值还在。需要用 Overwrite 绕过 reducer：return {"errors": Overwrite([])}；
UntrackedValue：声明「不进入检查点」的字段（数据库连接、临时缓存等），恢复时会被重置，适合不可序列化的运行时对象。

3.3 Nodes 与 Edges：线性、分支、循环

线性流程——最基础的链式执行：

__start__ → step_1 → step_2 → step_3，每个节点是一个超级步

条件边（conditional edges）——根据状态动态选路；虚线即条件跳转：

条件边示意：从 a 按条件进入 b 或 c

def route(state: State) -> str:
    return "pass" if state["score"] >= 60 else "retry"

builder.add_conditional_edges("judge", route, {"pass": END, "retry": "generate"})

循环与重试——图里可以成环，这是 Agent「想-做-看」循环的基础；实线箭头指回上游节点：

条件不满足时 a → b → 回到 a，直到满足才走向 __end__

循环要有退出条件，LangGraph 也提供递归上限（recursion_limit）兜底，防止无限循环烧掉 API 额度。

此外还有 Command（节点内动态决定下一步 goto 与状态更新）和 Send（动态扇出）两个进阶控制流原语，下一节就会用到。

3.4 并行与 Send：一个 Map-Reduce 实例

以下图为例——先生成多个主题，并行为每个主题生成内容，最后汇总挑选：

generate_topics →（并行）generate_joke → best_joke

from langgraph.types import Send
from operator import add
from typing import Annotated

class State(TypedDict):
    topic: str
    subjects: list[str]
    jokes: Annotated[list[str], add]   # 并行分支的写回自动合并
    best_joke: str

def continue_to_jokes(state: State):
    # 为每个主题动态扇出一个 generate_joke 节点实例
    return [Send("generate_joke", {"topic": s}) for s in state["subjects"]]

builder.add_edge(START, "generate_topics")
builder.add_conditional_edges("generate_topics", continue_to_jokes)
builder.add_edge("generate_joke", "best_joke")
builder.add_edge("best_joke", END)

分支并行执行（同一超级步），结果通过 Annotated[..., add] reducer 自动汇总——这就是 LangGraph 版 Map-Reduce。

3.5 编译：图可视化

compile() 之后可以随时导出图结构——官方文档里所有的结构示意图都来自它：

img = graph.get_graph().draw_mermaid_png()   # 导出 PNG
print(graph.get_graph().draw_mermaid())      # 或拿到 Mermaid 源码

四、实战：手写一个 ReAct Agent

理解了上面的原语，就可以拆解「Agent 循环」的本质了——模型决策 → 执行工具 → 回填结果 → 再决策，直到模型不再调用工具：

flowchart TD
    START((START)) --> AGENT[agent 节点 · 调用 LLM]
    AGENT -->|模型要求调用工具| TOOLS[ToolNode · 执行工具]
    TOOLS --> AGENT
    AGENT -->|没有工具调用| END((END))

用 LangGraph 手写这个循环，核心只有 7 行：

from langchain.chat_models import init_chat_model
from langchain_core.tools import tool
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import ToolNode, tools_condition

@tool
def get_weather(city: str) -> str:
    """查询指定城市的天气。"""
    return f"{city} 今天晴，25°C"

tools = [get_weather]
model = init_chat_model("openai:gpt-5.5").bind_tools(tools)  # 任意支持工具调用的模型

def call_model(state: MessagesState):
    return {"messages": [model.invoke(state["messages"])]}

builder = StateGraph(MessagesState)
builder.add_node("agent", call_model)
builder.add_node("tools", ToolNode(tools))          # 内置工具执行节点
builder.add_edge(START, "agent")
builder.add_conditional_edges("agent", tools_condition)  # 有工具调用→tools；否则→END
builder.add_edge("tools", "agent")                   # 工具结果回填后回到模型
graph = builder.compile()

graph.invoke({"messages": [{"role": "user", "content": "北京天气怎么样？"}]})

ToolNode：内置节点，负责解析工具调用并执行、回填结果；
tools_condition：内置路由函数——模型输出里有 tool call 就去 tools，否则去 END；
这个循环天然支持多轮工具调用（模型可以连续调用多次工具）。

💡 不想手写？LangChain 的 create_agent 和 LangGraph 的 create_react_agent 内部就是这套结构。理解底层循环的价值在于：你可以随时插入自己的节点——比如加一个「先检索知识库再回答」的固定节点，或一个「审批」节点（见第六节）。

五、持久化：Checkpointer 与 Store

持久化是 LangGraph 的灵魂。 没有它，就没有断点续跑、没有人工介入、没有记忆、没有时间旅行。LangGraph 提供两套互补的持久化系统：

Checkpointer（检查点）：把「一个线程（thread）」的图状态按超级步保存成检查点——用于线程级短期记忆：对话连续性、人工介入、时间旅行、容错；
Store（存储）：在图状态之外保存应用自定义数据——用于跨线程长期记忆：用户偏好、事实、共享知识。

官方这张图把核心概念一网打尽：

Graph / Super-steps / Checkpoints / Thread / StateSnapshot 的关系：每个超级步打包一次状态 → 检查点；线程 = 检查点集合

5.1 快速上手

from langgraph.checkpoint.memory import InMemorySaver

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

config = {"configurable": {"thread_id": "thread-1"}}   # thread_id 是持久化游标
graph.invoke({"messages": [{"role": "user", "content": "你好，我叫小明"}]}, config)
graph.invoke({"messages": [{"role": "user", "content": "我叫什么？"}]}, config)  # 记得住了

thread_id 就是指针：同一个 thread_id 复用一个检查点链（继续对话）；换新值则开一条全新线程（空白状态）；
InMemorySaver 存在内存里，进程重启即丢——只适合本地测试。

flowchart TB
    G[图执行] -->|thread_id=A · 每个超级步保存| A3
    subgraph TA["线程 A"]
        A1[检查点 1] --> A2[检查点 2] --> A3[检查点 3 · 最新]
    end
    subgraph TB1["线程 B"]
        B1[检查点 1] --> B2[检查点 2]
    end
    G -->|thread_id=B| B2
    G -.->|跨线程长期记忆| S[(Store · 键值存储)]

5.2 短期记忆 vs 长期记忆

短期记忆（对话历史）走 Checkpointer；长期记忆（用户档案、偏好）走 Store，两者一起喂给 LLM

长期记忆的更新时机也有讲究——热路径 vs 后台：可以在回复用户前同步更新（简单但增加延迟），也可以把记忆更新放到后台任务（比如 30 分钟后）异步处理：

In the hot path：更新记忆 → 响应用户；In the background：后台进程异步更新记忆

5.3 生产环境选型

场景	组件	安装
本地测试	`InMemorySaver`	内置
单机 / 开发	`SqliteSaver`	`pip install langgraph-checkpoint-sqlite`
生产	`PostgresSaver`（支持异步）	`pip install langgraph-checkpoint-postgres`

from langgraph.checkpoint.postgres import PostgresSaver

checkpointer = PostgresSaver.from_conn_string("postgresql://...")
checkpointer.setup()   # 建表 + 索引

三个高频坑：

thread_id 超长 → PostgresSaver 列长度有限制，控制在 255 字符内（可用 UUID）；
检查点无限增长 → 长对话会累积大量检查点，定期清理 + 设置保留策略；
子图状态与父图检查点命名空间相互独立，跨图边界的数据建议走 Store 共享。

另外，持久化粒度可调——durability 模式控制何时写检查点：

"exit"：只在执行退出时持久化，性能最好，但崩溃后无法恢复中间状态；
"async"：下一步执行时异步持久化，性能与安全平衡；
"sync"：每步同步持久化，最安全，有一点性能开销。

💡 用 Agent Server（LangGraph 服务器）部署时，持久化基础设施由服务器自动管理，无需自己接 checkpointer 和 store。

六、Human-in-the-loop：interrupt

interrupt() 让图在任意位置暂停，把控制权交给人，等人输入后再从断点继续：

sequenceDiagram
    participant U as 用户 / 前端
    participant G as 图（approval 节点）
    participant C as Checkpointer
    U->>G: invoke(input, thread_id)
    G->>G: 执行到 interrupt() 暂停
    G->>C: 保存检查点（等待可无限期）
    G-->>U: 返回中断载荷（__interrupt__）
    Note over U: 人工审核…
    U->>G: Command(resume=True)
    G->>C: 读取检查点恢复执行
    G-->>U: 继续执行直到结束

from langgraph.types import interrupt, Command

def approval_node(state: State):
    # 暂停，把问题交给调用方；恢复时，人的回答成为这里的返回值
    approved = interrupt({"question": "是否执行该操作？", "details": state["action"]})
    return {"approved": approved}

# 第一次调用：执行到 interrupt 后暂停
result = graph.invoke({"action": "删除生产数据库"}, config)
print(result["__interrupt__"])   # 拿到中断载荷

# 恢复：resume 值原样返回给 interrupt()
graph.invoke(Command(resume=True), config)

要点与注意：

interrupt 是动态的——可以按业务逻辑放在任意代码位置（区别于「静态断点」只能停在某节点前后）；
必须配 checkpointer，且 resume 时使用同一个 thread_id；
恢复时被中断的节点会从头重跑（interrupt 之前的代码再次执行），所以节点内要避免非幂等的副作用；
并行分支同时中断时，用 {interrupt_id: resume_value} 字典一次性恢复全部；
Command(resume=...) 是唯一允许作为 invoke() 输入使用的 Command 形式。
用 event streaming 时，中断载荷在 stream.interrupts，stream.interrupted 为 True 表示「跑到一半暂停了」。

常见模式：审批（执行敏感操作前）、编辑（人工修改 LLM 输出/工具调用再继续）、验证（校验人工输入后再进入下一步）。

七、流式输出：Stream 与 Event Streaming v3

7.1 传统 stream 模式

graph.stream(input, stream_mode=[...]) 支持 7 种模式，可组合：

模式	内容
`values`	每步之后的完整状态快照
`updates`	每步之后的状态增量（含节点名）
`messages`	LLM 调用产生的 (token, metadata) 二元组
`custom`	节点内通过 `get_stream_writer()` 发出的自定义数据
`checkpoints`	检查点事件（需 checkpointer）
`tasks`	任务开始/结束事件（需 checkpointer）
`debug`	上面所有信息的大合集

for chunk in graph.stream(
    {"topic": "冰淇淋"},
    stream_mode=["updates", "custom"],
    version="v2",
):
    if chunk["type"] == "updates":
        for node_name, state in chunk["data"].items():
            print(f"节点 {node_name} 输出: {state}")
    elif chunk["type"] == "custom":
        print(f"进度: {chunk['data']['status']}")

version="v2" 后输出格式统一为 StreamPart 字典：{"type": ..., "ns": ...(子图命名空间), "data": ...}，不再因模式数量、是否含子图而变化，类型检查器也能正确缩窄类型。

7.2 Event Streaming v3（1.2 新特性，官方推荐）

1.2 版本引入了新的推荐方式——event streaming：返回一个「运行流对象」，为不同消费场景暴露类型化投影（typed projections），多个消费方可以并发读取、互不干扰：

flowchart LR
    P[Pregel 引擎 · 原始事件] --> R[事件路由 / 转换器]
    R --> M[stream.messages · 令牌流]
    R --> V[stream.values · 状态快照]
    R --> I[stream.interrupts · 中断载荷]
    R --> O[stream.output · 最终输出]
    R --> S[stream.subgraphs · 子图流]

stream = graph.stream_events(input, version="v3")

for message in stream.messages:        # 逐 token 流式输出
    for token in message.text:
        print(token, end="", flush=True)

final_state = stream.output            # 等待最终结果
if stream.interrupted:                 # 顺便还能处理人工介入
    print(stream.interrupts)

常用投影一览：

投影	用途
`stream.messages`	聊天模型消息与 token 增量
`stream.values`	状态快照
`stream.output`	最终输出
`stream.subgraphs`	嵌套子图执行
`stream.interrupts` / `.interrupted`	人工介入载荷与状态
`stream.extensions`	自定义 transformer 投影

读取 stream.messages 不会影响 stream.values、stream.output 等其他投影——这是 v3 API 相比传统模式最舒服的地方。

八、时间旅行与容错

因为每个超级步都留有检查点，LangGraph 天生支持「时间旅行」调试——查看任意历史状态、修改它、从那里重放：

检查点全貌：get_state 拿最新检查点；get_state_history 列出全部；update_state 分叉出新时间线；从任意检查点重放

config = {"configurable": {"thread_id": "1"}}

state = graph.get_state(config)                  # 最新检查点
for snapshot in graph.get_state_history(config): # 全部历史（新 → 旧）
    print(snapshot.values, snapshot.next)        # 每个快照的状态与下一步

# 从指定检查点重放：该点之前的节点不执行，之后的重新执行
graph.stream(None, {"configurable": {
    "thread_id": "1",
    "checkpoint_id": "<checkpoint_id>",
}})

# 修改历史状态 = 分叉一条新时间线（原历史保留）
graph.update_state(config, {"status": "已批准"})

「重放」的语义：

从检查点重放：检查点之前的步骤不执行（直接复用已保存的结果），之后的步骤会重新执行

这套机制也是容错的基础：执行中途进程崩溃，重启后从最后一个检查点恢复，已完成的步骤不会重复执行（配合 durability 模式控制落盘时机）。

九、可视化调试与生产部署

9.1 LangGraph Studio：把图「看」出来

本地开发最爽的一环：一条命令启动带 UI 的开发服务器（无需 Docker），浏览器里直接看到节点拓扑、提交输入、查看每条线程的完整状态流、拖动时间轴回溯：

pip install langgraph-cli
langgraph dev

LangGraph 本地开发 UI（langgraph dev）：左侧是实时渲染的图结构，底部提交输入，右侧管理线程与状态，还支持断点、Deploy、Open in VSCode

Studio 支持两种模式：Graph 模式（全功能：节点轨迹、中间状态、时间旅行调试、数据集/Playground 集成）与 Chat 模式（面向聊天类 Agent 的轻量交互界面）。

9.2 CLI 命令速查

命令	作用
`langgraph dev`	本地轻量开发服务器（无需 Docker），快速迭代
`langgraph build`	构建 Agent Server 的 Docker 镜像
`langgraph deploy`	一步构建并部署到 LangSmith
`langgraph dockerfile`	按配置生成自定义 Dockerfile 模版
`langgraph up`	本地 Docker 中启动完整 API 服务器

CLI 读取当前目录下的 langgraph.json 配置：

{
  "dependencies": ["."],
  "graphs": {
    "agent": "./agent.py:graph"
  },
  "env": ".env"
}

9.3 上生产：LangSmith

部署后的可观测性交给 LangSmith——追踪每一次 LLM 调用、工具调用、状态迁移，评估 Agent 轨迹，监控成本与延迟：

LangSmith：请求量、Token、成本、延迟与评估得分（如幻觉率）尽收眼底

接入只需两个环境变量：

export LANGSMITH_TRACING="true"
export LANGSMITH_API_KEY="..."

十、1.2.x 版本节奏与亮点

LangGraph 1.2 系列在 2026 年 6~8 月保持密集更新，周边包同步推进：

包	最新版本	发布日期
langgraph（核心）	1.2.11	2026-08-11
langgraph-sdk	0.4.4	2026-08-27
langgraph-checkpoint	4.2.0	2026-08-07
langgraph-checkpoint-postgres	3.1.2	2026-08-07
langgraph-checkpoint-sqlite	3.1.1	2026-07-30
langgraph-cli	0.4.31	2026-07-10

gantt
    dateFormat YYYY-MM-DD
    title LangGraph 生态 2026 年 6-8 月版本节奏
    section langgraph 核心
    1.2.7 :milestone, lg127, 2026-06-30, 0d
    1.2.9 :milestone, lg129, 2026-07-10, 0d
    1.2.10 :milestone, lg1210, 2026-07-28, 0d
    1.2.11 :milestone, lg1211, 2026-08-11, 0d
    section 周边包
    cli 0.4.31 :milestone, cli043, 2026-07-10, 0d
    checkpoint 4.2.0 :milestone, ckpt42, 2026-08-07, 0d
    sdk 0.4.4 :milestone, sdk044, 2026-08-27, 0d

近期值得关注的变更：

Event Streaming（v1.2 引入）：类型化投影的 stream_events(version="v3")，取代 stream_mode 的推荐地位，1.2.10 进一步强化了 v3 返回类型与原生投影；
trace_policy：1.2.10 / 1.2.11 为 add_node 引入节点级追踪策略配置（实验性）；
checkpoint 4.2.0：修复 delta 通道历史在普通值种子的写入收集问题；checkpoint-postgres / sqlite 加速对齐一致性测试套件；
稳健的依赖节奏：几乎每 2~3 周一次小版本，跟随即可。

十一、常见问题

问题	解决
`RuntimeError: Graph is not compiled`	忘了调用 `.compile()`，编译后才能 invoke / stream
循环跑飞 / 递归超限	检查条件边的退出条件；调 `recursion_limit` 兜底
对话记不住上下文	加 checkpointer + 传 `configurable.thread_id`
重启后记忆全丢	把 `InMemorySaver` 换成 `SqliteSaver` / `PostgresSaver`
Postgres 报错 thread_id 过长	控制在 255 字符内（UUID / hash）
`interrupt` resume 后行为诡异	确认同一 thread_id；记住被中断节点会从头重跑
stream 里看到了「私有」字段	values 流默认发出全部通道，用 `output_keys` 限制
列表字段总是被覆盖	给它加 `Annotated[list, add]` reducer
想清空带 reducer 的字段清不掉	用 `Overwrite([])` 绕过 reducer
大结果塞爆上下文	先落盘再引用（Deep Agents 的文件系统工具思路）

十二、总结

LangGraph 1.2 的完整使用路径：

装：pip install -U langgraph（Python 3.10+）；
画图：StateGraph 定义 State → add_node / add_edge / add_conditional_edges → compile()；
管状态：用 reducer 控制合并（Annotated[..., add]、Overwrite、UntrackedValue）；
加记忆：compile(checkpointer=...) + thread_id，长期记忆上 Store；
接人工：interrupt() + Command(resume=...) 实现审批/编辑/验证；
流式：新项目直接用 stream_events(version="v3") 类型化投影；
调试：langgraph dev 打开 Studio，时间旅行随便倒带；
上线：langgraph deploy 到 LangSmith，或自托管 Agent Server。

一句话：需要「确定性 + Agentic 混合」的复杂工作流时，LangGraph 就是那个把状态、持久化、人工介入和流式都做掉的地基。

~/blog