我那条每天自动跑的 AI 日报流水线,三个月下来攒了五十多个 Markdown 文件,一个日期一个。上周我要回溯三周前的一个判断,直接打开文件目录搜关键词,十秒钟翻到了原文。
差不多同一时间,我给另一个 agent 接了个记忆插件。它存了上万条嵌入,我问它六周前那个决定是怎么来的,它回给我五条相似度最高的片段,加一句「可能相关」。
这中间隔着的不是记性好不好,是能不能查。
给 agent 装记忆,是给它一台抽奖机;给它一间能读能写的档案室,才是给它脑子。
10 月 3 日,Kevin Liao 发了篇《Agents Don't Need Memory. They Need Documentation.》,在 Hacker News 拿到 266 分。他把市面上所有记忆插件拆成同一个五步套路:扫会话、切片段、存向量库、每次提问取最相似的五条注入、不够再给个搜索工具。然后他列了五个绕不过去的问题,我挑三个最要命的。
相似度只排序距离,不分辨对错和新旧。片段装不下动机与环境,一段关于「认证」的记忆,你不知道它是定稿还是当时被否掉的方案。最麻烦的是不可审计:库里一万条嵌入,哪些存在、哪些过期、哪些从来没被检索过、哪些是错的却一直在影响 agent 的判断,你一条都答不上来。
翻译成架构语言,这就是一个没有过期机制、没有结构约束、没有审计接口、写入方还完全不受控的隐式全局状态。
这种东西我在传统系统里一次都不会让它过评审。可一旦前面加上「agent 记忆」四个字,大家就觉得它理所当然。
我自己那条流水线恰好是个反例。它没有向量库,没有自动摘要,没有半夜起来整理记忆的后台进程。就是每天往一个目录里落一个文件,周报读最近七天的文件,月报读周报。
能打开、能搜索、能改、能删、能提交进版本库,这五件事加起来才叫记得住。
三个月前的一个结论为什么这么下,翻文件就在,不用问谁,也不用祈祷相似度算得准。
Kevin Liao 给的替换方案很朴素:把 agent 的循环从「提问、干活、忘记」改成「提问、查档、干活、回写」。工作前先读相关的文档,干完把过时的地方改掉、缺的地方补上。
同一天,GitHub Trending 上 thedotmack/claude-mem 单日涨了 627 星,总星数 95.9k,走的正好是相反那条路:捕获会话、AI 压缩、回注上下文。两条路线在同一天各自爆发,说明这个分叉社区还在投票,没收敛。
但另一边的量化证据已经出来了。Airbnb 的 CTO Ahmad Al-Dahle 在 10 月 2 日接受 Latent Space 专访时说,公司内部有个叫 Everest 的上下文图,做的是同一件事:把踩过的坑从人脑和会话记录里搬到一个可检索的地方。效果很具体,杂货配送服务的第三方 API 集成花了八到九个月;把模式与代码交互索引进 Everest 之后,另一拨人做机场接送这类同构集成,只用了约六周。他还给了个数:Airbnb 现在 60% 的代码由 AI 产出。
九个月到六周,压缩掉的不是编码时间,是「重新搞懂一遍」的时间。
这让我想起去年重构 AI 巡检后端的事。我把服务之间互相发 HTTP 请求的结构改成四层架构,第一件事不是写代码,是定规矩:业务层里不许出现框架的上下文对象。原因不是那个对象危险,而是不该出现的依赖,一旦允许它出现,就再也收不回来。
边界要写在载体上,不能写在约定里。 agent 的记忆也是同一条道理。你把「它该知道什么」交给向量的概率性回忆,这个边界就永远收不回来;你把它写进一组有读写契约、能评审、能回滚的文件,边界才真的存在。
我不是说检索没用。合理的分层是文档当主干,可审计可评审;检索当补充,覆盖长尾。
但补充层必须带来源引用和时间戳,不能是一段不知道从哪次会话掉出来的裸文本。
第一件,给记忆库做一次体检。 列出里面到底存了什么,标出哪些超过一个月没人检索过,哪些内容已经和当前代码对不上。列不出来本身就说明问题。
第二件,在仓库里建一个 agent 专属的文档目录。 不用复杂,指令、决策、外部接口的踩坑记录各一个文件就够。然后在 agent 的启动规则里加两条:干活前先读相关文件,干完把过时的地方改掉。
第三件,把「必须能解释」写成硬规矩。 Airbnb 的做法是,每个工程师都要能解释自己交付的每一行代码,哪怕整个 PR 是 AI 写的。
这条规矩不是针对 AI,是针对产出变便宜之后,理解成了唯一稀缺品这件事。
产出成本趋近于零的时候,筛子就只剩「你能不能讲清楚」。