OpenClaw Memory 系统:四个组件、三层睡眠、一条晋

AI Agent 最头疼的问题不是”怎么做”，而是”上次做了什么”。OpenClaw 用一套记忆管道解决这个问题：先记录会话，再在夜间整理成长期记忆。

我查了源码、配置和实际运行数据，拆解这套系统的真实机制。

四个组件，分工不同

OpenClaw 的 Memory 能力不是单一插件，而是由四个组件组成。但当前真正跑在主链路上的，是 session-memory 和 memory-core：

session-memory 负责捕获会话上下文（Bundled Hook，当前已启用），memory-core 负责 Dreaming 三阶段晋升（Plugin，当前已启用）；active-memory 负责对话时检索注入（Plugin，当前禁用），memory-wiki 负责 Wiki 知识库编译（Plugin，当前未启用，是可选扩展）。

session-memory：自动捕获会话

这是 Bundled Hook，随 OpenClaw 安装自带，当前配置已启用。

触发时机：/new 或 /reset 命令执行时。

工作流程（源码 HOOK.md 第 23-28 行）：

1. 找到上一会话的 transcript
2. 提取最近 N 条 user/assistant 消息（默认 15 条）
3. 用 LLM 生成描述性 slug（如 vendor-pitch、api-design）
4. 保存到 <workspace>/memory/YYYY-MM-DD-slug.md

配置项：

JSON

{"hooks": {"internal": {"entries": {"session⁠-⁠memory": {"enabled": true,"messages": 15/⁠/ 可⁠调⁠整        }      }    }  }}

不需要手动触发，重置会话时自动执行。

memory-core：三阶段 Dreaming 晋升

这是 Memory 系统的核心：定时触发的评分和晋升管道。

三个阶段各干一件事：Light Sleep 扫描日记和会话 transcript，去重相似内容，输出候选列表；REM Sleep 分析候选内容的模式强度，提炼”可能的持久真理”（Possible Lasting Truths）；Deep Sleep 对候选记忆评分，达到三个阈值才晋升——minScore ≥ 0.8、minRecallCount ≥ 3、minUniqueQueries ≥ 3。

当前 cron job 配置为每晚 3AM 触发（expr: “0 3 * * *”）。触发是自动的，是否完成要看当次 cron run 状态。

实际数据（2026-04-20 运行日志）：Light Sleep 产出 40KB 原始候选，REM Sleep 从 329 条记忆中提炼共同主题，Deep Sleep 最终晋升 10 条到 MEMORY.md。

active-memory：对话时检索注入

这个插件在对话开始前运行一个 blocking sub-agent，检索相关记忆注入上下文。

工作机制（openclaw.plugin.json 第 4 行描述）：

Runs a bounded blocking memory sub-agent before eligible conversational replies and injects relevant memory into prompt context.

配置项：

JSON

{"plugins": {"entries": {"active⁠-⁠memory": {"enabled": false,  "config": {"agents": ["main"],"queryMode": "recent","timeoutMs": 15000,"modelFallback": "bailian⁠/⁠glm⁠-⁠4⁠.⁠7"        }      }    }  }}

memory-wiki：知识库编译器

这是独立的 Wiki 系统，可以把 Memory 内容编译成结构化知识库。

三种 Vault Mode（openclaw.plugin.json 第 46-52 行）：

• isolated：独立 vault，不读取 memory-core 数据
• bridge：读取 active-memory 的公开 artifact
• unsafe-local：实验性，允许读取 memory-core 私有路径

Obsidian 集成：

• 支持用 Obsidian CLI 打开 vault
• renderMode 可选 native 或 obsidian（Obsidian-friendly 格式）

数据流：从会话到长期记忆

数据从会话交互开始，经 session-memory hook 提取最近 15 条消息写入日记，进入 short-term-recall.json。以 2026-04-20 当时快照为例：short-term-recall.json 约 604KB、17,369 行，日记文件累计 8 个、约 60KB。随后 Dreaming cron 每晚 3AM 依次跑 Light → REM → Deep。2026-04-20 当次运行中，最终晋升到 MEMORY.md 的是 10 条记录，当时 MEMORY.md 约 40KB。

配置要点

memory-core 晋升条件（可调整）：

JSON

{"plugins": {"entries": {"memory⁠-⁠core": {"config": {"dreaming": {"phases": {"deep": {"minScore": 0⁠.⁠8,"minRecallCount": 3,"minUniqueQueries": 3,"maxAgeDays": 30              }            }          }        }      }    }  }}

active-memory 超时调整（如需启用）：

JSON

{"timeoutMs": 30000,  /⁠/ 增⁠加⁠到 30 秒"queryMode": "message"/⁠/ 只⁠看⁠当⁠前⁠消⁠息⁠，⁠减⁠少⁠检⁠索⁠范⁠围}

关键结论

1. 定时触发
   
   ：Dreaming cron 每晚 3AM 触发，是否完成要看当次运行状态
2. 三阶段晋升
   
   ：Light → REM → Deep 依次执行，每层过滤一轮，最终留下评分最高的记忆
3. 评分驱动
   
   ：不是所有内容都晋升，需要 score≥0.8 + recall≥3 + uniqueQueries≥3
4. active-memory 可选
   
   ：当前禁用，启用需要调整超时配置
5. memory-wiki 独立
   
   ：是可选的知识库编译器，不是 Memory 系统必需组件

实际用下来，session-memory 和 memory-core 是核心，active-memory 看场景需要再开启。