故障分級：先判斷是否值得恢復
不是每個 AI 程式故障都需要啟動復原流程。一個常見的誤解是看到 agent 產生錯誤代碼就立刻終止並回滾，這往往浪費了已經投入的 context。正確的做法是先分級：
- P0（嚴重）：資料遺失、服務不可用、生產環境 agent 產生破壞性操作。必須立即停止目前 session，執行回溯或復原。
- P1（高）：程式碼邏輯嚴重錯誤、持續產生低品質程式碼導致進度延誤。可以嘗試在目前 session 內修正 prompt 或回退幾步。
- P2（中）：程式碼風格問題、小範圍邏輯錯誤、上下文理解偏差。通常不需要恢復，直接局部修改即可。
- P3（低）：格式問題、註解錯誤、推薦非最佳實務。忽略或下次迭代處理。
分級的關鍵在於：恢復本身有成本。回滾意味著失去當前 agent 累積的上下文，如果專案已經運行了幾個小時，不必要的回滾可能會讓先前正確的決策也被丟棄。
恢復順序：從影響面最小的操作開始
一旦確定需要恢復，應該按照從輕到重的順序執行：
- 重試目前指令：有時故障是 LLM 瞬時推理波動，重試相同 prompt 可能直接解決問題，成本最低。
- 回退到上一步 agent 提交的程式碼版本：大多數 AI 程式設計工具（如 Cursor、Copilot Workspace）會保留操作記錄，可以直接丟棄最後一次變更，而不影響先前的修改。
- 回滾到上一個 git commit：如果 agent 提交了多個步驟，且無法局部回退，則使用 git revert 或 reset。注意：這會遺失所有未提交的上下文，操作前請務必確認。
- 清理 agent 快取並重新初始化：一些故障源自於 agent 累積了錯誤的上下文（例如誤解了專案架構），此時清理對話記錄並重新描述需求比硬回滾更有效。
- 全量回滾至已知穩定版本：僅當上述步驟都失敗，且故障涉及生產環境時。
真實場景：一位開發者在重構 API 層時，agent 突然開始刪除 routes 文件，因為它在某次對話後被注入了「簡化專案結構」的錯誤偏好。錯誤分級後認定為 P1，執行步驟 2—回退到上一步提交。但發現回退不夠，因為 agent 已經修改了多個檔案。於是執行步驟 3—git reset 到上一個 commit。恢復後，在重新初始化 agent 時，手動修正了上下文描述，加入了「不要刪除任何現有文件」的約束，後續未再發生同類問題。
回滾邊界：什麼時候不該回滾
回滾不是萬能的。以下情況回滾可能帶來更大問題：
- 與其他開發者衝突：多人協作時，貿然回滾可能涵蓋他人的提交。此時應優先溝通，而非直接 reset。
- 依賴不可逆操作：如果 agent 已經執行了資料庫遷移、刪除雲端資源等操作，程式碼回滾並不能恢復資料。對應做法是編寫遷移回退腳本或利用雲端服務快照復原。
- 上下文完全遺失：如果回滾導致 agent 遺失了專案全域 context，後續可能需要花大量時間重建。此時可以嘗試「匯出目前 context」後再回滾，有些工具支援將對話記錄匯出為檔案。
- 故障源自於 prompt 設計不當：回滾只能消除症狀，不解決根源。如果不修改 prompt 策略，相同問題會重複出現。
失敗點分析：最容易踩的坑是「無差別回滾」。團隊在 P0 故障時，直接回滾到昨夜的穩定版本，卻沒有意識到當天協同的同事剛剛合併了一個關鍵特性。回滾將該特性也遺失了，引發二次事故。規範的做法是先識別受影響的範圍，只回滾 agent 相關的文件，必要時手動 cherry-pick 同事的提交。
升級條件：何時需要團隊介入
單靠個人復原無法解決問題時，需要升級：
- 復原嘗試超過 3 次失敗：可能出現了非技術問題（如工具 bug、權限不足）。
- 故障影響擴大到其他服務或客戶：P0 事件自動升級，同時通知對方。
- 無法確定故障根因：即使恢復了，如果不找出原因，可能會再次發生。需要團隊進行根因分析（RCA）。
- agent 表現出系統性的錯誤行為：例如持續呼叫錯誤的 API，或堅持使用已廢棄的函式庫。這可能是 agent 的 training data conflict，需要團隊調整模型選型或註入自訂規則。
升級後的典型動作：開一個臨時頻道（Slack 或 Discord），共享故障當前狀態，由專人執行恢復，其他人提供支援。同時記錄時間線，方便事後複盤。
從被動恢復走向主動預防
恢復流程只是最後一道防線。真正有效率的做法是在日常開發中建立預防機制：
- 為 agent 設定執行邊界：在 prompt 中明確“只修改 /src 目錄下的檔案”“不允許執行 shell 指令”，防止越權操作。
- 啟用修改前確認模式：如果 AI 程式設計工具支持，讓 agent 每次修改檔案前先輸出 diff，由開發者確認。
- 定期提交並打標籤：建議每完成一個功能點就 commit，且使用 descriptive message，方便後期定位。
- 監控 agent 的 token 消耗與異常行為：短時間內大量修改檔案、頻繁回滾都是預警訊號。
下一步行動
掌握 incident recovery workflow 只是基礎。當你面對更複雜的 AI 程式設計場景（多代理協作、長 context 管理、動態權限模型）時，恢復流程的邊界會更模糊。如果你希望從一般開發者轉型為能夠設計和維護此類工作流程的 Agent 工程師，可以關注我們的高品質原創付費文章與課程，深入拆解實際案例與工程模式。
暫無評論，快來發表你的看法吧