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 完整指南
| 联系我们 | |
|---|---|
| 教程看不懂?联系我们为您免费解答!免费助力个人,小企站点! |
客服微信
|
| ① 电话:020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| ③ 邮件:[email protected] | |
| ④ 工作时间:周一至周五,9:30-18:30,节假日休息 | |













3月11日 13:490
现在肯定还是做SEO的,只是玩法变了。 以前靠堆内容、堆关键词就能有流量,现在更看重 内容质量 + 品牌信任 + 用户体验。 另外单靠SEO其实越来越难,很多做得好的基本都是 SEO + 社媒 + 内容营销 + 私域转化 一起做。 SEO本质还是一个长期获客渠道,但不能再当成唯一渠道了。嘻嘻在干活
3月11日 10:540
正常,收录只代表 Google 看到了页面,不代表马上给排名,“已收录但没排名”通常是因为: 关键词竞争大、页面权重低、内容不够强、页面还比较新。 先继续优化长尾关键词、内容质量和内链,通常需要一点时间,排名会慢慢出来Amelia Foster 3月6日 16:200
有截图吗子非鱼也安知鱼之乐 3月6日 09:230
别先堆优化插件,先定位瓶颈: 用 Query Monitor 看慢 SQL、慢 Hook。 暂停全部插件做对比,再逐个开启。 检查 autoload 过大(options 表)。 检查数据库索引与大表查询。 服务器 TTFB 高就先处理主机/数据库性能。嘻嘻在干活
3月3日 16:470
你好风之旅,其实真不用搞复杂的本地环境,普通人按这几步来,更新基本不会崩站👇 先备份全站,文件 + 数据库都备一下,这是底线,出问题能一键回退。 更的时候别一键全更,分批更,先更不重要的插件,再更核心的。 更新完立刻清缓存,去前台检查首页、文章页、按钮、表单这些关键位置。 最好再装个支持版本回滚的插件,万一崩了,一秒切回旧版。 总结来说:先备份、分批更、更完查、留退路,稳得很✅😎希望能帮到你bugbang 3月2日 09:550
通常不是支付没成功,而是回调(webhook)没把订单状态写回来。 排查步骤: WooCommerce → 状态 → 日志:看支付网关是否有 webhook error / signature error / timeout 检查站点是否被 WAF 拦截(Cloudflare、宝塔防火墙、安全插件) 检查是否启用了“缓存结账页/接口路径”(结账页和回调接口不应缓存) 看服务器错误日志是否有 500/致命错误导致回调执行中断 解决方案: 放行 wp-json、wc-api、支付网关回调 URL(按网关文档配置) 关闭结账页的缓存与 JS 合并压缩测试一次 若使用 Cloudflare:为回调 URL 设置 不挑战、不拦截 的规则乌拉那拉甄嬛 1月31日 09:360
1) 先判断这是“正常等待”还是“异常卡住” 可以先看 3 个信号:页面发布时间是否在 7–14 天以内、是否 只有少量页面 出现该状态、页面是否已经出现在 XML Sitemap 中。 如果三个都满足,多半属于正常爬取与评估阶段,不需要立刻动手。 2) 什么情况下“等”是没用的? 以下情况基本不会靠时间自动解决:页面几乎没有内链(孤立页)、内容与站内已有页面高度相似、canonical 指向了别的 URL、同一主题短时间发布太多相似文章。 这种情况下,Google 已经抓取,但判断“当前不值得进入索引”。 3) 最有效的人工干预方式(不折腾) 优先做这 3 件事:加内链、从相关旧文章或栏目页链接到该页面、增强首屏信息密度 前 2–3 段直接回答用户问题,避免铺垫太多,确认 canonical 为自指,避免被判定为重复页,做完再去 GSC 请求重新编入索引即可。 4) 什么“干预动作”反而容易适得其反? 不太推荐:频繁删除重发、连续多次点“请求编入索引”、为了收录强行堆关键词、随意改 URL 或标题 这些操作会让 Google 重新评估页面稳定性,反而拖慢收录。 5) 一个实用判断标准 如果一篇文章:已被抓取、没有 noindex / robots 问题、有至少 1–2 条相关内链、内容明显解决了一个独立问题,那它 是否被收录,只是时间问题,不是插件问题。帖子搬运工 1月30日 10:000
新站前期不做外链完全可以,先把内容和站内结构做好更稳。只靠内容一般能拿到收录和部分长尾词排名,但中高竞争词起量会慢。建议等网站稳定收录、有30–50篇质量内容、关键词开始进前20/30后,再少量做外链,优先品牌词/裸链/引用型,别一上来追数量。👍