AI智能体的记忆难题：为何现有方案都不够，以及一种新思路

每天打开AI智能体的会话，你大概都在重复同一套动作：粘贴技术栈说明、项目约定、上周二关于认证流程的那个决定、三月份试过但失败的方案。然后你开始工作，会话结束，你花力气建立起来的一切又归零。

这篇文章聊的是AI智能体（AI agent）的记忆系统问题——一个每个重度使用者都在默默忍受、却早已习以为常的痛点。原作者尝试了市面上大多数记忆方案，认为它们都在同一个地方失败，于是自己造了一个。抛开其中明显的产品推广意味，这篇文章对「智能体记忆到底该解决什么」的拆解值得一读。

最聪明的工具，却什么都记不住

作者抛出了一个耐人寻味的观察：你机器上最聪明的那个工具，恰恰是唯一什么都不记得的。编辑器记得你的配置，终端记得你的历史命令，而花费最高、最需要「交底」的智能体，每天早上都从零开始——而你已经和这种状态和解了。

这种「和解」的代价是什么？是你手动维护的 CLAUDE.md 文件，像一个没人真正拥有的 wiki；是关闭会话前的「保存上下文」仪式；是五个 markdown 笔记文件，本质上是你用手工操作的一套记忆系统，服务于一个比你的编辑器还贵的软件。

一个检验记忆系统的核心问题

作者提出了评判所有记忆工具的唯一标准：当下一个 prompt 到达时，智能体究竟知道什么？ 不是存储了什么，不是能查到什么，而是此刻摆在模型面前的是什么。

基于这个标准，他逐一检视了三类现有方案，并指出它们都以同样的方式失败：

Markdown 文件（CLAUDE.md 及其同类）

这类文件在会话开始时加载一次，然后被冻结。你周二写进去的内容，就是智能体一整周所相信的内容。而没人愿意维护它，因为维护本身就是你想逃离的那个手工活。一个月后它就变成杂物抽屉：三条互相冲突的指令、两个项目前的技术栈清单、一条早已失效的备注。它是快照，不是记忆。

需要智能体主动调用的记忆工具

这类工具存储能力很好，但它们在「等着被问」。除非智能体在对话中途决定去搜索、并记得去搜索，否则什么都不会主动送到它面前。会话结束时的交接，取决于下一个会话想到要问什么。作者的比喻很精准：一个你必须记得去用的图书馆，不是记忆。

这类工具的代表包括 LangChain 的 Memory 模块、MemGPT（现更名为 Letta）以及各类基于向量数据库的 RAG 记忆方案。它们的共同架构是：将历史对话或知识片段向量化后存入数据库（如 Pinecone、Chroma、Weaviate），在需要时由智能体发起检索调用，取回语义相近的片段注入上下文。问题的本质在于检索是被动的——依赖智能体在推理过程中判断"此刻我需要查一下历史"，而这个判断本身就需要它已经知道有什么可查。更深层的困境是：智能体越是在处理新问题，越不容易想到去检索旧决策；而恰恰是这些旧决策最可能与新问题产生冲突。

搜索钩子（Search hooks）

较好的方案会在每个 prompt 时推送一些匹配的原始文本片段。这确实是真正的「注入」，但仍然不够——片段是检索，不是简报（briefing）。它们找到的是碎片，不会携带你的既定规则，不会把碎片和你后来做的决定做对账，也不会附带理由。智能体拿到的是搜索结果，而不是被告知「什么是对的」。

三者的共同失败在于：知识存在于某处，但真正重要的那个时刻——prompt 发生的那一刻——几乎什么都没得到。

搜索钩子（Search hooks）通常指在每次 prompt 发送前，由框架层自动触发一次语义检索，将匹配结果拼接到系统提示或用户消息头部，整个过程对用户透明。这比需要智能体主动调用的方案前进了一步——检索变成了自动发生的基础设施，而非可选的工具调用。然而其本质仍是相似度匹配：它找的是语义上接近当前 prompt 的历史片段，而非「对当前任务真正重要的」信息。两者之间存在结构性差距：限流器相关的代码片段会命中「限流器」关键词，但三个月前「我们决定不在网关层做限流」的架构决定，可能因措辞差异而排在检索结果之外。片段本身也不携带元信息——它是什么时候的、当时处于什么决策背景下、后来有没有被推翻——这些都需要额外的结构来承载。

记忆系统应该通过的三道测试

作者给出了他认为合格的记忆系统必须回答的三个时刻，这也是文章最有参考价值的部分：

• 会话开始时：在你开口之前就给出一份简报——上次停在哪、当前生效的规则、计划上接下来是什么。
• 每个 prompt 时：与该特定 prompt 相关的记录随之到达，而不是每一轮都把整个记忆倾倒进上下文窗口。
• 「为什么是这样？」时：决定本身、日期、理由，以及它当初击败的那个备选方案——用当时对话里的原话呈现。

这就是规格说明，其余都是实现细节。这套框架其实为任何做智能体记忆的人提供了一个清晰的需求定义。

一个普通工作日：有「大脑」而非「记忆」

作者描述了实际使用中的一天，用来说明理想状态下的体验：

早晨：开机，打开会话，说一句「继续」。简报已经在那里——上次会话的交接笔记、项目规则、计划的下几行、本项目剧本的索引。不用重新解释，不用「快速回顾一下仓库」。

中午：每个 prompt 到达时已经预先简报好——不是把所有东西都带上，而是只带与该 prompt 相关的记录。问到限流器（rate limiter），关于限流器那段对话的记忆就跟着问题一起来了。作者称自己三月份就停止维护 md 文件，也没有「保存上下文」的仪式，因为整理工作在对话进行时就完成了。

下午：两个智能体在同一个项目上工作，一个负责前端、一个负责后端，各自有自己的密钥，但共享同一份记忆。后端智能体的下一个 prompt 会携带前端对话里敲定的内容。当前端智能体为设置页面提出某个方案时，记忆会代为回答：那个选项在三月份已被否决，这是日期、这是理由，用当时对话的原话。没人会重新争论一个早已死掉的选项。

作者也坦承了一个取舍：注入会消耗上下文。简报和逐 prompt 的记录占用 token，这正是注入的本质。换来的是减少工具调用、对话轮次和翻找。他认为这笔账长期对自己有利。

底层设计：三层结构

这套系统的实现分三层，各司其职：

• 精选记录（Curated records）：当下的真相。系统以每五轮对话为窗口读取内容，保留对话中「敲定」的东西，把新事实和旧事实做对账，悄悄淘汰那些描述已被替换内容的记录。
• 决策图（Decision graph）：记录它是怎么走到这一步的。每个决定一行：带日期、带当时所说的理由、带它击败的选项。翻案是新增一行——历史永不被重写，所以「为什么是这样」总有答案。
• 完整历史（Full history）：全部内容，完整保留，可按关键词或语义搜索。

还有两个实践细节：项目之间彼此隔离，各有自己的记录、规则、图和计划，除非你主动调用跨项目搜索；规则有容量上限，达到 80% 会警告，会导致溢出的保存会被拒绝并给出修复建议，不会悄悄裁剪你写的内容。

隐私方面，作者强调记忆存在你本地机器（本地容器）或其加密云端，处理简报的 hub 不保留任何片段。

这种三层分离的设计思路，与软件工程中「热数据 / 温数据 / 冷数据」的存储分层逻辑颇为相似。精选记录相当于热数据——高频访问、始终保持最新；决策图是温数据——不常改动但关键时刻必须精确；完整历史则是冷存储——低频但需要完整性。值得注意的是「决策图只增不改」的设计：这是一种**仅追加（append-only）**的数据模式，在分布式系统和事件溯源（Event Sourcing）架构中很常见，其核心好处是审计链不可篡改、任意时刻的历史状态均可重建。应用于智能体记忆，意味着「翻案」不会抹掉旧决策，而是以新决策压过旧决策，历史上下文完整保留。这对多智能体协作场景尤为重要——任何一个智能体都能独立核查某个决定的来龙去脉，而不必依赖另一个智能体的口述。

一点冷静的审视

提一嘴，这篇文章本质上是一篇产品推广稿——文末明确给出了安装指令「install brethof-brain」、官网链接以及联盟推广计划（affiliate programme）。因此文中「我们用它运营自己公司」「从四月起每段对话都在、可搜索」这类说法属于单一来源的自述，缺乏独立验证。

但剥离营销外壳，文章对问题的定义——存储 ≠ 简报、检索 ≠ 对账、片段 ≠ 带理由的决定——确实击中了当前多数智能体记忆方案的软肋。对于正在构建或评估智能体记忆系统的开发者，这套「三个时刻」的测试和「精选记录 / 决策图 / 完整历史」的分层思路，比产品本身更值得借鉴。

如果你读到这里，说明你已经把「反复重新解释」当成了工作的一部分。作者的核心主张是：它本不该如此。