用户搜索 “Hermes cron” 时，真正想知道的通常不是 cron 表达式怎么写，而是：我能不能让 Hermes 长期自动帮我检查、总结、提醒，并且失败时有人知道、出错时能停掉？
Hermes cron 的关键词不是“定时”，而是“长期运行”。一旦任务离开当前聊天窗口，你要关心的不只是 schedule，还要关心它在哪个 profile 里运行、加载哪些 skills、结果发到哪里、失败后谁能看见。
官方文档把 cron 管理集中在 cronjob 工具和 hermes cron 命令上，支持创建、暂停、恢复、编辑、触发和删除任务。对应用层用户来说，这意味着 Hermes 可以通过自然语言、CLI 或 gateway 把定时任务纳入同一套运行体系。
先分清 5 类任务
| 类型 | 适合做什么 | 第一阶段风险 |
|---|---|---|
| reminder | 提醒、日程、周期复盘 | 低 |
| watcher | 服务状态、CI、feed、价格或数据变化 | 中 |
| summary job | 定期汇总日志、文档、issue、站点内容 | 中 |
| skill-backed job | 定期调用一个或多个已审查 skills | 中到高 |
| no-agent watchdog | 只跑脚本并直接投递 stdout / stderr | 取决于脚本 |
第一阶段建议从 reminder、watcher 或 summary job 开始，不要一上来就让 cron 修改生产资源。cron 的危险不在“会不会执行”，而在“它会不会每次都在你没注意时执行”。
设计一个 cron job 前先问 8 个问题
- 这个任务为什么必须定时，而不是事件触发？
- 它需要 LLM 推理，还是脚本输出就够？
- 它要不要加载 skills？
- 它要不要固定在某个 workdir？
- 它应该使用哪个 profile？
- 输出要发回 origin、local 文件，还是具体消息平台？
- 成功时要不要通知，失败时必须通知谁？
- 如何暂停、恢复、手动触发和删除？
这些问题比命令本身更重要。命令可以补，治理边界补晚了会很麻烦。
推荐配置顺序
- 先创建一个低风险 reminder 或只读 watcher。
- 明确 delivery：测试阶段优先 local 或个人消息入口。
- 如果任务依赖固定流程，再绑定经过审查的 skill。
- 如果任务依赖项目上下文，再设置绝对路径 workdir。
- 如果任务属于不同身份或环境，再固定 profile。
- 上线前确认 pause、resume、run、remove 都能正常操作。
- 最后再接入团队入口、告警流或长期日报。
这个顺序的好处，是你可以把调度、上下文、权限和投递分开验证。不要在第一次试点里同时引入 gateway、多个 skills、生产 workdir 和外部写操作。
一个 cron job 应该长什么样
长期运行任务最怕“创建时很清楚，三周后没人记得”。建议每个 cron job 至少记录一张任务卡：
| 字段 | 说明 |
|---|---|
| 任务目标 | 为什么要定时运行 |
| 触发频率 | 每天、每周、每月或按业务节奏补充 |
| profile / workdir | 在哪个身份和目录下执行 |
| 输入来源 | 读文件、读 API、读日志，还是只用 prompt |
| delivery | 结果发到哪里，失败发到哪里 |
| 权限边界 | 能读什么、能写什么、不能做什么 |
| 停用方式 | 如何暂停、删除或回滚 |
如果你写不出这张卡片，这个任务大概率还不适合长期运行。
三个更像真实业务的例子
例子一：内容站每周复盘。cron 每周读取教程列表，统计哪些页面太短、哪些意图缺内容、哪些官方资料需要复核，然后把摘要发回个人消息入口。这种任务适合搭配 skill，因为流程稳定，结果也容易人工审查。
例子二：项目健康检查。cron 每天跑一次依赖、构建或简单 smoke，只有失败时提醒。这里不一定需要模型参与，no-agent watchdog 可能更合适。模型真正有价值的部分，是在失败后解释日志和整理下一步。
例子三：研究型提醒。cron 每周提醒你复核 Hermes、Harness 或 OpenClaw 官方文档变化，但不自动改站点内容。真正写入教程前，仍然需要人工判断内容是否值得更新。
这三个例子有一个共同点：cron 负责触发，Agent 负责整理，最终发布、高风险写入或对外承诺仍保留人工确认。
no-agent 模式什么时候有价值
不是所有定时任务都需要模型。服务心跳、磁盘空间、内存阈值、CI ping、HTTP endpoint 探活这类 watchdog，如果脚本输出已经足够表达结果，就可以考虑 no-agent 模式。
它的价值是：
- 不消耗模型调用。
- 成功时可以静默。
- 失败或非零退出时仍然能告警。
- 适合把“只在异常时找我”做成稳定后台检查。
但 no-agent 不是“无风险”。脚本仍然可能读错文件、误删缓存、暴露 secret 或打爆外部 API。你仍然要设置超时、日志、环境变量边界和失败通知。
和 Messaging Gateway 的关系
Gateway 是入口，cron 是调度。一个长期运行的 Hermes 应用通常两者都会用：
- 用户通过消息入口临时发起任务。
- cron 定期做检查、摘要和提醒。
- 两者都可能触发 skills。
- 两者都可能写入 memory。
- cron 结果可能通过 gateway 投递给个人或团队。
所以治理要放在一起看，不要只给 cron 单独开权限。如果 gateway 的触发规则很松，cron 又能调用高风险 skills，系统就会变成“谁都能间接触发后台自动化”。
和 Profiles 的关系
Cron 运行久了，profile 隔离会变得非常重要。不同类型的定时任务不应该全部挤在 default：
| Profile | 适合任务 |
|---|---|
personal-default | 个人提醒、生活计划、轻量总结 |
content-research | 资料复核、SEO 内容盘点、教程缺口分析 |
project-readonly | 项目健康检查、日志摘要、只读 dashboard |
project-prod-guarded | 生产相关任务，只允许低风险检查和人工审批 |
如果一个 cron job 会读生产日志、调用外部 API 或触发团队通知，最好给它独立 profile 和明确 owner。
常见失败模式
| 失败模式 | 处理方式 |
|---|---|
| 任务重复运行 | 检查 schedule、手动触发记录、是否存在重复 job |
| 输出没人看到 | 检查 delivery 目标，给失败路径单独通知 |
| Memory 被污染 | 区分临时摘要和长期事实，不让所有 cron 输出自动进入 memory |
| Skill 权限过宽 | 把写操作改成人工确认或只生成草稿 |
| Cron 自我扩散 | 依赖官方的 cron 管理限制，同时避免让任务生成新任务 |
| 日志暴露 secret | 输出前做脱敏，失败通知不要直接贴完整环境变量 |
排查时先暂停任务，再定位是哪一层问题。不要让一个失败 cron 在后台持续重试。
上线检查
- 每个 cron job 都有明确 owner、目标和停用方式。
- 高风险任务没有直接写生产环境。
- Delivery 目标已经验证，不会把内部结果发错地方。
- Skill、profile、workdir 和输入来源都有记录。
- No-agent watchdog 有超时、失败告警和日志。
- 成功、失败、超时、手动取消都有可读回执。
- 任务不会把临时输出无差别写入长期 memory。
下一步
想看可直接迁移成任务卡的场景，继续读 Hermes cron job 示例。如果 cron 的结果需要发到消息入口，先补 Hermes Messaging Gateway。如果你准备给不同任务分身份，继续读 Hermes Profiles 与 API Server。
完成检查
- 你能区分 reminder、watcher、summary job、skill-backed job 和 no-agent watchdog。
- 你已经知道 cron 与 gateway、profiles、memory 的边界。
- 你能为每个 cron job 写出 schedule、delivery、risk、rollback 四项说明。
- 你不会把“能定时运行”误当成“适合长期运行”。