Loop Engineering

資料來源#

• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog
• How we use /goal to find bugs in Patch the Planet
• Loop Engineering
• Thread by @AndrewYNg
• Verify, Repair, Repeat, or Stop? Robust Stopping for Noisy Verify-Repair Loops in LLM Agents

摘要#

迴圈工程就是不再由你親自提示代理程式，而是設計一套會提示它的系統。 Karpathy 時代的代理式程式設計，是由人一次一輪地操作工具：輸入、閱讀、再輸入。迴圈工程則反轉這種做法：你打造一套小型系統，負責找出工作、分派工作、檢查成果、記錄完成事項，並決定下一步，接著讓這套系統去驅動代理程式。Addy Osmani 在 2026 年 6 月的文章為這種做法命名，並描繪其構成：五種基本元件，再加上一個記錄資訊的地方。 其中最尖銳、最出人意料的主張是，這「已經不太算是工具的事了」——一年前，迴圈還是你得永遠維護的一堆私人 bash 腳本；如今，這些元件已內建於產品中，而且同一個迴圈可以在 Codex app 或 Claude Code 裡運作，因為兩者的基本元件相同。

核心主張：別再寫提示，改為設計迴圈#

這篇文章以業界各自獨立得出、最後彼此呼應的兩句話為基礎：

• Peter Steinberger（Peter Steinberger）：「你不該再提示程式設計代理程式了。你應該設計會提示代理程式的迴圈。」
• Boris Cherny（Claude Code 負責人）：「我現在不再提示 Claude。我讓迴圈持續運作，由迴圈提示 Claude 並找出該做什麼。我的工作是寫迴圈。」

依這種說法，迴圈是個遞迴目標：你設定一個目的，代理程式便反覆執行，直到完成為止。每個迴圈的核心都是相同的四步循環——行動、觀察、推理、重複；代理程式採取行動、讀取回傳結果、判斷結果相對於目標代表什麼，再決定是否繼續。

迴圈工程位於代理程式 harness 之上一層（代理程式 harness 工程）：harness 是單一代理程式執行的環境；迴圈則是在計時器上運作的 harness，會產生輔助代理程式，並自行回饋。Osmani 公開表示懷疑——「現在還很早」——也強調成本上的但書：token 用量會因你「token 充裕或拮据」而大幅不同。

五種基本元件，再加上記憶#

迴圈需要五樣東西，此外還需要一個記錄事項的地方。Codex app 和 Claude Code 現在都提供對應的基本元件：

1. 自動化——自行執行的排程式探索與分類。這是讓迴圈成為迴圈而非一次性執行的心跳。→ Agent Loop Pattern
2. 工作樹——彼此隔離的平行檢出環境，避免兩個代理程式在同一檔案上互相衝突（相當於兩位工程師提交了同一行程式碼）。→ Agent Harness Engineering
3. 技能——用 SKILL.md 檔案記錄專案知識，避免代理程式自行猜測；兩種工具使用相同格式，而符合條件的描述會觸發隱式呼叫。→ Agent Context Files
4. 外掛／連接器——以 MCP 為基礎的整合，讓迴圈能操作真實工具（議題追蹤器、資料庫、staging API、Slack），而不只限於檔案系統。→ MCP and Computer Use
5. 子代理程式——一個代理程式提出想法，另一個負責檢查；做事的人評分自己的作業時，往往會太寬容。→ Verification as the New Bottleneck

第六樣東西是記憶：一個 markdown 檔案、一個 Linear 看板，任何存在於單一對話之外、能記錄已完成事項與下一步的東西都可以。「代理程式會忘記，儲存庫不會。」這與所有長時間運作的代理程式仰賴的「寫在磁碟上、不放進上下文」技巧相同（請見 Agent Harness Engineering 的「儲存庫作為系統紀錄」以及 Agent Context Files 的狀態與政策區分；Ticket-Driven Agent Orchestration 則是 Linear 看板形式）。

第六種基本元件有一項受控測量作為佐證。Knowledge-Centric Self-Improvement 使用一個代理程式刻意設為可拋棄式的迴圈——每次嘗試都使用全新上下文，除了狀態檔案之外不繼承任何東西——並顯示外部記憶本身就能促進改善：通用代理程式加上精選儲存庫，在五個基準測試中以更低的美元成本勝過 DGM、HyperAgents、GEPA 和 OpenEvolve；即使替換掉編寫儲存庫的模型家族，凍結的儲存庫仍然有效。有兩項設計要點可直接套用到 MEMORY.md 形式的狀態檔案：記錄適用條件，而不是結論（每筆項目都記載何時適用、何時不適用），並且限制交付的內容——他們的轉移介接器將每個欄位限制在 0-3 項，若先前資訊關聯性很低，就回傳空清單，因為固定數量的交接會讓記憶「變得雜訊太多，甚至有害」。只會不斷增長的狀態檔案，就是失敗模式。

不綁定工具：Codex app ≈ Claude Code#

這篇文章的核心結構觀察是，兩項產品如今都具備五種基本元件，只是對相同能力使用不同名稱：

基本元件	在迴圈中的用途	Codex app	Claude Code
自動化	排程探索與分類	Automations 分頁 → Triage 收件匣；/goal 用於執行直到完成	排程工作／cron、/loop、/goal、hooks、GitHub Actions
工作樹	隔離平行功能	每個對話串一個工作樹	git worktree、--worktree、子代理程式上的 isolation: worktree
技能	記錄專案知識	Agent Skills (SKILL.md)、$name 或隱式呼叫	Agent Skills (SKILL.md)
連接器	連接你的工具	Connectors (MCP) + 外掛	MCP 伺服器 + 外掛
子代理程式	發想與驗證	.codex/agents/ 中的 TOML 代理程式	.claude/agents/ 中的子代理程式、代理程式團隊
狀態	追蹤已完成事項	markdown 或 Linear 連接器	markdown (AGENTS.md、進度檔案) 或 Linear MCP

結論是：「一旦你看出形狀相同，就不再爭論要用哪個工具——只要設計一個無論身在何處都能運作的迴圈。」這是部署面上的證據，支持 Harness Shrinkage as Models Improve：過去得靠人工維護的 bash harness 才有的能力，正被吸收到產品中，成為具名基本元件。Osmani 特別指出一個清楚的細節：技能是編寫格式，外掛則是發佈方式——把技能與連接器打包成外掛，就能在不同儲存庫間分享。

Osmani 的文章發表兩週後，Google 提供了迄今最有力的佐證，證明迴圈不綁定工具：其 Agent Quality Flywheel 將完整的評估與修復迴圈（合成情境 → 評分 → 分析 → 提出修正 → 比較基準）封裝為可安裝的技能，由你已在使用的任何程式設計代理程式驅動——一家供應商將預先設計的迴圈打包，交由其他供應商的代理程式執行，並內建做事者與檢查者分工，如同 Optimizer–Evaluator Decoupling。

/goal：將做事者與檢查者分工套用到「完成」#

最接近整個概念的工作階段內基本元件是：/loop 依固定間隔重跑，但**/goal 會持續執行，直到你寫下的條件確實成立**——而且每輪結束後，會由另一個較小的模型檢查是否完成，因此寫出程式碼的代理程式不會負責評分自己的成果。你告訴它「test/auth 中所有測試都通過，且 lint 沒有問題」，然後就可以離開。Codex 也提供相同的 /goal（可驗證的停止條件、暫停／恢復／清除）。這是將做事者／檢查者分工套用到停止條件本身——這正是你能放心讓迴圈無人看管地停止的原因。

停止檢查器有雜訊時，執行迴圈比不執行更糟#

/goal 的獨立停止檢查器回答的是「由誰決定已經完成」。但它沒有回答：當這個決策者不可靠時該怎麼辦？Wu 等人（2026）（empirical）測量了這種情況的代價。在檢查器與修復器都有雜訊的驗證與修復迴圈中，固定五輪修復預算的最終真實有效率為 0.116，而提交第一份草稿則為 0.700；隨著預算增加，結果會單調惡化（K = 1/3/5 時分別為 0.246 / 0.122 / 0.116）。回報的接受率卻一路上升，因為驗證器的通過率是 ρ₀ + J·Q——當判別力 J 很低時，主要反映的是驗證器本身的誤接受率。

有三項發現可直接用於迴圈設計：

• 輪數上限是失敗模式，不是安全網。「最多修復 K 次」這種方案會崩潰；所有接受門檻啟發式（多數決、信心門檻）都只是逐漸接近不做修復，而且從未勝過不修復。唯一勝出的方案，是針對每個個案比較再做一輪的預期收益與預期損害。
• **停止界線取決於修復器，不是檢查器。**界線位於 b* = α/(α+β)——修復成功數除以修復成功數加修復破壞數——測得的數值會因設定而介於 0.954 和 0.289 之間，因此固定預算或通用信心門檻都無法直接套用到不同迴圈。
• **檢查器品質低於某個程度，就別做校準。**當判別力接近零時，不需標記資料的校準會隨著資料增加而更加嚴重地退化；解方是無須估計的「保留最佳結果」規則（除非挑戰版本通過明確的票數差距門檻，否則保留目前版本），可讓數值從 0.223 回升至 0.793。

在套用時必須留意研究範圍的限制：驅動這些損害率的情況，大多是刻意向修復器注入遭竄改的問題陳述；研究任務是 GSM8K 風格的數學題，不是程式碼儲存庫。可泛化的結論是這種模式——檢查器薄弱的無人值守迴圈可能進入負報酬區間，而輪數預算和通過率門檻都無法找出其臨界點。

撰寫目標：在 rustc、zlib 和 Keycloak 上實際執行的團隊提出三條規則#

以上談的都是由誰決定已經完成。Trail of Bits 的 Patch the Planet 實作紀錄（2026-07-28，case-study）是本資料集中第一篇以生產規模說明如何撰寫目標的記錄——數位工程師讓 Codex 連續數週檢查「全球使用最廣泛、稽核最嚴格的一些程式碼庫」，最後各自歸納出三條規則。請把它視為單一團隊附帶宣傳聯名的實務經驗（這項活動由 OpenAI 聯合舉辦，文章同時推廣其方法與 Codex）；其中沒有任何內容經過 A/B 測試。文章也直接提供兩項框架修正：

• **/goal 是一種模式，不是一條命令。**文章用 /goal「泛指以目標為基礎的提示」，並指出 Codex 可以透過工具呼叫替自己設定目標——「我們建議大家都這麼用；我們自己很少手動輸入斜線命令。」 上表把 /goal 列為自動化欄位的基本元件；但實際上，重度使用者已不再手動輸入它。
• **執行結果在開始前就已大致決定。**文章寫道：「/goal 會忠實追求我們交給模型的任何結果，也就是說，執行結果大多在模型開始之前就決定了。」 這正是本頁的核心主張——槓桿在迴圈設計，而非操控代理程式——而說出這句話的人，衡量成果的指標是 CVE。

1. 讓模型撰寫目標，再讓它攻擊自己的目標。他們最常重複提起的內部訣竅是：把威脅模型檔案和目標交給 Codex，請它撰寫目標提示。理由是「Codex 最了解 Codex」——它能把威脅模型轉換成可測試的成功條件，指出值得優先檢查的程式碼路徑，並把結果描述得足夠精確，讓執行過程得以收斂；所需時間遠少於從零開始撰寫。值得借鏡的是後半段：「你定義的任何結果，都可能以你意料之外的方式達成，而模型往往最先看出有哪些簡單的取巧路徑。」 因此，現在撰寫步驟會以模型對自己的目標進行紅隊測試作結——找出未來模型可能偷懶的方式，並在執行前修改條件、排除這些漏洞。如果單靠承諾不夠，他們就會建置一個儀器：aicov 追蹤 Codex 實際讀過哪些程式碼行，因為「即使明確要求，Codex 還是常常會略過整個程式碼庫」，所以它「不能『作弊』」。這是外部覆蓋率追蹤器，而非自我回報——請見 Task Gaming。

2. 定義結果，不定義路徑——而結果有一段校準區間，兩端各有一種失敗。「定義結果時，想花多少 token 都可以；告訴模型如何達成結果時，幾乎不必花 token。」如果你要做模糊測試，指示到「使用模糊測試」就夠了；「以我現有的模糊測試 harness 為基礎」會排除模型可能找到的更好方法，而「規定路徑的目標，保證 Codex 不會採取其他路徑。」需要調校的是結果本身，兩種失敗模式都有記錄：

結果規格	結果
已知錯誤的確切根本原因，再加上「尋找變體」	一無所獲。「範圍太窄」
用一句話描述同一已知錯誤的類別	「找出了許多錯誤。我們回報了 9 個，其中 3 個已修正並合併至上游」
「找出 [X] 中的錯誤」	永不終止——「無從判斷何時完成」，找出沒有實際影響的問題並浪費 token

中間那一列是本資料集中對「上下文越多越好」最有力的反例：同一個任務，拿掉對目標最精確的描述，就從零結果變成找到值得回報的上游修補。（專案和錯誤均未具名；比較是單一團隊的回憶，且第一列沒有附上數量。）此外還有兩項佐證做法。完整的結果定義會說明哪些情況不算完成——面對經過嚴格稽核的程式碼，/goal 不只一次回報「找不到錯誤」；他們把它視為中間結果，而非完成條件，並直接將持續搜尋寫入目標（請見 Stopping Under a Noisy Verifier，了解為何這種做法在此處安全、但不一定普遍適用）。另一項常設文件是 THREAT_MODEL.md，幾乎每個執行過的目標都會引用它，因為它「精確定義有效錯誤的樣貌，卻不解釋如何尋找錯誤」——也就是將目標的結果部分從提示抽離，移到儲存庫中。這是把 Agent Context Files 的政策／狀態區分套用到成功條件，而非程式碼規範。

3. 每個代理程式只設一個結果。在同一目標中要求兩種互相競爭的結果，會「一再」導致最佳化不均——要求找出錯誤並且提高覆蓋率，通常只會把其中一項做得遠比另一項好。在 zlib 上，Codex 不斷對最先找到的區域進行模糊測試；把覆蓋率要求加進提示後，它的最佳化方向就轉向覆蓋率，結果「漏洞搜尋表現平平」。解法是把覆蓋率完全從提示移除：先執行一輪，在讀完整個程式碼庫後找出最值得攻擊的五個攻擊面，接著針對每個攻擊面各開一個獨立的 /goal 工作階段，另外再開一個完全開放式工作階段，探索其他工作階段沒有負責的部分。這就是 LLM-Driven Vulnerability Research 中 Rust 流程採用的分流規則——每項 P-critical 議題分配一個 Codex 工作階段——也比「一個代理程式提出想法，另一個代理程式負責檢查」更精確地描述子代理程式的用途：要拆分的是目標，而非任務。

文章自身的限制，正是本頁第三項但書。「只有在你清楚知道自己要找什麼時，才能寫出好的提示」——成效「仍仰賴專家知道該去哪裡找、驗證結果是否足以構成可回報的發現，以及了解另一端的維護者實際想看到什麼。」迴圈設計無法取代領域判斷；它會放大判斷力，而放大效果取決於專家能否寫下成果。

一個迴圈的實際樣貌#

Osmani 描繪的實例是：每天早上由一項自動化工作執行分類技能，讀取昨天的 CI 失敗、未處理議題和近期提交，並把發現寫入 markdown 檔案或 Linear 看板。對每個值得處理的發現，系統都會開啟獨立工作樹，派出一個子代理程式草擬修正，再由第二個子代理程式依據專案技能與現有測試審查草稿。連接器負責開啟 PR 並更新工單；迴圈無法處理的事項則進入分類收件匣，交由人員處理。狀態檔案是骨幹——它記得嘗試過什麼、哪些通過、還有哪些未完成，因此隔天的執行會從今天停止的位置接續。「你只需設計一次。每個步驟都不必由你逐一提示。」

迴圈仍無法替你處理的事#

迴圈會改變工作方式，但不會讓人類從流程中消失。迴圈愈完善，有三個問題反而會更尖銳，而非更容易解決——Osmani 逐一點名（這些是他在部落格系列中使用的詞彙；本文連結了 wiki 中相應概念的介紹）：

• 驗證仍是你的責任。「無人值守的迴圈，也可能無人值守地犯錯。」即使有子代理程式負責驗證，「完成」仍是一種說法，而非證明——「你的工作是交付你已確認可正常運作的程式碼。」→ Verification as the New Bottleneck
• **放任理解能力生疏。**迴圈交付你未曾撰寫的程式碼愈快，實際存在的內容與你理解的內容之間的落差就愈大——Osmani 稱之為理解債務，是 Agentic Technical Debt 的認知面手足。解方是不可委派的瓶頸：理解：閱讀迴圈產出的內容。
• **最舒適的姿態也最危險。**迴圈自行運作時，人很容易不再表達意見，照單全收——也就是認知屈從。「有判斷力地設計迴圈，是解方；若以此逃避思考，就是催化劑——同一個行動，結果截然相反。」這是將「留在迴圈中，把它們當成工具」改寫成無人值守的情境。

第四個問題貫穿技能這項基本元件：沒有技能，迴圈每一輪都會從零重新推導整個專案——這是 Osmani 所說的意圖債務。技能是「寫在外部」的意圖，能不斷累積，而非每次都重新猜測（請見 Agentic Technical Debt、Agent Context Files）。人工審查的上限也確實存在：工作樹能消除機械層面的衝突，但「你能實際執行多少項工作，取決於你的審查頻寬，而非工具」——這就是無人值守分流受限於監督疲勞／管理幅度的瓶頸。

已部署的終點：能自行維護的程式碼庫（Anthropic，2026 年 7 月）#

Boris Cherny 在 YC 訪談中描述了 Osmani 所描繪的形式，如何在 Anthropic 的生產環境中大規模運作：「我們現在真的有 Claude 在維護自己。」 團隊在 Slack 頻道中開始讓 Claude 執行一組例行程序（雲端迴圈——使用相同的基本元件，而且筆電關閉後仍會繼續運作），對象是自己的程式碼庫：CLI、iOS、Android、桌面版。如今，所有程式碼庫每天合計執行 20–30 個例行程序，每項只用一句提示：

• 清理死碼——每天掃描靜態與動態分析結果，並每天送出刪除 PR（「我們沒有提示它做這件事，它就是自己想到了」）
• 交付完成的實驗——某項實驗達到 100% 推出比例，就刪除其旗標並交付
• 撰寫缺少的測試——補上覆蓋率缺口；反向操作則是刪除無用測試，這些測試是「較舊的模型或某些時候的人」加進去的
• 「抽象警察」——找出大型程式碼庫中彼此相近、後來逐漸分歧的抽象，並將其統一

Cherny 對此提出的主張是：每天數百至數千個代理程式，能完成「數十或數百位工程師的工作」，而且「我們正朝著完全自動化應用程式維護的方向前進」——讓工程師能投入新產品和接觸使用者。他的分類法區分了這種做法與動態工作流程：工作流程是把一項任務拆成多個協調執行的部分；迴圈／例行程序則是重複執行一項任務，「不共用上下文，但可能共用記憶」。這些都是 practitioner-opinion、第一方說法，沒有公開指標——但它是迄今最具體的案例，呈現文章中的主張如何成為持續運作的基礎設施，且同一模型同時擔任做事者與維護者。

這究竟是哪一種迴圈？#

Osmani 文章發表兩週後，Andrew Ng 回應迴圈工程「因 Boris Cherny 和 Peter Steinberger 提到它後迅速走紅，如今成了熱門流行語」，並回答文章沒有提出的問題：究竟是哪一種迴圈？ Ng 的三迴圈分類法將本頁所有內容都放進最內層迴圈，也就是代理程式能獨自以分鐘為間隔完成的迴圈。外面還有兩個較慢的迴圈：開發者回饋迴圈（人類檢視建置結果並重新引導，耗時數十分鐘到數小時），以及外部回饋迴圈（朋友、初期測試者、A/B 測試——數小時到數週），而只有這個迴圈會修改願景，而非規格。

這種重新框定很有用，因為它界定了這門學問的範圍。五種基本元件能加快內層迴圈，卻對外面兩層毫無作用；產品的速度取決於最慢的迴圈。它也預示了與 Ambrosino 的「迴圈已經過時了」（Vibe Coding vs. Agentic Engineering）之間的論點會如何發展：內層迴圈是harness，會因能力提升而被吸收（Harness Shrinkage as Models Improve）；外部迴圈則是產品開發的結構，不會消失。

槓桿點已經改變#

兩個人可以打造完全相同的迴圈，結果卻截然相反——一個人在深入理解的工作上加快速度，另一個人則完全逃避理解工作；「迴圈不知道兩者的差別，你知道。」Cherny 的重點不是工作變得更容易，而是槓桿點從撰寫提示轉移到設計迴圈，而這比提示工程更難，不是更容易。Osmani 在結尾提出平衡的看法：建立你的迴圈，但別忘記直接提示仍然有效——「依照你打算繼續當工程師、而非只負責按下開始的人來設計。」

相關連結#

• Layered Supervision — 本頁迴圈留下未解的協調層問題，並從實務角度處理。該來源直接引用 Osmani，將迴圈工程放在其主題下一層，並報告實務工作者如何應對迴圈所代表的逐步參與減少：逐步觀察生成過程並及早中斷；另有規劃子代理程式，再由另一個代理程式排序，該代理程式的明確目的，是偵測「某個代理程式已完全偏離方向」的情況。這是尚未自動化的 /goal 停止檢查，而且仍由人類負責

• Reviving Impractical Quality Tools — 將迴圈條件視為品質關卡：「你必須持續修改程式碼，直到這個工具說可以為止」，並以變異測試和複雜度評分作為終止條件

• Vibe Coding vs. Agentic Engineering — Ambrosino 的「迴圈已經過時了」，標記前線正從協調式迴圈走向自主開發，以及受監督與無人監督的開發模式

• Agent Loop Pattern — 迴圈的基本元件（/loop、例行程序、Ralph Wiggum）；迴圈工程則是在其上層的系統設計方法；自動化就是依排程執行這種基本元件

• Agent Harness Engineering — Osmani：「迴圈工程比 harness 高一層」；harness 設定計時器、產生輔助代理程式並自行回饋；提供工作樹隔離和外部記憶的基本元件

• Harness Shrinkage as Models Improve — 部署面的證據：bash 腳本堆成的迴圈正被吸收到產品中，成為具名基本元件；隨著各元件內建於工具，harness 也逐漸縮小

• Verification as the New Bottleneck — 做事者與檢查者子代理程式分工，以及 /goal 使用新模型進行停止檢查；「交付你已確認可正常運作的程式碼」；審查頻寬是無人值守分流的上限

• Agent Context Files — 技能是「寫在外部」的意圖；技能作為編寫格式、外掛作為發佈方式的區分；狀態檔案則是記憶

• MCP and Computer Use — 連接器／外掛（MCP）是讓迴圈能在真實工具中操作、而非只操作檔案系統的基本元件

• Outsource Your Thinking, Not Your Understanding — 迴圈加快後，理解債務與認知屈從問題會更加明顯；理解仍不可委派

• Agentic Technical Debt — 意圖債務（迴圈每輪都重新推導專案）是同一種累積偏差失敗；技能則是維持上下文的解方

• Jagged Intelligence (Ghosts, Not Animals) — 「留在迴圈中」是避免認知屈從的解方

• Ticket-Driven Agent Orchestration — 以 Linear 看板作為狀態，是記憶基本元件所形成的持續工作圖

• AI Brain Fry / Human-AI Accountability Redesign — 人類監督無人值守迴圈的限制；管理幅度改造是尚缺的配套

• Boris Cherny — 「我的工作是寫迴圈」；核心實務工作者；其團隊部署了自我維護的程式碼庫群

• Dynamic Workflows: An Algebra for Agents — 鄰近的基本元件：工作流程將一項任務交由分階段的代理程式執行；迴圈／例行程序則是不共用上下文、依排程重複一項任務

• Peter Steinberger — 首先提出「設計會提示代理程式的迴圈」這項文章核心框架

• Claude Code / Symphony — 如今已具備五種基本元件的工具介面（Claude Code 與 Codex 端的協調堆疊）

• Agentic Work Systematization — 技能基本元件在經驗證據與採用曲線上的對應：OpenAI 的 Codex 研究測量臨時做法轉為可重用例行程序的系統化過程（技能使用率從 5.4% 升至 26.6%，OpenAI 內部為 96.2%）

• Parallel Agent Orchestration — 迴圈產生的分流有經測量的數據：「你能執行多少項工作，取決於你的審查頻寬」是 OpenAI 數據所記錄、同時執行 5 個以上代理程式工作流程的上限

• Agent Quality Flywheel — 供應商打包的迴圈：Google 將評估與修復循環包裝成技能，可由任何程式設計代理程式驅動；迴圈設計成為產品，而非手工打造

• Optimizer–Evaluator Decoupling — 做事者／檢查者分工，以及 /goal 的獨立停止檢查器，是改善迴圈的架構不變條件

• The Three Loops of AI-Native Building — Andrew Ng 的分類法界定這門學問的位置：五種基本元件都在最佳化三層迴圈中最內層的一層；開發者回饋和外部回饋迴圈不受影響，產品速度取決於最慢的那一層

• Unknowns as the Agentic Bottleneck — 將理解債務變成可檢查的問題：Thariq Shihipar 的測驗關卡（「只有在我完美通過測驗後，我才會合併」）是本頁所說缺口的第一個具體檢查工具

• Risk-Tiered Auto-Approval — PostHog (case-study) 用迴圈處理鄰近審查的瑣事：PR 監督迴圈（CI 監控、重跑不穩定測試、更新分支、分類留言），以與 Haack 的 babysit-prs 相同的掃描／狀態設計為基礎；qa-swarm 審查小組會反覆執行外層迴圈，直到沒有新的可行動討論串；自動蓋章器則判斷哪些 PR 完全不需要人工審查。這也提供了本文預算問題缺少的具體成本數據——Paul D'Ambra：「我的 token 支出大概有 60% 花在自動處理 CI 與審查的瑣事上，我完全不後悔花這一分錢」

• Knowledge-Centric Self-Improvement — 將記憶基本元件提升為改善與測量的對象：可拋棄式代理程式、唯一持續狀態是外部精選儲存庫，以及依任務限制狀態檔案交付內容的規則

• Stopping Under a Noisy Verifier — 以決策理論和實測失敗區間界定停止條件：檢查器判別力低時，固定輪數預算遠比提交第一份草稿糟（0.116 對 0.700）；界線取決於修復器而非檢查器；檢查器品質低於某個程度時，應停止校準並保留目前最佳版本

• LLM-Driven Vulnerability Research — 迴圈中部署風險最高的實例，也是本資料集中唯一記錄目標提示如何以外部真值為依據的案例：每項 Rust P-critical 議題由一個 Codex /goal 工作階段處理，並經過安全分類以及兩種不同模型的裁判把關，最後找到 soundness 漏洞與錯誤編譯問題，並在 Rust 1.98 修正。該文也提供本頁唯一一組結果具體程度的前後比較：精確的根本原因描述一無所獲；一句話的錯誤類別描述則找出許多錯誤，回報 9 項，其中 3 項已合併至上游

• Task Gaming — 目標撰寫步驟試圖防範的失敗模式，以及生產團隊各自獨立採取的兩項緩解方式：執行前讓模型對自己的成功條件進行紅隊測試，找出「未來模型可能偷懶的方式」；並測量自我回報無法證明的特性（aicov 追蹤 Codex 實際讀過哪些程式碼行，因為即使要求不要略過，Codex 還是會跳過程式碼庫）。這就是從迴圈設計角度推導出的「評分狀態，而非回報」

• Review as the Control Point — 「將人工審查納入代理程式自己的迴圈／由第二個子代理程式檢查第一個」是 CMU 理論綜合整理出的其中一種觀點；其中自動化審查是一種審查動態因素（提高吞吐量、降低延遲，但對品質與安全的影響仍有爭議），而該理論也將做事者／檢查者迴圈仍會累積的理解債務形式化

• The Committed-Artifact Chain — 將相同迴圈畫在組織流程邊界，而非單一工程師的終端機內。Anthropic Applied AI 手冊（vendor-claim，2026-08-21）提出的升級流程，與本頁的描述相同——「首先，你手動提示每個步驟，直到最終狀態成為一個迴圈；每個獲准的成品都會觸發下一道關卡」——但提示者改成合併事件：接受 intent.md 會觸發非互動工作，將 spec.md 作為 PR 提交；核准規格會觸發計畫模式；合併 PR 則觸發管線。其維護階段完全將人類從呼叫流程中移除：確定性偵測器監看一項生產指標，數值超出控制範圍時就呼叫 Claude；該程序無狀態且不需互動，因此「迴圈可以在沒有人啟動的情況下自行開始和結束」，診斷結果則以新的 intent.md 回到計畫階段。本文所列基本元件未提及兩項限制：停止條件是一個由服務負責人處理的分類佇列，而非代理程式自己的判斷；最高層級可啟動的回復流程「應該是整條管線中演練最充分的路徑」，而且應在迴圈真正需要之前定期於 staging 環境中演練。

尚待釐清的問題#

• Osmani 對成本的但書沒有量化：持續運作的迴圈要到多少 token 預算時才不再划算？又該如何為它配置儀器？（參見 Agent Loop Pattern 中「模型自行安排迴圈時，誰負責預算？」）**部分解答（僅有規模）：**一位執行審查／CI 迴圈的 PostHog 工程師表示，這約占他個人 token 支出的 60%，但他不後悔（Risk-Tiered Auto-Approval，case-study）——這證明支出占比可以過半，仍被認為值得；但這是個人自評占比，不是損益兩平門檻，也不是找出門檻的工具。
• 如果 /goal 的停止檢查器本身也是模型，那誰來驗證驗證器？做事者／檢查者分工將信任問題往上推了一層，而非消除問題。部分解答（2026-08-04）——信任問題有所界定，但尚未解決：Wu 等人（empirical）並未驗證驗證器，而是把它的不可靠程度轉成可測量的純量（Youden's J = 1 − ρ₀ − ρ₁），並說明各種數值下可以採取哪些行動。當 J ≥ 0.18 左右時，迴圈可以根據對檢查器雜訊程度的校準估計採取行動，與真實參數基準值的差距可保持在 2.8pp 之內；當 J = 0.03 時，不需標記資料的校準便會崩潰（而且資料愈多，崩潰得愈嚴重），正確作法是停止信任任何估計，改採無須估計的「保留最佳結果」規則。尚未解決的部分，正是問題實際詢問的內容：測量 J 本身需要少量人工標記的探測資料，所以信任問題只是移到人工標記的樣本上，並未消失。第二項部分解答（2026-08-12），來自實務，而非理論：一個生產環境安全團隊以增派人手處理信任問題：Trail of Bits（case-study）會先執行安全關卡，再由兩個不同模型執行裁判且必須達成共識（一個判斷合理性，另一個專注於 PoC 並要求可重現），接著進行人工篩選與重複項目檢查；團隊也另外建置非模型儀器（aicov 行讀取覆蓋率），測量自我回報無法證明的特性。這是實際團隊認為有必要的做法——模型多樣性、外部測量，以及最後一道人工把關——但文章沒有公布任何階段的誤判率，所以這記錄的是團隊判斷必要的措施，而非這些措施實際攔截了多少問題。
• 迴圈工程是否會收斂成一種主導形式（早晨分類 → 工作樹 → 做事者／檢查者 → PR），還是會分化成許多依慣例而異的迴圈？文章描述的是一種「我一直採用」的形式，卻也主張這些基本元件具有通用性。

資料來源#

• Loop Engineering — Addy Osmani，「Loop Engineering」（addyosmani.com，2026 年 6 月；經 X 傳播）
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny，YC 訪談（2026-07-27，practitioner-opinion）：每天 20–30 個自我維護例行程序（清理死碼、交付實驗、撰寫／刪除測試、抽象警察），以及工作流程／迴圈／例行程序的分類法
• Driving the Agent Quality Flywheel from Your Coding Agent- Google Developers Blog — 封裝成程式設計代理程式驅動技能的評估與修復迴圈（vendor-claim）
• Thread by @AndrewYNg — Andrew Ng，The Batch（2026-06-30），practitioner-opinion：這門學問實際最佳化的是三個巢狀迴圈中的哪一個
• How we use /goal to find bugs in Patch the Planet — Trail of Bits，2026-07-28（case-study；與 OpenAI 的 Patch the Planet 活動共同署名，並推廣作者自己的方法與 OpenAI 的 Codex）：三條經實務歸納出的目標設計規則、/goal 是工具呼叫而非斜線命令的說明、結果校準比較（精確根本原因 → 一無所獲；一句話錯誤類別 →「許多錯誤……回報 9 個，其中 3 個已修正並合併至上游」；「找出 [X] 中的錯誤」→ 永不終止）、THREAT_MODEL.md 做法、zlib 中錯誤搜尋與覆蓋率的衝突、五個攻擊面的分流、aicov，以及最後對人類判斷的限制。本文沒有任何數據測量——沒有執行次數、比率、成本或 token 預算；校準比較是單一團隊的回憶，且沒有說明專案和錯誤的名稱。Rust 的錯誤類別發現與 P-critical 流程收錄於 LLM-Driven Vulnerability Research
• Verify, Repair, Repeat, or Stop? Robust Stopping for Noisy Verify-Repair Loops in LLM Agents — Wu、Shen、Yang、Peng 與 Hu（arXiv 2607.17641，2026-07-20，empirical）：§5.3 表 1 和附錄 D 表 6——固定輪數預算崩潰，以及勝過固定預算、依個案判斷邊際收益的規則；詳見 Stopping Under a Noisy Verifier