Hermes Agent cron jobs：真正跑得穩嘅定時調度

嗨，我係 Lena。有一個 cron job，我設好咗差唔多三日，先發現佢其實冇做緊我以為佢會做嘅事。

佢喺 list 入面睇落冇問題。schedule 係啱嘅。個 prompt 係我某個星期二下午寫落，當時覺得好清楚。但實際跑出嚟嘅結果，總係有少少唔對路——唔係壞咗，只係……同我喺普通 chat 入面問 agent 同一件事時得到嘅 output，唔係同一種感覺。**我喺呢度停咗一下。**我一直將佢當成 Linux cron。問題係，Hermes Agent cron 其實唔係 Linux cron。佢只係借用咗 schedule syntax。

呢篇係我慢慢理解 Hermes 入面 cron 到底點樣工作嘅筆記——亦係點解好多 jobs 睇落 schedule 配得好正確，但實際跑起上嚟就唔太好。呢啲事大概喺未出事之前都唔急，直到佢突然變得好急。

Hermes Cron 到底做緊咩

第一件值得直接講清楚嘅事係：Hermes cron job 唔係一個按 timer 執行嘅 shell command。佢係一個按 schedule 觸發嘅 agent session。

呢個分別比我一開始以為嘅重要得多。根據 official Hermes cron documentation，每一次 scheduled run 都會由一個完全全新嘅 agent session 開始。冇 conversation history。冇上一個 run 嘅記憶。亦唔會由你嘅 interactive sessions 繼承 context。agent 要完成任務需要咩資訊，就要由 prompt 提供——或者由 attached skills 提供。

第二件事：**gateway 必須運行緊。**scheduler 唔係一個可以由你忽略嘅獨立 daemon。喺 gateway mode 入面，scheduler tick 係 gateway main event loop 嘅一部分，大約每 60 秒呼叫一次。如果 gateway 冇起，你個 job 會留喺 jobs.json 入面等，睇落完美地 scheduled，但其實咩都冇做。我係意外學到呢點嘅——有個 job “冇跑”，其實 job 本身冇問題；gateway 兩日前已經 crash 咗。

第三件事係 delivery。agent 嘅 final response 會自動送到配置好嘅 target。所以如果你寫嘅 prompt 以 “and send this to me on Telegram” 結尾，而 destination 就係 Telegram，Hermes 會偵測到重複，只 send 一次。呢部分已經處理好。你唔使一直諗住佢——但你要知道佢係咁運作嘅。

Schedule formats、repeats、skills、destinations

Hermes 同時接受 natural-language intervals 同標準 5-field POSIX cron expressions。所以 every 1h、30m、0 9 * * 1-5 都用到。5-field format 基本上就係到處都用緊嗰套——Linux crontab、Kubernetes CronJobs、GitHub Actions——如果你想確認 step values 同 ranges 喺 Vixie dialect 入面點樣互相作用，Wikipedia entry on cron 其實係一個出奇好用嘅參考；大多數系統，包括 Hermes，都跟住呢個方向。

如果你唔肯定自己嘅 expression 係唔係真係代表你以為嘅意思，crontab.guru 係我一直會返去用嘅工具。貼入 expression，睇 plain-English version，再 sanity-check 下一次 5 個 run times。呢種事花三十秒，但可以慳返一個下午 debug。

你可以用 --skill name attached skills（一個或多個），用 --deliver 設定 destination，幫 job 改名，亦可以逐個 job override model。Job records 會用 JSON 存喺 ~/.hermes/cron/jobs.json，而且用 atomic writes——即係如果寫入中途被打斷，你唔會得到一個半壞嘅 file。

建立頂得住真實使用嘅 jobs

我最後用落嘅 pattern，大概係咁：

hermes cron create "0 9 * * 1-5" \
  "Pull yesterday's commits from the repo at ~/work/project, \
   summarize what changed in 5 bullets, and flag anything that \
   looks unusual" \
  --skill git-summary \
  --name "Weekday standup prep"

有三件事我想特別講出嚟：

• schedule 係明確嘅。0 9 * * 1-5——工作日朝早 9 點。唔係 every day at 9。cron expression 對任何識呢套 syntax 嘅人都清楚，包括未來某個夜晚 11 點、想 debug 點解佢星期六都觸發咗嘅我。
• **prompt 係自包含嘅。**佢講清楚 repo 喺邊度。講清楚要 summarize 咩。講清楚要幾多 bullets。佢唔假設 agent 記得 previous runs 入面任何嘢。
• skill 已經 attached。git-summary skill（呢度只係假設）承載真正嘅 procedure——點樣讀 git log、用咩 format、咩先算 “unusual”。cron prompt 只需要講 要做咩，唔需要講 點樣做。

第三點係我不停重新學識嘅地方。

點解 self-contained prompts 比好多人想像中更重要

呢個係我第一個星期寫過嘅 prompt，結果冇按我想要嘅方式工作：

"Same as last time but for this week's data."

喺我嘅 interactive session 入面，呢個 prompt 係冇問題嘅。agent 有 conversation history。佢知道 “last time” 係咩。佢知道我哋當時睇緊邊份 data。**但喺 cron run 入面，呢啲全部都唔存在。**全新 session。冇 memory。冇 context。agent 讀到 “same as last time”，但冇任何嘢可以用嚟比較。

真正 work 嘅版本係：

"Read the CSV at ~/data/weekly-signups.csv. Calculate the percentage change in signups versus the previous 7 days. Report the number, the change, and the top 3 referral sources. Format as a Slack message."

悶。囉嗦。具體。每次都跑得穩。

Hermes docs 入面都有一個講同一件事嘅好例子：推薦 pattern 本質上就係，假設 agent 第一次、孤立地讀你個 prompt，除咗 attached skills 之外冇任何 context。如果呢個 prompt 作為一條畀陌生人嘅獨立 instruction 都講唔通，咁佢對一個全新嘅 cron session 都一樣講唔通。

常見 cron failures，同點樣預防

有幾種我見過會出事嘅 pattern，大多數都係我自己 setup 入面見到：

**gateway-isn't-running silence。**Job 已經 scheduled。list 入面見到。status 睇落都正確。就係冇嘢觸發。通常修法係：先用 hermes cron status 確認 scheduler 仲活緊，然後確保 gateway 安裝成 service，咁佢先頂得住 reboot 同 logout。喺你將佢安裝成 user 或 system service 之前，每次 foreground 跑 hermes gateway，都只係差一次 terminal-close 就失敗。

**帶住 implicit context 嘅脆弱 prompts。**前面已經講過。呢個問題最常見嘅版本係 “summarize what's new”——new 係相對咩？幾時？agent 唔知道。

**頻率估錯造成 overlapping runs。**一個設成 every 1m 嘅 job，如果要 90 秒先完成，就會帶出一個幾有意思嘅問題。Hermes 喺 scheduler tick 上用 file-based locking，避免同一個 due-job batch 被並行處理兩次，呢點係好嘅。但更深層嘅問題係，你真係需要 1-minute resolution 嗎？通常唔需要。

**prompt 要求 delivery，造成 duplicate sends。**如果你個 prompt 結尾寫咗 send_message(...)，目的地又同 scheduler 本身會 deliver 去嘅 destination 一樣，Hermes 會偵測到重複，skip 第二次 send。咁係冇問題嘅。但如果你習慣性將 send_message calls 寫入每一個 prompt，job 嘅 intent 就會變得更難讀。更乾淨嘅做法係將 delivery 留畀 scheduler，等 prompt 專注喺 task 本身。

**job 讀取嘅 data 帶嚟 prompt injection。**如果你個 cron job 會抓一個 webpage 然後 summarize，嗰個 webpage 理論上可以包含啲 instructions，嘗試 redirect agent 要做嘅事。Hermes 會喺 creation 同 update time 掃描 cron prompts 入面嘅 prompt-injection patterns，但佢唔會 sanitize job 喺 runtime 拉入嚟嘅 external content。呢個同 OWASP 喺 LLM Top 10 入面描述嘅 indirect prompt injection 係同一類風險——任何會 ingest untrusted input 嘅 cron job，都值得留意。我仲未完全諗清楚低風險 personal jobs 應該點樣衡量呢件事，但只要涉及 credentials 或 external systems，佢就好重要。

值得用嘅 operational patterns

幾個我反覆用返嘅 setup：

• 固定工作時間嘅 daily report。0 9 * * 1-5，配一個拉 data 嘅 skill，再配一個 self-contained prompt，清楚講明要 summarize 咩。
• Periodic health check。*/15 * * * *——每 15 分鐘——跑一個小 script 去 ping endpoint，只喺有問題時先 deliver message。cron job 入面嘅 script field 會喺每次 agent turn 之前執行，佢嘅 stdout 會成為 agent 嘅 context。對於 change-detection patterns 呢種你唔想每日 96 次 run 都輸出噪音嘅情況，好有用。
• **Multi-skill jobs。**attached 兩三個 skills，可以令一個 job 將 data-collection skill 同 analysis skill 組合埋一齊。cron prompt 就變成 “use both skills and report.”
• **Fallback-aware jobs。**Cron jobs 會繼承已配置好嘅 fallback providers 同 credential pool rotation。所以如果一個 job 喺凌晨 3 點跑，而 primary provider 回傳 rate-limit error，呢次 run 可以 route 去 fallback provider，而唔係令成個 job 失敗。呢個 feature 我之前唔太珍惜，直到佢救返一次本來會 miss 嘅 run。如果你想確認 resolution chain 具體點樣運作，Hermes cron internals page 有更詳細嘅描述。

我一直提醒自己：**一個跑得起嘅 cron job，比一個優雅嘅 cron job 更有價值。**悶、囉嗦、自包含嘅 prompts。明確嘅 schedules。以 service 形式安裝好嘅 gateway。由 skills 做重活。呢個組合，先係 “我 set 咗呢個嘢” 同 “佢已經靜靜地跑咗三個星期，我甚至忘記佢存在” 之間嘅分別。

FAQ

點解我嘅 cron job 冇辦法 access previous chat history？

每次 run 按設計都係一個全新嘅 agent session。冇 history，亦冇 memory carryover。prompt 同任何 attached skills，就係 agent 睇到嘅唯一 context。

我需要喺 prompt 入面 call send_message 嗎？

唔需要，理想情況下亦唔好。scheduler 會自動 deliver agent 嘅 final response。如果你個 prompt 亦對同一個 destination call send_message，Hermes 會偵測到重複，並 skip 第二次 send。

我個 job 會 run，但 schedule 從來冇 fire。係咩問題？

最常見係 gateway 冇運行緊。試下用 hermes cron status 檢查 scheduler。Cron jobs 只會喺 gateway up 嘅時候 fire，或者喺 CLI mode 入面有 active session 正在運行時 fire。

一個 cron job 可以建立更多 cron jobs 嗎？

唔可以。cron-run sessions 會停用 cronjob toolset，避免 runaway scheduling loops。

一個 cron job 可以跑幾耐？

預設 timeout 係根據 inactivity，而唔係 wall-clock——一個正在 actively making tool calls 或 streaming tokens 嘅 job，可以無限期運行。idle 超過 HERMES_CRON_TIMEOUT（預設 600s）嘅 job 會被 kill。

我大概仲會繼續 refine 自己寫呢啲 prompts 嘅方式。Cron 就係嗰種東西：真正令佢 work 嘅，大部分唔喺 schedule field 入面——而係喺 prompt、skill，同底層系統係唔係真係仲運行緊。間中檢查一下，呢三樣係唔係仲喺你以為嘅位置，好值得。

相關文章：

• 👉 如果你正在設定多個 scheduled tasks，可能要先理解 Hermes Cron Memory & Context Limits 會點樣影響你嘅 cron jobs。
• 👉 如果你正在排查 overlapping runs 或 slow execution，可以睇呢篇關於 Safe Hermes MCP Setup for Cron Jobs 嘅 guide。
• 👉 想深入改善 agent behavior，配合清晰 prompts 同 instructions：How to Write Effective Hermes Agent Skills
• 👉 諗緊自動化 real-time monitoring？呢篇 guide 會幫到你：Periodic Health Check Cron Jobs with Hermes
• 👉 需要優化 cron delivery，令結果更穩定？可以繼續讀 Managing Agent Capabilities and Tool Access