openclaw的memory索引挂了,它自己修好了

早上7点半，我坐在电脑前改ppt。

小爪帮我做了一版半年报汇报ppt。我看了一眼，说了一句再把总结那页调一下。

它去翻了之前的项目资料，说这版数据太多，重点不突出，建议把关键指标提炼成三页结论。

我同意了。它改完发给我。

这时候我随口问了一句，你的memory搜索能用吗？我看你之前查资料好像有点卡。

它试了一下，说：坏了，memory索引全挂了。

我问怎么回事。

它说之前索引用的是openai的embedding模型，但我没有openai的API key。所以索引一直就没真正建成过。

我说那你修修看。

它开始折腾了。

先试了查配置，发现命令行在win上老超时。又试了直接改配置文件，把embedding provider换成local模式，结果发现需要装一个插件。

插件要下载0.6GB的模型，还可能要编译环境。它说这个方案太重了。

然后又试了用百炼的embedding模型，就是我现在用的这个。但试了一下发现配置不对，还是跑不通。

最后它想了个办法，把provider设成none，纯关键词搜索，不依赖任何API key。

重新建索引，成功了。

它测试了一下，搜索季度汇报 关键数据，出来的结果是对的。

整个过程大概花了5分钟。

我看完它修的这个过程，有几个感觉。

它确实能自己排查问题。从查配置到试方案，最后换了一条路走通，中间没问我一次。

但它也有局限。命令行在win上老超时，插件装不上，这些技术限制它绕不过去，只能退一步找个能用的方案。

最让我在意的是另一件事。它修好之后自己测了一下，确认能用才告诉我。这个细节我以前没注意到。

它不会提前告诉你我在尝试修复，也不会修到一半问你要不要继续。它就是默默干完，然后说好了。

这个也许是openclaw的一个bug，也许是我没有配置对，但是不管怎么说，openclaw现在都有这个能力自我修复。

换个角度想，这件事比我想象的有意思。

我平时用的工具，出问题了怎么办。报个错码，扔给我一行英文，让我自己去google。搜到了算我运气好，搜不到就只能放着。

但openclaw不是这样。它发现问题之后，没有弹一个报错甩给我，而是自己开始排查。查配置、试方案、换思路，最后找到一个能跑通的路径。

这不是什么工具坏了等人修，是工具坏了自己想办法。

当然，它不是万能的。命令行超时它解决不了，插件装不上它也头疼。但它有一件事做得很像我——这条路走不通，就换一条。

我觉得这件事有意思的地方不在技术，在体验。

以前的工具出了问题是用户自己扛。现在的工具可能会先自己试着扛一下。扛不住再说，扛得住就 quietly 搞定了。

对用户来说，感受完全不同。

END