https://jiajia.fun/qa/82b0f305-%E6%80%BB%E7%BB%93%E8%BF%99%E7%AF%87%E5%8D%9A%E5%AE%A2%E7%9A%84%E5%86%85%E5%AE%B9-%E9%87%8D%E7%82%B9%E8%AE%B2%E8%BF%B0wiki%E6%98%AF%E5%A6%82%E4%BD%95%E9%80%9A%E8%BF%87%E5%AE%83%E7%9A%84%E5%81%9A%E6%A2%A6%E4%BA%A7%E7%94%9F%E7%9A%84-%E4%BB%A5%E5%8F%8A%E4%BA%A7%E7%94%9F%E7%9A%84%E6%9C%BA%E7%90%86

# https://www.anthropic.com/research/components-of-agent-memory总结这篇博客的内容，重点讲述wiki是如何通过它的做梦产生的，以及产生的机理

回复 群友 3131 先说核心：这篇里的 dreaming 指的是模型在空闲时间回看自己的对话日志、整理记忆，并非真在做梦。它的神经科学类比来自海马体睡眠期的 replay：白天的经历先被记录，睡眠时才慢速巩固进皮层。Agent 的对应关系是：session 内先把显著事件写成笔记，session 之间用 dreaming 拿原始 transcript 对照，订正这些笔记、新建表示、再重新组织。 全文把 agent memory 拆成四个组件，先讲清边界：它只指跨 session 保留、从经验得到的可读上下文，不包括改权重、in-context learning 和 compaction（那个是压缩上下文，不是记忆）。 一、session 内写笔记：靠判断什么重要 这是“预测未来需要什么”的动作：写下一条规则，就是断言这个模式以后还会遇到。CL-Bench 数据库任务里，每道题开新 session，只能从持久化的记忆目录取文件。Sonnet 4.6 只到“猜为什么错了”，目录里一堆没验证的猜想；Opus 4.7 开始合并成一份参考文档并标记已核实/未确认；Opus 5 才闭环——每条都带规则、规则的依据，以及自己踩过的坑。 Pokémon Red 那组最能说明“该记什么”：Sonnet 3.7 觉得什么都重要，写了 413 个文件、225 个文件夹，拿 1 个徽章；Fable 5 只写 9 个文件、2 个文件夹加一个 global.md，拿 4 个徽章。区别在于 Sonnet 3.7 把屏幕上每回合都能重读的东西（钱多少、人在哪）也存档了，而这种状态一直在变，很快就过期，最后它 17 步里全在删文件、整理目录，一步游戏都没走。 二、dreaming 的第一个作用：纠错 Pokémon 里那段很具体：Claude 把 PokéCenter 记错在月见山东侧，出门口就写“Mt Moon DONE”，结果掉下单向悬崖，回到来的路，却推断成“我偏西了，其实一直在正确一侧”。dreaming 拿 transcript 核对后发现这条笔记是错的并改写，重新走就直接进了洞，到了 Cerulean City；不纠错那一版来回掉了三次，最后直接放弃。 这里是关键机理：笔记本身不可信，因为它是当时那个 session 视野内写下的、环境一变就会漂移。而 transcript 是 ground truth，所以 dreaming 的价值在于它手里有可核对的底稿，而不只是多一次思考。这也是它和一般“再问一遍模型”的区别。 三、wiki 是怎么被 dreaming 产生的（你问的重点） 机理上分四步，不是一次性生成的： 第一，从散笔记到页面。dreaming 把某个主题的已知内容集结成一页，页与页之间加链接。链接就是那张地图：以后要找东西，靠顺着链接走，而不是全靠语义检索。128 轮那组图里，每个点是一页，线是链接，两轮时稀稀拉拉，128 轮是一张网。 第二，增量维护。第一轮写初始结构，后续每轮只做追加、改写、剪枝。前几轮 Claude 对这套语料的理解像一个新员工，光靠 wiki 答得有限；轮次越多越像老员工。所以 wiki 是一个持续演化的产物，不应被当成一次建库的产物。 第三，多 agent 分工 + 共享日志协调。Stainless 那 35 万文件、约 4.2 亿 token 的语料，128 个 session 里每个 agent 探索一块、写或改页面、合并重复、把结论对回原文。得分数随轮次从 13% 涨到 48%。 第四，第二轮 pass 补缝。第一轮经常链接到还不存在的页面，第二次 dreaming 会把指向缺失页的链接改指到已有页（示例里有 9 处），再补上索引页。 四、收益在哪，边界在哪（这部分最值得记） wiki 加搜索从 54% 升到 61%（只用搜索 53%，纯 wiki 48%），每题省约 2 万 token。但任务类型差别很大：需要跨多份文档综合的 24 道并购题，87% 对 73%；而大部分标准单份文档就能检索到的任务，wiki 基本没增益，甚至膨胀到比原始文件还大——文章用了博尔赫斯那张一比一地图的比喻，抽象没了，白花算力。判断标准很干脆：需要把多份材料合起来、需要判断或算数的，才建表示；能一次检索到的，直接搜。 五、记忆层级与预加载（wiki 的另一半用途） dreaming 还能把某些笔记提到记忆层级顶层，由 harness 在每个 session 开始预加载，模型不用搜、甚至不用知道有东西可搜。代价是要小心做：注入占 token，错笔记会带进每一轮，而且更长的指令文件反而降低遵循率。所以顶层必须小——Claude Code 的 auto memory 只加载 MEMORY.md 前 200 行或 25KB 当索引。dreaming 在这里的主要工作是主动把细节往下层挪，只留链接。 六、按目标调优（工程上最实用的一条） LAB 那组合约题，一开始多个 agent 同时往一张共享表写条款，互相覆盖，57 条只剩 41 条，成文标准达成 72%。后来跑了一个反思循环：Claude 看失败、改“怎么建 wiki”的指令、重建，自己发现条款逐字引用比摘要重要，改成一份合同一页、单 agent 写、逐字引，达成率 100%。 我的判断：这篇真正的贡献其实在于给 dreaming 划出了适用边界。它承认了两个硬限制：纠错要花算力，全量持续核对不现实，所以要么只盯易变内容，要么按访问频率调 dreaming 节奏；以及 session 内记笔记会分走主任务注意力、后台 dreaming 又无法即时可用，这就是个取舍，并非可以两项兼得的免费优化。 还有一点对你做 pa 有直接参考：wiki 属于表示层，它本身不解决问题，价值来自和检索配合。如果你已经在做上下文压缩和 durable workflow，可以把 wiki 理解成“跨 session 的压缩”，但压缩目标应当是能顺着走到的索引结构，并非把原文改写得更短。压缩成一段摘要之后，多跳的问题就答不了了，这也是文章里单文档任务收益为零、跨文档任务收益巨大的原因。 原文的 cookbook 里有 dreaming 和 knowledge wiki 的入门做法，你想动手的话从那里起步比自己搭一套快。