持久化AI Agent记忆：跨会话如何记住上下文

关键要点

• 持久化智能体记忆是一个外部存储层，而不是更大的上下文窗口。
• 智能体需要情景记忆、语义记忆和程序性记忆，并通过捕获到更新的循环保持最新。
• Claude Code、Codex 和 Dify 可以共享同一个持久状态层。
• 仅靠向量搜索是不够的。生产级记忆需要作用域、元数据和一致性。

一个编码智能体每次你打开新终端时就忘记你的架构决策，这正是它被设计成的运行方式。它确实是按设计运行的。持久化 AI 智能体记忆是外部层，它跨会话、工具和机器存储并检索有用的上下文，因此 Claude Code、Codex 或 Dify 中的智能体不会每次启动时都重新学习你的偏好和过去的修复。

什么是持久化 AI 智能体记忆？

持久化记忆是存在于提示词之外、也存在于模型权重之外的持久上下文。它是一个独立的存储，由智能体写入和读取，并在会话结束后仍然存在。

无状态聊天历史不是同一回事。一段很长的对话线程感觉像记忆，因为模型可以看到你到目前为止输入的所有内容，但一旦截断裁剪上下文窗口或会话结束，这种连续性就消失了。上下文压缩，即智能体总结旧消息以节省 token，是对有限窗口的权宜之计，而不是一种长期回忆。

Claude Code 记忆和 Dify 智能体记忆在实践中都暴露了这一缺口。一位使用 Claude Code 的开发者在周一解释了一个 bug 修复，关闭终端，周三重新打开，却发现智能体完全不知道这个修复发生过。一个 Dify 工作流在一个会话中处理了客户的账户详情，在下一个会话中却从零开始。两者都是同一种失败：没有外部层捕获重要内容。

持久化记忆存在于上下文窗口之外

上下文窗口是工作记忆。它保存模型当前正在主动推理的内容，并且是有界的、昂贵的、临时的。持久化记忆位于其下方，存在于智能体在需要窗口当前不包含的内容时查询的数据库中。

会话连续性与持久回忆不是同一回事

一个在 50 轮对话中保持连贯的会话并不是长期记忆的证据。它只是上下文窗口尚未耗尽的证据。持久回忆意味着智能体可以在另一台机器上检索三周前、五个会话前的内容，而该信息从未持续保留在窗口中。

为什么智能体总是忘记一切

LLM 在调用之间是无状态的。每个请求都会根据提示词中的任何文本重新评估，除非该历史被传回，否则不会记住先前的请求。重启智能体、打开新线程或切换工具，工作上下文就会重置为零。

开发者会感受到这是一组特定的失败。智能体询问上周已经被告知的同一架构约束。它重新引入一个已经修复过的 bug。它根据哪个会话恰好仍加载着相关上下文，对同一问题给出不同的答案。这些都不是推理失败。它们是记忆失败。

这一缺口对长时间运行的智能体比一次性聊天助手更重要。一个只回答单个问题然后关闭的聊天机器人没有真正的持久化需求。一个在数周内管理代码库、支持队列或多步骤工作流的智能体需要像人类队友那样累积状态，否则它会永远停留在初级水平。

上下文窗口是临时的

即使是大上下文窗口也是缓存，而不是存储。一旦会话结束或窗口填满且旧轮次被驱逐，任何未写入持久层的内容都会消失。

文件笔记和提示词片段无法扩展

把不断更新的笔记文件粘贴到每个提示词中是一种手动记忆系统，而且很快就会崩溃。它不按用户或项目划分作用域，不去重，并且会无界增长，直到有人手动清理。当不止一个智能体或不止一个人需要读取同一状态时，团队就会超出这种模式。这就是将智能体记忆扩展到 SQLite 之外成为真正讨论话题的时刻，而不是可有可无的东西。

每个持久化智能体都需要的三种记忆类型

大多数生产级记忆系统都收敛为三类，每一类都有自己的写入模式、检索模式和保留规则。

情景记忆存储发生了什么

情景记忆记录单个事件：问了什么、尝试了什么、什么坏了、什么修复了它。一个记录了不稳定测试实际修复方案的编码智能体，而不仅仅是记录发生过修复，就可以直接复用该修复，而不是重新推导它。

语义记忆存储跨会话成立的事实

语义记忆保存关于用户、项目或领域的持久事实。团队的命名约定、客户的账户层级、项目的部署目标。这些不会逐轮变化，因此它们一次写入、多次读取。

程序性记忆存储智能体应如何工作

程序性记忆编码的是规则和习惯，而不是事实：提交前始终运行 linter，未经确认绝不删除生产表。这是早期实现中最常缺失的记忆类型，因为它需要在任务开始时主动加载，而不是被动检索。

真正的持久化记忆系统必须做什么

记忆系统并不是一个带保存按钮的向量数据库。它是一个循环：捕获新信息，提取值得保留的内容，与已存储的内容进行去重，以正确的范围写入，在相关时检索它，并在它过时时更新或淘汰它。向量相似性搜索，在 TiDB 的向量搜索文档中有详细介绍，处理检索中的相似性匹配部分，但这个循环比这更大。

范围划分不是可选项。一个多用户或多项目的智能体如果跨用户混合记忆，就会泄露信息并给出错误答案。混合检索，将向量相似性与诸如用户 ID、项目或时间戳之类的结构化过滤器相结合，才能使检索变得精确，而不是近似相关。而且写入控制与读取控制同样重要。一个将每一个零散细节都写入永久记忆的智能体，会让未来的检索淹没在噪声中。

记忆捕获只是第一步

记录每一次交互很容易。决定什么值得保留，以及以哪种记忆类型保留，才是真正的工程问题。一个不加区分地写入所有内容的捕获步骤，只是把杂乱从提示词搬到了数据库中。

检索必须具有选择性和范围限定

返回与查询松散相关的所有内容的检索违背了记忆的目的。有效的系统先按范围过滤，再按相关性排序，这样智能体得到的是一小部分真正适用于当前任务的记忆，而不是一整面无关上下文的墙。

好的记忆系统知道何时遗忘或更新

事实会变化。客户升级了他们的套餐，团队切换了框架，一个 bug 被修复而变通方案的记忆变得过时。一个从不更新或过期记忆的系统会积累矛盾，而一个检索到相互冲突事实的智能体比完全没有记忆的智能体更糟。这就是 AI 记忆架构指南必须做对的核心：写入路径应取代过时条目，而不仅仅是追加到它们之上。

Claude Code 记忆如何与持久化后端协同工作

Claude Code 记忆旨在保留项目上下文：编码偏好、过去的修复、架构决策，以及应当延续到下一个会话的经验。本地记忆文件和会话摘要可以捕获其中一部分，但它们被绑定到一台机器和一个工作目录上。

Claude Code 需要的不仅仅是本地笔记

一个签入仓库的 markdown 笔记文件对单台机器上的单个开发者有帮助。它不会跟随智能体到另一台笔记本电脑，不会跨团队同步，也不会随着事实变化自动去重或更新。

共享记忆胜过机器绑定的记忆

像 TiDB Cloud 这样的持久状态层为 Claude Code 提供了一个独立于任何一台机器而存在的记忆空间。TiDB Cloud 连接到兼容 MCP 的客户端，包括 Claude Code，直接通过其 AI 工具集成，因此智能体将检查点、记忆记录和先前的决策写入持久存储，而不是本地文件。这样，无论开发者是在笔记本电脑上、在 CI 运行器上，还是在队友的机器上接续同一任务，相同的项目上下文都可用。

Codex 记忆和 Dify 智能体记忆如何契合同一模式

Codex 和 Dify 具有不同的运行时形态。Codex 作为编码智能体在本地和云环境中运行。Dify 作为工作流和聊天机器人平台运行。两者都需要相同的基础能力：跨会话的连续性、限定到正确用户或项目的记忆，以及将新事实写回存储的结构化方式。

Codex 记忆需要跨机器的连续性

一个从 CI 流水线调用的 Codex 智能体和一个从开发者终端调用的 Codex 智能体正在处理同一个代码库，但不会自动共享上下文。跨机器连续性意味着两者都可以读取相同的项目记忆，因此在一个环境中发现的修复可以在另一个环境中可用，而无需人工转达。

Dify 智能体记忆需要的不仅仅是对话缓冲区

Dify 的默认会话记忆保存当前对话缓冲区。这对于单次聊天来说足够了，但对于一个案件跨越两周内三次对话的客户来说就不够了。随着 Dify 用例从单会话聊天机器人成熟为持续性的工作流，团队会添加一个生命周期更长的记忆层，独立于任何一次对话而持久保存关于客户或任务的事实。

一个共享后端可以服务多个智能体运行时

实际含义是，Claude Code、Codex 和 Dify 不需要三个独立的记忆系统。一个通过单一查询接口暴露检查点、记忆记录和向量的持久状态层可以支撑所有三者，因此在一个工具中习得的事实可在另一个工具中使用，而无需手动同步步骤。

TiDB Cloud 如何充当持久化上下文层

TiDB Cloud 为长时间运行的智能体提供一个持久状态层，用于检查点、记忆记录、运营数据和向量，因此智能体可以跨会话和运行时重启恢复工作，而不是每次运行时结束时都丢失进度。

一个存储同时用于检查点、记忆和向量

智能体将对话轮次、偏好、事实和决策写入 TiDB Cloud，在那里该记忆保持可查询，并可供同一工作流中的其他智能体访问。检查点与智能体所更改的应用程序数据保持一致，因此智能体可以从它可信任的状态恢复，而不是猜测它在哪里停止。Kimi 的 K2.6 智能体平台和 Manus 的智能体集群都在生产环境中运行这一模式，在相同架构之上为每个智能体会话配置一个隔离的数据库。

无需专用基础设施的智能体和租户隔离

TiDB Cloud 的分布式架构将逻辑隔离与物理基础设施分离每个代理或租户都拥有自己的数据库，具有硬性数据边界，而计算和存储在整个集群中共享。隔离不需要为每个代理配置专用基础设施，这在许多代理是短生命周期或大部分时间处于空闲状态时尤为重要。Kimi 的代理托管平台在相同的模型上，不到一秒即可为每个站点配置一个新的隔离数据库。

为什么记忆层仍然需要真正的数据库

记忆 API 的持久性仅取决于其底层存储。持久记忆首先是一个数据架构问题，其次才是检索问题。

持久记忆是一个数据架构问题

持久地存储记忆需要追踪用户范围、时间戳、元数据、检索信号和运行状态，并且所有这些都要一致且可一起查询。本地文件或内存缓存无法在生产规模下处理这些。

仅靠召回是不够的

向量搜索能找到语义相似的内容，但它不强制记忆属于哪个用户，不保证写入实际已提交，也不处理范围化检索所依赖的结构化过滤条件，如项目 ID 或日期范围。向量相似度只是检索模式中的一个信号，而非整个系统。

持久状态需要结构、过滤和一致性

生产级记忆系统需要多租户隔离，使一个用户的记忆永远不会泄漏到另一个用户；需要共享访问，使多个代理和服务可以读取同一存储；还需要运行可靠性，使成功的写入在下次读取时确实存在。这是一个AI 代理状态的最佳数据库问题，而不是向量索引问题。

TiDB 如何在生产规模下支持持久记忆

TiDB 是一个兼容 MySQL 的分布式 SQL 数据库，这使其成为持久上下文层所依赖的元数据、搜索和运行状态的实用系统记录。

TiDB 为代理记忆提供持久的系统记录

用户范围、记忆时间戳、检索元数据和检查点状态都需要一个系统记录，它不会丢失数据，也不需要额外附加一个单独的一致性层。TiDB 提供了该记录，同时保持与大多数工程团队已经熟悉的 MySQL 工具链兼容。这就是在 TiDB 上构建代理记忆的理由。

记忆与分析共用一个查询层

在 TiDB Cloud 上，支持代理可以在一条 SQL 语句中查询客户的账户层级、未结工单以及语义相似的过往对话。TiFlash 对实时数据执行分析查询，无需单独的管道，因此记忆和运营分析保持在同一个系统上，而不会彼此偏离。

TiDB 如何帮助团队构建真正能记住的代理

跨会话记忆的代理需要两样东西：一个知道该存储和检索什么的持久上下文层，以及其下方一个持久的数据基础。任何一样出错，结果都一样。代理会重复自己、与自己的过往决策矛盾，或者在运行时一结束就丢失进度。

TiDB 直接为长期运行的代理提供了这一层。检查点、记忆记录、运营数据和向量都存储在一个持久、可查询的存储中，专为代理记忆、状态和多跳推理而构建。

持久 AI 代理记忆常见问题

AI 代理默认具有持久记忆吗？

不。LLM 在调用之间是无状态的，大多数代理框架附带的是仅会话记忆，会话结束时会重置。当代理需要跨会话和重启回忆事实、决策或过往交互时，开发者会添加一个外部记忆层，通常是数据库加检索 API。

Claude Code 记忆和持久记忆有什么区别？

Claude Code 记忆在其默认形式下，指的是与单台机器绑定的本地上下文文件和会话摘要。持久记忆是代理读写的一个持久后端，因此相同的记忆可在多台机器、多个会话和团队成员之间使用，而不仅限于一个工作目录内。

Dify 代理记忆与长期记忆有何不同？

Dify 的内置记忆保存单个会话的活动对话缓冲区。长期记忆是一个单独的层，跨多个会话和对话持久保存关于用户或任务的事实，独立于任何一个聊天线程。

AI 代理应在长期记忆中存储什么？

跨会话成立的事实（语义记忆）、具体的过往事件及其结果（情景记忆），以及代理应如何行为的规则（程序记忆）。不是每次交互的每个细节。捕获步骤应过滤出真正可复用的内容。

持久 AI 代理记忆的最佳数据库是什么？

这取决于工作负载形态，但生产系统通常需要多租户范围、与向量搜索并存的结构化元数据，以及规模化的运行可靠性，而不仅仅是一个向量索引。像 TiDB 这样的分布式 SQL 数据库覆盖了仅向量存储所遗漏的元数据和一致性要求。

文章 持久 AI 代理记忆详解：代理如何跨会话记忆 首次发表于 TiDB。