一次把新版本记忆能力移植进旧版 OpenClaw 的实战不升级主程序只在 workspace 层外挂 Light / REM / Deep 三阶段记忆巩固系统并把旧记忆链路收口成单一主线。一、为什么要折腾这件事OpenClaw 新版本里有一个很有意思的实验性记忆功能Dreaming。它不是简单做语义检索而是试图把“短期记忆 → 长期记忆”的过程拆成三个阶段Light整理、去重、暂存候选REM做主题归纳和模式反思Deep真正决定哪些内容值得进入MEMORY.md这个思路很对我胃口。因为很多 Agent 系统的“记忆”其实只有两种纯检索纯追加前者只会找后者只会堆。时间一长MEMORY.md要么越来越乱要么越来越依赖人工维护。但问题是我当前线上跑的是旧版 OpenClaw 2026.3.8不想直接升级。原因很简单线上已经有一堆 cron、provider、脚本和消息链路在跑一升级可能连带影响 gateway、cron、模型路由、插件行为很多时候生产环境最怕的不是“没有新功能”而是“为了一个新功能把一整套稳定链路搞乱”所以我选了第三条路不升级主程序直接把 Dreaming 的核心能力外挂到当前系统二、先确认官方 Dreaming 到底是什么动手前先去查官方文档和 CLI 说明而不是凭印象乱抄。核到的关键信息大概是这样1Dreaming 的输出分两类机器状态memory/.dreams/人类可读输出DREAMS.mdmemory/dreaming/phase/YYYY-MM-DD.md长期记忆只有 Deep 能写MEMORY.md2三阶段职责很清晰Light读取近期短期记忆去重、整理、暂存候选记录强化信号不写MEMORY.mdREM做主题归纳提取模式和反思输出到DREAMS.md不写MEMORY.mdDeep用加权评分给候选排序通过阈值门后才允许晋升到长期记忆只有 Deep 写MEMORY.md3官方 Deep 用的是六维加权信号frequencyrelevancequery diversityrecencyconsolidationconceptual richness4CLI / UI 在新版里是现成的文档里能看到这些接口openclaw memory promoteopenclaw memory promote --applyopenclaw memory promote-explainopenclaw memory rem-harness/dreaming on/dreaming off/dreaming status看起来非常完整。三、真正的关键旧版本有没有这些能力我在当前机器上直接查当前版本OpenClaw 2026.3.8openclaw memory --help结果只有indexsearchstatus没有promotepromote-explainrem-harness这就意味着一件事旧版本里没有现成 Dreaming 功能不能靠开开关解决所以如果还想要这套能力只能自己补。四、外挂方案不改主程序只在 workspace 层加一套 Dreaming我最后采用的是一种很稳的做法不碰 OpenClaw npm 主体不升级主版本只在 workspace 里外挂一层记忆巩固系统这样做有几个好处不影响当前 gateway / provider / cron 主链路出问题也容易回滚逻辑都落在自己可控的脚本和文件里能复用现有MEMORY.md、memory/YYYY-MM-DD.md、cron 体系最终目录结构1配置config/dreaming.json2主脚本scripts/dreaming.pyscripts/dreaming_status.py3机器状态memory/.dreams/phase-signals.jsonmemory/.dreams/candidates.light.jsonmemory/.dreams/promoted.json4人类可读输出DREAMS.mdmemory/dreaming/light/YYYY-MM-DD.mdmemory/dreaming/rem/YYYY-MM-DD.mdmemory/dreaming/deep/YYYY-MM-DD.md五、怎么在旧版上复刻三阶段1Light先把“短期材料”整理成候选池旧版本没有新版那种完整 recall trace所以我不能百分百照抄官方内部实现。我采取的是一种更接地气的替代直接扫描近期memory/YYYY-MM-DD.md提取里面的bullet 项[P0]/[P1]/[P2]记忆条目标题上下文重复出现的规则/结论/偏好然后做文本归一化去重统计跨天出现次数检测是否有“记住 / 默认 / 以后 / 规则 / 必须”这类强化信号基于关键词做简单分类最后把候选写到memory/.dreams/candidates.light.jsonDREAMS.md的Light Sleep区块memory/dreaming/light/YYYY-MM-DD.md2REM做主题和模式识别REM 不是用来写长期记忆的它更像是“这些天你到底在反复处理什么问题”“哪些主题明显在持续出现”“哪些东西已经从临时记录变成稳定模式了”我现在的实现会做两件事a. 统计主题强度比如这次首轮跑出来就能看到providercronmemoryenglishfamilyb. 提取“可沉淀真相候选”也就是明确出现过强化信号或者跨天重复出现这些候选不直接写长期记忆而是先作为 REM 对 Deep 的“加权强化信号”。输出位置DREAMS.md的REM Sleepmemory/dreaming/rem/YYYY-MM-DD.md3Deep把晋升权收口到唯一入口Deep 是整个系统最关键的一层。我在旧版本上复刻时保留了官方六维骨架但做了“适配旧系统”的实现。六维评分仍然保留frequencyrelevancequery diversityrecencyconsolidationconceptual richness但具体信号来源改成了旧版可拿到的内容frequency候选在短期记忆中累计出现次数relevance是否带“默认 / 规则 / 必须 / 以后”等明显强化信号query diversity是否出现在不同日期 / 不同标题上下文recency按半衰期做衰减consolidation是否跨天重复出现conceptual richness候选的有效概念密度另外我还加了 phase boostLight 命中加一点分REM 命中再加一点分最后再过阈值门minScoreminRecallCountminUniqueQueriesmaxAgeDays只有全部通过才允许晋升。并且有个硬规则只有 Deep 能写MEMORY.md这是整套系统最重要的收口点。六、第一次跑起来的结果我先做了一次 dry-runcandidateCount 183Light topCount 40REM truths 76Deep reviewed 183promoted 0这个结果反而挺理想。为什么因为它说明流程已经跑通了候选抓到了主题识别也正常但是默认阈值下没有条目被随便塞进MEMORY.md换句话说它宁可保守也不乱写。在记忆系统里这比“看起来很聪明但一路乱晋升”强太多了。七、真正的难点不在脚本而在“旧系统收口”刚把 Dreaming 接进去时最大的风险不是算法而是旧的记忆管理流程本来就还在跑原来系统里有一条Memory Managementcron大意是执行记忆淘汰脚本压缩 7 天前日志更新记忆文件问题就出在第三句“更新记忆文件”这句话太模糊了如果 Dreaming 也在处理长期记忆晋升而旧 cron 也保留“更新记忆文件”的模糊职责后面一定会出现双写重复晋升标准不一致MEMORY.md风格漂移以后根本说不清一条长期记忆是从哪来的所以我做了第二步也是我认为比写脚本本身更重要的一步把旧记忆链路收口成单一主线八、怎么收口旧链路我没有粗暴地把旧Memory Management整条删掉。因为它还在负责一些有价值的 housekeeping压缩旧 daily logs保持memory/archive/归档链路维护状态文件做目录卫生清理这些工作 Dreaming 并没有接管。所以我采取的是保留 housekeeping收走长期记忆晋升权也就是把职责改成两段A. Housekeeping只负责记忆淘汰 / 清理压缩 7 天前 daily memory 日志维护目录与状态B. Dreaming Sweep强制调用python3 /root/.openclaw/workspace/scripts/dreaming.py sweep --apply并写进硬性规则不要再用旧批量逻辑直接整理、改写或晋升MEMORY.md只有 Dreaming Deep 允许追加写入MEMORY.md这样以后系统里“谁有权把内容写成长期记忆”就很明确了。九、收口后怎么验证没有双写我做了一个很重要的复核直接执行Deep apply 一次结果是reviewed 186promoted 0apply true然后再去看MEMORY.md里 dreaming 自动晋升条目数。结果dreaming_lines 0说明当前状态是Deep 已经能正常执行本轮没有可晋升条目没有误晋升没有双写没有脏数据混进去这一步非常关键。很多“自动化系统上线成功”的错觉都是因为没有做这种复核。十、这套方案最适合什么场景我觉得这套“外挂 Dreaming”特别适合下面这种情况1线上环境已经稳定不想随便升级主程序很多人不是不想用新功能而是不敢在一台已经跑满 cron、provider、消息通知和脚本的机器上直接升级。2你有自己的MEMORY.md memory/YYYY-MM-DD.md工作流也就是说你不是从零开始。你已经有长期记忆文件短期日志文件固定 cron自己的整理习惯这种情况下外挂层比整机升级更容易落地。3你真正缺的是“巩固机制”不是“检索能力”很多人已经有memory_search了但长期记忆还是主要靠人工维护。这时最缺的不是更强搜索而是哪些东西值得进长期记忆谁来做这个决策决策后怎么保持可解释Dreaming 解决的就是这个问题。十一、这次实战里最值得保留的几个原则原则 1不要一上来就升级主系统很多时候“系统升级”不是唯一解。如果一个新能力的本质是新增后台逻辑新增状态文件新增 cron 行为新增整理规则那它往往是可以先在 workspace 层外挂验证的。原则 2先查文档和 CLI不要靠脑补抄功能这次如果不先核文档CLI配置项旧版本 help很容易出现一种典型错误以为“旧版本大概也支持”结果上来就写一堆根本接不上的兼容代码。原则 3记忆系统最重要的不是“会不会记”而是“谁有权写长期记忆”这一点比算法权重本身重要得多。只要长期记忆入口不收口后面系统一定会漂。原则 4先保守不要乱晋升第一次跑出来promoted 0不是失败。相反这是非常健康的信号。因为记忆系统最怕的不是“暂时没记住”而是“把垃圾郑重其事地写成长期原则”。十二、现在这套系统的最终状态截至当前这套外挂 Dreaming 已经做到不升级 OpenClaw 主程序在旧版 OpenClaw 2026.3.8 上工作默认全开不需要手动开启不需要人工调参数自动跑 Light / REM / Deep自动写DREAMS.md自动维护memory/.dreams/自动输出memory/dreaming/phase/YYYY-MM-DD.md只有 Deep 拥有MEMORY.md的晋升权旧Memory Management已收口为 housekeeping Dreaming sweep已通过 dry-run 和 apply 复核当前没有双写、没有误晋升十三、如果你也想复刻建议顺序别反如果让我给一个最省坑的落地顺序我会建议这样做第一步查清官方新功能的真实边界不要只看宣传描述要确认写哪些文件哪些阶段能写长期记忆CLI 有没有现成入口哪些配置是公开的哪些是内部策略第二步先验证旧版本到底缺什么重点查CLI help本地版本号现有 cron / memory 链路当前 workspace 的记忆文件结构第三步先做外挂版不要先动主程序先把状态目录产出文件主脚本dry-run跑通。第四步先收口长期记忆入口再谈优化算法这是最容易被忽略的一步但其实是系统质量的关键。第五步最后再调阈值不要一开始就把精力花在0.8还是0.78上。先确认流程对不对权限边界对不对有没有双写有没有误晋升这些比参数重要得多。十四、一个很现实的总结这次做完我最大的感受是真正可用的 Agent 记忆系统重点不在“能不能搜到”而在“能不能稳、准、可解释地沉淀”检索是入口巩固才是长期价值。Dreaming 这个设计方向本质上是在给 Agent 加一个“后台睡眠整理层”。而在旧系统里复刻它真正值得学的也不是某个参数而是这几个设计观念短期与长期记忆要分层反思层和晋升层要分权长期记忆入口必须唯一自动化上线前一定要做复核这几件事比“是不是官方原生实现”更重要。附这次外挂版的核心文件新增文件scripts/dreaming.pyscripts/dreaming_status.pyconfig/dreaming.json运行产物DREAMS.mdmemory/.dreams/memory/dreaming/light/YYYY-MM-DD.mdmemory/dreaming/rem/YYYY-MM-DD.mdmemory/dreaming/deep/YYYY-MM-DD.md被收口的旧链路Memory Managementcron关键原则Only Deep writes MEMORY.md如果后续还要发论坛我建议在正式发帖前再补两样东西一张目录结构图一张 Light / REM / Deep 数据流图这样传播效果会更好也更容易让别人照着复刻。