代理迴圈：為何最佳 AI 編碼工作流是迴圈而非提示

大多數人在使用 AI 編碼時仍然遵循著一種快節奏但缺乏記憶的模式：寫一個提示，得到一段程式碼，大致看一眼，貼上，然後祈禱。這種方法在小任務中或許可行，但一旦變更規模超出上下文視窗、風險超過一次差異、或者錯誤可能看起來合理時，就會失效。

真正透過代理交付實際工作的團隊已經悄然轉向一種不同的形態——不是提示，而是迴圈。

代理迴圈的核心很簡單：行動 → 透過硬性門控檢查 → 重複，直到收斂訊號指示停止。代理每次只做一個微小改動，自動化門控決定該改動是否有效，迴圈持續執行——積累成功、回滾失敗，並在沒有值得做的改動時自動停止。有趣的部分並非代理本身，而是圍繞它構建的框架，使得數千次自主小步行動變得安全。

我們剛剛釋出了一組名為“Agentic Loops”的技能包，包含八個經過實戰考驗的編碼代理迴圈模式。本文旨在解釋其背後的理念。

一次性提示的天花板

要求代理一次性“修復所有失敗的測試”或“將程式碼庫遷移到新 API”總會遇到同樣的障礙：

• 上下文溢位：一個涉及 200 個檔案的重構無法放入上下文，代理只能猜測看不見的部分。
• 無法審查：單次提示產生的 600 行差異沒有人會認真閱讀，最多隻是掃一眼就憑信心合併。
• 獎勵看似正確實則錯誤：沒有門控檢查，代理的自信成了驗收標準，但自信不等於正確。
• 沒有停止機制：像“查詢錯誤”這樣的任務只執行一次就停止，無論是否找到了全部問題。

迴圈解決了上述所有問題——不是透過讓代理變得更聰明，而是將工作單元從“一次大躍進”轉變為“許多小步、經過檢查的步驟”。

三個不變原則

每個有效的代理迴圈，無論任務是什麼，都遵循同樣的三條規則。跳過任何一條，迴圈就會退化為昂貴的忙碌工作，或者更糟——造成自信的破壞。

1. 每次迭代都有硬性自動化門控

門控是整個迴圈的核心。它是一個確定性的檢查，代理無法透過辯解繞過：測試套件的退出碼、tsc --noEmit 返回零、評估分數沒有下降、每批次行數對賬等。

規則：未透過門控的變更視為未發生。回滾，不合並。正是門控使得讓十個代理並行編輯四十個檔案成為安全之舉——因為只有綠燈的變更才會落地。

2. 每次迭代只有一個可歸屬的變更

將“修復這四件事”打包成一個步驟，當兩項透過、兩項倒退時，你無法判斷是哪個編輯導致了什麼。代理開始用散彈槍式編輯來移動數字，你會失去頭緒。

一次一個變更，一次門控執行，一次裁決。單獨步驟更慢，但整體更快，因為每一步都可獨立審查和回滾。當出問題時，你可以透過 git bisect 精確定位到具體行，而不是除錯半成品。

3. 誠實的收斂訊號

沒有停止條件的迴圈要麼永遠執行，要麼隨意停止。解決辦法是量化進展並依此停止：跳過率超過 50%、失敗測試數降為零、漏洞發現器連續 K 輪無新發現、評估分數達到平臺期。

這裡的紀律是誠實的跳過。當頁面已經完善，正確的輸出是“沒有改動，原因如下”——而不是強行做一個微不足道的調整來顯得忙碌。一個知道何時完成的迴圈抵得上十個硬撐的迴圈。

迴圈能捕獲而提示永遠無法發現的問題

一個具體例子：我們將自我改進迴圈指向一個生產環境的管理面板——擷取每個頁面的螢幕截圖，檢視它，做出一個小改進，執行 tsc 加 eslint，然後重複。經過多輪迭代，它產生了大約 85 項改進，並且每批次數都透過了門控檢查。

但最精彩的時刻並非打磨。某一輪，螢幕截圖工具——同時也在監聽未捕獲的頁面錯誤——發現了一個設定標籤頁渲染出了框架的整頁崩潰螢幕。API 健康檢查一直顯示綠色，因為崩潰是客戶端的。人類瀏覽縮圖可能會錯過它。迴圈自動捕獲了它，我們獲得了實際錯誤（Cannot read properties of undefined (reading 'memes')），跟蹤到一個狀態合併錯誤，並從根源上修復了它——現在該工具將永久標記該類錯誤。

這就是回報：迴圈不僅完成工作，它還建立了一個棘輪，防止迴歸再次發生。

八個模式對應八項任務

該模式是通用的，門控和收斂訊號隨任務變化。技能包涵蓋以下八種：

• 自我改進：截圖 → 改進一項 → 測試；門控：tsc 0 / eslint 0；停止條件：跳過率 > 50%
• 測試與修復：執行測試 → 修復第一個失敗 → 重新執行所有；門控：測試退出碼；停止條件：失敗計數歸零
• 漏洞搜尋：多樣化發現者 → 懷疑者驗證 → 修復；門控：透過對抗性審查 + 可復現；停止條件：K 輪無新發現
• 遷移：偵察站點 → 轉換每個 → 驗證；門控：每個檔案型別檢查 + 執行時；停止條件：未遷移殘留歸零
• 評估驅動：提議一項變更 → 重新執行評估 → 如果更好則保留；門控：無分數迴歸；停止條件：開發分數平臺期
• 研究綜合：收集 → 批評差距 → 填補；門控：每個主張引用已讀來源；停止條件：評論家未發現差距
• 有測試的重構：小結構變更 → 完整測試套件；門控：套件每一步後均為綠色；停止條件：達到目標結構
• 資料回填：批次 → 檢查點 → 驗證 → 繼續；門控：每批次不變性 + 對賬；停止條件：游標完成且源等於目標

值得特別指出一些容易被誤解的模式：

漏洞搜尋成敗取決於兩個細節。發現者必須視角多樣——給每個發現者不同的鏡頭（正確性、安全性、併發、洩漏），否則五個相同的發現者只會對同一個明顯的空指標解引用達成一致。驗證必須是對抗性的——要求“確認此漏洞”的驗證者會隨意蓋章看似合理的廢話；而要求“反駁此漏洞，預設反駁，僅在有具體復現時確認”的驗證者會給出可信的結果。一個細微但致命的點：去重不僅要針對已確認的發現，還要針對所有見過的發現——否則每個被拒絕的發現都會被重新發現，迴圈永遠不會枯竭。

測試與修復模式是故意偏執的。代理可能會透過刪除斷言來讓測試透過。因此，迴圈每次迭代都會比較測試檔案，拒絕任何縮小或削弱測試的變更。它一次只修復一個失敗，然後重新執行整個套件（修復第一個失敗常常會破壞第五個失敗），並檢測“卡住”——同一失敗簽名出現兩次意味著升級，而非永遠迴圈。

有測試的重構有一個不變原則：每一步的行為完全相同。如果測試套件很薄弱，代理會在觸及結構之前編寫特徵測試，將當前行為（包括 bug）固定下來。然後它採取微小的步驟，使每一步都獨立透過測試並可回滾。一旦需要修改測試才能透過，它就停止：那是以重構為名的行為變更。

資料回填建立在冪等性之上。一個處理一千萬行資料的六小時工作可能被中斷，因此每個批次必須安全地重新執行（透過鍵進行 upsert，絕不要盲目插入），並且游標必須在每個批次後設定檢查點——因短暫故障從零重啟意味著任務永遠無法完成。它邊執行邊驗證，並在最後進行源與目標的核對，因為“迴圈不再報錯”不等於“所有資料都正確”。

如何構建你自己的迴圈

你不需要一個框架。你需要三樣東西，以及誠實連線它們的紀律：

1. 選擇一個無法爭辯的門控：退出碼、型別檢查、評估分數、行數。如果你說不出門控的名字，你就沒有迴圈——你只有一種感覺。
2. 使工作單元儘可能小：一個失敗、一個頁面、一個呼叫點、一個批次。可歸屬且可回滾。
3. 量化收斂並尊重它：計數某個趨向於零的東西。讓迴圈告訴你它完成了——當它這樣做時，相信它。

然後，如果工作規模較大，就進行扇出：多個代理，每個擁有不同的切片（不同檔案、不同頁面），各自在執行任何提交前透過相同的門控。並行自主性之所以安全，完全是因為門控的存在。這就是全部訣竅。

結論

過去一年代理生產力的飛躍並非源於更聰明的模型寫出更好的單次答案，而是源於一個認識：讓一個足夠好的代理採取一千個小而經過檢查的步驟，比要求一個偉大的代理邁出完美的一步走得更遠。

提示產生一個工件。迴圈產生一個過程——一個在你睡覺時仍在工作、拒絕交付未透過檢查的內容、並在完成時誠實告知你的過程。

上述八個模式現已釋出在 SkillDB 上，每個都包含哲學、迴圈圖、可執行驅動、來之不易的陷阱以及確保安全的精確門控。讓你的代理指向 Agentic Loops 包，給它一個迴圈去執行吧。