Hermes 迁移到 OpenClaw：旧 Agent 任务如何拆成可复核工作流？-361Sale WordPress Care

Hermes 迁移到 OpenClaw，不能只理解为“换一个自动化工具”。真正要迁移的是任务模型：过去很多 Hermes Agent 偏向一次性执行，提示词里堆满账号、流程和异常处理；迁到 OpenClaw 后，更适合拆成可审计的工作流，让每一步都有输入、输出、状态和复核记录。这样做的好处是文章发布、媒体选择、内链检查、缓存复核都能留下证据。

如果你正在把旧 Hermes 写作任务迁到 OpenClaw，建议先看 OpenClaw 官方文档，再结合站内的 Hermes 迁移到 OpenClaw 旧 Agent 改造、AI 自动化运营巡检做迁移清单。

一、迁移前先盘点旧 Agent

很多旧 Agent 的最大问题是职责太宽：同一个提示词既负责选题，又负责写正文，还负责登录后台、上传图片、改分类、清缓存。迁移时不要照搬，而要把它拆成三张表：任务表、权限表、失败处理表。任务表写每天要做什么；权限表写允许访问什么；失败处理表写遇到 403、媒体库为空、排期冲突时怎么做。

Hermes 迁移到 OpenClaw 的任务梳理截图

保留稳定的业务规则，例如每天 7 篇、固定发布时间、固定分类。
删除过期账号、旧 Cookie、废弃 API 地址。
把“直接发布”改成“创建 future 并复核”。
把异常处理写成分支，不要藏在长提示词里。

二、从单 Agent 改成多角色流程

OpenClaw 更适合多角色协作。内容站可以拆成调度、写作、质检、发布四个角色。调度只看数量和时间；写作只产出符合结构的正文；质检检查字数、图片、内链和外链；发布角色才调用 WordPress API。这样做会稍微增加配置量，但能显著降低“写错分类”“图片重复”“漏内链”的概率。

Hermes 与 OpenClaw 工作流对比截图

多角色并不等于复杂。你可以先从两个角色开始：主调度 Agent 负责读取与发布，写作 Agent 负责生成内容。等流程稳定后，再加入质检 Agent。对于主题、插件、Cloudflare 等高风险维护任务，建议参考主题配置顺序，不要让内容流程直接修改生产配置。

三、迁移排期任务的关键字段

1. 时间字段

WordPress REST API 同时存在 date 与 date_gmt。迁移时必须统一以站点时区为准，例如柏林时间 15:00 写入 date=2026-05-24T15:00:00。不要让模型自行推算多个时区，否则夏令时期间容易错排。

2. 状态字段

未到时间的文章应为 future，而不是 draft 或 publish。旧 Hermes 脚本如果使用“立即发布再改时间”，迁移时要改掉，因为这会触发订阅、缓存和站点地图的异常更新。

3. 媒体字段

featured_media 必须唯一，正文图片至少两张，并且图片 ID 应来自已审核的媒体库范围。迁移脚本要记录已使用图片，避免连续几篇文章使用同一张封面。

四、迁移后的验证流程

完成迁移后，不要马上让它跑满一周。第一天只跑检查任务和一篇测试 future；第二天补齐 3 到 7 篇；第三天再打开自动简报。验证重点有五个：文章是否按时从 future 变 publish；正文是否包含 H2/H3；图片是否真实显示；站内链接是否可点击；外链是否指向可信文档。

如果出现 403 或 REST API 被防火墙拦截，先检查应用密码、Cloudflare 规则和安全插件，不要反复重试创建文章。反复失败可能造成半成品草稿堆积，后续清理成本更高。相关排查可看 Cloudflare 报错排查。

五、迁移完成后的运营指标

迁移不是以“脚本能跑”为结束，而是以“稳定不断更”为目标。建议每天记录 7 个指标：计划篇数、实际 publish/future、missed schedule 数、平均字数、图片缺失数、内链不足数、重复选题数。连续 7 天无异常后，再考虑增加更多选题方向或频道通知。

总结一下：Hermes 迁移到 OpenClaw 的核心，是把旧的提示词自动化升级为可复核工作流。只要任务边界清楚、权限最小化、字段固定、验证充分，迁移后的系统会比旧 Agent 更适合长期内容运营。

六、旧提示词迁移时的改写示例

旧 Hermes 提示词通常会写成：“你是一个全能运营助手，请检查站点、写文章、找图、发布、清缓存并通知我。”这种写法短期方便，长期不可控。迁到 OpenClaw 后，应改成更明确的指令：“先读取今天 publish/future 数量；如果少于 7 篇，只创建缺口数量；每篇使用指定分类、指定媒体库图片和指定发布时间；发布后返回结构化简报；遇到认证失败、媒体缺失、Cloudflare 拦截时停止并报告。”这类指令虽然更长，但每一步都能被检查。

字段映射也要显式写出

迁移清单里建议保留字段映射表：旧任务名对应新 Agent 名，旧发布时间对应 WordPress date 字段，旧图片变量对应 featured_media 与正文 wp-image，旧通知渠道对应 OpenClaw channel。字段映射能减少很多隐性错误。例如旧脚本可能把“封面图”和“正文截图”当成同一个变量，新流程必须拆开，否则就会出现正文有图但特色图片为空，或者特色图片存在但正文没有真实截图的问题。

最后还要把失败重试次数写清楚。内容创建失败可以重试一次；认证失败不应重试；标题重复应回到选题阶段；发布时间冲突应换到最近的空档，而不是覆盖已有文章。迁移后的流程越像一张操作票，后续越容易交给不同编辑维护。

THE END