Hermes 与 OpenClaw 并跑策略：先做 Shadow Run，不要直接替换

Charity Majors / Kelsey Hightower

真正该优化的不是“多一个 agent”，而是单一可见 owner、单一可观察 runtime、单一故障归因面。 所以不应该把 Hermes 和 OpenClaw 都做成 production mainline。

Kent Beck

最小可逆改动优先。既然 OpenClaw 已经稳定，Hermes 最合理的位置不是替换，而是 拿新内容做 shadow sample，先比较体验和产出，再迁移。

1. 官方最佳用法

Hermes 官方更像一个独立运行时：有自己的 ~/.hermes、gateway、skills、sessions， 并提供从 OpenClaw 迁移的路径。这更像“并行评估后迁移”，不是“嵌进 OpenClaw 里一起跑”。

2. 你的最佳用法

对你来说，最稳路径是： OpenClaw 保持 production harness， Hermes 只吃一类新输入，例如新的 content / capture / research 主题。

3. 技术上能并跑吗

能。你现在本机是 Apple M1 Pro、16GB RAM，OpenClaw gateway 当前在跑， cron 有 37 jobs。短期再开一条轻量 Hermes harness 没问题，但不建议同时跑两套高频 intake。

4. 维护上适合双主链吗

不适合。真正会出问题的不是 CPU，而是： 新内容进哪个入口、回执从哪个 bot 出、哪个记账本算 canonical、哪个系统负责 writeback。

本机现状

• CPU: Apple M1 Pro
• Memory: 17179869184 bytes ≈ 16GB
• OpenClaw gateway CPU 当下约 21.6%
• OpenClaw cron: enabled=true, jobs=37
• 系统 free memory 报告约 40%

风险判断

性能角度是可以短期并行的，但你当前 load average 已经不低。更适合的是： Hermes 只跑少量新内容、低频任务、单独端口、单独日志目录；不要让它同时参与高频 Feishu intake。

更大的风险不是性能，而是维护混淆。

可以做第二个机器人吗

可以。现有配置里已经有 Codex IM 机器人、FEISHU_TASK_INTAKE、 FEISHU_SHEET_AUTO、FEISHU_MULTI_AGENT 等模式，说明“再绑一个入口”不是从零开始。

但不要复制整个主链

最好的切法不是“再造一个一模一样的 OpenClaw bot”，而是 给 Hermes 一个单独触发前缀、单独群或单独 chat_id、单独输出台账， 只处理新内容，不回写主 writeback。

1. 不要双主账本

同一类内容如果同时进两个 canonical sheet / board，后面很难判定谁是准的。

2. 不要双 writeback

如果 Hermes 和 OpenClaw 都能直接写 TODO / focus / board，会出现重复、冲突或静默覆盖。

3. 不要一上来迁移老任务

先拿新的内容流做对照，别动已经稳定的 OpenClaw 主线。

4. 不要追求“混得像一个系统”

官方路线更像 side-by-side compare，再迁移；不是把 Hermes 内嵌成 OpenClaw 的子模块。

Phase A · 现在就能做

• OpenClaw 保持 production，不动现有 bot / cron / writeback。
• Hermes 新起独立目录、独立端口、独立日志。
• 只接一类“新内容”或一个新的 Feishu 触发前缀。
• Hermes 只输出 shadow board / shadow sheet / compare log。

Phase B · 稳定后再决定

• 比对 2-3 周：token、响应质量、故障率、维护成本。
• 如果 Hermes 更好，再做迁移；如果没有显著优势，就保持旁路工具。
• 迁移时只迁移一条 lane，不要一次切全量。