自動化卡在半途，先查清楚再決定能不能重跑

Larry

客戶填完表單後，系統建立了一筆任務，也寄出了確認信，接著卻在更新付款狀態時失敗。畫面上只顯示「執行失敗」，值班的人無法確定前面兩個動作是否真的完成。此時按下重新執行，可能不是修復，而是再建一筆任務、再寄一封信。

多步驟自動化最棘手的狀況，通常不是完全沒有動作，而是外部世界已經被改變，流程卻停在半途。GitHub Actions、Zapier、n8n、內部腳本，以及能操作外部工具的 AI agent，都可能遇到同一個問題：系統會重試，不代表重試一定安全。

Cloudflare 在 2026 年 6 月介紹 Workflows 的 saga-style rollbacks，讓開發者能在 step.do() 旁定義後續失敗時要採取的補償動作。這項功能帶出的實用問題並不受特定平台限制：流程報錯之後，團隊能否查明哪些影響已經發生，並據此選擇重試、補償或停下來交由人工處理？

判斷重試風險，要看外部世界是否已被改變

讀取資料時暫時連不上 API，或查詢因服務忙碌而逾時，只要沒有寫入資料或對外發送內容，再試一次通常不會增加太多風險。但建立客戶資料、任務、訂單或發票，寄出 Email、簡訊與客戶通知，處理付款、退款、點數或庫存，更新 CRM 與權限，都會留下真實結果。外部 AI agent 若已經改檔、開 PR 或發出訊息，也不能當作什麼都沒做過。

因此，安全復原不等於一律把資料改回原值。已寄出的通知收不回來；另一個使用者可能已經更新同一筆資料；外部服務建立的紀錄也未必適合直接刪除。Microsoft 的補償交易模式同樣指出，補償方式要配合實際應用與同時發生的其他工作，不能只把系統倒回先前狀態。

Saga 的用途正是在這裡。當一連串本地交易中的後段失敗，系統以事先定義的補償交易處理前段留下的影響。它不保證時間倒轉，而是讓失敗之後的責任與處理路徑可以被執行、查證和接手。

每個高影響步驟都要有一份復原約定

不必先更換自動化平台。先拿一條現有流程，逐步標出哪些動作會改變外部狀態，再為這些動作補齊證據、重複執行的保護方式、補償措施與停止條件。

步驟類型	必須留下的證據	失敗後的安全處理
建立任務、訂單或發票	流程 ID、外部 ID、請求結果	先用固定識別碼查詢既有紀錄；確認不存在後才可再建
寄送 Email、簡訊或客戶通知	收件人、內容版本、服務回傳狀態	暫停後續寄送並標成待查；需要更正時由負責人確認內容
修改付款、退款、點數或庫存	交易 ID、修改前後值、完成時間	鎖定該筆操作，不自動重跑；核對交易紀錄後決定補償
更新 CRM、正式資料或權限	對象、欄位、操作者與回應	隔離有疑慮的變更，保留稽核紀錄並交人工判斷
呼叫 AI agent 或外部工具	工具呼叫紀錄、檔案或 PR ID、訊息 ID	停止後續串接，先確認工具已完成哪些動作，再決定如何收尾

Cloudflare 的 Workflows 規則建議，可能被重試的步驟應盡量具備冪等性。換成日常說法，就是同一個請求執行數次，也不會多製造一份副作用。例如以固定訂單編號建立任務時，第二次請求應回傳既有任務，而不是新增另一筆。

不過，冪等性只能處理「不要重複做」，無法修正「第一次就做錯」。寄錯內容、套用錯誤金額或授予不該有的權限，即使只發生一次，仍然需要更正、隔離或人工接手。因此，一份完整的復原約定至少要回答四件事：發生了什麼、有什麼直接證據、如何處理既有影響，以及誰能核准下一個動作。

證據不足時，正確動作是停下來

只寫「失敗就重試」無法成為復原設計。流程至少要保留整體執行 ID、各步驟的開始與完成時間、外部系統回傳的 ID、錯誤內容，以及目前停在哪個狀態。缺少這些資料時，逾時和失敗看起來可能一樣，團隊也無法判斷取消、補做或再次執行哪一個比較安全。

碰到金錢、正式客戶資料、權限或對外訊息，還需要把人工確認放進實際流程。可以參考替 AI 程式任務設置人工檢查點的做法，明確指定誰查看哪些證據、在哪個狀態下按下繼續，而不是只在文件中留下負責人的名字。

若自動化能自行串接多個工具，停止條件還必須符合它真正擁有的權限。當前一步是否成功仍不明確，或補償本身會再次改動正式資料時，應依照常駐型 AI 助理的權限邊界先封住後續動作，避免復原程序反而擴大影響。

今天可以先挑一條會寄信、改資料或呼叫外部服務的流程，只處理其中影響最大的一步。替它寫下一條可以直接執行的規則，例如：「建立任務後若寄信失敗，不得重新建立任務；保留任務 ID 與寄送結果，轉成待審狀態，由指定負責人決定是否補寄。」

只要團隊還說不清楚已發生的影響、可採取的補償方式與核准人，高影響流程就不應自行恢復。先讓系統看得見、停得住，再談自動重試，才不會把一次故障變成兩次真實損失。

AI 整理卡

先查看你目前有權存取的工作區、儲存庫、工作流設定與執行紀錄，以唯讀方式選出一條包含多個步驟的自動化；不要要求我預先整理或貼上資料，也不要實際執行、重跑、修改、取消、發送或刪除任何內容。

請自行辨認一個最明確的復原缺口，優先檢查已可能建立外部紀錄、寄出通知、修改付款／庫存／權限，或呼叫 AI agent 與其他工具的步驟。引用你直接找到的檔名、節點名稱、設定值、日誌欄位、流程 ID 或外部 ID，將結果分成「已觀察事實」與「依證據推論」；沒有證據的欄位一律寫「待確認」。若關鍵位置或權限無法存取，最多提出一個具體的存取問題。

根據現有證據，說明該步驟造成的外部影響、是否有防止重複執行的機制、可採取的取消／更正／隔離／人工接手方式，以及由誰核准後續動作。結論只能是「可自動重試」「需補償後恢復」或「必須停下交人工」。最後提出一個今天即可採用的最小修正；凡涉及正式資料、金錢、權限、客戶訊息或外部工具，只能提供建議，必須等指定負責人核對證據並明確核准，不得代為執行。