从OpenClaw到Hermes：一个非程序员的24小时迁移实录

袁锐钦 · AI编程实践者

凌晨一点的崩溃

凌晨一点，我刚用AI写完一篇公众号文章，看着它把文章推到草稿箱，长出一口气。

然后问了一句："总结一下今天犯的错。"

它给了我一段漂亮的总结。我接着问："你明天还记得吗？"

它说："不会。"

这是用OpenClaw的第三周。30多篇公众号，一个出海项目，整套知识库——全是它帮我干的。它很稳，像个你培训好的助理，你说什么它做什么。

但有一个事它做不到：变强。

今天踩的坑，明天还得重新教一遍。昨天犯的错，后天它再犯一次。我得一遍一遍手写配置、手动调教，像个老师傅带新徒弟。

然后我看到了Hermes。

它有一个东西叫"自改进循环"：做完一件事，自动总结经验，写成可复用的技能，下次遇到类似的事直接用上。

我不确定这玩意儿靠不靠谱。但"AI自己学着变强"这件事——我想试试。

OpenClaw和Hermes到底有什么区别

聊迁移之前，先说清楚这两个东西到底是什么关系。

很多人以为它们是竞品——其实不算。更像是同一件事的两种思路。

OpenClaw的核心是Gateway。 一个大管家，所有消息都经过它调度。你在飞书说一句话，Gateway收到后分配给对应的Agent去处理，处理完了再回复给你。整个系统围绕"你怎么控制这个AI"来设计。

它的好处是稳定、开箱即用、社区生态成熟。你装好之后，按照模板写几个配置文件，就能跑起来。写作、发布、配图，都有现成的技能包可以装。对新手来说，这个体验很友好。

但有一个问题：它是被动的。 你说什么它做什么，不说它就不动。今天踩了一个坑，你手把手教它改了。明天换个场景，它还是不会。

Hermes的思路完全不同。 它的核心是一个自改进循环：

做完一件事 → 自动总结哪里做得好哪里做得烂 → 把经验写成可复用的技能 → 下次遇到类似的事直接调用。

翻译成人话：OpenClaw是你教AI干活，Hermes是AI自己学着干活。

举个例子。我用OpenClaw发布公众号文章，每次都得手动选主题、手动检查格式、手动上传封面图。用了三十多次，流程完全一样，但它从来不记住。

换到Hermes之后，第一次发布完，它自动把这个流程总结成一个技能。第二次我说"发布"，它直接按上次的参数走，只问我要不要改。

这就叫"越用越懂你"。

搬家不是打包行李

决定迁移之后，我做的第一件事是列清单。

发现要搬的不只是聊天记录。是三样东西：

知识库 — 36篇公众号文章、个人档案、选题库、读书笔记，全存在OpenClaw的文件系统里。

技能包 — 公众号发布、写作系统、配图设计，5个定制好的工作流技能。

平台接入 — 飞书机器人、微信网关、公众号API凭证。

三件事串在一起。少搬一样，整个系统就跑不起来。

我先给自己画了一张路线图：

1. 1. 先搬知识库（最重但最简单）
2. 2. 再改技能包（最折腾，要逐个适配）
3. 3. 最后接平台（收尾验证）

就这么三步。但每一步都踩了坑。

先搬最重的家具：知识库

OpenClaw和Hermes的文件结构完全不同。不是换个文件夹名字那么简单，是整个组织逻辑变了。

OpenClaw的结构是围绕"一个workspace"设计的——所有东西都放在 /root/.openclaw/workspace/ 下面，平铺展开：

workspace/
├── memory/          → 个人档案、日记、选题库
├── shared/          → 跨Agent共享内容
├── articles/公众号/  → 36篇已发布文章，全平铺在一个目录
└── tools/           → HTML排版器等工具

Hermes的思路是wiki式的，按功能分目录：

~/wiki/
├── 1-我/            → 个人档案
├── 2-创作/公众号/    → 文章、草稿、选题库
├── 3-学习/          → 深度学习、读书笔记
├── 4-项目/          → 出海、KB_pngtrid
├── 5-人脉/          → 联系人
└── 6-原始资料/      → 源文件备份

我得先做一张映射表：

• • workspace/ → ~/wiki/
• • workspace/memory/ → ~/wiki/ 下按功能分的子目录
• • workspace/articles/公众号/ → ~/wiki/2-创作/公众号/已发布/
• • /root/.openclaw/.env → ~/.hermes/.env

看着不复杂对吧？搬文件嘛，cp过去就行了。

然后我踩了第一个坑。

行号污染。

OpenClaw的 read_file 返回的内容带行号——每行前面有个 5|xxx 这样的标记。看起来挺贴心的，方便你看行数。

但问题是：我在Hermes里直接用 write_file 把这些内容写回去，结果所有文件都被行号污染了。每行前面多了一堆数字和竖线，文章根本没法看。

"心想这也行？"

36篇文章，每篇都被污染了。如果我没发现就继续往下走——后面所有基于这些文件的操作全都会出错。

解决方案：用 cat 命令读原始内容，不带行号，再写过去。就这么简单的一个操作。但如果你不知道这两个工具的返回格式不一样，你会在这一步浪费两个小时。

搬完之后，Hermes顺手做了一件事：把36篇文章按系列整理了一下。

原来在OpenClaw里，36篇文章全平铺在一个目录下。没有分类，没有结构。找一篇BRD系列的文章，你得在36个文件里一个个翻。

搬到Hermes之后，我建了子目录：

• • BRD系列 5篇
• • 出海系列 9篇
• • AI工具教程 7篇
• • 复盘 6篇
• • 散文 9篇

从一团平铺变成有结构的创作库。以后找文章，直接按系列进目录就行。

这步不是必须的。但做了之后，后面用Hermes管理内容会顺手很多。

经验：搬家不是把东西从旧箱子倒进新箱子。是趁搬家的机会，把原来懒得整理的东西理一遍。

最折腾的零件：技能包

这是整个迁移里花时间最多的部分。

先说说我有哪些技能包。我的公众号工作流有5个技能，是从OpenClaw社区里找来定制的：

搬之前先做了一件事：砍掉没用的。

wechat-mp-publish 功能完全被 baoyu-post-to-wechat 覆盖——两个都能发布文章，但baoyu支持更多主题、更完善的排版。留着只会混淆。

wechat-mp-cn 更离谱，打开一看只有功能列表和几个API链接，没有任何可执行的脚本。装了等于没装。

砍完剩下3个核心技能，才是真正要搬的。

然后坑来了，一个接一个。

坑一：bun install 莫名其妙报 SSL 错误

公众号发布技能 baoyu-post-to-wechat 用 TypeScript 写的，依赖 bun 运行。先装依赖：

cd skills/baoyu-post-to-wechat/scripts/
bun install

直接报错：

UNKNOWN_CERTIFICATE_VERIFICATION_ERROR

我第一反应是网络问题。换网络、挂梯子、清缓存——全没用。

然后去查了才知道：这不是代码的问题，是 macOS 的证书链和 bun 的兼容性有冲突。bun 自己有一套证书验证逻辑，跟 macOS 系统证书对不上就会报这个错。

"算了不想了。"直接换成 npm install，一次通过。

功能完全一样，只是包管理器换了一个。后续运行也没任何问题。

经验：遇到工具链报 SSL 错误，先换个工具试，别死磕。

坑二：截图工具找不到浏览器在哪

配图技能 infographic-design 的原理是：先用 Python 生成 HTML，再用 Playwright 打开 HTML 截图，输出 PNG。

听起来很顺滑。跑起来直接报错：找不到 Chromium。

打开 screenshot.py 一看，路径写死了：

/root/.cache/ms-playwright/chromium-1208/chrome-linux64/chrome

这是 Linux 的路径。我的机器是 macOS。Playwright 在 macOS 上的安装路径完全不同：

~/Library/Caches/ms-playwright/chromium-*/chrome-mac/Chromium.app/Contents/MacOS/Chromium

不光路径不同，连目录结构都不一样。Linux 是直接一个 chrome 二进制文件，macOS 是藏在 .app 包里的。

修复方案：改成自动检测系统类型。先判断是 Linux 还是 macOS，然后动态查找 Playwright 的安装路径。这样不管在什么系统上都能跑。

经验：涉及系统路径的代码，永远不要硬编码。用动态检测。

坑三：技能文件里写死了我的个人信息

这个坑最隐蔽。

OpenClaw 的技能包里有不少地方直接写了用户名、AppID、文件路径。比如公众号发布的技能里，直接写死了我的公众号 AppID 和 AppSecret。写作系统的技能里，写死了选题库的绝对路径。

Hermes 的设计原则是：技能文件本身不能包含任何个人信息。 需要个性化的内容，运行时动态读取。

为什么？因为技能是可能被分享的。你把技能发给别人，里面还夹着你的 AppID——这不合适。

所以我要做三件事：

1. 1. 所有硬编码路径改成相对路径或环境变量
2. 2. 所有凭证（AppID、AppSecret）移到 .env 文件，技能运行时读取
3. 3. 所有"袁锐钦""Ruiqin"这类个人信息改成占位符，运行时从个人档案读取

这步改完，技能包从"只能在一个人机器上跑"变成了"任何人拿到都能用"。

经验：迁移不只是让东西能跑起来。是让它们变得可以复用、可以分享。

最后的收尾：接平台

知识库和技能都搬完了，最后是接平台。这一步涉及两个东西：飞书机器人和公众号API。

飞书机器人：看起来简单，坑最阴

OpenClaw 的飞书接入是通过 Gateway 配置文件管理的。你在配置文件里填好 App ID、App Secret，启动 Gateway，就通了。

Hermes 用的是 WebSocket 模式。配置写在 config.yaml 里，逻辑差不多——填凭证、选模式、启动。

看起来就是换个地方写配置的事。我十分钟就搞定了。

然后发现了一个问题：WebSocket 断线重连。

Hermes 的飞书 Gateway 在网络波动的时候，ping 会超时。超时之后它尝试重连——但只重连1次。如果碰到 SSL 错误（比如网络刚好抖了一下），它就卡住了，不再重试。

你不会收到任何通知。等你发现的时候，机器人已经"失联"好几个小时了。有人给你发消息，你没回——你根本不知道。

解决方案很暴力但有效：用系统 crontab 每10分钟跑一个 healthcheck 脚本。

*/10 * * * * /path/to/feishu-healthcheck.sh

脚本做的事情很简单：检查 Gateway 进程是否活着、WebSocket 连接是否正常。不正常就自动重启。

不需要调 LLM，零成本运行。稳了。

公众号API：最顺利的一步

公众号 API 的迁移就三步：

1. 1. 把 AppID 和 AppSecret 从旧的 .env 搬到新的位置
2. 2. 确认服务器 IP 仍在公众号白名单内
3. 3. 跑一次发布测试，验证 token 能正常获取

从操作到验证通过，15分钟。

经验：平台接入看起来是小事，但它决定了你整个系统"通不通"。放到最后做，因为前面两步都正常了，这一步出问题才好定位。

24小时后的样子

全部搞定。我检查了一遍所有功能：

然后我让Hermes帮我做了一件事——总结今天迁移过程中踩的坑。

它不光给了总结。它把这些坑写成了一个可复用的技能文件，存到了技能库里。

下次有人问我"怎么从OpenClaw迁到Hermes"，它不需要我重新教一遍。

它自己会了。

就这一刻，我觉得这24小时值了。

然后它还做了一件事让我更意外——它不仅总结了坑，还把36篇文章按系列整理好了。我没让它这么做。但它看到文件平铺在一个目录里，觉得"这样不好用"，就自己建了子目录、按内容分类、把文件搬进去了。

这不就是我一直在找的"AI自己学着干活"吗？

但我不是劝你换

说句实话：如果你刚接触 AI Agent，OpenClaw 是更好的选择。

开箱即用，社区成熟，踩坑成本低。你遇到任何问题，群里问一句就有人答。技能包也多，直接装就能用。

Hermes 适合另一类人——已经用过一段时间，开始觉得"我每次都在重复教AI"的人。

你想让AI记住你上次犯的错。你想让它下次自动避开。你想让它越用越懂你。

到了这个阶段，你需要的不是一个听话的助理，而是一个会自己成长的搭档。

选工具不是选最好的。是选你到了哪个阶段。

功能机稳定好用。但到了你想让手机自己装App的那一天——路已经有人替你踩过了。

迁移清单：

1. 1. 搬知识库：注意 read_file 的行号格式差异，用 cat 读原始内容
2. 2. 改技能包：砍掉重复的、补全缺失的、脱敏个人信息
3. 3. 接平台：飞书加 crontab 自动重连、公众号迁移 .env 验证白名单

就这三步。每一步的具体操作和踩坑记录，我都写在这篇文章里了。

如果你也在考虑迁移，希望这篇能帮你省掉我踩过的那些坑。