Hermes cron 最容易被误用成“能定时就定时”。真正有价值的 cron job，应该能回答三个问题：为什么要周期性触发，输出发给谁，失败后怎么停。
官方文档这轮把 cron 能力讲得更清楚了：现在统一通过 cronjob 工具管理，既支持一次性任务和周期任务，也支持 pause、resume、edit、run 和 remove；任务结果可以回到 origin chat、保存到本地文件，或投递到已配置的平台目标。对应用层用户来说，这意味着你不必把 cron 只理解成“命令行定时器”，而应该把它当成一个长期运行的任务总线。
下面这些示例不追求炫技，而追求可落地。
先用官方能力划分任务形态
在挑第一个 cron job 前，先按官方能力拆分：
| 形态 | 更像什么 | 适合的第一批任务 |
|---|---|---|
| one-shot | 延迟执行一次 | 1 小时后提醒我复核迁移结果 |
| recurring | 固定周期重复 | 每周内容复盘、每日健康检查 |
| skill-backed | 调已审查 skill | 固定格式周报、结构化复盘 |
| no-agent | 直接跑脚本 | 心跳检查、端口检查、磁盘阈值提醒 |
如果任务只需要脚本 stdout，就别强行上 LLM；如果任务需要归纳、分类、解释，再让 Agent 参与。
示例 1：每周内容缺口复盘
适合内容站、文档站、工具导航站。
任务目标：每周统计哪些教程太短、哪些搜索意图缺页、哪些官方资料需要重新核验。
输出方式：发到个人消息入口或本地摘要文件。
风险等级：低。它只读内容，不自动发布。
这个任务适合 AgentClaw 这类站点。cron 负责触发，Hermes 负责总结，人工决定下一批写什么。它能把“我该更新什么”变成稳定节奏。
更稳的写法是把 delivery 先设成 origin 或 local。这样结果会回到创建任务的会话，或者落到本地输出目录，便于你先观察两三轮，再决定要不要接 Telegram、Discord 或 Slack。
示例 2：每日构建健康检查
适合个人项目和小团队项目。
任务目标：定时运行 build 或 smoke，失败时生成摘要。
输出方式：失败时投递到 Telegram、Slack 或本地通知。
风险等级：中。它可以读项目、运行命令，但不应该自动改代码。
如果只是检查命令是否成功，可以先用 no-agent watchdog；如果失败后需要解释日志，再让 Hermes 参与总结。
官方文档明确提到 no-agent 模式会把脚本输出原样投递，不走模型。这个模式的价值是克制：平时静默，异常时再把 stdout / stderr 摘要送出来。
示例 3：依赖更新提醒
适合长期维护的开源或内容项目。
任务目标：定期查看依赖、框架、官方文档或 API 变化。
输出方式：生成“需要关注 / 可以忽略 / 需要人工确认”三类列表。
风险等级：低到中。建议只提醒，不自动升级。
这类任务的价值是减少遗忘，而不是替你做决定。它尤其适合官方资料还在快速迭代的产品线，因为 cron 可以提醒你“该看一眼”，但不替你自动改正文。
示例 4：每周 memory 清理提醒
适合长期使用 Hermes 的用户。
任务目标：提醒用户检查 MEMORY.md 和 USER.md 是否有重复、过期或敏感内容。
输出方式：本地提醒或个人消息。
风险等级：低。不要让 cron 自动删除 memory，先生成建议。
memory 清理很像整理项目约定。你不做，它就慢慢变乱；自动做，又容易误删。
如果你只想提醒而不是输出长文，可以让任务返回短摘要；如果想完全不打扰，只落地文件，也可以让任务把结果写到本地输出目录，等人工批量处理。
示例 5：skill-backed 周报
适合已经有稳定 skill 的工作流。
任务目标：定期调用一个经过审查的 skill，生成固定格式周报。
输出方式：投递到指定消息入口或保存到固定目录。
风险等级：中。关键在于 skill 已经审查过。
不要让 cron 调用临时脚本。cron 会把一次动作变成长期动作，长期动作必须先通过安全审查。
这也是为什么示例 5 必须先有 skill，再有 schedule。先审查动作，再放大调用频率，顺序不要反。
示例 6：no-agent Watchdog
适合服务心跳、端口检查、磁盘空间、简单 API ping。
任务目标：只在异常时提醒。
输出方式：失败时输出 stdout / stderr 摘要。
风险等级：取决于脚本。只读检查通常较低。
no-agent 的好处是克制：不需要模型的时候不调用模型，成功时可以安静，异常时再找你。
如果你只是想把现有脚本接入 Hermes 交付链路，这个模式比“为了定时而重写成 prompt”更实际。
交付方式要先定，不然后期会混乱
Hermes cron 的 delivery 不是小细节，而是治理边界。你至少要先选一种：
| 交付方式 | 什么时候用 |
|---|---|
| origin | 先在创建任务的原会话里观察输出 |
| local | 想保留审计文件，不想每次都推消息 |
| platform target | 已经确认投递对象、格式和噪音阈值 |
官方文档还提到：即使不投递到外部目标，输出也会保存在本地，适合审计和复盘。对于团队项目，这比“只看聊天窗口”稳得多。
两个容易踩的边界
1. cron 不是递归自动化生成器
官方文档专门限制了 cron 运行时的 cron 管理能力，目的就是避免任务自己再创建、修改一堆任务，最后没人知道调度面发生了什么。
所以你要把 cron 理解成“执行层”，不是“无限繁殖自动化的母任务”。
2. 静默输出不是失败
如果任务结果被标记为静默，外部不会收到消息，但本地仍可能有审计输出。遇到“没收到提醒”时，不要马上判断为任务没跑，先看任务是否本来就是静默设计。
上线前写清 5 件事
每个 cron job 上线前，至少写清：
- 触发频率。
- 运行 profile。
- workdir。
- delivery 目标。
- 停用方式。
如果一个任务没有停用方式，它就不该上线。长期运行的自动化，必须能优雅停止。
再补一项很实用的字段：owner。谁创建、谁验收、谁停用，要写清楚，不然两周后你只会看到一个“还在跑但没人认领”的后台任务。
完成检查
- 你已经选出一个低风险 cron 示例。
- 你知道它是否需要 LLM。
- 你已经决定结果先发回 origin、local 还是平台目标。
- 你写清了输出发到哪里。
- 你没有让第一批 cron 自动修改生产资源。
- 你知道失败后如何暂停或删除任务。