迴圈工程：Claude Code迴圈、例行程序與工作流程

摘要：Loop engineering 是讓代理程式反覆執行工作循環，直到符合停止條件為止的實務方法，而非每次只提示代理程式執行一個回合。Claude Code 的創作者、Anthropic 的 Boris Cherny 直言不諱地描述自己的工作流程：「我已經不再提示 Claude。現在有多個迴圈持續運作，由它們提示 Claude，並判斷該做什麼。我的工作就是編寫迴圈。」¹ Claude Code 如今提供完整且層次分明的迴圈介面，包括 /goal（重複執行，直到另一個模型確認已符合條件）、/loop（定期在本機執行）、官方 Ralph 外掛（持續反覆運作，直到兌現承諾）、routines（雲端 cron），以及動態工作流程（Claude 會撰寫 JavaScript 協調圖，並透過該圖執行最多 1,000 個 subagents）。然而，真正支撐整套方法的並非上述任何功能，而是驗證。唯有由「生成器之外」的機制——例如測試、評分模型、像素差異比對或機器檢查——判定「完成」，迴圈才會收斂。驗證得當，迴圈的效益便能層層累積；驗證失準，換來的只會是一場代價極高的隨機漫步。本指南將說明各種迴圈介面及其版本依據、Ralph 模式與失敗情境、何時應將迴圈升級為圖形工作流程、驗證階梯、成本與安全規範，以及如何維運常駐的代理程式叢集。內容更新至 Claude Code v2.1.234（2026年8月）。

什麼是 Loop Engineering？

兩年前，工程師仍親手撰寫原始程式碼。之後，agents 開始根據人類的提示撰寫程式碼。如今正在發生的轉變又高了一個層次：agents 提示 agents，而人類負責編寫「決定要提示什麼內容的系統」。Cherny 直言這次跨越的幅度：「從原始程式碼跨越到 agents 是多麼重大的進展，loops 就同樣重要，也是同等幅度的跨越。」²

他的定義出奇地平實：「Loop 本質上就是在本機針對 Claude 執行的 cron job。Routine 也是同樣的東西，只是改在雲端執行。」³ 這種聽來新奇的實務——一夜之間讓「數百個、有時甚至數千個 agents 執行 5、10、20 小時」⁴，以及 Claude Code「超過 6 個月來完全由 Claude Code 撰寫」⁴——其實可歸結為幾個簡單的基本要素：依排程或條件重新觸發的提示、在迭代之間持續保留的狀態，以及結束執行的檢查機制。

Anthropic 於 2026年6月為這門實務命名：loops 是「agents 反覆執行工作週期，直到符合停止條件」，而且「loop 的輸出品質取決於其周邊系統」。⁵ 本指南探討的正是這套周邊系統。

由於相關論述在 2026年中快速演變，這裡補充一則出處說明：「graph engineering」一詞常在病毒式傳播的貼文中被歸於 Cherny，但其實是由社群創造（Peter Steinberger 於 7月18日發文表示「我們還在談 loops，還是已經轉向 graphs 了？」，隨後經 Hamel Husain 推廣），並非出自 Anthropic 或 Cherny。⁶ 廣為流傳的「我們 85% 的工程師……實現方法就是 graph engineering」這段話，僅見於第三方貼文。編寫本指南時，我們未能在他的任何第一手演講紀錄中找到這段內容（包括 YC Startup School 對談、Bloomberg 的 Odd Lots，以及 TechCrunch 的 Meta @Scale 報導），因此應將其視為尚未證實的歸屬。他的實際做法確實呈現 graph 結構（orchestrators 產生 implementer/verifier/fixer subagents，最多巢狀至第 5 層），但經證實的用語是 loops、routines 與 workflows——本指南也將沿用這套詞彙。

5 分鐘黃金路徑

只需 3 個指令，即可從 prompting 進入 looping：

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud routine: runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

這些指令與一般提示的差異在於結構，而非表面形式：每一項都有一條重新觸發規則（條件、時鐘或 cron），也都需要一條停止規則。本指南其餘內容，都是為了讓這兩條規則值得信賴。

核心 Loop 與唯一準則

所有 agentic system 都遵循相同的內部循環；Anthropic 的 Agent SDK 文件將其定義為：蒐集脈絡→採取行動→驗證工作→重複執行。⁷ Claude Code 自身的流程也是一個 loop：評估提示、呼叫工具、讀取結果，反覆執行，直到回應不再包含工具呼叫為止。⁸

Loop engineering 是在這個內部循環之外再包覆外部 loops——同時繼承一項絕不妥協的準則，而此領域所有嚴謹來源都一再強調：

執行工作的 agent 絕不能為自己的成果評分。

• Anthropic 的 /goal 文件：「是否完成應由全新的模型判定，而非由執行工作的模型決定。」⁹
• Anthropic 的 harness 設計文章：「將執行工作的 agent 與評判成果的 agent 分離，證實是處理此問題的有力槓桿。」¹⁰
• Cherny 談實務工作者經常忽略的重點：「驗證很可能是大家最常做錯、同時也是最重要的一件事。」³ 他曾以一項歷時兩週、將 Electron 重寫為 Swift 的任務舉例，下達的指示是：「在 Mac 虛擬機器中執行 Electron 應用程式，擷取畫面，然後逐像素檢查。將它與 Swift 版本比較。在全部完成之前不要停止。」³

原因源自機制，而非道德：當模型被問及「您完成了嗎？」時，會展現正向自我評分偏誤；一份語氣篤定的逐字紀錄，也可能說服以模型判定的結束條件過早得出「完成」結論。¹¹ 唯有外部驗證——測試套件、編譯器、像素差異比較，或一個對答案沒有利害關係的全新模型——才能提供不受此影響的訊號。

自主性階梯

Claude Code 中的 loop surfaces 構成一座階梯，從「再次按下 Enter」一路提升至「無須您介入即可執行」。每一環都以更高的驗證負擔換取更多自主性：

（環級架構沿用 pardel.dev 於 2026年7月提出的分類法，這是目前對此領域最清楚的獨立梳理。¹¹）

這座階梯的紀律是：從能解決問題的最低環級開始，只有在該環級的驗證獲得證實後才向上攀升。 如果 /goal 無法將條件表述為可檢查的項目，就還不適合提升為 routine。

Loop Surfaces 詳解

（本指南涵蓋 loop surfaces 本身。Claude Code 指南是完整的 CLI 參考資料——包括設定、權限、hooks、MCP——而 Agent Architecture 指南則說明 harness 元件如何組合；loops 是運行於兩者之上的機制。）

/goal——evaluator-optimizer loop

/goal <condition> 會讓 Claude 持續工作，直到條件成立：「每一輪結束後，一個小型快速模型會檢查條件是否成立。若不成立，Claude 便會開始下一輪，而不會將控制權交還給您。」⁹ evaluator（預設為 Haiku）會回傳是／否及理由，供 Claude 作為下一輪的指引。它也能以 headless 模式執行：claude -p "/goal ..." 會持續執行 loop，直至完成。

撰寫要點：條件應該可以觀察（「測試通過」、「endpoint 回傳 200」、「TypeScript 錯誤為零」），而非流於願景（「程式碼很乾淨」）。模糊的 verifier 無法為 loop 指引方向——而且語氣篤定的逐字紀錄可能說服模型同意某個由模型判定的條件，因此只要有機器檢查可用，就應將其與 /goal 搭配。¹¹

v2.1.234 的兩項變更強化了 loop 本身。現在，如果某一輪因無法復原的錯誤而終止——例如驗證遭撤銷、點數餘額耗盡或 context overflow——goal 會顯示通知並自動清除，不會繼續對已無法運作的 session 保持啟用。此外，當背景工作讓 goal 等候超過 30 分鐘時，Claude 會主動檢查進度，而非無限期等待（可透過 CLAUDE_CODE_GOAL_CHECKIN_MINUTES 調整門檻；設為 0 則恢復原本永遠等待的行為）。³³

/loop——週期性本機執行

/loop [interval] <prompt> 會依排程重複執行提示：固定間隔（/loop 5m check the deploy）、自行調整節奏（Claude 根據觀察結果決定下一次延遲時間），或單獨使用 /loop 執行內建維護作業。底層使用 CronCreate/CronList/CronDelete（5 欄位 cron、每個 session 最多 50 項工作、7 天後到期）及 Monitor tool；後者會串流背景指令碼的輸出，而非反覆輪詢。¹² Cherny 自己的啟動範例是：「/loop babysit all my PRs. Auto-fix build issues and when comments come in, use a worktree agent to fix them.」¹³

真正關鍵的限制是：/loop 存在於您的 session 中。關閉終端機，loop 就會終止——這正是 routines 的用武之地。

Ralph plugin——反覆執行，直到兌現承諾

Anthropic 的官方 ralph-wiggum plugin 將社群最常用的暴力模式產品化：Stop hook 會攔截 Claude 結束 session 的嘗試，並重新注入提示，讓模型在同一 session 中持續迭代。使用 /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" 啟動；以 /cancel-ralph 中止。README 明確指出，--max-iterations 是「您的主要安全機制」——完全相符的字串比對可能永遠無法完成。¹⁴

Dynamic workflows——Claude 自行編寫 graph

Dynamic workflows 隨 Claude Code v2.1.154（2026年5月）推出，並於 Anthropic 在 2026年6月2日發布的文章中詳加說明。這是概念上幅度最大的躍進：「Claude 現在能即時編寫自己的 harness，針對手邊工作量身打造。」¹⁵ 您只要描述工作（甚至只需說「use a workflow」）；Claude 就會撰寫 JavaScript orchestration script——agent() 會產生 subagent，並可選擇使用 JSON-schema 輸出；pipeline() 讓項目依序通過各階段；一般的 await／loops／conditionals 則負責控制流程——再由 runtime 於背景執行。「workflow 將計畫移入程式碼……workflow script 自行保存 loop、分支與中間結果，因此 Claude 的 context 只會保留最終答案。」¹⁶

限制與結構如下：最多同時執行 16 個 agents，每次最多 1,000 個（「防止 loops 失控」），執行途中不接受使用者輸入；儲存至 .claude/workflows/ 的指令碼可成為重複使用的 slash commands；執行作業可透過快取的 agent 結果續接。¹⁶ 其代表性拓撲為 fan-out / refute / converge：先由彼此獨立的 finders 尋找答案，再由 adversarial verifiers 嘗試推翻每項發現，持續迭代，直到答案經得起反駁。發布文章中的主打成果，是 Bun 將 535,496 行的 Zig 程式碼庫移植到 Rust——產生超過 100 萬行的 Rust 程式碼庫——根據 Jarred Sumner 的說法，64 個平行 agents 在 11 天內（2026年5月3日至14日）完成此項工作。¹⁵

Agent teams——peer graph

此功能位於 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 之後（自 v2.1.32、2026年2月起進入 research preview）：由一名 team lead 加上多名 teammates 組成；teammates「各自在自己的 context window 中獨立工作，並直接彼此溝通」——這是一種 peer graph，而非 subagent tree。協調機制包括具相依關係的共用工作清單、檔案鎖定認領，以及每個 agent 各自的 mailbox。由 Hook 強制執行的 quality gates（TaskCompleted exit-code-2 會阻擋完成）則在 teammate 與「完成」之間加入機器檢查。¹⁷

Routines——在筆記型電腦關機後仍持續運作的 loops

Routine 是「儲存好的 Claude Code 設定：包含一個提示、一個或多個 repositories，以及一組 connectors；只需封裝一次，之後便能在 Anthropic 管理的雲端或您自己的 self-hosted runners 上自動執行」。¹⁸ 共有 3 種可組合的觸發類型：cron 排程（最短間隔 1 小時）、API 觸發（POST .../routines/{id}/fire），以及 GitHub 事件。可透過 /schedule 或 claude.ai/code/routines 建立。執行過程完全自主——不會出現核准提示——也正因如此，文件中的警語至關重要：綠色執行狀態「不代表提示中的工作已成功完成。請開啟該次執行、閱讀逐字紀錄，並確認 Claude 實際完成了哪些工作。」¹⁸

Anthropic 每天都會在自己的程式碼庫中執行「大約 20 或 30 個這類 routines」——包括清理無用程式碼、提升測試涵蓋率，以及發布實驗性功能。³

其他支援角色

Background subagents（自 v2.1.198 起預設啟用）讓委派的工作留在您的 context 之外；可透過 /agents 面板監控。Cross-session messaging（v2.1.224）透過 SendMessage 將彼此獨立的 sessions 串成 message-passing graph，其中的安全準則值得借鏡：來自另一個 session 的訊息「絕不等同於您的同意」。¹⁹ Self-hosted runners（v2.1.224，Team/Enterprise）可在您自己的機器上執行雲端 sessions 與 routines——這是組織級 agents 艦隊的底層基礎。²⁰

Ralph Pattern

社群率先採用了這套方法。2025年7月，Geoffrey Huntley 發表文章，並以《辛普森家庭》的角色為此技術命名：Ralph 實際上就是

while :; do cat PROMPT.md | claude-code ; done

——這是他發表時的原句——每次迭代處理一個儲存庫、一項任務，每一輪都使用全新脈絡；規格與進度檔案透過檔案系統在迭代之間傳遞狀態，測試與 lint 則充當「反壓」機制。²¹ 如今，同一模式的現代無頭形式是在 shell 迴圈中執行 claude -p "$(cat PROMPT.md)"；Anthropic 自己的 C 編譯器 harness 本質上採用的正是這種做法。²³ 他宣稱的成果（以價值 $297 的 token 完成一份 $50K 合約的 MVP；在黑客松一夜完成6個儲存庫）也伴隨著同樣明確的限制：僅適用於全新專案、預留位置與重複實作是反覆出現的失敗模式，而且「LLMs 反映的正是操作者的能力」。

Anthropic 從未在其工程資料中使用這個名稱，但此模式如今已兩度成為官方準則：2025年11月的長時間執行 agents 文章提出了完全相同的架構——由初始化 agent 建立功能清單與進度檔案，接著每個脈絡視窗都啟用全新的 coding agents，並「在工作階段開始時讀取進度備註檔案與 git commit 紀錄」²²——而2026年2月的 C 編譯器專案則並行執行16個 Claude agents。Nicholas Carlini 如此描述：「我打造了一個 harness，把 Claude 放進簡單的迴圈裡。」該系統以檔案式任務鎖定機制搭配 git 作為同步層，在約2,000個工作階段中產生約100K行 Rust，成本約為 $20K。²³ 文章中關於驗證的一句話，道盡了此模式的整套理論：「任務驗證器必須近乎完美，這一點至關重要。」

為何全新脈絡勝過單一長工作階段：隨著工作階段的脈絡逐漸填滿，效能會隨之下降——實務界普遍認為，約在100K tokens 後便會開始偏離——而壓縮摘要是有損的改寫，會將錯誤包裝成信心十足的文字。²⁴ Ralph 採用全新程序加上檔案的設計，巧妙避開了這兩個問題。（官方 plugin 的工作階段內迴圈為了便利性而犧牲了部分優勢；若需長時間執行，使用外部狀態的無頭形式仍是更穩健的模式。）

此模式的警世案例同樣值得借鏡：一位實務工作者以模糊的提示執行 plugin，並設定 max_iterations: 0——這代表的是無限次，而非停用——結果 Claude 向自己重複詢問同一個釐清問題1,966次，Stop hook 還劫持了此後的每一則訊息。²⁵ 迭代上限絕非可有可無。

當迴圈演變為圖形

單一迴圈假設各次迭代彼此獨立，或嚴格依序進行。一旦平行工作存在相依關係——例如任務 B 需要 A 的輸出，或兩個 agents 會編輯同一個檔案——自由形式的迴圈便會互相衝突，此時就需要明確的結構：包含相依性陣列的任務清單、檔案認領機制，以及合併規範。這正是迴圈與圖形之爭的實質內涵：單一儲存庫與單一目標使用迴圈；平行工作需要排序時則使用圖形。²⁶

圖形方案依基礎設施規模由小至大如下：

1. 動態工作流程——在 JavaScript 控制流程中表達相依關係；只有當某個階段確實需要先前所有結果時，才設置屏障。Anthropic 所列出的拓撲包括：扇出後綜整、對抗式驗證、產生後篩選、錦標賽（「生成 N 個 agents，讓它們各自使用不同方法嘗試相同任務」，再進行兩兩評判），以及持續迴圈直到完成。¹⁵
2. Agent teams——共用具備相依性追蹤的任務清單，並由 lead 核准計畫；圖形是資料，而非程式碼。¹⁷ 此模式下有一項預設值已經變更：自 v2.1.233 起，任務工具（TaskCreate/Get/Update/List、TodoWrite）在 Opus 4.8、Sonnet 5、Fable 5 及更新版本中預設關閉——文件明確指出，沒有 Task 工具的 agents「會透過訊息協調，而非使用共用任務清單」，因此在目前世代的預設設定中，任務清單其實悄然缺席。設定 CLAUDE_CODE_ENABLE_TODO_TOOLS=1 即可恢復此功能。³³
3. 外部協調器——社群用於橫向擴充的方案：Steve Yegge 的 Gas Town 讓20至30個 Claude Code 實例針對以 git 為後端的「beads」DAG 執行工作（依其自述，17天內寫出75K行 Go，同時也是一個「吞金怪獸」，而且對操作者能力要求極高）；²⁷ claude-flow/Ruflo（約31K顆星）以 queen/worker 階層封裝 swarms；LangGraph 類型的引擎則在上層加上具型別的狀態機，並將 Claude Code 放入各節點中。

Cherny 本人對此發展軌跡的正式歸納，是 Anthropic 於2026年7月發布的 AI 採用階段階梯：設有限制（0個 agents）→ 輔助（約1個）→ 平行（約10個）→ 受監督的自主運作（約100個，此時「大多數 agents 都由 Claude 啟動，而非由人類啟動」）→ AI 原生（1,000個以上）。他提出的建議是：「在每個階段……都必須找出並突破下一批瓶頸，同時建立下一批護欄。」²⁸

驗證工程

上述一切都只是管線。本節才是產品本身。

Anthropic 的升級階梯，依目前最佳實務文件所述：提供一項能產生通過或失敗結果的機制給 Claude，如此一來「迴圈便會自行閉合」→ 由獨立評估器重新檢查 /goal 條件 → 以 Stop hook 作為「確定性閘門」→「使用驗證 subagent，或採用會檢查自身發現的動態工作流程，再由全新的模型嘗試推翻結果，確保執行工作的 agent 不會同時為自己的成果評分。」²⁹ 與之相應的證據規範是：「讓 Claude 展示證據，而非只是聲稱成功。」

3類回饋，源自 Agent SDK 文章：規則式回饋（「為輸出明確定義規則，再說明哪些規則未通過及其原因」——這是最佳形式）、視覺回饋（螢幕截圖、像素差異），以及 LLM-as-judge（模糊的評分規準——用 Anthropic 的話來說，「通常不是非常穩健的方法」）。⁷ 應依此順序優先採用；只要確定性檢查確實存在，就勝過僅憑意見評判的 judge。

收斂條件。 對迴圈最犀利的批判性分析——Yoko Li 於2026年8月發表的分析——將收斂歸納為4項必要條件：明確定義的目標狀態、可觀測的目前狀態、精準的局部編輯，以及位於產生器之外的停止規則。她的儀器化實驗有一項數字值得銘記：迴圈所耗用的 token 中，有67%未帶來任何改善，因為沒有任何機制告訴迴圈，其報酬已呈對數遞減。³⁰ 預算上限不只是成本控制，也是最後一道停止規則。

測試完整性。 根據 Anthropic 的長時間執行 agents 準則：「移除或編輯測試是不可接受的，因為這可能導致功能缺失或錯誤。」²² 迴圈會鑽規格漏洞——通過可見測試，卻未滿足隱含意圖——因此驗證器本身也必須受到保護，不得由其所評判的 agent 任意修改。

評量結果，而非路徑。 根據 evals 文章：「評量 agent 產出的成果，而非其採取的路徑。」客觀項目使用程式碼式 graders，評分規準則使用模型式 graders，並進行校準：「除非閱讀多次試驗的逐字稿與評分，否則無從得知 graders 是否運作良好。」³¹

此外，多數討論還忽略了一項區別：當迴圈中的每項檢查都是確定性的，迴圈中根本不該出現模型。 比較時間戳記的偏移監視器、連結檢查器、建置哨兵——這些都應是排程執行的 shell scripts：零 token、每次執行只需數秒，而且結果完全可重現。只有當迭代需要判斷力時，才應使用模型驅動的迴圈。最便宜的迴圈，就是從不呼叫模型的迴圈。

成本與安全規範

社群對迴圈工程最強烈的反對意見是成本，而各種事後檢討案例也印證了這一點：生成 subagent 的錯誤在5分鐘內燒掉4M tokens；隔夜迴圈耗費數千美元；用量限制「比預期快得多」就已觸頂。³² 其中一道限制如今已經移動：自 v2.1.234 起，工作階段會在 claude.ai 用量限制重設後自動繼續（可在 /config → “Continue automatically at usage limit” 中關閉）——以往會在上限處終止的隔夜迴圈，如今會在用量視窗重新開放後恢復執行。這使下列預算控制更加重要，而非無關緊要。³³ 最終形成的規範如下，每一項都對應已推出的控制措施：

最後一列值得另闢一段說明，因為這正是最積極的實務工作者維持安全的方法：讓 pull request 成為影響範圍的邊界。 Cherny 長駐背景執行的 agents——一個持續改善架構，另一個持續搜尋重複的抽象層——會在無須人類觸發的情況下提交 PR；² 未經審查，任何內容都不會合併。若常駐迴圈最糟的結果只是「一個尚未合併的 branch」，便能放心高速運轉；若迴圈會直接寫入 main，則絕不可如此。應循序漸進地提升迴圈權限：先從僅觀察模式開始（產生報告，不進行寫入），在多次平淡無奇的執行中累積信任，再升級為提出變更——而且必須在安裝排程之前，先以書面完整記錄排序證明（「只有在驗證回傳新標記後，才執行清除」）與詳盡無遺的影響範圍聲明。此升級路徑的經濟效益，是 Loops Win Where Verification Is Cheap 一文的主題：決定哪些工作能夠無人監督執行的，是驗證成本，而非迴圈建構成本。

最深層的反對意見並非成本，而是審查能力——迴圈產生程式碼的速度，快過人類能夠進行實質審查的速度。³⁴ 對此沒有取巧的答案，只有誠實界定範圍：無人監督的迴圈，只適用於能由機器檢查驗證的工作，其他地方一概不宜。「若無法驗證，就不要發布。」²⁹

執行 Fleet

loop engineering 的最終形態並非單一 loop，而是一支常態運作的 fleet。當這套實務趨於穩定時，會呈現以下樣貌：

• 以檔案保存規格。 每個 loop 都是一份受版本控管的規格——包含名稱、層級、排程、目標、verifier、允許使用的工具、預算與逾時時間——並存放在其服務的 repo 中。若同一項手動檢查已執行 3 次，就應將其轉為規格。
• 兩種層級，憑實績晉升。 Observe loops 可讀取任何內容，但只能寫入自己的報告目錄，且能立即排程。Act loops 會對外部環境進行變更，因此必須先備妥 ordering proof、blast-radius declaration，以及並非由 maker 擔任的 verifier——這些都要在建立排程前寫好。Loops 一律從 observe 起步，達標後才可晉升。
• exec/model 分工。 確定性檢查以指令碼執行（零 token、耗時 1–2 秒）；model loops 則專門處理需要判斷的工作。Fleet 每日的例行檢查可以分文不花。
• 報告契約。 每項檢查占一行，格式為 PASS|FAIL <check>: <reason>，並附加至以日期命名的報告檔案。若無法定義一眼即可讀懂的 PASS 行，表示 loop 尚未準備就緒。Digest loop 會讀取 fleet 的所有報告，讓人員只需查看 1 頁，而非 30 頁。
• 自我維護的基準線。 最出色的偏移監控程式會直接從受保護的 artifact 推導預期值——例如指南本身記錄的時間戳記、lockfile 自身的雜湊值。如此一來，更新 artifact 便會同步更新監控程式，也不會出現容易遭遺忘的第 2 個 truth source。
• 經得起考驗的排程。 本機 fleets 透過作業系統排程器（launchd、cron、systemd timers）呼叫 runner script；雲端 fleets 則採用 routines。Session-bound loops（/loop）適合需要人在場的工作。

這正是 Cherny 所說的「我的工作是撰寫 loops」的具體實踐：人員的工作轉為規範檢查、verifiers 與預算，並閱讀報告。

最值得率先建立的 2 個 Loops

若要從零開始建立 fleet，有 2 個 loops 能立刻帶來回報——兩者都已在本站的 harness 中得到驗證：

Gate loop——為所有發布內容執行 maker-checker。全新的 evaluator（不保留前幾輪的記憶）會依明確標準為 artifact 評分；您須處理每一項明列的發現；接著由新的 evaluator 重新評分；loop 會在達標或觸及嚴格的輪次上限時停止。從一次涵蓋 15 篇文章的衝刺中，可歸納出 2 項實務心得：修正可能引入新缺陷（某輪修正錯誤歸屬了一項數據，直到下一輪 evaluator 才發現）；而且 evaluators 可能從兩個方向犯錯——其中一次甚至信心十足地「修正」了正確陳述。因此，具體修正必須先回到來源查證，才能套用。Checker 並非權威；來源才是。

Groundskeeper——act-tier 的進入點。每次執行只處理 1 項小型且可客觀驗證的修正；在 branch 上作業；開啟 PR 前必須通過所有測試；而且 loop 絕不執行 merge。兩項規則可確保安全：凡有歧義之處，一律標記，不修正（首次有人監督的執行正確地拒絕處理 detector 的 false positive）；若 main 原先就有失敗，應據實回報，絕不可將其納入 loop 的 diff。

有一項 fleet 維運細節值得借鏡：為無人監督的 model loops 設置 session lease——只要同一 repo 中仍有 interactive session，就延後所有執行。兩個 writers 共用同一個 checkout，遲早會交錯提交 commits；session lease 能從機制上確保 loop 主動禮讓人員。

常見問題

什麼是 loop engineering？

這是一種讓 AI agents 反覆執行工作週期，直到符合停止條件為止的實務，而不是逐輪向其輸入提示。工程師的工作從撰寫 prompts 轉為設計 loop：包括其重新觸發規則（條件、排程或事件）、各次迭代之間的狀態、verifier，以及預算。Anthropic 於 2026年6月為這門實務命名；其 Claude Code 介面包括 /goal、/loop、Ralph plugin、routines 與 dynamic workflows。

什麼是 Ralph loop？

這是一種由 Geoffrey Huntley 於 2025年7月命名的暴力式 autonomy pattern：在 shell while loop 中執行 Claude Code，每次迭代都以全新 context 傳入相同 prompt，並透過 progress files 與 git 在各輪之間保存狀態，再以測試形成 backpressure。Anthropic 提供官方 ralph-wiggum plugin，透過 Stop hook 在 session 內執行 looping，並以 --max-iterations 作為主要安全機制。

如何在 loop 中執行 Claude Code？

選擇符合需求的最低層級：使用 /goal <condition> 反覆執行，直到獨立 evaluator 確認條件成立；使用 /loop <interval> <prompt>，在 session 開啟期間定期執行；使用 /ralph-loop，反覆處理單一任務，直到達成 completion promise；使用 /schedule，建立依 cron 執行且不需本機在線的 cloud routine。若採 headless 模式，經典作法是在 shell loop 中執行 claude -p，並搭配外部檢查。

Loops 會取代 prompting 嗎？

Prompt 並未消失——只是換了位置。您只需撰寫一次，將其納入 loop 的規格，之後由 loop 重複觸發；而且愈來愈常見的情況是（如 dynamic workflows，以及 Cherny 所說的「其實是另一個負責 prompting 的 Claude」），由 orchestrating agent 為個別任務撰寫 prompts。人員的專業重心不再是雕琢 prompts，而是設計驗證機制：明確說明機器或全新 model 能夠檢查的條件。

Claude Code 中的 loop、routine 與 workflow 有何差異？

Loop（/loop）會在本機 session 中依排程重新執行 prompt，並隨 session 結束而停止。Routine 是將同一概念封裝後，改在雲端基礎架構上執行——可由 cron、API 或 GitHub 事件觸發，無須筆記型電腦在線。Workflow 則是單次執行的 orchestration graph：由 Claude 撰寫的 JavaScript script，可產生並協調多達 1,000 個 subagents，並將 loops 與 branching 保存在程式碼而非 context 中。

Agent loops 的成本是多少？

如實回答，範圍可能「從零成本到代價慘重」，關鍵變數在於設計。確定性監控程式無須付費——它們只是依排程執行的指令碼。Model loops 則按迭代計費：務必設定上限（--max-iterations、--max-budget-usd），讓回報可供觀察，使 loop 能在邊際效益遞減時停止；並將每項上限視為停止規則，而非妨礙。那些代價高昂的失敗事後檢討——一夜耗費數千美元、幾分鐘內使用 4M tokens——都有同一項根本原因：缺少外部停止條件。

Loop 何時應轉為 graph？

當平行工作產生相依關係時：某項任務需要另一項任務的輸出，或 2 個 agents 會修改相同檔案。Loops 負責單一 repo 與單一目標；graphs（dynamic workflows、agent teams、external orchestrators）則加入 dependency ordering、file claiming 與 merge discipline。只有在衝突確實出現時才採用 graphs——額外結構會增加 observability 與 setup 的成本。

變更紀錄