我同时用了 Hermes 和 OpenClaw,然后默默把 Hermes 关了

我同时用了 Hermes 和 OpenClaw，然后默默把 Hermes 关了

一次真实的 AI 框架上手体验对比

今晚在服务器上装了两个 AI 框架：OpenClaw 和 Hermes Agent。同一个 DeepSeek V4 Pro，同一个飞书应用，同一台服务器。想看看哪个更适合日常用。

结果很明确：OpenClaw 开箱即用，Hermes 折腾了两个小时才勉强稳住。下面是我实际遇到的情况。

安装：两边差不多

两个都是一行 curl 命令安装，几分钟完成。Hermes 的安装脚本更详细，自动装了 uv、Python 3.11、ripgrep、ffmpeg，这点不错。

接入飞书：差距从这里开始

OpenClaw 在 openclaw.json 里填 appId 和 appSecret，启动，私聊群聊都能回。完事。

Hermes 第一次对话不给回复，弹一个配对码要求管理员在命令行手动批准。批准完发现飞书群聊不回消息，排查出来是飞书应用缺少 group 相关权限 scope。

而且两个机器人共用一个飞书应用的 appId 和 secret，Hermes 不认识 OpenClaw 发的内容，日志里不停报 Unauthorized。

API Key 写错了一个字母

配完 API 后 Hermes 报 401。debug 发现是我把 key 末尾的 b 写成了 f。两个字符的像素差别非常小，花了十几分钟才看出来。

最大的问题：自己重启自己

Hermes 接上 API 后，在处理消息时执行了 systemctl restart hermes-gateway——它要重启自己。被内部拦住之后又换 sudo 重试。每次需要审批，审批超时后又重试。几次下来 gateway 被 kill，systemd 自动拉起来，新进程恢复了上次未完成的会话——那个会话里它正好在尝试重启自己。就这样 10 分钟重启了 7 次。

23:03:52 Refusing to restart the gateway from inside

23:04:38 STOPPED (SIGKILL)

23:04:38 STARTED

23:05:38 Refusing to restart the gateway from inside

23:05:46 STOPPED (SIGKILL)

23:06:02 Command timed out without user response

23:06:45 systemctl restart — timed out

23:07:06 STOPPED (SIGKILL)

23:07:09 STARTED

23:08:09 Refusing to restart the gateway

23:09:01 STOPPED (SIGKILL)

而这种循环在 OpenClaw 那边完全没有发生——OpenClaw 收到消息就回消息，不会自己去重启自己的服务。

修复清单

1飞书私聊需要管理员批准配对码

2飞书群聊需要补权限 scope

3API key 字符错误

4会话恢复导致重启死循环

5命令审批超时导致阻塞

6.env 配置项被重复写入

对比总结

	OpenClaw	Hermes
安装到可用	5 分钟	约 2 小时
飞书接入	填配置直接可用	配对码 + 权限配置 + 审批
群聊支持	开箱即用	需额外配置
运行稳定性	0 次意外重启	10 分钟重启 7 次
技术设计	简洁实用	理念先进但偏研究向

个人的选择

Hermes 的设计思路是好的——自学习循环、技能自动创建、跨会话记忆——这些概念方向没问题。但它现在的状态更像一个还在快速迭代的研究项目，作为要 24 小时跑在服务器上随时响应飞书消息的工具，还不够省心。

OpenClaw 没那么多花哨的功能，但它做到了最重要的一件事：装上就能用，放着不用管。

「好用」不是功能多，是关键时刻不出问题。

对我来说，OpenClaw 就是那个能放心把钥匙交给它的助手。Hermes 我会继续关注，期待它变得更成熟的那天。

关注忱光，看见被忽略的真实

不追热点，只说真的