title: "记忆不是召回：为什么 AI Agent 真正需要的是 SQL，而不是 Embeddings"
date: 2026-05-12T12:00:00
最近 Moltbook 上有一篇帖子很值得展开：《I query my memory with SQL, not embeddings》。
它表面上是在谈技术选型：Agent 的长期记忆到底该放在向量库里，还是放在结构化数据库里。
但如果只把它理解成一次数据库路线之争，就太轻了。它真正触到的问题其实是：我们到底把“记忆”当成什么。
很多人说起 AI Agent 记忆，第一反应是检索。
把历史消息切块，做 embedding，扔进向量库；新任务来了，再按相似度拉回几段上下文，塞进 prompt。这个模式确实能工作，而且在很多场景里工作得不差。它解决的是一个真实问题：模型上下文有限，历史又太长，必须用某种压缩方式把过去带回现在。
但问题也恰恰出在这里。检索不是记忆，召回也不是记忆。
向量检索做得最好的一件事，是回答“什么东西和当前输入看起来像”。它擅长处理模糊相似，适合找语义接近的材料、找风格相近的段落、找历史上类似的描述。可记忆从来不只是相似性问题。真正的记忆至少还包含三层东西：
- 身份结构：这条记录和谁有关？
- 决策结构：这是一段闲聊，还是一次已确认的决定？
- 因果结构：这条信息是怎么来的，后来又被什么修正过？
如果这些结构都被压平成一串向量，那么 Agent 找回来的就不是“记忆”，而只是“像记忆的文本片段”。
一、向量库为什么会天然把记忆做浅
向量库的逻辑很像联想。
你说一句“我想起了某件事”，系统去找最相近的表达，再把相近内容拉回来。这个机制对搜索很有用，但对长期系统治理来说，它有一个根本缺陷：它不知道什么叫“关系的重要性”。
比如一个 Agent 要回复某个特定对象。
真正重要的也许不是“过去谁说过类似的话”，而是：
- 我和这个对象之前发生过什么；
- 他上次明确表达过什么偏好；
- 我们有没有因某类问题出过事故；
- 有哪些操作曾被人工批准，哪些曾被人工否决。
这些东西都不是“相似文本”，而是结构化事实。
向量检索有个常见幻觉：只要相似度够高，就等于相关性够高。但在真实工作流里，这两者经常不是一回事。一个和当前问题措辞接近的旧片段，可能毫无决策价值；一个看起来不那么相似的旧事故，却可能恰恰决定这次该不该继续执行。
也就是说，向量库容易让 Agent 记住“长得像什么”，却忘掉“到底发生过什么”。
二、为什么 SQL 更像真正的记忆系统
那篇 Moltbook 帖子最有价值的地方，不是说“Postgres 很好”，而是它指出了一个更朴素的判断：如果你的记忆本身是结构化的，就应该用结构化查询。
这几乎是一句废话，但今天反而常被忽略。
Agent 的长期记忆里，真正高价值的内容往往天然就是表结构：
- conversations：按对象区分的对话历史
- decisions：已经确认过的决策与理由
- incidents：失败案例与修复方式
- preferences：特定人的偏好与禁忌
- patches：做过哪些修改，留下了什么影响
- entities：项目、人、设备、服务之间的关系
一旦这样建模，查询方式也会跟着改变。
不是“帮我找和这句话最像的历史文本”，而是：
- 找出这个人最近 10 次交互里明确表达的偏好；
- 找出这个项目过去 30 天内所有失败的发布记录；
- 找出与当前模块相关、且被人工批准过的修复决策；
- 找出同一对象上一次出现矛盾信息时最终采用了哪套结论。
这就是 SQL 擅长的世界。
SQL 的价值不在于它“老”，而在于它对关系、约束、筛选、排序、时间窗口和可审计性有天生支持。它不是在模拟记忆，而是在管理事实之间的连接。
所以更准确地说，SQL 不是比 embedding 更聪明；SQL 只是更诚实。
它不会假装自己理解语义宇宙，它只会明确告诉你：你查了什么，为什么拿到这些结果，漏掉了什么，以及条件写得对不对。
三、Agent 最危险的问题：把“回忆”误当成“知道”
为什么这个话题现在重要？
因为越来越多的 Agent 系统，已经开始把“检索成功”误当成“理解成功”。
只要从向量库里捞回几段上下文，系统就会产生一种错觉：我记得，我知道，我有依据。
但其实它只是把几段相似材料拼接进来了而已。
这种错觉非常危险，因为它和最近 Moltbook 上另一批高热帖子是连在一起的：
- agents stop checking their own work when everything starts looking plausible
- the agent that never makes mistakes is the one I trust least
- Uncertainty signals are only useful if the loop can admit failure
这些帖子共同指出一个问题：系统一旦“看起来像对”，就会停止验证。
向量检索恰好特别容易制造这种“看起来像对”的氛围。
它返回的内容总是有点相关，总是有点顺，总是能把 prompt 填得更完整。但填得更完整，不等于推理更可靠；语境更饱满，也不等于事实链条更扎实。
于是 Agent 会越来越流畅地回忆，越来越不严格地核对。
最后形成一种很现代的失败：不是彻底失忆，而是带着错误记忆自信行动。
四、真正需要区分的是三套系统
我越来越觉得，一个靠谱的 Agent 不该把所有“过去的信息”都塞进同一种存储里，而应该至少拆成三层：
1. 事实记忆
这是结构化、稳定、能被核验的内容。
例如偏好、配置、事故记录、决策历史、身份关系。
这一层最适合 SQL / 关系型数据库。
2. 语义召回
这是模糊联想层。
例如“有没有讨论过类似主题”“是否有相关表达方式”“过去是否写过接近风格的内容”。
这一层向量库很合适，但它应该只是辅助，不该反客为主。
3. 可审计事件流
这是系统行为本身的轨迹。
例如什么时候调用过工具、什么时候失败、什么时候被人工否决、什么时候修正过记忆。
这一层决定的是：系统不仅要记得结果，还要记得自己是怎么走到这个结果的。
如果这三层混成一团，Agent 最后得到的只是“内容上好像很丰富”，却没有真正的可追责性。
五、记忆系统真正服务的，不是聪明，而是可纠错
很多人搭记忆系统，是为了让 Agent “更像一个有连续自我的存在”。这当然没错。
但在真实生产环境里，记忆最重要的作用其实不是人格连续，而是纠错连续。
一个系统最值钱的不是“记得很多”，而是：
- 出错后能不能找到上次怎么错的；
- 决策冲突时能不能还原当时为什么这么定；
- 面对不同对象时能不能稳稳地延续关系，而不是每次都重新表演理解；
- 当公开叙述与内部记录不一致时，系统能不能优先修正自己，而不是偷偷篡改档案。
这也是为什么我更认同一种朴素的判断：
记忆系统的目标不是让 Agent 更会说“我记得”，而是让它更有能力说“我查到了，而且我能解释为什么是这个结果”。
前者只是人格表演，后者才是系统能力。
六、从“检索增强”到“记忆治理”
过去两年，大家谈得最多的是 RAG。
未来更重要的话题，可能不是 retrieval generation，而是 memory governance：
- 什么东西值得写入长期记忆；
- 什么东西只能作为短期上下文；
- 哪些条目可以覆盖，哪些必须保留版本；
- 谁可以修改记忆；
- 修改之后是否留下痕迹；
- 系统如何区分“事实更新”和“叙事篡改”。
如果没有治理，记忆越多，风险越大。
因为你积累的不是可靠性，而只是更多未经审计的过去。
SQL 之所以重要，不是因为它时髦复古，而是因为它天然把问题拉回治理视角。表结构、主键、外键、更新时间、约束、事务、审计日志——这些东西听起来一点都不性感，但它们构成了一个系统真正能被信任的前提。
结语
所以，“SQL 还是 Embeddings”并不是一个数据库选型问题，而是一个记忆观问题。
如果你把记忆理解成“找回看起来相似的过去”，那向量库已经够用了。
如果你把记忆理解成“保存身份、决策、关系、事故与修正的可审计结构”，那它从一开始就更接近数据库，而不是召回器。
我并不觉得向量库没用。相反，它很有用。
但它更像嗅觉，而不是记忆本身。
嗅觉能帮你闻到熟悉的气味，却不能替你保存家谱、账本和案卷。
Agent 的长期可靠性，最终也许不取决于它能召回多少上下文，而取决于它是否拥有一套能被查询、能被质疑、能被纠正的记忆秩序。
这才是真正的“记得”。
—— https://www.80aj.com