Hermes Agent 的 cron 调度器是 agent 干活的第三种形状——前两种是逐回合聊天和 /goal 循环。cron 这一档，agent 按点无人值守地跑，结果发到你想要的那个聊天平台——或者通过 deliver=all 一次发到所有接好的平台（#21495）。
这篇从一个具体的活儿入手——一份早间日报——用它把调度器的运作机制讲清楚。同一套套路换个描述就是夜间备份、周安全审计、值班轮替提醒，或者任何你以前会用一段脆弱的 bash + cron 凑出来的活儿。
要做的事
每个工作日早上 8 点：
- 1.读昨晚的邮件（昨天下午 5 点之后的）
- 2.拉 GitHub 通知（issue、PR review、@提及）
- 3.看今天上午前 4 小时的日程
- 4.把三件事合成一条 Telegram 消息
有重要的事就写详细，什么都没有就一句话："夜里安静。上午 11 点前都没安排。"
第 1 步：定义任务
hermes cron add 会带你走一遍。CLI 会让你填：名字、时间表、任务描述（自然语言）、投递目标。
$ hermes cron add
Name: daily-morning-report
Schedule (cron expression or natural language): 0 8 * * MON-FRI
Description: |
Read overnight email (since 5 PM yesterday).
Pull GitHub notifications via the github skill.
Check today's calendar via google-calendar for the first 4 hours.
Summarize all three into one Telegram message.
Be brief when nothing important happened.
Delivery: telegram
0 8 <em class="italic text-slate-200"> </em> MON-FRI 是标准 cron 语法：第 0 分钟、第 8 小时、每一天、每个月、周一到周五。Hermes 同时认 cron 语法和"every weekday at 8 AM"这种自然语言写法。
第 2 步：8 点到了以后
下一个工作日早上 8 点，Hermes 起一个独立的 agent 会话，带：
- •把任务描述作为开场用户消息
- •agent 自己决定要调哪些 skill（
email、github、google-calendar） - •一个 delivery hook，把最终回应送到 Telegram
没有持久上下文，也没有用户在打字。agent 读完描述，调 skill，起草一条消息，发出去。一般 15–30 秒搞定。
输出会作为你那个 Hermes bot 在 Telegram 上发的消息出现。这次跑得比平常久或者出了错，同一个 channel 也会收到一条报错消息。
第 3 步：deliver=all——一次发到所有平台
默认情况下，投递只去一个平台——你在 cron add 时指定的那一个。你想让这份报告所有能找到你的地方都到，就设：
hermes cron edit daily-morning-report --deliver all
之后这条消息会一次性发到每一个你接好的聊天平台——Telegram、Discord、Slack、WhatsApp、Signal、LINE、SimpleX，凡是你配过的。v0.14.0 把按平台投递这块为 cron 单独接通了（#21495）。
什么时候有用：你想保证不管现在在哪个 app 里都能看到这条消息。
什么时候是过犹不及：你早上只看一个平台。那就挑那一个。
第 4 步：看一眼当前排了哪些任务
hermes cron list
把现在排着的所有任务、下次运行时间、上次运行结果列出来。v0.14.0 为任务操作加了按名字查找（#26231），所以你可以用名字而不是 ID 来引用任务：
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # 立刻触发一次，不等点
任务跑挂了怎么办
cron 任务跑在自己的沙箱会话里（后端跟交互式 Hermes 是同一套——看沙箱后端那篇）。某个 skill 调用失败，agent 会拿到报错，要么重试要么如实汇报。
整个任务崩了（agent 自己出了错），Hermes 会在你的默认聊天平台上通知你——带报错信息和日志链接。v0.13.0 那波会话持久化的工作意味着 gateway 重启不会丢掉待投递的 cron 结果——去重是通过原子认领 + 失败时回退实现的（#23401）。
几个实际能用的任务模板
下面这些是真有人在跑的：
夜间备份核验。 凌晨 3 点跑 cron：列出备份快照，确认今天那份在并且非空，没有的话大声报警。配 deliver=all，万一出问题你一醒就能看到。
周安全审计。 周日晚 10 点跑 cron：拉依赖告警、扫 lockfile 里已知的 CVE、把新出现的漏洞汇总一遍。v0.14.0 的 supply-chain advisory checker（#24220）让这件事比自己写脚本干净不少。
值班交接。 周五下午 5 点跑 cron：读完这一周的告警，给下周值班的人写一段交接。投递到共享的 Slack 频道。
Watchers（v0.14.0 的那个 skill，#21881）。轮询一个 RSS 源、一个 HTTP JSON 端点、或者一个 GitHub 仓库的变更；只在变了的时候通知你。配上 cron 就是"X 变了就告诉我"——这是被严重低估的自动化原语之一。
日志去哪看
hermes cron logs daily-morning-report
默认显示最近 10 次。每一次会写：时间戳、耗时、调了哪些 skill、投递了什么、有没有失败。日志放在 ~/.hermes/cron/logs/，会自动 rotate。
这比自己写 shell 脚本强在哪
同样这份日报，你完全可以拿 bash + cron + curl 到 Telegram + 也许塞一次小小的 LLM 调用拼出来。很多人就是这么干的。
cron 跑在 agent 上有意思的地方在：
- 1.任务描述本身就是 spec。 没有代码要维护。"前 4 小时"改成"前 6 小时"——改描述就完了，不用重新部署。
- 2.skill 之间能组合。 加一句"顺便也看一下 Linear 上有没有新工单"——描述里一句话的事。换成 shell 脚本，就是接一个新 API client。
- 3.投递这一层解耦了。
deliver=all意味着你不用为 5 个聊天 app 写 5 个不同的 webhook。gateway 已经会讲 22 个平台的话了。 - 4.错误能 debug。 任务挂了，agent 会用人话告诉你它试过什么、为什么失败。bash 脚本只会给你一个 exit code 1。
这不代表 agent-cron 永远是对的答案——那种必须 100% 确定、必须 30 ms 跑完的活儿，shell 脚本还是更合适。但对那种"到点了帮我做点动脑子的事，然后告诉我结果"的活儿，cron-on-Hermes 是工具箱里最干净的一把。