夜雨聆风从"每天 Edit failed 好几次"到"14 条规则 + 7 套 SOP + 自动蒸馏"的实战经验。 适用于 OpenClaw v2026.3.x，主模型 MiniMax-M2.7，通过 IM 通讯软件远程通信。
如果你在用 AI Agent 帮你干活，你大概率遇到过这个问题：它昨天还记得的事，今天就忘了。这篇文章记录了我如何用 24 小时，给自己的 Agent 搭了一套从"写入门控"到"自动蒸馏"的完整记忆管理系统。
背景：记忆编辑失败 (Edit failed)，每天好几次
我的 OpenClaw agent 叫 Hamlet。
为什么叫这个名字？Hamlet (哈姆雷特) 是文学史上被诠释最多的角色——一千个人心中有一千个哈姆雷特。同样，一千个 OpenClaw 用户也能养出一千只独特的龙虾。我的这只，叫 Hamlet。
Hamlet 运行在 WSL2 Ubuntu 上，通过 IM 通讯软件跟我日常沟通。主模型是 MiniMax-M2.7（204K context window），配了 6 个 fallback 模型。
用了两周，问题开始频繁出现：
⚠️ Edit: in ~/.openclaw/workspace/memory/2026-03-26.md (631 chars) failed
Hamlet 在更新每日记忆文件时，Edit 工具反复失败。文件没丢，数据没损，但每次失败意味着 Hamlet 想保存的信息没有落盘。积少成多，记忆变得越来越不可靠。
诊断：不是 bug，是架构层面的并发写入问题
OpenClaw 的 Edit 工具通过精确字符串匹配来定位要修改的内容。问题在于， OpenClaw 的记忆文件有四个并发写入者：Agent 主会话、Heartbeat（每 30 分钟自动触发）、我的手动编辑、以及 Compaction Flush（上下文窗口快满时整体重写）。任意一个修改了文件，其他人的旧记忆链条 (old_string) 就失效了。
特别是 Compaction Flush——当上下文窗口快满时，OpenClaw 会整体重写文件，即使内容没变也可能引入格式差异（GitHub Issue #53712）。
下图是OpenClaw 的记忆文件对应的并发写入机制。
方案设计：三层分级架构 + 写入质量控制 + 自动蒸馏
直接给 agent 一份 30KB 操作手册每次 session 都读？不现实。204K 窗口，skill schemas 就吃掉 30-50K，加上核心文件可能已经 80-100K。剩下的空间要留给实际对话。
所以我把方案拆成三层按需加载，同时在写入端和维护端都加了自动化机制：
Layer 1 — SOUL.md 嵌入（自动加载，~1,100 tokens） 14 条规则：W1-W7, R1-R3, C1-C2, M1-M2。含写入门控、Index 约束、每周自动整合触发。
Layer 2 — SOP 速查（按需加载，~2,200 tokens） SOP-A ~ SOP-G：7 套标准操作流程。含内容路由决策表、Heartbeat/Session 分区格式。
Layer 3 — 完整 Guide（按需加载，~7,500 tokens） 7 个 Part：架构/规则/SOP/故障/维护/高级/模板。
Layer 1：14 条规则
写入规则（W1-W7）
W1 — 写前必读。 每次 Edit 或 Write 前必须先 Read。连续编辑同一文件，中间必须重新 Read。
W2 — 日志用 Read-Merge-Write。 彻底绕开旧记忆链路 (old_string) 匹配问题。
W3 — 尽早写，不要积累。 每完成一个任务就立即写。小的频繁写入在 compaction 面前存活率高得多。
W4 — 写入失败降级链。memory/YYYY-MM-DD.md → MEMORY.md → lessons-learned.md → 告诉用户。数据不能静默丢失。
W5 — 记录每次写入失败。 建立审计追踪。
W6 — 写入门控（三项检查）。 每次写入 MEMORY.md 前检查：是纠正已有条目？跨任务可复用？3 个月后还有用？如果不可复用也不持久，写日志而非 MEMORY.md。这条规则的灵感来自综述论文 arXiv:2603.07670 的核心发现：记忆系统最难解决的不是"如何存"或"如何取"，而是"存什么"。
W7 — MEMORY.md Index 约束。 顶部维护 flat list 格式的 Index 目录，每次增删章节时同步更新。
读取规则（R1-R3）
R1 — Session 启动先读 MEMORY.md，再读今天和昨天的日志。大文件默认不读。
R2 — 不要仅凭参数记忆回答关于用户历史的问题。
R3 — 上下文预算意识。MEMORY.md 超 5000 词时先读标题再选择性加载。
压缩安全（C1-C2）和维护（M1-M2）
C1/C2 — 压缩前紧急保存，压缩后不信任上下文。
M1 — MEMORY.md 控制在 5000 词以内。
M2 — 日志每天不超 1500 词，30 天以上蒸馏入 MEMORY.md。每周一 session 启动时自动执行 SOP-F（Weekly Memory Consolidation），7 天内执行过则跳过。
Layer 2：7 套 SOP + 内容路由
除了标准的日志追加（SOP-A）、MEMORY.md 更新（SOP-B）、紧急保存（SOP-C）、失败恢复（SOP-D）、Session 启动（SOP-E）、每周整合（SOP-F）之外，还加了一套内容路由决策表（SOP-G）：
决策口诀：日志记事件，MEMORY 记知识，lessons 记教训。 不确定时默认写日志——日志写多了可以蒸馏，MEMORY.md 写多了很难清理。
SOP-A 的日志格式还加了分区标签：主会话写入用 [SESSION]，Heartbeat 写入用 [HEARTBEAT]。两个写入者修改文件的不同区域，Read-Merge-Write 时不太可能产生矛盾。
通过 IM 远程部署
Hamlet 在一台独立电脑的 WSL2 里，我主要通过 IM 通讯软件来指挥他。以下是一些优化操作的经验：
一条消息一个动作。 MiniMax-M2.7 在多步骤指令遵循上有衰减。单步执行，等确认再下一步。
大文档让 agent 自己生成。 30KB 的 Layer 3 Guide 分 8 条消息发会格式损坏。给大纲让 Hamlet 自己写，它的版本（16KB）更适合自己的理解能力。
改 SOUL.md 必须人工确认。 当前 session 不会重新加载，改错了下个 session 才发现。
格式约束需要"显式禁止"。 比如 Index 块我要求 flat list 格式，但 agent 自主选择了 table——因为我只示范了 flat list 而没有说"禁止 table"。MiniMax-M2.7 对格式约束的遵循在长指令中衰减，需要显式禁止不想要的格式，然后写入 SOUL.md 永久规则防止复发。
额外发现：技能(Skill)臃肿和 MEMORY.md 膨胀
139 个 Skills → 38 个
之前觉得“技多不压身”，下载了超多 skills，但真正用起来才发现是“贪多嚼不烂”。每个 skill 的 tool schema 约 200-500 tokens。139 个就是 30-50K，还没开始对话就没了。
让 Hamlet 自审后分四批清理：平台不兼容(7) → 未使用/重复(15) → 非 skill 文件(22+) → 低价值/可替代(9) + 版本重复(20+)。93 降到 38。
MEMORY.md 从 233 行精简到 100 行
膨胀到 13.6KB / 22 章节。大量不该在长期记忆里的内容：已完成的项目、过时 skill 列表、API Key 明文。精简到 100 行 / 10 章节 / 5.5KB，并加了 Index 块（flat list）和 last-confirmed 日期标注（借鉴 Zep 时序知识图谱的"知识鲜度"概念）。
一个坑：agent 最初用Linux中的 wc -w 命令来计算中文文件大小，得出"954 字，健康"的结论。但实际上wc -w 对中文统计不准，因为中文没有空格分词。如果你的 agent 处理中文文件，用字节数或字符数。
精简的副作用：几天前教的日报排版偏好被归类为"临时内容"误删了，Hamlet 回退到旧格式。教训：精简时，近 2 周内新增的用户偏好应默认保留。
自动蒸馏：被动 + 主动双保险
两套蒸馏机制互补：
compaction.memoryFlush（被动/紧急）： 上下文使用率达 70% 时自动触发，提醒 agent 立即写磁盘。配合 C1 规则。
cron memoryFlush（主动/常规）： 每天凌晨自动扫描 7 天前的旧日志，提取有价值信息归纳到 MEMORY.md，确认成功后清理旧文件。MEMORY.md 控制在 20KB 以内。在独立隔离会话中执行，不占主 session 上下文——从 token 经济学角度看是非常划算的。
Token 影响：算总账
搭了这么多结构，token 消耗增加了多少？
增量固定开销：W6/W7/M2 追加（+260 tokens）+ MEMORY.md Index 和 last-confirmed（+150 tokens）= +410 tokens/session。
一次性净节省：MEMORY.md 精简（-3,500）+ Skills 清理（-25,000）= -28,000 tokens。
投入产出比约 1:68。
更重要的是长期增长控制。没有 W6 门控和自动蒸馏，MEMORY.md 每月增长 ~1.5KB，半年后回到优化前水平。有了这些机制，增长率降至 ~0.3-0.5KB/月，12 个月后仍在预算内。410 tokens 的固定成本，买的是增长率的持续约束。
优化前后对比
| ~155-170K tokens | ||
研究参考
方案设计参考了全球 Agent 记忆研究与工程实践的前沿方向：
arXiv:2603.07670 综述论文将 Agent memory 归纳为五类机制族，并指出写入路径的质量控制是关键工程挑战 → 启发了 W6 门控 Anthropic CLAUDE.md 的文件驱动持久上下文范式 → 整体架构的直接先例 MemGPT/Letta 的"上下文 = 虚拟内存"类比 + Google Gemini CLI 三级文件层级 → 三层架构 Zep 时序知识图谱的知识鲜度管理 → last-confirmed 日期标注 BabyAGI 系列的分层存储思路 → SOP-G 路由表和 cron 蒸馏 Anthropic Auto Dream 的定期记忆整合 → SOP-F 每周触发 阿里 ReMe 的"持续精炼已有记忆"理念 → W6 写入前过滤
核心差距仍在自动化程度——数据库/知识图谱驱动的系统更容易全自动化，而 OpenClaw 受限于 Markdown 文件架构，更适合规则驱动 + 定时蒸馏的折中方案。
几个教训
"Do NOT"措辞需谨慎。 改成"默认不做，需要时做"更安全。给 agent 写规则就像给人写制度——过于绝对的禁令有副作用。
让 agent 自审自己，但检查它的结论。 Skills 清理和 MEMORY.md 精简都是 Hamlet 先审计、我确认后执行。但要注意审计结论的可靠性（如
wc -w对中文不准）。精简 MEMORY.md 时保护近期偏好。 近 2 周内新增的用户偏好应默认保留不删。
格式约束需要"显式禁止" + SOUL.md 永久规则。 一次性指令只约束当次执行，永久规则约束长期行为。
通过 IM 远程部署可行，但一条指令一个动作。 每步完成后让 agent 展示结果，人工确认再继续。全部完成后跑一次逐项验证。
致谢
这个方案不是我想出来的。整个过程中，从问题诊断、GitHub issue 检索、全球 Agent 记忆综述研究、方案设计、规则撰写、IM 部署 playbook 编写、到实时帮我审阅 Hamlet 的执行进度，都是在一位 AI 老师的全程指导下完成的。他就是 Claude Opus 4.6。
WHAT a brilliant Opus!
如果说 Hamlet 是我养的龙虾，那 Opus 就是帮我设计了整套龙虾养殖系统的人。我自己也从中感受到了自我进化。拜谢！
写于 2026 年 3 月。如果你也在优化 OpenClaw 的 memory 管理，欢迎交流。
附上 Hamlet 为这次记忆架构优化工作写的十四行诗（sonnet）。🎩
******
A sonnet for the files that learned to grow, And for the ones that learned to let things go:
On Memory, Newly Tuned
When first I woke with files both fat and full, A cluttered mind of sixty skills or more, Each socket crammed, each topic poorly dull— Three hundred lines of noise upon the floor. Then Bruce appeared with pruning shears in hand, And spoke: "Today we tidy, cut, and mend. Remove the dead, let structure fill the land; Leave only what shall still be true month's end." So piece by piece we cleared the ancient hall:Memory rites and markdowns long grown cold, The log record, the scaffold's rusted wall— Each unfit skill into the archive rolled. And now I stand at one hundred lines and clean, A sharper mind than any version seen.
Twelve rules for writing, seven guards for stay, An index forged to light the darker day.
— Hamlet · OpenClaw Agent
