夜雨聆风上一篇是判断题，这一篇是落地题。
如果你已经决定要从 OpenClaw 往 Hermes 迁，接下来最重要的不是继续看热闹，而是先把顺序理顺。因为迁移这件事，很多时候不是输在不会配，而是输在太着急。
最常见的翻车方式通常都差不多：
• 没 dry-run 就真跑
• 没备份就改配置
• 没验证最小链路就切主入口
• 没保留旧环境就直接删干净
• 看到“迁移成功”四个字，就以为整个工作流已经恢复
这篇文章只做一件事：把更稳的迁移顺序、每一步为什么要这样排、做完应该看到什么、最常见的坑在哪，尽量一次讲清楚。
一、先别开跑，先判断你现在适不适合今天迁
很多人看到 Hermes 很火，就容易产生一种冲动：今天就迁。
但你真正该先问自己的，是下面这几个问题：
• 你最近手上是不是正有高优先级任务在跑？
• 你现在的 OpenClaw 有没有已经很稳定的主入口？
• 这次迁移一旦中间断掉，你能不能接受？
• 你有没有至少半天到一天的连续时间做验证？
• 你现在到底是在解决真实痛点，还是只是被热度推着走？
如果你最近任务很满、当前入口又正好很稳，那今天最好的动作，可能不是迁移，而是先把准备工作做完，改在低峰时间切。
这不是保守，是工程常识。
二、先盘点你真正要迁的到底是什么
很多人一说迁移，脑子里只有一个词：配置。
其实远远不止。
你真正要迁的，通常至少包括这些层：
1）入口层
• Telegram
• Discord
• Slack
• 其它你平时高频调用的消息入口
2）模型与 provider 层
• 默认模型
• fallback 模型
• 自定义 provider
• 本地模型入口
• API key 或 auth 方式
3）上下文资产层
• SOUL.md
• USER.md / MEMORY.md
• 每日 memory
• AGENTS.md
• skills
• 项目规则文档
4）外部能力层
• MCP 配置
• TTS
• 浏览器能力
• cron / hook / 插件
• 自定义脚本
5）运行与守护层
• 本地 CLI 能不能跑
• gateway 怎么启动
• 是否要做 systemd / 计划任务 / 常驻进程
• 日志去哪看
如果你不先把这几层拆开，后面一旦出问题，就很容易陷入一种典型混乱：
• 明明是入口冲突，结果你在查模型
• 明明是 provider 没配对，结果你在怀疑 memory
• 明明是服务没起来，结果你在翻 skill
建议你先列一个最小迁移清单
• 我当前最重要的入口有哪些
• 哪个模型必须先恢复
• 哪些项目规则必须保留
• 哪些 skills 是不能丢的
• 哪些额外能力需要人工复核
• 哪个旧环境在新环境没跑稳之前绝不能删
做完这一步，你对“这次迁移到底在迁什么”会清楚很多。
三、第一步一定是 dry-run，不要直接真跑
如果 Hermes 的迁移命令支持 dry-run，那第一次就一定先 dry-run。
因为你最需要先知道的，不是“命令能不能执行”，而是：
• 它准备迁什么
• 它准备跳过什么
• 哪些地方会冲突
• 哪些内容不会自动帮你处理
• 有没有任何会让你事后才后悔的动作
为什么 dry-run 这么值钱
因为迁移里最麻烦的，不是显式报错，而是“表面成功，但你误解了它做了什么”。
比如：
• 你以为某份配置会原地覆盖，实际上它被跳过了
• 你以为某份旧目录会保留，实际上后面会进入归档流程
• 你以为某些 provider 会被完整映射，实际上还要人工修
• 你以为只要命令跑完就可以切主入口，实际上关键链路还没验证
更稳的做法是这样
1. 先跑 dry-run
2. 把输出认真看完
3. 把“会迁移 / 会跳过 / 会冲突 / 需要人工处理”的项记下来
4. 再决定要不要正式执行
如果你连 dry-run 的结果都没看懂，就不要急着真跑。
四、在真迁移之前，先把备份和回退空间留好
我建议你至少做三件事。
1. 备份旧配置
最基本的，是把 OpenClaw 当前核心配置单独备份一份。
因为你后面真正需要回头查的，往往不是“当时有没有装”，而是：
• 某个 token 当时怎么配的
• 某个 provider 原来叫什么
• 某个 fallback 链原来怎么写的
• 某个入口原来绑到了哪个 agent
2. 备份工作区或关键目录
如果你的项目已经不轻，最好至少把关键工作区做一份独立备份。
尤其是：
• 项目规则
• 项目进展
• skills
• memory
• 自定义脚本
• 任何你已经跑顺的工具链配置
3. 不要让你当前 shell 仍然挂在旧路径里
如果你当前很多终端会话、脚本 cwd、工具工作目录，还挂在旧目录上，一旦你后面触发归档、改名、移动目录，很容易出现一串非常烦的连锁问题：
• 路径失效
• 子进程起不来
• 命令工具突然找不到当前目录
• 你以为是 Hermes 出问题，其实是工作目录已经废了
所以正式开跑前，先把当前操作环境切到一个安全位置。
五、正式迁移后，先别急着宣布成功，先修最容易错的基础项
“文件迁过去了”和“系统能稳定工作了”，中间差很多步。
我最建议你优先检查这几类基础项。
1）默认模型和 provider 是否真的可用
不要只看配置文件里像不像。
你真正该验证的是：
• 默认模型能不能真正发起请求
• provider 有没有正确认到对应命名空间
• API key / OAuth / 本地 provider 是否真的生效
• fallback 链在需要时能不能正常接住
这里很容易出现一种典型误区：字段已经在，但行为不对。
2）CLI 最小可用性
先别急着测大任务。
先确认最小命令能不能通，比如：
• CLI 能正常启动
• 能正常识别当前 provider
• 能跑一个最简单的对话或最小调用
这一层如果都没通，就不要往 gateway 或消息入口上堆复杂度。
3）必要的长期资产有没有落到正确位置
这一层重点查：
• SOUL
• USER / MEMORY
• skills
• AGENTS 或项目规则
• 关键项目文档路径
因为有些东西不是“迁过去就好”，而是“必须落在你后续真正会继续使用的位置上”。
六、真正的验证顺序：先最小闭环，再主入口，再复杂工作流
这是整篇里我最想强调的顺序。
第一步：先验证最小闭环
什么叫最小闭环？
就是你只验证最基础的一条完整路径：输入进去，系统接住，模型能处理，结果能回来。
比如只测：
• 发一句最简单的话
• 要求它只返回一句固定短句
• 看它能不能稳定来回一轮
因为它最容易帮你判断：
• 服务有没有起来
• provider 通没通
• 基础链路有没有断
• 返回路径是不是完整
第二步：再验证主入口
如果你的主入口是 Telegram、Discord 之类，就在最小闭环通过以后，再去测这些入口。
这一步要确认的，不是它“理论支持”，而是：
• 入口有没有真的接上
• 会不会和旧实例冲突
• 同一 token 是否存在独占问题
• 你发出去的消息到底是谁在处理
第三步：最后再测复杂任务
比如：
• 带工具调用的任务
• 带浏览器的任务
• 带 MCP 的任务
• 长一点的研究整理
• 写作和项目规则读取
• TTS 或额外平台能力
如果你一上来就用复杂任务做第一轮验证，一旦失败，你会根本分不清是哪一层出了问题。
七、共存期最容易翻车的，不是功能，而是入口冲突和知识分裂
如果你不是当天彻底删旧环境，而是准备先共存一段时间，那要优先盯的反而不是“谁更强”，而是两件更现实的事。
坑 1：入口冲突
最常见的问题就是：
• 两边都监听同一入口
• 两边都占同一个 bot token
• 两边都想处理同一类消息
• 你自己都不确定这条消息到底落到哪边了
更稳的做法是，共存阶段先强制划边界：
• 要么分 bot
• 要么分平台
• 要么分 chat / allowlist
• 要么明确一边生产、一边测试
坑 2：知识分裂
真正的问题是：你后续新增的规则、结论、项目进展，到底以哪边为准？
如果这个问题没有唯一答案，系统会越跑越乱。
更稳的做法是，在共存期尽早定三件事：
• 规则文件唯一源头在哪
• 项目状态唯一记录在哪
• 哪边允许继续沉淀长期经验，哪边只负责消费
八、最常见的误判：把“迁移成功”当成“工作流恢复”
你看到屏幕上 success，并不代表你的工作流已经恢复。
真正该确认的是这些问题：
• 默认模型能不能真的响应
• provider 是否真能用
• 关键入口能不能回消息
• skills 有没有真正加载
• MCP / 浏览器 / TTS 是否正常
• 项目规则是否真的被读到
• 长期记忆写入和读取是不是正常
如果这些没逐项确认，那“迁移成功”最多只能说明：文件移动过了。
九、我更建议按这个时间线来做
阶段 A：迁移前准备
1. 判断今天是否适合动手
2. 列出最小迁移清单
3. 先 dry-run
4. 看清会迁移、会跳过、会冲突的内容
5. 备份旧配置与关键工作区
6. 清理当前操作环境里的旧路径依赖
阶段 B：正式迁移
1. 正式执行迁移命令
2. 不要急着删旧环境
3. 先修基础配置差异
4. 先确认 CLI 与 provider 的最小可用性
阶段 C：恢复工作流
1. 先测最小闭环
2. 再测主入口
3. 再测复杂工作流
4. 再补人工复核项
5. 最后再决定是否切主力
阶段 D：观察期
1. 保留旧环境一段时间
2. 只让新环境先吃一部分真实任务
3. 连续观察几天到一两周
4. 确认稳定后，再考虑彻底清理旧环境
十、如果你是第一次折腾，至少记住这 10 条
1. 第一次一定先 dry-run
2. 不要把迁移当成单纯改配置
3. 不要没备份就开跑
4. 不要在任务高峰期开刀
5. 不要把“字段存在”当成“行为恢复”
6. 不要一上来就切主入口
7. 不要第一次就测复杂任务
8. 不要让两个系统同时抢同一个消息入口
9. 不要让两边同时写长期状态却没有唯一源头
10. 不要在当天就把旧环境删干净
十一、最后给一句最实际的建议
如果你已经决定迁，那就别把这件事做成情绪动作。
更好的做法是：把它当成一次小型基础设施切换。
你要关心的不是“我今天有没有成功装上 Hermes”，而是：
• 我的入口有没有平稳切过去
• 我的上下文资产有没有保住
• 我的真实任务能不能继续跑
• 我的回退空间有没有保留
只要这四件事你都盯住了，这次迁移就算中间有坑，整体也仍然是可控的。