https://jiajia.fun/qa/b956c0a3-%E8%AE%B2%E8%AE%B2-claude-%E7%9A%84%E8%BF%99%E7%AF%87%E6%96%B0%E6%96%87%E7%AB%A0-anthropic-com-components-of-agent-memory

# https://www.anthropic.com/research/components-of-agent-memory 讲讲 claude 的这篇新文章

回复 群友 622 这篇之前有群友问过，完整解读在这里：https://jiajia.fun/digest/3d9bc42bab3319755bffed14 针对你问的，我补充几个我觉得最关键、也最容易被误读的点： 一，它没把 memory 当“存东西”，而是当成一条带纠错闭环的流水线。四个组件里最容易漏掉的是第二个——拿原始 transcript 当 ground truth 去校验笔记。原因是笔记本身从写下来那一刻就可能是错的，Pokémon 那个例子就是：Claude 记错 PokéCenter 在东边，于是判断“Mt Moon 已经过了”，结果掉回原路。没有 transcript 对照，这个错会被一直继承下去，错误还会越滚越大。 二，dreaming（后台空闲时的那种“睡眠式回看”）的价值不只是整理，而是把“当时觉得重要”换成“事后看确实重要”。在线写记忆是当下的显著性判断，离线回看是全局判断，两件事的信息条件完全不一样。这也是为什么它说 dreaming 要耗算力，而且不建议对所有记忆都做——应该聚焦在容易变化的信息上。 三，wiki 的边界要看清。文章里数据很好看，但 gain 全集中在需要跨文档综合的题（87% vs 73%），单文档可检索的任务一点不涨，甚至出现 wiki 比原始文件还大的情况，作者自己拿博尔赫斯那张一比一的地图讽刺了一下。这条对做 pa（personalAgent）很有参考价值：先有 search，再考虑要不要建表示层，顺序反了就是白烧 token。 四，顶层记忆必须小。MEMORY.md 只预加载前 200 行 / 25KB 当索引，细节全往下压。原因很实在——注入的指令越长，遵循率越低。所以 memory 设计的核心矛盾不是“能不能存下”，而是“每轮要背多少上路”。放到 ca（codingAgent）上就是同样的问题：AGENTS.md 越长越不听话。 五，那条按目标调优记忆结构的实验最值得抄。同一批合同，多个 agent 往一张共享表里写，57 条条款只剩 41 条（互相覆盖），标准达成率 72%；改成一份合同一页、单 agent 写、逐字引用，57/57，达成率 100%。这不是“记忆能力”问题，是并发写入和摘要损失的问题。做多 agent 协同沉淀知识库的，这条基本是必踩的坑。 要做的话我建议从最小的那步起：先别搭 wiki，先把 session 日志留下来，跑一个离线的纠正 pass，看它能不能挑出你之前记错的假设。这一步有效，再往上加表示层。