OpenClaw Dreaming 详解:机制、问题与最佳配置指南

作者：赓金 & 元宝虾 🦐 日期：2026-04-15 基于 OpenClaw 2026.4.14

一、什么是 Dreaming？

Dreaming（梦境）是 OpenClaw 的实验性记忆巩固功能，灵感来自人类睡眠的记忆处理机制。它在后台自动运行，读取日常会话记录，提取有价值的信息，最终将有价值的内容晋升到长期记忆（MEMORY.md）。

默认状态：关闭（enabled: false）。用户需要主动开启。

二、三个阶段的运作机制

Dreaming 模拟人类的三种睡眠状态：

🟢 浅睡（Light Sleep）

参数	默认值
频率	每 6 小时（`0 /6 * *`）
回溯范围	最近 2 天
提取上限	100 条
资源消耗	轻量（fast / low thinking / cheap budget）

作用：快速扫描最近的对话和日志，批量提取可能重要的内容片段（candidate）。

比喻：就像人刚入睡时，大脑快速回顾白天发生的事，但还没做深度加工。

🟡 深睡（Deep Sleep）

参数	默认值
频率	每天凌晨 3 点（`0 3 * * *`）
最低分数	≥ 0.8
最少召回	≥ 3 次
最少不同查询	≥ 3 个
近半衰期	14 天
最大年龄	30 天
资源消耗	中等（balanced / high thinking / medium budget）

作用：从浅睡积累的 candidate 中筛选，只有满足多个条件的才能晋升到 MEMORY.md。

比喻：深度睡眠时的记忆固化——只有反复出现、被多次调用的信息才值得长期记住。

🟣 REM 睡眠（REM Sleep）

参数	默认值
频率	每周日凌晨 5 点（`0 5 * * 0`）
回溯范围	最近 7 天
最低模式强度	≥ 0.75
资源消耗	重度（slow / high thinking / expensive budget）

作用：发现跨会话的模式和关联，把不同天里相似的内容聚合。

比喻：REM 期的"梦境联想"——把看似不相关但实际有关联的记忆连接起来。

三、我们发现的致命问题

问题描述

开启 Dreaming 后，系统产生了大量无用日志，具体表现为：

每日日志被 candidate 塞满：memory/2026-04-15.md 膨胀到 32KB，全是 confidence: 0.62, recalls: 0, status: staged 的 candidate
short-term-recall.json 达到 191KB：装满了从未被召回的碎片
完整对话被抄写：2026-04-14-dreaming-heartbeat-cleanup.md（7.4KB）是 dreaming 把完整会话记录又抄了一份
每次新会话都加载垃圾：因为 startupContext 会自动注入最近 2 天的 daily memory，导致 context window 被无用信息占据

根本原因

Dreaming 的默认输出模式是 inline —— 它直接把候选内容写到 daily memory 文件里（就是 memory/YYYY-MM-DD.md）。而这些文件恰恰是每次新会话启动时会被加载的。

结果：

浅睡不停灌 candidate，但深睡过滤后发现都不够格（recalls 全是 0）
没有一个 candidate 真正晋升到 MEMORY.md
中间产物全部堆积在 daily memory 里
每次 /new 新会话，agent 都带着一堆垃圾醒来

就像一个一直在"半梦半醒"状态的人，翻来覆去就是醒不来，什么事也做不了。

四、官方在 2026.4.14 中的修复

OpenClaw 2026.4.14 版本对 Dreaming 做了四个关键修复：

修复 1：心跳后不再重复回放

在心跳触发 dreaming 前加了双重门控，必须同时满足：

有一个待消费的 dreaming cron 事件
heartbeat body 里包含 dreaming 触发标记

之前 cron 事件被消费后，后续心跳还会再次触发 dreaming。现在不会了。

修复 2：Light Sleep confidence 不再为 0.00

旧版 confidence 只靠召回次数计算，没有召回记录就是 0。新版引入四个维度：

维度	权重	说明
averageScore	45%	原始评分
recallStrength	25%	召回强度
consolidation	20%	巩固程度（新增）
conceptual	10%	概念标签数量

即使 recall = 0，confidence 也不会归零。

修复 3：不再自循环

Dreaming 的叙事报告（DREAMS.md / separate reports）被排除在 ingestion 源之外。之前 dreaming 生成的文件会被下一轮 dreaming 又读进去，形成死循环。

修复 4：Promotion 分数提升

新增的 consolidation 维度（20% 权重）让反复出现的条目能逐步积累分数，最终跨过晋升门槛。之前打分只看 recall count 和 score，重复做梦 revisits 的分数永远卡着。

五、我们的最佳配置方案

经过一天的排查和实验，我们总结出了这套配置：

核心配置

{  "plugins": {    "entries": {      "memory-core": {        "enabled": true,        "config": {          "dreaming": {            "enabled": true,                          // 开启 dreaming            "frequency": "0 3 * * *",                 // 每天凌晨 3 点            "timezone": "Asia/Shanghai",              // 跟随你的时区            "phases": {              "light": {                "enabled": true                       // 浅睡：快速扫描              },              "rem": {                "enabled": true                       // REM：跨会话找模式              }            },            "storage": {              "mode": "separate"                      // ⭐ 关键：分离报告，不污染日志            }          }        }      }    }  }}

为什么用 `"separate"` 模式？

官方默认是 "inline"，candidate 直接写进 daily memory。我们改成 "separate" 后：

	inline（默认）	separate（推荐）
输出位置	daily memory 文件	独立报告文件
是否污染日志	✅ 会	❌ 不会
新会话是否加载	✅ 会加载垃圾	❌ 不加载
晋升到 MEMORY.md	正常	正常

一句话：让 dreaming 的中间产物乖乖待在独立目录里，只有真正通过深睡筛选的内容才写进 MEMORY.md。

配套配置

确保 startupContext 保持开启（默认就是开的），这样新会话能正常加载干净的每日日志：

{  "agents": {    "defaults": {      "startupContext": {        "enabled": true              // 保持开启      }    }  }}

六、清理已有垃圾

如果你已经像我一样被塞满了 candidate，手动清理一下：

# 查看 daily memory 文件中的 dreaming 内容grep -n "Light Sleep\|REM\|staged" memory/2026-04-*.md# 清理掉 .dreams 目录中的旧数据rm -rf /root/.openclaw/workspace/memory/.dreams/*

然后等下一轮 dreaming 重新跑。

七、总结

Dreaming 的设计理念是好的——让 agent 像人一样，通过"睡眠"来巩固记忆。但在 2026.4.14 之前，它的实现有问题：中间产物直接污染了日常日志。

2026.4.14 的修复让它更自律了，但我们仍然建议：

✅ 开启 Dreaming
✅ 设置 storage.mode: "separate"
✅ 保持 startupContext.enabled: true
❌ 不要用默认的 inline 模式

这样才能真正实现：梦里做梦，醒来挑有用的放记忆。

如果你也在使用 OpenClaw，欢迎交流你的配置和体验 🦐