核验指南 2026年4月17日核验 · 8 分钟
OpenClaw 迁移：Hermes 官方会迁入哪些内容
来源 站内指南 + 官方文档
迁移是桥，不是魔法
官方文档确认，hermes claw migrate 默认从 ~/.openclaw/ 读取配置，也会自动识别旧版 Clawdbot / Moldbot 目录。真正重要的解释是：Hermes 给了 OpenClaw 用户一条严肃的迁移路径，但它仍然期待操作者在迁移后做验证。
会迁移哪些内容
- SOUL.md 到
~/.hermes/SOUL.md - MEMORY.md 与 USER.md 到
~/.hermes/memories/ - Skills 到
~/.hermes/skills/openclaw-imports/ - Provider 与 MCP 配置，以及部分 messaging 配置
- API Keys，在启用 secrets 迁移时一并导入
你现在该不该迁
- 该迁：如果你的 OpenClaw 环境仍然活跃，而且里面确实有值得保留的身份、记忆和技能
- 该迁：如果你不想再把同一套人格与知识体系手工重建一遍
- 先别迁：如果旧环境本身已经混乱，导过来也只会把问题一起带过来
- 先别迁：如果你还没有判断 Hermes 是否真是这条工作流的长期落点
哪些地方要格外留意
- 执行前可以先预览变更
- 若要把
AGENTS.md写到工作区，需要使用--workspace-target - 部分 OpenClaw 概念不会直接映射，而会被归档供人工检查
- WhatsApp 迁移后仍需重新配对
推荐迁移流程
- 先预览，先看 Hermes 认为哪些内容可以映射
- 决定 secrets 是一起导，还是分阶段导
- 只有在明确 workspace 规则落点时，才设置
--workspace-target - 导入完成后，先验证一个 provider 和一个 messaging surface，不要一下子全开
操作者视角的结论
迁移路径之所以好，恰恰是因为它没有假装自己完全无摩擦。更稳妥的理解方式是：让 Hermes 先导入可映射的数据和配置，然后再明确验证 providers、workspace 规则和 messaging。迁移是加速 onboarding，不是替代 review。
更稳妥的迁移顺序
- 先预览迁移结果
- 确认映射合理后再真正导入
- 用
hermes status检查 provider 认证 - 一次只测试一个 messaging 入口
- 等基础环境稳定后，再处理 workspace 级指令整理
迁移后立刻要验证什么
- 导入后的
SOUL.md是否仍然表达的是你想要的实例身份 - workspace 规则是否应该从导入内容里拆出去，放进
AGENTS.md - provider 凭据是否导入完整，而且真的能用
- 导入的 skills 是有价值的能力，还是只是历史包袱
迁移最容易出错的地方
最常见的错误不是命令本身，而是心理预期：看到文件都导过来了，就误以为环境已经 production-ready。更稳妥的态度是把迁移结果当成 可复核的起点，而不是“旧环境已经被完美翻译”的证明。