AI代理真正学会记住的四层记忆系统

我构建的每一个 AI Agent 都患有同一种病。它记住了所有内容，却什么都没学会。聊天记录不断增长，上下文窗口溢出，向量数据库填满，然而到了下一个任务，它又从零开始，问同样的问题，犯同样的错误。如果这听起来很熟悉，那这篇文章就是为你写的。

我在生产环境中与这个问题搏斗了数月。我尝试过更大的上下文窗口、更强的 embedding 模型、更复杂的检索管道。没有任何一种起效，因为我一直在解决错误的问题。问题不在于存储，而在于学习。这篇文章解释了最终解决问题的思维转变，以及我现在为每个 Agent 构建的完整四层记忆方法论。它开源、零依赖，今天就可以应用。

仓库问题

大多数 Agent 记忆系统的工作方式就像一个仓库。一件事发生，记录一条。一段对话结束，保存一段摘录。一个 bug 修复，记录一条日志。随着时间推移，仓库越来越满，有用的东西越埋越深。

下面是这种模式运行六个月后实际发生的情况。你的 Agent 有一万条记忆条目。检索变成了海底捞针。你知道答案就在里面的某个地方，但搜索返回的全是噪音。Agent 最终在重做它已经做过的工作，因为上一次如何解决问题的记录被九千九百条无关内容埋在了下面。

我称之为囤积，不是记忆。事实的仓库并不等于学会的技能。你可以存储一千条部署日志，下次部署时仍然可能部署错误，因为那些日志没有教给 Agent 任何规则。存了很多，却从未真正学会。

为什么向量数据库解决不了这个问题

我直说了。向量数据库、embedding、RAG 管道，这些都是检索基础设施，不是学习系统。它们回答的是如何找到某样东西的问题。它们不回答什么值得保留、原始事实如何变成可复用判断的问题。

我用向量存储、语义搜索、以及所有光鲜的东西构建了一个系统。它很快，但它没用。为什么。因为我仍在记录一切，所以检索仍然充满噪音。因为我仍将每条记录当作独立事实，所以永远没有模式浮现。因为管道中没有任何东西将重复的教训提升为规则。

基础设施很优秀。方法论缺失了。这就是这篇文章要填补的空白。

转变：记忆是训练数据，不是库存

这里有一句话改变了一切。

一段不能改善未来判断的信息，不值得长期保留。

从这个角度思考，整个设计就变了。记忆不是存放东西的地方。记忆是训练数据。它唯一的使命是让下一次决策更好。如果一条记录不能让 Agent 下次更快、更准确、更谨慎，它就不应该进入长期记忆。

这引出了第二个同样重要的原则。

能够被提升为技能的东西不应该留在日志级别。

日志是原始矿石。技能是精炼后的武器。记忆系统的目标不是积累矿石。目标是不断将矿石精炼成武器。当你这样看待它时，Agent 记忆的整个架构就变了，下面这个四层设计就是结果。

四层架构

我将长期记忆组织为四层。层级越高，越接近已学会的东西。系统的全部工作就是不断将事实向上推送。

第一层，世界事实。这些是协作中稳定的背景事实。用户是谁以及他们偏好的工作方式。项目目录在哪里。部署约定是什么。当前产品方向是什么。这一层不常变化，但每个任务都需要它。它存放在一个名为 MEMORY.md 的文件中。

第二层，经验事实。这些是真实操作的痕迹。这一轮发生了什么。如何定位问题。哪个版本同步到了哪里。哪个管道验证为正常工作。这一层存放在按日期命名的每日日志中，例如 2026-08-14.md，它是上面所有层级的原材料。

第三层，观察。这些是从重复事实中提炼出的模式。为什么某种类型的问题反复出现。某个测试约定在哪个地方容易误判。某种类型的需求如何最可靠地收敛。这一层是记忆开始变成智能的地方，因为它不再关于一个事件，而是关于众多事件背后的规则。

第四层，技能和心智模型。这是价值最高的层级。当一个模式足够稳定且会被反复使用时，它就不再是记忆而是技能。它被压缩成一个技能包、标准操作流程、检查清单或判断标准。从现在起 Agent 调用技能而不是搜索档案。

一个真实例子让这变得具体。我早期工作中遇到一个前端 bug，页面上多个按钮同时停止响应。我将其记录为一条经验事实。几周后它再次发生，症状相同但页面不同。现在我有了两条事实，于是可以形成一个观察：前端多个触点同时失败时，优先检查 JavaScript 语法错误，因为一个损坏的脚本可以拖垮页面上的所有处理器。那条观察成为第四层技能。今天我的 Agent 在多个 UI 元素同时失败时会优先检查 JavaScript 语法。它再也不用重新发现这个教训了。

每个记忆都需要的四个要素

一旦你接受记忆是训练数据，下一个问题就是一个良好形成的记忆长什么样。我要求每条有效记忆条目都包含四个要素，缺少任何一个都会被拒绝。

时间。它何时发生。一个日期、一个版本、一个里程碑。没有时间你就无法区分新旧事实，过时的信息会悄悄毒害决策。

上下文。它在什么任务或环境中发生。部署阶段、测试阶段、哪个项目。没有上下文，一条事实就是一座孤岛，什么都无法与之连接。

结论。事实是什么以及如何解决的。这是真正承载价值的部分。如果一条记录只描述症状而没有解决方案，它不是记忆，是抱怨。

下一步。如何复用它以及后续要注意什么。这是大多数人会跳过的要素，而它正是将记录转变为训练的关键。一条以规则结尾的部署记录——"所有长时间运行的进程必须以后台模式用 nohup 启动，这样它们才能在会话结束后继续运行"——抵得上十条只写着"今天部署失败了"的记录。

五个质量关卡

在写入长期记忆之前，我会用五个关卡审查它。全部通过才能写入，否则该条目不入库。

可复用。这条以后还会用到吗。如果这是一条一次性事实且未来不会再用，它就不属于长期记忆。

有结论。有没有清晰的结论或解决方案。一条只描述发生了什么而没有教训的记录，在这个关卡折戟。

有边界。适用条件和风险是否说明。无脑规则如"总是这样做"是危险的。规则需要说明它在什么时候成立、什么时候不成立。

可检索。以后能找到吗。如果条目没有上下文也没有关键词，它永远不会被检索到，那它跟不存在没什么区别。

有时效。标注了时间或版本吗。新旧信息混在一起会产生虚假的自信。

这五个关卡有一个美妙副作用。它们迫使 Agent 在写入前先思考。大多数糟糕的记忆系统失败，不是因为检索做得差，而是因为写作的门太宽，什么都涌进来。关上门，整个系统就干净了。

生命周期：写入、检索、反思、提升、清理

记忆不是写一次就永久保留的。它有完整的生命周期，包含五个阶段。

写入。按照四要素规则、通过五个质量关卡进行记录。

检索。在后续任务中真正使用它。一条从未被检索过的记忆是摆设。

反思。在多次使用后，提炼出其下稳定的模式。

提升。当模式稳定后，将其升级为技能或 SOP。

清理。过期的、被合并的或已被技能覆盖的记录进行归档或删除。

我按节奏运行这个流程。每天结束时，扫描当天的日志并标记可以提升的条目。每周，汇总观察型记忆并合并重复项。每月，正式将稳定模式提升为技能包。节奏很重要，因为提升不是自动的，它是一种纪律。

三层检索

检索遵循严格的顺序，而这个顺序就是重点。

第一层，先调用相应技能（如果存在的话）。技能是精炼后的武器。如果一个技能覆盖了这类任务，直接用它。不要先在原始历史中翻找。

第二层，搜索近期记忆，即 MEMORY.md 文件和近期日志。

第三层，只有在万不得已时才读取原始日志和历史对话。

这个顺序不能颠倒。大多数 Agent 先搜索原始历史，而这正是它们淹没在噪音中的原因。技能层存在的意义就是让 Agent 不必每次都重新推导教训。当检索失败时，系统不会放弃。它用同义词搜索，它从日 log 扩展到周 log 再到专题报告，如果仍然什么都没找到，那这就是一个信号——记忆记录得很差，系统会写一条关于这个检索盲点的观察，让自身得到改进。

在这个系统上运行数月后，我列出了一份杀死 Agent 记忆的错误清单，每一条都是行为问题，不是技术问题。

错误一，记录一切。认为记录越多记忆就越好。结果是膨胀、检索变慢、有用信息被噪音淹没。修复方法：五个质量关卡。

错误二，记录但从不行动。条目写完后从不回顾、从不提升，所以记忆永远停留在松散日志的状态。修复方法：每日、每周、每月的节奏。

错误三，记录但从不检索。反正下一个任务还是从零开始，所以记忆成了一个博物馆。修复方法：让检索成为默认动作——每次任务开始前先检查技能和记忆。

错误四，永远保留一切。认为删除记忆是一种损失。实际上过期的记忆只会干扰判断。修复方法：按计划清理，保持记忆精简。

你不需要向量数据库就能起步。你需要一个文件加一份纪律。

第一步，创建一个 MEMORY.md 文件，记录关于项目和用户的稳定事实。这就是你的第一层。

第二步，维护一份按日期命名的每日日志，每条经验事实都按四要素来写：时间、上下文、结论、下一步。

第三步，每周结束时，查看每日日志并问自己一个问题。什么模式出现了不止一次。那个模式成为一条观察，而这条观察就是技能的种子。

这就是整个系统最精简的形式。开源项目中的完整版本增加了写作规则、检索技术、生命周期管理、五个质量标准、记忆模板和常见陷阱，全部格式化好，可以直接安装为 Agent 技能。

该方法论名为 Fenglei Memory，其座右铭是：学习，而非存储。它开源、免费，采用 MIT 许可证。

https://github.com/Kim-FengLei/fenglei-memory

仓库包含完整的 SKILL.md 文件，你可以直接安装到自己的 Agent 中，还有一份完整的 README，涵盖架构、工作流和快速上手。如果它对你有帮助，请给个 Star；如果你想自行调整，请 Fork；请将它分享给任何一个 Agent 总是遗忘的人。

你的 Agent 已经存储了一切。是时候教它去学习了。

Built by KIM, Founder of FENGLEI YI, 风雷益, 天施地生，其益无方. Technical exchange, kimsunjian@vip.qq.com.