迴圈工程：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.312（2026年10月）。

什麼是 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 scheduled task (formerly a 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月提出的分類法，這是目前對此領域最清楚的獨立梳理。¹¹）

在環級 3 與環級 5 之間，還有一個本機選項：Desktop 排程工作在您的機器上執行，無須開啟 session；由 Claude 設定時，間隔最短可達 1 分鐘（透過表單設定則為 1 小時），文件也建議在「需要存取本機檔案與工具時」使用。¹²

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

Loop Surfaces 詳解

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

/goal——evaluator-optimizer loop

/goal <condition> 會讓 Claude 持續工作，直到條件成立：「每一輪結束後，會由一個模型檢查條件是否成立。若模型判定條件尚未達成，Claude 便會開始下一輪，而不會將控制權交還給您。」⁹ 在底層，「/goal 是包覆在一個 session 範圍、以提示為基礎的 Stop hook 外層的 wrapper」，因此只要 hooks 遭到關閉（disableAllHooks，或 managed settings 中的 allowManagedHooksOnly），就無法使用。evaluator 是您所設定的小型快速模型，會回傳下列 3 種判定之一，每種都附上簡短理由：⁹

它也能以 headless 模式執行：claude -p "/goal ..." 會持續執行 loop，直至完成。

撰寫要點：條件應該可以觀察（「測試通過」、「endpoint 回傳 200」、「TypeScript 錯誤為零」），而非流於願景（「程式碼很乾淨」）。模糊的 verifier 無法為 loop 指引方向——而且語氣篤定的逐字紀錄可能說服模型同意某個由模型判定的條件，因此只要有機器檢查可用，就應將其與 /goal 搭配。¹¹ 文件也直接點明這項限制：evaluator「不會自行執行指令或讀取檔案，因此請將條件寫成 Claude 自身輸出能夠證明的內容」。⁹ 停止規則也應寫進條件裡：像 or stop after 20 turns 這樣的子句，會與條件的其餘部分一併判定；條件最長可達 4,000 個字元。如果 Claude 連續數輪只回應 evaluator 而未使用任何工具，Claude Code 會停止 loop，並在 goal 仍維持設定的狀態下，將控制權交還給您。⁹

失敗處理自 v2.1.234 起首度強化，³⁴ 如今已涵蓋一輪可能失敗的各種情況：

若由桌面應用程式或雲端 session 等主機管理憑證，驗證失敗時 goal 會維持啟用，因為主機會自行恢復存取權。此外，當背景工作讓 goal 持續等待時，Claude 會在 30 分鐘後檢查進度，1 小時後再檢查一次，之後每 2 小時檢查一次；在您兩次提示之間，最多只會啟動 3 次閒置檢查（CLAUDE_CODE_GOAL_CHECKIN_MINUTES 設定第一次的間隔；設為 0 則會關閉檢查與自動重試）。⁹

/loop——週期性本機執行

/loop [interval] <prompt> 會依排程重複執行提示：固定間隔（/loop 5m check the deploy）、自行調整節奏（Claude 根據觀察結果，在 1 分鐘到 1 小時之間決定下一次延遲時間），或單獨使用 /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.md（專案中的 .claude/loop.md 優先，或 ~/.claude/loop.md）；「對 loop.md 的修改會在下一次迭代生效」，超過 25,000 位元組的內容則會被截斷。¹²

真正關鍵的限制是：/loop 存在於執行中的 Claude Code 程序內。「工作只會在 Claude Code 執行中且處於閒置狀態時觸發。」結束程序，工作就不再觸發；將 session 移至背景，loop 會在沒有終端機的情況下繼續執行；以 --resume 或 --continue 恢復 session 時，以 CronCreate 排定的工作會恢復，但自行調整節奏的 /loop 不會，因此需要重新執行。¹² 對於必須在 session 結束後繼續運作的工作，文件比較了 3 種 surfaces：¹²

必須在機器關機時執行的工作，正是雲端排程工作的用武之地。

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

Anthropic 的官方 ralph-loop plugin 將社群最常用的暴力模式產品化。自 2026年1月6日起，它在 anthropics/claude-plugins-official repository 中便名為 ralph-loop；當時 Anthropic「依據法律建議」將其由 ralph-wiggum 更名。2026年10月26日，claude-code repository 刪除了自身過時的 ralph-wiggum 副本，其 marketplace 現在改從官方 repository 安裝 ralph-loop，因此「既有的 plugin id 仍可正常運作」。¹⁴ 其運作機制是：Stop hook 會攔截 Claude 結束 session 的嘗試，並重新注入提示，讓模型在同一 session 中持續迭代。使用 /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" 啟動；以 /cancel-ralph 中止。README 明確指出，--max-iterations 是「您的主要安全機制」——完全相符的字串比對可能永遠無法完成。¹⁴ 所有 Stop-hook loop 都受一項 harness 限制約束：「如果 hook 連續阻擋 8 次停止，且其間沒有任何工具呼叫，Claude Code 會覆寫下一次阻擋並結束該輪」（CLAUDE_CODE_STOP_HOOK_BLOCK_CAP 可提高此上限）。²⁹ 這會終止已停止進展的 loop，卻不會終止持續呼叫工具的 Ralph loop，因此迭代上限依然重要。

Dynamic workflows——Claude 自行編寫 graph

Dynamic workflows 隨 Claude Code v2.1.154（2026年5月）推出，並於 Anthropic 在 2026年6月2日發布的文章中詳加說明。這是概念上幅度最大的躍進：「Claude 現在能即時編寫自己的 harness，針對手邊工作量身打造。」¹⁵ 您只要描述工作、說出「use a workflow」，或在提示中加入關鍵字 ultracode，Claude 就會撰寫 JavaScript orchestration script：其中 agent() 會產生 subagent，並可選擇使用 JSON-schema 輸出；pipeline() 會針對清單中的每個項目各執行一次；parallel() 會同時執行一組工作；一般的 await／loops／conditionals 則負責控制流程。接著由 runtime 於背景執行。/effort ultracode 更進一步：Claude「會為 session 中的每項實質工作規劃 workflow」，而這樣的 session「會比關閉此功能時處理相同工作，更快觸及 session 或每週用量限制」。¹⁶ 「workflow 將計畫移入程式碼……workflow script 自行保存 loop、分支與中間結果，因此 Claude 的 context 只會保留最終答案。」¹⁶

限制與結構，依文件所述如下：¹⁶

儲存至 .claude/workflows/ 的指令碼可成為重複使用的 slash commands。Claude 重新啟動某次執行時，會從已儲存的 agent 結果續接；但失敗的 agent「會重新執行，指令碼在它之後啟動的每個 agent 也會重新執行，即使已經完成」，而您在執行途中移至背景或結束的執行作業，「不會自行繼續」。¹⁶

其代表性拓撲為 fan-out / refute / converge：先由彼此獨立的 finders 尋找答案，再由 adversarial verifiers 嘗試推翻每項發現，持續迭代，直到答案經得起反駁。Anthropic 如今也推出了這種拓撲的實例：內建的 /deep-research workflow 會「針對一個問題從多個角度展開網路搜尋，擷取並交叉核對找到的來源，對每項主張進行表決，最後回傳附有引用來源的報告，並濾除未通過交叉核對的主張」；當其 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 形式加入；文件如今表示「Agent teams 屬於實驗性功能，預設為停用」）：由一名 team lead 加上多名 teammates 組成；teammates「各自在自己的 context window 中獨立工作，並直接彼此溝通」。這使其成為一種 peer graph，而非 subagent tree；協調機制包括具相依關係的共用工作清單、檔案鎖定認領，以及每個 agent 各自的 mailbox。由 Hook 強制執行的 quality gates 會在 teammate 與「完成」之間加入機器檢查：TaskCompleted 以 exit code 2 阻擋完成，TeammateIdle 以 exit code 2 讓 teammate 繼續工作。¹⁷ 啟用前需要了解兩項行為：agent teams 啟用期間，「Claude 命名的 subagent 會以 teammate 身分啟動，因此即使您沒有要求，也可能形成 team」；此外，「teammate 無法代替您核准權限提示或表示同意」。¹⁷

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

雲端排程工作（前身為 routine）是「儲存好的 Claude Code 設定：包含一個提示、一個或多個 repositories，以及一組 connectors；只需封裝一次，之後便能自動執行」，可在 Anthropic 管理的雲端基礎架構或您組織的 self-hosted 環境上執行。¹⁸ 在更名會造成問題的地方，舊名稱依然保留：網址（claude.ai/code/routines）、作為 /schedule 別名的 /routines，以及 /fire API 路徑。共有 3 種可組合的觸發類型：排程（週期性執行的最短間隔為 1 小時，也可在指定時間單次執行）、API 觸發（POST .../routines/{id}/fire），以及 GitHub 事件。可透過 /schedule、Desktop 應用程式或 claude.ai/code/routines 建立。除非無法使用 auto mode，否則每次執行的 session 都會以 auto mode 啟動；由分類器允許或阻擋每項動作，而在某些情況下，例如即使在 auto mode 中仍會提示的動作（ask 規則），或反覆遭到阻擋時，執行會停下來等待。也正因如此，文件中的警語至關重要：執行結果說明的是「session 如何結束，而非 Claude 是否完成提示中描述的工作，因此請開啟該次執行並閱讀逐字紀錄，了解實際發生了什麼」。¹⁸ 9月以來的兩項修正顯示這個落差確實存在：在 v2.1.286 之前，雲端 session 從未啟動的執行會顯示為 Succeeded；在 v2.1.302 之前，執行會在「雲端 session 意外停止後顯示為 Completed」。³⁶ 同一版本也修正了中途失敗的執行會從頭重新執行的問題，這種情況「可能重複執行工作，例如將同一份報告發布兩次」，這也是應讓觸發的工作具備冪等性的理由。³⁶

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

其他支援角色

Background subagents（自 v2.1.198 起預設啟用）讓委派的工作留在您的 context 之外；可透過 /agents 面板監控。Cross-session messaging（v2.1.224）透過 SendMessage 將彼此獨立的 sessions 串成 message-passing graph，其中的安全準則值得借鏡：來自另一個 session 的訊息「絕不等同於您的同意」。¹⁹ 從連接至 Remote Control 的 session 出發，它也能觸及您在其他機器上（v2.1.225+）以及雲端中的 sessions。若要在 loops 之間等待，notify_when_idle 輸入（v2.1.236+）³⁶ 可要求本機上的某個 session 在下次進入閒置或結束時發出一則通知，而 Claude Code 會在「不於受監看的 session 中啟動任何一輪、也不耗用 token」的情況下完成訂閱。¹⁹ Self-hosted runners（v2.1.224，Team/Enterprise）可在您自己的機器上執行雲端 sessions 與雲端排程工作（前身為 routines），這是組織級 agents 艦隊的底層基礎。²⁰

Ralph模式

社群早已先行一步。2025年7月，Geoffrey Huntley發表了一篇文章，以《辛普森家庭》中的角色為這項技術命名：Ralph其實就是

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

——以上單行指令與他發表的原文完全一致——一個儲存庫、每次迭代一項任務、每輪都使用全新上下文，透過檔案系統中的規格與進度檔案在迭代之間傳遞狀態，並以測試與程式碼檢查作為「背壓」。²¹ 同樣架構的現代無介面形式，是在shell迴圈中執行claude -p "$(cat PROMPT.md)"，本質上就是Anthropic自家的C編譯器harness所採用的方式。²³ 他聲稱的成果（僅花費297美元的token費用，就完成一份價值5萬美元合約的MVP；在黑客松中一夜完成6個儲存庫）也伴隨同樣明確的限制：僅適用於全新專案、佔位與重複實作是反覆出現的失敗模式，而且「LLM反映的是操作者的能力」。

Anthropic從未在工程資料中使用這個名稱，但這個模式如今已兩度成為官方準則：2025年11月關於長時間執行代理的文章，明確建議採用這套架構——由初始化代理建立功能清單與進度檔案，再為每個上下文視窗啟動全新的程式開發代理，並「在工作階段開始時，先讀取進度筆記檔案與git提交紀錄」²²——而2026年2月的C編譯器專案則讓16個Claude代理平行執行。正如Nicholas Carlini所述：「我建立了一個harness，把Claude放進一個簡單的迴圈。」專案使用以檔案為基礎的任務鎖定機制，並以git作為同步層，歷經約2,000個工作階段，產出約10萬行Rust程式碼，成本約2萬美元。²³ 文章中關於驗證的那句話，道盡了這個模式的理論核心：「任務驗證器必須近乎完美，這點至關重要。」

為何全新上下文勝過單一長工作階段：隨著工作階段的上下文逐漸填滿，效能也會下降——實務工作者的共識是，偏移大約從10萬個token開始——而上下文壓縮摘要會遺失資訊，甚至將錯誤重新包裝成語氣篤定的文字。²⁴ Ralph每次啟動新代理並搭配檔案的設計，避開了這兩個問題。（官方外掛為了便利性，在工作階段內執行迴圈，因而犧牲了部分優勢；對於長時間執行的任務，搭配外部狀態的無介面形式仍是更穩健的模式。）

這個模式的警世案例也值得借鏡：一位實務工作者以模糊的提示詞搭配max_iterations: 0執行外掛——這個值代表無限次，而非停用——結果Claude向自己重複提出同一個澄清問題1,966次，Stop hook還攔截了之後的每一則訊息。²⁵ 迭代次數上限不可或缺。

當迴圈演變成圖

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

以下依所需基礎設施由少到多，列出採用圖的選項：

1. 動態工作流程——透過JavaScript控制流程表達相依關係；只有某個階段確實需要所有先前結果時，才設置同步屏障。Anthropic列出的拓樸包括：分散執行後彙整、對抗式驗證、生成後篩選、錦標賽（「啟動N個代理，各自以不同方法嘗試同一項任務」，再兩兩評比），以及迴圈執行直到完成。¹⁵
2. 代理團隊——共用一份具備相依性追蹤的任務清單；負責人處於規劃模式時產生的隊友，會送出計畫等待核准，而Claude Code會自動核准；只有當您將執行中的同程序隊友切換至規劃模式（Shift+Tab）時，才由負責人審查計畫；圖以資料形式呈現，而非程式碼。¹⁷ 這個模式下有一項預設值變更，最早出現在v2.1.233：³⁴ 任務追蹤工具（TaskCreate、TaskGet、TaskUpdate、TaskList、TodoWrite）如今「僅在Opus 4.7、Sonnet 4.6、Haiku 4.5及更早的模型上預設提供」，此預設組合自v2.1.268起適用。³⁸ 沒有這些工具的代理會「透過訊息協調，而非共用任務清單」，¹⁷ 因此在一般本機工作階段中使用目前的模型時，除非主動啟用，否則任務清單並不存在；背景與雲端工作階段則在所有模型上都提供這些工具。³⁸ 可透過CLAUDE_CODE_ENABLE_TODO_TOOLS=1、--allowedTools TaskCreate，或在--tools清單中列出這些工具來啟用。匯出的環境變數不會傳遞給分割窗格中的隊友，因此若要讓這類隊友取得這些工具，請以claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'啟動負責人。³⁸
3. 外部協調器——社群的橫向擴充方案：Steve Yegge的Gas Town讓20–30個Claude Code執行個體，依照由git支援的「beads」所組成的DAG執行工作（17天內產出7.5萬行Go程式碼，但他自己也稱其為「燒錢機器」，且對操作者能力要求很高）；²⁷ claude-flow/Ruflo（約3.1萬顆星）以女王／工作者階層架構組織代理群；LangGraph風格的引擎則在上層加入具型別的狀態機，將Claude Code放在節點內執行。

Cherny在2026年7月透過Anthropic發表的AI採用階段階梯，正式整理了這條演進路徑：關卡控管（0個代理）→輔助作業（約1個）→平行作業（約10個）→受監督的自主運作（約100個，此時「多數代理由Claude啟動，而非人類」）→AI原生（1,000個以上）。他的建議是：「每往前一步……都需要找出並突破下一批瓶頸，同時建立下一套防護措施。」²⁸

驗證工程

以上都是基礎管線。這一節才是產品本身。

Anthropic的逐級強化階梯，出自目前的最佳實務文件，始於一項建議：「給Claude一個能執行、並會回傳通過或失敗結果的東西。有了它，Claude就能自行持續工作，您也不必在旁盯著。」接下來的各階，從由Claude自行決定，逐步走向由harness強制執行：一行提示（run the auth tests after, and keep going until they pass）→/goal條件，「每一輪結束後，由另一個模型對照對話內容檢查」，這「對長時間的背景執行很重要，因為Claude有時會在項目仍未完成時，以進度摘要結束一輪」→Stop hook，「由Claude Code（harness）強制執行，因此在型別檢查通過或達到阻擋上限之前，該輪都不會結束」→「由未撰寫該程式碼的人」進行審查，其中/code-review「會在從未看過您對話的全新subagent中審查差異。它不會受到產生程式碼的推理過程左右」。²⁹ 隨附的證據規範是：「要求Claude提供證據：它執行的指令與輸出，或螢幕截圖」，因為「對於您沒有在旁觀看的工作階段，這也是您僅有的證據」。²⁹ 對抗式反駁原本是這座階梯的最後一階，如今則收錄於工作流程文件中；其範例提示要求工作流程「在回報每項發現之前，先以對抗方式加以驗證」。¹⁶

同一份文件將每項指示區分為由Claude決定的部分，以及由Claude Code強制執行的部分。其中3列正好對應迴圈的停止、預算與合併規則：²⁹

無人值守的迴圈，每一列都需要右欄中的一項機制；沒有人寫下這些機制時，迴圈就只剩左欄可依靠。這份文件也淘汰了一種提示習慣：像「keep going, loop until done, don’t be lazy」這類句子，「比較可能造成過度工作，而非解決停滯」，而且「對於無人監看的執行，應由/goal或Stop hook強制執行」。²⁹

3類回饋，出自Agent SDK文章：規則式回饋（「明確定義輸出必須遵守的規則，再說明哪些規則未通過，以及原因」——這是最佳形式）、視覺回饋（螢幕截圖、像素差異），以及以LLM擔任評審（模糊的評分規準——用Anthropic的話說，「通常不是非常穩健的方法」）。⁷ 請依此順序優先採用；現成的確定性檢查，勝過只會發表意見的評審。

收斂條件。 對迴圈最犀利的批判性探討——Yoko Li於2026年8月發表的分析——將收斂歸納為4項要求：明確定義的目標狀態、可觀測的目前狀態、精確的局部修改，以及設於生成器外部的停止規則。她透過量測實驗得到的數字值得記住：迴圈中67%的token花費毫無改善，因為沒有任何機制告訴迴圈，效益已轉為對數成長。³⁰ 預算上限不只是成本控制，更是最後一道停止規則。

測試完整性。 Anthropic的長時間執行代理準則指出：「移除或編輯測試是不可接受的，因為這可能導致功能缺漏或錯誤。」²² 迴圈會鑽規格的漏洞——通過可見的測試，卻未達成背後的真正意圖——因此，驗證器本身也必須受到保護，避免遭到受評代理竄改。

評分應看成果，而非路徑。 評估文章指出：「評分對象是代理產出的成果，而非它採取的路徑。」對於客觀標準，使用程式碼式評分器；對於評分規準，則使用模型式評分器，並進行校準：「除非閱讀大量試驗的對話紀錄與評分，否則無法知道評分器是否運作良好。」³¹

多數討論還忽略了一個區別：當迴圈中的每項檢查都具有確定性時，迴圈根本不需要模型。 比較時間戳記的偏移監控器、連結檢查器、建置監控器——這些都只是排程執行的shell指令碼：不消耗token、每次執行僅需數秒，而且結果完全可重現。請將模型驅動的迴圈保留給需要判斷的迭代。成本最低的迴圈，就是從不呼叫模型的迴圈。

成本與安全紀律

社群對迴圈工程最強烈的質疑是成本，而事後檢討案例也印證了這一點：產生subagents的錯誤在5分鐘內燒掉400萬個token；通宵執行的迴圈耗費數千美元；用量限制「比預期快得多」就觸頂。³² 其中一道限制如今已有變化：自v2.1.234起，claude.ai用量限制重設後，工作階段會自動繼續（即autoContinueAtUsageLimit設定；可在/config →「Continue automatically at usage limit」關閉）。³⁴³⁷ 但適用範圍很窄。「在以claude.ai訂閱登入的互動式工作階段中，自動繼續預設為開啟」；若是「超過24小時後才會重設」的限制，例如每週限制，Claude Code不會自行開始等待；結束Claude Code即會終止等待；而在「背景工作階段與-p執行」中，Claude Code「完全不提供等待」，這涵蓋了無介面的Ralph與claude -p "/goal ..."。³⁷ 在符合條件的工作階段中，迴圈也會隨之等待：暫停的/goal會在重設時恢復，⁹ 而自v2.1.271起，工作流程執行會等候限制解除，而不會讓其代理失敗，每次執行最多等候兩次。¹⁶ 留在開啟中互動式工作階段的通宵迴圈，如今能撐過用量上限；以無介面方式或在背景工作階段中執行的迴圈，仍會在上限處停止。因此下列預算控制更加重要。實務中逐漸形成以下紀律，每一項都有已推出的控制機制對應：

最後一列值得獨立說明，因為這正是最積極的實務工作者確保安全的方法：將影響範圍限制在pull request內。 Cherny常駐的背景代理，一個持續改善架構，另一個尋找重複的抽象設計，無須人工觸發就會提交PR；² 所有變更都必須經過審查才能合併。如果持續運作的迴圈最糟也只會留下「尚未合併的分支」，就能放手執行；會直接寫入main的迴圈則不行。雲端排程工作已將這項做法設為預設：「Claude會將工作推送至以claude/為前綴的分支，除非您的提示指示它推送至其他分支」，而GitHub的分支保護或規則集則決定執行作業能推送到哪裡。¹⁸ 迴圈應循序升級：先從僅觀察開始（產生報告，不寫入），經過多次平穩執行建立信任，再升級為提出變更——而且必須在設定排程之前，寫下執行順序的證明（「只有驗證回傳新標記後，才執行清除」），以及完整的影響範圍聲明。驗證成本低，迴圈才有優勢探討的正是這條升級路徑的成本效益：決定哪些工作能無人值守執行的，是驗證成本，而非建構迴圈的成本。

任何迴圈輸入都不算同意。 4條有文件記載的規則彼此一致：來自另一個工作階段的訊息「絕不等同於您的同意」；¹⁹ 隊友「無法代替您核准權限提示或表示同意」；¹⁷ 雲端排程工作被觸發時的提示「無法在執行期間充當對任何動作的核准或同意」，而透過API觸發一併送出的文字，「會包在<routine-fire-payload>區塊中，標示為不受信任的資料」；¹⁸ 在auto模式下，工作流程指令碼傳給agent()的提示「不算是您提出的要求」，因為「Claude Code會將其標示為指令碼計算出的文字」。¹⁶ 請將這條規則沿用到自己的迴圈中：機器產生的文字是資料，核准必須來自人。

最根本的質疑不是成本，而是審查能力——迴圈產生程式碼的速度，超過人類能確實審查的速度。³³ 這沒有取巧的解法，只能誠實界定適用範圍：無人值守的迴圈，只適合能由機器驗證的工作，其他一概不適合。無法驗證，就不要發布。

受控研究如何看待harness元件

多數harness建議，包括本指南在內，都來自實務工作者在正式環境中逐一調整變因的經驗。2026年9月，UMass Amherst、Emory、UNC Charlotte與Zoom的一項研究，則在受控條件下進行測試：研究團隊打造了專用harness，「固定執行迴圈，只改變3個元件：規劃、動作空間與上下文管理」，並在SWE-Bench Verified與Terminal-Bench 2.1上，以4個開放權重模型——3種規模的Nemotron-3與Mistral-Medium-3.5-128B——執行「176組配對設定，涵蓋5種上下文管理策略、4種上下文視窗預算，以及針對規劃與動作空間的消融實驗」。³⁵ 以下是作者提出的4項發現：

• 「上下文視窗預算越緊，上下文管理就越有價值；其大部分效益來自避免上下文溢位造成的失敗。」
• 「先依規則刪減內容，再以LLM進行摘要，在各種上下文管理策略中，整體效率最佳；相較之下，讓刪減內容可供復原，只會增加模型很少使用的機制，並未提升準確度。」
• 「對較弱模型而言，規劃是提升準確度的支架；對較強模型而言，規劃則轉為節省成本的手段，對準確度影響甚微。」
• 「預先定義的工具能改善bash熟練度較低模型的表現；具備bash能力的模型，則能透過僅提供bash的介面有效運作，並大幅降低成本，尤其是在以命令列為核心的任務上。」

依我的解讀，其中3項直接適用於迴圈工程。上下文管理是防範溢位的保險：長時間執行的迴圈應妥善分配視窗預算，並在產生任何摘要前，先刪減龐大的工具輸出；至於模型不會使用的內容找回機制，則可省去。對能力較強的模型而言，規劃是調節成本的手段，而非提升準確度的槓桿；在為使用強大模型的迴圈加入規劃階段前，值得先理解這一點。而僅使用bash的結果，則是在更高一層印證執行／模型分工：當執行者能力足夠時，將動作整合為較少、範圍較大的操作，成本反而更低。研究本身也指出其限制：僅涵蓋4個模型、2項基準測試，而且harness是為實驗打造，並非任何已推出的代理，因此這些結果可作為方向參考，不能直接套用為設定。³⁵

營運迴圈群

迴圈工程的最終形態不是單一迴圈，而是一組常駐運作的迴圈。當實務運作穩定後，會呈現以下樣貌：

• 將規格寫成檔案。 每個迴圈都是一份納入版本控管的規格——名稱、層級、排程、目標、驗證器、允許使用的工具、預算、逾時限制——存放在它所服務的儲存庫中。同一項手動檢查若已輸入3次，就該寫成規格。Anthropic也推出了這個概念的小型版本：loop.md檔案可取代單獨使用/loop時的內建提示，而且對它的修改會在下一次迭代生效。¹²
• 分為2層，憑實績升級。 觀察迴圈可以讀取任何內容，但只能寫入自己的報告目錄，並可立即排程。行動迴圈會對外部環境產生實際影響，因此必須具備執行順序證明、影響範圍聲明，以及獨立於產出者的驗證器——這些都要在設定排程前寫明。迴圈一律從觀察層開始，靠實績取得升級資格。
• 執行／模型分工。 確定性檢查以指令碼執行（零token、1–2秒）；模型迴圈則保留給需要判斷的工作。整組迴圈的每日例行檢查可以完全不花錢。
• 報告契約。 每項檢查占一行，格式為PASS|FAIL <check>: <reason>，附加至按日期命名的報告檔案。若無法定義一眼就能看懂的PASS行，迴圈就還沒準備好。再由摘要迴圈讀取整組迴圈的報告，讓人只需閱讀1頁，而非30頁。
• 自行維護的基準。 最好的偏移監測器，會從受監測的產出本身推導預期值——例如指南自行記錄的時間戳記、鎖定檔本身的雜湊值——如此一來，更新產出就等於更新監測器，也不會多出另一份容易忘記維護的權威資料來源。
• 能持續運作的排程。 本機迴圈群透過作業系統排程器（launchd、cron、systemd timers）呼叫執行指令碼，或在機器持續開機時使用Desktop排程工作；雲端迴圈群則使用雲端排程工作（前身為routines）。綁定工作階段的迴圈（/loop）適合您在場時進行的工作，或在移至背景的工作階段中執行。¹²

這就是Cherny「我的工作是撰寫迴圈」的具體實踐：人的工作轉為定義檢查、驗證器與預算，以及閱讀報告。

最值得先建立的2個迴圈

若要從零開始建立迴圈群，有2個迴圈能立即帶來回報——兩者都已在本站的harness中驗證：

把關迴圈——為所有要發布的內容建立產出與檢查分工。由全新的評估者（不記得先前輪次）依明確標準評分；您處理每一項明確指出的問題；再由新的評估者重新評分；達標或達到輪次硬性上限後，迴圈便停止。在一輪密集處理15篇文章的實作中，有2點觀察：修正可能引入新缺陷（某輪修正把一項數據歸給錯誤來源，下一輪評估者才抓到），而且評估者會犯2種方向相反的錯誤——其中一個曾自信地「修正」原本正確的敘述，因此套用具體修正前，必須先回到來源查證。檢查者不是權威，來源才是。

維護迴圈——行動層的入門選擇。每次執行只在分支上完成一項小規模、可客觀驗證的修正，測試全部通過後才開PR，而且迴圈絕不自行合併。2條規則維持其安全性：任何有歧義的項目都只標記，不修正（首次受監督執行時，就正確地拒絕處理偵測器的一項誤報）；main上原本就存在的失敗，則如實回報，絕不混入迴圈的差異內容。

有一項迴圈群營運細節值得借鏡：為無人值守的模型迴圈加入工作階段租約——同一儲存庫內只要有互動式工作階段正在使用，就延後執行。2個寫入者共用同一份工作目錄，提交遲早會交錯；租約則從機制上確保迴圈讓位給人。

常見問題

什麼是迴圈工程？

讓AI代理反覆執行工作週期，直到符合停止條件的實務方法，而非逐輪下提示。工程師的工作從撰寫提示，轉為設計迴圈：重新觸發規則（條件、排程、事件）、迭代之間的狀態、驗證器與預算。Anthropic於2026年6月為這個領域命名；在Claude Code中，對應功能包括/goal、/loop、Ralph外掛、雲端排程工作（前身為routines）與動態工作流程。

什麼是Ralph迴圈？

Geoffrey Huntley於2025年7月命名的一種暴力迭代式自主運作模式：在shell的while迴圈中執行Claude Code，每次迭代都以全新的上下文餵入相同提示，透過進度檔案與git在各輪之間保存狀態，並由測試提供背壓。Anthropic提供官方ralph-loop外掛（2026年1月由ralph-wiggum更名），透過Stop hook在工作階段內執行迴圈，並以--max-iterations作為主要安全機制。

如何讓Claude Code以迴圈執行？

選擇足以滿足需求的最低層級：使用/goal <condition>持續迭代，直到獨立評估者確認條件成立；使用/loop <interval> <prompt>，在Claude Code工作階段執行期間定期執行；使用/ralph-loop反覆處理同一項任務，直到輸出完成承諾；使用/schedule建立依cron排程執行的雲端排程工作，無須依賴您的電腦。若採無介面模式，經典做法是在shell迴圈內執行claude -p，並搭配外部檢查。

迴圈會取代提示嗎？

提示不會消失，只是換了位置。您將提示寫入迴圈規格一次，之後由迴圈重新觸發；而且越來越多情況下（如動態工作流程，以及Cherny所說的「實際上是另一個Claude在下提示」），各任務的提示會由負責協調的代理撰寫。人類的核心技藝，則從雕琢提示轉為設計驗證：明確列出機器或全新模型能夠檢查的條件。

Claude Code中的迴圈、routine與工作流程有何差異？

迴圈（/loop）會在本機Claude Code工作階段內依排程重新執行提示，並在該程序結束時停止觸發；移至背景的工作階段則會讓它持續執行。雲端排程工作（前身為routine）則將同樣的概念封裝為在雲端基礎架構上執行的功能：由cron、API或GitHub事件觸發，無須筆電。工作流程則是單次執行的協調圖：由Claude撰寫的JavaScript指令碼，負責產生並協調最多1,000個subagents，迴圈與分支邏輯都保存在程式碼中，而非上下文中。

代理迴圈要花多少錢？

老實說，範圍從「零成本到傾家蕩產」都有，關鍵在於設計。確定性監測器不花錢——它們只是排程執行的指令碼。模型迴圈則按迭代累計用量：設定上限（--max-iterations、--max-budget-usd），讓效益可觀察，以便在邊際效益遞減時停止，並將每一道上限視為停止規則，而非麻煩。那些失敗後的檢討案例——一夜耗費數千美元、幾分鐘燒掉400萬個token——都有同一個根本原因：缺乏外部停止條件。

何時應將迴圈改為圖結構？

當平行工作出現相依關係時：某項任務需要另一項任務的輸出，或2個代理會修改同一批檔案。迴圈處理單一儲存庫與單一目標；圖結構（動態工作流程、代理團隊、外部協調器）則加入相依排序、檔案認領與合併紀律。只有實際出現衝突時，才採用圖結構——新增的結構也會增加維持可觀測性與設定的成本。

更新紀錄