在构建基于 LLM 的复杂应用时我们经常会遇到一个棘手的问题：如何让程序像人一样拥有“记忆”，并且Neng够有条不紊地处理多步骤任务？LangGraph 作为一个强大的状态管理框架，正是为了解决这些痛点而生。hen多初学者在面对官方文档时往往会被各种概念搞得晕头转向。今天我们就抛开那些晦涩的理论，用一种geng接地气的方式，深入聊聊 LangGraph 的那些基础但核心的 API，特别是关于 Checkpoints和 Subgraphs的那些事儿。

一、 状态的“时光机”：深入理解 Checkpoints

想象一下Ru果你的 AI 程序在执行到一半时突然崩溃了或者你想知道它在三步之前到底Zuo了什么决定，该怎么办？这就需要用到 Checkpoints 机制。简单来说Checkpoints 就是 LangGraph 在图执行过程中，每当完成一个“超级步骤”时自动按下快门键保存的一张状态照片。

每一个 Checkpoint 实际上就是一个 StateSnapshot 对象。这玩意儿里头藏着什么宝贝呢？我们Ke以把它拆解来kan：

values这是Zui核心的部分，记录了当前所有状态通道的具体数据。比如你定义了 foo 和 bar 两个字段，这里就会存着它们此刻的数值。

next这就像是路标，告诉系统下一步该去哪个节点。Ru果这里是空的，那就意味着流程跑完了Ke以歇口气了。

metadata相当于照片的 EXIF 信息，记录了执行来源、修改记录、步骤编号等辅助数据。

created_at / parent_config前者记录了快照诞生的时间，后者则像家谱一样，记录了父检查点的配置，这对于构建完整的执行链路追踪至关重要。

那么谁来负责管理这些快照呢？这就是 Checkpointer 的职责。LangGraph hen贴心地提供了多种实现方式，比如存内存里的 InMemorySaver，或者存数据库的。要想让你的 Graph 具备“时光倒流”的Neng力，在编译的时候，必须显式地带上 checkpointer 参数。

# 内存记忆器：保存每一步执行状态，支持回溯
checkpointer = InMemorySaver
# 编译并绑定记忆
graph = workflow.compile

1.1 身份标识：Config 的作用

既然要存状态，就得有个“身份证号”，不然系统怎么知道这个状态是属于谁的？这时候就需要 config 出场了。它是一个关联的配置字典，里面Zui关键的就是 thread_id 和 checkpoint_id。

你Ke以把 thread_id 理解为一次对话的唯一标识。当我们在调用 graph 时传入这个 config，graph 内部就会根据 thread_id 去 Checkpointer 那里取数据。Ru果找不到，就说明是新对话；找到了那就接着上次的地方继续聊。

# 定义会话ID，区分不同的对话上下文
config = {"configurable": {"thread_id": "thread-123"}}

1.2 获取快照与历史回溯

有了 Checkpointer，我们就Neng随时查kan当前的状态，甚至翻阅历史记录。这就像是在查kan聊天记录一样方便。

# 获取当前时刻的快照
snapshot = graph.get_state
# 获取全部历史快照，按时间顺序排列
history = list)

这里有个细节需要注意：graph 本身其实并不存储快照，它只负责处理流程逻辑。真正的快照存储是和 Checkpointer 绑定在一起的。所以每次 invoke 的时候，别忘了把 config 传进去，否则系统就是个“金鱼记忆”，转头就忘。

二、 实战演练：构建一个Neng聊天的循环

光说不练假把式。我们来kankan如何用 LangGraph 搭建一个简单的对话循环。这里涉及到状态定义、节点注册以及循环控制。

2.1 定义状态：TypedDict 的妙用

在 LangGraph 里状态通常用 TypedDict 来定义。为了模拟类似 LangChain 中 ChatModel 的消息列表功Neng，我们Ke以利用 Python 的 Annotated 和 operator.add 来实现消息的自动合并。

from typing import TypedDict, Annotated, Sequence
from langchain_core.messages import BaseMessage, HumanMessage, AIMessage
import operator
class ChatState:
    # messages 自动合并消息的历史记录
    # Annotated：附加信息
    # Sequence：有序列表
    messages: Annotated, operator.add]

2.2 节点逻辑：输入与输出

我们需要两个核心节点：一个负责接收用户输入，另一个负责生成 AI 回复。为了增加程序的健壮性，我们在代码里加了一些异常处理，这可是实战中的好习惯。

用户输入节点

def handle_user_input:
    """
    处理用户输入节点
    """
    try:
        user_input = input.strip
        if user_input.lower == "Q":
            logger.info
            return END
        # 保留历史记录并追加新消息
        return {"messages": }
    except Exception:
        return END

AI 回复节点

def generate_ai_response:
    """
    生成AI响应节点
    """
    try:
        # 使用Zui近6条消息保持上下文连贯性
        recent_history = state
        """Zuo个摘要"""
        response = model.invoke
        return {"messages": }
    except Exception as e:
        error_msg = f"系统暂时无法响应，请稍后再试（错误代码：{str})"
        return {"messages": }

2.3 节点注册与图构建

有了节点函数，接下来就是把它们注册到图里。这里有个小知识点：add_node 内部其实会自动把我们的函数包装成 RunnableLambda，所以我们在调用时既Ke以传函数名，也Ke以显式地写 RunnableLambda。

from langgraph.graph import StateGraph, END
from langchain_core.runnables import RunnableLambda
builder = StateGraph
# 节点注册
# RunnableLambda 可不写，add_node 内部会自动包装成 RunnableLambda
builder.add_node
builder.add_node)
# 设置入口和边
builder.set_entry_point
builder.add_edge
builder.add_edge # 形成循环

2.4 对话循环的主逻辑

图编译好后我们用一个 while True 循环来驱动它。这里展示了如何提取Zui新的交互记录，并判断何时退出。

conversation = builder.compile
state = {"messages": }
while True:
    try:
        # 执行对话流程
        result = conversation.invoke
        if result is None or "messages" not in result:
            break
        # 提取Zui新交互记录
        new_messages = result
        # 打印AI响应
        for msg in new_messages:
            if isinstance:
                logger.info
        # geng新对话状态
        state = result
        # 检查退出条件
        if any and m.content.lower == "退出" for m in state):
            break
    except Exception as e:
        logger.info}")
        break

三、 模块化利器：Subgraphs详解

当业务逻辑变得庞大时把所有逻辑塞进一张图里简直是噩梦。这时候，Subgraphs就派上用场了。这就好比我们在编程语言里使用父类和子类的关系，LangGraph 允许我们将复杂的工作流拆解成geng小、geng易管理的子图，然后把这些子图当作一个普通的 Node 添加到主图中。

LangGraph 提供了两种截然不同的子图模式，这可是初学者Zui容易踩坑的地方，大家睁大眼睛kan好了。

3.1 模式一：共享状态模式

这种模式下父图和子图就像住在同一个宿舍的室友，它们共享一部分状态数据。关键点在于：共享的键名必须完全一致。

比如父图有 text，子图也有 text。当子图修改了 text，父图里的 text 也会自动同步geng新。这非常方便，但也容易产生“副作用”，Ru果不小心改了不该改的变量，可Neng会引发连锁反应。

class SharedParentState:
    text: str  # 父图与子图共享的键
    result: str  # 父图私有键
class SharedSubgraphState:
    text: str  # 与父图共享的键
    processed: str  # 子图私有键
def subgraph_node -> SharedSubgraphState:
    """子图节点：将共享键"text"转大写，存到私有键"processed"""
    return {
        "text": state.upper,  # 修改共享键
        "processed": f"Processed: {state.upper}"  # 子图私有数据
    }
def parent_node -> SharedParentState:
    """父图节点：直接调用子图"""
    return state  # 子图会修改"text"键，父图后续可直接用

3.2 模式二：不同状态模式

这种模式geng加严谨，适合解耦复杂的业务。父图和子图的状态完全独立，互不干扰。但是这也意味着我们必须在父图的节点里手动Zuo“翻译”工作。

具体来说就是要在父图节点中完成三个步骤： 1. 输入映射把父图的数据塞进子图Neng识别的格式。 2. 调用子图运行子图逻辑。 3. 输出映射把子图的结果拿回来geng新父图的状态。

class DifferentParentState:
    user_query: str
    answer: str
class DifferentSubgraphState:
    task: str
    result: str
def different_subgraph_node -> DifferentSubgraphState:
    # 处理逻辑：给 task 增加子图前缀
    return {"result": f" Processed: {state}"}
def parent_wrapper_node -> DifferentParentState:
    """
    父图包装节点：
    因为父子图状态完全独立，必须手动：
    . 父图状态 → 子图输入
    . 调用子图
    . 子图输出 → 父图状态
    """
    # ---------------------- 输入映射 ----------------------
    # 父图键：user_query → 子图键：task
    subgraph_input = {"task": state}
    # ---------------------- 调用独立子图 ----------------------
    # 子图与父图状态隔离，不会互相污染
    subgraph_output = compiled_different_subgraph.invoke
    # ---------------------- 输出映射 ----------------------
    # 子图键：result → 父图键：answer
    return {
        "answer": subgraph_output,
        "user_query": state  # 保留父图原始输入
    }

kan，根据主图的输入映射 {"task": state}，子图在 state 里操作主图传递的 task 字段。这种模式虽然写起来繁琐一点，但胜在安全清晰，特别适合大型项目开发。

四、 可视化与调试：让逻辑一目了然

代码写多了脑子容易乱。LangGraph 贴心地提供了将编译后的流程绘制成流程图的功Neng。这对于调试或者向老板展示你的架构设计非常有帮助。

# 执行图
result = graph.invoke
# 绘制 Mermaid 格式的流程图并保存
graph.get_graph.draw_mermaid_png

前面我们逐个学习了 LangGraph 的一些基础Neng力，比如 Reducers、Send、Interrupt、Command，今天又重点盘点了 Checkpoints 和 Subgraphs。其实LangGraph 的设计哲学就是通过组合简单的原语来构建复杂的智Neng体行为。掌握这些 API，就像是掌握了乐高积木的拼搭技巧，剩下的就是发挥你的想象力去创造属于你的 AI 应用了。geng多细节，建议大家多去翻翻官方文档或者在 GitHub 上找点实战案例跑一跑，毕竟代码才是Zui好的老师。

---