一个命令，能把 OpenClaw 里攒下来的 Persona、记忆、技能、模型供应商、MCP、TTS，以及 Telegram、Discord、Slack 配置，搬进 Hermes。
这个命令叫 hermes claw migrate。它看起来是导入工具，但对本地 Agent 用户来说，更像一次换轨：旧系统里的配置、习惯、自动化入口和长期记忆，会进入 Hermes 的目录和配置体系。
我更在意的不是它能迁多少字段，而是它把哪些东西定义成“可迁移资产”。这会影响 OpenClaw、Clawdbot、Moltbot 老用户怎么换工具，也会影响 Agent 工具之间真正争的是什么。
迁得很广，但边界写得很清楚
这份迁移指南最有用的地方，是没有把事情包装成“无缝”。它给了预览、备份、dry-run，也明确说有些能力只能归档。
| 项目 | Hermes 迁移处理 | 对用户的影响 |
|---|---|---|
| Persona / 记忆 / 用户档案 | 可迁入 ~/.hermes/，记忆会合并、去重 | 长期上下文能延续，但仍要检查合并结果 |
| 技能 | 从 workspace、~/.openclaw/skills/、~/.agents/skills/ 等来源汇入 | 旧工作流可部分保留 |
| 模型与供应商 | 默认模型、自定义 provider、baseUrl、API 类型可映射 | 多模型配置不用完全重配 |
| MCP / TTS | MCP server、语音相关配置可迁 | 工具调用和语音入口可继续接入 Hermes |
| 消息平台 | Telegram / Discord / Slack 等配置可迁 | 外部消息入口会进入 Hermes 管理 |
| 无直接等价能力 | cron、plugins、hooks/webhooks、复杂 channel、多 Agent 列表等归档 | 不能当成无损迁移，后续要人工重建 |
迁移默认会先展示完整预览，再让用户确认。也支持 --dry-run，只看结果，不改文件。
真正执行迁移前，Hermes 默认会备份 ~/.hermes/，生成 zip。除非用户显式加 --no-backup。
密钥处理更关键。即使用 --preset full，API keys 也不会静默迁移。用户必须显式加 --migrate-secrets。
而且它只复制 allowlist 内的 key，比如 OpenAI、Anthropic、OpenRouter、Gemini、Telegram Bot Token 等。这个限制很必要。Agent 一旦拿到密钥，就不只是“调用模型”，而是拿到了替用户执行任务的凭证。
OpenClaw 里没有 Hermes 等价物的内容，会进入 ~/.hermes/migration/openclaw/.../archive/。比如 IDENTITY.md、TOOLS.md、cron、plugins、hooks/webhooks、复杂 channel 配置、多 Agent 列表。
这不是迁移失败，但也不是一键搬家。老用户最该做的动作很具体：先跑 --dry-run，再看 archive 目录，最后单独复核 token、hooks、cron 和消息平台入口。
受影响最大的是老用户和工具链维护者
OpenClaw、Clawdbot、Moltbot 的现有用户，短期会得到一个省事选项。已有记忆、技能、模型配置和 MCP server 不用从零搭。
但省事有代价。迁移后，日常 Agent 配置会更多进入 Hermes 的结构里。以后再换走，难点可能不在模型，而在这些长期积累的上下文和执行环境。
对个人开发者，建议别急着把 full preset 当默认方案。更稳的做法是分三步：
| 动作 | 为什么要做 |
|---|---|
先用 --dry-run | 确认哪些配置会被迁，哪些会被归档 |
暂缓 --migrate-secrets | 先看清密钥范围，尤其是平台 token 和模型 API key |
| 迁完后检查 archive | cron、hooks、复杂 channel 可能要手工恢复 |
对维护 Agent 工作流的小团队，影响更直接。迁移前最好延后一次工具链切换，先盘点自动化入口：哪些任务靠 cron，哪些靠 webhook，哪些靠 Discord 或 Slack 触发。
这些入口一旦漏迁，表面上 Agent 能启动，实际工作流会断。最麻烦的不是报错，而是静默失效。
这里有一个现实约束：材料只证明 Hermes 提供了迁移工具和指南。它不能说明 Hermes 收购、关闭或接管 OpenClaw，也不能推出用户规模和商业动机。判断只能落在迁移设计本身。
这个设计已经足够说明问题。Hermes 在争取的不只是配置文件，而是用户已经训练出来的 Agent 使用习惯。
Agent 的护城河，正在从模型转向记忆和执行环境
模型供应商列表越来越不像护城河。今天接 OpenAI，明天接 Anthropic，后天再接 OpenRouter 或 Gemini，用户虽然嫌麻烦，但不是搬不动。
Hermes 文档里还提到，hermes setup --portal 可以通过 Nous Portal，把多供应商配置折叠成一次 OAuth，并宣称接入 300+ 模型和 Tool Gateway。
这很方便，也很有方向感。模型入口被折叠后，用户面对的不是一堆 provider，而是一个统一控制台。
真正难搬的是另一层：记忆、Persona、技能、MCP server、命令白名单、消息平台 token、自动化入口。它们不像模型名称那么好替换。它们更接近一个 Agent 的“日常生活”。
历史上平台竞争经常这样。浏览器最开始只是访问网页，后来变成账号、插件、支付、同步和工作流入口。云服务也一样，早期卖算力，后来沉淀权限、日志、密钥、流水线和组织流程。
不完全一样，但结构相似。入口一旦接住长期数据和执行权限，就会从工具变成平台。
“天下熙熙，皆为利来。”放到这件事上也直白：用户要少折腾，平台要沉淀资产。两边都合理，关键是账要摊开算。
Hermes 这次做得体面的地方，是没有默认偷搬密钥，有预览，有 dry-run，有备份，也承认部分 OpenClaw 能力只能归档。
它强势的地方也在这里：迁移范围覆盖了记忆、技能、模型供应商、MCP、TTS 和消息平台。Agent 的上下文、工具调用和外部入口，都被纳入 Hermes 的迁移路径。
接下来最该观察的不是“又支持了多少模型”。那个数字会继续膨胀，区分度有限。
更该看三件事：Hermes 如何处理归档能力的重建；Nous Portal 的 OAuth 和 Tool Gateway 会不会成为默认路径；迁移后的配置能不能足够清楚地导出、审计和撤回。
如果这些都做得好，Hermes 会成为更稳的 Agent 工作台。如果做得含糊，用户会在省事之后发现，真正难走的是回头路。