AI 代理迴圈：自我糾錯的編碼代理如何把活幹完

大多數人用 AI 編碼代理的方式，至今仍像在打乒乓球。你發提示，它回答，你發現哪裡不對，再發提示。你成了那臺糾錯機器，每一回合都得守在迴圈裡。

迴圈把這一切反了過來。你描述想要什麼，代理開始幹活，自己寫檢查清單，自己找薄弱環節，反覆執行直到結果靠得住。你不再是那個去抓錯誤的人，代理抓自己的錯誤。

這種轉變不是炒作。打造這些工具的人都在依賴它。Claude Code 的創造者 Boris Cherny 和 Cat Wu 談的就是在代理迴圈裡寫程式碼。給「Ralph loop」起名的 Geoffrey Huntley，則讓代理在一個樸素的 while 迴圈裡跑一整夜。如今這個模式有了名字，在你照搬 Instagram 上那三條提示之前，值得先把它弄明白。

從提示乒乓球到迴圈

單條提示是一次性的。你問，得到一個答案，這筆交易就結束了。想讓它變好，你得先察覺到差距，再發一次提示。把這一套放大到一個真正的功能上，你就是在手動做幾十次微調。

AI 代理迴圈把這道差距收進了代理內部。你定一個目標，代理規劃、行動、檢視結果、糾錯，一遍又一遍，直到目標達成。你沒有消失，你在最後做審閱。但你不再是每一次迭代上的瓶頸。

提示乒乓球讓你每回合都待在迴圈裡。真正的迴圈把代理放進去。

一個 AI 代理迴圈到底是什麼

每個代理迴圈都跑同樣的四拍：規劃、行動、觀察、糾錯。代理決定下一步，把它做了（寫程式碼、跑命令、讀檔案），看看發生了什麼，再調整。Claude 寫程式碼，跑測試，看到失敗，修復，再跑測試。這個反饋就是全部訣竅所在。正是它讓迴圈變成自我糾錯，而不只是重複。

迴圈最強的版本，會把這幾拍拆給三個角色：一個負責規劃，一個負責建置，一個負責審閱。把它們分開，才能阻止代理在寫下答卷的同一口氣裡給自己的作業打分。

今天就能照搬的三命令迴圈

下面是眼下流傳的那套做法，重新拆成三條 Claude Code 斜槓命令。每條貼一次，代理就會建立對應命令，然後你按順序執行它們。

規劃者，/spec：

一次問我一個問題，直到你完全理解我想要什麼。
然後把一份精確的計劃寫進 specs/project.md：目標、確切的
需求、邊界情況，以及哪些在範圍內、哪些在範圍外。
寫得簡短犀利，別寫成長篇小說。

建置者，/build：

讀 specs/project.md，嚴格按它描述的來建置，不多做。
做完後，列出計劃裡的每一條需求，標明你覆蓋了
哪些。

審閱者，/review：

把建置出來的東西和 specs/project.md 逐條需求對照。
對每一條，說明它是否被覆蓋。寫出需要的修正，
交回給 /build。只有整個計劃都被覆蓋時才放行。

三條命令，一個迴圈：spec 寫計劃，build 實現它，review 拿它和計劃對照並把修正交回給 build。它會一直迴圈，直到每條需求都被滿足。

計劃是唯一的事實來源。審閱是拿建置去對照它，而不是對照一種感覺。

這底層就是 spec-driven coding：用來約束代理的是寫下來的 spec，而不是聊天記錄。GitHub 的開源 Spec Kit 用 /specify、/plan、/tasks 和 /implement 把同一個理念正式化，而且它在 Claude Code、Copilot、Cursor、Codex CLI 和 Antigravity CLI 上都能跑。

為什麼全新上下文能讓迴圈奏效：Ralph loop

2025 年年中，Geoffrey Huntley 給這套思路最直白的版本起了名：Ralph loop。它的想法是用一個樸素的 shell 迴圈，對著一份寫好的 spec 一次次把同樣的提示餵給代理，讓它挑一個任務並交付，然後啟動一個上下文全新的代理，再把一模一樣的提示喂進去。

while 還有待辦; do
  agent --prompt "處理 todo.md 裡的下一個任務" --non-interactive
done

不那麼直觀的地方，是上下文的重置。長會話會腐壞：視窗裡塞滿了舊的推理、走過的死衚衕和過時的檔案內容，模型會悄悄開始丟掉指令。每一次 Ralph 迭代都是一個全新的代理，它從磁碟讀取當前的程式碼庫和待辦清單，做完一個工作單元，提交，乾淨退出。Huntley 故意拿《辛普森一家》裡的那個角色給它命名：它看起來蠢到不可能管用，但它就是管用。如果你見過一段長會話開始產生幻覺，你已經懂為什麼一個全新的視窗勝過一個臃腫的視窗。

Claude Code 的 /loop 和 /goal

Claude Code 直接內建了迴圈原語。/goal 設定一個持久的終態，也就是「完成」長什麼樣，Claude 在每一輪過後都會對照它來評估進度，而不是隻跑下一步。/loop 按某個節奏重複一個任務，或者重複到某個條件成立為止，形式有 /loop every 10m 或 /loop until: <condition>。兩者一起用，就構成了一個自我驅動、自我終止的迴圈：Claude 一直處理當前狀態與目標之間的差量，在目標被滿足或你按 Ctrl+C 時停下。

關鍵細節是：迴圈保有連續性。它記得自己試過什麼、為什麼失敗，所以每一輪都建立在上一輪之上，而不是重複同一個死衚衕。這和 Ralph 那種清空上下文的重置是相反的取捨，兩者都成立。要緊湊的自我糾錯就用連續性，視窗腐壞了就用全新上下文。知道該出哪一招，才是真正的本事。

同一個迴圈，每家 provider 都有

迴圈不是 Claude 的某個功能，而是整個領域正在去往的方向。名字各異，形態如一。

公開場合裡，Codex CLI 把迴圈推得最遠。OpenAI 團隊把它的 /goal 描述為他們對 Ralph loop 的詮釋，而 a16z 的 Andrew Chen 讓它在一個裝置驅動上跑了一整夜，連續 14 小時無人干預。他也指出這會「讓 token 用量翻一萬倍」，這就是放任一個代理磨上大半天所要付出的、誠實的代價。

陷阱：迴圈會放大一切

迴圈放大的不只是好的產出，它也會放大一個糟糕的計劃。把一個自我糾錯的代理對準一份含糊的 spec，它會信心十足地建置出錯的東西，再拿它對照同一份含糊的 spec 來審閱，然後放行。計劃就是那根槓桿。一份犀利的 spec 省下十條提示，一份模糊的 spec 浪費一百條。

有兩種失敗模式要盯著。成本會失控：每一次迭代都燒 token，一個目標不清、又不設邊界的迴圈能燒掉很多。還有，迴圈可能永遠停不下來，要麼宣佈勝利，要麼去追一個它永遠滿足不了的目標。給它設界：一個清晰的 until 條件、一個 token 上限，或者在合併前設一個人工檢查點。一個不會停的迴圈不是自主，是失控狂奔。

這個人類檢查點提出了每個團隊最終都會爭論的問題: 你還應該審查你的AI代理的程式碼嗎，以及你根據什麼標準來判斷代理出錯了？

在一支機隊上執行迴圈

一個自我糾錯的代理，盯著它很容易。槓桿出現在你同時跑好幾個的時候，每個都在自己的任務上迴圈，而這恰恰是盯著一個終端開始撐不住的地方。

AgentsRoom 就是為此而生。它是一個多代理駕駛艙：每個代理都有一個角色、一個實時狀態點和自己的顏色，你從一個視窗裡監管整支機隊。往待辦板上丟一張工單，一個代理就會接走它，跑它的 plan-build-review 迴圈，再把一份乾淨的 diff 交給你。這就是落到實處的 spec-driven AI 編碼：工單就是 spec，代理跑迴圈，你審閱結果。

因為長迴圈會腐壞上下文，AgentsRoom 會替你盯著。每個代理在每一輪結束時寫一行狀態，當一個代理連續兩輪不再更新它時，就會彈出一條警告，附帶一個一鍵在全新上下文上重啟的按鈕，正是 Ralph loop 所依賴的那種全新視窗重置。想知道它怎麼運轉，去看上下文漂移檢測這一頁。

而且因為迴圈與 provider 無關，你不會被鎖死在某一家。一張工單跑在 Claude Code 上，下一張跑在 Codex 上，再一張跑在 Antigravity CLI 上，全在同一個儀表盤裡，每個都在自己的 git worktree 裡迴圈，讓並行的代理永不相撞。下班前把它們放出去，第二天早上審閱 diff，這正是後臺編碼代理和夜班的全部意義。

設一次目標，讓迴圈把它收尾，最後審閱。下載 AgentsRoom，檢視 provider 相容性矩陣，再讀讀關於按代理審閱和多 provider 支援的更多內容。