Hermes Cron 自动化：定时任务、后台检查与周期性提醒

Hermes 应用 进阶 进阶 预计 16 分钟 发布于 2026/5/23 核验于 2026/6/1

Hermes cron 的关键词不是“定时”，而是“长期运行”。一旦任务离开当前聊天窗口，你要关心的不只是 schedule，还要关心它在哪个 profile 里运行、加载哪些 skills、结果发到哪里、失败后谁能看见。

官方文档把 cron 管理集中在 cronjob 工具和 hermes cron 命令上，支持创建、暂停、恢复、编辑、触发和删除任务。对应用层用户来说，这意味着 Hermes 可以通过自然语言、CLI 或 gateway 把定时任务纳入同一套运行体系。

先分清 4 类任务

第一阶段建议从 reminder 和 watcher 开始，不要一上来就让 cron 修改生产资源。

设计一个 cron job 前先问 6 个问题

1. 这个任务为什么必须定时，而不是事件触发？
2. 它需要 LLM 推理，还是脚本输出就够？
3. 它要不要加载 skills？
4. 它要不要固定在某个 workdir 或 profile？
5. 输出要发回 origin、local 文件，还是具体消息平台？
6. 失败后谁会收到提醒，如何暂停或回滚？

这 6 个问题比命令本身更重要。命令可以补，治理边界补晚了会很麻烦。

推荐配置顺序

1. 先用自然语言或 CLI 创建一个低风险任务。
2. 明确 delivery：测试阶段优先 local 或个人消息入口。
3. 如果任务依赖固定流程，再绑定经过审查的 skill。
4. 如果任务依赖项目上下文，再设置绝对路径 workdir。
5. 如果任务属于不同身份或环境，再固定 profile。
6. 上线前确认 pause、resume、run、remove 都能正常操作。

三个更像真实业务的例子

例子一：内容站每周复盘。cron 每周读取教程列表，统计哪些页面太短、哪些意图缺内容、哪些官方资料需要复核，然后把摘要发回个人消息入口。这种任务适合搭配 skill，因为流程稳定，结果也容易人工审查。

例子二：项目健康检查。cron 每天跑一次依赖、构建或简单 smoke，只有失败时提醒。这里不一定需要模型参与，no-agent watchdog 可能更合适。模型真正有价值的部分，是在失败后解释日志和整理下一步。

例子三：研究型提醒。cron 每周提醒你复核 Hermes、Harness 或 OpenClaw 官方文档变化，但不自动改站点内容。真正写入教程前，仍然需要人工判断内容是否值得更新。

这三个例子有一个共同点：cron 负责触发，Agent 负责整理，最终发布或高风险动作仍保留人工确认。

给每个 cron job 写一张卡片

长期运行任务最怕“创建时很清楚，三周后没人记得”。建议每个 cron job 至少记录：

如果你写不出这张卡片，这个任务大概率还不适合长期运行。

no-agent 模式什么时候有价值

不是所有定时任务都需要模型。服务心跳、磁盘空间、内存阈值、CI ping 这类 watchdog，如果脚本输出已经足够表达结果，就可以考虑 no-agent 模式。

它的价值是：

• 不消耗模型调用。
• 成功时可以静默。
• 失败或非零退出时仍然能告警。
• 适合把“只在异常时找我”做成稳定后台检查。

和 Messaging Gateway 的关系

Gateway 是入口，cron 是调度。一个长期运行的 Hermes 应用通常两者都会用：

• 用户通过消息入口临时发起任务。
• cron 定期做检查、摘要和提醒。
• 两者都可能触发 skills。
• 两者都可能写入 memory。

所以治理要放在一起看，不要只给 cron 单独开权限。

上线检查

• 每个 cron job 都有明确 owner 和停用方式。
• 高风险任务没有直接写生产环境。
• delivery 目标已经验证，不会把内部结果发错地方。
• skill、profile、workdir 都有记录。
• no-agent watchdog 有超时、失败告警和日志。

完成检查

• 你能区分 reminder、watcher、skill-backed job 和 no-agent watchdog。
• 你已经知道 cron 与 gateway 的边界。
• 你能为每个 cron job 写出 schedule、deliver、risk、rollback 四项说明。
• 你不会把“能定时运行”误当成“适合长期运行”。