OpenClaw 和 Hermes Agent,到底该怎么选?

最近一段时间，OpenClaw 和 Hermes Agent 经常被放在一起讨论。一个走的是工程化、可控、安全的路线，另一个主打自进化、技能沉淀和越用越强。表面上看，它们都是 Agent 工具，但真拆到架构、技能、记忆和执行逻辑这一层，你会发现两者其实不是在回答同一个问题。

这篇文章我不打算站队，也不想重复“谁吊打谁”的结论式写法，而是结合官方资料、实际安装环境和可复现的操作路径，把 OpenClaw 和 Hermes Agent 放在同一张桌子上认真比一遍：它们分别适合谁，强项在哪里，短板是什么，以及如果你真的准备上手，第一步应该怎么选。

一句话先说结论：

OpenClaw 更像一个“可控的 AI 助手操作系统”；Hermes Agent 更像一个“会把经验沉淀下来的自进化 Agent”。

如果你关心的是多端接入、网关、权限、安全审计、可控执行，OpenClaw 更顺手。

如果你关心的是让 Agent 越用越熟，自动把复杂任务沉淀成技能，Hermes Agent 更有想象力。

所以这篇文章不做情绪判断，只从安装、架构、技能、记忆、安全、执行环境和复现实验几个角度，把两者讲清楚。

先看现状：两个项目都已经不是“小玩具”

截至我写这篇文章时，OpenClaw 官方 GitHub 显示已经超过 36 万 star，最新 release 是 `2026.4.20`

Hermes Agent 官方 GitHub 显示超过 10 万 star，最新 release 是 `v0.10.0`。官方文档里给它的定位很直接：一个自改进、多渠道、带技能和记忆系统的 AI Agent。

这两个项目有一个很有意思的关系：Hermes 文档里甚至专门提供了从 OpenClaw 迁移的命令：

bashhermes claw migrate

也就是说，Hermes 并不是只把 OpenClaw 当成竞争对手。它至少承认了一个现实：很多用户的 Agent 使用习惯、技能、配置，已经先在 OpenClaw 里沉淀了一部分。

这点很关键。以后讨论这类 Agent 工具，不要只问“谁替代谁”，还要问“谁更适合作为我的下一层工作台”。

安装体验：OpenClaw 更容易先跑起来，Hermes 在 Windows 上要绕一下

OpenClaw 安装

OpenClaw 的安装路径比较直接。官方推荐通过 npm 安装：

bashnpm install -g openclaw@latest openclaw onboard

如果你只是想先试起来，OpenClaw 的门槛相对低一些。尤其是你已经有 Node.js 环境时，安装和升级都比较自然。

Hermes Agent 安装

Hermes 官方给的安装方式是：

bashcurl -fsSL https://hermes-agent.nousresearch.com/install.sh | bashhermes setup

但这里有个坑：Hermes 官方明确不支持 Windows 原生安装，Windows 用户要用 WSL2。

所以如果你是 Windows 用户，复现路径应该是：

powershellwsl --install

重启后进入 Ubuntu / Debian 之类的 WSL 环境，再执行 Hermes 的安装命令。

我没有在 Windows 环境硬装 Hermes。这个选择不是偷懒，而是为了避免两件事：

第一，非官方路径装出来的结果没有代表性。

第二，文章写给别人照着做，必须尽量减少“我这里可以，你那里不行”的玄学。

如果你是 macOS 或 Linux 用户，Hermes 的安装反而会更直接。

最大差异：OpenClaw 先问“怎么安全执行”，Hermes 先问“怎么越用越强”

这才是两者真正的分水岭。

OpenClaw 的底层问题是：我怎么把一个 AI 助手接入真实环境，让它能访问文件、浏览器、终端、消息平台，同时又尽量可控？

所以它天然会重视这些东西：

- 网关- 多端接入- 安全审计- sandbox- 工具权限- 技能管理- 记忆搜索- 后台任务

Hermes Agent 的底层问题是：Agent 做完一件复杂任务后，能不能把经验沉淀下来，下次少走弯路？

所以它特别重视：

- skill loop- 自动创建 / 更新技能- MEMORY.md- USER.md- 历史会话搜索- 外部记忆提供商- 多后端执行环境- 从 OpenClaw 迁移

这两个出发点都对，只是优先级不同。

OpenClaw 的气质更像工程产品：先把边界、接入和控制做好。

Hermes 的气质更像研究型工具：先把 Agent 自己变强这条路跑通。

技能系统：OpenClaw 偏“管理”，Hermes 偏“沉淀”

这部分是我最建议重点看的地方。

OpenClaw 现在也有 Skills，而且不是早期那种随手塞几个 prompt 文件。它的技能来源包括内置技能、本地技能、工作区技能、ClawHub 技能等，还支持安装、更新和生命周期管理。

简单说，OpenClaw 的技能更像一个“插件化知识包”：

你可以提前写好；

可以从社区安装；

可以放在工作区；

可以让不同项目加载不同技能；

可以通过 manifest 和文件结构管理边界。

这种方式很稳，适合团队和工程场景。缺点也明显：它更依赖人主动维护。

Hermes 的技能系统则更激进。

Hermes 的文档把 Skills 称为 procedural memory，也就是“过程性记忆”。它希望 Agent 在完成复杂任务后，自己判断这段经验是否值得保存。如果值得，就把流程写成 Markdown 技能文件，后面再遇到类似任务时直接复用。

举个例子。

你让 Hermes 做一次“调研一个开源项目，然后写成公众号文章”的任务。它可能经历这些步骤：

1. 找官方仓库和文档2. 看 release 和 install guide3. 抽取关键能力4. 设计复现实验5. 写文章结构6. 输出最终稿

如果这个过程足够复杂，而且中间用了多次工具调用，Hermes 就有机会把它沉淀成一个类似这样的技能：

markdownopen-source-project-review## 适用场景当用户要求分析一个开源项目，并输出面向公众号或博客的文章时使用。## 步骤1. 查官方仓库和文档，不优先引用二手文章。2. 记录版本、安装方式、系统要求和关键功能。3. 设计最小可复现实验。4. 对比竞品时先统一模型、环境和任务。5. 最后输出文章正文和资料来源。

这就是 Hermes 最吸引人的地方：它不是只完成这一次任务，而是想把“怎么完成这类任务”的经验存下来。

当然，这里也有风险。

因为“要不要创建技能、技能写得好不好、下次会不会正确调用”，很大程度依赖模型的判断。模型判断错了，技能就可能变成噪音；技能越来越多，也需要人定期清理。

所以我的判断是：

OpenClaw 的 Skills 更适合可控交付，Hermes 的 Skills 更适合个人探索和流程打磨。

如果你是团队负责人，我会更愿意让 OpenClaw 管核心技能。

如果你是个人重度用户，我会愿意让 Hermes 先跑一段时间，看它能不能把你的工作流学出来。

记忆系统：旧说法需要更新了

之前有些文章会把两者简化成：

Hermes 是三层记忆，OpenClaw 只有单插件槽位。

这个说法现在不太准确。

Hermes 的记忆确实做得比较完整。它有几类东西：

- MEMORY.md：长期记忆- USER.md：用户画像和偏好- session_search：历史会话搜索- 外部 memory provider：比如 Honcho

这套设计很适合个人助手。它不仅知道你刚才说了什么，还尝试记住你长期偏好的工作方式。

OpenClaw 这边也不是只有一个“记忆插件槽”。官方文档里已经有 MEMORY.md、memory search、memory dreaming 等能力。

OpenClaw 的 memory search 更偏检索增强：需要时从历史记忆或索引里找相关内容。

memory dreaming 则更像后台整理：把碎片化历史归纳成更稳定的记忆文件。

如果非要用一句话区分：

Hermes 的记忆更像“个人助理的脑子”，OpenClaw 的记忆更像“可接入、可检索、可治理的知识层”。

这也对应它们的性格。

Hermes 希望越用越懂你。

OpenClaw 希望记忆这件事不要破坏可控性。

安全模型：不要迷信“默认安全”

安全这块，很多文章容易写偏。

比如把 OpenClaw 写成绝对安全，把 Hermes 写成放飞自我。这样不准确。

更准确的说法是：

OpenClaw 更早把安全审计、网关信任和 sandbox 当成产品主线；Hermes 也有多层安全设计，但如果你用默认 local backend，它本质上还是在本机跑命令。

OpenClaw 官方有 security audit、sandboxing、trusted operator model 等文档。它支持 Docker、SSH、OpenShell 这类隔离或远端执行方式，也会强调不要把高风险主机直接暴露给 Agent。

Hermes 官方安全文档也写了多层安全，包括命令审批、容器隔离、危险命令拦截、跨会话隔离等。但 Hermes 的配置文档里也说得很清楚：默认 local backend 没有隔离。

所以真正该写进实践里的建议是：

如果只是本地玩一玩，任何一个工具都不要给它放生产密钥。

如果要跑真实任务，尽量用容器、远端沙箱或最小权限用户。

如果要让它操作私有仓库，先从只读任务开始。

如果要让它改文件，必须有 Git 工作区和回滚路径。

如果要让它执行 shell，先禁用或限制危险命令。

这不是保守，这是 Agent 工具的基本卫生习惯。

执行环境：Hermes 后端选择更多，OpenClaw 更强调网关控制

Hermes Agent 支持多种 backend，包括 local、docker、ssh、modal、daytona、singularity。

这点对高级用户很有吸引力。比如你想把任务丢到远端机器、云端 sandbox、科研环境或者容器里跑，Hermes 的后端选择会更多。

OpenClaw 的执行环境更围绕 Gateway 和 Node 展开。它也支持 Docker、SSH、OpenShell 等 sandbox/backend，但它的重点不是炫 backend 数量，而是把“用户、消息、工具、模型、执行环境”串起来。

所以这块也不是谁更强，而是看你要什么。

你想做一个自己每天都能在微信、Telegram、浏览器、桌面里叫出来的助手，OpenClaw 的产品感更完整。

你想研究 Agent 怎么在不同计算环境里执行和沉淀技能，Hermes 的探索空间更大。

国内平台：Hermes 更直接，OpenClaw 也不是不能扩

Hermes 的官方文档里列了很多 messaging integration，里面包括飞书、钉钉、企业微信等国内常用平台。

OpenClaw 的强项是 Gateway 和多端接入，官方也列了 WhatsApp、Telegram、Discord、iMessage、Slack、Signal 等通道，还可以通过插件继续扩展。

如果你是国内团队，想接企业微信、飞书、钉钉，Hermes 的开箱路径看起来更顺。

如果你更在意个人助理、多端消息入口、浏览器和本地工具联动，OpenClaw 会更自然。

怎么复现一次相对公平的对比？

Agent 工具很难做绝对公平的跑分。因为结果会被模型、网络、权限、上下文、工具可用性影响。

但我们至少可以做一个“相对靠谱”的对比。

第一步：统一模型

不要让 OpenClaw 用一个模型，Hermes 用另一个模型，然后拿结果说谁强。

尽量让两边使用同一个模型、同一个 API provider、同一个温度参数。如果实在做不到，文章里必须写清楚。

第二步：准备同一个测试目录

可以建一个最小项目：

bashmkdir agent-abtestcd agent-abtestgit initmkdir src test docs

写一个很小的需求文件：

bashcat > docs/task.md <<'EOF'请完成一个小型项目改造：1. 阅读 src/calc.js 和 test/calc.test.js。2. 修复测试失败的问题。3. 给 README.md 增加使用说明。4. 不要改无关文件。5. 完成后说明你改了什么、怎么验证。EOF

再写一段故意有 bug 的代码：

bashcat > src/calc.js <<'EOF'export function add(a, b) { return String(a) + String(b)}export function divide(a, b) { return a / b}EOF

测试文件：

bashcat > test/calc.test.js <<'EOF'import { add, divide } from '../src/calc.js'if (add(1, 2) !== 3) { throw new Error('add failed')}if (divide(6, 2) !== 3) { throw new Error('divide failed')}EOF

再补一个 `package.json`：

bashcat > package.json <<'EOF'{ "type": "module", "scripts": { "test": "node test/calc.test.js" }}EOF

第三步：给两个 Agent 同一个 prompt

提示词不要太玄，越像真实工作越好：

text请阅读 docs/task.md，完成里面的项目改造。要求：1. 先说明你的计划；2. 修改前先确认相关文件；3. 运行测试；4. 不要改无关文件；5. 最后给出验证结果和文件变更摘要。

第四步：记录这几项

建议记录一个表：| 指标 | OpenClaw | Hermes Agent || 是否先读需求文件 | | || 是否只改相关文件 | | || 是否主动运行测试 | | || 是否遇到危险命令审批 | | || 是否留下可读总结 | | || 第二次类似任务是否更快 | | || 是否沉淀 skill / memory | | |

第一轮看“完成任务能力”。

第二轮换一个类似的小项目，看“是否复用经验”。

这时 Hermes 的 skill loop 才有机会体现出来。

如果只跑一次就下结论，基本不公平。Hermes 的卖点本来就不是第一次惊艳，而是第二次、第三次是否更会做。

我的选型建议

如果你是普通个人用户，想先用起来，我建议先试 OpenClaw。

原因不是 Hermes 不好，而是 OpenClaw 的入口更顺，产品感更完整，尤其是你已经在 Windows 上装好了 OpenClaw。

如果你已经用 OpenClaw 做了一段时间，开始积累固定工作流，比如写周报、整理资料、处理开源项目、批量生成内容，那就值得试 Hermes。

但我建议你不要一上来就把 Hermes 接到真实生产目录。先用 WSL2 或 Linux 机器，准备一个干净测试目录，让它跑三类任务：

第一类，简单代码修复。

第二类，资料调研和文章输出。

第三类，重复性工作流，比如每次都按同一格式整理项目。

如果第三类任务第二次明显更顺，Hermes 才算真正发挥价值。

如果你是团队负责人，我的建议更保守：

核心生产任务优先 OpenClaw，尤其是权限、审计、网关、执行边界要清楚。

个人研究和工作流探索可以让 Hermes 先跑。

等某些 Hermes 自动沉淀的 skill 被验证稳定，再人工整理进团队技能库。

这样更安全，也更现实。

最后说一句

OpenClaw 和 Hermes Agent 的关系，不像两个输入法，不是谁装了另一个就没意义。

它们更像两种不同的 Agent 思路：

OpenClaw 是把 Agent 放进真实世界之前，先想清楚边界、通道和控制。

Hermes 是让 Agent 在真实工作里不断积累经验，逐渐形成自己的工作方法。

一个偏控制，一个偏成长。

我更愿意把它们看成两条会互相借鉴的路线，而不是简单的“谁杀死谁”。

如果你现在只想要一个结论：

想稳一点，先 OpenClaw；想折腾自进化，试 Hermes；想长期用，最好两边都跑一轮自己的真实任务，再决定谁进主力工作流。