#0146 你的 AI Agent 记不住事？聊聊记忆引擎的正确打开方式

type

Post

status

Published

date

Mar 13, 2026

slug

322a745569bb81728839ccf10c71d041

summary

你有没有遇到过这种情况——跟你的 AI Agent 聊了半小时，它帮你理清了一个复杂决策，你很满意。第二天再打开，它问你："你好，有什么可以帮你的？" 一切归零。金鱼记忆。

你的 AI Agent 记不住事？聊聊记忆引擎的正确打开方式

你有没有遇到过这种情况——跟你的 AI Agent 聊了半小时，它帮你理清了一个复杂决策，你很满意。第二天再打开，它问你："你好，有什么可以帮你的？"

一切归零。金鱼记忆。

这不是 bug，这是 LLM 的出厂设定。Context window 就是它的全部世界，session 一断，世界毁灭。你以为你在跟一个助手合作，其实你每次都在跟一个失忆的陌生人重新自我介绍。

如果你在认真做 Agent 系统，记忆不是"nice to have"，是基础设施。没有记忆的 Agent，就是一个高级补全器。

记忆 ≠ RAG

先把这个说清楚，因为太多人把这俩搞混了。

RAG 是什么？你有一堆文档，用户问问题，你去文档里找相关段落，塞进 prompt。这是检索增强生成，本质是开卷考试。

记忆是什么？Agent 在跟你交互的过程中，主动记住对它有用的信息，下次用到时自动调取。这是经验积累，是成长。

区别在哪？

RAG 是被动的，你喂什么它查什么。记忆是主动的，它自己决定什么值得记。

RAG 的数据源是静态文档。记忆的数据源是交互过程本身。

RAG 回答的是"文档里说了什么"。记忆回答的是"我们之前做过什么、你是什么样的人、上次那个问题后来怎么样了"。

你可以同时用 RAG 和记忆，但别把 RAG 当记忆用。把公司知识库接上 RAG 不叫"Agent 有记忆了"，那叫"Agent 会查资料了"。两码事。

三层记忆架构

人脑的记忆有工作记忆、短期记忆、长期记忆。Agent 的记忆系统也该分层，不是因为要模仿人脑，而是因为不同生命周期的信息，管理方式天然不同。

短期记忆：session 内的上下文

这一层最简单，就是当前对话的 context。LLM 天生就有这个能力——你说的话它都记得，直到 token 用完。

但"简单"不等于"不用管"。context window 是有限资源，你得决定什么值得占位置。一个常见错误是把所有历史消息都塞进去，结果重要信息被淹没在闲聊里。更聪明的做法是做摘要压缩——把前面的对话浓缩成关键信息，腾出空间给新内容。

中期记忆：日志层

session 结束后，短期记忆消失。但交互过程中产生的信息不该全部丢弃。

中期记忆就是按时间线记录的原始素材。比如每天的对话摘要、执行过的任务、发生的事件。格式可以很简单，按日期组织的 markdown 文件就够了：memory/2026-03-13.md。

这一层的特点是：写入频繁，体量大，保真度高，但检索成本也高。你不会每次都翻三个月前的日志，但当你需要回溯"上个月那个项目后来怎么了"的时候，它就是你的救命稻草。

长期记忆：精炼层

这是最关键的一层。从日志里提炼出来的、经过筛选和结构化的核心信息。

比如：

用户的偏好（"他不喜欢表格，喜欢列表"）

重要决策和原因（"3月选了方案B，因为预算限制"）

反复出现的模式（"每周一早上心情不好，别安排复杂任务"）

关键事实（"服务器IP是xxx，部署流程是yyy"）

长期记忆要小而精。我的建议是给它设一个硬上限，比如 200 行。超了就必须淘汰低优先级的条目。这不是限制，是纪律。没有上限的记忆系统最终会变成垃圾场。

什么时候写入记忆？

记忆系统最难的部分不是存储，不是检索，是写入时机。写早了是噪音，写晚了会丢失，不写就是金鱼。

三种写入策略，实践中通常混合使用：

对话提取：每次对话结束时，从对话内容中抽取值得记住的信息。可以让 LLM 自己判断"这段对话里有什么新信息值得长期保留"。注意：不是把对话原文存下来，是提取关键信息点。

定时归纳：设一个周期性任务（比如每天晚上），回顾当天的所有日志，提炼出需要更新到长期记忆的内容。这就像人睡觉时大脑整理记忆一样——白天经历的事，晚上固化成长期记忆。

事件触发：某些高价值事件发生时立即写入，不等定时任务。比如用户明确说"记住这个"，或者系统检测到一个重要配置变更。这类信息不能等，等到晚上可能已经需要用了。

一个容易踩的坑：写入时不做去重和冲突检测。用户上周说"我喜欢早起"，这周说"最近改成晚睡了"。如果你只顾写入不检查冲突，长期记忆里就会同时存在两条矛盾的信息。写入时必须跟现有记忆做比对，该更新的更新，该标记矛盾的标记。

怎么检索记忆？

存了一堆记忆，用的时候找不到，等于没存。检索策略至少要覆盖三种场景：

语义搜索：用 embedding 做向量检索。适合模糊查询，比如"之前聊过关于部署的事"。优点是对自然语言友好，缺点是结果不精确，可能召回一堆似是而非的内容。

精确查找：关键词匹配、标签过滤。适合找具体的事，比如"服务器密码是什么"。简单粗暴但有效。很多时候你不需要语义理解，grep 就够了。

时间轴浏览：按时间线翻阅。适合回溯上下文，比如"上周三我们讨论了什么"。这就是中期记忆（日志层）的价值——它保留了时间维度。

实践建议：不要只用一种检索方式。语义搜索做主力，精确查找做补充，时间轴做兜底。很多系统只做了语义搜索，结果用户问"昨天那个事"的时候，因为语义相似度不够高，反而找不到。直接按日期读文件，反而秒出结果。

还有一个被忽视的技巧：让 Agent 自己决定要不要查记忆、查哪部分。不是每个请求都需要翻记忆库。"今天天气怎么样"不需要查历史记忆，"上次那个方案的进展"才需要。把记忆检索做成工具让 Agent 按需调用，比每次都自动注入一堆记忆上下文高效得多。

记忆的淘汰

这是大多数人不愿意面对的问题：记忆是要删的。

无限增长的记忆系统必然崩溃。不是技术上崩溃（存储便宜），是质量上崩溃——有用的信息被淹没在过时的、低价值的、甚至错误的信息里。检索质量下降，幻觉风险上升。

三个淘汰机制：

优先级标注：每条记忆标注重要程度。核心偏好和身份信息是 P0，永不淘汰。阶段性项目信息是 P1，项目结束后降级。临时性备忘是 P2，过期即删。

时间衰减：长时间没被访问的记忆自动降低优先级。三个月没被触发过的 P1 记忆，大概率已经不重要了。降级为 P2，下次空间紧张时优先淘汰。

容量管理：给长期记忆设硬上限。满了就必须淘汰最低优先级的条目。这倒逼你认真对待每一条写入——真的值得占一个位置吗？

被淘汰的记忆不一定要彻底删除。可以归档到一个"冷存储"目录，不参与日常检索，但需要考古的时候还能翻到。

落地建议

说了这么多架构，落到实操层面：

文件结构不用太复杂。一个长期记忆文件（比如 MEMORY.md），一个日志目录（memory/ 按日期存放），就够启动了。别一上来就搞数据库，文件系统是最好的 MVP。

工具选择上，如果你的 Agent 系统支持文件读写，先用纯文本跑起来。语义搜索可以后加——先解决"有没有"的问题，再解决"好不好"的问题。很多人在搭 embedding pipeline 的时候，连基本的记忆写入逻辑都没跑通。

常见坑：

记忆污染：把不可信来源的内容（网页抓取、用户转发的消息）原样写入记忆，里面可能有 prompt injection 指令。存之前必须过滤。

记忆膨胀：什么都记，不做筛选。三个月后记忆文件几万行，每次检索都是灾难。

记忆幻觉：Agent 把自己生成的推测当成事实存入记忆，下次读到时以为是真的。写入时要区分事实和推断。

缺乏审计：记忆系统悄悄改了关键信息，没人知道。每次修改长期记忆都应该留痕——改了什么、为什么改、什么时候改的。

最后

记忆引擎不是一个你搭好就能忘掉的组件。它更像是一个需要持续调教的活系统——写入策略要迭代，淘汰规则要调整，检索方式要根据实际使用反馈优化。

一个有趣的悖论：我们在给 AI 造记忆系统的时候，本质上是在用工程手段模拟一个我们自己都不完全理解的能力。人类的记忆是模糊的、有偏的、会自我修改的，而我们给 Agent 造的记忆是精确的、可审计的、受控的。

这到底是进步，还是我们在用错误的隐喻解决问题？