Hermes 停更了,你的 AI 助手怎么办?
如果你之前一直用 Hermes 跑自己的 AI 助手——不管是做 Telegram 客服、微信自动回复还是 Discord 社群管理——你可能已经发现一个问题:Hermes 的 GitHub 仓库几个月没更新了。
原因很简单:Hermes 团队把所有精力转到了 OpenClaw。Hermes 的代码、功能、架构全部重构后合并进了 OpenClaw 项目。老项目不再维护,意味着没有新功能、没有 bug 修复、没有安全补丁。
好消息是,OpenClaw 提供了一键迁移工具。你在 Hermes 上的所有东西——对话记录、Agent 配置、Channel Token、定时任务、记忆文件——都能完整搬过来,不丢数据。
我自己上周刚把三个 Hermes 实例迁移到 OpenClaw,整个过程不到 20 分钟。下面把踩过的坑和完整步骤分享出来。

迁移前必须做的三件事
第一件:备份整个 Hermes 目录
不管官方说迁移多安全,动手之前一定要备份。Hermes 的数据默认在 ~/.hermes/ 目录下,里面包括配置文件、数据库、记忆文件、session 历史。整个目录打包一份:
tar -czf hermes-backup-$(date +%Y%m%d).tar.gz ~/.hermes/
这个备份放到别的地方(移动硬盘、云盘、另一台机器),确保万一出问题能恢复。
第二件:记录当前运行状态
迁移后需要对比验证,所以先记录一下现在 Hermes 的状态:
# 记录版本
hermes --version
# 记录 Agent 列表
hermes agents list
# 记录活跃的 Channel
hermes status
# 记录定时任务
hermes cron list
把输出截图或者保存到文件里,迁移后逐项对比。
第三件:停掉 Hermes 进程
Hermes 和 OpenClaw 不能同时跑在同一个 Bot Token 上——两个进程抢同一个 Telegram/Discord/WhatsApp 连接会导致消息丢失或重复。
# 优雅停止
hermes gateway stop
# 确认进程已退出
ps aux | grep hermes

正式迁移:四步搞定
步骤一:安装 OpenClaw CLI
OpenClaw 是独立的 npm 包,安装不会碰你的 Hermes 文件:
npm install -g @openclaw/cli
# 验证
openclaw --version
要求 Node.js 18 以上。如果你的服务器 Node 版本太旧,先升级 Node(推荐用 nvm 管理)。
步骤二:运行迁移命令
OpenClaw 内置了 Hermes 数据导入工具,一行命令完成迁移:
# 从默认路径迁移
openclaw migrate hermes
# 如果 Hermes 数据不在默认位置
openclaw migrate hermes --source /your/custom/path/.hermes
迁移工具会扫描 Hermes 目录,自动识别并导入:
- 所有 Agent 的 SOUL.md 和配置文件
- Channel 配置(Token、webhook URL、群组 ID 等)
- 对话历史和 session 文件
- 记忆文件(memory/ 目录)
- Cron job 定义
- Pairing 状态(已配对的用户不需要重新验证)
迁移过程大约 10-30 秒,取决于你的数据量。完成后会显示一个摘要:导入了多少个 Agent、多少条 session、多少个 cron job。

步骤三:验证数据完整性
这一步最关键。逐项对比迁移前记录的数据:
# Agent 数量和名称应该跟 Hermes 一致
openclaw agents list
# Channel 应该全部显示 configured(还没连接,因为 Gateway 没启动)
openclaw status
# 检查记忆文件
ls ~/.openclaw/memory/
# 检查 Cron job
openclaw cron list
对比清单:
- Agent 数量一致 ✓
- 每个 Agent 的 SOUL.md 内容完整 ✓
- Channel Token 已正确迁移(不需要重新输入)✓
- Cron job 的调度时间、payload、delivery 配置正确 ✓
- 记忆文件完整且内容没乱码 ✓
如果某项不对,别慌。迁移工具的日志在 ~/.openclaw/logs/migrate.log 里,能看到哪一步出了问题。
步骤四:启动 OpenClaw Gateway
# 启动
openclaw gateway
# 看日志确认所有 Channel 连接成功
openclaw logs --follow
你应该看到类似这样的日志:
[info] Telegram: connected (bot: @YourBotName)
[info] Discord: connected (guilds: 3)
[info] WhatsApp: connected
[info] Cron: loaded 5 jobs
[info] Gateway ready
如果某个 Channel 显示 error,通常是 Token 过期或网络问题,不是迁移本身的问题。

迁移后你会发现这些变化
迁移完用了几天之后,我注意到几个明显的改进:
启动速度快了很多。Hermes 启动要 4-5 秒,OpenClaw 1 秒不到就 ready。这在服务器重启或者部署更新时区别很大。
内存占用降了。同样的 3 个 Agent + 5 个 Channel,Hermes 吃 180MB 左右,OpenClaw 只要 100MB 出头。小 VPS 上这个差距很明显。
多 Agent 不再需要多进程。Hermes 时代我跑 3 个 Agent 要启动 3 个 Gateway 进程,各占一个端口。OpenClaw 一个进程全搞定,通过 binding 规则把不同 Channel 路由到不同 Agent。
定时任务好用太多。Hermes 的 cron 只能在主 session 里跑,结果会打断你的正常对话。OpenClaw 支持 isolated session 执行,cron 跑完把结果推到群里,完全不干扰你的日常使用。

我踩过的坑
坑一:Node.js 版本太旧
我一台服务器还在跑 Node 16,OpenClaw 直接报错装不上。解决办法是用 nvm 升级到 Node 20:
nvm install 20
nvm use 20
nvm alias default 20
坑二:忘了停 Hermes 就启动 OpenClaw
两个进程抢同一个 Telegram Bot Token,结果消息随机分配到两边,用户收到重复回复。发现后马上 hermes gateway stop 就好了。
坑三:自定义 Hermes 插件没有 OpenClaw 对应版本
我之前写了一个 Hermes 插件用来查天气。迁移后这个插件不能直接用。解决办法是把它改写成 MCP Server,OpenClaw 原生支持 MCP 协议。改写大约花了一个小时。
一般的な問題
迁移后 Telegram Bot 需要重新跟用户配对吗?
不需要。Pairing 状态是迁移的一部分,已经配对过的用户可以继续正常对话,无感切换。
迁移过程中会中断服务吗?
会有短暂中断。从停掉 Hermes 到 OpenClaw Gateway 启动成功,大约 1-2 分钟。这段时间收到的消息不会丢失(Telegram/Discord 会缓存),Gateway 启动后会补处理。
能不能先测试再正式切换?
可以。用 openclaw migrate hermes --dry-run 只做检查不实际写入。确认没问题后去掉 –dry-run 正式执行。
迁移后原来的 Hermes 数据还在吗?
在。迁移是复制操作,~/.hermes/ 目录不会被修改或删除。如果 OpenClaw 有问题,你随时可以停掉 OpenClaw、重新启动 Hermes 恢复服务。
OpenClaw 收费吗?
核心开源免费。跟 Hermes 一样,你只需要付模型调用的费用(OpenAI/Anthropic 的 API 费用)。OpenClaw 本身不收钱。
相关教程推荐
- OpenClaw 怎么做 SEO 关键词研究?从找词、分类到内容规划的实操教程
- OpenClaw 怎么做 WhatsApp 客服自动回复?从安装到上线的完整教程
- OpenClaw 怎么做内容排期?把关键词研究变成可执行的发布计划
概要
从 Hermes 迁移到 OpenClaw 就是:备份 → 停进程 → 装 CLI → 跑迁移命令 → 验证 → 启动。整个过程 15 分钟,数据完整搬过来,已配对的用户无感切换。
我的建议是尽快迁移。Hermes 不再更新意味着安全漏洞不会被修复,拖得越久风险越大。而且 OpenClaw 的新功能(isolated cron、multi-agent、background tasks)用过就回不去了。
官方迁移文档:从 Hermes 迁移到 OpenClaw 完整指南
| お問い合わせ | |
|---|---|
| チュートリアルが読めない?無料でお答えします!個人サイト、中小企業サイトのための無料ヘルプ! |
カスタマーサービス WeChat
|
| ① 電話:020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| 三 Eメール:[email protected] | |
| ④ 勤務時間: 月~金、9:30~18:30、祝日休み | |
この記事へのリンクhttps://www.361sale.com/ja/87569/この記事は著作権で保護されており、必ず帰属表示を付けて複製してください。













3月11日 13:490
今はまだ間違いなくSEOを行っているが、ただ遊び方が変わっただけだ。 以前はコンテンツの山に依存し、キーワードの山は、トラフィックを持つことができ、今ではコンテンツの質+ブランドの信頼+ユーザーエクスペリエンスにもっと注意を払う。 SEOだけに頼ることに加えて、実際にはますます困難であり、多くの良い基本的にSEO +ソーシャルメディア+コンテンツマーケティング+一緒に行うには、プライベートドメインの変換。 SEOは依然として長期的な顧客獲得チャネルであるが、もはや唯一のチャネルとして捉えることはできない。ヒヒは仕事中
3月11日 10:540
ノーマルは、Googleに代わってページを参照してくださいにのみ含まれ、すぐにランキングにそのことを意味するものではありませんが、"含まれているが、ランク付けされていない "通常のため: キーワードの競争は、ページの重量が低い、コンテンツが十分に強力ではない、ページが比較的新しいです。 ロングテールキーワード、コンテンツの品質と内部チェーンを最適化し続け、通常は少し時間がかかり、ランキングは徐々に出てくるだろう!アメリア・フォスター 3月6日 16:200
スクリーンショットはありますか?魚でない息子も魚の喜びを知っている。 3月6日 09:230
最初に最適化プラグインを積み上げるのではなく、最初にボトルネックを特定する: クエリモニタを使って、遅いSQL、遅いフックを確認する。 すべてのプラグインを一時停止して比較し、それから1つずつオンにする。 オートロードが大きすぎないかチェックする(オプションテーブル)。 大きなテーブルクエリでデータベースのインデックスをチェックする。 サーバーのTTFBが高い場合は、まずホスト/データベースのパフォーマンスに取り組んでください。ヒヒは仕事中
3月3日 16:470
ウィンドジャマーさん、複雑なローカル環境をいじくる必要はありません。普通の人はこの手順に従って更新すれば、基本的にサイトがクラッシュすることはありません👇。 まず、サイト全体のバックアップ、ファイル+データベースの準備、これが肝心です。 サイトのアップデートをする場合、ワンクリックで全部行わず、一括で行い、まず重要でないプラグインを変更し、次にコアなプラグインを変更する。 更新後すぐにキャッシュをクリアし、フォアグラウンドに移動してトップページ、記事ページ、ボタン、フォーム、これらの重要な位置をチェックする。 バージョンのロールバックをサポートするプラグインをインストールしておくと、クラッシュした場合、一瞬で古いバージョンに戻すことができる。 まとめると:まずバックアップ、一括変更、変更後チェック、戻る方法を残す、非常に安定している ✅😎 これが役立つことを願っています!バグバング 3月2日 09:550
通常、決済がうまくいかなかったのではなく、コールバック(ウェブフック)が注文状況を書き戻さなかったのです。 トラブルシューティングの手順 WooCommerce → Status → Logs: ペイメントゲートウェイにウェブフックエラー/シグネチャーエラー/タイムアウトがあるか確認してください。 サイトがWAF(Cloudflare、Pagoda Firewall、セキュリティプラグイン)によってブロックされていないか確認する。 Cache checkout pages/interface paths "が有効になっているか確認する(チェックアウトページとコールバックインターフェースはキャッシュされるべきではない) サーバーのエラーログを見て、コールバックの実行を中断させるような500/致命的なエラーがないか確認する。 解決方法 wp-json、wc-api、ペイメントゲートウェイのコールバックURLを解放する。 チェックアウトページのキャッシュとJSマージ圧縮テストを一度無効にする。 Cloudflareを使用している場合: コールバックURLのno-challenge、no-blockルールを設定する。ウラ・ナラ・ジェンファン(18嬛嬛) 1月31日 09:360
1) 「正常な待機」なのか「異常な停滞」なのかを判断する。 まず3つのシグナルを見ることができる:ページ公開時間が7-14日以内か、このステータスのページは少数か、XMLサイトマップにページが登場しているか。 この3つが満たされていれば、通常のクロールと評価の段階である可能性が高く、すぐに行う必要はない。 2)どのような場合に「待つ」ことが無駄になるのか? 内部リンクがほとんどないページ(孤立したページ)、サイト内の既存ページと内容が酷似している、カノニカルポイントが他のURLになっている、同じトピックで似たような記事が短期間に公開されすぎている、などの場合は、時間が経過しても自動的には解決されません。 この場合、Googleはクロールはしているが「インデックスに登録する価値はない」と判断している。 3)手動で介入する最も効果的な方法(手間をかけない) 内部リンクの追加、関連する古い記事やコラムからページへのリンク、最初の画面の情報密度を高める。 最初の2-3段落はユーザーの質問に直接答える、詰め込みすぎを避ける、重複ページと判定されないようにcanonicalを自己参照として確認する、そしてGSCに再インデックスを依頼しに行く。 4) 逆効果になる「介入行動」とは? 頻繁に削除や再投稿を繰り返す、「インデックスリクエスト」を何度も連続でクリックする、インデックスされるためにキーワードを無理やり重ねる、URLやタイトルを恣意的に変更する、など。 これらの操作は、Googleにページの安定性を再評価させるが、インクルードが遅くなる。 5) 現実的な判断基準 記事:クロールされている、noindex/robotsの問題がない、少なくとも1-2個の関連する内部リンクがある、コンテンツが明らかに独立した問題を解決している、プラグインの問題ではなく時間の問題である。ポスト・ポーター 1月30日 10:000
新しい駅は完全に外部リンクを行うことはできませんが、最初のコンテンツと駅の構造は、より安定した良い仕事をする。コンテンツにのみ依存して、一般的にロングテールの単語のランキングの一部が含まれて得ることができますが、高い競争の量が遅くなります。それは、サイトが安定してインクルード、30〜50品質のコンテンツを待つことをお勧めします、キーワードはトップ20/30を入力するようになったし、外部リンクの少量は、優先順位のブランド語/裸チェーン/引用型は、番号を追いかけて出てこない。👍