AI Agent记忆 vs RAG：核心区别与工程选择

大多数基于 LLM 构建的团队，最终会在同一个代码库中用到两种模式：RAG 用于在语料库中查找信息，以及某种手写的 memory 机制来记住 agent 执行过的操作或用户说过的话。这两者经常被混为一谈，而混用会造成实实在在的工程时间浪费——当一种模式被用来做另一种的事时。

RAG 检索的是 agent 尚不知道的内容。Memory 检索的是 agent 已经参与过的上下文。

两者共用一个向量存储——通常是 pgvector 或专门的向量数据库——检索时都使用近似最近邻搜索。但相似性到此为止。

RAG 存储的是源文档的块（markdown 页面、PDF、支持文章）。检索返回与用户问题语义最相似的块，作为 grounding 拼入 prompt。

Memory 存储的是事件的有类型记录：episode（原始对话轮次、工具调用、决策）和编译后的 memory（从 episode 中派生出的有类型事实，带有到源的出处追溯）。检索返回与该主题最相关的历史上下文，按近因性、类型、有效性、相似性排序。

如果只需要在静态文档中 grounding 答案，只需要 RAG。如果需要 agent 跨会话记住用户，需要的是 memory。

RAG 的局限

RAG 的设计目标是回答"我们的文档对 X 是怎么说的？"——而不是"这个用户上个月告诉我们什么？"当团队用 RAG 来覆盖 memory 场景时，会出现三种失败模式：

Embedding 最近邻不等于决策相关。用户消息"我对花生过敏"和后续问题"我午饭应该点什么？"在 embedding 上并不接近。余弦相似度会把所有餐厅相关的块排在过敏记录之前。Memory 排序需要的不仅是相似性——还需要类型优先级、时间有效性、明确的出处。

没有压缩机制。RAG 将语料库原样索引。Memory 需要做摘要——把 200 轮对话压缩成"用户是金融科技公司的高级工程师，喜欢简洁的回复"——因为 prompt 预算有限。RAG 不做这件事。

没有失效模型。如果用户的工作变了，"在金融科技公司工作"这条旧记录需要被标记为 superseded，而不是与新记录一起被检索。RAG 的只追加块存储没有有效性窗口或替换的概念。

你可以在应用代码中逐一打补丁来掩盖这些问题。这样做的团队最终会得到一个除了名字不叫 memory 运行时的 memory 运行时。

Memory 超越检索之处

Memory 运行时在向量存储之上增加了三样东西：

编译（Compilation）——对原始 episode 的一次处理，产出有类型的 memory：profile 事实、偏好、流程、episode 摘要——带置信度分数和有效性窗口。这就是把 200 轮压缩成一条事实的原因。

确定性排序（Deterministic ranking）——综合相似性、类型优先级（一个流程比一次随口提及更重要）、近因性、时间有效性以及显式 token 预算的评分。同样的查询 → 同样的 bundle。不会有静默重排序。

出处（Provenance）——每条编译后的 memory 都携带它所派生自的 episode 的 ID。当 agent 从 memory 回答问题时，答案是可以审计回溯到产生它的原始事件的。

这三个都不是文献意义上"RAG"的属性。它们是把 memory 基础设施区别于"对聊天日志做检索"的关键。

何时选择哪种

大多数生产级 agent 两者都需要。Grounding 语料库（文档、知识库）放在 RAG。用户/账户/项目上下文放在 memory。

试图让任一模式做另一方的工作是常见的架构错误——这也是我们构建 Statewave 来阻止人们犯这个错误的原因。

Statewave 在这个图景中的位置

Statewave 是 memory 层——输入 episode，输出排序后的上下文 bundle，带有确定性排序和出处。它在底层使用 pgvector（不需要运维单独的向量数据库），但它不是 RAG 框架：没有文档加载器、没有分块器、没有用于语料库 grounding 的检索接口。如果你想要 RAG，把 Statewave 接入你现有的 RAG 技术栈——Statewave 处理"你在和谁说话"这一层，你的 RAG 框架处理"知识库说了什么"这一层。

文档站的架构页面深入讲解了排序信号和 compile-vs-retrieve 的分工。五分钟 Docker Compose 快速入门指南如果你想与当前的 RAG 设置并行试用的话。

---

FAQ

1. RAG 和 AI agent memory 有什么区别？

RAG 检索 agent 尚不知道的内容——按余弦相似度排序的文档块。Memory 检索 agent 已经参与过的上下文——按近因性、类型、有效性、相似性排序的 episode 和编译事实。

2. 我可以用 RAG 代替 memory 层做 agent memory 吗？

可以强撑，但会出现三种失败模式：embedding 最近邻不等于决策相关（过敏记录不会是与午餐问题最接近的 embedding），没有将历史压缩为持久事实的机制，也没有对被替换事实的失效模型。

3. 我需要同时使用 RAG 和 memory 运行时吗？

大多数生产级 agent 是需要的。Grounding 语料库——文档、知识库——放在 RAG。用户、账户或项目上下文放在 memory。试图让任一模式做另一方的工作是常见的架构错误。

4. memory 运行时相比单独的向量存储增加了什么？

三样东西：编译（将原始 episode 转化为带置信度和有效性的有类型事实）、确定性排序（同样的查询始终返回同样的 bundle）、出处（每条编译后的 memory 都携带它来源的 episode 的 ID）。

5. Statewave 是 RAG 框架吗？

不是。它在底层使用 pgvector，但不提供文档加载器、分块器或用于语料库 grounding 的检索器。它是"你在和谁说话"这一层，旨在与你现有的 RAG 技术栈并行运行，而不是取代它。

6. 如何决定使用哪一个？

看问题的形态。"我们的内容对 X 是怎么说的？"是 RAG。"这个用户、agent 或项目现在需要知道什么？"是 memory。

原文最初发表于 Statewave 博客。Statewave 是一个开源、自托管的 AI agent memory 运行时——GitHub。