阅读全文预计耗时 8 分钟。

几秒钟速读版

这篇讲什么

很多人都在问：OpenClaw 和 Hermes，到底谁更强，谁更值得迁移。

我把两边 README、定位和代码结构重新拆了一遍，结论很直接：

它们不是不能比，但大多数人从一开始就比错了。

为什么要看

因为你选错的，从来不只是一个工具名字。

你后面整套使用方式都会跟着偏：

你会把时间花在消息入口、语音、设备、产品体验上，还是花在 memory、skills、cron、subagents 这些长期工作能力上。

你能记住什么

• OpenClaw 更像“住进日常入口里的 AI 助手产品”
• Hermes 更像“能长期记忆、长期执行、长期进化的 Agent 系统”
• OpenClaw 重心在渠道、语音、设备、Canvas、产品化体验
• Hermes 重心在 memory、skills、session search、cron、subagents、profiles
• 真正的选择题不是谁赢，而是你现在缺入口，还是缺闭环

适合谁

• 正在看 Agent 落地、消息入口、设备协同、语音交互的人
• 正在搭自动化链路、知识沉淀、任务调度、多机器人协同的人
• 已经在 OpenClaw 或 Hermes 里跑起来，但开始遇到边界的人

完整正文版

先给结论。

如果你现在还在用“谁更强”“谁更高级”“谁会替代谁”这套问题来比较 OpenClaw 和 Hermes，那大概率会越看越乱。

因为这就像拿一台做内容入口的设备，去和一套长期自动化系统比输赢。

不是不能比，是题目本身就偏了。

我把两边仓库、README、功能重点、目录结构重新过了一遍，最后得出的判断很明确：

OpenClaw 在解决“人怎么更自然地使用 AI”。Hermes 在解决“AI 怎么长期把事情做完”。

这句不是文案，是这两个项目最核心的分水岭。

你要是只想先记住一句话，那就是：

OpenClaw 更像 AI 助手产品。Hermes 更像 Agent 执行系统。

—

一、很多人不是不会选，而是一开始就把题做错了

为什么 OpenClaw 和 Hermes 总被放在一起聊？

原因很简单。

因为它们表面上确实有很多像的地方：

都有 Agent 味，都碰消息入口，都谈工具调用、自动化、技能、记忆、Gateway。

只看关键词，很容易以为它们是两台配置不同的同类机器。

但只要你真的翻一遍项目首页和代码结构，就会发现不对。

它们虽然都叫 Agent，但主战场根本不是一个地方。

OpenClaw 在首页第一句话就写得很直白：personal AI assistant。

它后面一路强调的是：

• 你已经在用的聊天渠道
• 语音唤醒和 Talk Mode
• iOS / Android node
• Live Canvas
• Gateway control plane
• 多端体验和产品化入口

Hermes 的开场也很直接：self-improving AI agent。

它后面最重的关键词，几乎全在另一组能力上：

• skills
• memory
• session search
• cron scheduling
• subagents
• toolsets
• profiles
• provider-agnostic
• MCP

你看到这里，其实就已经差不多知道答案了。

一个更像助手。

一个更像系统。

一个优先解决“人怎么更顺手地把 AI 用起来”。

一个优先解决“AI 怎么把事长期接住、继续干、越干越顺”。

所以如果你非要我用一句最不绕的话来概括：

OpenClaw 更像你每天会去用的 AI 助手。Hermes 更像你越用越离不开的 Agent 工作系统。

这不是咬文嚼字，这是选型起点。

—

二、OpenClaw 最强的地方，不是参数表，是它先把“入口”做对了

很多 Agent 项目一上来，先跟你讲 loop、planning、reasoning、tool orchestration。

听起来都很强。

但问题是，很多人听完以后，还是不知道这东西到底怎么融进自己每天的使用场景。

OpenClaw 走的不是这条路。

它先解决的是一个非常现实的问题：

我怎么让 AI 真的住进你已经在用的入口里。

Telegram、WhatsApp、Slack、Discord、Signal、WeChat、QQ……这些在 OpenClaw 那里，不像是“顺手接一下”的外围支持，更像是产品本体的一部分。

再往下看，你会发现它把语音、设备节点、移动端延伸、Canvas 这些东西也放得很靠前。

这说明它想做的，不只是一个“在终端里很强”的 Agent。

它想做的是一个你能随时发消息、随时叫醒、随时接进生活场景里的助手。

这也是为什么 OpenClaw 很容易在第一眼打动人。

因为你会立刻知道它怎么用。

不是“未来也许很强”，而是“现在就像个产品”。

从代码体量上看，这种产品导向也非常明显。

这次本地浅克隆后，过滤依赖目录，大约有 19231 个文件，主语言明显是 TypeScript，.ts 文件大约 15623 个。src/、extensions/、ui/ 都很重，尤其 extensions/ 和 ui/ 的体量，本身就在说明一件事：

它把复杂度大量投在插件、渠道、界面和产品体验上。

这不是偶然，这是路线选择。

所以如果你是下面这几类人，OpenClaw 很容易让你上头：

• 你希望 AI 直接住进 Telegram、Slack、WhatsApp 这些熟悉入口
• 你很在意语音、设备、移动端、可见交互是不是原生能力
• 你想做的不是一个抽象 Agent，而是一个真正能被用起来的 personal AI assistant
• 你非常看重“产品感”，而不是只看“功能表”

说白了，OpenClaw 解决的是：

AI 怎么真正靠近人。

—

三、Hermes 真正值钱的地方，不在第一眼，而在第三周

Hermes 走的是另一条路。

它不急着先证明“我接了多少入口”，它先回答的是另一个更硬的问题：

你今天做过的事，明天能不能留下来；这条链路跑通以后，下次能不能更省力。

这才是 Hermes 最值钱的地方。

它 README 第一屏就把定位压得很清楚：self-improving AI agent。

注意这个词，不是普通 agent，是 self-improving。

也就是说，它不只关心“这一轮答得好不好”，更关心“这个系统会不会越来越会干活”。

你顺着 README 往下看，会发现它最重的卖点，几乎都在回答同一个问题：

经验怎么留下来，系统怎么持续进化。

具体就是这几块：

• persistent memory
• user profile
• skills
• session search
• cron scheduling
• delegate_task / subagents
• toolsets
• profiles
• provider abstraction
• MCP

这些词单独拎出来看，都不算新鲜。

但 Hermes 把它们串成了一个闭环。

你修过一次问题，能不能沉淀成 skill。

你做过一次复杂任务，能不能靠 session search 把上下文找回来。

你有固定重复动作，能不能直接挂到 cron。

你一个人做不过来，能不能交给不同子代理分工。

你同一套系统想服务不同角色、不同工作区、不同配置边界，能不能靠 profiles 隔开。

这一整串能力放在一起，Hermes 的味道就不再像“工具箱”，而更像“运行时”。

它不是只帮你把一件事做完。

它是想帮你把一整类事越做越顺。

从代码结构看，这个方向同样非常明显。

Hermes 这次本地过滤后大约有 4192 个文件，主语言是 Python，.py 文件 1991 个，skills 目录就有 571 个文件，agent/、tools/、gateway/、hermes_cli/、website/ 都是核心部分。

这组结构说明它把主要复杂度投在了另一件事上：

不是把入口铺到最多，而是把执行闭环做深。

所以内容生产、研究工作流、长期自动化、多角色协同这类事情，Hermes 往往不是第一眼最炸的那个，却很容易成为最后离不开的那个。

—

四、真正能看出差异的，不是功能表，而是复杂度投在哪

很多人做选型，最容易犯的错，就是开始列功能表。

谁接 Telegram。

谁能工具调用。

谁有记忆。

谁有 UI。

谁能跑 cron。

这当然不是完全没用。

但如果你只停在这一步，很容易把真正重要的差异看没了。

因为真正决定产品气质的，不是“有没有”，而是：

它把主要复杂度和主要资源，投在什么地方。

OpenClaw 的复杂度，明显更多投在：

• TypeScript 大仓
• 消息渠道
• 插件扩展
• 设备节点
• 语音交互
• UI / 控制面
• onboarding 路径

Hermes 的复杂度，明显更多投在：

• Python runtime
• tools
• skills
• memory
• cron
• session search
• delegation
• profiles
• provider abstraction

你看懂这层以后，很多误解会一下子消失。

比如两边都在讲 skill，但 skill 的味道并不一样。

OpenClaw 的 skill，更像是让助手能力扩展得更自然。

Hermes 的 skill，更像是把一次成功经验正式沉淀成下次还能自动复用的程序化记忆。

两边都在做 gateway，但 gateway 在两边的角色也不一样。

OpenClaw 的 gateway 更像产品控制中枢。

Hermes 的 gateway 更像把 agent 送到多个入口，继续执行任务的通道。

两边都在做消息平台，但一个更在意“怎么让人愿意天天用”，另一个更在意“怎么让系统越跑越会做事”。

这就是为什么你只看功能，会觉得它们有不少重叠；但你一旦看结构，就会知道它们根本不是同一道题。

—

五、OpenClaw 为什么容易让人一眼喜欢，Hermes 为什么容易让人越用越深

这部分其实才是很多人真正想问的。

不是抽象地定义谁是谁。

而是落到自己身上，到底该选哪边。

如果你是想做一个 AI 助手产品的人，OpenClaw 会很迷人。

因为它给你的不是单点功能，而是一整套更接近真实产品层的东西：

• 渠道模型
• 设备节点
• Voice Wake / Talk Mode
• Live Canvas
• 多 agent routing
• onboarding 驱动的装配路径

你会有一种很直观的感觉：

它不是只在帮你“调 agent”，它是在帮你“做产品入口”。

反过来，如果你是自动化玩家、研究用户、内容运营、长期工作流搭建者，Hermes 的吸引力会越来越强。

因为你一旦开始在意下面这些问题，Hermes 就会很顺：

• 做过的事能不能留住
• 链路跑通后能不能变成 skill
• 能不能定时执行
• 能不能拆给子代理
• 能不能跨会话接着干
• 能不能给不同角色不同配置边界

它打动人的地方，不是“第一分钟就很炫”，而是“第三周你已经回不去了”。

这个差别非常现实。

OpenClaw 更容易在第一眼打动人。

Hermes 更容易在长期使用里拴住人。

前者像一款你会愿意装起来、接进生活、拿来天天聊的 AI 产品。

后者像一套你会慢慢往里塞工作流、塞技能、塞记忆，最后离不开的生产系统。

这两种强，不是一个维度。

—

六、最容易被说错的一句话，是“OpenClaw 偏前台，Hermes 偏后台”

很多人喜欢用一句话偷懒：

“那不就是 OpenClaw 偏前台，Hermes 偏后台吗？”

这个说法不能说全错，但只说到一半。

更准确一点的说法应该是：

OpenClaw 更关心‘人如何自然使用 AI’。Hermes 更关心‘AI 如何持续把事做完’。

重点不只是前台后台，而是问题意识不同。

前者是入口问题。

后者是执行系统问题。

所以你如果只拿“谁功能更多”来比，很容易吵半天没结果。

因为两边根本不是在同一个地方发力。

这也是我为什么一直觉得，OpenClaw 和 Hermes 最值得看的，不是谁赢谁输，而是它们各自代表了 Agent 落地的两条路线：

一条路，往“更像生活里的 AI 助手产品”去。

一条路，往“更像长期工作的 Agent 系统”去。

这两条路，未来大概率都会越来越重要。

但对个体用户来说，最重要的不是站队，还是先认清自己现在缺哪一种。

—

七、普通用户、内容运营、开发者，到底怎么选

如果你看到这里，最想要的可能还是一句更直接的话：

那我到底怎么选？

我给你最省时间的版本。

如果你更在意这些，优先看 OpenClaw：

• 想让 AI 直接住进 Telegram、Slack、WhatsApp 等熟悉入口
• 很在意语音、设备、移动端、Canvas 这类交互体验
• 想做一个更像产品的 personal AI assistant
• 你要的是上手就有感觉的使用体验

如果你更在意这些，优先看 Hermes：

• 想把经验沉淀成 skill
• 想让 AI 记住你、记住工作方式、记住历史上下文
• 想做定时任务、长期自动化、研究链路、内容流水线
• 想拆子代理、多角色、多 profile 协同
• 想把 Agent 逐步养成一套工作系统

如果你已经在 OpenClaw 用得很顺，但最近越来越频繁地碰到 memory、skill、cron、profiles、subagents 这些需求，这通常不是你之前选错了。

更可能是：

你的需求已经从“我想用 AI”，升级成“我想让 AI 长期替我干活”。

这时候，你自然会更看懂 Hermes 的价值。

—

八、我怎么看

我自己的判断很简单。

OpenClaw 代表的是 Agent 产品化的一条路。

它在解决的是：

怎么让 AI 更自然地进入消息、语音、设备、移动端和日常使用场景。

Hermes 代表的是 Agent 系统化的一条路。

它在解决的是：

怎么让记忆留下来，怎么让技能沉淀下来，怎么让任务拆分、调度、执行、继承，最后长成一套真正能持续跑的工作系统。

所以我不会简单说谁碾压谁。

这种说法很爽，但没价值。

真正有价值的是承认：

它们在解决不同阶段、不同重心的问题。

如果你现在最缺的是一个像产品的助手，OpenClaw 更对味。

如果你现在最缺的是一个会越来越会干活的系统，Hermes 更对味。

把这个问题想清楚，选型就不会再跑偏。

不适合谁 / 适合谁

不适合这篇文章的人：

• 只想看一句“谁赢了”的结论，不关心产品定位和系统结构
• 只想做情绪站队，不想看能力边界和使用场景

适合这篇文章的人：

• 正在做 AI 助手、Agent、自动化、内容工作流的人
• 正在 OpenClaw 和 Hermes 之间犹豫的人
• 已经在在一个系统里跑起来，但开始遇到能力边界的人

坑和注意点

有几个坑，最好提前说透。

第一，不要只看功能名重叠，就以为它们是平替。

都有消息入口，不代表定位一样。

都有 skill / memory / gateway，也不代表系统中心一样。

第二，不要把“第一眼产品感”，误判成“长期工作能力”。

OpenClaw 第一眼很有产品吸引力，这是真的。

但长期自动化、技能沉淀、调度闭环，未必是同一种强项。

第三，也不要把“长期闭环能力”误判成“人人都更适合”。

Hermes 这套思路很强。

但如果你现阶段最核心的需求，就是自然入口、多端消息、语音和陪伴式使用，那 OpenClaw 反而可能更直接。

所以别被社区气氛带着跑，先看自己到底缺什么。

收藏版清单

一句话记忆：

• OpenClaw：更像 AI 助手产品
• Hermes：更像 Agent 执行系统

OpenClaw 重点看：

• 多端消息入口
• 语音唤醒与 Talk Mode
• 设备节点
• Canvas
• 产品化体验

Hermes 重点看：

• memory
• skills
• session search
• cron
• subagents
• toolsets
• profiles
• 长期自动化闭环

下一步建议

如果你已经在 OpenClaw 跑得很顺，先别为了“追新”硬迁。

先问自己一句：

你是不是已经开始频繁需要长期记忆、技能沉淀、任务调度、多机器人协同？

如果还没有，这件事不急。

如果你现在最头疼的是：

– 做过的事留不住

– 自动化链路接不长

– 不同角色不好分工

– 一轮聊完就断档

那你应该认真试试 Hermes。

如果你是第一次入坑，最省时间的方法不是看谁喊得更大声，而是先回答这一句：

你要的是一个陪你随时对话的 AI 助手，还是一个会越来越会干活的 Agent 系统？