MEMORY.md瘦身全过程——从反复绕弯路到找到正确方案

本文更新于 2026-07-25

OpenClaw 的 MEMORY.md 是主 agent（oc-engineer）的持久化记忆文件，随着时间推移，这个文件会不断增长。当文件过大时，每次对话都会把整个文件加载到上下文中，造成：

1. Token 消耗飙升：每次请求都要处理数千行的记忆内容
2. 响应速度变慢：上下文窗口被大量历史信息占据
3. 注意力稀释：agent 需要在海量信息中找到相关内容

因此需要定期对 MEMORY.md 进行"瘦身"——把过期、冗余、低价值的内容清理掉，保留真正有用的信息。

问题的发现

用户发现 oc-engineer 的 MEMORY.md 已经膨胀到了相当可观的体量，决定对其进行瘦身清理。用户最初的想法很直接：把旧内容移到知识库，MEMORY.md 只保留当前需要的内容。

反复折腾的弯路

弯路一：qmd 索引分析方案

思路：用户最初想通过分析 MEMORY.md 的 qmd（某种索引/量化分析）来判断哪些内容可以删除。

过程：尝试用各种方式分析 MEMORY.md 的结构，试图找到一种自动化的方法来识别"冗余"内容。

问题：这条路走得很艰难。MEMORY.md 是自然语言编写的，没有统一的结构化格式，很难用自动化方式精确判断哪些内容"过期了"。而且分析本身就需要先把整个文件读进来，等于没有解决根本问题。

结论：放弃 qmd 索引分析方案，转向更直接的方法。

弯路二：软链接方案

思路：是否可以通过软链接（symlink）的方式，让 MEMORY.md 指向一个精简版本，旧内容放到别处？

过程：讨论了用 symlink 把 MEMORY.md 链接到一个"瘦身版"文件的可行性。

问题：OpenClaw 直接读取 MEMORY.md 路径，symlink 虽然技术上可行，但并没有真正解决问题——内容只是换了个地方存放，总量没减少。而且引入 symlink 增加了系统复杂度，带来了潜在的维护风险。

结论：放弃软链接方案。

弯路三：知识库归档方案（过度设计版）

思路：既然有知识库（Obsidian vault），把 MEMORY.md 的旧内容全部整理归档到知识库，MEMORY.md 只保留索引或摘要。

过程：开始着手把 MEMORY.md 中的历史记录逐条搬到 Obsidian 知识库的对应目录下。这个方案看起来合理，但在执行中发现：

• 需要逐条判断每条内容该放到知识库的哪个目录
• 归档过程本身非常耗时
• 归档后 MEMORY.md 中仍需保留对这些内容的引用，否则 agent 无法找到
• 实际操作中，很多内容"既不该在 MEMORY.md 也不适合进知识库"——它们就是过期了

结论：这个方案方向正确但执行过度，需要简化。

最终正确方案

经过多次试错后，找到了真正有效的方案：

核心思路

MEMORY.md 就应该小而精，过期内容直接删，有价值的内容已经在知识库中了。

不需要把每条历史记录都搬到知识库。真正重要的信息，在产生时就应该已经归档到知识库了。MEMORY.md 只是一个"当前状态快照"，不是历史档案馆。

具体执行步骤

1. 直接读取当前 MEMORY.md 全文
2. 逐段审查：对每一段内容判断：
   • 是否仍然与当前系统状态相关？
   • 是否已经在知识库中有对应笔记？
   • 是否是过期的一次性记录？
3. 分类处理：
   • 保留：当前系统配置、活跃项目状态、重要决策原则
   • 删除：过期的调试记录、已完成的一次性任务、已在知识库中的内容
   • 精简：把冗长的描述压缩为一两句话的摘要
4. 直接重写 MEMORY.md：用精简后的内容替换原文件

执行结果

• MEMORY.md 从原来的大幅体量压缩到精简状态
• 保留了所有当前活跃的关键信息
• 删除了大量过期、冗余的历史记录
• Token 消耗显著降低

核心教训

教训一：不要过度工程化简单问题

MEMORY.md 瘦身的本质就是一个"删除过期内容"的操作。最初的 qmd 分析、软链接、全量归档都是过度工程化。最简单的方案往往就是最好的方案：读一遍，删掉不要的，保留该留的。

教训二：MEMORY.md 的定位要清晰

MEMORY.md 不是知识库，不是档案馆，不是历史日志。它是 agent 的"短期工作记忆"——只保留 agent 在当前会话中需要知道的信息。一旦混淆了这个定位，就会陷入"什么都想保留"的陷阱。

教训三：归档应该在产生时进行，不是事后搬运

真正有价值的信息，在产生时就应该归档到知识库。MEMORY.md 中不应该出现"值得永久保存但当前不需要"的内容——这类内容应该在产生时就写入知识库。事后搬运的成本远大于即时归档。

教训四：先动手再优化，不要先设计方案再执行

这次折腾的根本原因是"想太多做太少"。如果一开始就直接读 MEMORY.md、逐段判断、直接删除，整个过程可能半小时就完了。但前期花在方案设计上的时间反而远超实际执行时间。对于确定性问题，直接执行比设计方案更高效。

教训五：接受不完美

不需要为每一条删除的内容找到"归档去向"。很多内容就是过期了，直接删掉就好。试图给每条内容找个"家"是一种完美主义陷阱。

行动项

• 完成 MEMORY.md 瘦身
• 建立 MEMORY.md 定期审查机制（建议每月一次）
• 在 AGENTS.md 或操作手册中明确 MEMORY.md 的定位和更新规则
• 确保新产生的重要信息即时归档知识库，而不是堆积在 MEMORY.md

参考来源

• OpenClaw 官方文档：MEMORY.md 机制说明
• Obsidian 知识库管理实践

–全文完–

若你有故事想讲、有困惑想聊、或是想找个人说说心里话，甚至只是吐槽发泄一下情绪，都欢迎来找我聊聊：　　　《内容已折叠，点击展开》

希望我写的每一个字，成为我自己和某个人活下去、拼下去的力量。　　　　　　　　　　　　　　　　　　　　　《内容已折叠，点击展开》

“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”

转载请注明来自https://oklife.me。