Windows 养龙虾真会卡:OpenClaw 合并了我们的修复,Hermes 维护者也回应了

OpenClaw / Hermes Windows 实战：官方 PR 与稳定性经验

这篇想聊一个很真实的问题：在 Windows 上养龙虾、养马，为什么经常会卡？

这里说的“龙虾”和“马”，指的是 OpenClaw、Hermes 这类本地 AI Agent 工具。它们能接任务、跑命令、读写文件、调用工具，看起来像一个能长期工作的智能体。但真正放到 Windows 桌面环境里跑一段时间后，很多人会遇到类似情况：

任务做一半突然不动了。

刚才还在输出，下一句就不理你了。

gateway 窗口还开着，但实际已经不接任务。

没升级前好好的，一升级就启动异常。

memory 重建失败，Agent 像失忆了一样。

这类问题最烦的地方，是它们往往不像一个清楚的报错。不是那种“第 23 行语法错了”或者“缺少某个依赖”的问题。很多时候窗口还在，进程也像是活着，日志里也没有一句特别直白的话告诉你：我到底坏在哪里。

于是用户只能反复重启、降级、换终端、换机器。折腾到最后，很容易把问题归因成一句话：Windows 玄学。

但我们这段时间跟下来，越来越觉得它不是简单的玄学。很多卡顿背后，其实是 AI Agent 真正落到本地环境之后，和文件系统、后台进程、终端窗口、日志恢复机制之间发生了摩擦。

所以这次我们没有只停留在吐槽，而是把几个真实问题整理成证据、PR 和维护者沟通记录，提交给 OpenClaw / Hermes 官方项目。

目前比较明确的结果是：

OpenClaw PR #76024 已经被官方合并。

Hermes PR #15846 没有直接合并，但维护者明确回应：相关 Windows 支持会进入统一规划，后续整合时会参考并给 credit。

这篇文章就把这件事讲清楚：问题是什么，我们怎么修，官方怎么回应，以及普通 Windows 用户能从里面得到什么经验。

OpenClaw PR #76024 合并证据

一、OpenClaw 的问题：一次很典型的 Windows 文件锁

先说 OpenClaw PR #76024。

PR 地址：

https://github.com/openclaw/openclaw/pull/76024

这个 PR 修的不是一个炫酷功能，也不是让 Agent 突然变聪明。它修的是一个很普通、但对 Windows 用户非常要命的问题：memory index 重建时，底层 SQLite 文件替换可能失败。

OpenClaw 在重建 memory index 的时候，需要做类似“先准备新文件，再把旧文件替换掉”的流程。理想情况下，这个操作应该像一次干净的原子替换：准备好，切过去，结束。

但 Windows 上经常会多一个变量：文件可能被短暂占用。

占用它的不一定是 OpenClaw 自己。可能是杀毒软件，可能是系统索引器，可能是同步工具，也可能只是某个句柄还没来得及完全释放。结果就是，在替换 SQLite 文件的那一瞬间，fs.rename 可能撞上 EBUSY、EPERM 或 EACCES。

fs.rename  EBUSY EPERM EACCES

从底层看，这是文件系统和句柄释放的问题。

从用户角度看，它就变成了更模糊的现象：memory 不对了，任务卡住了，Agent 状态怪怪的，甚至下一步完全没反应。

这类问题非常容易被误判。用户会觉得是模型不行、项目不稳、工具太新。但实际根因可能只是一个很短暂的 Windows 文件锁。

我们的修复思路很克制：不重写 memory 系统，不改 SQLite journal mode，也不扩大行为范围，只在 index swap 的关键位置加 bounded retry。

换成人话说，就是不要因为一次瞬时文件占用，就直接把整个流程判死。可以在有限次数、有限时间里重试几次。如果只是 Windows 临时卡了一下，就让它自己恢复；如果确实一直失败，再把错误抛出来。

这个补丁后来被 OpenClaw 官方项目合并了。

它看起来不是大新闻，但对真实使用很重要。因为 Agent 稳不稳定，很多时候不是看它 demo 时能不能跑通，而是看它在用户机器上连续跑任务、反复读写文件、遇到失败路径时，能不能把这些边角问题处理好。

二、参与别人的 PR，也是在补稳定性

另一个 OpenClaw 相关工作是 PR #59137。

PR 地址：

https://github.com/openclaw/openclaw/pull/59137

这个 PR 不是我们发起的，主线方向已经有人做了。我们参与的是 follow-up，主要关注失败路径里的临时数据库关闭和文件清理顺序。

这件事听起来更不像“大功能”。但在 Windows 上，它同样很关键。

很多稳定性问题不是主流程错了，而是失败路径没有收好。比如一个临时数据库已经不需要了，逻辑上应该清理掉。但如果连接还没完全关闭，Windows 可能仍然认为文件被占用，于是删除失败、替换失败、回滚失败。

这种细节不会出现在宣传语里，却会出现在用户的真实卡顿里。

这也是我越来越明确的一个判断：本地 AI Agent 的稳定性，不只是模型能力问题。它更像一个工程系统，要处理文件、进程、网络、终端、日志、恢复、权限和各种失败路径。任何一个环节没收好，用户看到的都是“它又卡了”。

所以参与这种 follow-up，价值不在于“我们做了多大的功能”，而在于把官方项目里的一个稳定性边角补上。长期看，这类小修小补会决定工具能不能真正进入日常工作流。

Hermes PR #15846 维护者回应

三、Hermes 的问题：不要把稳定性寄托在前台窗口上

再说 Hermes PR #15846。

PR 地址：

https://github.com/NousResearch/hermes-agent/pull/15846

Hermes 这边，我们关注的是 Windows gateway 的后台稳定运行。

很多人在 Windows 上跑 Agent，会直接开一个 PowerShell 或 CMD 窗口，让 gateway 在里面跑。短时间测试没问题，但如果你希望它长期稳定地在后台服务任务，这种方式就有点脆。

前台窗口可能被关掉，终端状态可能异常，用户也很难判断 gateway 到底只是“窗口还在”，还是“服务真的健康”。

我们的方向是：Windows gateway 尽量通过 Scheduled Task 这类方式在后台静默启动，同时提供状态检查、日志和基础恢复。也就是说，不要把“窗口还开着”当成健康标准，而要有更明确的 health check。

这个 PR 最后没有直接合并。

但维护者的回应很有信息量。他们说 native Windows 支持需要统一设计，正在关闭一批零散 PR；同时也明确表示，这个方案已经进入内部 Windows support plan，后续整合时会参考并 credit。

对我们来说，这个反馈其实很重要。

开源协作里，不是每个 PR 都会立刻合并。尤其是涉及平台支持、启动方式、系统服务这类问题，维护者往往会考虑整体路线，而不是只看某一个补丁能不能跑。

但只要问题被记录、证据被看到、方向被维护者纳入后续规划，这件事就不是白做。它会成为官方项目判断 Windows 支持时的一部分输入。

四、给普通 Windows 用户的几个经验

这次修 OpenClaw 和 Hermes，最直接的启发不是“赶紧去追最新版本”，反而是相反：不要胡乱追新。

如果你在 Windows 上跑这类 Agent，我建议至少记住这几件事。

第一，升级前先看 issue 和 PR。

Agent 工具还在快速变化，某个版本修了一个问题，也可能引入另一个问题。尤其是 gateway、memory、插件调用、终端执行这类基础模块，一旦变化比较大，最好先看看官方 issue 里有没有 Windows 相关反馈。

第二，升级后先用小任务验证。

不要一上来就把大任务丢进去。先跑几个短任务，确认 memory 能读写，gateway 能接任务，插件调用正常，日志能看到，失败后能恢复。小任务过了，再让它做长任务。

第三，尽量减少对前台终端窗口的依赖。

前台窗口适合调试，不适合长期托管。能后台跑就后台跑，能有状态检查就加状态检查。你要确认的是服务健康，而不是窗口还亮着。

第四，保留日志和证据。

遇到卡死，不要只截图一句“它不动了”。尽量保留时间点、命令、日志、复现步骤、系统环境、版本号。如果能把问题整理成官方维护者看得懂的材料，修复概率会高很多。

第五，别把所有问题都怪到模型身上。

模型可能会犯错，但 Agent 卡死、gateway 掉线、memory 重建失败，很多时候是工程问题。工程问题就要用工程方式处理：复现、定位、缩小范围、提补丁、等反馈。

Windows Agent 稳定运行经验

五、这件事真正有价值的地方

这次最有价值的地方，不是“我们发了几个 PR”，也不是“我们终于证明 Windows 有多坑”。

真正有价值的是：把本地踩坑变成了官方项目能判断、能讨论、能合并或纳入规划的材料。

OpenClaw PR #76024 已经合并，这是一个明确结果。

Hermes PR #15846 没有合并，但维护者给出了路线反馈，这也是一个明确结果。

它说明一件事：如果只是说“我这里又卡了”，问题很难向前走；但如果能把现象、环境、日志、截图、代码修改和边界讲清楚，开源社区是有机会接住这些反馈的。

对普通用户来说，这类稳定性修复可能不够热闹。它不像新模型发布那样容易吸引眼球，也不像新功能 demo 那样立竿见影。

但如果你真的想把 AI Agent 放进日常工作流，稳定性就是第一层地基。

能不能在 Windows 上稳定跑，能不能从失败里恢复，能不能知道 gateway 是真活着还是假活着，能不能避免一次文件锁毁掉整个 memory 重建流程，这些问题都很具体，也很现实。

我们后面还会继续把这类案例整理出来。一方面给自己留证据链，另一方面也希望给同样在 Windows 上养龙虾、养马的人一点参考：遇到问题不要只重启，也不要只吐槽。能定位就定位，能复现就复现，能提交就提交。

这可能比一次漂亮的 demo 慢很多，但它更接近真实工程。

完整博客版已发布，后续案例和证据整理会继续更新：

https://kunpeng-ai.com/blog/openclaw-hermes-windows-agent-stability-evidence-trail/