8.0
热点
AI SCORE
编程提效2026-08-17 04:02
Agent的State、Memory、Checkpointing不是一回事
dev.to · AI#AI Agent#架构#状态管理
Editor brief · 编辑速览
三者虽常被混用，但State是执行时刻的快照，Memory是跨任务的信息保留机制，Checkpointing是用于恢复的持久化状态；框架通常将它们有意关联但不可互换。
当我在让 Agent 进行编排、恢复执行或做其他任何操作时，发现自己会自然地想到我们人类自身是如何处理这些事的。我们注册信息、保留一些、遗忘一些、回忆重要的内容，然后还能从中断处继续。就是在尝试让 Agent 做类似事情的过程中，我反复遇到三个术语：state（状态）、memory（记忆）和 checkpointing（检查点）。我单独理解每个概念都不难，但在构建工作流并让它们持久化的过程中，这三者的边界开始变得模糊。接触得越多，我就越意识到区分它们很重要。所以让我从最简单的方式开始，把它们拆解开来。
让我们把它们梳理清楚。
当 AI Agent 记住用户的名字、恢复中断的任务，或者知道刚才调用了哪个工具时，我们通常会说这个 Agent "有记忆"。
但这一个词背后隐藏着多种不同的机制。
State、memory 和 checkpointing 密切相关，一些框架也有意将它们关联起来。然而，它们并不能互换使用。
一个简单的起始思路是：
区分它们很重要，因为每个解决的是不同的问题。
State 是贯穿 Agent 执行过程携带的数据。
例如：
以一个旅行规划 Agent 为例。它的 state 在概念上可能是这样的：
state = {
"messages": [...],
"destination": "Jaipur",
"travel_dates": {
"start": "2026-11-04",
"end": "2026-11-10"
},
"budget": 40000,
"flight_options": [...],
"hotel_search_completed": False,
"waiting_for_user_approval": True
}
这不一定是 memory。它只是描述和继续当前工作流所需的数据。
State 也不一定只存在于 LLM 的 context window 中。它可以保存在应用内存、数据库、工作流引擎或其他持久化系统中。
LLM 被调用时，可能只收到该 state 的选定部分。State 随着 Agent 工作而变化。一个 Agent 可以被看作一个反复执行状态转换的系统：
Current state → Agent step → Updated state
未选择目的地
↓
已选择目的地
↓
已获取航班信息
↓
等待用户审批
↓
预订确认
每次工具调用、模型响应、人类决策或工作流规则都可能更新 state。
因此，state 回答的问题是：这个 Agent 执行此刻处于什么位置，它目前拥有哪些数据？
Memory 是从过去保留的信息，以便影响未来的行为。
这个定义是故意写得宽泛的。Agent memory 不是某个特定的数据库或框架功能。它是一种能力，可以通过多种方式实现。
Memory 通常分为两个作用域。
Short-term memory 在同一对话或执行线程内保持连续性。
例如：
假设用户说："我想十一月去 Jaipur。"过了几条消息后，他们问："你能帮我找那里的酒店吗？"短期记忆让 Agent 理解"那里"指的是 Jaipur。在 LangGraph 等系统中，短期记忆作为线程 state 的一部分进行维护，并通过检查点持久化。
Long-term memory 超越单个对话或执行线程而存在。
例如：
user_memory = {
"user_id": "user_42",
"preferred_airline": "Air India",
"meal_preference": "vegetarian",
"prefers_direct_flights": True
}
即使新的旅行规划对话始于不同的线程，它也能获取这些记忆。
因此，长期记忆回答的问题是：Agent 应该从过去保留什么信息并在将来再次使用？
Memory 需要选择。系统不应该将每个历史细节都视为同等有用的记忆。
实用的 memory 系统需要制定以下策略：
完整的 transcript 是历史数据。只有当系统能够在正确的时刻将相关部分提供出来时，它才成为有用的 agent memory。
检查点是在特定时刻的执行状态的持久化表示。Checkpointing 使系统能够恢复或继续执行，而无需重新启动整个工作流。
假设我们的旅行 Agent 已经完成了以下步骤：
如果流程在等待用户时停止，检查点可以保存第四步之后达到的状态。当用户返回时，应用可以恢复该状态并从审批步骤继续，而无需再次搜索航班。
Checkpointing 可以支持：
特别是在 LangGraph 中，检查点保存器在执行步骤处保存图状态的快照，并将其组织成线程。这些检查点支持容错、人工干预、状态历史、回放和线程级对话连续性等功能。
Checkpointing 回答的问题是：系统如何保存执行到达的位置并从那里继续？
让我们在旅行 Agent 找到航班选项后暂停一下。
{
"destination": "Jaipur",
"dates": ["2026-11-04", "2026-11-10"],
"flight_options": [...],
"current_step": "awaiting_approval"
}
这描述的是当前执行状态。
{
"prefers_direct_flights": True,
"meal_preference": "vegetarian"
}
这是保留的信息，可用于此次及未来的旅行对话。
Thread: trip-planning-781
Checkpoint: step-4
Saved state: awaiting approval
Saved at: 2026-08-15T10:30:00Z
这是一个持久化的执行快照，工作流可以从中恢复。
它们的关系可以总结如下：
在这篇博客中，我介绍了 state、memory 和 checkpointing，以及它们如何不同——尽管它们在 Agent 系统中经常一起出现且容易混淆。目前最简单记住的区分方式是：
但这只是第一层。
在下一篇博客中，我想介绍这些边界开始模糊的地方：Checkpointing 如何实现短期记忆、为什么检查点不等于长期记忆、应用 state 与 LLM context 的区别，以及什么真正应该存在哪里。
未完待续。Mahak