生产级记忆架构与自动化记忆维护

适用版本： OpenClaw v2026.4.11（stable）/ openclaw-memory-final 验证日期： 2026-04-12 目标读者： 已用第 6 篇配好基础记忆系统，OpenClaw 稳定运行至少 2 周 难度： ⭐⭐⭐⭐ 高级 适合首次阅读： 否——本篇面向长期运行的生产场景。如果你刚接触 OpenClaw，请先完成第 6 篇《记忆系统、SOUL 与个性化进化》并跑稳 2-4 周再来。

⚠️ 重要提醒： 不建议第一次接触 OpenClaw 的读者直接照做全部内容。本篇的完整架构适合 OpenClaw 已跑数月、遇到了记忆膨胀/重复/静默失败等真实痛点的用户。如果你还没遇到这些问题，只做"必做生产基线"部分就够了。

目标

把第 6 篇《记忆系统、SOUL 与个性化进化》的基础记忆系统升级成生产级架构：自动同步、防重复、成本可控、长期稳定运行数月不崩。

我们以社区开源项目 openclaw-memory-final 为参考蓝本（本文按该仓库 main 分支 2026-04-12 状态验证；仓库后续更新可能与本文描述有差异，以你实际 clone 的版本为准）。本文会说清楚：哪些是直接借鉴该仓库的组件，哪些是结合 OpenClaw 通用场景做的泛化建议。你不需要完全照抄仓库——按自己的需求挑选组件即可。

前置条件

• 已完成本系列前面的章节，特别是第 6 篇《记忆系统、SOUL 与个性化进化》
• openclaw daemon status 显示运行中
• workspace 已部署（至少有 SOUL.md + MEMORY.md + USER.md）
• 对 cron 表达式和 shell 脚本有基本认知

最短可用安装路径

如果只想快速装好生产基线，4 步搞定：

bash
# 1. 克隆仓库
git clone https://github.com/codesfly/openclaw-memory-final.git
cd openclaw-memory-final

# ⚠️ 版本固定建议：本文按 main 分支在 2026-04-12 的状态验证。
# 生产环境建议 pin 到你验证通过的 tag 或 commit：
#   git tag                              # 查看可用 tag
#   git checkout v1.0.0                  # pin 到 tag（推荐）
#   git checkout abc1234                 # 或 pin 到 commit
# 如果仓库没有 tag，记录你当前的 commit：
#   git rev-parse HEAD                   # 记下这个值，回滚时用

# 2. 一键安装（⚠️ 请替换：时区和模型参数换成你的实际值）
bash scripts/install-ai.sh --tz Asia/Shanghai --retrieval-model gpt5.4

# 3. 验证 cron 任务已注册
openclaw cron list | grep memory
# 应该看到 memory-sync-daily、memory-weekly-tidy 等任务

# 4. 手动触发首次同步
openclaw cron trigger memory-sync-daily

QMD 语义索引是可选的。 不配也能正常运行 daily sync 和 weekly tidy。QMD 只影响语义检索质量，不影响核心记忆流转。如果你暂时不需要语义搜索，跳过 --retrieval-model 参数即可。

安装脚本是幂等的，重复运行安全。

让 OpenClaw 帮你部署生产级记忆

不想手动跑脚本？让 Bot 代劳：

text
帮我部署生产级记忆架构（基于 openclaw-memory-final）。
按步骤来，每步确认后再进下一步：

[第 1 步：环境检查]
检查以下前置条件，逐条报告：
- openclaw daemon status 是否正常
- ~/.openclaw/workspace/ 下是否有 SOUL.md / MEMORY.md
- git 和 python3 是否可用
- 当前 MEMORY.md 行数（超过 200 行先提醒我清理）

[第 2 步：安装]
git clone https://github.com/codesfly/openclaw-memory-final.git /tmp/openclaw-memory-final
cd /tmp/openclaw-memory-final
# 如果仓库有 tag，列出可用 tag 让我选择要 pin 的版本
展示 install-ai.sh 的可用参数，问我：
- 时区
- 是否需要 QMD 语义索引（可选）
- 如果要 QMD，用哪个嵌入模型
确认后运行安装脚本。

[第 3 步：验证]
- openclaw cron list | grep memory，确认 cron 任务已注册
- 手动触发 openclaw cron trigger memory-sync-daily
- 检查 daily log 是否生成
- 检查 processed-sessions.json 是否创建
逐条报告结果。

[第 4 步：可选增强]
问我是否需要启用：
- context budget guard（上下文预算守卫）
- conflict detection（规则漂移检测）
- watchdog（健康检查）
我选哪个就配哪个，不选就跳过。

任何一步失败就停，告诉我失败点，不要自动修复。

两层架构总览

一、必做生产基线

📖 以下组件直接来自 openclaw-memory-final 仓库，是经过社区验证的生产实践。

核心 pipeline：日增量 → 周精炼 → 长效记忆

text
会话（Session） → 短期工作区（daily log）
                      │ 每天 23:00
                      ▼
              Daily Sync（日增量蒸馏）
              · 幂等游标跳过已处理消息
              · 提炼结论写入 memory/YYYY-MM-DD.md
                      │ 每周日 22:00
                      ▼
              Weekly Tidy（周精炼）
              · 提取高频/稳定结论
              · 合并到 MEMORY.md（80 行 / 5KB 限制）
              · 归档已处理 daily logs
                      │
                      ▼
              MEMORY.md（长效记忆）

Daily Sync（日增量蒸馏）

Cron：0 23 * * *（每天 23:00）

每天扫描当日 session，提炼有价值的结论写入 memory/YYYY-MM-DD.md。

幂等保护： 通过 processed-sessions.json 记录已处理消息的 SHA256 指纹。即使 cron 重跑、session 文件重复读取，都不会产生重复记忆。

json
{
  "last_processed_message_id": "msg_8f3a29b1",
  "processed_fingerprints": ["a3f2e8c1d4b5...", "7d9c4f2e1a8b..."],
  "cursor_updated_at": "2026-04-10T23:00:12Z"
}

Weekly Tidy（周精炼）

Cron：0 22 * * 0（每周日 22:00）

读取过去 7 天的 daily logs，提取值得长期保留的结论，合并到 MEMORY.md。已处理的 daily logs 归档到 memory/archive/。

5KB / 80 行限制是社区实测的合理上限——Agent 每次启动读取不会爆 token。超过就该归档老旧条目。

验证安装结果

bash
# 确认 5 个 cron 任务已注册
openclaw cron list | grep memory

# 手动触发一次 daily sync，确认能正常运行
openclaw cron trigger memory-sync-daily

# 检查 daily log 是否生成
ls ~/.openclaw/workspace/memory/$(date +%Y-%m-%d).md

# 检查幂等游标文件
cat ~/.openclaw/workspace/processed-sessions.json | python3 -m json.tool

跑通这些就意味着生产基线就位。后续 daily sync 和 weekly tidy 会自动运行。

二、可选增强（按需启用）

📖 以下组件部分来自 openclaw-memory-final 仓库，部分是结合 OpenClaw 通用场景的泛化建议。遇到对应痛点时再启用。

Context Budget Guard（上下文预算守卫）

解决痛点： MEMORY.md 膨胀到 500 行 + 20 个 daily log，每次对话注入 200K tokens 烧钱。

强制两层硬限：单文件 20,000 字符、所有文件合计 80,000 字符。超限时按优先级截断（SOUL > USER > MEMORY > TOOLS > daily log）。

bash
# ⚠️ 请替换：profile 名换成你实际使用的
python3 scripts/memory_context_pack.py --profile main --dry-run

--dry-run 只报告不修改，先看看当前状态。

Conflict Detection（规则漂移检测）

解决痛点： Agent 在某次对话中临时"同意"了一个新决定，weekly tidy 把它写成长期规则，覆盖了之前的稳定决策。

memory_conflict_check.py 在 weekly tidy 写入前扫描：数值漂移（超时 30s → 60s）、布尔反转（启用 → 禁用）、路由变更（告警发 Telegram → 发 Slack）。检测到冲突时暂停写入，等你人工确认。

Watchdog 双重确认

解决痛点： 某天的 sync 失败了，半个月后才发现。

两个 watchdog 定时检查：

• memory-cron-watchdog（每 2h）：检查 daily sync / weekly tidy 是否按期运行，游标文件是否可读
• memory-retrieval-watchdog（每 30min）：检查 QMD 索引是否健康、查询延迟是否正常

双重确认机制： 单次异常不告警，连续两次才触发——避免瞬时网络抖动造成假警报。

QMD 语义索引

解决痛点： 记忆文件越来越多，关键词搜索不够用，需要语义级检索。

QMD 有三类操作：

省成本推荐： 用硅基流动的免费 BAAI/bge-m3 嵌入模型，月成本归零，中文检索效果优秀。

bash
# ⚠️ 请替换：API Key 换成你在硅基流动申请的真实值
export SILICONFLOW_API_KEY="sk-your-key-here"

# 安装时指定硅基流动作为嵌入后端
bash scripts/install-ai.sh \
  --tz Asia/Shanghai \
  --embed-provider siliconflow \
  --embed-model "BAAI/bge-m3" \
  --embed-endpoint "https://api.siliconflow.cn/v1/embeddings"

bash
# 找 QMD 配置文件的三个常见位置
ls ~/.openclaw/config/qmd*.{json,yaml,yml} 2>/dev/null
grep -n '"qmd"\|"embed"' ~/.openclaw/openclaw.json
ls ~/openclaw-memory-final/config/ 2>/dev/null

json
{
  "embed": {
    "provider": "siliconflow",
    "model": "BAAI/bge-m3",
    "endpoint": "https://api.siliconflow.cn/v1/embeddings",
    "api_key_env": "SILICONFLOW_API_KEY"
  }
}

bash
# 先备份旧索引
mv ~/.openclaw/workspace/memory/qmd ~/.openclaw/workspace/memory/qmd.bak.$(date +%Y%m%d)

# 重建（二选一，看你仓库里有哪个脚本）
cd ~/openclaw-memory-final
python3 scripts/memory_qmd_rebuild.py --profile main
# 或
openclaw cron trigger qmd-nightly

# 验证
python3 scripts/memory_qmd_query.py "test query" --profile main
# 有返回结果 = API 嵌入已生效

bash
ollama list                          # 看装了哪些模型
ollama rm nomic-embed-text           # ⚠️ 请替换：换成实际的模型名

text
帮我把 QMD 的 embedding 从本地模型改为硅基流动 API。按步骤来：

1. 用 ls + grep 定位当前的 QMD 配置文件，告诉我在哪
2. 读取配置，确认当前是本地模型后，展示改为 siliconflow 的 diff
3. 检查 SILICONFLOW_API_KEY 环境变量是否已设置
4. 备份 memory/qmd 到 .bak 目录后重建索引
5. 跑一条测试查询确认新索引可用
6. 问我是否要删本地模型（跑稳后再删）

每步等我确认。任何一步失败立即停。

任务卡隔离

解决痛点： 子 Agent 并行运行时，中间产物污染主 MEMORY。

memory/tasks/YYYY-MM-DD.md 专门存子 Agent 的任务结果，只存 result，不存过程。主 Agent 检索时优先读任务卡，不被过程噪声干扰。

Dreaming 自动记忆晋升 🔬 进阶可选

OpenClaw 2026.4.9+ 内建的 Dreaming 功能：在离线时段（默认每日 3:00）自动扫描最近的对话和日志，把反复出现的高价值信息从短期记忆晋升到 MEMORY.md。

晋升需要同时通过三个阈值（官方默认值）：

三个阈值同时满足才晋升——防止单次噪声或偶发重复污染长期记忆。启用后会自动创建一个 dreaming cron 任务。

bash
# 查看 Dreaming 状态
openclaw memory dreaming status

# 手动触发一次 dreaming sweep（先看效果）
openclaw memory dreaming run --dry-run

⚠️ 版本说明： Dreaming 是 2026.4.9 引入的官方功能，字段名和阈值默认值可能随版本更新。以你实际使用版本的 openclaw memory dreaming --help 输出为准。

💡 建议： Dreaming 和 daily sync 互补——daily sync 做离线批量蒸馏（每天固定跑一次），Dreaming 做高信号晋升（只晋升真正被多次用到的）。两者同时开，形成「广度 + 深度」的双层记忆治理。

主动记忆维护（HEARTBEAT 规则）🔬 进阶可选

思路来源： 借鉴 Hermes agent 的 agent-curated memory 设计——让 Agent 主动判断哪些信息值得持久化，而不是被动等用户说"记一下"。

除了定时的 daily sync，还可以让 Agent 在会话中主动判断哪些值得沉淀。在 ~/.openclaw/workspace/HEARTBEAT.md 中加入记忆维护检查项：

markdown
## Memory Maintenance Checks

- After any conversation lasting more than 10 turns, judge if there are
  durable preferences or decisions worth adding to MEMORY.md.
- If yes, propose the addition to the user for confirmation before writing.
- Review memory/ for notes that appear in 3+ daily logs —
  candidates for promotion to MEMORY.md.
- Flag entries in MEMORY.md that reference services/paths that no longer exist.

这些规则不需要新字段，就是普通的 HEARTBEAT 检查项。Agent 会在心跳检查时评估这些条目，发现候选时主动向你提出（不会自行修改 MEMORY.md）。

💡 建议： 主动维护的收益在你偏好变化快的场景最明显。比如新项目启动阶段，每天都在确立新约定——让 Agent 主动捕获比你手动告诉它"记一下"更及时。

记忆哲学对比：OpenClaw vs Hermes

本节前面多次提到"借鉴 Hermes agent"的增强方案。帮你理解两种哲学的差异，再决定要融合哪些：

一句话概括： OpenClaw 是「结构化规则 + 离线批处理 + 人主导节奏」；Hermes 是「全量存储 + 按需检索 + Agent 主导维护」。

没有绝对优劣——Hermes 对硬件和成本要求更高（SQLite 会膨胀、检索需 LLM 调用），OpenClaw 更可预测、更省钱但需要更多人工治理。本篇把好的 Hermes 理念（事后沉淀、主动记忆、Dreaming 式晋升）作为可选增强吸收进 OpenClaw 框架，不必整套迁移。

💡 选型建议： 个人使用、预算敏感 → OpenClaw 原生足够；团队协作、需要 Agent 理解多人用户 → 值得把 Honcho 类外部 provider 也看看；想跨 Agent 迁移技能 → 关注 agentskills.io 标准对齐。

三、成本参考

💡 建议： 先跑一周看控制台（Dashboard）的实际 token 用量，再决定要不要调整 cron 频率。daily sync 消耗最大，如果你的对话量小，可以改成每两天一次。

验证清单

bash
# 1. cron 任务已注册
openclaw cron list | grep memory

# 2. daily sync 能正常运行
openclaw cron trigger memory-sync-daily
# 检查输出是否为 SYNC_OK

# 3. 幂等游标文件存在
cat ~/.openclaw/workspace/processed-sessions.json

# 4. daily log 自动生成
ls ~/.openclaw/workspace/memory/$(date +%Y-%m-%d).md

# 5. MEMORY.md 行数在合理范围
wc -l ~/.openclaw/workspace/MEMORY.md
# 建议 80-150 行

常见问题

Q: 必须完全照抄 openclaw-memory-final 仓库吗？

不必。仓库是一个完整的参考实现。你可以只用其中的 daily sync + weekly tidy（必做基线），其他组件按需启用。

Q: 没有 QMD 能跑吗？

能。QMD 只影响语义检索质量，不影响 daily sync / weekly tidy / watchdog 等核心 pipeline。不配 QMD 时记忆系统正常运转，只是搜索记忆时退化为关键词匹配。

Q: install-ai.sh 重复运行安全吗？

安全。脚本是幂等的，检测到已有 cron 任务和配置文件时会自动合并而不覆盖。--force-recreate 参数可以强制重建。

Q: MEMORY.md 已经涨到 300 行了怎么办？

先跑一次 weekly tidy 让它自动归档过期条目。如果仍然过大，手动 review 删除不再有效的规则。目标是控制在 80-150 行。

Q: daily sync 失败了怎么排查？

bash
openclaw logs --follow
# 找 memory-sync-daily 相关的日志

# 检查游标文件是否损坏
python3 -m json.tool ~/.openclaw/workspace/processed-sessions.json

常见原因：session 文件格式异常、磁盘空间不足、游标文件 JSON 损坏（重建：删除 processed-sessions.json 后重跑 sync）。

Q: 和第 6 篇的模板包是什么关系？

第 6 篇《记忆系统、SOUL 与个性化进化》的模板包定义了规则层（文件结构、分层约定、维护规则）。本篇补齐执行层（自动化脚本 + cron + 守护）。两者结合 = 规则 + 执行 + 守护的完整闭环。

下一步

记忆系统的生产级架构就位了。接下来去第 8 篇《自动化、多 Agent 与高级执行（核心生产力）》，把 OpenClaw 从被动响应变成主动执行。