前十四天，我們先把 Agent 的模型、記憶、知識庫與角色邊界整理好。但如果每天仍然要由人打開對話，逐一輸入「幫我看財務」「幫我整理社群」「幫我追客戶」，它本質上還是比較方便的聊天工具，不是營運系統。

真正讓 Agent 開始像同事工作的轉折點，是排程。

在 ZoneTech，我把 cron 看成 Agent 的班表。它不只是某一行時間格式，而是一個有輸入、有執行者、有交付位置、有驗收標準的工作流程。每天固定時間，系統自己收集資料、整理結果、寫入報告，再把結果交付到指定聊天室。人只需要處理例外與決策。

從「幫我盯」到「每天交付」

早期的自動化通常長這樣：我在 Telegram 發一則訊息，要求 Agent 去讀幾份文件，整理成報告，再貼回來。這種方式可以驗證能力，但有兩個問題。

第一，工作是否發生，取決於我有沒有想起來下指令。第二，輸出品質很難穩定，因為每次對話帶入的上下文、資料範圍與指令細節可能不同。

改成 cron 後，工作被拆成固定的執行契約：

執行時間：每天 10:00 或 17:00

輸入資料：指定的 Google Sheets、Gmail、網站或前一次產物

處理流程：先做認證與資料健康檢查，再收集、去重、分析

輸出結果：固定格式的 Markdown 報告與指定交付渠道

驗收條件：資料筆數合理、來源可追溯、內容不是空白或錯誤 fallback

這個差異很大。前者是「有人記得就做」，後者是「到了時間就產生可驗證的交付物」。

一個 cron job 不只是時間設定

我現在設計排程時，不會只寫一個 command 然後期待它成功。至少要明確定義六個部分。

一、觸發條件

例如每天平日 10:00 執行，週末不發送公司專區報告。時間、時區、星期限制都要寫清楚，不能讓系統依預設值猜測。

二、資料來源

來源要列出具體文件、Sheet、信箱查詢條件或 API。若資料來源讀不到，流程應該回報阻塞，而不是用昨天的舊資料填滿報告。

三、執行模型與權限

固定格式的資料整理可以用成本較低的模型；跨來源判斷與管理報告才交給推理能力較強的模型。每個 job 也要限制能讀取的 Profile、檔案與外部服務，避免一個排程意外取得整間公司的資料。

四、產物位置

報告要寫到固定且可追蹤的位置，例如 Obsidian Vault 的 reports 目錄。只在 /tmp 產生一份檔案，下一次被清掉，就不算可靠的交付。

五、外部交付

若要傳到 Telegram、LINE 或 Email，必須固定對象與格式。寫入本機檔案不等於對方已收到；送出後仍要讀回訊息或平台結果驗證。

六、停止條件

認證失效、來源筆數異常、上游回傳空白、輸出包含錯誤標記時，應停止後續發布。自動化最危險的狀態不是失敗，而是帶著錯誤資料看起來成功。

ZoneTech 的排程生命週期

一個 job 從建立到穩定運作，大致會經過四個階段。

建立：先定義目標、資料源、owner、輸出、時程與驗收方式。

審計：檢查 job 是否真的存在、模型是否被意外改掉、環境變數與權限是否正確、輸出位置是否仍可寫入。

修復 delivery：執行成功但沒有人收到，通常不是核心程式壞掉，而是交付渠道、Chat ID、權限或格式出了問題。這要和「工作沒有執行」分開診斷。

監控：保留每次執行的輸出與錯誤，觀察連續失敗、耗時變化與上游資料品質。不能只看程序的 exit code。

實際踩雷：成功執行，卻沒有成功交付

有一次排程在程序層面回報成功，log 也沒有明顯錯誤，但預期的報告沒有出現在目標聊天室。若只看 exit code 0，很容易直接把它標記成完成。

後來把流程拆開檢查，才發現「產生報告」與「送出報告」是兩個不同的狀態。前半段已經完成，後半段的 delivery 卻沒有留下足夠證據。這次經驗讓驗收規則改成三段式：

本機變更：報告檔案確實產生，內容不是空白

服務狀態：排程程序與必要服務確實載入並執行

外部效果：指定聊天室或平台讀回實際送達結果

只有三段都成立，才稱得上完成。這個原則後來也套用到文章發布、Google 文件與網站部署。

先做 preflight，再做正式工作

排程不應該一到時間就直接執行主要任務。比較安全的順序是：

1. 檢查必要認證是否仍有效。
2. 認證失效時，嘗試既定的自動修復流程。
3. 修復後重新測試；仍失敗就保留任務並回報阻塞。
4. 檢查上游資料是否有合理筆數與內容。
5. 執行主要分析與產生報告。
6. 驗證本機產物，再執行外部交付。
7. 讀回外部平台結果，最後才記錄成功。

這個流程看起來比「直接跑腳本」多了幾步，但它把最常見的錯誤從正式交付前攔下來。尤其是認證問題，越晚才發現，越容易產生空報告、過期報告或重複重試。

排程系統的核心不是自動，而是可追溯

當 cron 數量增加，真正的管理問題不是「能不能再加一個 job」，而是出了問題能不能回答以下問題：

這份報告由哪個 job 產生？

它讀了哪些資料？資料是在什麼時間讀取的？

使用哪個模型與哪組設定？

誰負責處理失敗？

最後一次成功的外部證據在哪裡？

如果這些答案只能靠翻聊天紀錄或猜測，系統就還沒有產品化。每個排程都應該留下最小但足夠的證據：執行時間、輸入範圍、輸出路徑、狀態、錯誤原因與外部結果識別資訊。

今天的驗證

本篇不是用「我設定了一個 cron」作為完成證據，而是檢查它能否留下完整交付鏈：

本機：排程產生固定格式報告，並保留在 Vault 的 reports 目錄。

服務：job 設定包含固定的觸發時間、模型與交付目標，執行記錄可追蹤。

外部：送出後從目標平台讀回實際訊息，確認文字、時間與對象一致。

如果其中一段沒有證據，正確的狀態應該是「部分完成」或「阻塞」，而不是成功。

結語

Cron 讓 Agent 從被動回應問題，變成主動交付工作的系統。但排程本身不會自動帶來可靠性；可靠性來自明確的輸入、權限、產物、交付與驗收邊界。

下一篇會進入一個每天 10:00 與 17:00 自動運作的真實案例：財務日報。重點不是把數字加總，而是如何定義唯一收入口徑，避免不同資料表與不同解讀造成管理決策偏差。