/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 * * *"
          }
        }
      }
    }
  }
}

这里最值得关注的是这两个字段：

• enabled
• frequency

如果你把 dreaming 开启，而不额外改配置，那么它默认会按下面这个 cron 表达式调度：

0 3 * * *

也就是：每天凌晨 3 点执行一次完整 dreaming sweep。

这次 sweep 会按顺序跑完整个后台流程，内部包含：

• light
• REM
• deep

其中只有 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，不只是要“知道你刚刚说了什么”，更重要的是：它要逐渐知道，什么是值得一直记住的。