/dreaming：OpenClaw 的记忆整理机制
/dreaming 是 openclaw 2026.4.5 发布的新功能，是一套全新的“记忆整理机制”。
OpenClaw 本来的记忆结构其实很朴素，它直接存在工作区里的 Markdown 文件中。
MEMORY.md：长期记忆，存放稳定的事实、偏好、重要决策memory/YYYY-MM-DD.md：每日记忆，存放当天的上下文、临时观察、对话过程中的记录DREAMS.md：开启 dreaming 后新增的“梦境日记”，记录 dreaming 的整理过程和摘要
/dreaming真正做的事情是：从 daily memory 里，筛出那些被反复提起、反复召回、跨天仍然重要的信息，再把它们升格进 MEMORY.md。
在 /dreaming 出现之前，OpenClaw 是怎么记忆的？
这是理解这个功能最关键的一步。因为很多人会误以为：“是不是 2026.4.5 之前，OpenClaw 还不会长期记忆？”
答案是否定的。
在 /dreaming 出现之前，OpenClaw 已经有长期记忆，只是形成长期记忆的方式更直接，也更依赖模型当下的判断。主要有两种路径。
1. 对话过程中直接写入
如果用户明确说：
记住我更喜欢 TypeScript。
或者模型判断某件事明显属于长期有效的信息，比如用户偏好、项目长期背景、关键技术决策，它就可以直接写进记忆文件。
如果它认为这是长期知识，就写到 MEMORY.md；如果它认为这只是当天上下文，就更可能写到 memory/YYYY-MM-DD.md。
2. 会话压缩前自动补写
OpenClaw 有一个默认开启的机制，叫 memory flush。当会话接近 compaction，也就是要做上下文压缩之前，系统会先触发一个静默回合，提醒 Agent：
现在快压缩了，如果有值得长期保存的信息，先写进记忆文件。
这一步的作用很现实，防止一些原本还留在上下文窗口里的重要信息，在压缩后丢失。
所以，/dreaming 出现之前，OpenClaw 会记，但更像“当场记录”；缺少一套系统性的“事后复盘和筛选”机制。
/dreaming 解决的是什么问题？
问题不在“能不能记”，而在“记得够不够好”。举个很典型的场景。
假设你这几天一直在和 OpenClaw 讨论同一个问题：
- 第一天：我们项目 API 先用 REST，不用 GraphQL
- 第二天：之前 API 架构怎么定的？
- 第三天：登录接口和 projects 接口当时怎么规划的？
在没有 dreaming 的时候，这段信息当然也可能被记住。
但它是否最终进入 MEMORY.md，很大程度上取决于模型在某一次当下交互里，有没有判断出它足够“长期重要”。
而 dreaming 的逻辑是另一种思路：它不急着在第一次出现时就决定，而是先观察。它会看：
- 这条信息有没有被反复召回
- 每次召回时相关度高不高
- 是不是不同问题都在指向它
- 是不是跨了不止一天，而不是当天偶然被提了很多次
如果这些信号都足够强，它才会认为：这不是一次性的上下文，而是值得进入长期记忆的稳定信息。
也就是说，dreaming 的价值是：更有依据地决定该存什么。
用一个最直观的例子理解 dreaming
假设 daily memory 里有这样一段内容：
# memory/2026-04-04.md
## API 决策
决定采用 REST，不用 GraphQL。
原因：实现简单、缓存友好、团队熟悉。
接口先做：
- GET /users
- POST /auth/login
- GET /projects/:id这段内容最开始只是 daily memory，也就是“当天笔记”。
接下来几天里，用户又不断提到相关问题：
- “之前 API 是怎么定的？”
- “为什么我们没选 GraphQL？”
- “登录接口最初是不是
/auth/login？”
每次问这些问题时，memory_search 都会把这段 daily memory 找出来。
dreaming 看到的不是“这段内容出现过一次”，而是：
这段内容在多天、多轮问答里，被反复召回，而且命中很准。
于是它最终可能把这条信息整理后写入 MEMORY.md：
## 重要技术决策
- 2026-04-04：项目 API 采用 REST，不使用 GraphQL。
原因：实现更简单、缓存支持更好、团队更熟悉。以后再问同类问题，系统就更容易直接从长期记忆里取出这个结论，而不是每次都去翻某一天的流水账。
那什么信息不会被 dreaming 升格？
理解这个边界也很重要。dreaming 不是自动把所有 daily memory 全部搬进 MEMORY.md。如果这样做，长期记忆很快就会被噪音塞满。
通常不会被升格的，是那些一次性、短生命周期、局部上下文型的信息，比如：
- “今天 3:17 把按钮改成蓝色”
- “刚才试了一个命令，失败了”
- “这轮调试先临时注释掉一个函数”
这些信息对当前会话可能有用，但通常不构成长期稳定上下文。所以它们更适合留在 memory/YYYY-MM-DD.md，而不是进入 MEMORY.md。
这个功能要不要手动使用？
要手动开启，但开启之后会自动运行。
当前官方文档里，用户常见的控制命令包括：
/dreaming on
/dreaming off
/dreaming status
/dreaming help也就是说，用户需要先决定：我要不要启用 dreaming。但一旦启用之后，它就不是那种“每次都要自己手动执行一次”的功能了。
开启之后，它是怎么自动运行的？
默认配置里，dreaming 是关闭的：
{
"plugins": {
"entries": {
"memory-core": {
"config": {
"dreaming": {
"enabled": false,
"frequency": "0 3 * * *"
}
}
}
}
}
}这里最值得关注的是这两个字段：
enabledfrequency
如果你把 dreaming 开启，而不额外改配置，那么它默认会按下面这个 cron 表达式调度：
0 3 * * *也就是：每天凌晨 3 点执行一次完整 dreaming sweep。
这次 sweep 会按顺序跑完整个后台流程，内部包含：
lightREMdeep
其中只有 deep 阶段会真正把内容追加到 MEMORY.md。
light：先整理短期材料
这一阶段更像“收拾桌面”。系统会先把最近出现过、被召回过的短期记忆整理出来，做基础归并、去重和候选收集，让后面的流程有一份更干净的候选集合可以处理。
你可以把它理解为：先把最近哪些内容值得关注，初步捞出来。
REM：再提炼主题、联系和模式
这一阶段更像“做联想和归纳”。它不只是看某一句话本身，而是会尝试把多条相关的短期线索联系起来，提取出更高层的主题、模式或反思。
比如零散的问题可能都指向同一个长期主题：
- 用户持续偏好 TypeScript
- 项目 API 一直围绕 REST 决策展开
- 某个联系人在多个上下文里重复出现
所以 REM 更像是：把零散片段组织成有意义的主题。
deep：最后决定哪些内容真正进入长期记忆
这是最关键的一步。到了 deep 阶段，系统才会结合前面的召回证据和筛选结果，判断哪些候选项真的值得写入 MEMORY.md。
也就是说：
light负责收集和整理REM负责归纳和提炼deep负责最终升格
所以这三步像一条逐层收敛的流水线：从短期片段，到主题线索，再到长期记忆。
为什么 dreaming 比旧机制更强？
它把长期记忆的生成，从一次性的主观判断，变成了基于真实召回证据的筛选过程。
在旧机制里，某条信息能不能进入 MEMORY.md，主要取决于模型在某一轮对话中的当场判断。
它可能会判断得很好，也可能会漏掉真正重要的信息，或者把一些只在当下有用的细节过早写进长期记忆。
而 dreaming 的逻辑更像“延迟决策”：先不急着升格，先观察这条信息在真实使用中是否反复被召回、是否跨天仍然重要、是否在不同问题里都发挥作用。等证据足够强，再把它写进 MEMORY.md。
这带来几个很具体的改进。
1. 长期记忆会更干净
旧机制更容易把一些一次性细节写进长期记忆，比如临时调试状态、当天的局部修改、很快就会过期的上下文。
dreaming 通过召回频率、相关度、查询多样性等加权信号做筛选，目标是让长期记忆只保留高信号内容，而不是不断膨胀成一个杂乱备忘录。
2. 升格依据会更稳定
以前更像“模型觉得重要就记”。现在更像“这条信息确实在后续多轮使用中证明了自己重要”。
这意味着长期记忆的形成，不再那么依赖某一次对话时模型的即时判断，而更多依赖真实的复用证据。
3. 更容易保留长期模式，而不是一次性细节
什么是长期模式？
比如：
- 用户长期偏好
- 项目的核心技术决策
- 反复出现的人物关系
- 跨多天仍然会被问到的背景事实
这些内容本来就应该成为长期记忆，但在旧机制里不一定每次都能被及时、准确地升格。dreaming 则更擅长把这类“持续有效的信息”沉淀下来。
4. 更不容易把过期内容写进长期记忆
官方文档提到，promotion 之前会重新读取 live daily note，而不是盲目依赖旧快照。这能降低一种典型风险：
某条内容曾经出现过，但后来被用户修改了、删除了，或者其实已经失效了。
旧机制下，这类信息更容易因为“当时看起来重要”而被写进长期记忆；dreaming 则在流程上更强调 promotion 前再次确认当前版本。
5. 更可观察、更可审计
旧机制很多时候比较黑盒。你知道它记了，但不一定知道为什么记。
而 dreaming 这套流程至少给了更多可观察面：
DREAMS.md- Dreams UI
openclaw memory promote- promotion 候选项和阈值配置
这意味着你可以更具体地检查它是怎么筛选出来的。
没有 /dreaming 的 OpenClaw，也能记忆；有了 /dreaming 之后，它开始更像一个会复盘、会沉淀、会筛选长期知识的系统。
它补上是“记忆整理能力”。
再换一种更形象的说法：
memory/YYYY-MM-DD.md像当天的工作笔记memory_search像翻笔记找线索MEMORY.md像整理后的长期知识库/dreaming像晚上帮你把笔记复盘一遍，决定哪些内容值得永久留下
这就是为什么这个功能看起来不张扬，但实际上非常关键。
因为一个真正能长期协作的 AI，不只是要“知道你刚刚说了什么”，更重要的是：它要逐渐知道，什么是值得一直记住的。
