Skip to main content
AI 应用需要内存来在多次交互中共享上下文。在 LangGraph 中,你可以添加两种类型的内存:

添加短期内存

短期内存(线程级持久化)使智能体能够跟踪多轮对话。要添加短期内存:

在生产环境中使用

在生产环境中,使用由数据库支持的检查点:
首次使用 Postgres 检查点时,你需要调用 checkpointer.setup()
设置 要使用 MongoDBSaver,你需要一个 MongoDB 集群。如果你还没有,请按照此指南创建一个集群。

在子图中使用

如果你的图包含子图,你只需在编译父图时提供检查点。LangGraph 会自动将检查点传播到子图。
你可以配置子图特定的检查点行为。有关持久化级别(包括中断支持和有状态继续)的详细信息,请参阅子图持久化

添加长期内存

使用长期内存来跨对话存储用户特定或应用特定的数据。

在节点内访问存储

一旦你用存储编译了图,LangGraph 会自动将存储注入到你的节点函数中。推荐的访问存储方式是通过 Runtime 对象。

在生产环境中使用

在生产环境中,使用由数据库支持的存储:
首次使用 Postgres 存储时,你需要调用 store.setup()

使用语义搜索

在图的内存存储中启用语义搜索,让图智能体可以通过语义相似性搜索存储中的项目。
InMemoryStore 适用于开发。对于生产环境,请使用持久化存储,如 PostgresStoreMongoDBStoreRedisStore

管理短期内存

启用短期内存后,长对话可能会超出 LLM 的上下文窗口。常见的解决方案有:
  • 裁剪消息:移除前 N 条或后 N 条消息(在调用 LLM 之前)
  • 从 LangGraph 状态中永久删除消息
  • 总结消息:总结历史中的早期消息,并用摘要替换它们
  • 管理检查点以存储和检索消息历史
  • 自定义策略(例如,消息过滤等)
这允许智能体跟踪对话而不会超出 LLM 的上下文窗口。

裁剪消息

大多数 LLM 都有最大支持的上下文窗口(以令牌为单位)。决定何时截断消息的一种方法是计算消息历史中的令牌数,并在接近该限制时进行截断。如果你使用 LangChain,你可以使用裁剪消息工具,并指定要从列表中保留的令牌数量,以及用于处理边界的 strategy(例如,保留最后 maxTokens)。 要裁剪消息历史,请使用 trimMessages 函数:

删除消息

你可以从图状态中删除消息以管理消息历史。当你想要移除特定消息或清除整个消息历史时,这很有用。 要从图状态中删除消息,你可以使用 RemoveMessage。要使 RemoveMessage 工作,你需要使用带有 messagesStateReducer reducer 的状态键,如 MessagesValue 要移除特定消息:
删除消息时,请确保生成的消息历史是有效的。检查你使用的 LLM 提供商的限制。例如:
  • 一些提供商期望消息历史以 user 消息开始
  • 大多数提供商要求带有工具调用的 assistant 消息后面必须跟有相应的 tool 结果消息。

总结消息

如上所示,裁剪或删除消息的问题在于,你可能会因消息队列的筛选而丢失信息。因此,一些应用程序受益于使用聊天模型总结消息历史的更复杂方法。 Summary 提示和编排逻辑可用于总结消息历史。例如,在 LangGraph 中,你可以在状态中包含一个 summary 键,与 messages 键并列:
然后,你可以生成聊天历史的摘要,使用任何现有摘要作为下一个摘要的上下文。这个 summarizeConversation 节点可以在 messages 状态键中积累了一些消息后被调用。

管理检查点

你可以查看和删除检查点存储的信息。

查看线程状态

查看线程的历史记录

删除线程的所有检查点

数据库管理

如果你使用任何基于数据库的持久化实现(如 Postgres 或 Redis)来存储短期和/或长期内存,你需要在将其与数据库一起使用之前运行迁移以设置所需的模式。 按照惯例,大多数特定于数据库的库在检查点或存储实例上定义一个 setup() 方法,该方法运行所需的迁移。但是,你应该检查你的 BaseCheckpointSaverBaseStore 的具体实现,以确认确切的方法名称和用法。 我们建议将迁移作为专用部署步骤运行,或者你可以确保它们在服务器启动时运行。