OpenClaw的“梦境”解码:记忆架构该从什么问题出发?

3月底 Claude Code 源码泄漏，社区从 51 万行代码里挖出了一个叫 AutoDream 的隐藏功能——它让 Agent 在后台像做梦一样整理记忆。OpenClaw 团队从中看到了思路，几天后发布了自己的"梦境"功能。今天我们就一起给这两大热门项目解解梦，学习处理Agents记忆的最新思路。

莫名觉得这首歌，很适合今天的话题。

PART 01

为什么大家会突然盯上"梦境"

3月30日，Anthropic在发布Claude Code v2.1.88 到npm时，包里意外带上了一份source map。这份文件相当于一把翻译钥匙，能把混淆后的代码还原成可读的源码。几小时之内，被解码并公开的51万行代码、1900 个文件被镜像到GitHub。

在这堆代码里，社区翻出了很多没有公开过的能力。其中一个引起开发者密集讨论的，是 `services/autoDream/`，一套后台运行的记忆整理系统。

AutoDream这个名字很直白：它让Claude Code像做梦一样，在后台对积累的记忆做合并、修剪和重组。它作为独立子代理运行，对项目代码只读不写，只动记忆文件。

这件事的意义不在八卦。不少开发者是头一次直观地意识到：头部团队已经在正面处理一个被忽视的问题——Agent跑久了，记忆膨胀、互相矛盾，最终拖垮表现。X上不少人的反应是：我半年前就在干这事了，写个cron job定期清理记忆文件，只是没人把它做成正经系统。

OpenClaw团队看到了这套思路，几天后在v2026.4.9里正式发布了自己的"梦境"功能。

众所周知，OpenClaw是目前 GitHub上最火的开源AI助手项目，35万+ stars，72K forks。项目之前就提过"三文件心智模型"：SOUL.md 管身份，MEMORY.md 管经验，DREAMS.md 管整合。"梦境"的落地，既受到AutoDream启发，也是这套自有思路的兑现。

为什么拿它来拆？因为它在 AutoDream 基础上走得更远，它的设计选择能回答一个做Agent 的人都关心的问题：记忆架构的起点到底应该放在哪里。

PART 02

OpenClaw之前的记忆问题

OpenClaw此前已经有记忆系统。daily notes、session transcripts、recall traces，短期记忆的采集不缺。坑在采集之后。

系统能把信息找回来，但找回来的未必值得留下来。没有筛选机制的情况下，假设一条信息被命中了三次，很难判断到底是它确实重要，还是恰好最近的对话反复碰到了同一个话题。

短期和长期之间也没有缓冲带。临时判断、过时结论、带噪音的观察，一不小心就直接写进了持久化存储。进去之后，后面的检索和推理全被带偏。对 Agent 来说，记住一条错误信息，比什么都没记住还糟糕。

Agent的知识状态也在变。上周的正确判断，这周可能过时了。旧判断和新判断同时待在长期记忆里，推理就会自相矛盾。

还有一个问题更隐蔽：写进去了，人看不懂。系统知道自己记了什么，但用户很难判断"这段记忆凭什么留下来"。写入过程是黑箱，短期省事，长期一定出事。你没法debug一个你看不见的决策过程。

Claude Code的AutoDream差不多同一时间被人翻出来，回应的也是同一组问题——Agent 跑久了，记忆必须被治理，否则系统自我退化。OpenClaw从中拿到了方向验证，然后在AutoDream的基础上，做了自己的三阶段方案。

PART 03

"梦境"带来了什么提升

长期记忆的写入变克制了

"梦境"的核心是三阶段流水线：Light（采集去重）→ REM（模式提取）→ Deep（评分晋升）。只有Deep 阶段能动 MEMORY.md，前两个阶段只做整理和信号积累，不碰长期层。

Deep 阶段有一套六维评分：

信号	权重
相关性	0.30
出现频率	0.24
查询多样性	0.15
时间新鲜度	0.15
跨天巩固度	0.10
概念丰富度	0.06

评分之外还有三道门槛同时卡着：综合分 ≥ 0.8、被召回次数 ≥ 3、触发过的不同查询 ≥ 3。全部通过才算过。

被检索过一两次？往外站站吧。得在不同场景下反复证明自己有用，才有资格进长期层。

比如你跑了个code review Agent两周，攒了几百条记忆。"项目偏好 early return"被不同 PR 反复触发过，查询场景多样，综合分过 0.8，晋升进MEMORY.md。"周三那个PR有个拼写错误"只出现过一次，分数很低，留在Light层慢慢过期。以前没这层筛选，两条东西一块儿塞进长期层，拼写错误那条后面就成了噪音。

记忆整理也终于能被人看见了

DREAMS.md是"梦境"写出来的人类可读层。每次Deep阶段完成晋升，系统在DREAMS.md里写一段摘要；REM阶段的主题提取也会记下来。你可以打开它，看到系统某一天提取了哪些主题、晋升了哪些条目，直接diff和review。

DREAMS.md不参与评分。它是个透明化层，让人类能审阅记忆治理过程。AutoDream目前没有对应的东西，这是"梦境"多走出来的一步。`memory rem-backfill`命令能把过去的 daily note 重新推入REM流水线。旧笔记里可能藏着当时不显眼、后来被反复验证的信息，以前沉在底下没人管，现在有了第二次机会。

PART 04

对比一下：AutoDream和"梦境"

AutoDream走的是硬上限路线，超了就修剪，单次最多砍 50%。简单粗暴，但管用。"梦境"觉得这个粒度太粗，不限制文件大小，写入之前先用评分体系把关：综合分够不够、被不同场景召回的次数够不够。当然评分体系也有自己的问题：一个编程助手和一个客服 Agent对"时间新鲜度"的依赖能一样吗？门槛也是硬切的，0.79 和 0.80 之间差了一整个世界。

另一个差异是透明度。AutoDream是个安静的后台进程，干完活不留痕迹。"梦境"多了DREAMS.md，每次整理都写一份摘要。不过说实话，有多少人会定期翻自己Agent的记忆整理日志？透明化这事，得有人真的去看才有用。

Anthropic内部和开源社区已经押了同一注，不能放任记忆自生长。

PART 05

我们做开发的人，能从这里学到什么

值得拿走的是"梦境"和 AutoDream背后的设计视角。

别把"梦境"当成记忆架构的全套方案。你的Agent可能同时需要RAG做检索、需要MemGPT那种方式管上下文窗口。"梦境"管的是另一件事：信息采集完了、还没写进持久化之前，中间那段筛选和整理。

如果你正在设计Agent的记忆架构，有几个问题应该比"用什么数据库"更早想清楚。

你的系统会记错什么？大多数人上来就想容量和召回速度，但记忆架构第一个该担心的是污染。Agent跑得越久，矛盾信息、过时结论、噪音越多。处理不了这些，记忆量越大，表现退化越严重。怎么防，方案各有各的做法，但这个问题必须排在最前面。
然后是写入控制。长期记忆最怕进入太容易。一条信息被检索了一次就能直接写进持久化，这个通道就太宽了。中间得有关卡，不管是阶段隔离、评分筛选还是容量硬上限。
出了问题，你能查到是哪条记忆、什么时候、为什么被写进去的吗？完全黑箱的记忆系统没法debug。人类必须有办法看到记忆治理的过程。

Markdown 还是数据库、JSON 还是向量，这些都是流水线末端的实现细节。真正决定系统好不好用的，是中间那段从"信号"到"知识"的筛选、整理、审阅流程。格式随时能换，治理流程换不了。

PART 06

结语

记忆架构的起点，应该从"怎么让系统只留下真正该留的东西"开始。容量、格式、检索速度，都是这个问题想清楚之后的实现细节。

OpenClaw和Claude Code各自给了一套方案，具体做法你可以参考，也可以自己设计。关键就一个：你的 Agent 记忆系统，有没有一条治理链路。

你们团队在做Agent的长期记忆吗？踩过什么坑、用过什么方案，评论区聊。我们的社区也在持续讨论这类Agent工程问题，后台回复"记忆"可以进群。

面向开发者、创业者、行业方的 AI 学习与项目共创社区。

扎根场景，生长项目。