客戶填完表單後，系統建立了一筆任務，也寄出了確認信，接著卻在更新付款狀態時失敗。畫面上只顯示「執行失敗」，值班的人無法確定前面兩個動作有沒有真的完成。這時按下重新執行，可能不是修復，而是再建一筆任務、再寄一封信。
2026 年 6 月，Cloudflare 為它的工作流程服務加入「回滾」功能：開發者可以在每個步驟旁邊，寫好這一步之後如果流程失敗要執行的補救動作。後面的步驟失敗時，系統會依步驟開始的相反順序，逐一執行前面已完成步驟的補救；補救本身失敗，就停下來、標成錯誤。
這個功能帶出的問題不限於特定平台。不論是排程腳本、無程式碼自動化，還是能操作外部工具的 AI 代理，流程卡在半途時，都要先查清楚哪些事已經發生，再決定重試、補救，或停下來交給人。
重跑之前，先問前面發生了什麼
讀取資料時連線逾時，沒有寫入任何東西，再試一次通常沒問題。但建立訂單或發票、寄出通知、處理付款或退款、更新客戶資料或權限，都會留下真實的結果。AI 代理如果已經改了檔案、發出訊息，也不能當作什麼都沒做過。
而補救也不等於把資料改回原值。寄出的信收不回來；同一筆資料可能已經被別人改過；外部服務建立的紀錄也不一定適合直接刪除。微軟的架構指南說得很清楚：補救動作要依實際業務規則處理已完成的部分，不一定能讓系統回到原本的狀態。例如旅行網站訂好了機票、卻訂不到飯店，比起把機票全部取消，替客人換一家飯店可能更好，而且這個決定應該由客人來做，不是系統。
替每個會改變外部的步驟寫好三件事
拿一條現有的流程，標出會改變外部狀態的步驟，為每一步寫下：
留下什麼紀錄： 流程的執行編號、外部系統回傳的編號、請求結果和完成時間。缺了這些，「逾時」和「失敗」看起來一樣，沒人判斷得了下一步。
出錯時怎麼處理： 建立任務前，先用固定的編號查有沒有已經建好的，避免重複；寄信失敗就停止後續寄送、標成待查；付款或權限的變更一律不自動重跑，核對紀錄後由人決定。
誰決定下一步： 牽涉金錢、正式客戶資料、權限或對外訊息的步驟，要指定一位負責人，說清楚他看哪些紀錄、在什麼狀態下按繼續。
Cloudflare 的官方規則也建議，可能被重試的步驟要設計成「冪等」：同一個請求執行好幾次，也只產生一次結果。例如用同一個訂單編號建立任務，第二次應該回傳已有的那筆，而不是再建一筆。但冪等只能避免重複，不能修正第一次就做錯的事。
把收不回來的步驟排在最後
微軟的指南還有一個很實用的建議：明確標出「不可回頭」的步驟，例如對外寄送、具有法律效力的動作，並把它們安排在所有關鍵檢查都通過之後才執行。以開頭的例子來說，先建任務、更新付款狀態，全部確認無誤，最後才寄確認信，失敗時要收拾的東西就少得多。
流程中有 AI 代理時，前一步是否成功還不確定，或補救本身會再改動正式資料，就先封住後續動作，參考〈常駐 AI 助理要先學會停手，才適合接上主要帳號〉。程式修改類的任務怎麼設人工檢查點，參考〈一張 issue 能不能交給 coding agent，看你寫不寫得出第一個 diff〉。
補救本身也可能失敗
補救動作本身也可能失敗，所以它也要能重試、要留紀錄。微軟的指南提醒，有時候人工介入是唯一的恢復方式，這時系統要發出附有失敗原因的警報，而不是默默停住。
今天可以先挑一條會寄信、改資料或呼叫外部服務的流程，只處理影響最大的那一步，寫下一條可以直接執行的規則，例如：「建立任務後若寄信失敗，不得重新建立任務；保留任務編號和寄送結果，轉成待審，由指定負責人決定是否補寄。」說不清楚已經發生了什麼、能怎麼補救、誰來核准之前，高影響的流程不應該自己恢復。
AI 整理卡
我們有一條多步驟的自動化流程（排程、無程式碼工具或 AI 代理），想先確認它卡在半途時不會因為重跑而做兩次，或留下收不回來的結果。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/workflow-rollback-needs-compensating-steps/
文章的看法是：流程卡在半途時，要先查清楚哪些事已經發生，再決定重試、補救或交給人。每個會改變外部狀態的步驟都要留下可查的編號、寫好出錯時的處理方式、指定決定下一步的人，並把收不回來的步驟排在所有檢查通過之後。
請只以唯讀方式查看我授權的流程設定和執行紀錄，不要重跑、修改或刪除任何東西。
1. 列出流程的所有步驟，標出哪些會改變外部狀態（建立紀錄、寄信、付款、改權限、AI 代理的對外動作）；
2. 檢查每一步完成後留下了什麼紀錄或編號，缺的標示「缺紀錄」；
3. 為每一步建議出錯時的處理方式：可以重試、要先查再補救、或必須停下交人，並說明理由；
4. 檢查收不回來的步驟是不是排在所有檢查之後，如果不是，建議怎麼調整順序。
最後挑出影響最大的一步，寫一條可以直接執行的處理規則。
參考來源
- Cloudflare 官方部落格：How we built saga rollbacks for Cloudflare Workflows — https://blog.cloudflare.com/rollbacks-for-workflows/（2026-06-25）
- Cloudflare 官方文件：Rules of Workflows — https://developers.cloudflare.com/workflows/build/rules-of-workflows/ [accessed: 2026-10-11]
- Microsoft Learn（官方）：Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction [accessed: 2026-10-11]
