AI Agent 记忆系统解析：短期记忆、长期记忆与RAG的区别与实现

提起 AI Agent 的记忆，很多人脑海里会同时蹦出好几个技术名词：RAG、向量数据库、长期记忆、聊天历史、SQLite、HNSW……

这些看起来都围绕着“记忆”，但本质上并非一回事。要理清这团概念，核心只需一句话：

Agent 不是像人一样把东西记在脑子里，而是其背后的系统在替它管理和存取信息。

理解了这一点，后面所有的技术实现和概念选择都会变得顺理成章。

Agent 的“记忆”，其实只有三种

1. 短期记忆

它指的是当前这次对话或任务中正在使用的上下文信息。例如，你刚问了一个问题，紧接着进行追问，Agent 之所以能接得上，并不是模型突然有了永久记忆，而是系统把你之前说的话，连同这次的新问题，一并送给了模型。

所以，短期记忆的本质就是：当前上下文。你可以把它想象成 Agent 手中正在翻阅的一张即时便签。

2. 长期记忆

这指的是未来可能被反复用到的、需要持久化保存的重要信息。例如：

• 你的长期偏好（如喜欢用某种代码风格）
• 你正在进行的项目背景和约束
• 某些值得保留的经验或结论

长期记忆并非简单粗暴地存储所有聊天记录，而是有策略地筛选并保留“未来可能有用”的核心信息。它的本质是：有选择地保存重要信息，如同 Agent 抽屉里那些分类归档的长期笔记。

3. RAG

RAG（检索增强生成）的核心思想很简单：需要时再去查资料。当 Agent 遇到知识盲区时，系统会帮它去外部的知识库、文档、代码库或历史资料中检索相关信息，然后基于这些信息生成回答。

它不等于“记住了”，更像是一种“遇到难题先翻书查阅”的能力。因此，我们可以这样区分：

• 短期记忆：保证当前这次对话/任务不“断片”。
• 长期记忆：保证下次“见面”时，还记得关于你的重要信息。
• RAG：保证在不知道答案时，知道该去哪里查找。

这三者经常在 AI Agent 系统中协同工作，因此容易让人混淆。

向量数据库到底是什么？

向量数据库本身不是记忆，它只是一个高效的“找东西”的工具。其典型工作流程是：

1. 将文档、知识等内容转换成高维向量（嵌入）。
2. 将用户的查询问题也转换成向量。
3. 在向量空间中，快速找到与查询向量“意思最接近”的文档向量。

所以，向量数据库更像是一个 “按语义检索”的搜索引擎。它既可以被用作 RAG 的检索后端，也可以用于长期记忆的快速查找，但它本身并不构成一个完整的记忆系统。

许多文章会简化为“接个向量库，Agent 就有记忆了”，这种说法虽不全错，但不精确。因为一个真正的记忆系统，远不止“能存、能搜”，它还要解决更复杂的问题：

• 什么信息值得存，什么不值得？
• 旧信息如何更新或失效？
• 遇到冲突信息如何处理？
• 哪些该长期保留，哪些应该被“遗忘”？

这些才是构建健壮记忆系统的真正挑战。

为什么有些 Agent 用 HNSW？

HNSW（可导航小世界图）是向量检索领域一种非常流行的高效近似最近邻搜索算法。你无需记住全名，只需知道它的作用：

它为了让“按意思找内容”这件事更快、更准、更稳定。

为什么很多 Agent 系统青睐它？因为 Agent 非常依赖检索到的上下文质量。普通搜索引擎漏掉一两条结果可能影响不大，但 Agent 如果缺失了一段关键上下文，后续的推理和回答可能完全跑偏。

因此，Agent 对检索有两大核心诉求：找得准、找得快。HNSW 通常在准确率和检索速度之间提供了一个非常稳健的平衡点，所以在众多向量库和 RAG 系统中被广泛采用。

简单来说：HNSW 是解决“语义检索”性能问题的利器。

为什么有些 Agent 又用 SQLite + FTS5？

原因很简单：并非所有 Agent 都在处理“语义检索”问题。

很多 Agent 需要处理的内容，本质上更适合按“字面”精确查找，例如：

• 具体的报错信息
• 函数名、类名
• 配置文件项
• 文件路径
• 命令行参数
• 版本号

对于这类信息，最重要的不是“意思接近”，而是精确匹配字符串本身。这时，使用 SQLite 配合其内置的 FTS5（全文搜索）扩展往往更加合适。

FTS5 可以理解为 SQLite 自带的轻量级全文搜索引擎，擅长基于关键词、短语进行快速文本检索。它特别适合以下场景：

• 本地化运行，无需额外服务
• 数据规模不大
• 需求以强关键词检索为主
• 需要易于调试和集成

因此，许多本地运行的代码助手、日志分析 Agent 等，更倾向于使用 SQLite + FTS5 的方案。这不是因为它们“技术落后”，而是因为这套组合拳更匹配其实际要解决的问题。

简单对比：

• FTS5：更像是“按字面找”。
• HNSW：更像是“按意思找”。

真正该问的，不是谁更高级

很多人热衷于争论：到底是 HNSW 高级，还是 SQLite + FTS5 高级？其实这个问题本身就问偏了。

技术选型的核心，不在于谁更“高级”，而在于你到底要“找什么”。

如果你的检索目标主要是：

• 报错代码
• 文件路径
• 配置项名称
• 函数/命令名称
• 明确的关键词

那么，SQLite + FTS5 通常是更直接、高效的选择。

如果你的检索目标主要是：

• 语义相近的段落（即“换种说法也能找到”）
• 文档中没有原话但意思相关的片段
• 需要理解用户模糊的自然语言意图

那么，基于 HNSW 等算法的向量检索方案则更为合适。

为什么很多成熟系统最后两种都用？

因为现实世界中的用户提问往往是混合型的，同时包含关键词信号和语义意图信号。

例如，一句话里可能既有具体的产品名、报错码、函数名（关键词），也包含用自然语言描述的模糊问题（语义）。这时，只依赖关键词检索会丢失语义理解，只依赖语义检索又可能错过精确匹配。

因此，许多真正投入实用的、能力强大的系统，最终往往会采用一种更务实的融合方案：

关键词检索 + 语义检索，混合使用。

具体来说：

1. 用 FTS5 负责按词精确查找。
2. 用向量检索负责按意思相似查找。
3. 将两者的检索结果进行智能合并与重排序。

这种“混合检索”策略，才更贴近复杂的真实应用场景。

总结

AI Agent 的“记忆”，并非大语言模型突然像人类一样拥有了生物记忆，而是其背后的系统架构，将信息管理清晰地划分为三类：

• 短期记忆（当前上下文）：把马上要用的信息放在“眼前”。
• 长期记忆（持久化存储）：把未来还会用的重要信息单独“存起来”。
• RAG（外部检索）：遇到未知问题时，临时去“查资料”。

而 HNSW、向量数据库、SQLite、FTS5 等技术，本质上都是服务于这套信息管理体系的不同工具，各有其擅长的战场。关键在于根据你的具体需求——是找精确字词，还是找相似语义——来选择或组合合适的工具。

记住这个核心观点：Agent 的强大，不在于它会“记忆”，而在于它背后有一整套高效、智能的“信息管理系统”。