一文讲清楚 AutoDream：Claude Code 是如何-做梦-，更新记忆的？
公众号名称：三元同学
作者名称：三元同学
发布时间：2026-05-07 08:15
Claude Code 用了一段时间的人，应该都对它的 MEMORY.md 有印象——它会自己往这个文件里写笔记，记下你是谁、项目在做什么、踩过哪些坑。下次开新会话的时候，这些信息会自动加载到上下文里，让 Agent 不用从零开始认识你。
但你有没有想过一个问题：用了一两个月之后，这些记忆会不会越积越多，最后变成一锅粥？
我之前一直好奇这件事。直到最近研究下来发现，包括去翻之前泄露出来的部分源代码，Anthropic 给这个功能起了个非常飘逸的名字——AutoDream，自动做梦。
名字听起来挺玄乎，但它本质上在解决一个所有 Agent 都会遇到的问题：怎么管理好长期记忆。
为什么记忆需要”整理”
这得从 Agent 记忆系统的两个老大难问题说起。
第一个叫记忆膨胀。你上周跟 Agent 说”这个项目用 PostgreSQL”，前天又说了一次”PG 16 升级了”，昨天又补了一句”我们改用 RDS 托管”。三条记忆都还在，指向同一件事但有时间维度的演化。不整理的话，下次 Agent 检索”这个项目的数据库”，三条全捞出来塞进上下文——浪费 token 不说，模型还可能被矛盾信息搞困惑。
第二个叫记忆过期。你两个月前告诉 Agent”目前主要做 Stripe 集成”，后来项目转向了，你没专门跟它说”不做了”。这条记忆就一直挂着，下次相关讨论时还会被检索出来，误导决策。
Mem0 2026 年的报告给过一个数据：33% 的记忆事实在 90 天内变得不准确。你的 Agent 跑一年还在用半年前的记忆做判断，那错误率会非常高。
所以记忆系统不能只管”存”，还得管”整理”。AutoDream 解决的就是这件事——让 Agent 在空闲的时候自己整理记忆，把该合并的合并，该删的删。
类比一下人类大脑：你白天经历的事情，并不会原封不动地保留下来。睡觉的时候大脑会把短期记忆按主题归档，删掉不重要的，强化重要的。Anthropic 管这个功能叫 Dream，挺贴切的 :）
先上一张全景图，有个直觉再往下看。
先看看记忆长什么样
在聊 AutoDream 怎么整理之前，先看看它整理的对象——Claude Code 的记忆文件——长什么样。
打开你项目里的 ～/.claude/projects/<项目名>/memory/ 目录，大概是这个结构：
.claude/projects/<项目名>/memory/
├── MEMORY.md ← 索引文件，200 行上限
├── user_preferences.md ← 用户偏好
├── project_database_stack.md ← 项目技术栈
├── feedback_testing_policy.md ← 行为反馈
└── reference_linear_board.md ← 外部资源指针MEMORY.md 是索引，每一行指向一个具体的记忆文件：
- [用户偏好](user_preferences.md) — 偏好 TypeScript，不喜欢写注释
- [数据库技术栈](project_database_stack.md) — PostgreSQL 16 on RDS
- [测试规范](feedback_testing_policy.md) — 不要 mock 数据库每个记忆文件则是一段带 YAML frontmatter 的 Markdown，里面存着具体内容。
AutoDream 整理的就是这堆文件——合并重复的 topic 文件、更新过期的事实、保持 MEMORY.md 索引精简。搞清楚这个结构，后面讲整理逻辑就好理解了。
它不是真的”每天晚上”跑
先纠正一个误区。AutoDream 不是设了个闹钟凌晨三点跑。它的触发方式更聪明——每次你跟 Agent 聊完一轮，它就在后台悄悄检查一下”该不该做梦了”。
但整理记忆的开销不小——要 fork 一个子 Agent，读文件、写文件、调 LLM。不能每次聊完都跑一遍，太贵了。所以它设计了三道检查，从便宜到贵排列，任何一道没过就直接跳过。
第一道检查是看时间。 距上次整理不到 24 小时就直接跳过，这个检查几乎零成本，就读一下文件的修改时间。
第二道是看有没有新内容。 24 小时够了，但这段时间你可能压根没怎么用 Agent。它会扫一下会话目录，发现新增或改动的会话不到 5 个的话，也跳过——没多少新东西，不值得跑一次完整的整理。
第三道是拿锁。 前两道都过了，说明确实该整理了，但还得确认没有别的进程在跑。锁机制挺巧妙的——一个文件同时干两件事：文件的修改时间就是”上次整理时间”，文件内容写着当前跑整理的进程 PID。这个 PID 非常重要，它意味着是否当前有进程在操作这个文件，如果没有的话才能拿到锁，否则可能就会产生冲突。
大部分时候第一道就挡住了，而一次 stat 系统调用是纳秒级的。只有极少数情况才会走到”拿锁”这一步。
梦里做了什么
三道检查都过了，接下来正式开工。Claude Code 会 fork 出一个子 Agent，给它一段专门的整理 prompt。
这个子 Agent 会受到一些严格的限制。它只能用只读的 Bash 命令——ls、grep、cat 这些可以，任何写入操作都会被拒绝。它能改的只有记忆目录里的 .md 文件。这从工具层面保证了”做梦”不会弄坏你的项目。
整理 prompt 分四个阶段，每个阶段干的事情都不一样。
先认路。ls 一下记忆目录，读一遍 MEMORY.md 索引，扫一遍已有的 topic 文件。这一步的目的是搞清楚”已经记了什么”，避免后面创建重复的记忆。
然后找新信号。 看看最近有没有值得记住的新内容。主要是两个方向：一是看看已有的记忆跟代码现状有没有矛盾（比如记忆写着”用 MySQL”但代码里全是 PostgreSQL），二是必要时去 grep 会话历史找特定细节。
接着做整理。 把找到的新信号写到对应的 topic 文件里。写入的时候有三大原则：
-
优先合并到已有文件而不是创建新的；
-
“昨天""上周”这种相对日期转成具体日期；
-
如果发现某条事实已经过时了，直接改掉对应的记忆文件。
最后这点值得强调一下，Agent 不是只往里加东西，它有”删除”的权力。 这是 AutoDream 跟普通”记忆累加”最本质的区别。记忆系统最怕的不是记得少，是记了一堆错的还不删掉。
最后修剪索引。MEMORY.md 是记忆系统的目录，必须保持精简，Claude Code 里面有一套硬性约束——200 行上限、25KB 上限，每条不超过 150 个字符。如果有条目超长了，说明把内容写进了索引文件（索引应该只存内容的路径），需要拆出去。
几个值得记住的设计细节
做梦复用了主对话的 Prompt Cache。 Fork 出来的子 Agent 跟主对话用同一段 system prompt，前缀完全一致，cache 直接命中。所以做梦本身的 token 成本极低——大部分 input token 走的是缓存价格。
做梦的过程对用户透明。 子 Agent 跑完后，主对话里会插一条消息：“Improved memories: X.md, Y.md, Z.md”。你知道后台动了哪些文件，想看就去看，想改随时改。
你也可以手动触发。 输入 /dream 就行，跟自动触发走同一套整理逻辑。区别是手动触发有完整的工具权限，不受”只读工具”的限制。
回到这个名字
讲完了实现，我觉得”Dream”这个名字起得确实好。
人在睡觉的时候，大脑会做记忆巩固（memory consolidation）——把白天的短期记忆按主题分类、删掉不重要的、强化重要的。海马体把信息搬到大脑皮层，形成长期记忆。
AutoDream 做的事跟这个过程一一对应：白天积累的对话变成 topic 文件，按主题合并到已有记忆，删掉过期的事实，索引保持精简。甚至触发周期都像——大脑每晚做一次，AutoDream 每 24 小时做一次。
当然记忆本身不止于这些问题，还有生命周期管理、记忆投毒、语义化召回等等问题，这里不展开，更多内容可以去我的 Agent 付费课程里面报名解锁，里面系统讲 Agent 六大支柱，并且有从零带你实现生产级 Agent，每一步都能跑起来，感兴趣可以加我微信 sanyuan0704 备注”agent 学习”。
Hermes Agent 也在做干类似的事
AutoDream 不是唯一一个做这件事的。
最近爆火的 Hermes Agent（Nous Research 出品，GitHub 109K star）有一个叫 Curator 的功能，思路一脉相承但做得更系统化——它不只整理记忆，还整理 Skill（Agent 从经验中提炼的操作指南）。Curator 会给每个 Skill 打分、合并重复的、归档长期没用的，每 7 天自动跑一次。
Curator 的实现里还有一些 AutoDream 没有的设计，比如空闲检测触发、Skill 的 active → stale → archived 生命周期、以及让用户 Pin 住重要 Skill 不被自动清理的机制。
这些细节明天那篇我们好好聊。
如果你对 Agent 的”自我维护机制”这个话题感兴趣，可以期待一下。我是三元同学，我们明天再见：）
原创 三元同学 三元同学