持久化¶
LangGraph 有一个内置的持久化层,通过检查点器(checkpointer)实现。当你使用检查点器编译图时,检查点器会在每个超步(super-step)保存图状态的一个 检查点
。这些检查点会保存到一个 线程
中,在图执行完成后可以访问该 线程
。由于 线程
允许在执行完成后访问图的状态,因此包括人工介入、记忆、时间回溯和容错在内的多种强大功能都成为可能。有关如何为你的图添加和使用检查点器的端到端示例,请参阅此操作指南。下面,我们将更详细地讨论这些概念。
LangGraph API 会自动处理检查点操作
使用 LangGraph API 时,你无需手动实现或配置检查点器。API 会在幕后为你处理所有持久化基础设施。
线程¶
线程是一个唯一的 ID 或线程标识符,由检查点保存器为每个保存的检查点分配。当使用检查点保存器调用图时,你**必须**在配置的 configurable
部分指定一个 thread_id
:
检查点¶
检查点是在每个超级步骤保存的图状态的快照,由 StateSnapshot
对象表示,该对象具有以下关键属性:
config
:与此检查点关联的配置。metadata
:与此检查点关联的元数据。values
:此时状态通道的值。next
:图中接下来要执行的节点名称的元组。tasks
:PregelTask
对象的元组,包含有关接下来要执行的任务的信息。如果之前尝试过该步骤,它将包含错误信息。如果图在节点内部被动态地中断,任务将包含与中断相关的额外数据。
让我们看看当按如下方式调用一个简单的图时会保存哪些检查点:
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver
from typing import Annotated
from typing_extensions import TypedDict
from operator import add
class State(TypedDict):
foo: str
bar: Annotated[list[str], add]
def node_a(state: State):
return {"foo": "a", "bar": ["a"]}
def node_b(state: State):
return {"foo": "b", "bar": ["b"]}
workflow = StateGraph(State)
workflow.add_node(node_a)
workflow.add_node(node_b)
workflow.add_edge(START, "node_a")
workflow.add_edge("node_a", "node_b")
workflow.add_edge("node_b", END)
checkpointer = InMemorySaver()
graph = workflow.compile(checkpointer=checkpointer)
config = {"configurable": {"thread_id": "1"}}
graph.invoke({"foo": ""}, config)
运行图之后,我们预计会看到正好 4 个检查点:
- 以
START
作为下一个要执行的节点的空检查点 - 包含用户输入
{'foo': '', 'bar': []}
且以node_a
作为下一个要执行的节点的检查点 - 包含
node_a
的输出{'foo': 'a', 'bar': ['a']}
且以node_b
作为下一个要执行的节点的检查点 - 包含
node_b
的输出{'foo': 'b', 'bar': ['a', 'b']}
且没有下一个要执行的节点的检查点
请注意,由于我们为 bar
通道设置了归约器,因此 bar
通道的值包含了两个节点的输出。
获取状态¶
在与保存的图状态进行交互时,你**必须**指定一个线程标识符。你可以通过调用 graph.get_state(config)
来查看图的*最新*状态。这将返回一个 StateSnapshot
对象,该对象对应于配置中提供的线程 ID 关联的最新检查点,或者如果提供了线程的检查点 ID,则对应于该检查点 ID 关联的检查点。
# 获取最新的状态快照
config = {"configurable": {"thread_id": "1"}}
graph.get_state(config)
# 获取特定检查点 ID 的状态快照
config = {"configurable": {"thread_id": "1", "checkpoint_id": "1ef663ba-28fe-6528-8002-5a559208592c"}}
graph.get_state(config)
在我们的示例中,get_state
的输出将如下所示:
StateSnapshot(
values={'foo': 'b', 'bar': ['a', 'b']},
next=(),
config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28fe-6528-8002-5a559208592c'}},
metadata={'source': 'loop', 'writes': {'node_b': {'foo': 'b', 'bar': ['b']}}, 'step': 2},
created_at='2024-08-29T19:19:38.821749+00:00',
parent_config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f9-6ec4-8001-31981c2c39f8'}}, tasks=()
)
获取状态历史记录¶
你可以通过调用 graph.get_state_history(config)
来获取给定线程的图执行的完整历史记录。这将返回一个与配置中提供的线程 ID 关联的 StateSnapshot
对象列表。重要的是,检查点将按时间顺序排序,最新的检查点 / StateSnapshot
将位于列表的首位。
在我们的示例中,get_state_history
的输出将如下所示:
[
StateSnapshot(
values={'foo': 'b', 'bar': ['a', 'b']},
next=(),
config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28fe-6528-8002-5a559208592c'}},
metadata={'source': 'loop', 'writes': {'node_b': {'foo': 'b', 'bar': ['b']}}, 'step': 2},
created_at='2024-08-29T19:19:38.821749+00:00',
parent_config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f9-6ec4-8001-31981c2c39f8'}},
tasks=(),
),
StateSnapshot(
values={'foo': 'a', 'bar': ['a']}, next=('node_b',),
config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f9-6ec4-8001-31981c2c39f8'}},
metadata={'source': 'loop', 'writes': {'node_a': {'foo': 'a', 'bar': ['a']}}, 'step': 1},
created_at='2024-08-29T19:19:38.819946+00:00',
parent_config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f4-6b4a-8000-ca575a13d36a'}},
tasks=(PregelTask(id='6fb7314f-f114-5413-a1f3-d37dfe98ff44', name='node_b', error=None, interrupts=()),),
),
StateSnapshot(
values={'foo': '', 'bar': []},
next=('node_a',),
config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f4-6b4a-8000-ca575a13d36a'}},
metadata={'source': 'loop', 'writes': None, 'step': 0},
created_at='2024-08-29T19:19:38.817813+00:00',
parent_config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f0-6c66-bfff-6723431e8481'}},
tasks=(PregelTask(id='f1b14528-5ee5-579c-949b-23ef9bfbed58', name='node_a', error=None, interrupts=()),),
),
StateSnapshot(
values={'bar': []},
next=('__start__',),
config={'configurable': {'thread_id': '1', 'checkpoint_ns': '', 'checkpoint_id': '1ef663ba-28f0-6c66-bfff-6723431e8481'}},
metadata={'source': 'input', 'writes': {'foo': ''}, 'step': -1},
created_at='2024-08-29T19:19:38.816205+00:00',
parent_config=None,
tasks=(PregelTask(id='6d27aa2e-d72b-5504-a36f-8620e54a76dd', name='__start__', error=None, interrupts=()),),
)
]
重放¶
也可以回放之前的图执行。如果我们使用 thread_id
和 checkpoint_id
调用图,那么我们将*重放*对应于 checkpoint_id
的检查点*之前*已执行的步骤,并且只执行该检查点*之后*的步骤。
thread_id
是线程的 ID。checkpoint_id
是指线程内特定检查点的标识符。
在调用图时,你必须将这些作为配置的 configurable
部分传递:
config = {"configurable": {"thread_id": "1", "checkpoint_id": "0c62ca34-ac19-445d-bbb0-5b4984975b2a"}}
graph.invoke(None, config=config)
重要的是,LangGraph 知道某个特定步骤之前是否已执行。如果已执行,LangGraph 只需*重放*图中的该特定步骤,而不会重新执行该步骤,但仅针对提供的 checkpoint_id
*之前*的步骤。checkpoint_id
*之后*的所有步骤都将被执行(即,一个新的分支),即使它们之前已经执行过。请参阅此关于时间旅行的操作指南以了解更多关于重放的信息。
更新状态¶
除了从特定的 检查点
重放图之外,我们还可以*编辑*图状态。我们使用 graph.update_state()
来实现这一点。此方法接受三个不同的参数:
config
¶
配置应包含指定要更新哪个线程的 thread_id
。当仅传递 thread_id
时,我们更新(或分支)当前状态。可选地,如果我们包含 checkpoint_id
字段,那么我们将分支所选的检查点。
values
¶
这些是用于更新状态的值。请注意,此更新的处理方式与节点的任何更新处理方式完全相同。这意味着,如果图状态中的某些通道定义了归约器函数,这些值将被传递给这些归约器函数。这意味着 update_state
不会自动覆盖每个通道的通道值,而只会覆盖没有归约器的通道的值。让我们来看一个示例。
假设你已使用以下模式定义了图的状态(请参阅上面的完整示例):
from typing import Annotated
from typing_extensions import TypedDict
from operator import add
class State(TypedDict):
foo: int
bar: Annotated[list[str], add]
现在假设图的当前状态是
如果你按如下方式更新状态:
那么图的新状态将是:
foo
键(通道)被完全更改(因为该通道未指定归约器,所以 update_state
会覆盖它)。但是,bar
键指定了归约器,因此它会将 "b"
追加到 bar
的状态中。
as_node
¶
调用 update_state
时,你可以选择指定的最后一项是 as_node
。如果你提供了它,更新将被应用,就好像它来自节点 as_node
一样。如果未提供 as_node
,如果不模糊,它将被设置为最后更新状态的节点。这很重要的原因是,接下来要执行的步骤取决于最后进行更新的节点,因此这可用于控制接下来执行哪个节点。请参阅此关于时间旅行的操作指南以了解更多关于分支状态的信息。
内存存储¶
状态模式指定了一组在图执行时填充的键。如上文所述,检查点器可以在图的每个步骤将状态写入线程,从而实现状态持久化。
但是,如果我们想在*不同线程之间*保留一些信息呢?以聊天机器人为例,我们希望在与某个用户的*所有*聊天对话(即线程)中保留关于该用户的特定信息!
仅使用检查点器,我们无法在线程之间共享信息。这就催生了对 Store
接口的需求。作为示例,我们可以定义一个 InMemoryStore
来跨线程存储关于用户的信息。我们只需像之前一样使用检查点器编译图,并使用新的 in_memory_store
变量。
!!! info "LangGraph API 会自动处理存储"
使用 LangGraph API 时,你无需手动实现或配置存储。API 会在幕后为你处理所有存储基础设施。
基本用法¶
首先,让我们在不使用 LangGraph 的情况下单独展示这一点。
内存以 元组
进行命名空间划分,在这个特定示例中为 (<用户 ID>, "memories")
。命名空间可以是任意长度,代表任意内容,不一定与用户相关。
我们使用 store.put
方法将内存保存到存储中的命名空间。执行此操作时,我们指定上面定义的命名空间,以及内存的键值对:键只是内存的唯一标识符 (memory_id
),值(一个字典)就是内存本身。
memory_id = str(uuid.uuid4())
memory = {"food_preference" : "I like pizza"}
in_memory_store.put(namespace_for_memory, memory_id, memory)
我们可以使用 store.search
方法读取命名空间中的内存,该方法将以列表形式返回给定用户的所有内存。最新的内存位于列表末尾。
memories = in_memory_store.search(namespace_for_memory)
memories[-1].dict()
{'value': {'food_preference': 'I like pizza'},
'key': '07e0caf4-1631-47b7-b15f-65515d4c1843',
'namespace': ['1', 'memories'],
'created_at': '2024-10-02T17:22:31.590602+00:00',
'updated_at': '2024-10-02T17:22:31.590605+00:00'}
每种内存类型都是一个 Python 类 (Item
),具有特定的属性。我们可以像上面那样通过 .dict
将其转换为字典来访问它。
它具有以下属性:
value
:此内存的值(本身是一个字典)key
:此命名空间中此内存的唯一键namespace
:一个字符串列表,此内存类型的命名空间created_at
:此内存创建的时间戳updated_at
:此内存更新的时间戳
语义搜索¶
除了简单的检索之外,存储还支持语义搜索,允许你根据含义而不是精确匹配来查找内存。要启用此功能,请使用嵌入模型配置存储:
from langchain.embeddings import init_embeddings
store = InMemoryStore(
index={
"embed": init_embeddings("openai:text-embedding-3-small"), # 嵌入提供程序
"dims": 1536, # 嵌入维度
"fields": ["food_preference", "$"] # 要嵌入的字段
}
)
API Reference: init_embeddings
现在进行搜索时,你可以使用自然语言查询来查找相关内存:
# 查找关于食物偏好的内存
# (这可以在将内存放入存储后完成)
memories = store.search(
namespace_for_memory,
query="What does the user like to eat?",
limit=3 # 返回前 3 个匹配项
)
你可以通过配置 fields
参数或在存储内存时指定 index
参数来控制内存的哪些部分被嵌入:
# 存储时指定要嵌入的特定字段
store.put(
namespace_for_memory,
str(uuid.uuid4()),
{
"food_preference": "I love Italian cuisine",
"context": "Discussing dinner plans"
},
index=["food_preference"] # 仅嵌入 "food_preferences" 字段
)
# 存储时不进行嵌入(仍可检索,但不可搜索)
store.put(
namespace_for_memory,
str(uuid.uuid4()),
{"system_info": "Last updated: 2024-01-01"},
index=False
)
在 LangGraph 中使用¶
一切准备就绪后,我们在 LangGraph 中使用 in_memory_store
。in_memory_store
与检查点器协同工作:如上文所述,检查点器将状态保存到线程,而 in_memory_store
允许我们存储任意信息,以便*跨*线程访问。我们按如下方式使用检查点器和 in_memory_store
编译图。
from langgraph.checkpoint.memory import InMemorySaver
# 我们需要这个,因为我们要启用线程(对话)
checkpointer = InMemorySaver()
# ... 定义图 ...
# 使用检查点器和存储编译图
graph = graph.compile(checkpointer=checkpointer, store=in_memory_store)
我们像之前一样使用 thread_id
调用图,同时还使用 user_id
,我们将使用它来为特定用户的内存划分命名空间,就像上面展示的那样。
# 调用图
user_id = "1"
config = {"configurable": {"thread_id": "1", "user_id": user_id}}
# 首先,让我们向 AI 打个招呼
for update in graph.stream(
{"messages": [{"role": "user", "content": "hi"}]}, config, stream_mode="updates"
):
print(update)
我们可以在*任何节点*中通过将 store: BaseStore
和 config: RunnableConfig
作为节点参数来访问 in_memory_store
和 user_id
。以下是我们如何在节点中使用语义搜索来查找相关内存:
def update_memory(state: MessagesState, config: RunnableConfig, *, store: BaseStore):
# 从配置中获取用户 ID
user_id = config["configurable"]["user_id"]
# 为内存划分命名空间
namespace = (user_id, "memories")
# ... 分析对话并创建新内存
# 创建新的内存 ID
memory_id = str(uuid.uuid4())
# 我们创建一个新内存
store.put(namespace, memory_id, {"memory": memory})
如上面所示,我们还可以在任何节点中访问存储,并使用 store.search
方法获取内存。请记住,内存以对象列表的形式返回,可以将其转换为字典。
memories[-1].dict()
{'value': {'food_preference': 'I like pizza'},
'key': '07e0caf4-1631-47b7-b15f-65515d4c1843',
'namespace': ['1', 'memories'],
'created_at': '2024-10-02T17:22:31.590602+00:00',
'updated_at': '2024-10-02T17:22:31.590605+00:00'}
我们可以访问这些内存并在模型调用中使用它们。
def call_model(state: MessagesState, config: RunnableConfig, *, store: BaseStore):
# 从配置中获取用户 ID
user_id = config["configurable"]["user_id"]
# 为内存划分命名空间
namespace = (user_id, "memories")
# 根据最新消息进行搜索
memories = store.search(
namespace,
query=state["messages"][-1].content,
limit=3
)
info = "\n".join([d.value["memory"] for d in memories])
# ... 在模型调用中使用内存
如果我们创建一个新线程,只要 user_id
相同,我们仍然可以访问相同的内存。
# 调用图
config = {"configurable": {"thread_id": "2", "user_id": "1"}}
# 让我们再次打招呼
for update in graph.stream(
{"messages": [{"role": "user", "content": "hi, tell me about my memories"}]}, config, stream_mode="updates"
):
print(update)
当我们使用 LangGraph 平台时,无论是在本地(例如在 LangGraph Studio 中)还是使用 LangGraph Cloud,基础存储默认可用,在图编译期间无需指定。但是,要启用语义搜索,你**必须**在 langgraph.json
文件中配置索引设置。例如:
{
...
"store": {
"index": {
"embed": "openai:text-embeddings-3-small",
"dims": 1536,
"fields": ["$"]
}
}
}
有关更多详细信息和配置选项,请参阅部署指南。
检查点保存器库¶
实际上,检查点功能由符合 BaseCheckpointSaver 接口的检查点保存器对象提供支持。LangGraph 提供了几种检查点保存器实现,所有这些实现都通过独立的、可安装的库来完成:
langgraph-checkpoint
:检查点保存器的基础接口(BaseCheckpointSaver)以及序列化/反序列化接口(SerializerProtocol)。包含用于实验的内存检查点保存器实现(InMemorySaver)。LangGraph 已包含langgraph-checkpoint
。langgraph-checkpoint-sqlite
:使用 SQLite 数据库的 LangGraph 检查点保存器实现(SqliteSaver / AsyncSqliteSaver)。非常适合实验和本地工作流。需要单独安装。langgraph-checkpoint-postgres
:使用 Postgres 数据库的高级检查点保存器(PostgresSaver / AsyncPostgresSaver),用于 LangGraph Cloud。非常适合在生产环境中使用。需要单独安装。
检查点保存器接口¶
每个检查点保存器都符合 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
)。
Note
若要异步运行图,可以使用 InMemorySaver
,或者使用 Sqlite/Postgres 检查点保存器的异步版本 —— AsyncSqliteSaver
/ AsyncPostgresSaver
检查点保存器。
序列化器¶
当检查点保存器保存图状态时,它们需要对状态中的通道值进行序列化。这通过序列化器对象来完成。
langgraph_checkpoint
定义了用于实现序列化器的 协议,并提供了一个默认实现([JsonPlusSerializer][langgraph.checkpoint.serde.jsonplus.JsonPlusSerializer]),该实现可以处理多种类型,包括 LangChain 和 LangGraph 原语、日期时间、枚举等。
功能¶
人工介入¶
首先,检查点管理器通过允许人类检查、中断和批准图步骤,促进了人工介入工作流。这些工作流需要检查点管理器,因为人类必须能够在任何时间点查看图的状态,并且在人类对状态进行任何更新后,图必须能够恢复执行。有关具体示例,请参阅这些操作指南。
记忆¶
其次,检查点管理器允许在交互之间实现"记忆"。在反复的人工交互(如对话)中,任何后续消息都可以发送到该线程,该线程将保留对先前消息的记忆。有关如何使用检查点管理器添加和管理对话记忆的端到端示例,请参阅此操作指南。
时间回溯¶
第三,检查点管理器支持"时间回溯",允许用户重放先前的图执行过程,以审查和/或调试特定的图步骤。此外,检查点管理器还可以在任意检查点分叉图状态,以探索其他可能的轨迹。
容错性¶
最后,检查点机制还提供了容错和错误恢复功能:如果在给定的超级步骤中有一个或多个节点失败,您可以从最后一个成功的步骤重新启动图。此外,当图节点在给定超级步骤的执行过程中失败时,LangGraph 会存储在该超级步骤中成功完成的任何其他节点的待处理检查点写入,这样,当我们从该超级步骤恢复图执行时,就不会重新运行那些成功的节点。
待处理写入¶
此外,当图节点在给定超级步骤的执行过程中失败时,LangGraph 会存储在该超级步骤中成功完成的任何其他节点的待处理检查点写入,这样,当我们从该超级步骤恢复图执行时,就不会重新运行那些成功的节点。