大部分人用 AI 助理的方式是這樣的：打開對話 → 問問題 → 得到答案 → 關掉。
這樣用當然沒問題，但你有沒有想過：如果 AI 能在你沒問的時候，自己去做那些你每天都要做的瑣事呢？每天早上幫你整理今天的行程和待辦、自動跑一份投資分析、凌晨幫你回顧一整天的對話然後寫進筆記？
這才是 AI 助理的真正殺手級應用，而 OpenClaw 的 Cron Jobs 功能讓這件事變得非常容易實現。
兩種排程模式：先搞清楚再動手
OpenClaw 的 cron job 有兩種執行模式，這是一開始最容易搞混的地方，我自己也在這裡卡了一陣子。
systemEvent：注入主 session
想像一下，你正在跟 AI 助理聊天，突然有人在對話中插入了一條系統訊息：「現在是早上九點，請執行每日回顧。」AI 會在現有的對話脈絡中看到這條訊息，然後執行。
這就是 systemEvent 模式。它不會開新的 session，而是把排程指令「注入」到你正在進行的主 session 中。好處是 AI 可以看到之前的對話脈絡，壞處是如果你當時正在聊別的事，排程訊息可能會插得很突兀。
適用場景：需要對話脈絡的任務，比如「根據我們今天討論的內容整理一份摘要」。
agentTurn：獨立 session 執行
這個模式完全不同。它會啟動一個全新的、獨立的 session，讓 AI 在裡面執行任務，完成後把結果推送到你指定的頻道。跟主 session 完全隔離，互不干擾。
適用場景：獨立的、不需要對話上下文的任務，比如「抓取今天的股市數據做分析」、「從行事曆生成日報」。
我的經驗法則：**90% 的情況你應該用 agentTurn**。只有真的需要延續當前對話語境的時候才用 systemEvent。
排程類型：三種選擇
在決定好執行模式之後，還要選排程類型：
- **
at**：一次性排程，指定一個時間點執行一次就結束。適合「明天早上八點提醒我開會」這種場景 - **
every**：固定間隔執行，比如每 30 分鐘、每 2 小時。適合定期巡檢之類的任務 - **
cron**：標準的 cron expression，最靈活。0 5 * * 1-5代表每個工作日早上五點執行
我大部分的排程都用 cron 類型，因為它最靈活，可以精確控制「每週幾的幾點」執行。
設定方式：config.yaml 範例
實際設定 cron job 是在 OpenClaw 的 config 裡面完成的。大致結構長這樣：
1 | cron: |
這個設定檔看起來很直覺，但有幾個細節容易漏掉。第一，tz 一定要設，不然會用系統預設時區（後面會細說這個坑）。第二，deliver 要指定正確的頻道名稱或 ID，不然結果會不知道推到哪裡去。第三，prompt 要寫得足夠詳細，因為 agentTurn 是全新的 session，它不知道你平常習慣怎樣。
我一開始設定的時候，prompt 只寫了一句「生成日報」，結果 AI 給出來的東西格式亂七八糟，完全不是我要的。後來花了好幾次迭代，把期望的格式、資料來源、注意事項全部寫清楚，品質才穩定下來。
實戰案例：我的五個日常 Cron Job
1. 每日站會日報（05:00）
我每天早上五點（對，五點，因為我想醒來就看到結果）會跑一個 agentTurn，它的 prompt 大致是：
從 Google Calendar 抓取今天的行程，從 Notion 抓取進行中的任務和昨天完成的項目，然後用站會格式（昨天做了什麼 / 今天要做什麼 / 有什麼 blocker）生成一份日報。
AI 會自動呼叫對應的 skill 去抓資料，整理好之後推送到我 Discord 的工作頻道。等我七八點起來，打開 Discord 就看到一份整理好的日報了。
這個排程幫我省了每天至少 15 分鐘的手動整理時間。一個月下來就是 7.5 小時。聽起來不多，但積累下來真的很可觀。而且重點不只是省時間——是省掉那個「早上一坐下來先花十分鐘整理待辦」的心理負擔。
2. 投資分析推送（08:30）
早上八點半，另一個 agentTurn 會啟動。它會透過金融 API 抓取我關注的標的數據——包括股價變動、法人買賣超、融資融券變化、近期月營收等。
AI 拿到數據之後會做一份簡短分析：哪些標的有異常波動、法人動向是否有變化、有沒有需要注意的技術面訊號。然後把結果推送到我的投資分析頻道。
這個 cron job 的 prompt 花了我不少時間調教。一開始 AI 給的分析太籠統，後來我在 prompt 裡加了很多具體的分析框架和判斷條件，效果才慢慢變好。比如我會明確告訴它：「如果外資連續三天賣超超過一千張，特別標示出來。」這種具體的條件比「分析法人動向」有用太多。
3. 每日記憶整理（04:00）
凌晨四點，AI 會自動回顧前一天的所有對話紀錄，然後把重要的資訊整理寫入記憶檔案。這個是 OpenClaw 記憶系統的一部分，確保長期重要的資訊不會隨著 session 結束而消失。
這個任務我用 systemEvent 而不是 agentTurn，因為它需要存取主 session 的完整記憶上下文，才能正確判斷哪些資訊值得留下來。
4. Heartbeat 主動關心（每 4 小時）
這是 OpenClaw 內建的 heartbeat 機制。它會定期觸發一個檢查：「現在的狀況怎樣？有沒有什麼該做但還沒做的事？使用者今天有沒有異常（比如平常這個時間都會上線，今天卻沒有）？」
說實話，一開始我覺得這個功能有點多餘。但用了一陣子之後發現還蠻有用的——它會在我忘記某個重要截止日期的時候主動提醒，或者在發現系統異常（比如某個 API 連線失敗）時通知我。
有一次我完全忘了一個重要的會議，是 AI 主動在 Discord 提醒我的。從那之後我就再也沒關過 heartbeat。
5. 週報摘要（每週五 18:00）
每週五下班前，一個 agentTurn 會把這一週的所有 daily memory 拉出來，濃縮成一份週報摘要。包括這週主要做了什麼、有哪些決策點、下週需要注意的事項。
這份摘要對我每週的覆盤非常有幫助。人的記憶是不可靠的，一週過去之後你很可能已經忘了週二做的那個重要決定。有一份自動生成的週報，覆盤時就有素材可以參考。
踩坑經驗：血淚分享
用 cron job 的過程不是一帆風順的。以下是我踩過的幾個大坑：
坑 1：agentTurn 沒有上下文
這是最容易忘記的一點。agentTurn 啟動的是一個全新的 session，它不知道你之前聊了什麼、不知道你的慣用語、甚至不知道你最近在忙什麼——除非你在 prompt 裡明確告訴它。
一開始我的 prompt 寫得很簡短，結果 AI 給出的東西完全不符合期望。後來我學到：agentTurn 的 prompt 要像在給一個新來的實習生交代任務一樣詳細。 目標是什麼、需要哪些資料、輸出格式是什麼、有什麼特殊要求——全部寫清楚。
如果你的任務真的需要最近的對話脈絡，可以用 contextMessages 參數帶入一些近期訊息。但要注意 token 用量。
坑 2：時區問題
這個坑我踩得很痛。OpenClaw 的 cron job 有一個 tz 參數可以設定時區，但如果你忘了設，它會用系統預設時區。
我的伺服器時區是 UTC，而我人在 UTC+8。結果本來應該早上八點執行的日報，凌晨十二點就跑了。半夜收到一封熱情洋溢的「早安！這是你今天的行程安排」，那個體驗非常超現實。
教訓：永遠顯式設定 tz 參數。 不要依賴系統預設值。
坑 3：排程衝突吃光 API Quota
有一次我設了五個 cron job，其中三個都在早上五點整觸發。三個 agentTurn 同時啟動，三個 session 同時狂打 LLM API——然後我的 API rate limit 就爆了。
解法很簡單：錯開排程時間。我現在把排程改成 05:00、05:10、05:20 這樣，避免同時觸發。看起來是小事，但遇到之前真的想不到。
而且不只是 LLM API，如果你的 cron job 裡有打外部 API（像我的投資分析要打金融 API），同時觸發也可能觸碰到外部 API 的 rate limit。所以養成習慣：每個 cron job 之間至少間隔五到十分鐘。
坑 4：systemEvent vs agentTurn 選錯
早期我很多任務都用 systemEvent，因為覺得「能看到上下文」比較好。但後來發現幾個問題：
- systemEvent 會打斷你正在進行的對話
- 如果當時沒有 active session，systemEvent 的行為可能不符合預期
- 多個 systemEvent 擠在同一個 session 裡，AI 可能會搞混優先順序
現在我的原則是：除非任務明確需要延續主 session 的語境，否則一律用 agentTurn。 乾淨、獨立、不互相干擾。
坑 5：Prompt 裡沒有指定失敗行為
這個是我後來才意識到的問題。如果 cron job 的任務失敗了（比如 API timeout、資料格式錯誤），AI 會怎麼做？預設行為可能是回一段很長的錯誤訊息到你的頻道，或者默默失敗什麼都不說。
我現在的做法是在 prompt 裡加一段失敗處理指示，大概像這樣：
如果任何 API 呼叫失敗或超時，不要重試超過兩次。如果最終還是失敗，推送一條簡短的失敗通知，包含錯誤原因，不要推送長篇大論的技術細節。
這樣即使出問題，我收到的通知也是乾淨的，不會被一大堆 error stack 淹沒。
進階技巧
deliver 參數：精準推送
agentTurn 的 deliver 參數可以指定結果要推送到哪個頻道。這個超好用。比如投資分析推送到投資頻道、工作日報推送到工作頻道，而不是全部混在一起。
我甚至會根據任務結果的重要程度推送到不同頻道。比如日報是常規推送，但如果投資分析檢測到異常波動，就推送到一個高優先級的通知頻道。
善用 cron expression
如果你不熟悉 cron expression，推薦去 crontab.guru 測試。一些常用的：
0 5 * * 1-5：週一到五早上五點30 8 * * *：每天早上八點半0 */4 * * *：每四小時0 18 * * 5：每週五下午六點
除錯技巧
Cron job 出問題時，最有效的除錯方式是先用 at 類型設一個幾分鐘後的一次性排程，看它的輸出是不是符合預期。確認沒問題之後再改成定期排程。
另一個技巧是在 prompt 最後加一句「在回覆的最後附上你使用了哪些工具和各自的執行結果摘要」。這樣你收到推送結果時，可以快速檢查每個步驟是否正常。相當於內建了一個 debug log。
成本控制
每個 agentTurn 都是一次完整的 LLM 呼叫，是要花錢的。如果你設了十個每小時執行的 cron job，一天就是 240 次呼叫。加上每次呼叫裡面 agent 可能又呼叫了好幾次工具（每次工具呼叫都會產生新的 LLM turn），成本會比你想像的高。
我的做法是：定期檢查每個 cron job 的實際用量，把不常用或 ROI 不高的排程頻率降低。比如某個分析報告我本來設每天跑，後來發現每週一次就夠了——一下子省了 6/7 的成本。
結語：你的 AI 永遠不會忘記打卡
設好 cron jobs 之後，最大的感受是：我真的多了一個助手。
它不是那種你要一直盯著、一直下指令的工具。它是那種你設好規則之後，就會自己默默做事的助手。你不需要每天早上花時間整理日報——它已經做好了。你不需要手動去查股票——分析已經推送到你的頻道了。你不需要擔心忘記某件事——heartbeat 會幫你記著。
而且它永遠不會遲到、不會忘記、不會請假。（唯一的例外是你的伺服器掛了，但那是另一個問題。）
如果你已經在用 OpenClaw 但還沒試過 cron jobs，我強烈建議你從一個簡單的每日日報開始。體驗過「醒來就看到 AI 自動做好的東西」之後，你就回不去了。
自動化最大的價值不是節省時間，而是消除那些「我還有什麼事沒做」的焦慮。當你知道有一個不會忘事的助手在背後默默跑著，心裡那份安定感是很實在的。
OpenClaw 文件裡有完整的 cron jobs 設定說明：docs.openclaw.ai。有問題也歡迎到 Discord 社群 討論。