OpenClaw 自動化通知失敗怎麼辦？先定好這 5 個重送與去重規則，拒絕重複污染！

很多自動化流程不是「有跑」就算完成，而是要做到：內容回寫成功、通知送出、外部系統也確認收到，這三件事要同時成立才算真正的成功。使用 OpenClaw 建立工作流時，一旦跨過 Google Sheets、WordPress、Telegram 這幾層系統，就非常容易出現「半套成功」的情況：例如草稿已經成功寫入，但通知沒送出；或是通知送了兩次，但實際上只需要一次；甚至任務被系統自動重試，結果把同一筆內容重複發佈出去，造成數據污染。

所以，當 OpenClaw 的通知流程失敗時，重點真的不是只有「再按一次送出」那麼簡單，而是要先定義好重送（Retry）、去重（Deduplication）和補送（Re-send）的規則。只要這幾件事沒有事先設定好，系統就會把原本好意的「補救」動作，做成令人頭痛的「重複污染」。

1. 先把「送達狀態」徹底拆開

一個健康的通知流程，狀態至少要有四種：pending（待處理）、sent（已送出）、failed（失敗）、unknown（未知）。

很多開發者只在乎 sent（成功），但實際上 sent 並不代表整個業務邏輯完成，僅代表該通訊通道（Channel）已回應成功。而 unknown（未知）則是最危險的狀態，因為你不確定它是送出去了但網路卡住，還是卡在外部系統的中途。沒有徹底拆分這層狀態，你的重試邏輯就會亂跳，最後的結果不是漏送，就是無窮的重送。

2. 重送要有「退避機制」，不要同步轟炸

當 Telegram、WordPress、Sheets 或其他外部回寫服務出現短暫不穩時，最差的錯誤處理做法就是「每秒重送一次」。正確的做法是使用固定退避（Fixed Backoff）或指數退避（Exponential Backoff），例如：30 秒後重試第一次，2 分鐘後第二次，10 分鐘後第三次，並且必須設定重試上限。

這樣可以有效避開系統瞬間的「抖動」（Flapping），也不會因為過度的重試攻擊把外部服務打成更大的失敗。在重送時，務必保留同一組 trace_key（追蹤鍵）和 attempt（嘗試次數），讓後續維運人員知道這不是新任務，而是同一輪任務的補救措施。如果只看最後的結果而不看上下文（Context），會把系統事故藏起來，增加排查難度。

3. 「去重鍵」要在寫入外部系統前就定好

通知安全的核心不是「送得快」，而是「即使意外重送，也不會重複」。所以，每個外部目標系統（如 WordPress 網站、Telegram 頻道）都應該有自己的去重鍵（Deduplication Key）。

例如，文章草稿可以使用 title + date 的組合，通知訊息可以使用 task_name + run_id + channel。只要這個鍵值（Key Value）一致，目標系統就能判斷這次是「重試」還是「新事件」。

如果沒有去重鍵，重送一次看似沒事，重送兩次就開始污染收件端。對操作人員來說，最麻煩的不是少一則通知，而是收到通知後，不知道哪一則才是「真的」有實際動作。

4. 「回寫內容」和「發送通知」要徹底分流

很多工作流把「內容寫進去（回寫）」和「通知別人（通知）」綁成同一步（同一個 Task），結果任何一個外部服務失敗（例如 Telegram API 掛掉），都會讓整個任務狀態變得模糊。

比較穩健的架構模式是：先完成主資料的回寫，確認成功後，再觸發通知服務。通知失敗不應該回滾（Rollback）已經完成的內容回寫，但要留下「待補送」的旗標（Flag），讓後續的 Worker 流程可以單獨接手這個通知。

這樣做之後，你可以接受「內容已完成、通知待補」這種暫時性的半套狀態，因為它是「可控」的半套，而不是沒人知道下一步該做什麼的模糊半套。

5. 失敗類型要分路由處理

不是每個失敗都要用同一種重試邏輯。timeout（逾時）、權限錯誤、重複事件、格式驗證失敗，這四種原因應該走四條完全不同的路徑。

timeout 可以自動重試；權限錯誤（如 API Key 失效）要直接停止並報警；重複事件要直接去重後略過；格式驗證失敗則要回到產稿端修正模型提示詞。把失敗分類好，值班人員排查時才不會看到所有紅燈都長得一樣。

6. 留下可供「補送的證據」

如果通知真的沒送出去，系統至少要留下三樣證據：原始 Payload（資料負載）、目標 Channel、以及最後一次嘗試的回應碼。

這些資料會決定你能不能補送、要不要重建內容、以及是否需要改成人工介入。沒有證據的失敗，只會變成無謂的猜測，永遠找不到系統卡在哪裡。

對於 OpenClaw 這種工作流工具來說，最小可行的安全做法其實很簡單：把送達狀態拆開、重送加退避、每個外部目標先定去重鍵、回寫和通知分流、失敗類型分路由，最後留下補送證據。做到這六件事，你的通知流程就不會再靠運氣撐著，而是擁有真正的「補救」能力。