Agent Server 自动处理检查点
使用 Agent Server 时,您无需手动实现或配置检查点器。服务器会在后台为您处理所有持久化基础设施。
为什么使用检查点器
以下功能需要检查点器:- 人机交互:检查点器通过允许人类检查、中断和批准图步骤来促进人机交互工作流。这些工作流需要检查点器,因为人必须能够随时查看图的状态,并且在人对状态进行任何更新后,图必须能够恢复执行。有关示例,请参阅中断。
- 记忆:检查点器允许交互之间存在”记忆”。在重复的人类交互(如对话)的情况下,任何后续消息都可以发送到该线程,该线程将保留对先前消息的记忆。有关如何使用检查点器添加和管理对话记忆的信息,请参阅添加记忆。
- 时间旅行:检查点器允许进行”时间旅行”,允许用户重放先前的图执行以审查和/或调试特定的图步骤。此外,检查点器使得可以在任意检查点分叉图状态以探索替代轨迹成为可能。
- 容错性:检查点提供容错和错误恢复:如果在给定的超级步骤中一个或多个节点失败,您可以从上一个成功的步骤重新启动您的图。
- 待处理写入:当一个图节点在给定超级步骤执行过程中失败时,LangGraph 会存储该超级步骤中成功完成的其他任何节点的待处理检查点写入。当您从该超级步骤恢复图执行时,您不需要重新运行成功的节点。
核心概念
线程
线程是分配给检查点器保存的每个检查点的唯一 ID 或线程标识符。它包含一系列运行的累积状态。当执行一次运行时,助手底层图的状态将被持久化到该线程中。 使用检查点器调用图时,您必须在配置的configurable 部分指定一个 thread_id:
thread_id 作为存储和检索检查点的主键。没有它,检查点器无法保存状态或在中断后恢复执行,因为检查点器使用 thread_id 来加载已保存的状态。
检查点
线程在特定时间点的状态称为检查点。检查点是在每个超级步骤保存的图状态快照,由StateSnapshot 对象表示(有关完整字段参考,请参阅 StateSnapshot 字段)。
超级步骤
LangGraph 在每个超级步骤边界创建一个检查点。超级步骤是图的一次单独“滴答”,其中计划用于该步骤的所有节点(可能并行)执行。对于像START -> A -> B -> END 这样的顺序图,输入、节点 A 和节点 B 分别有单独的超级步骤——并在每个之后产生一个检查点。理解超级步骤边界对于时间旅行很重要,因为您只能从检查点(即超级步骤边界)恢复执行。
除了超级步骤检查点,LangGraph 还在节点(任务)级别持久化写入。当超级步骤中的每个节点完成时,其输出作为任务条目写入检查点器的 checkpoint_writes 表,并链接到进行中的检查点。这些每任务写入是待处理写入恢复的关键:如果同一超级步骤中的另一个节点失败,成功节点的写入已经持久化,在恢复时无需重新运行。然后,一旦超级步骤完成,就提交完整的状态快照。
LangGraph 还持久化超级步骤内单个节点执行的写入。这些写入作为任务存储,并用于容错:如果同一超级步骤中的另一个节点失败,当您恢复时,成功的节点写入不需要重新计算。这些任务写入不是完整的 StateSnapshot 检查点,因此时间旅行从超级步骤边界的完整检查点恢复。
检查点是持久化的,可用于在稍后时间恢复线程的状态。
让我们看看当调用如下简单图时会保存哪些检查点:
- 空检查点,
START为下一个要执行的节点 - 检查点包含用户输入
{'foo': '', 'bar': []}和node_a作为下一个要执行的节点 - 检查点包含
node_a的输出{'foo': 'a', 'bar': ['a']}和node_b作为下一个要执行的节点 - 检查点包含
node_b的输出{'foo': 'b', 'bar': ['a', 'b']}且没有下一个要执行的节点
bar 通道的值包含来自两个节点的输出,因为此示例中 bar 通道有一个归约器。
检查点命名空间
每个检查点都有一个checkpoint_ns(检查点命名空间)字段,用于标识它属于哪个图或子图:
""(空字符串):检查点属于父(根)图。"node_name:uuid":检查点属于作为给定节点调用的子图。对于嵌套子图,命名空间用|分隔符连接(例如"outer_node:uuid|inner_node:uuid")。
获取和更新状态
获取状态
与保存的图状态交互时,您必须指定一个线程标识符。您可以通过调用graph.get_state(config) 来查看图的_最新_状态。这将返回一个 StateSnapshot 对象,该对象对应于与配置中提供的线程 ID 关联的最新检查点,或者如果提供了检查点 ID,则对应于与该线程的检查点 ID 关联的检查点。
get_state 的输出将如下所示:
StateSnapshot 字段
获取状态历史
您可以通过调用graph.get_state_history(config) 来获取给定线程的完整图执行历史。这将返回与配置中提供的线程 ID 关联的 StateSnapshot 对象列表。重要的是,检查点将按时间顺序排列,最新的检查点 / StateSnapshot 将排在列表的第一位。
get_state_history 的输出将如下所示:
查找特定检查点
您可以过滤状态历史记录以查找匹配特定条件的检查点:重放
重放会重新执行来自先前检查点的步骤。使用先前的checkpoint_id 调用图,以重新运行该检查点之后的节点。检查点之前的节点将被跳过(其结果已保存)。检查点之后的节点将重新执行,包括任何 LLM 调用、API 请求或中断——在重放期间这些中断总是会重新触发。
有关重放过去执行的完整详细信息和代码示例,请参阅时间旅行。
更新状态
您可以使用update_state 编辑图状态。这会创建一个带有更新值的新检查点——它不会修改原始检查点。该更新被视为与节点更新相同:如果定义了归约器函数,值会通过归约器函数传递,因此带有归约器的通道会_累积_值而不是覆盖它们。
您可以选择指定 as_node 来控制该更新被视为来自哪个节点,这会影响接下来哪个节点执行。有关详细信息,请参阅时间旅行:as_node。
持久性模式
LangGraph 支持三种持久性模式,让您可以平衡性能和数据一致性。您可以在调用任何图执行方法时指定持久性模式:"exit":LangGraph 仅在图执行退出时(成功、出错或由于人机交互中断)持久化更改。这为长时间运行的图提供了最佳性能,但意味着中间状态不会被保存,因此您无法从系统故障(如进程崩溃)中恢复执行中的状态。"async":LangGraph 在下一步执行时异步持久化更改。这提供了良好的性能和持久性,但如果进程在执行期间崩溃,存在 LangGraph 不写入检查点的微小风险。"sync":LangGraph 在下一步开始之前同步持久化更改。这确保了 LangGraph 在继续执行之前写入每个检查点,以一些性能开销为代价提供了高持久性。
优化检查点存储
默认情况下,LangGraph 检查点在每个超级步骤写入每个状态通道的完整值。对于具有大量累积的长时间运行线程(例如多轮对话),这会随着时间的推移产生显著的存储增长。DeltaChannel 仅存储增量差异而不是完整的累积值,从而显著减少追加密集型通道的检查点大小。有关用法和存储与延迟的权衡,请参阅 DeltaChannel。
检查点器库
底层上,检查点是由符合BaseCheckpointSaver 接口的检查点器对象提供支持的。LangGraph 提供了几种检查点器实现,所有实现都通过独立的、可安装的库实现。
有关可用提供商,请参阅检查点器集成。
langgraph-checkpoint:检查点器保存器的基础接口 (BaseCheckpointSaver) 以及序列化/反序列化接口 (SerializerProtocol)。包含用于实验的内存检查点器实现 (InMemorySaver)。LangGraph 自带langgraph-checkpoint。langgraph-checkpoint-sqlite:使用 SQLite 数据库 (SqliteSaver/AsyncSqliteSaver) 的 LangGraph 检查点器实现。适用于实验和本地工作流。需要单独安装。langgraph-checkpoint-postgres:使用 Postgres 数据库 (PostgresSaver/AsyncPostgresSaver) 的高级检查点器,在 LangSmith 中使用。适用于在生产环境中使用。需要单独安装。langchain-azure-cosmosdb:使用 Azure Cosmos DB for NoSQL (CosmosDBSaverSync/CosmosDBSaver) 的 LangGraph 检查点器实现。适用于在 Azure 生产环境中使用。支持同步和异步操作,具有 Microsoft Entra ID 身份验证。需要单独安装。
检查点器接口
每个检查点器都符合BaseCheckpointSaver 接口并实现以下方法:
.put- 使用其配置和元数据存储一个检查点。.put_writes- 存储链接到检查点的中间写入(即待处理写入)。.get_tuple- 使用给定配置(thread_id和checkpoint_id)获取检查点元组。用于在graph.get_state()中填充StateSnapshot。.list- 列出匹配给定配置和过滤条件的检查点。用于在graph.get_state_history()中填充状态历史。
.ainvoke、.astream、.abatch 执行图),则将使用上述方法的异步版本(.aput、.aput_writes、.aget_tuple、.alist)。
要异步运行您的图,您可以使用
InMemorySaver,或 Sqlite/Postgres 检查点器的异步版本 — AsyncSqliteSaver / AsyncPostgresSaver 检查点器。序列化器
当检查点器保存图状态时,需要序列化状态中的通道值。这是使用序列化器对象完成的。langgraph_checkpoint 定义了 protocol 来实现序列化器,并提供了一个默认实现 (JsonPlusSerializer),可以处理多种类型,包括 LangChain 和 LangGraph 原语、日期时间、枚举等。
使用 pickle 进行序列化
默认序列化器 JsonPlusSerializer 在底层使用 ormsgpack 和 JSON,这不适用于所有类型的对象。
如果您想对当前 msgpack 编码器不支持的对象(如 Pandas 数据框)回退到 pickle,
可以使用 JsonPlusSerializer 的 pickle_fallback 参数:
加密
检查点器可以选择性地加密所有持久化的状态。要启用此功能,请将EncryptedSerializer 的实例传递给任何 BaseCheckpointSaver 实现的 serde 参数。创建加密序列化器最简单的方法是通过 from_pycryptodome_aes,它从 LANGGRAPH_AES_KEY 环境变量读取 AES 密钥(或接受 key 参数):
LANGGRAPH_AES_KEY,就会自动启用加密,因此您只需提供环境变量即可。可以通过实现 CipherProtocol 并将其提供给 EncryptedSerializer 来使用其他加密方案。
构建自定义检查点器
本节介绍如何从头开始为自定义存储后端实现BaseCheckpointSaver。如果您已经有一个工作的检查点器,只需要添加增量通道支持,请跳转到 Delta 通道支持。
概述
LangGraph 的持久层建立在两个存储抽象之上:- 检查点表 — 每个超级步骤一行;存储序列化的图状态(
channel_values、channel_versions、versions_seen)并链接到其父检查点。 - 写入表 — 超级步骤中每个节点输出一行;存储链接到检查点的
(task_id, channel, value)元组。
put 写入检查点行;put_writes 写入节点输出行;get_tuple 将两者读回到 CheckpointTuple。
基本契约
子类化BaseCheckpointSaver 并实现这五个方法。所有都是必需的 — 缺失的基础方法在运行时会引发 NotImplementedError。
put / aput
存储一行检查点。返回带有已存储checkpoint_id 的更新后的配置。
关键要求:
- 使用
self.serde.dumps_typed(checkpoint)序列化检查点 — 这会处理所有 LangGraph 原生类型,包括增量通道使用的_DeltaSnapshotblob。 - 完整存储
metadata— 不要删除未知的键。LangGraph 会在次要版本中添加新的元数据字段(例如用于增量通道的counters_since_delta_snapshot);静默地丢弃它们会破坏功能。 - 存储
config["configurable"].get("checkpoint_id")作为父检查点 ID,以便get_tuple可以填充parent_config。
put_writes / aput_writes
为当前超级步骤中的单个任务存储节点输出行。这些行通过(thread_id, checkpoint_ns, checkpoint_id) 链接到检查点。
langgraph.checkpoint.base 导入 WRITES_IDX_MAP。它将特殊通道(__error__、__interrupt__ 等)映射到保留的负索引,以避免与常规写入索引冲突。
get_tuple / aget_tuple
检索一个检查点。配置可能包含:- 没有
checkpoint_id— 返回线程 + 命名空间的最新检查点。 - 特定的
checkpoint_id— 返回该确切的检查点。
list / alist
返回线程的检查点,最新的在前。遵守before(仅返回比该配置的 checkpoint_id 更旧的检查点)和 limit。
delete_thread / adelete_thread
删除线程的所有检查点和写入。检查点行和写入行都必须被删除。行键/索引设计
您存储和索引检查点的方式直接影响正确性和性能。 推荐的模式(SQL):checkpoint_id 是 ULID,所以它是字典序可排序的 — 值越大越新。“获取最新” 是 ORDER BY checkpoint_id DESC LIMIT 1;“按 ID 获取” 是主键上的等值查找。
对于非 SQL 存储: 原则相同。无论您使用什么键方案,通过 (thread_id, checkpoint_ns, checkpoint_id) 的直接查找必须是 O(1) 或接近 O(1)。避免设计为唯一通过 ID 查找检查点的方法是扫描线程的所有行。
序列化
对于检查点、写入和元数据,请始终使用self.serde(从 BaseCheckpointSaver 继承,默认为 JsonPlusSerializer)。不要直接对元数据使用 pickle — 它可以工作,但 JsonPlusSerializer 产生人类可读的输出并且更好地处理版本控制。
JsonPlusSerializer 自动处理所有 LangGraph 原生类型:
_DeltaSnapshot— 增量通道使用的哨兵 blob(msgpack 扩展代码 7)- Pydantic v2 模型、数据类、numpy 数组、日期时间、枚举等
langgraph.checkpoint.serde.types 往返处理 _DeltaSnapshot。
扩展能力
这些方法是可选的,但可以解锁额外的 Agent Server 功能。如果您的存储后端可以高效地支持它们,请实现它们。
Agent Server 在启动时自动检测您的检查点器实现了哪些功能,并激活相应的功能。
Delta 通道支持
DeltaChannel 目前处于测试阶段。 API 和磁盘表示形式在设计稳定之前可能会发生变化。
DeltaChannel 是一个归约器通道,它在检查点 blob 中只存储一个哨兵 (MISSING),而不是完整的通道值。状态通过在归约器中重放祖先写入来重建。这使得检查点 blob 的大小从 O(N)(对于像 messages 这样随时间累积的通道)变为每步 O(1)。
运行时需要什么
当加载一个其增量通道在channel_values 中缺失的检查点时,LangGraph 调用 saver.get_delta_channel_history(config=config, channels=[...])。这为每个通道返回:
writes— 祖先链中对该通道的所有写入,按从旧到新的顺序,直到最近的快照。seed(可选)— 在最近一个具有_DeltaSnapshotblob 的祖先处存储的 blob;如果遍历到达根节点仍未找到快照,则缺失。
channel.from_checkpoint(seed) 和 channel.replay_writes(writes) 来重建实时值。
默认实现
BaseCheckpointSaver 提供了一个默认的 get_delta_channel_history,可与任何正确的 get_tuple 实现一起工作:
get_tuple(cursor) 总是使用特定的 checkpoint_id(父项的 ID)调用。如果该查找返回 None,则遍历立即停止,每个增量通道都重建为空 — 静默地,没有错误。这就是为什么 get_tuple 中的特定 ID 路径必须正确。
性能覆盖
默认的遍历会对每个祖先检查点调用一次get_tuple。对于具有良好查询支持的后端,请覆盖 get_delta_channel_history(及其异步版本),以便在两次查询中检索祖先链和写入:
带有增量通道的裁剪
DeltaChannel 的状态并非自包含在单个检查点中——它依赖于回溯到最近 _DeltaSnapshot 的祖先写入链。如果你实现了 prune 或 delete_for_runs,你绝不能删除某个存活检查点的增量通道所依赖的写入行。
安全选项:
- 裁剪前先遍历 — 对于你打算保留的每个检查点,遍历其祖先链,并将直到最近
_DeltaSnapshot的所有写入行标记为不可删除。 - 裁剪前强制生成快照 — 在你保留的检查点上重写
channel_values[ch] = _DeltaSnapshot(reconstructed_value),然后即可自由删除祖先项。 - 跳过对增量通道线程的裁剪 — 如果你暂不需要裁剪功能,这是最安全的短期选项。
带有增量通道的线程复制
在实现copy_thread 时,要复制完整的祖先链——而不仅仅是头检查点。目标线程必须为每个增量通道拥有至少回溯到一个 _DeltaSnapshot 的写入行,否则在复制后这些通道将重建为空。
使用一致性测试套件进行测试
langgraph-checkpoint-conformance 可根据完整规范(包括增量通道历史)来验证你的实现:
aget_delta_channel_history),并针对每项能力运行相关测试。请在发布前将其作为持续集成的一部分来运行。
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

