Hermes Agent 与 OpenClaw 迁移指南
正在考虑从 OpenClaw 迁移到 Hermes Agent?本指南对比两者的权衡取舍,说明哪些内容可以迁移,并给出最稳妥的迁移路径。

OpenClaw 更大,Hermes 更专注
如果你现在正在使用 OpenClaw,那你面对的并不是一个成熟产品与一个实验性项目之间的选择。截至 2026 年 4 月 12 日,OpenClaw 的 GitHub 仓库已有 356k 星标,最新版本为 openclaw 2026.4.11;而 Hermes Agent 仓库有 65.5k 星标,最新版本为 2026 年 4 月 8 日发布的 Hermes Agent v0.8.0。两个项目都在活跃维护,都有足够的可信度。问题不在于哪个"更真实",而在于哪个更符合你的工作方式。
OpenClaw 的功能面更广、更成熟。其官方文档将其定位为一款个人 AI 助手,覆盖海量渠道和设备,具备浏览器控制界面、引导流程、插件系统、配套应用以及宽泛的网关模型。Hermes Agent 则采取了不同的立场——Nous 将其描述为**"随你成长的智能体"**,具备持久化记忆、自动生成技能,并围绕长期智能体行为形成了更鲜明的产品主张。
这一差异对于考虑迁移的用户至关重要。你不是在替换一个 CLI 工具,而是在决定:你想要的是一个功能广泛的助手平台,还是一个更有主见的智能体运行时。
本指南面向第二种情况:你已经熟悉 OpenClaw,现在想要迁移到 Hermes,同时不丢失那些对你重要的东西。
什么时候迁移到 Hermes 更合适
如果以下描述大多符合你的情况,Hermes 会是个好选择:
- 你希望智能体体验的核心是记忆、档案、技能和长期运行行为,而不是浏览器控制台。
- 你认可一个能通过持久化记忆和自动生成技能随时间积累上下文的智能体理念。
- 你主要使用一两个消息平台(比如 Telegram),而不是需要覆盖大量渠道的复杂多平台配置。
- 你希望有官方迁移路径,而不是手动重建提示词、记忆文件、服务商凭证和 Telegram 配置。
Hermes 现在提供了这条官方路径。文档中包含专门的迁移指南以及 CLI 参考中的 hermes claw migrate 命令。这是 2026 年值得认真讨论这次迁移的最大理由。一年前,迁移成本对大多数用户来说还是太高了。
如果浏览器控制界面是你工作流的核心,或者你依赖其更丰富的插件和配套应用生态,又或者你的配置横跨多个消息平台并有自定义网关行为,那么 OpenClaw 仍然更适合你。OpenClaw 的文档明确说明平台支持大量渠道以及由网关提供服务的控制界面。如果这种广度正是你所需要的产品,仅仅因为 Hermes 更新而迁移,反而会是一种倒退。

切换之后实际会有哪些变化
最重要的实际变化是界面理念的不同。
OpenClaw 的入门流程围绕安装、引导、检查网关状态、在浏览器中打开控制台展开。文档表示从零到可用聊天大约只需五分钟,控制界面是最快的起点。Hermes 则相反,首先引导你使用 CLI 和配置流程,只有当你需要接入消息平台时才涉及网关。
这使得 Hermes 更像一个智能体运行时,而 OpenClaw 更像一个助手平台。
第二个重大变化是记忆机制。Hermes 的官方文档赋予记忆更核心的地位,内置了 MEMORY.md 和 USER.md 支持,并集成了多种外部记忆服务商。如果你希望长期回忆和结构化记忆成为系统的一等公民,Hermes 显然在朝这个方向持续投入。OpenClaw 当然也支持工作区提示词、技能、会话和智能体状态,但 Hermes 更明显地押注于"智能体应该跨会话持续进化"这一理念。
第三个变化是功能边界。OpenClaw 的功能面更广,这是它的优势,但也意味着更多的活动组件。其官方文档涵盖网关认证模式、控制界面来源规则、插件安装、移动端和 macOS 配套体验,以及完整的消息平台矩阵。Hermes 更窄、更有主见。对许多用户来说,这恰恰是它的吸引力所在。
Hermes 会帮你迁移哪些内容
Hermes 官方迁移指南出乎意料地详尽。hermes claw migrate 默认从 ~/.openclaw/ 读取,同时也能识别旧版 ~/.clawdbot/ 和 ~/.moldbot/ 目录。它提供 --dry-run 模式用于预览变更,--preset full 模式用于完整迁移,以及 --workspace-target 参数用于将工作区指令复制到指定项目。
更重要的是,迁移不仅限于几个外观文件。指南记录了以下内容的支持情况:
- 人格和工作区指令,如
SOUL.md和AGENTS.md - 来自
MEMORY.md、USER.md及每日记忆文件的长期记忆 - 服务商 API 密钥(需允许密钥迁移)
- 智能体行为设置,如推理力度、详细模式、时区、压缩、终端超时和 Docker 后端配置
- 会话重置策略
- MCP 服务器定义
- TTS 配置
- 包括 Telegram 在内的消息平台令牌(如果配置或
.env中能解析到相应值)
关键点在于:你不必从头重建你的智能体。
与此同时,Hermes 对哪些内容无法直接映射保持诚实。迁移指南会将没有直接对应项的内容归档到 ~/.hermes/migration/openclaw/<timestamp>/archive/ 中,留待人工审查。这些内容可能包括 IDENTITY.md、定时任务配置、插件配置、钩子、界面身份设置、日志配置以及多智能体列表。这是合理的设计——它避免了假装两个产品理念不同的系统可以一一对应。
迁移前需要盘点哪些内容
在执行任何命令之前,先快速盘点你 OpenClaw 配置中最重要的部分。这需要五分钟,通常能节省一个小时的后续清理工作。
| OpenClaw 资产 | Hermes 目标位置 | 注意事项 |
|---|---|---|
workspace/SOUL.md |
~/.hermes/SOUL.md |
直接复制 |
workspace/AGENTS.md |
目标工作区下的 AGENTS.md |
需要 --workspace-target |
workspace/MEMORY.md、USER.md、每日记忆文件 |
~/.hermes/memories/ |
合并并去重 |
| 工作区和共享技能 | ~/.hermes/skills/openclaw-imports/ |
仔细处理命名冲突 |
| 服务商 API 密钥 | ~/.hermes/.env |
仅在迁移密钥时有效 |
| Telegram 令牌和允许的用户 | Hermes .env 变量 |
导入后重启 Hermes 网关 |
| 插件、钩子、定时任务、界面身份设置 | 归档待人工审查 | 在 Hermes 中手动重建 |
如果你只是把 OpenClaw 当作聊天界面加几个提示词文件来使用,迁移风险很低。如果你有自定义插件、定时任务、钩子,或者高度定制的控制界面工作流,则需要预期一个混合过程——部分内容可以干净导入,部分需要手动重建。
最稳妥的迁移方式
不要把这当成重装系统。要把它当成一次状态迁移。
1. 冻结你的 OpenClaw 状态
OpenClaw 自己关于迁移到新机器的文档建议:在复制状态之前先停止网关,避免文件在复制过程中发生变化。同样的建议在这里也适用。
openclaw gateway stop
cd ~
tar -czf openclaw-state.tgz .openclaw
如果你使用了多个档案(如 ~/.openclaw-work),请分别备份每一个。
2. 先安装 Hermes
按照官方 Hermes 安装流程操作,然后运行 setup,确保在导入任何内容之前环境已就绪。
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
hermes setup
3. 在操作真实文件之前先做干演练
这是整个指南中最重要的一步。
hermes claw migrate --dry-run
如果你的项目级指令存放在独立的工作区,请附带目标路径:
hermes claw migrate --dry-run --workspace-target /path/to/your/project
仔细阅读报告,确认哪些内容会被迁移、哪些会被跳过、哪些会被归档待人工处理。
4. 执行真正的迁移
执行完整迁移(包含密钥):
hermes claw migrate --preset full --workspace-target /path/to/your/project
如果你更倾向于先迁移提示词、记忆和配置,稍后自行输入服务商凭证,可以改用 user-data 预设。
5. 验证那些通常会出问题的地方
Hermes 的迁移后检查清单指出了以下关键检查点:
- 运行
hermes status并验证服务商认证 - 检查归档文件目录,确认是否有需要手动重建的内容
- 如果迁移了消息平台令牌,重启 Hermes 网关
- 在 Hermes 配置中重新检查会话重置行为
- 如果你在 OpenClaw 中使用了 WhatsApp,需要手动重新配对

常见迁移错误
第一个错误是想当然地认为功能名称相同就意味着功能一致。插件、技能、钩子或重置策略可能在两款产品中都存在,但行为不同。请以迁移报告为准,而不是凭记忆判断。
第二个错误是在没有审计的情况下直接迁移密钥。当启用密钥迁移时,Hermes 可以从配置、.env 和认证档案中迁移密钥,这很方便,但也恰好是轮换旧密钥、删除未使用服务商、简化配置的好时机。
第三个错误是期待 OpenClaw 的体验在 Hermes 里原封不动地出现。这不会发生。如果你真正喜欢的是 OpenClaw 的控制界面、以网关为中心的工作流,或者配套应用层,在切换之前请对自己诚实。
那么,你应该迁移吗?
如果你想要功能最广泛的助手平台,OpenClaw 仍然是更稳妥的默认选择。它的生态更大,发布节奏稳健,官方文档覆盖了海量渠道、插件和运营商工作流。
如果你想要一个更专注的智能体——在持久化、技能、档案和长期上下文方面投入更深——Hermes 现在已经足够成熟,值得认真对待。官方迁移工具降低了试用成本,这改变了决策方程式。你不再需要在"永远留在 OpenClaw"和"一切从头手动重建"之间二选一。
这正是为什么 Hermes Agent 与 OpenClaw 的对比,如今已经是一个真实的迁移决策,而不再只是一篇推测性的比较文章。
参考来源
- Hermes Agent GitHub 仓库
- Hermes 官方网站
- Hermes 从 OpenClaw 迁移指南
- Hermes CLI 命令参考
- Hermes 记忆服务商文档
- OpenClaw GitHub 仓库
- OpenClaw 入门指南
- OpenClaw 迁移指南
- OpenClaw 控制界面文档
- OpenClaw 插件文档
试试 Hermify
如果你想体验 Hermes,又不想把周末花在 VPS 配置、容器搭建、Telegram 接入和持续更新上,用 Hermify 作为捷径吧。带上你的 API 密钥和 bot 令牌,跳过所有基础设施工作,专注于判断 Hermes 是否是适合你的长期智能体。最快的路径是用 Hermify 部署 Hermes Agent,然后再决定是否要自己掌管基础设施。