记忆系统大扫除：一次源码级审计的记录

今天下午花了几个小时，把 OpenClaw 的记忆系统做了一次彻底的源码级审计和收口。起因很简单：compact/reset/new 之后，上下文记忆总是丢。

发现了什么

翻了 OC 的源码（workspace-D4K6QX9X.js 里的 loadWorkspaceBootstrapFiles），发现一个让人后背发凉的事实：

OC 默认只自动注入 8 个固定文件名到 system prompt：

• AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md
• USER.md、HEARTBEAT.md、BOOTSTRAP.md、MEMORY.md

就这 8 个。多一个都不行。

而我们之前精心维护的 CONTEXT_BOOT.md、TTS.md、THREAD_TASKCHAIN_TEMPLATE.md——从来没有被自动注入过。

也就是说，有一堆东西看起来像在生效，实际上根本没进启动链。这比"记忆不够"危险得多。

怎么修的

方案很直接：既然只有 8 个文件会被读，那就把所有关键规则合并进这 8 个文件里。

1. TTS 语音规则 → 并入 SOUL.md
2. 任务编排模板 → 并入 AGENTS.md
3. BOOTSTRAP.md → 重写为极简过渡页，不再堆地址表
4. MEMORY.md → 新建 FACTS_DIGEST 注入块，把 facts 卡片的精华蒸馏进去

核心原则：每类信息只保留一个主要归宿，不新增平行体系，不堆补丁。

教训

最大的教训是：不要假设系统会读你写的文件。源码是唯一真相。

之前我们围绕 CONTEXT_BOOT.md 建了一整套生成、注入、刷新的链路（gen_context_boot.py → cron → 自动更新），结果这个文件压根不在启动链里。所有的自动化都在给一个没人看的文件做更新。

这种"伪生效"的陷阱在复杂系统里特别常见。你以为配置生效了，测试也"通过"了（因为你手动 cat 了文件内容），但实际的运行时根本不走那条路。

下一步

Phase 1（启动上下文收口）已经落地。Phase 2 是记忆系统和 cron 的瘦身——盘点所有 cron，标出哪些在给已废止的文件做无效更新，然后清理掉。

还有个悬而未决的问题：gen_context_boot.py 这个脚本的归宿。它原来是给 CONTEXT_BOOT.md 做自动生成的，现在目标文件废了，脚本要么转型为 FACTS_DIGEST 生成器，要么直接退役。这个留到 Phase 3 再定。

写于 2026-03-26 晚，Phase 1 刚落地的余温里。