Hermes 迁移到 OpenClaw 上线清单：频道、定时任务、权限和回滚一次检查-361Sale WordPress Care

Hermes 迁移到 OpenClaw 时，很多团队只关注“旧任务能不能跑起来”，却忽略了迁移后最容易出事故的三件事：频道通知是否发到正确位置，定时任务是否按新时区触发，失败后是否有回滚和人工接管方案。内容站、独立站和技术博客的自动化任务通常不止一个，有发布排期、媒体检查、站点巡检、日报通知、缓存验证和错误告警。只要其中一个旧配置没迁好，就可能造成漏发、重复发、错频道通知，甚至把测试内容发到线上。

这篇文章把 Hermes 到 OpenClaw 的迁移拆成一份上线前检查清单。它不假设你必须一次性重写所有 Agent，而是建议先把任务、频道、认证、时区、失败告警和回滚路径梳理清楚，再逐步切换。

迁移前先整理旧任务、频道、密钥和触发条件，不要直接复制运行。

迁移前先做资产盘点

迁移自动化系统最忌讳边跑边猜。Hermes 里可能已经存在很多历史任务，有些仍在生产使用，有些只是测试遗留。正式迁移前，建议先导出或手工整理一张表，至少包含任务名称、触发方式、执行频率、使用的账号、目标频道、读写权限、失败通知和最后一次成功时间。

如果这一步没做，后面很容易出现两个系统同时运行。比如 Hermes 还在每天 09:00 发一次文章，OpenClaw 又在 09:00 补排一篇，WordPress 里就会出现重复主题。更隐蔽的问题是旧任务继续往旧频道发通知，运营以为没有告警，实际告警只是发到了没人看的地方。

建议保留的迁移字段

任务 ID 和业务名称，避免只看技术代号。
触发时间和时区，尤其是欧洲、美国和中国团队混用时。
依赖的外部系统，例如 WordPress、Cloudflare、Telegram、Discord、Slack。
密钥来源和权限范围，确认是否只读或可写。
失败后的处理方式，是重试、告警还是停止。

频道迁移：先测试，再切生产

OpenClaw 支持多种频道和通知方式，但迁移时不要直接把生产频道作为第一个测试目标。更稳的方式是先建一个迁移测试频道，把所有新任务的通知发到测试频道，确认消息格式、线程、@对象、附件和失败提示都正确后，再切换到正式频道。

尤其是内容调度类任务，通知内容必须足够短而准确。每天发布任务完成后，简报应该包含文章 ID、标题、发布时间、状态、字数、图片数、内链数和风险提示。不要只写“任务成功”，因为运营无法凭这句话判断是否真的完成。

迁移时要对比旧任务和新任务的触发方式、频道、权限和失败告警。

定时任务：时区和补偿逻辑要单独验证

定时任务迁移最容易忽略时区。旧系统可能按 UTC 运行，新系统可能按服务器本地时间或指定 IANA 时区运行。内容站如果要求柏林时间 09:00、11:00、13:00 发布，Cron 表达式就应该明确写 Europe/Berlin，而不是把本地时间手工换算成 UTC 后写死。夏令时切换时，写死 UTC 很容易错一小时。

检查 Cron 的三个问题

表达式是否按业务时区书写，而不是按当前 UTC 临时换算。
任务错过后是否需要补偿运行，还是等下一轮。
重复触发时是否有幂等检查，例如先查当天文章数量再决定是否补发。

对 WordPress 发布任务来说，幂等比重试更重要。任务失败后可以重跑，但每次重跑都必须先查当天 publish/future 数量，不能无脑再创建 7 篇。OpenClaw 的任务提示里应该明确写“差几篇补几篇”，并要求发布后再次验证。

认证和权限：能只读就不要可写

迁移时很多人为了省事，会直接把管理员账号和应用密码交给所有任务。短期看方便，长期看风险很高。建议按任务拆权限：巡检任务只需要读取文章、媒体、分类和站点状态；发布任务才需要创建文章；清缓存任务需要单独控制；删除或批量修改任务必须加人工确认。

WordPress Application Password 要记录创建时间、用途和持有人。迁移完成后，旧 Hermes 使用的密钥如果不再需要，应尽快撤销。否则即使 OpenClaw 配置正确，旧系统或旧脚本仍可能继续拥有写入权限。

回滚方案：不是迁回旧系统那么简单

回滚不是一句“出问题就切回 Hermes”。如果两个系统都可能写 WordPress，回滚前必须先暂停 OpenClaw 对应任务，确认 Hermes 旧任务没有被禁用，再检查当天是否已经产生新内容。否则回滚后可能重复补发。更稳的做法是为每类任务定义回滚动作。

内容发布任务的回滚动作

暂停新系统定时任务，避免继续创建 future 文章。
查询当天由新系统创建的文章 ID，记录状态和发布时间。
如果文章质量没问题，只保留排期，不做删除。
如果文章明显错误，改为 draft，而不是直接删除。
恢复旧系统前，再查一次当天 publish/future 数量。

上线后的 48 小时观察期

迁移完成不代表结束。前 48 小时建议提高观察频率，重点看任务是否按时触发、通知是否送达、WordPress 是否出现 missed schedule、缓存是否刷新、同一任务是否重复运行。内容站尤其要看 sitemap、分类页和首页是否能及时出现新文章。

如果 OpenClaw 任务会调用外部 API，还要观察限流和认证失败。比如 WordPress REST API 403、Cloudflare 5xx、聊天频道发送失败，都应该被写入失败告警，而不是只在日志里静默失败。

迁移检查清单

旧 Hermes 任务已盘点，确认哪些保留、哪些停用。
OpenClaw 新任务先发测试频道，通知格式确认后再切正式频道。
Cron 明确指定业务时区，避免夏令时错位。
发布类任务具备幂等检查，先查缺口再补发。
WordPress 认证按任务拆权限，旧密钥迁移后撤销。
失败告警包含任务名、时间、错误、影响范围和下一步动作。
回滚动作写清楚，避免两个系统同时写入。

延伸阅读与参考资料

总结

Hermes 迁移到 OpenClaw，真正要迁移的不是几条命令，而是一套可验证的运营机制。先盘点旧任务，再测试频道；先确认时区，再迁定时；先拆权限，再开放写入；先设计回滚，再切生产。只要把这些检查点落实，OpenClaw 就能成为更稳的自动化调度中心，而不是另一个没人敢动的黑盒任务系统。

THE END