Agents don't need memory, they need documentation（Agent 不需要记忆，需要的是文档）

📅 2026-10-03 | 🏷️ 工程 & Agent | ⭐ HN 346分/210评论
🔗 原文：https://liao.gg/blog/agents-dont-need-memory
💬 讨论：https://news.ycombinator.com/item?id=49945933

是什么

一篇正面挑战当前 Agent 落地流行范式的长文：与其投入大量工程给 Agent 造「记忆系统」（自动记录、检索、遗忘），不如把 Agent 需要的知识老老实实写成好文档——约定、架构决策、踩坑记录，放进版本库随代码演进。文章引发 HN 346 分、210 条评论的大讨论，是「记忆 vs 上下文工程」方法论之争的最新代表作。

🔍 小白解读

先说几个词

• 记忆（Memory）：让 AI 跨会话「记住」信息的系统，自动存取你说过的事。像给 AI 配了一个随身笔记本，但这个笔记本自己决定记什么、忘什么。
• 文档（Documentation）：人写给人（和 AI）看的结构化说明文件，放在代码库里统一维护。像团队的公共手册，写什么、改什么都有记录。
• 上下文工程（Context Engineering）：设计「每次把什么信息塞给模型」的工程方法论。好比秘书在开会前为你准备的简报夹——放什么、放几页，全有讲究。
• 可审计：出了问题能查到「这条信息是哪来的、谁写的、什么时候改的」。文档天然具备，自动记忆很难。
• AGENTS.md / CLAUDE.md 类实践：在仓库根目录放一份说明文件，向 AI 编码助手交代项目约定——「文档对齐 Agent 行为」已是业界主流做法（公认实践背景）。

这篇到底在说什么

打个比方：很多团队在给 AI 造一个「自动记笔记的实习生」，笔记本记了一堆，但你不知道它记了什么、记错没有、该忘的忘了没有。文章的主张是：与其造这个不可控的笔记本，不如把该知道的东西写成一本大家都能看、都能改、都有版本记录的手册。手册的好处全是工程上的硬好处：写错了能 diff 出来，过时了能提 PR 修，新人（和新模型）来了直接读。而自动记忆系统的每个环节——写入什么、何时遗忘、如何检索、如何验证正确性——都可能悄悄引入噪声，而且错了你还不知道。评论区 210 条讨论证明这个选择确实是当前 Agent 落地的核心分歧点：一派认为「动态的用户状态」必须靠记忆，一派认为 90% 的「记忆需求」其实是「缺文档」。

这跟普通人有什么关系

你用的 AI 助手「记不住你的偏好」或者「记岔了」，多半就是这类系统的锅。对开发者和小公司来说，好消息是：先写好文档这个「笨办法」，往往比买一套记忆系统便宜且靠谱得多。

为什么值得架构师关注

• 直接影响记忆基础设施的投入决策：先做「文档覆盖率」审计，再决定要不要上记忆系统——大部分团队的差距其实在文档侧。
• 文档是可测试、可版本管理、可评审的上下文载体；记忆系统引入的隐式状态是排障噩梦，故障复现率极低。
• 与上篇《default hard budget caps》同读：本周社区共识是「用确定性的工程约束替代概率性的智能方案」。
• 对多 Agent 系统尤其关键：共享上下文的最佳载体目前仍是结构化文档，而非各自为政的记忆库。

核心内容

• 核心论点：Agent 缺的不是记忆，是文档——知识应显式化为人可维护的文档，而非隐式的自动记忆（标题主张）。
• 记忆系统的四大工程难题：写入选择、遗忘策略、检索质量、正确性验证，每一步都可能引入不可观测的噪声（公认技术常识）。
• 文档的硬优势：可审计、可 diff、可评审、可测试，错误可以被定位和修复。
• HN 346 分/210 评论，「记忆 vs 上下文工程」是当前 Agent 方法论之争的最热战场（缓存数据）。
• 与 CLAUDE.md / AGENTS.md 一类的「文档对齐」实践同源，属于该路线的理论化表达（公认实践背景）。

行动建议

盘点项目里给 Agent 用的「记忆」：凡是能用文档表达的（编码约定、架构决策、历史坑），迁移到版本库内的结构化文档；记忆系统只保留真正动态的用户状态。再给文档建立评测——定期让 Agent 回答关键问题，量化文档覆盖率和准确性，把「文档质量」当作和「模型选型」同级的工程指标。