使用AI代理重構單體應用的經驗教訓

4月20日，1Password團隊在博客中詳細披露了他們利用AI代理重構大型Go單體應用（代號B5）的實踐。該應用擁有數百萬行代碼，是1Password產品的基石，但隨着Unified Access功能對高請求率和低延遲的需求，團隊需要更清晰的服務邊界和獨立的擴展能力。他們決定使用AI代理來分析和規劃系統的分解。

構建分析層是第一步。團隊結合Go SSA分析、SQL解析和DataDog運行時耦合數據，構建了代理工具鏈，生成了領域所有權圖、耦合圖和優先級提取順序。結果與資深工程師的判斷一致：從Vault開始，然後是Billing、AuthN/AuthZ，最後是Identity。關鍵模式是：用代理構建確定性工具（如SSA分析器），而非依賴代理持續解釋代碼。這提供了穩定的基礎，並且額外帶來了端到端事務可見性的提升。

在尋找人工與代理最佳配比的過程中，團隊處理了一個長期積壓的清理任務：將Go服務器中用於啓動數據庫事務的MustBegin（失敗時panic）替換為返回錯誤。他們生成了3000多個調用點的清單，分類為少數模式，定義了明確模板，並編寫了詳細的執行手冊，包括常見失敗模式和停止升級條件。多個代理通過git worktree並行執行，實際修改僅花費數小時。關鍵發現是：當任務被完全指定和約束時，代理既快又準；遇到超出規範的情況，系統會主動上報而非隱式猜測。

然而，在更復雜的服務提取任務中，代理的表現就不那麼理想了。即使面對相對較小的服務，代理在順序和不變量的處理上仍存在問題。例如，代理會在更新插入新行的代碼之前嘗試回填UUID列，導致靜默數據丟失；或將共享表視為新服務獨立擁有，造成部署衝突。團隊還觀察到“推測”行為：代理在缺乏上下文時用未驗證的假設填補空白，比如錯誤推斷標識符格式為ULID，最終導致整個會話回滾。這類任務的效率提升僅為20-30%，雖然可觀，但無法替代人工協調和審查。

基於這些經驗，1Password總結了四條關鍵教訓：1. 代理重構的瓶頸不是代碼生成，而是管理有順序約束或難以逆轉的決策（如模式變更、部署順序）。2. 非確定性必須被仔細控制，最佳實踐是用代理構建確定性工具，並將後續工作約束在這些輸出上。3. 不完整的規格會導致代理隱式假設，唯一可靠的方法是提供明確的規格，包括不變性、順序約束和升級路徑。4. 並行性只在變更已隔離且衝突被結構性消除時才有效。

目前，1Password正在全工程組織推廣代理工具，但明確其適用邊界：代理在問題定義清晰時最有效，而工程師仍負責定義系統邊界、建模依賴和確保順序正確。這些經驗將幫助團隊將精力從編寫代碼或提示模型，轉向設計可安全、可預測執行系統。