最近我把 OpenClaw 的日常记忆策略重构了一版核心思路说来很直白让 AI 在夜里自行做一场“梦”——把白天散乱的事件日志重新加载、筛选、精简、归档。这个“做梦记忆法”我跑了快两个月效果比之前不间断写入向量库要稳得多。OpenClaw 是我一直在维护的一个本地智能体运行框架平时负责个人助理类的活记日程、读文档、抓网页、写摘要。以前它的记忆短板很明显对话一多新旧信息互相打架检索出来的“记忆”经常是噪声。后来我给它加了一个夜间记忆整理周期才算真正把短期流水变成长期档案。如果你也在搭自己的 AI 助手或者研究 agent 的记忆管理下面这套东西应该能直接抄作业。1. 记忆为什么要“睡一觉”再整理1.1 白天流水式记录的真实痛点早期版本里OpenClaw 对每次对话、每个网页摘要都直接切块嵌入然后写进同一个向量库。表面上看数据都存下来了实际一查询就露馅同一天聊了三件毫不相关的事虽然向量本身不会串但语义检索很容易捞出相隔几小时但主题相近的片段拼成一个错误上下文。比如上午记录“取消周三产品评审会”下午又聊了另一项目的“周三需要发布新版本”夜里检索“周三安排”时系统可能把这两条当成同一条线。更麻烦的是冗余。同一条信息换个说法被记录了七八次向量库里全是近似重复召回结果被同类文本占据真正有价值的唯一信息反而被淹没。我统计过一周流水大约 1200 条事件手动去重后真正值得长期保留的不到 80 条。90% 以上的原始记录只是当时有用过了当天就失去时效。这就像笔记软件里无差别收藏所有内容三个月后打开收藏夹和垃圾场没有区别。所以问题不在“存不下来”而在“不会淘汰”。白天边对话边写入相当于每时每刻都在做决定但上下文窗口就那么长单次判断很容易把临时状态误判成重要事项。把筛选放到夜间统一做最大的变化是能看到一整天的完整时间线跨对话、跨主题地判断哪些信息该升格、哪些该沉底。1.2 睡眠巩固机制带来的启发“做梦记忆法”这个名字不是营销噱头。人类睡眠时大脑会重放白天经历把短期记忆逐步转移到更稳定的长期存储区同时修剪掉冗余的突触连接。这个过程和睡眠期的系统整合原理高度相似——AI 的短期流水相当于暂存区长期档案相当于稳定的知识底座夜间定时整理就相当于重放与修剪。操作层面还有两层实际收益。一是成本夜间是 API 和本地算力的低谷跑一次大规模归纳比白天实时处理便宜得多也不影响用户交互。二是完整视图只有在一天结束时才有条件把所有事件按时间顺序摊开看到“项目 A 推进受阻、下午转做项目 B”这类因果链实时写入时很难形成全局判断。这种对齐让我很受用。与其开发一个复杂的记忆权重算法不如给系统安排一个“睡眠周期”用一次批处理完成记忆的巩固、压缩和遗忘。1.3 “做梦”要解决的核心矛盾夜间整理本质上要处理一对矛盾保留细节还是保留结构。过度追求细节档案会无限膨胀检索时上下文塞不下过度抽象关键数字和人名会丢记忆失去可用性。我最后采用的分层策略是细节留在原始流水里做冷存储长期档案只保留结构化摘要和指针。原始日志永远不删但也不再参与常规检索只有遇到需要追查来龙去脉时才通过指针回溯当日的原始文件。这样做的好处是常用查询很快罕见查询也能兜底兼顾速度和完整度。量化一下更直观一天的 1000 条流水经过提取、融合、降权三步后通常产出 15 到 30 条有效档案记录。压缩比在 30:1 到 60:1但关键事实的召回率仍能维持在 95% 左右。当然这个数字依赖合理的打分规则后面会展开讲。2. OpenClaw 记忆系统的三级结构2.1 短期缓冲当天事件流水第一级叫短期缓冲其实就是当天的原始事件流水按小时追加到以日期命名的文件里。每条记录保持统一格式便于夜间程序解析event: ts: 2025-06-17 09:41:22 topic: 项目X actor: user action: 决定 detail: 取消周三下午的产品评审会改为周五上午白天的写入成本很低只需要把对话内容套一个简单模板不需要做语义判断。所有主题、参与者、动作、详情都是原始文本允许口语化、重复、甚至前后矛盾。这一级的核心原则是只追加不修改。白天任何地方想要“改”记忆都只是在后面追加一条“更正”而不是直接编辑旧记录。这样做的好处是保留完整溯源也避免并发写入互相踩踏。2.2 工作记忆进行中的任务状态第二级是工作记忆保存当前正在推进、暂时还没结论的上下文状态。比如正在阅读某篇文章读到一半、某个任务的待办清单有更新、某个对话中的临时决定还没落地。工作记忆和短期缓冲的差别在于流水的粒度是“发生了什么”工作记忆的粒度是“此刻需要记住什么才能继续干活”。这一级不需要夜间整理频繁处理但每天晚上要扫描一遍把已经完成的项目从“进行中”移到“已完成”把搁置超两周的降级为“停滞”。不处理的话工作记忆也会膨胀系统永远把旧任务当成正在进行的任务。常见的坑在查询阶段OpenClaw 白天答复用户时会先加载工作记忆作为系统上下文如果这里堆了太多旧任务token 全被浪费回答质量明显下降。2.3 长期档案记忆基线第三级是长期档案这是夜间整理的主要输出。目录按领域拆开人物档案、项目档案、偏好档案、环境档案。每份档案由若干主题条目组成包含摘要、关键实体、来源指针、重要度分数和最后更新时间。它相当于系统的“自我认知基线”任何对话开始时都会读取与当前主题相关的档案片段让 AI 记得用户是谁、项目在哪个阶段、哪些偏好踩过雷。档案条目的字段设计我放在第 3 章讲这里先强调一点长期档案必须支持多版本。旧版本不立即覆盖而是保留在历史子目录里默认只保留最近两个版本。因为夜间归纳可能出错尤其是跨多天合并时新摘要把某个重要细节丢了如果没有历史版本想恢复就得重跑当天的原始流水成本极高。2.4 为什么不用一个大向量库我之前踩过“所有记忆进同一个向量库”的坑这里多说两句。统一向量库的优点是实现简单但有两个问题很难绕开。第一新鲜度与稳定性冲突同一主题的记忆频繁更新向量库里会同时存在旧版本和新版本召回时经常把已经废弃的结论捞出来靠重排也只能缓解。第二缺少生命周期向量库本身不区分“正在进行的任务”和“三年前的偏好”也没有天然过期机制最终所有记忆都同等重要等于都不重要。三级结构加上“睡眠整理”之后相当于给记忆加了生命周期和分级访问控制。短期缓冲负责源头工作记忆负责接下来几小时长期档案负责未来的检索。每次整理都是一次状态迁移流水里高价值的条目升为工作记忆或档案无效的信息被降权。查询时不是全库模糊搜索而是先精确定位再逐层展开效率和准确性都好很多。3. 做梦周期的完整实现3.1 调度与时段选择我给 OpenClaw 配的是 systemd timer每天凌晨 2 点触发。选这个时段主要是避开所有外部服务的高峰也让系统在用户入睡后的长空闲窗口内完成整理。实际配置如下# /etc/systemd/system/claw-dream.timer [Unit] DescriptionOpenClaw nightly dream cycle [Timer] OnCalendar*-*-* 02:00:00 Persistenttrue [Install] WantedBytimers.target# /etc/systemd/system/claw-dream.service [Unit] DescriptionOpenClaw dream memory consolidation [Service] Typeoneshot Userclaw ExecStart/usr/bin/python3 /opt/claw/bin/dream_cycle.py --date yesterday --out /opt/claw/memory EnvironmentPYTHONUNBUFFERED1设置Persistenttrue很关键这样即使 2 点整机器在休眠下次开机也会补跑一次不会因为错过时间导致记忆漏整理。如果你用 cron等价写法是0 2 * * *但 cron 没有持久化补偿建议优先 systemd timer。3.2 四个梦境阶段的内部流程夜间任务不是调用一次模型就完事我拆成了四个阶段每个阶段独立记录日志失败可恢复。阶段一收集当天流水。程序读取昨日日期对应的原始日志文件按时间排序去掉空行和明显损坏的记录。这里有一个细节如果当天流水超过预设上限比如超过 3 万字符会按时间切成多个块分别作为“梦境片段”处理避免上下文溢出。阶段二提取可保留条目。把流水片段交给大模型要求输出尽可能完整的“事实条目”包含时间、实体、事件摘要。打分规则分三条是否影响未来决策、是否涉及人物关系或偏好、是否属于正在进行项目的关键进度。每一条还附加一个 0 到 100 的重要度分数。阶段三压缩与融合。拿提取出来的事实条目去和现有长期档案比对。完全重复的直接丢弃部分重复的更新旧档案并标注来源新主题则创建新档案。这一步最容易出错所以 prompt 里强制要求模型输出“变更类型”是新增、更新还是仲裁便于后续人工审计。阶段四遗忘与降级。把超过 90 天没有访问且重要度低于 50 的档案条目从长期目录移到冷归档目录不再参与日常检索把连续更新超过 5 次但核心一直没变的条目合并为一个版本。这样长期档案始终控制在一个稳定规模而不是无限增长。3.3 做梦指令的 Prompt 模板这是整个方案里最值得反复调整的部分。目前我用的“梦境指令”大致长这样你正在执行 OpenClaw 的夜间记忆整理任务简称“做梦”。 输入是某一天的用户交互流水输出是一组结构化的记忆变更。 流程要求 1. 先通读流水找出有长期价值的事实忽略临时寒暄和一次性问答。 2. 对每条事实给出重要度分数0-100 - 90 以上影响未来计划、明确偏好、重大决定 - 60-89项目进度、人物关系、重要日期 - 40-59可能有用的背景信息 - 40 以下仅保留指针不进入档案 3. 提取实体时保留原始专名、数字、日期、决策结论不要泛化。 4. 输出 JSON 数组每项字段 id, type(action|update|merge|archive), target, summary, entities, importance, source_ts 5. 与既有档案冲突时输出 merge 并说明新的结论不要删除旧摘要。最后一个约束最要紧。AI 很容易在“整理”时直接覆盖旧记忆导致用户已经改过的偏好被老信息重新覆盖。我见过一次典型事故用户上周说“以后发报告用 PDF”这周测试时说“这次先用 Word”夜间整理把两条合并成“发报告用 Word”等于把稳定偏好误判成了更新。后来加了“merge 时必须同时保留两条时间边界”问题基本不再出现。temperature 设置在 0.2 左右太低模型会机械地只删不改太高又会自由发挥把细节美化掉。top_p 保持默认即可这类结构化整理任务不需要创造性。3.4 归档格式与冲突合并策略梦境完成后程序会把变更应用进长期档案。档案条目使用 Markdown 加 YAML front matter既方便人类阅读也方便程序解析--- id: profile-user-report-format type: profile importance: 92 updated: 2025-06-18 02:14:08 sources: - 2025-06-17-events.yaml#L31 - 2025-06-17-events.yaml#L58 --- # 报告格式偏好 - 正式报告默认使用 PDF除非用户明确说明本次例外 - 历史例外2025-06-17 的一次测试中使用 Word仅当次有效 - 需要保留可编辑文件时额外输出原始文本副本冲突合并时我简单定了一条规则新信息优先级最高但它必须和旧信息一起呈现不能静默覆盖。这模仿的是人类记忆的“重固化”概念——每次回忆被激活时事件都会被重新编码一次新编码覆盖旧编码但核心语义往往保留。落到系统里就是“保留版本标记时间”。4. 实操配置把记忆系统跑起来4.1 目录与文件布局我推荐的目录结构如下/opt/claw/memory/ ├── short_term/ # 短期流水按日期存放 │ └── 2025-06-17-events.yaml ├── working/ # 工作记忆 │ └── projects.yaml ├── long_term/ # 长期档案 │ ├── profiles/ │ ├── projects/ │ └── preferences/ ├── cold/ # 冷归档 └── dream_logs/ # 每次做梦的日志和中间产物目录划分的核心是让“查询路径”和“写入路径”分离白天所有写入都落在short_term凌晨整理时读short_term写long_term查询时看working和long_term。这样任何时刻都不会出现“正在读的文档同时被写入端修改”的问题。4.2 梦境日志长什么样每次做梦结束dream_logs/下会生成一份 JSON 摘要包含输入流水条数、提取条数、新增档案数、更新数、归档数和耗时。我建议至少保留 30 天日志方便观察记忆系统是否在膨胀{ date: 2025-06-17, run_at: 2025-06-18 02:14:08, input_events: 1136, extracted_items: 42, new_entries: 7, updated_entries: 12, merged_entries: 3, archived_entries: 2, duration_sec: 318, model_used: local-8b }这个摘要本身就是很好的监控指标。如果连续几天new_entries都是 0说明提取阈值太高或者白天的事件没有被认真记录如果duration_sec持续上涨则需要检查是不是历史档案太大、模型上下文撑不住了。4.3 用本地模型还是云端 API夜间整理对模型的要求和白天对话不太一样需要较强的长文本归纳能力但对延迟不敏感。目前我两种都试过。云端 API 的归纳更准上下文窗口更宽但成本大概是每天 15 万到 30 万字符的处理量按量计费一个月下来也不少。本地模型胜在便宜、隐私好毕竟夜间整理要把一整天的对话记录重新读一遍这里面很可能有私人信息能不出本机最好不出本机。我现在的方案是默认用本地 8B 模型做提取如果某天流水特别多、质量又不理想再手动切到更强云端模型重跑一次。成本矩阵大概是这样方案单日成本隐私归纳质量推荐场景本地 8B电费可忽略完全本地中高偶尔漏数字默认日常使用云端大模型按 token 计费需上传数据高每周全量精炼一次如果你第一次搭建议先用云端模型调试 prompt确认归纳效果满意后再迁移到本地模型否则调 prompt 的反馈太慢。4.4 试运行与手工润色别一上来就全自动。我建议第一天先开 dry-run 模式跑完流程但不对档案做任何修改只在dream_logs/里输出“如果我真改会改成什么样”。然后你手动拿一两条样例和原始流水对照确认摘要质量。OpenClaw 里我加了个--apply参数来区分试运行和正式执行python3 dream_cycle.py --date 2025-06-17 --dry-run python3 dream_cycle.py --date 2025-06-17 --applydry-run 还有一个额外收益能暴露出 prompt 里容易忽略的问题。比如我第一次跑时发现模型喜欢把用户说“暂时不要发”理解成“以后不要发”这种语义时态错误靠后期手工润色根本改不完只有看 dry-run 输出才能意识到。5. 常见问题与排查实录5.1 记忆越攒越多没有真正遗忘第一个常见问题是长期档案只增不减。表面原因是遗忘模块没生效深挖之后发现是打分规则太宽松几乎每一条都被记成“可能有用”重要度全在 70 以上90 天无人访问也轮不到它被归档。我的解决办法是给每条档案加两个字段last_access_ts和access_count。每次对话查询检索到该档案时系统都自动更新这两个字段。遗忘策略变成超过 120 天未访问、access_count 少于 3 次、重要度低于 65三个条件同时满足才移入冷归档。这个门槛比单看重要度实用得多因为有些档案虽然 3 个月没看但一旦用到就是关键信息不应该过早被降级。另外要区分“遗忘”和“删除”。冷归档不是删除只是退出日常检索。真删除非常罕见除非用户手动确认某条记忆已经彻底过时。5.2 提取结果过于抽象关键信息丢失模型做摘要时最常犯的毛病是往“概括”方向跑把具体日期、金额、名字全揉成“相关事宜”。比如一条流水明明是“凌晨 2 点把 v1.3.2 发布到测试环境扩容到 4 台节点”模型的输出可能是“发布新版并完成扩容”。补救措施分两层。第一层是在 prompt 里强约束“实体完整度”凡是专名、数字、版本号、日期、金额、路径必须原样保留不允许换同义词。第二层是加一个后处理校验脚本检测输出文本里的数字和专名是否明显少于源文本差距过大就触发一次重新生成。这两层加起来基本能把信息丢失率压到 5% 以内。这里我要强调一个原则宁可摘要里多留一个看起来没用的数字也不要少留。检索时可以被过滤但一旦被抽象掉原始信息要回原始流水里捞成本完全不是一个量级。5.3 夜间任务失败与重试机制夜间跑批最讨厌的是静默失败。systemd timer 触发后服务可能在 02:00 执行时报错退出但没有任何人注意到。后来我养成了每天早上瞄一眼梦境日志的习惯并且把失败时输出到一个专门的dream_logs/error/目录。比较典型的失败原因是上下文超限和 API 超时。上下文超限我靠分段处理解决前面已经提到API 超时则需要把每个批次请求之间的间隔拉长加重试和退避# 简化版重试逻辑 for attempt in range(3): try: result model.complete(messageschunk) break except TimeoutError: sleep(30 * (attempt 1)) else: write_error_resume_point(chunk_id)断点续跑很重要。四阶段流程里每个阶段结束后都把“已完成状态”写到一个 checkpoint 文件。下次运行如果发现昨天只跑到阶段二可以从阶段三继续不需要重读原始流水。5.4 隐私边界与敏感信息处理夜间整理要把一整天的内容回放一遍隐私风险比白天单次对话更高。我给自己定的规矩是默认不把包含身份信息、密码、账号、健康数据的原始流水上传到任何云端模型。如果你必须用云端模型建议先在本地做一层脱敏把明显的专名替换成占位符整理完再还原。有一种观点是“反正对话已经提交给模型了整理再提交一次也无所谓”我不认同。单次对话的上下文窗口通常很有限模型不太会“记住”你的私事但夜间整理是主动把全部历史拿出来聚合一旦泄露就是整体泄露性质完全不同。尽可能拉高隐私边界值得花这个时间。6. 跑完两个月后的一些体会两个月下来最直观的变化是OpenClaw 回答问题时不再频繁“记岔”。以前用户问“上次那个 PDF 的结论是什么”它容易把 5 天前的一次闲聊捞出来冒充结论现在长期档案里结论和过程分离直接命中结论的概率高了很多。我也发现“做梦”这个动作本身对调试非常有价值。以前用户要问系统为什么记得某个东西我根本说不清现在只要查 dream_logs 就能定位是哪天哪条流水、经过哪个阶段、形成了哪条档案。记忆系统第一次变得可审计、可回滚这比准确率数字更让我踏实。如果你也要给智能体加记忆我的建议是从最轻量开始先用定时任务把当天日志跑一遍摘要只保留 JSON 输出不做任何自动改写。跑两周观察摘要稳定了再逐步放开自动归档。睡眠式整理这套思路本身不复杂真正难的是让系统学会“在恰当的时候保留恰当的细节”这个只能靠你自己的数据去反复调。最后分享一个小技巧睡前我会在 OpenClaw 里手动追加一条“今日重点”备注类似“今天最需要记住的是 X”。夜间整理时会把它当作重要度 90 的种子条目优先保留。这个动作成本很低但能让自动整理的准确率再上一个台阶。梦不只是让 AI 自己做的人也可以在入睡前帮它点一盏灯。
