在 AI 編碼圈之中，有一個說法一直在流傳：別再對你的編碼 Agent 下提示詞了，開始設計能替你對它們下提示詞的循環吧。跟所有新鮮事物一樣，這套說法經常被重複，卻鮮少被解釋。以下就是實戰版本：什麼是 Agent 循環、它為何重要、以及一個投入生產環境的循環長什麼樣子。
下方是我（在 Claude 的協助下撰寫）從一些實驗、研究和與我們部分 學員、技術創辦人、AI 工程師和新創公司的對話中，整理出的一些想法。
你可能也會發現我們最近關於「[自主長期運行的編碼 Agent*](https://academy.dair.ai/events/cmplo7v3b000e04l1pxprat4d)」的線上課程，是一個很好的起點。
這個說法的來源
「你不該再對編碼 Agent 下提示詞了。你應該設計能對你的 Agent 下提示詞的循環。」Peter Steinberger (
@steipete ), 2026 年 6 月 7 日。觀看次數 220 萬。
Claude Code 的創造者 Boris Cherny，也從另一個角度提出了相同的觀點。
「我不再對 Claude 下提示詞了。我有正在運行的循環。是它們在對 Claude 下提示詞，並決定下一步該做什麼。我的工作是撰寫循環。」Boris Cherny (
@bcherny )。
關鍵不在於提示工程已死。透過循環工程，工作層級提升了一層，從撰寫程式碼，轉變為撰寫會寫程式碼的系統。走得最遠的開發者們回報，他們在好幾個月內，從未打開過 IDE 就送出了數百個 PR，每一行程式碼都是由 Agent 撰寫的。
循環到底是什麼
一個循環，就是你撰寫的一個小型程式，它會做四件事：
- 替你對編碼 Agent 下提示詞，
- 讀取它產出的結果，
- 判斷它是否完成，
- 如果還沒完成，就將錯誤或下一步指示再次下給它。
你不再坐在循環裡手動輸入提示詞；你撰寫這個循環，然後模型就變成它呼叫的一個子程式。
它的結構始終如一：設定目標、行動、檢查、回饋錯誤，然後重複，直到檢查通過或循環自行停止。
「循環」至少代表五種意思
許多歧異來自於人們用同一個詞來表達五種不同的概念。以下是從舊到新的演進過程。
- ReAct (2022 年)。 原始的研究模式：推理、行動、觀察、重複。
- AutoGPT (2023 年)。 一種自我提示的目標循環，因不知道何時該停止而惡名昭彰。
- ralph 循環。 在兩次疊代之間特意重置上下文，避免 Agent 淹沒在自己過往的歷史記錄中。
- /loop 與 /goal。 節奏和完成條件直接內建在 Agent 中，讓狀態能在不同輪次間延續。
- 編排。 一個作者可以調度多個 Agent，這些 Agent 會讀取你的 GitHub、Slack 和聊天記錄，並決定下一步該建構什麼。
你實際需要組裝的零件
前述的演進解釋了人們所指的「循環」是什麼意思；而以下是循環實際的「建構元件」。每次都會出現相同的六個部分，而且現在大部分都已經內建在編碼工具中，不再需要你自己撰寫腳本來維護。
- 一個觸發器。 某個能啟動循環，而無需你手動按下「開始」按鈕的東西：一個排程、一個 Webhook、一次檔案變更、或是 PR 上被加上了一個標籤。這就是一個真正的循環，與你需要手動重複執行的單次運行之間的區別。
- 隔離。 每個 Agent 都有私有的檢出環境，通常是透過 git worktree，這樣兩個同時執行的 Agent 就不會互相覆蓋彼此的檔案。一旦你同時運行超過一個 Agent，這就不再是選項，而是必需。
- 書面化的上下文。 編寫慣例、建置步驟和專案特定規則，都存放在 Agent 每次運行時都能讀取到的地方。忽略這點，循環就會在每次執行時，從頭推導你的專案，並憑空猜測缺漏的部分。
- 與你的工具連結。 連接到問題追蹤器、CI、資料庫和聊天系統的連線器，讓循環可以自動開立 PR、關聯工單、並發布結果，而不是只印出一個修正方案，然後等你來完成後續步驟。
- 由第二個 Agent 進行檢查。 一個獨立的工作者被指派來評估輸出內容，與產出它的 Agent 完全分開，因為讓模型審查自己的工作，它幾乎什麼都會通過。
- 磁碟上的狀態。 一個 Markdown 檔案、一個專案清單、或是一個佇列：任何存在於對話之外，能記錄哪些已完成、哪些是下一步的資料。模型會在每次運行之間遺忘；但檔案不會。
組裝好這六個部分，你就為循環工程打下了一個良好的基礎。過去你必須親手建構一切；現在大部分功能都已內建，這也是這個模式能從邊緣技巧轉變為常見方法的原因。
一個具體的循環：PR 保姆
一個你今天就能建構的具體範例：
- 觸發器。 每 15 分鐘。
- 範圍。 被標記為 agent-watch 的已開啟 PR。
- 行動。 如果 CI 因某個可確定的原因顯示紅燈，則嘗試修正一次。如果主分支有更新，則 rebase 一次。
- 預算。 每個 PR 嘗試修正一次，時間上限五分鐘，最多改動十個檔案。
- 停止條件。 CI 變綠，或預算耗盡，然後停止並通知人類。
最終，你只會看到被合併的 PR，而不是堆積如山的失敗建置。同樣的模式可以套用於大部分維運工作：
- CI 健康狀態。 每 30 分鐘，擷取失敗的運行，並根據其特徵進行分組，這樣十個紅燈 PR 如果根源相同，就會被歸納為一個需要查看的事項。
- 部署驗證。 在推送之後，檢查你的端點，確認回傳 200 狀態碼和預期內容，在使用者發現之前就標記出回歸問題。
- 意見回饋分群。 每 30 分鐘，從你的頻道中擷取評論，將其歸納成不同主題，並將每個群組對應到負責該議題的檔案或文件。
一個具體的 Claude Code 循環搭配 /goal
PR 保姆是一個你需要自己串接的循環；但了解一個內建在 Agent 中的循環也很有幫助。在 Claude Code 中，最簡單的完整循環就是 /goal：你給它一個可驗證的最終狀態，它會持續執行，直到該狀態為真。
以下是一個在 Claude Code 中，將 /goal 作為會話內指令使用的範例。你啟動會話，然後在會話內設定目標：
1$ claude # 啟動 Claude Code2$ /goal tests in test/auth pass # 在會話內設定目標
它與前面提到的「行動、檢查、重複」模式相同，並內建了驗證器。
到目前為止，很明顯一個好的 /goal 讀起來更像一份合約，而不是一個提示詞。好的 /goal 會指定四件事：你想要的最終狀態、能證明你已達成狀態的證據、Agent 在達成過程中不得違反的限制、以及它被允許花費的工作預算。只要其中任何一項定義模糊，模型就會用最簡單的方式解讀來填補空缺：它可能會提早停止、走捷徑、或重新定義成功，使得記錄看起來像是完成了，但實際系統卻壞掉了。
- 設定條件。 輸入 /goal 加上一個可檢查的最終狀態，例如：/goal tests in test/auth pass。第一輪會立即開始。
- Agent 執行一輪。 它會編輯程式碼、執行測試，並將會話中的結果呈現出來。
- 評估者進行檢查。 一個快速的模型會讀取會話記錄，判斷目標是「已達成」或「未達成」，這樣 Agent 就不會自己為自己的工作打分數。
- 循環或結束。 「未達成」會觸發下一輪，並附帶引導；「已達成」則表示目標已完成，運行終止。
狀態會在輪次之間延續，因此它不會過早退出，也不會在中途放棄某個限制條件。以下幾個控制措施能讓它保持可靠：
- 讓檢查結果可衡量。 一個測試結果、一個結束代碼、一個檔案數量、或是一個空的佇列。
npm test exits 0是一個目標；「讓它變得更好」則不是。 - 設定運行邊界。 加上類似「或在 20 輪後停止」的條件，這樣卡住的循環就會停止，而不是無限消耗輪次。
- 搭配自動模式，讓輪次能無人值守地運行，並使用 /goal clear 來提前放棄目標。
評估者這個步驟隱藏了一個有用的微妙之處：檢查者不需要與編碼者使用同一個模型。一旦循環有了不同的角色（規劃者、執行者、評估者、視覺審查者），每個角色都可以由不同的模型來執行，而選擇哪個模型來扮演哪個角色，就變成了一個架構決策，而不是單純賭一個「最好」的編碼 Agent。有些模型比較擅長規劃，有些執行起來成本更低，有些則能更準確地判斷螢幕截圖。一個好的編排器讓你能夠根據角色來更換模型，而不是等待某一個供應商在所有類別中都取得勝利。
這個模式在以下場景中效果很好：API 遷移（移動每個呼叫點直到編譯通過且測試通過）、重構（拆分一個檔案直到每個模組都在預算內）、處理問題待辦清單（處理已標記的佇列直到清空），以及評估循環（調整提示詞直到分數超過門檻）。/loop 則是針對沒有單一終點的工作的對應方案：它沒有完成條件，而是根據排程重新下提示詞，這正是像 PR 保姆這樣的循環能持續運作的方式。
同時運行多個無人值守的循環
一個單一的 /goal 循環，是一個 Agent 朝著一個目標努力。同時運行多個無人值守的流程，風險會更高，因為一個循環的可靠性，完全取決於它檢查自己工作的能力。Cherny 設定讓 Opus 自主運行數小時的方法，可以歸結為五個步驟：
- 自動核准權限，這樣 Agent 就不會在每次呼叫工具時停下來詢問。
- 使用動態工作流程（將 Ultracode 放入提示詞中），將任務分派給多個 Agent，而不是走單一的序列執行緒。
- 使用 /goal 或 /loop 讓它持續運作。/goal 設定了完成條件，/loop 則根據排程重新下提示詞，兩者都會延續狀態，所以它不會過早退出。
- 在雲端（桌面或行動應用程式）運行，這樣即使你關上筆電，會話仍然繼續。
- 給它一整套的自我驗證方式。 在 Chrome 中運行 Claude 來測試網頁，使用模擬器 MCP 來測試行動端，以及一個真實的伺服器來測試後端。這一步驟是讓其他四個步驟安全無虞的關鍵。
完整的順序：
1claude --permission-mode auto # 1 · 無需核准提示2ultracode orchestrate sub-agents to ship the feature # 2 · 任務分派3/goal all tests pass and the demo loads clean # 3 · 持續運行4→ cloud / desktop app # 4 · 關上筆電5→ chrome ext · sim MCP · live server # 5 · 自我驗證，然後停止
crabfleet：作為產品的編排功能
透過一個具體的工具，編排功能會更容易理解。Peter Steinberger 的 crabfleet 是一個 OpenClaw 專案，被稱作「Agent 運行的任務控制中心」，它是一個被打包成產品的循環，而其結構與上述所有內容完全對應。
- 工作就像專案上的卡片。 任務以卡片的形式輸入，這些卡片可以由一個提示詞、一個 GitHub Issue 或一個 PR 建立，然後會經過「待辦」、「運行中」、「人工審查」和「已完成」等階段。這個專案就是循環的佇列，也是其「停止並回報」的步驟，並以可視化的方式呈現。
- 持久運行，而非「發送後就忘記」。 每次運行都是一個帶有心跳訊號的可追蹤嘗試，因此當你移開視線時它仍會繼續，並且在關上筆電後依然存活。你只有在運行時提供支援交接功能時，才會接手控制。
- 能夠衍生其他 Agent 的 Agent。 一個運行可以在沙盒內啟動子會話、發送訊息、讀取執行記錄、並更新其自身的摘要：磁碟上的記憶體和任務分派功能被整合在一起，一個作者可以操控多個 Agent。
它運行在可拋棄式的雲端沙盒中，並提供基於瀏覽器的終端機，這正是讓你能安心離開無人值守運行的關鍵。重點不在於這個特定的工具，而在於循環已經被固化為基礎設施：一個佇列、持久化執行、任務分派、以及一個人工審查關卡，這些都變成了你可以配置的項目，而不是每次都需手動編寫腳本。
成本現在花到哪裡去了
過去兩年，AI 編碼的成本問題很簡單：哪個模型，以及多少個 token。在一個循環內部，這個直覺會指引你到錯誤的層面。花費不再取決於單次呼叫，而是循環需要運行多少次。因此，一個需要重試六次才能收斂的循環，其成本是第一次就成功的循環的六倍，即使使用的是同一個模型。
這改變了什麼值得優化：
- 疊代次數才是預算項目，而不是 token。 一個比較便宜的模型，如果運行次數多了一倍，並不代表更便宜。所以，請追蹤「每個完成任務的成本」，而不是「每次呼叫的成本」。
- 一個薄弱的驗證器是你可能導入最昂貴的錯誤。 如果決定「完成」與否的檢查條件很寬鬆，循環可能會在已損壞的工作上過早停止，或是在已經沒問題的工作上繼續努力，兩者都會浪費整個疊代。優先強化這個部分，勝過任何其他事情。
- 快速失敗是一種成本控制。 一個沒有連續失敗次數上限的循環，最終並不會成功；它最終只會耗盡你的帳戶。因此，停止條件不僅保護程式碼庫，也保護你的帳單。
過去你調整的是提示詞；現在你調整的是循環，因為成本就是在這裡累積的。
何時不該使用循環
循環在任務重複、且機器能判斷任務何時完成時，才能發揮價值。除此之外，循環只會將混亂自動化。在以下情況中，請跳過它：
- 一次性修改。 如果你能在一輪內完成，那麼使用循環就是純粹的負擔。
- 無範圍或探索性工作。「找出用戶流失的原因」沒有通過條件，因此循環永遠無法收斂。
- 任何沒有低成本自動化檢查的事情。 如果唯一的驗證者是你自己的眼睛，那麼你仍然身處在循環之中。先建立檢查機制，否則就手動完成任務。
可能出什麼錯
一個在你睡覺時運行的循環，也會在你睡覺時犯錯，而其失敗模式是可以預測的。
- 驗證負擔仍由人類承擔。 循環寫程式碼的速度比你審查的速度快，所以如果你停止閱讀 diff，你並沒有移除這項工作，只是將其延後。
- 理解差距擴大。 以你無法吸收的速度，送交不是你寫的程式碼，會侵蝕你對自己系統的理解，而這筆債會在下次事故發生時到期。
- 寬鬆檢查下的無聲偏移。 一個薄弱的驗證器，會在每次疊代時讓錯誤但通過檢查的工作流入，使得循環看起來生產力旺盛，但同時卻在挖坑。
這些都不是反對使用循環的理由；而是為什麼設計循環的工程師變得更重要，而非更不重要。
如何建立你自己的循環
- 選擇一個可重複的任務。 照顧 PR、修復 CI、驗證部署：從例行工作開始。
- 嚴格界定範圍。「修復計費 Webhook 的驗證，只觸及 app/api/billing 和 lib/billing」勝過「修復這個 bug」。一個範圍寬鬆的循環會到處遊蕩。
- 給它預算和停止條件。 最大嘗試次數、最長運行時間、最多檔案數、最大花費、最大連續失敗次數。一個無人值守的循環，同時也是在無人值守的情況下犯錯的循環。
- 加入獨立的驗證器。 由一個獨立的子 Agent 來評估工作，因為撰寫程式碼的 Agent 是最差的裁判，無法判斷工作是否完成。
- 設定一個規律的節奏。 使用 /loop 設定間隔、使用 cron 設定排程、在生命週期節點設定鉤子、或是使用 GitHub Actions，這樣即使關上筆電也能繼續運行。
- 將記憶保存在磁碟上。 模型會在每次運行之間遺忘，所以狀態應該存放在 markdown 檔案或專案中，而不是放在上下文視窗裡。
重點是：現在，昂貴且容易出錯的部分是循環，而不是模型。像一個對輸出成果負有責任的工程師那樣去建構它，而不僅僅是啟動運行的人。
如果你發現任何錯誤或需要進一步釐清的地方，請隨時提出。
