最近大家为什么会把它们放在一起

Hermes 最近在开发者圈子里热起来，原因不难理解。过去一年，大家对 agent 的兴趣已经从“聊天入口多不多”慢慢转向“长任务能不能跑稳、上下文能不能续、工具链会不会越跑越乱”。Hermes 正好踩在这条线上，所以很容易被拿来和 OpenClaw 正面对比。

但这组对比有个常见误区。表面看，两边都支持消息渠道、技能、自动化、多代理和长期运行，好像只是在功能表上互相覆盖。真把文档摊开，会发现它们并没有在同一层抢饭吃。

OpenClaw 最先抓住的是“入口”这件事。你可以在 WhatsApp、Telegram、Slack、Discord 这些已经在用的渠道里直接叫到它，也可以把不同 agent、不同设备节点、不同消息流都接回同一个 Gateway。它天然像一个长期在线的个人助手控制面。

Hermes 抓住的是“执行”这件事。它从一开始就把记忆、技能、子代理、代码执行、定时任务、容器隔离、编辑器接入这些东西放在中轴上，目标很明确，就是让 agent 真能在一台机器或一组后端上持续干活。

所以，“Hermes 会不会替代 OpenClaw”这个问题，问得其实有点偏。更准确的问题是：你现在缺的是一个更强的 agent runtime，还是一个更顺手的长期在线入口。

Hermes 更像执行内核，OpenClaw 更像入口和控制平面

先看 Hermes。官方首页和文档反复强调的都是同一件事：它不想做一个绑在 IDE 上的 coding copilot，也不满足于当聊天外壳。它想做一个会积累记忆、会长技能、会调子代理、会开定时任务、还能切进 ACP 编辑器和 API server 的 agent runtime。

这套设计有几个很硬的后果。

  • 它的记忆是有边界的，MEMORY.md 和 USER.md 会跨 session 留存，但容量被强行压住，避免变成无限膨胀的上下文垃圾桶。
  • 它的技能是按需加载的，走 progressive disclosure 路线，目的是让模型在需要时再读，不在每一轮都把一整套知识文档塞进 prompt。
  • 它的 delegate_task 和 execute_code 都在替长链任务省上下文。前者让子代理只把最终摘要回传，后者让中间工具结果留在脚本里处理，不把每一步都烧进 token。
  • 它把 cron、Docker/SSH/Singularity/Modal 这类执行环境放成一等能力，说明它默认用户会让它持续跑任务，而不是偶尔聊两句。

再看 OpenClaw。它的中心不是“怎样把一段复杂任务压缩得更省 token”，而是“怎样让一个 agent 真的活在你的通信和设备网络里”。Gateway 架构页面写得很清楚：一个长期运行的 Gateway 持有各类消息入口，客户端和节点都通过 WebSocket 接回来，再由 Gateway 做事件、配对、路由和控制。

这意味着 OpenClaw 的主语不是某一个会话，而是一整张入口网络。

  • 它把 WhatsApp、Telegram、Slack、Discord、Signal、iMessage、WebChat 这些渠道放进同一层。
  • 它把 node 当成正式角色，允许不同设备暴露 canvas、相机、屏幕、位置等能力。
  • 它把多 agent 路由、不同账号、不同人格、不同工作区都挂在 Gateway 下面统一调度。
  • 它的价值首先体现在“能不能从熟悉入口随时叫到自己的 agent”，其次才是“这条任务链压缩得够不够漂亮”。

一句话收口：Hermes 的世界观更接近 agent runtime，OpenClaw 的世界观更接近 personal agent gateway。

个人用户怎么选，先看你卡在哪一步

对个人用户，这两套东西不是同一道选择题。

如果你想解决的是“我希望自己的 agent 一直在线，而且我用手机、IM 和日常消息入口就能叫到它”，OpenClaw 更对路。它最强的地方不是某个单点能力，而是触达成本极低。你不需要额外培养一个使用习惯，只是把 agent 塞回你本来就在用的沟通流里。

这件事对普通个人用户特别重要。很多人高估了模型能力，低估了入口摩擦。桌面上再强的 agent，只要你懒得打开，它在真实生活里就会输给一个随时能在 Telegram 或 WhatsApp 里叫出来的中等能力 agent。OpenClaw 吃的就是这部分红利。

但如果你是另一类个人用户，答案会反过来。比如独立开发者、研究型个人用户、重度自动化玩家，手上的任务经常要跑半小时、两小时，甚至隔天续接，还要碰终端、脚本、批处理、网页自动化、定时任务和子代理拆工。对这类人，Hermes 的价值就会更大。

原因也不玄。

  • 它的记忆和技能更像可复用的工作骨架，不只是聊天记录。
  • 它的子代理和代码执行更像真正的长任务工具，不只是多开几个会话窗口。
  • 它能切进 ACP 编辑器，也能切回 CLI、消息平台和 API 入口，工作流更完整。
  • 它对运行环境、审批和隔离的设计，比单纯的“我能不能在手机里和它说话”更深入。

所以，个人用户里其实至少有两类人。

  • 日常型个人用户、prosumer、个人生活助手需求强的人，OpenClaw 更自然。
  • 重度开发者、研究型个人用户、想把 agent 当执行骨架用的人，Hermes 更有吸引力。

这也是为什么很多人会误判“谁替代谁”。他们拿的是不同用户画像，说的却像同一件事。

对企业用户，答案会更分裂

一到企业场景，差别会更明显。

先说 Hermes。假如一家团队真正想做的是内部研发代理、研究代理、运维代理、报告代理，重点是长任务执行、工具链调用、定时任务、可隔离运行、可接编辑器和 API，那么 Hermes 明显更像底子。它对 memory、skills、delegation、code execution、cron、ACP、provider routing、terminal backend 的投入，都是围绕这条线展开的。

这类系统在企业内部最常见的落点，不是“人人在群里和它聊天”，而是“它能不能稳定替人做掉一段工作”。Hermes 在这里更像一个可以继续往里搭的平台底板。

再说 OpenClaw。它对企业也不是没价值，恰恰相反，它在另一条线上很有价值：统一消息入口、统一 agent 触达、统一设备和节点接入。对于那些已经把 Slack、Teams、Telegram 或私有消息流当主入口的组织，OpenClaw 的 Gateway 架构会很顺手。你要做一个内部可触达的助手层，或者做跨渠道的数字前台，OpenClaw 的切口很对。

但这里有个必须说清的边界。OpenClaw 官方安全文档写得非常直接，它默认的是 personal assistant trust model。文档明确说，一套 Gateway 不是为多个相互敌对、相互不信任的用户做强安全边界的；如果要做混合信任或对抗性多租户，应该拆成不同 trust boundary，最好拆到不同 Gateway、不同凭据、不同 OS 用户甚至不同主机。

这句话的含义很重。它不是说 OpenClaw 不能进企业，而是说它更适合“同一信任边界里的企业内部使用”，不适合被想当然地当成成熟的外部多租户 SaaS 基座。

Hermes 这边，官方文档展现出来的安全姿态更像企业内核：危险命令审批、容器隔离、MCP 凭据过滤、上下文扫描、session 隔离、工作目录参数校验，层次比 OpenClaw 更偏运行时防护。这里我得补一句判断，这个判断来自文档结构而不是官方营销口号：Hermes 的安全和执行姿态更接近企业内用 agent kernel，但它同样没有把自己包装成一个现成的外部多租户企业平台。

放到企业里，可以这样粗分。

  • 内部研发、研究、运维、自动化团队，优先看 Hermes。
  • 内部消息入口、跨渠道助手、设备节点和 Gateway 控制面，优先看 OpenClaw。
  • 外部多租户 SaaS、强 RBAC、强审计、强计费、强组织治理，二者都不能原样拿来当终局。

效率和效果，得分开看

很多对比文章一写效率，最后都只剩“谁更快”。这个题不能这么做。Hermes 和 OpenClaw 各自优化的效率，压根不是一回事。

OpenClaw 优化的是触达效率。你能不能在最短路径里把 agent 用起来，能不能在已经存在的消息流里接上它，能不能把手机、桌面、不同账号、不同渠道都收回到一个控制面。这类效率很难写进 benchmark，但对真实使用频率影响极大。

Hermes 优化的是执行效率。它通过 bounded memory、按需技能加载、子代理摘要回传、execute_code 把中间结果留在脚本外面这些设计，尽量减少长链任务里最贵的东西：上下文污染、重复解释和 token 浪费。这不是 UI 便利性，而是 agent 深水区的成本控制。

效果也得拆开看。

OpenClaw 的最好效果，是把一个 agent 真正变成“随时叫得到的个人助手”。它让 agent 有持续在线感，有跨设备延续感，也有渠道天然带来的使用黏性。

Hermes 的最好效果，是让 agent 真能越跑越像一个工作系统。记忆有边界，技能能沉淀，长任务能拆开，cron 能续跑，编辑器和后端都能接进去。它更像一套能把复杂工作收拢起来的运行层。

所以如果你问“哪个更高效”，答案一定要带前提。

  • 想提高 agent 的调用频率和可达性，OpenClaw 更高效。
  • 想提高长任务的完成率、复用率和上下文利用率，Hermes 更高效。

扩展性这件事，两边朝的方向也不同

OpenClaw 的扩展性，主要是横向铺开。

  • 入口可以继续加渠道。
  • 节点可以继续加设备和能力。
  • agent 可以继续按人格、账号、工作区拆分。
  • skills 可以通过本地目录、共享目录、ClawHub、OpenProse 这些机制扩展。

这条路线很像在扩一张 control plane 的地图。它往外长，越长越像一个分布式个人助手网络。

Hermes 的扩展性，更像纵向加厚。

  • 上面接 ACP、API server、消息网关。
  • 中间接 memory providers、MCP、provider routing、fallback。
  • 下面接 Docker、SSH、Singularity、Modal 这些执行后端。
  • 同时再往内部加 skills、cron、delegate、execute_code、hooks、batch processing。

这条路线很像在把 runtime 做深。它不是先想“我还能接多少入口”，而是先想“同一套 agent 内核还能承担多少工作类型”。

这里也能看出最近 Hermes 为什么会显得更火。今天开发者最焦虑的，不再只是让 agent 看起来像 agent，而是让它在复杂任务里不散架。谁更接近这个焦点，谁就更容易拿到注意力。Hermes 正好卡在这里。

但这并不意味着 OpenClaw 价值变小了。它只是卡在另一条线上。等大家重新意识到“agent 再强，叫不到也白搭”时，OpenClaw 这种入口层和控制面又会重新变得扎眼。

最后给结论

如果只能用一句话来概括，我的判断是这样的：

  • Hermes 正在变热，但它没有直接替代 OpenClaw。
  • 两者最真实的关系，不是同层竞争，而是不同层面的 agent 系统各自长厚。

再具体一点。

如果你是普通个人用户，最看重的是手机可达、消息入口、跨渠道持续在线，OpenClaw 更值得优先装。

如果你是独立开发者、研究型个人用户，想让 agent 真正接手长任务、自动化和工程工作流，Hermes 更值得优先试。

如果你是企业内部团队，目标是做研发代理、研究代理、运维代理、报告代理，Hermes 更像底层骨架。

如果你是企业，目标是做统一消息入口、统一 Gateway、统一设备节点和跨渠道助手层，OpenClaw 会更像前台控制面，但前提是你得尊重它的 trust boundary，不要把它想成现成的 hostile multi-tenant 平台。

如果你打算做外部企业 SaaS，二者都不该被直接抬成完整答案。Hermes 更像执行内核，OpenClaw 更像入口和控制面，真正的企业级组织治理、多租户安全、计费和运营层，还得自己补。

所以最后不是“选谁替掉谁”，而是“你到底在给 agent 补哪一层”。这个问题答对了，Hermes 和 OpenClaw 都有位置。这个问题答错了，装哪个都容易觉得不对劲。