Background Mode Rollback 是什麼？我會先看它為什麼值得工程團隊關注

背景任務回溯：不是銀彈，但必不可少

在 Agent 工程中，越來越多的任務被設計成後台執行——使用者觸發一個長期操作（如程式碼審查、批量資料處理、多步驟審批），然後去做別的事。但這些後台任務一旦出錯，後果可能比前台更嚴重：使用者看不到中間狀態，回滾邏輯如果缺位，資料不一致可能累積到無法修復。

Background Mode Rollback 就是專門處理這種場景的機制：當後台任務失敗或主動中斷時，系統會自動把已變更的狀態回退到任務開始前的快照。聽起來簡單，但在實際工程中，這個機制的設計直接決定了系統容錯能力的上限。

它怎麼工作？從快照到原子化復原

實作 Background Mode Rollback 需要三個元件：

1. 狀態快照：在任務開始前，擷取所有可能被修改的來源（資料庫列、檔案系統、外部 API 狀態等）。快照必須包含完整上下文，不能只拍“主要欄位”，否則回滾後會殘留孤兒資料。
2. 變更記錄：任務執行期間的所有寫入操作，都透過一個代理層記錄到獨立的變更日誌（Changelog）。日誌條目需要包含交易 ID、時間戳記和逆向操作指令。
3. 回滾執行器：調度引擎偵測到任務終止訊號後，按日誌的逆序列執行撤銷操作，直到所有變更被清除。如果某些撤銷操作本身失敗，通常需要手動介入或觸發補償事務。

這裡最容易踩的坑是「部分回滾」。如果任務已經啟動了外部系統操作（例如發送郵件、扣減第三方帳戶餘額），回滾組件只能記錄「已操作」但無法撤銷－這些副作用會留下幽靈狀態。因此，Background Mode Rollback 的適用範圍是“內部可控狀態”，跨系統操作必須結合 Saga 或補償交易才能安全回滾。

適用邊界：什麼場景該用，什麼場景不該用

Background Mode Rollback 最適合以下場景：

• 長時間運行的批次任務：例如 Agent 在後台逐頁抓取資料並寫入本機資料庫，中途某一頁失敗。回滾讓整批回到初始狀態，避免髒數據。
• 多步驟編排任務：如程式碼自動部署，執行了 5 步後第 6 步出錯。回滾撤銷前 5 步的修改，環境恢復乾淨。
• 使用者可取消的任務：當使用者點擊“取消”，任務需要立刻停止並恢復原狀。

但不適合的場景包括：

• 任務涉及不可逆外部操作（發送訊息、建立第三方資源）。在這種場景下，回滾只能做“標記取消”，無法真正重置。
• 任務操作的資料量極大：全量快照成本可能高於重新執行任務。例如一個後台任務修改了 10 萬筆記錄，快照和回滾的 IO 壓力會拖垮主流程。
• 任務內部使用全域變數或快取：回滾只能恢復持久化資源，記憶體中的狀態快照難以捕獲，導致系統狀態不一致。

一個真實場景：Agent 程式碼審查中的回滾

假設你的 Agent 被設計成在後台自動審查 PR 並修改程式碼檔案。它在後台執行了 10 個重構步驟，在第 11 步時發現 API 返回 500 錯誤，Markdown 表格，但用戶已經在介面上看到了「審查中」的狀態。

失敗點：Agent 嘗試回滾，但步驟 3 修改的檔案已被其他使用者並發提交覆蓋－快照還原後檔案版本衝突。

可執行做法：設計回溯時，必須給每一個修改的檔案建立版本指標（如 Git SHA），回溯操作是「恢復版本指標」而非直接覆寫內容。這樣即使檔案被並發修改，回滾後原內容仍保留在其他分支中，允許人工合併。

失敗場景：回滾本身也可能失敗

最常見的回滾失敗原因有三：

1. 快照過期：回滾執行時，目標資源的狀態已經因外部並發操作改變，無法直接復原。例如回滾一個訂單狀態，用戶已經手動取消了訂單，回滾後又試圖標記為「已支付」。
2. 日誌不完整：變更記錄遺漏了某些寫入操作（如直接透過 SQL 指令而非代理層修改資料），回滾時無法覆寫所有變更，留下部分髒資料。
3. 資源鎖定衝突：回滾需要取得與任務相同等級的資源鎖，如果鎖被其他任務佔用，回滾陷入死鎖。

備用方案：當自動回滾失敗時，系統必須產生詳細的“回滾失敗報告”，列出所有已撤銷和未撤銷的操作，並觸發人工幹預流程。同時，保留任務執行前的完整快照作為存檔，以手動恢復時參考。

實務方法：三步驟將回溯整合到工程流程

第一步，定義回滾邊界。在編寫每個後台任務時，明確定義「任務可控制的資源範圍」。只對這部分資源實現回滾，其他操作使用「補償操作」或「標記回滾」。

第二步，優先採用冪等性設計。如果任務本身冪等（重複執行多次結果相同），回滾可以簡化為“丟棄當前結果，重新執行”，不需要複雜的狀態快照。

第三步，測試回滾的可靠性。在整合測試中模擬網路中斷、服務崩潰、並發寫入等多種故障，驗證回滾後系統一致性和資源釋放。不能只測試正常回滾路徑。

結論：回滾不是萬用藥，但沒有它不行

Background Mode Rollback 是容錯工具箱中的重要工具，但它有明確的邊界和失敗前提。真正可靠的系統依賴的是防禦性設計——減少需要回滾的情況，而不是把回滾當作兜底方案。但在無法避免的場景中，精心實現的狀態快照和變更日誌，是保護資料完整性的最後一道防線。