Agent 记忆实验：文件多不等于有效

记得越多，AI Agent 就越可靠吗？这篇文章给出的答案是：在持续变化的环境里，旧记录如果一直保留、又没有明确的取舍规则，记忆反而会制造冲突。作者用一个不接入模型的 Python 小实验，说明仅仅改变记忆的写入方式，就能拉开答题准确率。

它值得程序员读的地方，不是那个 100% 的成绩，而是把「模型记性不好」拆成了几个可以检查的工程问题：当前状态存在哪里，历史记录如何退出检索，以及错误记忆有没有独立证据可供纠正。

413 个文件的问题，出在旧状态仍然有效

原文转述了 Anthropic 于 2026 年 11 月 6 日发布的「The components of agent memory」。在 Pokémon Red 约 10,000 步的评估中，Claude Sonnet 3.7 写了 413 个记忆文件，分散在 225 个文件夹里，只拿到 1 枚徽章。Claude Fable 5 则用了 2 个文件夹中的 9 个文件，加一个顶层 global.md，拿到 4 枚徽章。Opus 5.5 也保持较小的记忆目录，并通关了游戏。

两种记录方式的区别，比文件数更关键。Sonnet 3.7 把战斗、物品、NPC 分别存档；Fable 5 的 global.md 保存目标、道馆计划，以及使用记忆的规则。前者更接近经历流水账，后者更接近行动指南。

游戏状态不断变化，详细记录很快过期。到第 10,000 步附近，Sonnet 3.7 连续花了 17 步创建 6 个文件、删除另外 9 个文件，没有执行任何游戏动作。维护记忆开始挤占完成任务的时间。

不过，这组成绩不能单独证明「文件少就更强」。模型不同，判断能力不同，选择保存的内容也不同。作者因此做了一个更窄的实验：去掉模型，只比较两套存档规则，看冲突是否仍会出现。

去掉模型，存档规则还能拉开多大差距

作者称，实验机制用约 80 行 Python 实现，随机种子固定为 1107。世界里有 24 个房间，共运行 8 轮；每轮有 6 条事实变化，例如门上锁、房间进水或守卫移动，代理每轮观察 10 条事实。最后逐个询问房间的当前状态。

检索只用关键词 grep。找到的记录如果对同一事实给出不同答案，就算歧义，答错。

Policy A 每次观察都新增一份笔记，既不修改，也不删除。Policy B 为每个房间维护一份笔记，再观察时直接覆盖，并额外保存一个记录目标的 global.md。

下面是原文单次运行的输出，它展示了文件规模、冲突和准确率之间的关系：

Policy A (log everything):
  notes: 80 files, 240 words
  quiz: 5/24 correct (20.8%)
  questions with conflicting notes: 19/24
  notes scanned per question (mean): 3.3

Policy B (consolidated, no dreaming):
  files: 24 room notes + global.md = 25 files, 54 words
  quiz: 23/24 correct (95.8%)
  notes scanned per question (mean): 1.0
  the one miss: room-07, recorded "open", true value "locked"

Policy B + dreaming:
  notes corrected: 1 (room-07)
  quiz: 24/24 correct (100%)

Ratios: A/B files 3.2x, A/B words 4.4x, A/B scanned per question 3.3x

重点看 questions with conflicting notes: 19/24。A 的文件量只多了 3.2 倍，词数多了 4.4 倍，但多数问题都找到了相互矛盾的答案。它不是没找到信息，而是同时找到了过去和现在的多个版本。

当前状态需要一个明确的有效版本。

B 的优势来自写入规则：同一房间只保留一条当前记录。它并不保证记录必然正确，却消除了同一事实在笔记之间互相打架的情况。

这里也有实验设定的影响。A 没有按时间选择最新记录的能力，出现冲突就直接判错；真实系统可以用时间戳、有效期或版本优先级处理历史。因此，20.8% 对 95.8% 证明的是这两套具体规则的差异，不能扩展成所有追加式存储都表现很差。作者也指出，A 的成绩只略高于在 6 种状态中随机猜测的 16.7%。

Dreaming 能纠错，前提是日志里有别的证据

实验还故意埋了一个错误：第 4 轮，room-07 被误记成 open，实际是 locked，之后也没有再次作为事实被观察。但第 5 轮的原始日志里，出现了「尝试开门，门打不开」的事件。

Dreaming 在这里可以理解为一次离线复核：把整理后的笔记与完整会话记录重新比对。作者的实现只是取最新日志条目的三行循环，凭那条开门失败的记录修正了 room-07，成绩从 23/24 变成 24/24。

纠错依赖的不是反复阅读，而是笔记之外的证据。如果日志里只有那条错误记录，复核也无法凭空恢复真实状态。

原文转述的 Mt. Moon 案例具有相同结构。Claude 错记了 PokéCenter 的位置，走下单向台阶后，又误判了方向。复核会话记录后，它修正笔记，穿过 Mt. Moon 到达 Cerulean City；没有修正的运行则掉下台阶 3 次，最终退回 Pewter City。

Dreaming 也被用于整理知识地图。在 350,000 个文件的内部语料上，经过 128 次整理，会话问答的评分标准达成比例从 13% 升到 48%。wiki 与搜索结合的成绩随 wiki 增长从 54% 升到 61%，单独搜索为 53%，每题约节省 20,000 tokens；需要跨文档推理的并购问题，wiki 为 87%，单独搜索为 73%。

这些结果支持整理的价值，但整理方式也可能损坏信息。合同摘要任务里，多个代理并行覆盖共享表格，只保留了 57 条事实中的 41 条，即 72%；改成每份合同独立建页、逐字引用后，达到 100%。另一份 wiki 甚至长得比原文档还大，被称为「Borges's map」：地图接近原物大小，压缩信息的意义也就消失了。

我的判断

我认同作者把记忆问题落到写入规则上。对 AI 编程来说，过期的接口约定、已经废弃的启动命令、旧目录结构，都可能比缺少记忆更麻烦。检索成功不等于拿到了有效信息。

但这个实验没有复现模型判断。房间状态容易覆盖，项目知识却常常带条件：某个命令只适用于特定分支，某种配置只影响一个运行环境。把这些内容压成唯一答案，也可能删掉必要的上下文。作者同样承认，真实实验里保存策略、经过验证的规则，还是瞬时画面状态，取决于模型如何选择，文件系统无法代劳。

此外，原文只给出固定种子的单次结果，没有提供多种子统计，也没有比较「追加日志加最新版本过滤」等替代方案。它展示了清楚的失败机制，还不足以证明某一种记忆架构普遍最优。Anthropic 的成绩在这里也是作者转述的数据，不能把这个玩具实验当作独立复现。

Claude Code 自动记忆只加载 MEMORY.md 的前 200 行或 25 KB，原文将其与长指令降低遵循程度联系起来。这个限制可以提醒我们控制入口长度，却不是所有系统通用的最佳容量。

能拿来做什么

• 给 AI 编程助手维护项目记忆时，把当前启动方式、接口约定和已验证规则整理成明确的有效记录；信息变化后更新对应条目，避免每次会话都新增一份互相冲突的说明。
• 保留可追溯的会话与执行记录，让整理后的结论能够回查证据。复核时检查命令输出、失败事件和后续修正，单纯让模型重读同一条结论无法可靠纠错。
• 排查记忆检索效果时，除了命中率，也检查同一问题是否返回多个冲突版本，并明确系统如何判断哪一条仍然有效。
• 多个 Agent 整理文档时，可以先按来源分别建页，再生成共享摘要；原文的合同案例提示，并行覆盖同一张表可能丢失事实，但具体收益仍需在自己的任务上验证。