← #813

智能体不需要记忆，它们需要文档

查看原文 HN 讨论

文章摘要

作者 Kevin Liao 在 2026 年 10 月 3 日发文（10 月 5 日更新），批评当下给编程智能体加「记忆」插件的流行做法。他认为整个记忆插件生态都在解决一个错误的问题，并借此推出自己开源的替代方案 Operator Memory。

记忆插件其实都是 RAG。 作者把市面上各种记忆插件拆开来看，发现套路几乎一样：扫一遍会话记录，切成上千条孤立的「记忆」片段，塞进向量数据库；每次提问时取相似度最高的五条注入上下文，不够的话再给智能体一个检索工具。有的插件会多加几样东西，比如逐字搜索历史记录、短期/长期分层记忆、夜里重写记忆的后台「做梦」进程、持续压缩上下文、重排序器等等。作者认为这些都是在消耗 token 给有缺陷的底层架构打补丁，所以没有一个真正靠得住。

召回式记忆的五个毛病。 第一，片段按嵌入空间里的相似度排序，可相似并不说明它是正确的、最新的，也看不出还缺了什么。第二，单条片段装不下背景、动机、教训和环境信息。第三，它把过去当成事实，可代码库每天都在变，关于认证的 500 条旧片段谁知道还有几条准确。第四，智能体不知道自己不知道什么，就算给了检索工具，它也判断不了什么时候该用。第五，存储没法审计：一万条嵌入躺在 SQLite 里，哪些过期了、哪些从没被取用过、哪些是错的还在暗中影响智能体，都看不出来。

该做的是文档，不是回忆。 作者打了个比方：没有人会为了想起某个功能的约束，去重看三年前的会议录像，大家都是把事情写下来，然后查记录。AGENTS.md 已经证明了给智能体提供上下文是有效的，但单个文件只够撑起黑客松级别的原型。智能体需要的是一整个「大脑」，也就是一个结构化工作区，里面有指令、规格、调研、映射关系等，干活前先读，干完再维护。他从 2025 年 8 月起让智能体往 internal/ 文件夹里写规格、计划和索引，后来逐步发展成 Operator。他把 Operator 定位为「上下文引擎」，不算传统意义上的记忆插件：它改造了智能体的工作循环，让「做事前查文档、做完后更新文档」成为每个任务固定的两个阶段。

一个好「大脑」要做到四点。 一是内容：代码已经说明了它在做什么，所以文档只记代码表达不了的东西，比如需求、决策、约束、映射关系、可复用的调研和规范。不然每个新会话都得先花约 8 万 token 去探索代码，最后只能有损地反推出原本的意图。作者拿自己举例：Operator 的 Claude Code 适配器不到 100 行 TS，因为早就定下「逻辑尽量放进 CLI」的架构原则。要是没写下来，智能体很可能图省事把逻辑塞进适配器。二是可发现性：每个会话开始时只注入一份精简目录，说明每份文档讲什么、什么时候该打开，深层内容由智能体按需去读；代码库也生成分层索引，不用反复 ls、grep。三是新鲜度：文档必须由正在干活的智能体趁上下文还完整时写，不交给后台进程；事实变了就直接改写，不追加。四是纪律：智能体写的文档最大的问题是膨胀，它们会反复总结代码、记流水账、编造没人提过的需求。Operator 用调好的指令要求它们只记代码给不了的东西，保持精简，内容跑题时就拆分或合并。不过作者也承认，多数智能体不愿主动拆分或合并文档，好在文档就是 Markdown，审文档和审代码是一回事。

其他好处。 记忆可以提交到 Git，能 diff、能审阅、能回滚；有一个 .operator-shared/ 共享分区可以随仓库提交，同事和云端智能体都能用；不绑定特定的 harness，Claude Code、Codex、OpenCode、Pi 都能接；不需要向量库、嵌入、重排序器，也没有后台守护进程，整套系统就是磁盘上的 Markdown 加一套调好的提示词。作者最后说 Operator 并不完美，他自己也经常要手动让智能体新建、重写或精简文档。

HN 评论精华

讨论有 300 多条，大致分成三派：赞同用文档代替记忆的、觉得这其实也是一种记忆系统的、坚持「代码就是文档」的。其中 kaydub 和多位用户的长篇争论占了很大篇幅。

理论层面的回应

• jdw64 搬出 Peter Naur 的《Programming as Theory Building》：文档本来就装不下程序背后完整的心智模型。不过 AI 和人不一样，它的工作上下文大多得写成显式内容，所以也许能找到另一种维护程序整体模型的办法。他设想以后会更多依赖代数数据类型、状态机和清晰的模块边界，人只需要记住接口。nottorp 补充说，人脑在做项目的过程中会自己「重新训练」，LLM 不会，因为现在重训成本太高。

对文章本身的质疑

• CapitalistCartr 指出作者的批评其实也落在他自己身上：「智能体搜不到自己不知道的东西」，Markdown 大脑也一样有这个问题；文档同样会过时；让智能体更新过时内容，跟他嘲笑的那些「做梦」后台进程干的是同一件事。文章说「经过测试」，却没给出测试。不过他翻了 GitHub 仓库后觉得实现比文章写得好：每个范围都有目录文件，写明每份文档讲什么、什么情况下该读（read_if），会话开始时加载这份目录。
• panarky 提出一个安全问题：Operator 会在你输入第一条提示前，把 .operator-shared/operator.md 和索引文件直接注入智能体指令，优先级还高于 AGENTS.md。如果克隆的仓库或审阅的 PR 里藏了恶意指令，智能体就会自动、悄无声息地执行，可能把 .env、~/.ssh/ 偷走。
• zx8080、cracell 吐槽作者把记忆系统批了一通，最后给出的方案还是一个记忆系统。jrochkind1 认为文章一看就是 LLM 写的，花大量篇幅说别人哪里不行，只用一张流程图带过自己的方案，是一篇平庸的营销文。jookers 认为这就是 Karpathy 讲过的「LLM Wiki」模式。nicwolff 提到 Cline 早在 2025 年 2 月就推出过「memory bank」。stbenjam、jmtulloss、abhinav_sk 都要求拿出评测数据，stbenjam 说：谁能拿出像样的 A/B 评测，他就把帽子吃了。

「代码就是文档」之争

• kaydub 是全帖最活跃的反方：Markdown 文档、决策记录、第三方记忆系统都是浪费时间、污染上下文，项目文档最后都会「过时得一塌糊涂」，而且 LLM 只会追加、不会删除，已经废弃的方案还留在上下文里继续误导。他说自己在清理文档，只保留一个很简短的 AGENTS.md/CLAUDE.md。后来他补充说自己说得有点极端：真正反对的是巨大的决策文件、长期堆积的 Markdown、注释比代码还多，还有各种没有证据的技能和插件，他管这些叫「LLM 版的鲁布·戈德堡机械」。他还举了团队里的例子：一位高级工程师花了 6 到 8 周给仓库迁移写 Claude 技能，只迁了 5 个仓库；两位初中级工程师直接用 Claude，分别迁了 30 个和 10 个。他自测时，一个复杂的 MR 审查技能跑 45 分钟、花 20 美元，效果还不如「原版 Claude + 一段提示词」，后者只要 4 分钟、不到 1 美元。
• JohnBooty 和他来回争论了很久：读会话记录就会发现智能体每次都在重复解决同样的小问题，比如找不到测试账号的凭据、不了解团队「模型保持精简、跨模型逻辑放进 service 对象」的约定。如果每次重新发现要花 5000 token，写进 AGENTS.md 只要 500 token，账很好算。他建议一开始尽量少写指令，看到智能体反复卡在哪里再精简地补上，用不上的就放进按需加载的技能。两人最后吵到人身攻击，不欢而散。chaostheory 引用了 SWE-bench、RepoCoder 等论文支持「上下文有用」，kaydub 反驳说这些都是 2023、2024 年用 Claude 2 那一代模型做的研究。
• enraged_camel、mgfist、smokel 等人认为，代码说明的是「是什么」和「怎么做」，说明不了「为什么」，很多约束根本不在代码里。smokel 举了个例子：咖啡机固件里为什么隔一阵就要拉高 42 号引脚（研磨）？总不能写进 commit message。hbrn 认为拒绝提交 LLM 生成的文档需要一种多数工程师没有的自律，因为生成文档让人觉得很有产出。perrygeo 的看法是：想让 LLM 遵循某种模式，就让代码本身体现这种模式，别光写成文字。

各种实践分享

• crazygringo 在 CLAUDE.md 和每份顶层设计文档开头都强调「只保留当前状态，替换而不是追加」，因为 Claude 默认会把旧段落标成「[DEPRECATED]」再在后面写新版。这样做之后，召回和过时两个问题都基本解决了。他唯一还没解决的是编号：功能编号最后会变成「Phase 9、9b、9e、11」这种。
• zahrevsky 不认同文章里「重看会议录像」的比喻：记忆片段本来就相当于会后笔记。真正的问题是智能体每听一句话就记一条笔记，然后对着 5000 条笔记干活。片段又是不可变、只能追加、没有结构的，条数越多，坏处越大于好处。
• pornel 不信任没经过人审批的智能体规格文档，他说智能体写的 ADR 总会加进他没要求的推测细节，这些内容像回旋镖一样反复冒出来。mzhaase 也说，他做的「决策记录」后来被智能体自己扩写，审查代码时还会冒出「违反 D-236」这种他从没批准过的规则。
• bushido 推荐写「原则」而不是记忆，原则带版本号，代码注释引用时写成 PDD-3@v1 这样。原则一升级，所有依据旧版本做的决定都要重新评估。
• spike021 等人吐槽，明确要求用 jq，智能体还是会写临时 Python 脚本解析 JSON。locknitpicker 认为更危险的是用户会养成条件反射，习惯性地批准智能体用自己的权限执行这些临时脚本。jon-wood 主张这类规则应该用确定性的 hook 来强制执行。
• athrowaway3z 认为 RAG 应该被视为有害：找 Markdown 文件时，路径和文件大小本身就是很有用的信号；RAG 却把五段高度相似的内容整段塞进上下文，让模型的任务更难。yesb 反驳说，这套 Markdown 系统本质上也是一种检索，只是检索方式是针对问题定制的。
• nijave 指出方案缺少时间维度和冲突处理（比如「迁移期间注意某事」，迁移结束后就该失效），也没有把个人偏好和事实分开，而且默认所有智能体都是跑在本地的命令行工具，没考虑服务器上的聊天机器人和事件驱动型智能体。