经验分享:QClaw(OpenClaw)记忆大清洗术,摆脱越用越笨

大家好，我是老王。

你的 AI 助手用了三个月，突然开始犯糊涂。把你的公众号说成博客，把你从来不碰的工具当成常用推荐。

你检查了一遍提示词，没问题。模型也没降级。问题出在记忆——不是没记住，是记住了太多互相打架的东西。

我用 QClaw 三个月，MEMORY.md 从几百字膨胀到接近一万字。记忆混乱比没有记忆更可怕。

01 · 记忆的「肥胖症」

大部分 AI 编程工具的记忆机制都一样：一个 Markdown 文件，什么都往里塞。

Claude Code 的 CLAUDE.md、QClaw 的 MEMORY.md、Cursor 的 .cursorrules、Codex的Angets.md——名字不同，逻辑一样。你的个人信息、工具配置、写作规范、项目进度、历史决策……全堆在一个文件里。

刚用的时候，几十行，很清爽。两个月后，几百行。三个月后，上千行。

然后症状来了：

Token 消耗跟着膨胀，每次对话先烧几千 Token 读记忆
信息互相矛盾——早期写的规则后来改了，但旧内容还在
上下文被稀释——AI 看到的 80% 是历史索引，当前任务反而被淹没
最致命的：AI 开始「创造性缝合」，把不同时期、不同上下文的信息拼在一起，输出看着合理但其实完全不对

这是记忆腐烂。

而且不是个例。LLM 本质上是无状态 API，每次调用都是跟一个「失忆者」说话，所有记忆都靠客户端把历史塞进 prompt。当这个 prompt 里的记忆开始打架，AI 的输出就不只是偏了，是「自信地胡说」。

02 · 我怎么拆的：三个文件各司其职

我之前的 MEMORY.md 大约 9000 字，个人信息、工具清单、写作规范、50多篇文章索引、自定义 Skill 配置、AI 周报定时任务 ID……全混在一起。

拆分的逻辑不是按主题，而是按「谁需要读、读多频繁」。

USER.md —「我是谁」

名字、时区、偏好、关注领域、写作风格。每次会话都需要，但不会频繁变化。独立出来，职责清晰。

TOOLS.md —「我用什么」

常用命令路径、自定义 Skill、技术规范。只有执行具体任务时才需要，日常对话根本用不到。

MEMORY.md —「我经历了什么」

精简为长期决策和历史记录：文章索引、写作规范、重要规则、项目状态。顶部加了一行声明：

基本信息、偏好、时区等已迁移至 USER.md，工具清单已迁移至 TOOLS.md。

拆完，MEMORY.md 从 9000 字降到 4000 字出头。砍了一半多，信息量没丢——只是各归其位。

03 · 拆分的核心：别按主题，按「调用频率」

很多人第一反应是按主题拆：工作一个文件、生活一个文件、项目一个文件。

错了。

AI 读记忆的方式和人不一样。它不会「浏览目录后选择性地看」，它是每次会话全量加载。所以拆分的关键不是主题分类，而是调用频率分层。

高频层（每次都读）： 你是谁、你怎么用、你的核心偏好 → USER.md

中频层（执行任务时读）： 你用什么工具、怎么排版、技术参数 → TOOLS.md

低频层（需要时查）： 历史记录、项目索引、过去的决策 → MEMORY.md

这样分的好处：AI 每次启动只加载 USER.md（几百字节），需要时再读 TOOLS.md 或 MEMORY.md。Token 消耗直接砍半，记忆冲突大幅减少。

这个思路跟认知科学对人类记忆的四层分类不谋而合——感知记忆（当前上下文）、工作记忆（任务状态）、情节记忆（历史经历）、语义记忆（知识库）。你给 AI 分层，本质上是在复刻人脑的记忆调度机制。

04 · 拆完还不够，还有三件事

拆分只是第一步。内容不清理，拆了也白拆。

删掉过时信息

任何标记了「已废弃」「待定」「可能有用」的内容，直接删。犹豫就删。记忆文件不是备忘录，是操作手册。 手册里不会写「这个按钮以前有用但现在不知道了」。

去重是第一优先级

同一个信息出现两次，AI 就可能用不同版本——这就是冲突的根源。拆分后，每个信息只在唯一位置存在，其他地方用引用指向它。一条原则：单一来源。

定期回炉

记忆不是写完就不管了。我用 QClaw 的心跳机制，每隔几天让 AI 自己检查记忆文件。我给自己设的阈值是 5000 字。超了就必须拆分或归档。

05 · 让 AI 自己整理：一段提示词就行

手动拆文件太累。有个更省事的办法：让 AI 自己跑记忆整理。

我发现一个规律——你给 AI 一段结构化的提示词，让它按固定流程审查自己的记忆文件，效果比人肉整理还好。因为它能看到矛盾、重复和过时信息。

提示词模板：

你是一个长期记忆提炼器。请执行以下整理流程：1. 读取所有记忆文件（USER.md、TOOLS.md、MEMORY.md）2. 检查是否存在以下问题：   - 重复信息（同一事实出现两次以上）   - 过时信息（标记了「待定」「已废弃」或超过30天未引用）   - 矛盾信息（同一主题在不同文件中说法不一致）   - 膨胀信号（MEMORY.md 超过 5000 字）3. 对每个问题给出处理建议：删除/迁移/合并4. 输出整理后的文件内容，标注修改位置5. 不要删除任何信息，只做标记——等我确认后再执行

关键设计： 第 5 条最重要——AI 只标记不动手，人确认后才执行。防止误删。跑一次大约 2-3 分钟，但能省下后续无数次「AI 胡说 → 手动纠正」的死循环。

06 · 更根本的问题：升级不自动重建

前面说了怎么手动整理。但有一个更根本的问题——即使你整理好了，下次版本升级可能又乱了。

OpenClaw 从 3 月到 5 月，经历了多次大版本更新。LCM 引擎上线、Dreaming 模式启用、memory_search 语义检索接入——每一次更新都在底层能力上增强了记忆系统。

但你的记忆文件呢？没有任何自动迁移。

我的 AGENTS.md 创建于 4 月 20 日，SOUL.md 和 USER.md 同一天重建。但 MEMORY.md 的创建日期是 3 月 28 日——那个版本的记忆结构只有 MEMORY.md 一个文件，没有 USER.md 和 TOOLS.md 的概念。新版本的工具知道要读三个文件，但旧版本积累的记忆全堆在一个文件里，没有人帮你拆。

三个具体的「不自动」：

LCM 不会回填文件记忆。 LCM 的迁移脚本只负责数据库 schema 升级——确保 SQLite 表结构正确。它不会扫描你的 MEMORY.md，把属于 USER.md 的内容提取出来。对话压缩和文件沉淀是两条独立的管道，中间没有自动同步。

Dreaming 没有持续运行。 我的 .dreams 目录里只有 5 月 17 日的一次产出。Dreaming 的设计初衷是「heartbeat 时自动整理 memory/*.md 日志，提炼精华写入 MEMORY.md，清理冗余」。但心跳没触发或 AI 没执行 Dreaming 流程时，日志就一直堆着。

memory_search 只管搜，不管整理。 语义检索能找到相关记忆，但不会告诉你「这段已经过时了」。搜索是被动能力，不解决记忆质量的问题。

所以，升级后你需要手动做一次「记忆重建」

步骤 1：按新结构拆分。 如果你从旧版本升级上来，MEMORY.md 里大概率混着个人信息、工具配置和历史记录。按本文 02 节的方法拆成 USER.md + TOOLS.md + MEMORY.md。

步骤 2：清理过期内容。 旧版本里可能记着已经不存在的工具路径、已废弃的项目配置。用 05 节的提示词让 AI 标记过时信息，确认后删除。

步骤 3：验证 Dreaming 是否生效。 检查 memory/.dreams/ 目录有没有近期产出。如果没有，说明 Dreaming 没在心跳中触发——你需要在 HEARTBEAT.md 里加上「检查并整理 memory/ 日志」的任务。

步骤 4：建立容量意识。 给自己设一个硬性上限——我的阈值是 MEMORY.md 5000 字。每次超过就强制拆分或归档。这不是技术限制，是纪律。

一个判断标准： 如果你升级后从来没手动整理过记忆文件，那你现在的记忆大概率还停留在旧版本的结构里。新能力是有了，但你没享受到。

07 · 外面有什么：三个方案和一条出路

手动整理是权宜之计，升级又不自动重建。那有没有更系统的方案？

Mem0：生态最大，但不适合打补丁

GitHub 56k+ stars，目前体量最大的 Agent 记忆框架。V3 批处理流水线，本质三件事：提取事实、去重、链接关联实体。 LoCoMo 91.6%，LongMemEval 93.4%，时序推理提升最大。

能用在 OpenClaw 吗？ Mem0 的记忆提取依赖 LLM 调用，每次对话额外消耗 Token。4 作用域模型跟 OpenClaw 的文件系统逻辑不匹配——两套记忆并存只会更乱。

结论：适合从零搭建记忆的新项目，不适合给已有文件体系打补丁。

Letta（原 MemGPT）：概念最硬核

伯克利团队出品，22k+ stars。核心类比：上下文窗口是 RAM，外部存储是磁盘，记忆调度器是 MMU。 上下文快满时自动 swap-out，Agent「睡眠」时后台整理记忆。

能用在 OpenClaw 吗？ Letta 的调度器是框架级的，它控制了整个记忆生命周期。要集成 Letta，等于重写 OpenClaw 的会话管理。投入产出比太低。

结论：概念值得学习，工程上不推荐集成。

Hindsight：认识论最严谨

目前学术严谨度最高的 Agent 记忆系统。四网络模型——区分「知道什么」和「相信什么」。BEAM 10M 64.1%（最高分），10M token 规模下退化最小。CARA 反思系统让 AI 知道自己「多容易相信别人」。

能用在 OpenClaw 吗？ 对个人用户过度设计。但 CARA 的思路值得偷——给 AI 注入自我认知，比在 MEMORY.md 里写规则更高效。

结论：框架级别不推荐，CARA 的思路值得偷。

出路：迁移到 Hermes 引擎

三个都不适合直接集成，原因一样：它们是完整框架，不是组件。

但有一条更现实的出路。先看看 Hermes 的记忆架构跟 OpenClaw 的差距有多大：

OpenClaw：三文件分层（USER.md + TOOLS.md + MEMORY.md），LCM 做对话压缩，memory_search 做语义检索。分层思路对了，但没有垃圾回收机制——只做了「存」没做「删」。

Hermes：五层纵深架构——

L1 短期记忆（「热」）：MEMORY.md + USER.md 注入 prompt。硬限 MEMORY.md 2200 字符（~800 tokens），超了不注入，必须压缩或归档。
L2 用户画像（「温」）：从对话中动态提炼用户习惯，不是静态文件。
L3 长期历史（「冷」）：SQLite + FTS5，按需搜索，不注入 prompt。
L4 Holographic（可选）：HRR 全息检索，不用向量数据库也能做语义搜索，零外部依赖。
L5 外部工具（可选）：MCP 服务器、RAG 管道等。

Hermes 最聪明的设计：L1 有硬性上限，保持 prompt 稳定，最大化 API 缓存命中率。 其他内容推到工具层，只有 AI 主动调用时才访问。

维度	OpenClaw	Hermes
记忆层级	2 层（文件 + LCM）	5 层
容量管理	❌ 无上限	✅ 硬限 800 token
自动提取	❌	✅ 从对话提取
语义检索	LCM（仅当前会话）	HRR + FTS5
缓存友好	❌ 随内容波动	✅ prompt 稳定

差距不在功能，在于有没有容量管理和缓存意识。OpenClaw 的 MEMORY.md 是没有 GC 的内存，Hermes 的是带 GC 的虚拟内存。

好消息是：QClaw 新版本已支持将指定 Agent 的数据迁移到 Hermes 引擎。 你可以在 QClaw 中选择一个 Agent，将其配置、记忆文件、Skill 数据导出为 Hermes 格式。迁移后，Agent 切换到 Hermes 引擎运行，直接享受五层记忆架构和自动 GC，不再需要手动管理。

这意味着你不用纠结「给 OpenClaw 打补丁」还是「从零开始用 Hermes」——你可以保留 QClaw 的 Skill 生态，同时让记忆系统用 Hermes 的架构。

但迁移不是银弹，三个现实考量：

1. Skill 生态有差异。 部分在 OpenClaw 引擎下调通的 Skill 在 Hermes 引擎下可能需要适配，尤其是依赖 LCM 或文件路径的 Skill。

2. 用户画像需要时间积累。 Hermes L2 的 Honcho 提炼用户习惯是渐进的，迁移后不是立刻生效，需要几天的对话积累。

3. 双引擎并行是过渡策略。 用 OpenClaw 引擎跑已有项目，用 Hermes 引擎跑新项目，感受差异后再决定是否全面切换。

我的判断：如果你是新用户，直接选 Hermes 引擎。如果你是老用户，先迁移一个非核心 Agent 试试水，确认没有兼容问题后再迁移主力 Agent。工具不是信仰，好用就行。