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 是工具箱裡最乾淨的一把。