Agent Loop Pattern

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• CS329A Self-Improving AI Agents — Part 1: Course Overview
• Full Walkthrough: Workflow for AI Coding — Matt Pocock
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)

摘要#

迴圈是一種代理程式流程，會重複執行提示，直到佇列清空或達到停止條件。到 2026 年年中，有三種逐漸匯聚的實作方式顯示，迴圈正成為與單次工作階段同等地位的基本原語：Anthropic 的 /loop 斜線指令（依 cron 排程、重複執行）、Anthropic 的例行程序（伺服器端的 /loop），以及 Matt Pocock 的 Ralph Wiggum 迴圈（以 bash 搭配 claude --permission-mode accept-edits 在 while 迴圈中執行）。Boris Cherny 稱迴圈是「未來」；Matt Pocock 則以迴圈作為端對端工作流程中 AFK 執行的骨幹。

兩種迴圈#

依 cron 排程的迴圈（/loop、例行程序）#

用於 Claude Code 和 Cowork。運作方式：代理程式呼叫 cron（透過工具）排定未來時間的工作；到時，該工作會帶著執行任務的指示重新進入代理程式。排程可以重複執行（每分鐘、每 5 分鐘、每天）。

Boris Cherny 提到的用途：

• 看顧 PR — 修復 CI、自動 rebase
• 維持 CI 健全 — 修復不穩定的測試
• 每 30 分鐘彙整一次 Twitter 回饋
• 「任何時候都有數十個迴圈在執行」
• 夜間：「幾千個代理程式」執行較深入的工作

例行程序是在伺服器上執行的相同基本原語，因此即使闔上筆電也會繼續運作。

清空待辦清單的迴圈（Ralph Wiggum 迴圈）#

由 Matt Pocock 等人使用。運作方式：Shell 指令稿以固定提示執行代理程式，提示指示它從待辦清單挑選下一項任務並完成，然後指令稿重新啟動。待辦清單是由 Markdown 問題檔案（或 GitHub issues）組成的目錄。

Pocock 的 once.sh 骨架：

issues=$(cat issues/*.md)
recent_commits=$(git log -5 --oneline)
prompt=$(cat prompt.md)
claude --permission-mode accept-edits "$prompt" --context "$issues" "$recent_commits"

「迴圈」包裝器只會不斷重新執行 once.sh，直到代理程式輸出哨兵字串（no more tasks），或由 harness 停止它。

提示會強制採用僅限 AFK 的任務選擇——只有標記為 AFK（而非 human-in-loop）的任務才符合資格。

迴圈為何重要#

1. 將規劃成本分攤到多次執行。 一次仔細的規劃工作階段（例如透過 Design Concept Grilling）建立 Kanban 待辦清單（見 Vertical Slice Tracer Bullets）；迴圈可在不需人類進一步輸入的情況下清空清單。
2. 讓需時數小時的任務變得可行。 迴圈將工作拆分成許多全新的工作階段，而非塞進一個巨大的上下文視窗；每次都能維持在 Context Window Smart Zone 內。
3. 平行化。 彼此獨立的待辦項目會同時在不同沙箱中執行。Pocock 的 Sandcastle 函式庫透過 Docker 容器中每個 issue 專屬的 git worktree 來完成這件事；之後由合併代理程式負責整合。
4. 利用閒置運算資源。 Boris 的夜間設定是在便宜的閒置時段執行上千個代理程式的迴圈——這些工作不值得人類花整個晚上處理，但以代理程式的成本執行卻能創造價值。

AFK 與 human-in-loop 任務#

Matt Pocock 的關鍵區分：

• AFK 任務 — 實作、重構、測試架構、文件整理、修復 CI。代理程式不需要逐步取得核准也能成功；驗證是自動的（測試、型別、linter）。
• Human-in-loop 任務 — 對齊、設計選擇、排定優先順序、QA。這些任務沒有機械式驗證方式，需要品味與默會脈絡。

迴圈適用於 AFK 類任務。試圖讓 human-in-loop 工作進入迴圈會造成偏離——代理程式會做出看似合理但實際錯誤的判斷，並不斷累積。

驗證能力是上限#

Pocock 更進一步主張：回饋迴圈的品質決定迴圈能力的上限。 沒有良好的測試、型別和 linter，迴圈就等於「盲目寫程式」。Agent Harness Engineering 也提出相同觀點，指出機械式強制執行的重要性——迴圈只是讓代價更明顯，因為沒有人能及時發現偏離。

與模型發展軌跡的關聯#

Boris Cherny 表示，Opus 4.7 會在沒有提示的情況下自發啟動迴圈：

「我會跟它說：『去查詢這筆資料。』然後它會說：『嘿，我注意到資料會隨時間變動。我會啟動一個迴圈，每 30 分鐘給你一份報告。』」

這符合 Harness Shrinkage as Models Improve 的說法——過去需要由 harness 注入的能力，逐漸成為模型的自然行為。迴圈原語仍然存在，但使用者不再需要主動呼叫它。

2025 年底的基準：迴圈當時是例外，還不是預設做法#

值得記錄這個時間點，因為本頁的來源都來自轉變的另一端。Stanford 的 CS329A 第 1 講（CS329A Self-Improving AI Agents — Part 1: Course Overview，於 2025-09-22 授課，practitioner-opinion）對迴圈的定義與本頁相同——目標、計畫、對環境採取行動、回饋、修正，以及決定何時停止（或回頭說明目標無法達成）；工具和記憶則由目標衍生——但講者接著指出，當時幾乎沒有人在執行這種迴圈：

「在大多數情境中，工作流程仍然非常靜態……對開放式問題而言，手動建構一張圖來描述人類會怎麼做比較容易。」

一年前的實務狀態是手工打造的工作流程圖——也就是 Building Effective Agents 的模式，講座列出的項目包括提示串接、路由、平行處理與彙整、協調者搭配工作者、評估者／裁判，以及驗證器；開放式迴圈只在兩個領域出現「生命跡象」：程式碼代理程式和深度研究。甚至連程式碼迴圈都還很新：終端機迴圈（瀏覽儲存庫、搜尋檔案、檢視／編輯、執行指令、閱讀輸出、決定下一步要改什麼）「去年還不太可靠，而現在才剛開始變得可靠」。

有兩點讓這個觀察成為有用的指標，而不是過時的說法：

• 講師將變化歸因於模型，而不是 harness。「我認為整個典範基本上相同。主要是模型能力更強了，然後是更好的 RL 搭配可驗證的獎勵。」這是從轉變的另一端預測 Harness Shrinkage as Models Improve——而 Agentic Loops Overtake Bespoke Systems 後來也以形式化數學確認了同一個因果脈絡：隨模型進步，簡單迴圈追上了客製化系統。
• 關鍵變數正是本頁已指出的那一項。 迴圈恰好只在兩個能低成本取得回饋的領域出現生命跡象——程式碼的測試，以及研究中擷取的來源；這正是上文所說「驗證能力是上限」的觀察，只是呈現為部署邊界，而非品質界線。

相關連結#

• CS329A: Self-Improving AI Agents (Stanford) — 2025 年底的基準：靜態手工打造的工作流程圖是常態，開放式迴圈僅限於程式碼和深度研究
• Claude Code Best Practices — 最佳實務指南將 /loop 視為核心工作流程原語
• Engineer PM Convergence — 通才型 PM 工程師透過迴圈分派工作
• Boris Cherny — 主要倡議者，也是日常使用者
• Matt Pocock — Ralph 迴圈與 Sandcastle 的代表案例
• Harness Shrinkage as Models Improve — 迴圈成為新一代原語，取代逐步提示
• Context Window Smart Zone — 為何拆成許多全新工作階段勝過一個漫長工作階段
• Vertical Slice Tracer Bullets — 填入迴圈所清空之待辦清單的內容
• Design Concept Grilling — 讓迴圈合理化的規劃步驟
• Deep Modules for Agents — 具備明確測試邊界的模組讓迴圈得以運作
• Agent Harness Engineering — 推廣「驗證能力是上限」這項觀點
• Symphony — 編排層中由常駐程式驅動的對應做法
• Claude Code Auto Mode — 權限分類器，讓 accept-edits 模式能安全地用於 AFK 迴圈
• Agentic Misalignment (AM) — 迴圈加上薄弱的逐動作監督，正是 AM 的威脅面；迴圈審查者仰賴模型端的對齊在無人值守時仍然有效
• AI Brain Fry — 人類面對產出倍增的限制：迴圈產出增加 → 審查增加 → 認知疲勞增加 → 漏掉更多錯誤
• Human-AI Accountability Redesign — 迴圈迫使我們重新思考問責方式；無人值守的迴圈部署還缺少控制幅度的重新設計
• AI-Driven Formal Proof Search — DeepMind 的基本證明搜尋代理程式實際上就是「Ralph 迴圈」（huntley2025ralph）：反覆執行產生→編譯→吸取教訓，並以獨立子代理程式平行執行
• AlphaProof Nexus — 其基本代理程式 (A) 是由 Ralph 迴圈組成的代理程式群；它在多數問題上追平了客製化系統
• Agent-Native Infrastructure — 透過感測器／致動器持續運作的迴圈，是 Karpathy 代理程式原生世界的執行環境
• Stopping Under a Noisy Verifier — 實測案例指出這項原語的兩種預設停止條件有何問題。在 Wu 等人的壓力測試設定中，回合上限（「最多修復 K 次」）是可部署方案中最差的一種——真實有效率為 0.116，相較之下，提交第一版草稿為 0.700，而且效能會隨預算增加而單調下降；代理程式輸出的哨兵字串也只能和背後的驗證器一樣可靠，而驗證器的辨別能力會限制它能支持多精細的停止判斷。可轉移的規則是：停止邊界應由改寫工作內容的機制決定，而非由檢查它的機制決定，因此它是 α/(α+β)；移植到不同迴圈時，其表現不會比這兩個比率更好
• Loop Engineering — 比此原語再高一層的系統設計方法（Osmani／Steinberger）：自動化是迴圈定時執行的心跳，而 /goal（持續執行直到符合明確寫下的條件，並在每一輪結束後由另一個小型模型檢查是否「完成」）則是將製作者／檢查者的分工套用到停止條件本身
• The Three Loops of AI-Native Building — Andrew Ng 的分類指出此原語的位置：它完成三個巢狀迴圈中最內層的迴圈，外層的開發者回饋與外部回饋迴圈則慢 1–2 個數量級
• Dynamic Workflows: An Algebra for Agents — 與此並列的原語，適用於單一大型任務，而非重複任務：工作流程會安排不同階段的代理程式來完成一次執行；本頁的迴圈則提出「什麼時候再次執行？」這個問題
• Reasoning–Acting Interleaving (ReAct) — 迴圈內部的交替運作，以及它的起源。ReAct 是在單次執行中一次進行一組思考／行動／觀察；本頁的迴圈探討的是外層問題：何時重複整次執行，以及什麼條件會使它停止。CS329A 第 4 講也為此原語作了註解：交替機制如今已濃縮進思考模型，因此過去用來強制這種機制的 harness 已不再必要

待解決的問題#

• 當模型為自己排定迴圈（4.7 的行為）時，由誰負責預算？Boris 的回答是「模型自己決定」——但這等於把成本紀律交給模型訓練，而非 harness。
• 如果模型夠聰明，迴圈還需要 Kanban 待辦清單嗎？還是模型會直接從原始目標中自行選擇下一項任務？
• 迴圈產出的審查現在成了 Matt Pocock 坦承的瓶頸——「我們只需要準備好做更多程式碼審查。」

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next — /loop 和例行程序作為主要原語
• Full Walkthrough: Workflow for AI Coding — Matt Pocock — Ralph 迴圈與 Sandcastle 架構
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — 功能層級的迴圈（修復 CI、程式碼審查）
• CS329A Self-Improving AI Agents — Part 1: Course Overview — Stanford CS329A 第 1 講（Azalia Mirhoseini 與 Aakanksha Chowdhery，於 2025-09-22 授課、2026-08-03 發布，practitioner-opinion）：目標／行動／回饋／停止的定義、工作流程模式分類，以及 2025 年底靜態手工打造的圖仍是常態的發現