Hermes 迁移到 OpenClaw：定时任务、频道配置与回滚清单一次讲清

Hermes 迁移到 OpenClaw，不建议把它理解成“换一个聊天入口”。真正需要迁移的是任务触发方式、频道身份、文件权限、定时策略、失败告警和人工接管路径。很多团队只复制配置文件，结果上线第一天就遇到消息发不出去、后台任务重复跑、图片路径失效、Cron 漏触发、旧机器人还在回复等问题。本文按运营上线的视角，把 Hermes 迁移拆成可执行清单，适合已经有自动化脚本、内容排期、客服通知或站点监控任务的团队使用。

如果你第一次接触 OpenClaw，建议先看官方文档入口：OpenClaw Docs。迁移前不要急着停旧系统，先做一轮并行验证，确保新通道能收到消息、能调用工具、能记录日志、能在失败时回滚。

一、迁移前先盘点：别让旧任务变成隐形风险

迁移第一步不是安装 OpenClaw，而是列出 Hermes 当前承担的所有工作。至少要盘点四类资产：第一类是入口资产，例如 Telegram、Discord、Slack、Webhook、站内表单、邮件转发；第二类是任务资产，例如每日发布、异常监控、数据抓取、媒体上传、报错通知；第三类是权限资产，例如 WordPress 应用密码、服务器 SSH、Cloudflare Token、数据库只读账号；第四类是运营资产，例如谁能触发任务、谁能批准发布、失败后通知谁。

这一步常见错误是只迁移“能看见的聊天频道”，忽略后台定时任务。Hermes 里如果有 crontab、systemd timer、队列消费者或自定义脚本，迁移后仍可能继续运行。新旧系统同时写 WordPress，最容易造成重复草稿、重复特色图、错过排期或 slug 冲突。因此迁移清单要包含任务名称、触发时间、输入来源、输出目标、失败处理、是否允许并行、是否需要人工审批。

建议保留一张迁移矩阵

迁移矩阵不需要复杂，字段保持清楚即可：旧任务 ID、业务用途、旧触发器、新触发器、依赖密钥、频道、负责人、验证结果、回滚方式。对于 WordPress 站点，还要记录分类 ID、媒体库范围、默认发布时间、是否需要 Elementor 结构、是否需要内链检查。这样做的好处是上线时可以逐项勾选，而不是靠记忆判断。

二、OpenClaw 侧配置：先通道，后任务，再权限

OpenClaw 的迁移顺序建议采用“通道优先”。先确认消息通道能收发，再确认 Agent 能理解指令，最后开放写入型工具。不要一开始就把 WordPress 发布、文件写入、远程命令全部打开。迁移期最安全的做法是先用只读检查，例如读取媒体库、读取当天文章、读取日志；确认稳定后，再允许创建草稿；最后才允许未来发布或修改已发布内容。

频道配置完成后，要测试三件事：第一，普通消息是否能到达正确会话；第二，长任务是否能在后台运行并返回结果；第三，失败是否有清晰提示。如果你的团队依赖每日内容排期，建议把“检查今日 publish/future 数量”做成固定任务，而不是等运营人员发现漏发才补救。

权限迁移要最小化

WordPress 应用密码、Cloudflare API Token、服务器私钥都不应该一次性塞进同一个环境。能只读就不要写入，能限定站点就不要全账号，能限定目录就不要给根目录。对于自动发布任务，权限通常只需要读取文章、读取媒体、创建文章、上传媒体；如果不负责主题和插件维护，就不应具备更新插件或修改主题文件的权限。

三、定时任务迁移：重点检查时区和漏发

Hermes 迁移到 OpenClaw 后，最容易出错的是时区。内容团队说的 09:00 往往是本地运营时间，服务器可能是 UTC，WordPress 站点可能是欧洲柏林时间，Cron 调度器又可能使用宿主机时区。发布任务必须明确写入时区，不要靠默认值猜测。对于 361sale 这种一天多篇的节奏，建议每天固定检查一次当天 publish/future 数量，发现缺口立即补排。

还要确认 WP-Cron 是否可靠。低流量站点的 WP-Cron 可能因为没有访问而延迟触发，高缓存站点也可能因为页面缓存导致前台看不到新内容。稳妥做法是创建文章后再用 REST API 读取一次，确认 status、date、categories、featured_media、content 中的图片和链接都存在。必要时，再访问前台链接检查是否返回 200。

避免重复触发

迁移期间旧 Hermes 任务可能还在跑，新 OpenClaw 任务也开始跑。为了避免重复发布，可以给每个任务设置唯一名称，并在执行前先查询当天同主题标题。如果发现同一发布时间已经有文章，就不要强行覆盖，而是补到后续空档。内容排期系统的目标不是“跑完脚本”，而是保证前台节奏稳定。

四、回滚策略：不要等事故后再想办法

回滚不是简单地“关掉 OpenClaw”。如果新系统已经创建了未来文章，回滚时要决定这些 future 文章是否保留；如果新系统已经把频道切到新机器人，回滚时要恢复旧机器人权限；如果新系统已经更新了环境变量，回滚时要恢复旧密钥。建议在正式切换前准备三条命令或三个操作步骤：暂停新任务、恢复旧入口、冻结写入权限。

对 WordPress 发布任务而言，回滚检查包括：当天文章数量是否仍满足计划、未来文章是否有重复特色图、媒体库是否出现孤立图片、分类是否正确、内链是否缺失。相关的 WordPress 上线检查也可以参考这些站内文章：

• Elementor 页面上线前别急发布：5 个检查点
• Cloudflare 报错修复顺序
• WordPress 性能优化插件选择
• 内链工具实战对比

五、上线验收：用运营指标判断迁移是否成功

技术迁移成功不等于运营迁移成功。真正的验收指标应该包括：当天排期完整、发布间隔正常、失败能自动通知、日志能追溯、人工能接管、密钥没有扩大暴露、频道没有重复回复、文章结构符合要求。迁移后的前三天建议保留人工复核，尤其检查截图、内链、外链、分类和特色图。

最终建议是：Hermes 不要“一刀切”下线，先保持只读或备用状态；OpenClaw 先承担检查和草稿生成，再承担正式排期；当连续几天没有漏发、重复、权限报错和缓存异常后，再关闭旧任务。这样迁移成本更低，也更符合内容运营的稳定性要求。