OpenClaw 8.33 记忆搜索失效：不报错，却搜不到新内容

如果你是从 7.x 升上来的，建议先看完根因部分再动手排查。这个问题的成因和升级方式强相关——不同路径进来，症状一样，原因可能不一样。

OpenClaw 8.x 系列有一个大变化：会话数据的存储方式从 jsonl 文件改成了 sqlite 数据库。我是从 7.35 升到 8.33 的，升级本身很顺利，但记忆索引在这个切换上栽了跟头。

症状：升级后，我往 memory/ 目录里新写的内容，openclaw memory search 一直搜不到。

最坑的是它不报错。搜索命令正常返回、有结果，只是结果里永远没有刚写进去的那条。查状态也没有红字——你很容易以为一切正常，直到某天发现索引其实早就停了。

先确认是不是真坏了

判断标准就一条：写一条全新的，看能不能搜到。别去看 dirty 显示，那个会骗人（后面单独说）。

echo "- 自检标记 VERIFY-$(date +%s)" >> ~/.openclaw/workspace/memory/$(date +%F).md
openclaw memory search "自检标记"

搜得到，说明索引在干活；搜不到，才轮到往下查。

根因：两个问题叠在一起

排查下来是两件事同时发生，缺一不可地把它搞坏了。

第一个：升级留下的"幽灵索引源"。

升级把会话从 jsonl 文件迁到了 sqlite，但记忆索引的源登记表 memory_index_sources 没有跟着清理——里面还留着 38 条指向旧 jsonl 文件的记录，而这些文件在升级后已经不存在了。

索引状态机扫描时遇到这些"文件不存在的源"，就卡在了 dirty 状态，增量索引从此不再执行。这是升级过程的数据残留，不是你配置写错，也不是你哪里操作失误。

第二个：官方的文件监听 bug。

即使清掉了幽灵源，增量索引默认还是依赖"文件一变化就自动触发"这条路径——而这正是 8.33 的已知 bug（#119411，P1），官方修复 PR 到我写这篇文章时（2026-10-05）仍未合并。也就是说，升级到 8.34 也不会自动好。

所以结论是：光清幽灵源不够，还得把"自动索引"这条路径整个绕开。

我的处理：两步，缺一不可

第一步，清掉幽灵源。 备份 sqlite 之后，删除 memory_index_sources 里指向不存在文件的登记，以及它们对应的 chunks。

这里有个必须注意的坑：删 chunks 时，memory_index_chunk_provenance 和 memory_index_chunk_recall_metadata 这两张表也必须一起清（它们都有 chunk_id 外键）。只删主表会留下一堆孤儿记录，之后整个记忆检索都会挂掉。清完用 PRAGMA foreign_key_check; 确认没有孤儿。

第二步，既然文件监听靠不住，改成定时轮询。

openclaw memory index          # 增量模式：快，且不被活跃会话打断
openclaw memory index --force  # 全量重建：会话持续写入时基本必失败

实测（2026-10-02）不带 --force 的增量模式十几秒跑完，而且不受活跃会话影响；--force 全量重建因为索引 revision 一直在变，会反复失败。所以我加了一个每 5 分钟跑一次增量的定时任务，用轮询代替监听。

这不是官方推荐方案，但在我的环境里稳定跑了好几天，新写的内容都能搜到了。

验证

写一条测试内容 → 等定时任务跑一轮 → 搜索命中；再看索引里该源的 mtime 和 size 与文件完全一致，就算通了。

最后说下 dirty

清完幽灵源、索引恢复正常之后，dirty: yes 依然存在。它是另一码事，不影响检索。判断记忆索引健不健康，就看"新内容能不能搜到"，别被 dirty 牵着走——这个我会单独写一篇说明。

如果你有更干净的做法，欢迎告诉我，我验证过会补进来。