LangGraph 状态管理详解：让AI Agent具备“上下文延续性”

关键词：LangGraph、状态管理、AI Agent、上下文延续性、多智能体协作、检查点机制、记忆系统
摘要：当前AI Agent在处理长周期、多步骤任务时普遍存在「上下文断档」问题：做旅游规划时忘了用户带宠物的需求、写代码时忘了原始需求的边界、客服对话时让用户重复描述已经说过的问题。本文将从小白也能懂的生活类比出发，拆解LangGraph状态管理的核心原理、算法逻辑、实现方案，通过完整的项目实战教你如何用LangGraph的状态机制让AI Agent拥有「过目不忘」的能力，实现真正的上下文延续。全文覆盖从概念到落地的全流程，适合所有大模型应用开发者、AI Agent爱好者阅读。

---

背景介绍

目的和范围

你有没有遇到过这种情况：让ChatGPT帮你做一份3天的上海旅游攻略，你特意提了「带宠物、预算5000、要住外滩附近」，结果它做攻略的时候给你推荐了禁止宠物入内的酒店，你提醒它之后它还得让你再重复一遍出发时间、人数这些已经说过的信息？
这就是典型的无状态Agent的痛点：所有上下文都依赖LLM的上下文窗口，要么窗口不够大丢了信息，要么多步骤处理的时候把关键信息忘了。而LangGraph的状态管理就是专门解决这个问题的核心机制。
本文的目的是把LangGraph状态管理的底层逻辑、使用方法、最佳实践讲透，你看完之后不仅能理解状态管理的本质，还能独立开发出具备上下文延续性的AI Agent应用。本文不涉及太复杂的底层源码，重点关注应用层的原理和实战。

预期读者

1. 有基础Python能力，想要开发AI Agent应用的开发者
2. 已经在用LangChain，但遇到上下文丢失问题的大模型应用开发者
3. 对多智能体协作感兴趣的技术爱好者
4. 想要优化LLM应用用户体验的产品经理

文档结构概述

本文先从生活故事引入核心概念，再拆解状态管理的三大核心组件（State、Reducer、Checkpoint）的原理和关系，接着讲核心算法和数学模型，再通过完整的旅游规划Agent实战带你写可运行的代码，最后讲实际应用场景、最佳实践和未来发展趋势。

术语表

核心术语定义

1. LangGraph：LangChain团队推出的用于构建状态化、多角色、可循环的AI Agent的开发框架，是当前工业界最主流的Agent开发框架之一
2. 状态（State）：存储AI Agent运行过程中所有信息的「共享笔记本」，所有节点都可以读写
3. Reducer：状态的更新规则，相当于「笔记本的填写规范」，避免信息被乱改或者覆盖
4. 检查点（Checkpoint）：状态的历史快照，相当于「笔记本每写一页就拍一张照片」，支持断点续跑和历史回溯
5. 上下文延续性：Agent在多轮对话、多步骤处理过程中，能记住所有历史信息，不需要用户重复输入的能力

缩略词列表

• LLM：大语言模型（Large Language Model）
• RAG：检索增强生成（Retrieval Augmented Generation）
• Agent：具备自主决策、执行能力的大模型应用

---

核心概念与联系

故事引入

我们拿奶茶店点单的场景来类比：
你去奶茶店点单，第一次说「要一杯珍珠奶茶，三分糖，少冰」，店员把这些信息写在一个专属你的点单小本本上。过了2分钟你又跑回去说「再加一份椰果，不要珍珠了」，店员不需要你再重复说三分糖少冰的要求，直接在小本本上修改就行。中途如果这个店员去吃饭，换了一个新店员来，他只要看一眼小本本上的内容，就知道你的所有需求，不会出错。最后你拿到的奶茶就是符合你所有要求的。
这个场景里：

• 专属你的点单小本本 = LangGraph的State
• 店员修改小本本的规则（加配料就追加、改糖度就覆盖）= Reducer
• 小本本上写的所有内容 = 上下文
• 就算换店员也不会丢信息 = 上下文延续性
• 每写完一笔就给小本本拍个照存起来 = Checkpoint机制

核心概念解释

核心概念一：State（状态）

State就是AI Agent的「共享记忆本」，所有和任务相关的信息都存在这里：用户的历史对话、提取的用户偏好、中间步骤的执行结果、最终输出内容等等。
和你自己定义的Python字典不一样，LangGraph的State是结构化、有更新规则、多节点共享的：比如你做旅游Agent，State里可以定义user_preferences（用户偏好）、flight_info（机票信息）、hotel_info（酒店信息）、messages（对话历史）四个字段，每个节点只能修改自己负责的字段，不会乱改其他字段。

核心概念二：Reducer（更新规则）

Reducer就是「记忆本的填写规范」，决定了新产生的信息怎么更新到State里。
比如对话历史messages字段，我们希望每次新产生的对话是追加到列表后面，而不是覆盖原来的内容，就可以用operator.add作为Reducer；比如用户预算budget字段，我们希望新的预算直接覆盖旧的，就用默认的覆盖Reducer；比如累计消费金额total_cost字段，我们希望每次新产生的消费是累加到原来的金额上，就可以自定义一个累加的Reducer。
如果没有Reducer，你自己维护字典的话很容易出现不小心覆盖了历史消息、或者多节点同时写的时候出现冲突的问题，Reducer从机制上避免了这些问题。

核心概念三：Checkpoint（检查点）

Checkpoint就是「记忆本的快照」，每执行完一个节点的操作，LangGraph就会自动把当前的State存下来，相当于给记忆本拍了一张照片。
Checkpoint的作用非常大：

1. 断点续跑：如果Agent跑长任务的时候中途崩溃了，不需要从头开始跑，直接从最近的Checkpoint恢复就行
2. 多用户隔离：每个用户的状态用唯一的thread_id标识，不同用户的状态不会串
3. 历史回溯：如果你对某一步的结果不满意，可以回到任意一个Checkpoint的状态，重新执行后面的步骤
4. 持久化存储：Checkpoint可以存在SQLite、Redis、PostgreSQL等数据库里，就算服务重启，用户的状态也不会丢

核心概念四：上下文延续性

上下文延续性是最终的效果：Agent不管跑多少步、换多少个节点处理、甚至服务重启之后，都能记住用户所有的历史信息，不需要用户重复输入。
这个能力是State+Reducer+Checkpoint三者配合实现的：State存所有信息，Reducer保证信息正确更新，Checkpoint保证信息不丢失。

核心概念之间的关系

我们先看一个核心概念属性对比表：

概念	作用	类比	核心特性
State	存储所有运行时信息	点单小本本	结构化、多节点共享
Reducer	定义状态更新规则	小本本填写规范	可自定义、避免更新冲突
Checkpoint	存储状态的历史快照	小本本的照片	可持久化、支持回溯、多用户隔离
上下文延续性	最终效果	不用重复说需求	长周期记忆、无感知

概念之间的交互逻辑

1. State和Reducer的关系：Reducer是State的「附属规则」，每个State字段都可以绑定自己的Reducer，所有对State的修改都必须经过Reducer处理，避免脏写。就像你改小本本上的内容必须按照规范来，不能随便乱涂乱画。
2. State和Checkpoint的关系：Checkpoint是State的「快照备份」，每更新一次State就生成一个Checkpoint，State是当前的最新内容，Checkpoint是所有历史版本的内容。就像你每写一页小本本就拍一张照，所有照片加起来就是小本本的完整历史。
3. Reducer和Checkpoint的关系：Reducer处理完更新生成新的State之后，Checkpoint才会保存新的快照，保证所有保存的快照都是符合更新规则的有效状态。

核心概念原理和架构的文本示意图

[用户输入] → [初始State生成] → [Reducer校验更新] → [最新State]
                                                  ↓
                                          [Checkpoint持久化]
                                                  ↓
[节点1执行] ← [读取State] ← [路由判断] ← [Checkpoint恢复状态]
    ↓
[节点1返回更新内容] → [Reducer合并更新] → [新State] → [Checkpoint保存]
                                                  ↓
                                          [路由判断下一步]
                                                  ↓
[节点N执行] ← ... 重复上述流程 ... ← [判断是否结束] → [输出结果]

Mermaid 架构图

Mermaid 状态流转流程图

---

核心算法原理 & 具体操作步骤

状态定义算法

LangGraph的State是通过Python的TypedDict或者Pydantic定义的，你可以给每个字段加上Annotated标记来绑定Reducer。
核心代码示例：

from typing import TypedDict, Annotated, List
from langchain_core.messages import BaseMessage
import operator

# 定义State
class AgentState(TypedDict):
    # messages字段绑定operator.add作为Reducer，每次更新是追加消息
    messages: Annotated[List[BaseMessage], operator.add]
    # 用户偏好字段默认是覆盖更新
    user_preferences: dict
    # 累计消费字段自定义累加Reducer
    total_cost: Annotated[int, lambda old, new: old + new]

状态定义的核心规则

1. 字段类型必须明确：方便LangGraph做类型校验，避免非法值写入
2. 必要字段绑定Reducer：根据业务需求选择追加、覆盖、累加等更新规则
3. 尽量扁平化设计：不要嵌套太深的结构，方便Reducer更新和后续读取

Reducer核心算法

Reducer的本质是一个函数，输入是旧的状态值和新的更新值，输出是合并后的新值。
默认的Reducer规则：

1. 没有显式绑定Reducer的字段：新值直接覆盖旧值
2. 绑定了operator.add的字段：如果是列表就追加，如果是数字就相加
3. 自定义Reducer：按照你定义的函数逻辑合并
   核心代码示例（自定义Reducer）：

# 自定义Reducer：只保留最近10条消息，避免上下文过长
def keep_last_10_messages(old: List[BaseMessage], new: List[BaseMessage]) -> List[BaseMessage]:
    return (old + new)[-10:]

# 绑定自定义Reducer
class AgentState(TypedDict):
    messages: Annotated[List[BaseMessage], keep_last_10_messages]
    user_preferences: dict

Checkpoint核心算法

Checkpoint的核心是用thread_id来隔离不同用户的状态，每执行完一个节点就把当前的State序列化存到持久化介质里。
核心运行逻辑：

1. 每次调用Agent的时候传入config={"configurable": {"thread_id": "用户唯一ID"}}
2. LangGraph根据thread_id从Checkpoint数据库里读取最新的State作为初始状态
3. 执行完节点更新State之后，自动生成新的Checkpoint存到数据库
4. 如果服务重启，只要传入相同的thread_id，就能恢复之前的状态
   核心代码示例（配置Checkpoint）：

from langgraph.checkpoint.sqlite import SqliteSaver
import sqlite3

# 连接SQLite数据库存Checkpoint
conn = sqlite3.connect("checkpoint.db", check_same_thread=False)
checkpointer = SqliteSaver(conn)

# 编译工作流的时候传入checkpointer
app = workflow.compile(checkpointer=checkpointer)

---

数学模型和公式 & 详细讲解

状态更新模型

状态的更新过程可以用下面的公式表示：
$$S_{t+1}=R(S_t,{\Delta }_t)$$
其中：

• $S_t$ 表示t时刻的状态值
• ${\Delta }_t$ 表示t步骤节点返回的更新内容
• $R$ 表示对应字段的Reducer函数
• $S_{t+1}$ 表示更新后的新状态值

举个例子：如果$S_t$的messages字段是[msg1, msg2]，${\Delta }_t$的messages字段是[msg3]，$R$是operator.add，那么$S_{t+1}$的messages字段就是[msg1, msg2, msg3]。

检查点存储模型

检查点的存储模型可以用下面的公式表示：
$$C_k(threa{d}_{i}d)=S_{t_k}(threa{d}_{i}d)$$
其中：

• $C_k(threa{d}_{i}d)$ 表示某个thread_id对应的第k个检查点
• $S_{t_k}(threa{d}_{i}d)$ 表示该thread_id在$t_k$时刻的状态值
• 同一个thread_id的所有检查点按时间戳排序，最新的检查点就是当前的最新状态

上下文窗口优化模型

为了避免状态里的消息太多超过LLM的上下文窗口，我们可以自定义Reducer做消息截断，公式如下：
$$S_{t+1}.messages=(S_t.messages+{\Delta }_t.messages)[-N:]$$
其中N是你要保留的最近消息条数，比如N=10就只保留最近10条消息，既保证了最近的上下文不会丢，又不会超过LLM的上下文窗口。

项目实战：旅游规划Agent实现

我们来做一个具备上下文延续性的旅游规划Agent，用户可以随时补充需求，Agent不会忘记之前的要求，服务重启之后也能恢复之前的规划进度。

开发环境搭建

先安装需要的依赖包：

pip install langgraph langchain-openai python-dotenv sqlite3

然后在.env文件里配置你的OpenAI API Key：

OPENAI_API_KEY=你的API Key

源代码详细实现

import os
import json
import sqlite3
from typing import TypedDict, Annotated, List
from dotenv import load_dotenv
from langchain_core.messages import BaseMessage, HumanMessage, AIMessage, SystemMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.sqlite import SqliteSaver
import operator

# 加载环境变量
load_dotenv()
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# --------------------------
# 1. 定义State和Reducer
# --------------------------
def keep_last_20_messages(old: List[BaseMessage], new: List[BaseMessage]) -> List[BaseMessage]:
    """自定义Reducer：只保留最近20条消息，避免上下文过长"""
    return (old + new)[-20:]

class TravelState(TypedDict):
    messages: Annotated[List[BaseMessage], keep_last_20_messages]
    user_preferences: dict # 存储用户的旅游偏好：出发地、目的地、时间、预算、特殊要求等
    flight_info: dict # 存储查询到的机票信息
    hotel_info: dict # 存储查询到的酒店信息
    itinerary: str # 存储最终生成的行程

# --------------------------
# 2. 定义各个节点的逻辑
# --------------------------
def collect_preferences(state: TravelState):
    """收集用户偏好的节点，判断信息是否齐全，不全的话提示用户补充"""
    messages = state["messages"]
    system_prompt = """
    你是专业的旅游规划助理，需要从用户的对话中提取以下旅游偏好信息：
    1. 出发城市
    2. 目的地城市
    3. 出发日期
    4. 旅游天数
    5. 出行人数
    6. 总预算
    7. 特殊要求（比如带宠物、要海景房、忌口等等）
    如果以上信息都收集齐全了，返回json格式，包含is_complete: true和所有偏好字段；
    如果有信息缺失，返回自然语言提示用户补充缺失的信息，不需要返回json。
    """
    response = llm.invoke([SystemMessage(content=system_prompt), *messages])
    # 尝试解析返回的json
    try:
        preferences = json.loads(response.content)
        if preferences.get("is_complete"):
            return {"user_preferences": preferences, "messages": [AIMessage(content="好的，我已经收集齐你的需求了，现在帮你查机票~")]}
    except:
        return {"messages": [response]}

def search_flight(state: TravelState):
    """查询机票的节点，模拟调用机票接口"""
    pref = state["user_preferences"]
    # 模拟接口返回
    flight_info = {
        "departure": pref["departure_city"],
        "destination": pref["destination_city"],
        "date": pref["departure_date"],
        "price": 1200,
        "airline": "中国国航",
        "departure_time": "08:00",
        "arrival_time": "10:30"
    }
    msg = f"已为你查询到符合要求的机票：{flight_info['airline']} {flight_info['departure_time']} - {flight_info['arrival_time']}，价格{flight_info['price']}元"
    return {"flight_info": flight_info, "messages": [AIMessage(content=msg)]}

def search_hotel(state: TravelState):
    """查询酒店的节点，模拟调用酒店接口，会考虑用户的特殊要求"""
    pref = state["user_preferences"]
    special_request = pref.get("special_request", "")
    # 模拟接口返回，会包含特殊要求的匹配
    hotel_info = {
        "name": "外滩观景酒店",
        "price": 800 * pref["travel_days"],
        "address": "上海外滩附近",
        "facilities": "允许宠物入住、外滩观景窗、免费早餐" if "带宠物" in special_request else "外滩观景窗、免费早餐"
    }
    msg = f"已为你查询到符合要求的酒店：{hotel_info['name']}，总价{hotel_info['price']}元，{'允许宠物入住' if '带宠物' in special_request else ''}"
    return {"hotel_info": hotel_info, "messages": [AIMessage(content=msg)]}

def generate_itinerary(state: TravelState):
    """生成最终行程的节点"""
    pref = state["user_preferences"]
    flight = state["flight_info"]
    hotel = state["hotel_info"]
    system_prompt = f"""
    根据以下信息生成一份详细的{pref['travel_days']}天旅游行程：
    用户偏好：{json.dumps(pref, ensure_ascii=False)}
    机票信息：{json.dumps(flight, ensure_ascii=False)}
    酒店信息：{json.dumps(hotel, ensure_ascii=False)}
    行程要合理安排每天的景点、餐饮、交通，总预算不要超过用户的要求。
    """
    response = llm.invoke([SystemMessage(content=system_prompt)])
    return {"itinerary": response.content, "messages": [AIMessage(content=response.content)]}

# --------------------------
# 3. 定义路由逻辑
# --------------------------
def route(state: TravelState):
    """判断下一步该执行哪个节点"""
    # 没有收集齐偏好就继续收集
    if not state.get("user_preferences") or not state["user_preferences"].get("is_complete"):
        return "collect_preferences"
    # 没查机票就查机票
    if not state.get("flight_info"):
        return "search_flight"
    # 没查酒店就查酒店
    if not state.get("hotel_info"):
        return "search_hotel"
    # 没生成行程就生成行程
    if not state.get("itinerary"):
        return "generate_itinerary"
    # 都完成了就结束
    return END

# --------------------------
# 4. 构建工作流
# --------------------------
workflow = StateGraph(TravelState)
# 添加节点
workflow.add_node("collect_preferences", collect_preferences)
workflow.add_node("search_flight", search_flight)
workflow.add_node("search_hotel", search_hotel)
workflow.add_node("generate_itinerary", generate_itinerary)
# 设置入口节点
workflow.set_entry_point("collect_preferences")
# 添加条件边
workflow.add_conditional_edges("collect_preferences", route)
workflow.add_conditional_edges("search_flight", route)
workflow.add_conditional_edges("search_hotel", route)
workflow.add_conditional_edges("generate_itinerary", route)
# 配置Checkpoint持久化
conn = sqlite3.connect("travel_agent.db", check_same_thread=False)
checkpointer = SqliteSaver(conn)
# 编译工作流
app = workflow.compile(checkpointer=checkpointer)

# --------------------------
# 5. 测试运行
# --------------------------
if __name__ == "__main__":
    # 每个用户对应唯一的thread_id，这里用用户ID作为thread_id
    config = {"configurable": {"thread_id": "user_001"}}
    print("=== 旅游规划助手上线啦，输入你的需求吧 ===")
    while True:
        user_input = input("你：")
        if user_input == "exit":
            break
        # 调用Agent
        response = app.invoke({"messages": [HumanMessage(content=user_input)]}, config=config)
        # 输出最新的回复
        print("助手：", response["messages"][-1].content)

代码解读与分析

1. State设计：我们定义了5个字段，其中messages字段绑定了自定义的Reducer只保留最近20条消息，避免上下文过长。
2. 节点逻辑：每个节点只负责自己的任务，只修改自己对应的字段，比如search_hotel节点只会修改hotel_info和messages字段，不会碰user_preferences字段，避免脏写。
3. Checkpoint配置：我们用SQLite存储检查点，就算你关掉程序重新运行，只要用同一个thread_id，就能恢复之前的所有状态，不需要用户重新输入需求。
4. 上下文延续性验证：你可以先输入「我下周五从北京去上海玩3天，预算5000」，等助手问你有没有特殊要求的时候再输入「我带宠物，要住能看外滩的酒店」，助手会自动把这些信息加到用户偏好里，查酒店的时候会优先选允许宠物入住的，不会忘记之前的需求。

---

实际应用场景

1. 智能客服系统

客服Agent可以用状态管理存储用户的所有历史咨询记录、订单信息、投诉记录等，用户下次咨询的时候不需要重复说自己的订单号、之前遇到的问题，客服Agent直接从状态里就能拿到所有信息，大大提升用户体验。

2. 多智能体协作系统

比如内容生产多智能体：策划Agent负责写大纲，写手Agent负责写内容，校对Agent负责改错别字，运营Agent负责加标签。所有信息都存在State里，每个Agent都能拿到之前的产出，不需要互相传文件，也不会丢信息。

3. 长周期任务Agent

比如代码开发Agent，需要先拆解需求，再写代码，再单测，再改Bug，整个流程可能跑几个小时。用Checkpoint机制可以实现断点续跑，中途哪怕服务器崩溃了，重启之后从最近的检查点恢复就行，不用从头开始跑。

4. 个人助理Agent

个人助理可以用状态存储用户的所有习惯：比如喜欢喝半糖咖啡、每天早上需要看天气预报、每周五要开周会等等。助理会根据这些习惯自动安排日程，不需要用户每次重复说。

工具和资源推荐

1. 官方文档：LangGraph State Management 官方文档，最权威的原理讲解
2. 可视化调试工具：LangSmith，可以看到每一步状态的变化、节点的输入输出，非常适合调试Agent
3. Checkpoint持久化插件：langgraph-checkpoint-redis、langgraph-checkpoint-postgres，支持把检查点存在Redis或者PostgreSQL里，适合生产环境
4. 开源项目参考：LangGraph官方示例库，里面有很多基于状态管理的Agent实现，比如客户服务Agent、代码Agent等等

---

未来发展趋势与挑战

发展历史时间表

时间	发展阶段	核心特性
2023年之前	无状态Agent时代	所有上下文依赖LLM窗口，容易丢失信息，不支持长任务
2023年中	LangGraph首次发布	自带State和Reducer机制，首次实现结构化状态管理
2024年初	Checkpoint机制发布	支持状态持久化、断点续跑、多用户隔离
2024年中	多智能体状态共享发布	支持多个Agent共享同一个State，跨Agent协作
2025年（预测）	智能状态压缩发布	自动压缩不相关的历史状态，支持更长周期的记忆
2026年（预测）	跨设备状态同步	支持手机、电脑、智能家居多端同步Agent状态

面临的挑战

1. 状态压缩问题：长周期任务的状态会越来越大，怎么在不丢失关键信息的前提下压缩状态，降低LLM推理成本是当前的核心挑战
2. 状态安全问题：状态里会存储用户的隐私信息，怎么加密存储、怎么防止越权访问是生产环境要解决的问题
3. 状态冲突问题：多智能体同时写同一个State的时候怎么解决冲突，避免信息被覆盖
4. 边缘端状态管理：离线运行的边缘Agent怎么在本地管理状态，和云端同步的时候怎么解决冲突

---

总结：学到了什么？

核心概念回顾

1. State：Agent的共享记忆本，存储所有运行时信息，结构化设计，多节点共享
2. Reducer：记忆本的填写规范，定义状态的更新规则，避免脏写和冲突
3. Checkpoint：记忆本的快照，支持持久化、断点续跑、多用户隔离、历史回溯
4. 上下文延续性：三者配合实现的最终效果，Agent不会忘记历史信息，不需要用户重复输入

概念关系回顾

State是核心存储，Reducer定义State的更新规则，Checkpoint保存State的历史快照，所有Agent节点通过读写State共享信息，实现上下文的无缝延续。和自己用字典存上下文相比，LangGraph的状态管理从机制上避免了更新冲突、信息丢失、多用户串状态等问题，大大降低了开发复杂Agent的成本。

思考题：动动小脑筋

1. 如果你要做一个外卖配送Agent，需要在State里存哪些字段？每个字段对应的Reducer应该怎么设计？
2. 如果你要开发一个需要跑10个小时的论文写作Agent，怎么用Checkpoint机制实现断点续跑？如果中途你对某一部分的内容不满意，怎么回到之前的检查点重新生成？

---

附录：常见问题与解答

Q1：LangGraph的状态和我自己用Python字典存上下文有什么区别？

A：自己用字典存上下文有几个问题：①没有更新规则，很容易不小心覆盖历史信息；②不支持持久化，服务重启就丢了；③不支持多用户隔离，容易串状态；④不支持历史回溯，不能回到之前的状态重新跑。LangGraph的状态管理解决了所有这些问题。

Q2：状态里的消息太多超过LLM的上下文窗口怎么办？

A：可以自定义Reducer只保留最近的N条消息，或者把历史消息存在RAG向量数据库里，需要的时候再检索相关的历史信息，不要全量放到LLM的上下文里。

Q3：多智能体场景下怎么防止某个Agent乱改其他Agent负责的字段？

A：可以给不同的Agent设置字段级别的读写权限，比如查机票的Agent只能改flight_info字段，不能改user_preferences字段，LangGraph的自定义Reducer可以实现这个能力。

扩展阅读 & 参考资料

1. LangGraph 官方状态管理文档
2. LangGraph Checkpoint 官方教程
3. Stateful LLM Applications: A Survey
4. LangGraph 多智能体协作最佳实践

（全文完，字数约9800字）