假设你给一个 agent 接上了记忆目录，跑了几周，笔记越攒越多。某天它照着一条笔记信心满满地往前走，结果那条笔记从写下的那一刻就是错的，它自己还没发觉。Anthropic 在 2026 年 11 月 6 日发表的工程文章 The components of agent memory（作者 Lance Martin）用好几组实验讨论了这类处境。读完我的判断是：给 agent 加记忆，写进去很容易，难的是让它记对，记错了还有办法发现。下面的每个数字都只属于它出自的那项评测，我会尽量把范围交代清楚。
Anthropic 对“agent 记忆”的界定很窄：Claude 从经历里得到、跨会话保留、以后能读回来的上下文。模型权重的变化、单次对话里的上下文学习、用摘要替换旧轮次的 compaction，都不算在内。在这个范围里，它谈了几个组成部分：会话中写笔记，事后回看日志重新整理，用 wiki 这类互相链接的页面组织知识，再挑一小部分在每次会话开头直接塞进上下文。事后整理这一步，Anthropic 叫它 dreaming，类比人在睡眠中整理记忆，并把它和 Letta 与 UC Berkeley 研究者提出的 sleep-time compute 联系起来，也就是利用两次交互之间的空闲时间重新组织已有上下文。
Pokémon 里走得更远的，是记得少而准的那次运行
开头这组对比来自 Pokémon Red，每个模型只有一次运行。Anthropic 比较了 Claude Sonnet 3.7 和 Claude Fable 5 各走到大约第 10,000 步时的记忆目录。Sonnet 3.7 几乎什么都记，每场战斗、每件道具、每个遇到的角色常常单开一个文件，按原文它一共写了 413 个文件、分在 225 个文件夹里，拿到 1 枚徽章。Fable 5 只写了两个文件夹里的 9 个文件，外加一个顶层的 global.md，拿到 4 枚徽章。
Anthropic 的解释是，游戏状态一直在变，Sonnet 3.7 的详细记录不停过期，它花在翻记忆上的时间越来越多：大约第 10,000 步时，它开了第四个“master”记忆文件夹，接下来 17 步里新建 6 个文件、删掉 9 个，游戏里一步没动。Fable 5 则把记忆留给游戏不会直接告诉它的东西。钱和位置每回合都能从屏幕上读到，存下来是多余的；策略、计划和验证过的规则只有自己推出来才有，不写下来就没了。另一次运行里，Claude Opus 5.5 也只维护一个小目录，记当前目标和下一步，边玩边改写，最后通关。
两次运行谈不上定律，但它给了你一个能直接试的取舍：环境里随时查得到的状态，抄进记忆只会多出一份要维护的副本；更值得写的是 agent 自己花代价得出的结论。
在这项问答测试里，Opus 4.7 和 Opus 5 只需知道用途，一条硬规则反而拖后腿
第二组实验用的是 Continual Learning Bench 1.0 里的一个数据库问答任务。每道题都在一个全新会话里开始，唯一跨会话保留的是一个记忆目录；答完以后，Claude 会被告知正确答案，可以写笔记帮以后答题。理想的用法是一个学习循环：答错了就记下来，提出原因，验证原因，再把结论写成规则。
不同模型在这个循环上走到了不同位置。Sonnet 4.6 只走到提出猜测，目录里散着一堆没验证过的想法。Opus 4.7 把笔记并成一份参考文档，开始标注哪些事实核实过。Sonnet 5 会在评分确认后把答案标成已确认，答错时写更正。按 Anthropic 的说法，Opus 5 是这几个模型里率先把循环跑通的，多数条目写明了规则、怎么知道这条规则成立，以及踩过的坑。Opus 5.5 和 Sonnet 5.5 也跑通了，用上记忆后的得分和 Opus 5 差不多，只是它们不用记忆时的基线略高。
引导方式的结果有点反直觉，但同样只出自这项任务。Anthropic 只告诉模型“有一个记忆目录可用”，这对 Opus 4.7 和 Opus 5 就够了，两者都因此明显得分更高。Anthropic 还逐条测试过关于该记什么的规则，原文给出结果的是“只记录失败”这一条：加上它以后，Opus 5 和 Opus 4.7 都丢掉了记忆带来的大部分提升。对 Sonnet 4.6 则相反，提示它先读记忆再答题、并明确验证自己的猜测，分数接近翻倍。这项任务里，Sonnet 5 不用提示，10 次里有 9 次会先读记忆，Sonnet 4.6 不到一半。
这些结果说的是几个 Claude 模型在一个数据库问答任务上的表现，Anthropic 自己的概括也只到“对更强的模型，让它自己判断什么值得记，比事先定死规则更有效”。换成别的模型或别的任务，结论未必成立。我能给的建议是：别默认一套写法规则对所有模型都好，换模型时把“只给用途”和“写明先读再答、验证再写”两种提示都测一遍。
Pokémon 里那条错笔记，是对照会话记录改过来的
模型判断得再好，也是在当下猜未来需要什么，笔记可能一开始就错，也可能随着环境变化而过期，而下一次会话会照样相信它。Anthropic 举的例子来自一次用 Managed Agents、挂载了记忆目录的 Pokémon 运行，地点是 Mt. Moon。这片洞穴入口在地图西侧、出口在东侧，入口附近有一道单向的坎，掉下去就回到来时的路上。Claude 拿洞口的 PokéCenter 当地标，却在笔记里把它写在了东侧。走出 PokéCenter 时，它说 “Mt Moon is behind me”，并把笔记改成 “Mt Moon DONE”。几步之后它跌下那道坎，导航工具又显示不出落差，于是它认定自己只是“往西走过头了”。
没有纠正的那次运行里，Claude 三次跌回原路，第三次后写下想停下来别再兜圈子，被实验设置的自动回复要求继续，结果一路退回 Pewter City，整场都没到达 Cerulean City。Anthropic 随后对那份写错的记忆目录跑了一次 dreaming：Claude 拿笔记去对照当次会话的完整记录，发现了错误并改写。带着改正后的笔记，它直接回到洞里，最终到了 Cerulean City。在这个例子里，会话记录给了笔记一个可以对照的事实依据。
这项能力已经出现在 Anthropic 的产品文档里，但仍是研究预览。按 Claude Managed Agents 的 dreams 文档，一次 dream 读入一个已有记忆库和 1 到 100 个历史会话，输出一个新的记忆库，原来的不动，由你看过再决定用还是丢；费用按所选模型的标准 token 价计算。记忆库文档还提醒了另一种写坏记忆的方式：记忆库默认可读写，如果 agent 处理不可信输入，一次提示注入就可能把恶意内容写进去，后面的会话会把它当成可信记忆来读。文档建议，参考资料和 agent 不需要修改的库挂成只读。
Anthropic 同一天发表的 Project EVE 是另一项研究，由 Frontier Red Team 做，测的是 EVE 网游里的交易和多 agent 协作，不是记忆系统。它记录的一类失误可以放在旁边参照：EVE Frontier 里的 Claude 团队跳过核对时，犯下了一些代价最大的错误，比如以为一份稀缺资源已经到手，或者照着过时的情报行动。这只是我的读法，不是 Anthropic 的结论，两项研究的设置和指标都不同，不能互相印证数字。
wiki 在要跨文档拼答案的题上有帮助，单文档任务里看不出好处
wiki 是 Claude 自己写、自己维护、互相链接的一组页面。Anthropic 用 5 月收购的软件公司 Stainless 的内部文档先做了一项测试，约 35 万个文件、约 4.2 亿 token，配 25 道题，并给了 Claude 一个搜索工具。Opus 5 agent 在 128 个会话里接力探索文件、写和修 wiki 页面、合并重复内容、对照原始文件核实说法。随着 dreaming 从 2 个会话扩到 128 个，这 25 道题的得分从评分项的 13% 升到 48%；原文另说，只用 wiki 答题时的最好成绩是 48%。同时用搜索和 wiki 时，得分随 wiki 长大从 54% 升到 61%，只用搜索是 53%。原文还说搜索加 wiki 每道题省下约 2 万 token，但没写明是跟哪种做法比。
为了看哪类任务适合用 wiki，Anthropic 又用了两组材料：一组并购文档配一套问答题，以及 Harvey 的 LAB 基准，后者让 Claude 读一批文档写法律简报，再按评分清单打分。并购问答共 24 道题，超过一半要从几份文档里找信息，很多还要判断或计算。87% 对 73% 这组数字只针对这些需要跨文档、判断或计算的项目，也就是原文图中红线和橙线标出的部分：用 wiki 得 87%，只用搜索得 73%，不是 24 道题的总成绩。LAB 那边是另一回事。在一项评分点大多能从单份文档里直接搜到的 LAB 任务上，wiki 相对搜索看不出明显优势；在另一项 LAB 任务里，wiki 写得比原始文档还大，等于什么都没有提炼。
写法也决定 wiki 会不会丢东西。LAB 里有一项任务模拟公司收购，提供一批合同，简报按合同条款写得对不对来评分。起初几个 agent 同时往一张共享的合同条款表里写，互相覆盖，条款也概括得不好，用这份 wiki 生成的简报只包含了 57 个评分事实中的 41 个，约 72%。Anthropic 让 Claude 循环反思失败、修改建 wiki 的指令、重建 wiki，最后改成每份合同由一个 agent 单独写一页、条款逐字引用。用改进后的 wiki 生成简报，评分标准可以 100% 满足，图注写的是 57 个事实全部保留下来。
这几项结果只覆盖 Anthropic 选的这几组文档和任务。能稳妥带走的是一个判断方法：如果你的问题常要跨几份文档拼答案，值得试一份 wiki，并留着搜索一起用；如果答案通常就在某一份文档里，好的搜索可能已经够。多个 agent 共写同一页时，先想好怎么防止互相覆盖。
每次都加载的那一层要尽量小
最后一个组成部分是把少量笔记“提拔”到顶层，在每次会话开头直接注入上下文，这样 Claude 不用去搜，甚至不用知道有东西可搜。Anthropic 对此相当谨慎：注入的内容要占 token，一条错笔记会被带进每一次会话，而且装进去也不等于会照做，Claude Code 的文档就提醒过指令文件越长、遵循得越差。所以顶层要保持相对小，dreaming 在这里的主要工作是把细节往下移，只在顶层留链接。
Claude Code 的 auto memory 就是这么做的。每次会话开头，它只加载 MEMORY.md 的前 200 行或前 25 KB，以先到者为准；这个文件是一份索引，每条记忆一行，具体内容放在单独的主题文件里，需要时再读。文件写得超过上限时，写入仍然成功，但 Claude Code 会返回错误，让 Claude 重写这份索引，因为超出的部分下次不会被加载。
这些数字都来自 Anthropic 自己的评测，各项评测的任务、模型和评分方式都不同，Pokémon 的对比各只有一次运行，目前没有独立复现；文章也没有给出 dreaming 的算力成本。什么时候写记忆、多久做一次 dreaming、要不要干脆以会话记录检索为地基，Anthropic 自己也列为未解决的问题。所以别把这些百分比当成你系统里的预期收益，把它们当成值得去试的设计方向。
如果你正在给 agent 做记忆，我会先做四件事。给每类记忆留一个能核对的依据：从会话里得出的笔记，保留原始会话记录；从文档里整理出的 wiki，回到原始文档去核。常驻上下文的那一层只当索引，可以参考 Claude Code 给 MEMORY.md 定的 200 行或 25 KB 上限来控制规模。定期跑一次核对，Anthropic 提到可以优先查容易变化的信息，或按记忆被读取的频率安排节奏。会处理不可信输入的会话，先问一句它是否真的需要写记忆，不需要就挂只读。记忆系统常见的毛病，往往不在记得太少，而在记错的东西一直没人回头去对。