做 OpenClaw 自動化排程最讓人頭痛的，往往不是任務完全沒動靜，而是跑到了某一步突然逾時（Timeout），你卻完全不知道現在按下重跑安不安全。
很多時候，AI 模型其實已經把文案產出來了，WordPress 也已經默默建好了草稿，可能只差最後一步 Google Sheets 的狀態回寫沒收到回應。如果維運人員只看到錯誤通知，反射性地直接手動按下 Retry，下場往往就是 WordPress 後台多出一篇一模一樣的草稿、試算表多了一筆重複資料，通訊軟體甚至連跳兩次推播。
要讓自動化流程能長期穩定運作，關鍵從來不是無腦把重試次數往上加，而是要讓流程中的每個步驟都能明確辨識：「這件事，到底是不是同一筆工作？」
本篇目錄
一、為每次排程建立穩定的「冪等鍵（Job Key）」
每次排程觸發時，系統都必須產生一組具備唯一辨識能力的 Job Key。這組鍵值建議包含任務名稱、預定執行時間與目標業務對象（例如文章分類或目標 ID）。
當排程中斷需要補跑時，一定要沿用原本那組 Key，千萬不要重新產生一個看似全新任務的 ID。這組冪等鍵必須一路帶進 AI 模型呼叫、產出檔案、WordPress 草稿建立以及通知回寫的每一個環節，讓各個下游系統都能先檢查是否已經處理過。
千萬不要只拿「當下執行的系統時間」當 ID，因為補跑的時間每分每秒都不同，這樣完全無法阻止系統重複交付。
二、把執行狀態拆解成可判讀的節點
很多排程只用單一的 success 欄位來記錄狀態，這在複雜流程中根本不夠用。一個能安全恢復的流程，至少要將狀態細分為五個節點：
queued：已進入排程佇列running：正在執行中generated：內容已產出完畢，準備交付delivered：外部系統已成功寫入，並取得外部 IDfailed：執行失敗，並記錄具體中斷點與錯誤訊息
如果狀態已經停在 generated，代表文案已經生成好，重跑時直接從交付步驟繼續往下走即可，不需要再浪費資源重跑一次模型；若狀態已經是 delivered，重試時就該先去查詢外部系統確認結果，而不是再次發送建立請求。狀態機的核心價值，就是讓系統在補跑時「先判斷現況，再決定要不要呼叫下一個工具」。
三、每個外部寫入動作，都必須設定「查重條件」
網路傳輸常有「對方其實已經處理成功，但回應封包因為網路延遲中途遺失」的情形。因此，所有對外部系統的寫入動作，都必須具備查重機制：
- WordPress 寫入：建立文章前，先透過標題、自訂欄位（Metadata）或冪等鍵查詢是否已有相同草稿。
- Google Sheets 回寫：先檢查任務名稱、排程日期與標題的組合是否已經存在於工作表中。
- 即時通訊通知：發送訊息前，先比對是否已有相同 Job Key 的成功發送紀錄。
查重的目的不是限制所有內容都不能相似，而是確保同一個交付動作不會因為網路逾時被執行兩次。當 API 回應遺失時，「先查詢現況再決定是否重送」，永遠比盲目重試來得安全。
四、把「生成」和「交付」設成兩個明確邊界
內容生成通常只耗費運算資源，可以安全重跑；但外部寫入往往具有不可逆的副作用，因此這兩件事必須明確拆開。
標準作法是：先將完整的 Prompt 輸入、模型產出的版本與草稿文字在本地保存妥當，確認無誤後，再進入 WordPress、試算表或發送通知的「交付階段」。
而且，每一個交付步驟只要成功，就必須立刻將回傳的外部 ID（例如 WordPress 文章 ID）寫回狀態記錄，絕對不能等整條流程全部跑完才一次存檔。這樣即使在最後關頭斷線，下一次補跑也能精準從最後成功的邊界接續進行，而不是整條打掉重練，猜測舊資料到底送出去了沒。
五、透過「故意中斷測試」驗證補跑機制
千萬不要只在一切正常時測試排程。要驗證自動化流程是否足夠穩健，最有效的方法就是做「故障注入測試」。
你可以準備一筆測試任務，並在以下三個時間點故意強制中斷：
- 模型生成內容後、寫入 WordPress 前中斷。
- WordPress 草稿建立後、回寫 Google Sheets 前中斷。
- Google Sheets 回寫後、發送最後通知前中斷。
接著帶入相同的 Job Key 重新執行，確認系統是否能符合三項標準：
- 已完成的外部動作不會增加第二筆重複資料。
- 未完成的動作能精準接續執行。
- 最後能完整讀回正確的執行狀態與文章網址。
如果重跑時還需要人工進後台確認哪一步做過、手動刪除重複草稿，就代表目前的狀態紀錄與冪等鍵設計還不夠完整。
穩定的 OpenClaw 排程從來不是「失敗就再跑一次」，而是每次補跑都能清楚回答三個問題：同一筆工作是哪一筆、已經交付到哪裡、下一步會不會造成重複。把這套架構建立好，重試才會真正成為安全、可驗證的自動化恢復流程。
常見問答（FAQ）
Retry 只是單純再次執行動作的行為；而冪等性要求的是無論同一個動作重跑多少次，都不會產生多餘的副作用或重複資料。兩者必須互相搭配設計。
不建議直接重送。建議先用 Job Key 查詢外部系統是否已經寫入成功，確認完全沒有紀錄後，才重新發送未完成的動作。
冪等鍵應貫穿整個流程：保存在任務狀態紀錄中、帶入每次呼叫工具的請求參數內，並寫入外部系統（如 WordPress 的自訂欄位 Metadata），方便日後反查。
至少需驗證三種情境：正常端到端執行、在外部交付完成瞬間故意中斷後重跑，以及遇到權限錯誤或網路中斷後的修復重跑。