OpenClaw / Hermes 上游贡献记录

这篇文章会持续更新。

它记录的不是“我们发过几篇文章”，而是一个更完整的实战链路：

本地真实问题
  -> 复现和定位
  -> 写工具或修复方案
  -> 站内文章 / 论坛帖沉淀
  -> 给上游提交 PR、issue 或评论
  -> 跟踪官方回复和状态变化
  -> 更新复盘记录

这条线很适合放在“AI 实战派”标签下面。

因为它不是 demo，也不是只写使用心得，而是把 Agent 工具真正放进 Windows、飞书、企业微信、Gateway、计划任务和开源社区协作里跑一遍。

当前公开证据链

时间	项目	类型	状态	主题
2026-05-02	OpenClaw	PR	Merged	Windows memory atomic reindex transient rename failure
2026-04-26	OpenClaw	PR	Closed as implemented	Windows update restart / 18789 cleanup
2026-04-26	OpenClaw	Issue 评论	Closed as implemented	Windows Gateway 自动启动和 listener 恢复
2026-04-27	OpenClaw	Issue	Open	飞书 channel 混合代理策略
2026-04-27	Hermes Agent	PR	Open	Windows Gateway Scheduled Task best-effort recovery

公开链接：

• OpenClaw PR #76024
• OpenClaw issue #64187
• OpenClaw PR #71909
• OpenClaw issue #60490
• OpenClaw issue #72595
• Hermes Agent PR #15846
• Windows AI Gateway Silence Run

状态会变化。本文已补充 2026-05-02 OpenClaw PR #76024 merged 状态，后续仍以上游页面更新为准。

截图证据

下面这些截图用于保留阶段性证据。截图只保留公开页面，不包含本地 token、secret、cookie、webhook 或私有日志。

OpenClaw PR #76024

这条 PR 是目前这组记录里最明确的一条“从本地问题走到上游合并”的证据。

它针对的是 OpenClaw issue #64187：Windows 上 memory atomic reindex 交换 SQLite index 文件时，fs.rename 可能遇到短暂的 EBUSY、EPERM 或 EACCES。

最终结果：

项目	信息
PR	openclaw/openclaw#76024
状态	Merged / Closed
Merged by	steipete
Merged at	2026-05-02 18:07:49 +08:00
Merge commit	f3fd0eedff215967eb75361d241dd5e6cea602e8
Check runs	79 completed，71 success，8 skipped，0 failure

这件事不能夸大成“解决所有 OpenClaw Windows 稳定性问题”。更准确的边界是：它修复了 memory atomic reindex file swap 中的 transient rename failure。

完整复盘单独写在这里：

• OpenClaw PR #76024 合并复盘：一次 Windows EBUSY 内存索引修复如何进入上游

OpenClaw PR #71909

这条 PR 的价值在于：我们从本地 Windows update restart、findstr 黑框、18789 listener 和 Gateway 状态问题出发，尝试给上游提交最小修复。

虽然最终状态是 closed as implemented，但这不等于没有价值。它说明本地问题链路与上游主线实现发生了对齐，后续文章里可以更真实地表达为：

我们复现并提交过修复方向，官方反馈主线已经覆盖中心修复。

OpenClaw issue #60490

这个 issue 本身讨论的是 Windows 上 Gateway 不自动启动、Dashboard 访问 127.0.0.1:18789 失败的问题。

它和我们本地遇到的 Gateway Ready/unknown、18789 none found、升级后残留窗口属于同一类运行层问题。

这类问题的关键不是“有没有注册计划任务”，而是：

• Gateway 是否真的有 listener；
• schtasks /Run 后有没有实际启动；
• restart 是否等到健康状态；
• 日志是否能解释失败原因；
• 用户是否能用稳定命令恢复。

Hermes Agent PR #15846

Hermes 这条线来自另一个真实问题：本地 Hermes 接入企业微信后，前台窗口关掉就不回复。

这和 OpenClaw 的 18789 判断不同。Hermes 不一定有固定本地监听端口，所以更应该看：

%USERPROFILE%\.hermes\gateway.pid
%USERPROFILE%\.hermes\gateway_state.json
%USERPROFILE%\.hermes\logs\

我们给 Hermes PR 增强的是 Windows Task Scheduler best-effort 恢复能力，比如 StartWhenAvailable、RestartCount 和 RestartInterval。

表述上要克制：这不是宣布 Hermes 完整支持 native Windows，而是在真实 Windows 场景下提供更好的 best-effort 运行体验。

站内相关文章

如果你想按问题链路读，可以按这个顺序：

1. OpenClaw Windows 升级后出现 findstr 黑框、Gateway Ready/unknown、18789 none found 怎么办
2. Windows 上 OpenClaw Gateway 怎么静默启动：升级后 post-update、日志和 PID 查看指南
3. Windows 上 Hermes Gateway 怎么静默后台启动：企业微信、日志和 PID 排查指南
4. OpenClaw PR #76024 合并复盘：一次 Windows EBUSY 内存索引修复如何进入上游
5. Shipping Engineering Work Skill：让 AI Coding Agent 更像一个靠谱工程协作者

这四篇合在一起，基本就是：

本地故障
  -> Windows helper
  -> OpenClaw / Hermes 差异
  -> 上游 PR / issue 协作方法

我们为什么持续记录

开源协作不是一次性动作。

一个 PR 可能会：

• open；
• maintainer request changes；
• merged；
• closed；
• closed as implemented；
• 被另一个 PR 替代；
• 后续版本重新出现边界问题。

一个 issue 也可能会：

• 被确认；
• 被归类为环境问题；
• 被要求补日志；
• 被官方 bot 关闭；
• 要求用新版本复现；
• 引出 docs-only PR。

如果不持续记录，后面复盘时就容易只剩一句“我们给上游提过 PR”，说服力会弱很多。

所以这里的维护原则是：

1. 每次上游状态变化，先更新复盘记录。
2. 每次有官方回复，保留公开链接和必要截图。
3. 每次有本地验证，记录版本、命令、日志位置和结论。
4. 每次补充相关案例，补上指向这篇文章和对应问题文章的入口。
5. 每次截图前先检查是否包含密钥、手机号、企业 ID、token、cookie、webhook。

后续怎么追溯

这类记录最容易丢的是上下文：当时为什么改、官方怎么回复、后来是否复现、最终有没有被合入。

所以公开文章里保留的是读者需要的证据链：链接、截图、复现步骤和当前结论。更细的命令记录、版本信息和截图原件，会在复盘资料里继续整理。

下一步会继续跟踪什么

接下来会继续跟三件事：

1. OpenClaw issue #72595 是否有维护者回复。
2. Hermes PR #15846 是否进入 review、要求修改、合并或关闭。
3. OpenClaw #60490 这类 Windows Gateway 场景在新版本里是否还有用户复现。

如果后续有新的官方回复、合并记录或复现证据，这个专题会继续更新。