别直接把 OpenClaw 搬到 Hermes Agent:我把迁移、冲突和回滚完整跑了一遍-夜雨聆风

别直接把 OpenClaw 搬到 Hermes Agent:我把迁移、冲突和回滚完整跑了一遍

大家好，我是 One，

很多人以为从 OpenClaw 换到 Hermes Agent，就是把 ~/.openclaw/ 改名，再跑一条安装命令，

其实要做得好，没这么简单，

我在隔离目录里造了一套带有模型配置、MCP、workspace、memory 和 skill 的 OpenClaw 测试实例，

装上当前 Hermes Agent v0.18.2，完整跑了一遍预览、迁移、密钥边界和回滚，

先说结论，迁移工具现在确实能帮你搬不少东西，但它搬的是“可映射的数据”，不是把两个 Agent 的运行时原样复制过去，

真正注意的地方，仍然是 workspace、认证、冲突文件和迁移后的验证，

OpenClaw 迁到 Hermes Agent，真正容易出问题的不是复制文件，

而是环境隔离、配置冲突、认证迁移和失败回滚，这篇文章把实际跑过的命令、失败结果和完整迁移链路都拆开了，

先别迁，先判断你是不是适合迁

如果你只有一个 Agent、一个模型 provider、一个消息入口和一个 workspace，迁移的风险相对可控，先复制数据，跑预览，再逐项验证，

如果你有多个 Agent 共享状态、多个租户共用 system-level service、复杂的 channel binding，

或者依赖 OpenClaw 特有插件，建议先做旁路迁移，不要直接停掉生产实例，

还有一个现实问题，Telegram 这类 bot token 同一时间只能由一个活跃轮询实例使用，

OpenClaw 没停，Hermes 又拿同一个 token 启动，最后通常不是两个都能用，而是互相踢下线，

所以迁移顺序不是“安装 Hermes → 复制文件”，而是：备份，隔离，停止旧服务，预览，迁移，重新认证，启动新 gateway，最后才切消息入口，

第一关：隔离 Hermes，别拿生产 profile 做实验

我第一次测试只设置了 HOME，但 Hermes 仍然把目标解析到了当前公众号助手 profile，还检测到了正在运行的 Feishu gateway，

这不是小问题，Hermes 当前用 HERMES_HOME 决定自己的数据根目录，单独改 HOME 不够，

先建立一个临时目标，真实迁移时换成你自己的新目录，

export HERMES_HOME=/tmp/hermes-migration-testmkdir -p "$HERMES_HOME"hermes --versionhermes config path

我这次实际跑到的版本是：

Hermes Agent v0.18.22026.7.7.2

这里还有一个容易被忽略的保护，当前 Hermes 会拒绝在 /tmp 这种临时目录里写 systemd gateway unit，提示这是测试环境，

所以临时目录可以用来验证配置和迁移结果，但不能把它当成最终服务安装目录，

真正部署 gateway 时，要换到正常的 Hermes home，并确认 systemd 用户服务的范围，

第二关：先做 OpenClaw 归档，不要只备份 json

OpenClaw 的配置不是 Agent 本体，workspace 才是 Agent 长期行为的一部分，至少要把这些内容一起收走：

~/.openclaw/└── openclaw.json~/.openclaw/workspace/├── SOUL.md├── AGENTS.md├── MEMORY.md├── USER.md├── memory/└── skills/

生产环境先停服务，再归档，路径按你的实际 workspace 调整，

openclaw gateway statusopenclaw gateway stoptar czf ~/openclaw-archive-$(date +%Y%m%d).tar.gz \  ~/.openclaw/ \  ~/.openclaw/workspace/

注意的一点是，

这个~/clawd/ 目录是我的 workspace，不是所有 OpenClaw 安装的固定路径，

当前 OpenClaw 默认workspace 更常见的是~/.openclaw/workspace，

第三关：先 dry-run，再决定是否覆盖

当前 Hermes 的原生迁移入口是：

hermes claw migrate --help

官方提供两个 preset，user-data 主要搬用户数据，full 会尝试搬更多兼容配置，但两个 preset 默认都不会导入 secrets，

我这次先用不带密钥的预览：

hermes claw migrate \  --source"$HOME/.openclaw" \  --dry-run \  --preset user-data \  --workspace-target /tmp/hermes-migration-workspace

在我的合成测试实例里，预览显示 11 项会迁移，1 项冲突，24 项跳过，

迁移内容包括 SOUL.md、memory、USER、model、MCP、agent config、session config 和 workspace skill，

跳过的内容里包括 cron、hooks、gateway、browser、tools、approvals、插件配置和原始 OpenClaw runtime 数据，

这就是迁移工具最容易被误解的地方，预览里没有出现的东西，不会因为你换成 full 就自动变成 Hermes 原生能力，

我的目标目录第一次启动时已经自动生成了 Hermes 默认 SOUL.md，所以迁移工具默认拒绝覆盖，报的是 conflict，不是失败，

确认过目标目录确实是新的、没有要保留的文件之后，才使用：

hermes claw migrate \  --source"$HOME/.openclaw" \  --preset user-data \  --workspace-target /tmp/hermes-migration-workspace \  --overwrite \  --yes

不要一上来就加 --overwrite，先看 preview，尤其是多人共用 profile 或者你已经启动过 Hermes 的机器，

第四关：workspace、memory 和 skills 怎么映射

我实际迁移后确认的结果是：SOUL.md 进入 Hermes home，MEMORY.md 和 USER.md 进入 memories/，

每天的 memory 文件会合并进 Hermes 的 memory 文件，AGENTS.md 则可以通过 --workspace-target 放到指定 workspace，

原来的 workspace skill 会被放到：

$HERMES_HOME/skills/openclaw-imports/

我特意在测试里放了一个嵌套目录 memory/research/keep.md，

迁移之后它没有被当成 Hermes memory 直接吞掉，而是出现在迁移报告的 archive 目录里，

这件事很重要，迁移工具会把它能理解的内容合并到 Hermes memory，

但复杂的目录结构仍然需要你自己复核，不能只看 MEMORY.md 里有没有几行文字，

迁移后建议直接检查：

find "$HERMES_HOME/memories" -maxdepth 3 -type f -printfind "$HERMES_HOME/skills/openclaw-imports" -maxdepth 3 -type f -printsed -n '1,120p'"$HERMES_HOME/SOUL.md"sed -n '1,160p'"$HERMES_HOME/memories/MEMORY.md"

如果 Agent 能回复，但说话方式、用户背景和长期上下文都没了，优先检查 workspace 是否迁移，而不是先换模型，

第五关：配置能搬，旧 OAuth 不要盲信

OpenClaw 的模型配置可以被转换成 Hermes 的 config.yaml，

我这次真实看到的是：默认模型进入 model.default，MCP 进入 mcp_servers，自定义 provider 进入 custom_providers，

hermes config showhermes config checkhermes config path

注意， hermes config get gateway.port 在当前 Hermes v0.18.2 里不是有效命令，

当前应该用 config show、config check 和 config path，不要把旧文章里的命令原样复制，

认证是另一条线，当前 Hermes 文档优先使用：

hermes authhermes auth add <provider>hermes auth status <provider>

旧版本里的 hermes login 仍可能出现在旧教程里，但不应该把它写成所有版本的唯一入口，具体 provider 按当前 hermes auth --help 确认，

我的建议是：迁移配置，重新登录，验证一次真实模型调用，三件事分开做，

旧 OAuth token 即使格式能被复制，也可能已经过期，最麻烦的是 gateway 能启动，消息入口也能通，

但每次真正调用模型都失败，Agent 看起来活着，其实不会思考，

第六关：secrets 默认不迁，确实需要时才显式打开

我用合成的假 token 做了第二轮 full 测试，

只有显式加 --migrate-secrets 后，迁移预览才出现 .env 和 allowlisted 环境变量，默认 user-data 和 full 都不会偷偷导入密钥，

hermes claw migrate \  --source"$HOME/.openclaw" \  --preset full \  --migrate-secrets \  --workspace-target /absolute/path/to/workspace \  --overwrite

这一步不要在文章、截图或日志里暴露 token，我的测试只核对了 .env 里出现了预期的变量名，没有把任何密钥值写入记录，

Telegram bot token、provider API key、gateway token 这些东西，

最好先手动列清楚，哪些要重新生成，哪些可以复制，哪些必须重新登录，别把“迁移成功”理解成“所有认证都自动恢复”，

第七关：gateway 不要直接照抄旧教程

当前 Hermes 官方入口是：

hermes gateway setuphermes gateway installhermes gateway starthermes gateway status

Linux 用户服务通常配合：

sudo loginctl enable-linger "$USER"

我没有在真实 Telegram 账号上启动 pairing，因为这会产生外部消息和 token 竞争，官方命令形态可以确认，

但具体 code 要以你的 gateway 日志为准：

hermes pairing listhermes pairing approve telegram <CODE>

切换消息入口前，先确认 OpenClaw 已经停掉，再让 Hermes 单独接管 bot，验证一条最小消息，最后再恢复 cron 和其他 channel，

第八关：cron、插件和多 Agent 不要假设会自动出现

迁移报告里，我的 cron、hooks、gateway、plugins 和复杂 channel 都被列为 skipped，

这不是迁移工具坏了，而是这些内容需要按 Hermes 的运行方式重建，当前可以先看：

hermes cron --helphermes cron listhermes skills list

计划任务可以在已运行的 Hermes 对话里用自然语言创建，具体语法不要写死成某一句 slash command，先以当前平台帮助为准，

OpenClaw 的多 Agent 列表也不应该直接等价成 Hermes 的多个 workspace，

复杂部署要重新设计 profile、共享 memory 和消息路由，单 Agent 迁移能跑通，不代表三套互相依赖的 Agent 也能原样搬过去，

最后一定要做回滚测试

每次实际迁移都会在 Hermes home 下生成备份，例如：

$HERMES_HOME/backups/pre-migration-YYYY-MM-DD-HHMMSS.zip

我在测试里先修改了迁移后的 config.yaml，再执行：

hermes import \"$HERMES_HOME/backups/pre-migration-YYYY-MM-DD-HHMMSS.zip" \  --force

命令真实返回了 Import complete，配置回到了迁移前的状态，

回滚不是“出问题再想办法”，而是迁移验证的一部分，至少要确认三件事：备份文件存在，备份能被 hermes import 读取，回滚后配置确实恢复，

我最后确认的迁移清单

[ ] OpenClaw 已归档，workspace 不只备份了 openclaw.json[ ] Hermes 使用独立 HERMES_HOME，未碰生产 profile[ ] dry-run 预览过冲突和 skipped 项[ ] SOUL、MEMORY、USER、AGENTS、skills 都逐项检查[ ] config.yaml 能通过 hermes config check[ ] provider 重新认证，未盲信旧 OAuth[ ] secrets 是否迁移已经明确决定[ ] OpenClaw gateway 已停止，避免 bot token 冲突[ ] Hermes gateway 单独启动并检查状态[ ] Telegram pairing 或其他入口完成最小消息验证[ ] cron、hooks、plugins、多 Agent 路由单独重建[ ] pre-migration zip 可以被 hermes import 恢复

这次实测没有把 Telegram 真实账号、生产 provider 或线上 gateway 接进来，

所以我能确认的是迁移工具的配置映射、

workspace/memory/skills/MCP 导入、secret 开关、冲突处理、备份和回滚，不能把它包装成“所有渠道端到端已经跑通”，

我的判断是，OpenClaw 到 Hermes Agent 不是一次目录搬家，而是一次运行时迁移，

单 Agent、单入口的用户可以迁，先按这套流程旁路跑一遍，确认 Agent 没有失忆，模型真的能调用，消息真的能回来，再切生产，

多 Agent、强耦合、多租户用户不要急着换，先把 channel、cron、plugin 和共享状态画出来，

迁移工具能帮你处理一部分文件，但不会替你完成架构重写，

以上，

看到这里，如果这篇内容对你有一点帮助，

欢迎点个赞、在看，或者转发给需要的朋友～

如果不想错过后续更新，也可以给我点个星标🌟，第一时间收到推送。

感谢你的阅读和支持，我们下篇文章见！