2026年4月3日 · 阅读 —
OpenClaw 记忆定时检查与每周卫生整理：机制复盘与配置说明
先给结论
- 你当前这套配置已经足够应对日常记忆管理：
- 对话层靠 OpenClaw 的上下文裁剪与 safeguard compaction 防止上下文爆炸
- 文件层靠
daily-memory-check做低风险体检，靠weekly-memory-hygiene做增量保养
- 现阶段没有启用“自动改写压缩 MEMORY.md 内容”的强破坏性机制，这点是好事：安全、可控、可回滚。
1 背景：我们到底在管什么
在 OpenClaw 语义里，记忆通常分成两类问题：
- 会话上下文变长
- 聊天历史、工具输出、检索引用越堆越多
- 风险：命中上下文窗口上限、token 成本上升、回答开始发散
- 文件层记忆变脏
- Vault 里笔记变多，重复与低价值内容混入索引
- 风险：召回不准、引用噪音、长期偏好与决策难以稳定沉淀
你的 cron 体系是专门解决第 2 类问题，但第 1 类也已经在全局配置里有“自动刹车”。
2 你当前启用的两条记忆 cron
2.1 daily-memory-check
定位：日常轻检查，偏体检，低风险，默认不动刀。
- 调度：每天 9:10 Asia Shanghai
- agent：
light - sessionTarget：
isolated（隔离运行，避免污染主会话）
它在任务 payload 里约定的输入范围是：
- 近 24h 变更或新增的笔记，优先：
00-Inbox05-Daily01-Articles 04-Memory下既有主题：04-Memory/topics/*
输出与落盘约束：
- 默认不删除，不做大范围重写
- 可复用结论要沉淀进
04-Memory/topics/*.md - 不确定主题先写进
04-Memory/topics/cron-jobs.md - 更新
04-Memory/MEMORY.md的updated字段
2.2 weekly-memory-hygiene
定位：每周增量卫生整理，偏保养，允许小幅整理，但仍要求安全可控。
- 调度：每周日 4:30 Asia Shanghai
- agent：
code - sessionTarget：
isolated
硬约束：
- 默认不删除，不 wipe，不做大范围重写
- 任何破坏性变更必须列入“待确认”
输出与落盘：
- 周摘要追加到
04-Memory/topics/cron-jobs.md - 如需调整主题文件，优先在
04-Memory/topics/下新增或小幅追加，不要覆盖 - 更新
04-Memory/MEMORY.md的updated字段
3 通知机制：你要求“两者都要 + 详细版”后的最终形态
你希望每次跑完都：
- 发 Telegram 通知给你（让你知悉）
- 落盘到 Vault（便于追溯、复盘、可引用）
目前已对以下两条 job 启用了 announce 投递：
- daily-memory-check
- weekly-memory-hygiene
投递策略：
- mode：announce
- channel：telegram
- to：你的 chatId
- account：main
- bestEffort：true（投递失败不让 job 整体失败）
你最终在 Telegram 收到的内容，来自 cron run 的 summary 字段；同时，Vault 的 04-Memory/topics/cron-jobs.md 会持续积累“运行摘要”。
4 这套体系的设计原则
4.1 daily 是报警器 weekly 是保养
-
daily-memory-check：
- 目标是“尽早发现噪音与可沉淀点”
- 更像体检报告，不做手术
-
weekly-memory-hygiene：
- 目标是“去重合并、结构化沉淀、提升召回精度”
- 更像保养与整理，但仍保守地避免破坏性操作
4.2 破坏性变更必须显式待确认
原因很简单：文件层记忆属于长期资产，一旦自动覆盖或删除，代价远大于收益。
因此你当前约束是合理的：
- 默认不删
- 需要删改必须列“待确认”
4.3 会话层与文件层分别治理
你问到的“切片压缩与摘要”机制，主要对应会话层：
- 上下文裁剪 contextPruning
- safeguard compaction
而文件层更多是：
- qmd 索引与检索
- cron 体检与卫生整理
这也是为什么“自动压缩重写 MEMORY.md”默认不启用：它属于文件层的破坏性改写。
5 实操：如何查看配置与运行结果
5.1 看 cron 配置
openclaw cron list --all- cron 的持久化存储在：
~/.openclaw/cron/jobs.json
5.2 看每次运行结果
openclaw cron runs --id <jobId> --limit 5- 运行历史落在：
~/.openclaw/cron/runs/<jobId>.jsonl
5.3 看落盘摘要
04-Memory/topics/cron-jobs.md
6 建议的输出格式：指标 + 建议（你可以长期固定用）
为了让你每次能快速扫完，建议 cron summary 固定包含：
- 状态：ok warn fail
- 扫描范围：命中路径或聚合后的命中目录
- 指标：
- 近 24h 新增与修改数量
- 疑似噪音命中数
- 疑似重复组数
- 召回风险等级与理由
- 建议：Top 3 actions
- 待确认：任何删除、合并、覆盖操作必须在这里列出
- 落盘：写入了哪些文件
这套格式既适合 Telegram 通知，也适合 Vault 归档。
7 何时需要升级策略
当你遇到以下信号，可以考虑把 weekly 的“整理力度”稍微加大，但仍建议走“先提案后执行”：
- 经常 recall 出无关笔记，且重复出现
- topics 下同一主题出现多个版本，难以判断权威版本
- token 成本明显上升，且主要来自无关召回
升级路线建议：
- weekly 先输出 Compression Proposal
- 你确认后再做合并或重写
- 全程 git 可回滚
附录 A 相关文件与路径速查
- Vault 运行摘要：
04-Memory/topics/cron-jobs.md - 全局配置：
~/.openclaw/openclaw.json - cron 配置：
~/.openclaw/cron/jobs.json - cron runs：
~/.openclaw/cron/runs/*.jsonl