譯者註：本文翻譯自 Addy Osmani 的開放指南《Loop Engineering: Stop Asking Me What It Is》， 由 HuaShu 格式化為 IEEE 會議論文格式，原文免費提供。 原始 PDF 翻譯目的為方便中文讀者閱讀，如有疑義請以原文為準。
在過去兩年中，一連串以「XX 工程（XX Engineering）」為名的術語緊隨著模型發布的步伐相繼出現。這份筆記探討了其中最新的術語——「迴圈工程（Loop Engineering）」。此術語於 2026 年 6 月由 Peter Steinberger、Boris Cherny 和 Addy Osmani 獨立提出，並由 Osmani 首次在書面中命名。與提示詞工程（Prompt engineering）、上下文工程（Context engineering）或安全裝置工程（Harness engineering）不同，迴圈工程並非教導從業者如何更好地完成工作，而是將從業者完全從具體工作中抽離。我們定義了此術語，將其歸為安全裝置（Harness）之上的第四層架構，並將迴圈的單次執行（Turn）拆解為五個動作——探索（Discovery）、交付（Handoff）、驗證（Verification）、持久化（Persistence）和排程（Scheduling）——以及實現這些動作的六大元件。我們特別關注生成者與評估者（Generator/Evaluator）的分離：從經驗來看，被要求為自己輸出評分的代理人（Agent）往往會自我讚美，而調整一個獨立且抱持懷疑態度的評估者，遠比讓生成者對自己的工作進行批判更具可行性。我們調查了實務中運行的三個迴圈，從一位工程師的早晨分類工作，到 Stripe 公司每週合併超過 1,300 個機器撰寫之拉取請求（Pull Request）的企業級流水線，並編錄了四個在無形中累積的代價——驗證債（Verification debt）、理解退化（Comprehension rot）、認知棄守（Cognitive surrender）和 Token 暴增（Token blowout）。最後，我們提供了建構第一個迴圈的具體方法。核心觀點是：迴圈使生成幾乎變得免費，而讓判斷力成為稀缺資源；由兩個人建構同一個迴圈，可能會產生截然相反的結果。
索引詞（Index Terms）——代理型 AI（Agentic AI）、軟體工程（Software engineering）、自主代理人（Autonomous agents）、編碼代理人（Coding agents）、生成者-評估者（Generator–evaluator）、排程（Scheduling）、自動化（Automation）。
提示詞工程課程依然熱銷，上下文工程的墨水未乾，而安全裝置工程才剛被記錄下來。如今，迴圈工程也悄然登場。在過去的一年裡，這些「XX 工程」術語幾乎與模型發布同步出現，人們難免會想對此嗤之以鼻。
但這一次有所不同。它並非關乎如何更好地完成工作，而是將從業者完全從具體工作中抽離。早期的術語都假設有一位人類坐在鍵盤前，逐行指導代理人。迴圈工程刪除了這個假設。從業者不再處於迴圈之內（Inside the loop），而是站在迴圈之外（Outside the loop）建構迴圈。
提出該術語並將其記錄下來的人是 Google Chrome 團隊的工程師 Addy Osmani。他的定義很簡短：迴圈工程是取代自己作為提示代理人的人，並設計出取而代之的系統。我們不再需要逐行餵給代理人指令，而是設計出一個自動為其提供指令的系統。這句話的重點在於「取代自己（Replacing yourself）」。這是一次位置的轉變——從作為引擎本身，轉變為設計引擎的人。我們所寫的不再是給代理人看的文字，而是能夠自動向代理人發送文字的系統。
這個術語並非憑空發明。在 2026 年 6 月的某一週內，數個團隊幾乎在同一時間遇到了同樣的問題。引爆點是 OpenClaw 的作者 Peter Steinberger 發表的一篇突破 800 萬瀏覽量的帖子：我們不應該再向編碼代理人（Coding agent）進行提示，而應該設計那些能夠提示它們的迴圈。幾乎在同一時間，Anthropic 負責 Claude Code 的主管 Boris Cherny 也在說同樣的話——他不再主動向 Claude 發出提示，而是運行一些迴圈來向 Claude 發出提示並弄清楚下一步該怎麼做，他的工作就是撰寫迴圈。6 月 7 日，Osmani 在其部落格上以《迴圈工程》（Loop Engineering）為題發表了文章，整合了 Steinberger 和 Cherny 的觀點，並在次日同步發布於 Substack。一次點火、一次迴響、一個命名，皆在一週之內完成。
將這三個陳述放在一起，它們指向同一個轉變：我們設計的對象已從代理人的單一行為，轉變為驅動代理人的整個系統。與之前的「直覺編碼（Vibe coding）」一樣，這個術語聽起來可能有些粗糙，但它將一種工作方式轉化為可供討論的實體。
值得思考的是，為何三位事前未曾交流的從業者，會在同一週內想到同一個詞。答案是，周邊的工具已在不知不覺中跨越了臨界點。編碼代理人已變得足夠可靠，可以在無人看管的情況下完成非瑣碎的任務；排程原語（Scheduling primitives）已出現在各大安全裝置中；而單次代理人運行的成本已降得足夠低，以至於在定時器上重複運行不再顯得浪費。當所有零件都齊全時，將它們結合起來的舉措對所有人來說都變得顯而易見。名稱滯後於實務數個月：在任何人稱其為迴圈工程之前，人們就已經在撰寫迴圈了，就像在生成者/評估者分離有了正式名稱之前，團隊就已經在使用寫作者代理人（Writer agent）搭配審查者代理人（Reviewer agent）一樣。
這種「實務先行，命名在後」的模式值得銘記，因為它告訴讀者該去哪裡尋找下一個術語。它不會來自某次模型的發布，而是來自某個新功能變得足夠便宜、以至於先前不可想像的組合方式變成常態的那一刻。
這個轉變可以簡化為兩句話。在舊世界中，你坐下來逐行提示代理人；它完成一件事後便會停下來，等待下一個指令。你是迴圈內部的人類時鐘，每一次滴答都必須來自人類。在新世界中，你設計了一個能夠自己滴答運行的系統——它依據定時器運行、產生助手來執行工作，並將自己的結果回饋給自己。
正如 Osmani 所說，迴圈工程位於安全裝置之上一層：下方的安全裝置負責武裝單次的代理人運行；上方的迴圈則使其一遍又一遍地自我運行。這是一種身分的轉變，從操作代理人的人，轉變為對其進行排程的人。價值的焦點從「知道如何指導」轉向「知道如何建構迴圈，以及如何在迴圈中放置一個可以說不（No）的檢查機制」——正如隨後章節所解釋的，最後一部分是最困難的。
[圖 1：四層堆疊架構（The Four-Layer Stack）。每一層關注的範圍都比其下方的層級更大；迴圈工程將安全裝置留下的「等待你」這一步驟自動化。圖中文字由下至上為：提示詞工程（Prompt engineering，為模型撰寫的字句）→ 上下文工程（Context engineering，此時放入視窗的內容）→ 安全裝置工程（Harness engineering，武裝單次運行：工具、動作與「完成」判定）→ 迴圈工程（Loop engineering，使其一遍又一遍自我運行）。範圍隨之向上一層增長。]
四層堆疊（The Four-Layer Stack）
| 層級（Layer） | 關注對象（What it minds） | 核心問題（Core question） |
|---|---|---|
| 提示詞工程（Prompt eng.） | 撰寫一個優質提示詞 | 我應該告訴模型什麼 |
| 上下文工程（Context eng.） | 當前視窗中放入什麼內容 | 該檢索、摘要或清除什麼 |
| 安全裝置工程（Harness eng.） | 武裝單次運行 | 使用哪些工具、哪些動作，什麼算完成 |
| 迴圈工程（Loop eng.） | 對安全裝置進行排程 | 如何使其一遍又一遍地自我運行 |
這些「XX 工程」術語並非相互替代，而是層層疊加，每一層都關注著更大的範疇。表 I 展示了這四層架構。
每往上一層，關注的單元就大上一號：從一個句子，到一個視窗，到一次運行，最後到一個自我運行的迴圈。圖 1 將這四層展示為一個堆疊，其中迴圈坐落在安全裝置之上一層。
提示（Prompt） 是最底層，也是最廣為人知的。它關注該告訴模型什麼：字句、範例、角色、語氣。它的邊界是一次對話。問題在於，它假設人類每次都在場並親手遞交提示詞。
上下文（Context） 將問題從「我該說什麼」提升到「此時該將什麼放入這個視窗中，好讓模型能夠解決問題」。它關注模型的整個視野——要檢索什麼、如何進行摘要、該清除什麼過期資訊。一個充斥雜訊的視窗，即便是再完美的提示詞也是浪費。
安全裝置（Harness） 關注代理人在單次運行中需要攜帶什麼：哪些工具、哪些動作、何時載入上下文、如何從失敗中恢復，以及什麼狀態算完成。它武裝了單次運行，但並不使該運行重複。
迴圈（Loop） 則將「等待你」這一環節自動化消除。在具備前三層的情況下，代理人可以乾淨俐落地下載運行一次，然後停止。迴圈為其配備了定時器，使其能按計畫醒來，產生子代理人（Sub-agent）進行平行工作，並將自己的輸出作為下一輪的輸入。
有三個動詞將安全裝置與迴圈區分開來。定時運行：迴圈依據排程自行醒來，無需手動按鈕。產生助手：運轉中的迴圈會分拆出子代理人——一個負責起草變更，另一個則專職在審查中挑剔找出毛病。自我回饋：迴圈產出的內容會成為自己下一輪的輸入；昨天的發現被寫入檔案，今天早上它便讀取該檔案並繼續進行。這種跨越對話的記憶，正是使其成為迴圈而非僅僅是多次運行的單次任務的原因。
細粒度的劃分至關重要，因為每一層的失敗方式都不同，而能夠說「不」的檢查機制必須安裝在不同的地方。糟糕的提示詞會被當場發現；糟糕的上下文會顯現在錯誤的答案中。但在迴圈層，系統會在你睡覺時運行、修改你從未看過的代碼，並將自己的錯誤帶入下一輪——而這些錯誤可能好幾天都未被發現。層級越高，你距離現場就越遠，錯誤累積的時間也越長。這正是為什麼迴圈工程真正的難點從來不在於建構迴圈，而是在於在其中加入可以讓它停下來的機制。
考慮同一個潛在錯誤——代理人誤讀了函數返回的內容——在各層級中的表現。在提示詞層，誤讀會在一輪對話中產生一個錯誤答案；人類會立刻看到並重寫提示詞。在上下文層，誤讀來自於載入到視窗中的過期文件；人類會注意到答案錯得非常有自信，進而清除上下文。在安全裝置層，代理人依據誤讀行動一次——也許它編輯了一個檔案——但運行結束，差異（Diff）清晰可見，人類會在任何內容交付上線前進行審查。在迴圈層，同樣的誤讀被寫入狀態檔案，次日清晨作為既定事實被重新讀取，並在此基礎上進行多輪構建。當有人注意到時，這個錯誤假設已成為承重結構。
這是迴圈工程中最重要的一種直覺：出錯的代價與該錯誤在被發現前所存活的輪數成正比，而迴圈在結構上就是一部將輪數最大化的機器。後續章節中的所有內容——評估者、人類檢查點、預算上限——其存在都是為了縮短錯誤發生到被發現之間的距離。
「迴圈」一詞很容易被誤解為無意義的原地空轉。每一次執行（Turn）都完成了具體的事情：尋找值得做的工作、交給代理人、驗證結果是否正確、保存狀態，然後決定下一步。忽略探索（Discovery）、交付（Handoff）、驗證（Verification）、持久化（Persistence）、排程（Scheduling）這五個動作中的任何一個，迴圈就無法運轉，或者只能原地打轉。圖 2 描繪了這五個動作，一輪的執行將會為下一輪提供養分。
[圖 2：單次執行的五個動作。排程（Scheduling）完成了這個循環——它將未完成的執行回饋到次日的運行中。驗證（Verification）則是那個可以說「不」的動作。]
五個動作映射至分類迴圈（Triage Loop）
| 動作（Move） | 具體功用（What it does） | 在分類迴圈中的具體表現（In the triage loop） |
|---|---|---|
| 探索（Discovery） | 自主尋找當前執行的工作 | 技能讀取 CI、議題及提交紀錄 |
| 交付（Handoff） | 將任務交付至隔離環境中 | 每個發現皆開啟一個專屬工作區（Worktree） |
| 驗證（Verification） | 引入另一個代理人進行否定質疑 | 第二個子代理人對比測試進行審查 |
| 持久化（Persistence） | 將狀態寫入對話之外的地方 | 產生 PR、更新工單並寫入狀態檔案 |
| 排程（Scheduling） | 讓迴圈一輪接一輪運轉 | 早晨自動化獨立運行 |
Osmani 為自己建構了一個清晨分類迴圈。早晨，自動化任務會自行啟動。一項分類技能（Triage skill）讀取昨天的失敗 CI 測試、依然敞開的議題（Issue）以及最近的提交紀錄，並將結果寫入 Markdown 檔案或 Linear 任務看板中。針對每一個值得採取行動的發現，它會開啟一個隔離的 Git 工作區（Worktree）；一個子代理人起草修復，第二個子代理人對照專案的技能與測試進行審查。一個連接器（Connector）會自動開啟拉取請求並更新工單。任何它無法處理的事項都會進入收件匣（Inbox）等待人類處理，而狀態檔案得以保留，使次日的工作能夠承接今天的進度。整個過程不需要任何人工協助，然而它會在該停下來等待人類的地方精準停下。
探索 確定了這一輪執行應該做什麼。在上述範例中，分類技能讀取 CI 失敗、未解決議題和最近的提交。關鍵裝備在於讓代理人自己尋找工作，而不是被塞給一份清單。至關重要地，自動化觸發的是一項技能——成為永久知識的部分——而非貼在無人更新的 Cron 定時任務中的一大堆指令。探索決定了整個迴圈品質的天花板：若探索出來的工作毫無價值，那麼其他四個動作即便做得再漂亮，也是在為無用之事服務。
交付 將任務從排程系統移交到執行工作的代理人手中。每個值得做的事情都會獲得一個獨立的 Git 工作區，因此多個代理人可以在不同的目錄中修改代碼，而不會互相踩踏。任務切分得越乾淨，後續的驗證和合併就越容易。
驗證 是最容易偷工減料、卻也最不能省略的動作。在第一個子代理人起草好修復後，由第二個子代理人進行審查——使用不同的指令，有時甚至使用不同的模型。撰寫代碼的代理人對自己作業的評分往往過於寬鬆；專職挑毛角的評估者則能捕捉到第一個代理人說服自己放行的破綻。這就是「可以說不的機制（Thing that can say no）」。一個缺乏真實檢查的迴圈，不過是代理人對自己的盲目點點頭。
持久化 將結果落在對話之外、能保留下來的地方：透過連接器產生 PR 並更新工單，將無法處理的事情放入收件匣，並寫入記錄進度的狀態檔案。迴圈的記憶不能僅僅活在上下文視窗中；寫入 Markdown 或是看板的內容不會被遺忘。
排程 是將單次運行轉化為迴圈的關鍵。分類任務在每天早晨自動運行，狀態檔案則讓未完成的發現得以延續到次日，並能自動承接。正如 Osmani 所言，自動化正是讓迴圈成為真正的迴圈，而非僅僅是你手動運行了一次的腳本。表 II 總結了這五個動作。
如果說「動作」描述了單輪執行中發生的事，「元件（Part）」則描述了要讓迴圈運轉起來必須具備的工具。兩者一一對應：探索依賴技能（Skill）、交付依賴工作區、驗證依賴子代理人、持久化依賴記憶（Memory）、排程依賴自動化（Automation）。
六大元件與五大動作的對應關係
| 元件（Part） | 定義與功能（What it is） | 對應的動作（Maps to move） |
|---|---|---|
| 自動化（Automations） | 依據排程或觸發器運行 | 排程（Scheduling） |
| 工作區（Worktrees） | 用於平行代理人的隔離目錄 | 交付（Handoff） |
| 技能（Skills） | 永久性的專案知識，用以償還意圖負債 | 探索（Discovery） |
| 連接器（Connectors） | 連結外部系統的 MCP 掛鉤 | 持久化 / 探索（Persistence / Discovery） |
| 子代理人（Sub-agents） | 將生成者與評估者分開 | 驗證（Verification） |
| 記憶（Memory） | 磁碟上的持久化狀態 | 持久化（Persistence） |
自動化 讓迴圈得以自行運轉，掛載於排程或觸發器上。沒有排程，你手頭擁有的只是單次運行，而非迴圈。自動化應當觸發命名技能，而非 Cron 定時任務中的一大堆指令。排程有多種形式——本地排程（電腦必須保持開機）和雲端排程（即使電腦關機也能運行）。
工作區 是 Git 內建的機制，用於在單一倉庫中支援多個獨立的工作目錄。其價值隨平行度擴展：兩個代理人同時修改同一個檔案，與兩位工程師在同一行代碼上發生衝突一樣令人頭疼。工作區將平行處理從「雖可運行但混亂」轉化為「運行流暢且乾淨」。
技能 將專案知識永久保留在單一檔案（SKILL.md）中，使代理人無需在每輪都重新推導上下文。Osmani 將它們清償的代價命名為意圖負債（Intent debt）：即反覆解釋「這個專案是什麼、規則是什麼、陷阱在哪裡」的經常性成本。技能可以被重複使用和維護，而一大堆提示詞則無法做到。
連接器（建構於模型上下文協定 [Model Context Protocol, MCP] 之上）將迴圈與外部世界連結——議題追蹤器、資料庫、測試 API、Slack。一個只能看到檔案系統的迴圈是一個極其局限的迴圈。連接器決定了迴圈的視野半徑，且為某個工具撰寫的連接器通常可以直接移植到另一個工具上使用。
子代理人 將負責撰寫的代理人與負責評判的代理人分開。當同一個代理人既當球員又當評估者時，評估者難免會偏心。出人意料的是，調整一個獨立評估者使其保持挑剔，遠比讓生成者對自己的工作苛刻要容易得多——這就是為什麼迴圈會保留一個額外的代理人，而不是讓單一代理人自我審計。
記憶 是保存在單次對話之外的磁碟持久化狀態——例如 Markdown 檔案或任務看板。一旦上下文視窗被清除，代理人將遺忘一切；為了讓迴圈今天能承接昨天的進度，記憶必須落在磁碟上。代理人會遺忘，但倉庫不會。記憶不同於上下文：上下文是代理人在本輪看到的內容，並會在重新整理時被清除；記憶則跨越輪數和天數持久存在。表 III 展示了六大元件與五大動作的映射關係。
擁有了這六個元件，迴圈便有了骨架：自動化使其運轉，工作區防止其內部衝突，技能避免其做重複工作，連接器拓寬其視野，子代理人使其能夠自我糾正，而記憶使其能夠記住進度。然而，這僅僅是個開始：相同的元件組合在不同的人手中，結果可能完全相反。
迴圈最難的部分不是讓代理人運行，而是在其中加入可以說「不」的機制——而撰寫代碼的代理人最不可能說出這個字。
[圖 3：生成者與評估者作為獨立的代理人。評估者不帶有生成者的自我說服傾向，預設抱持懷疑態度，並透過實際行動（如點擊、截圖、運行測試）而非僅僅閱讀代碼來進行評判。]
Anthropic 的工程師 Prithvi Rajasekaran 在建構長期運行的代理人應用時觀察到：如果要求代理人為自己剛剛產出的內容打分，它往往會充滿自信地給予讚美，即使人類可以一眼看出其品質平庸。這不是聰明與否的問題，而是自己改自己考卷的弊端。編寫代碼的上下文已經塞滿了之所以這樣寫的種種理由，因此當代理人看著自己的輸出時，它看到的不是結果，而是導致該結果的自我說服鏈。在迴圈中，這種缺陷會被放大：如果每一次「這是否足夠好」都由剛剛撰寫代碼的代理人決定，它每輪都會對自己點點頭，運行得越久，偏離真實品質就越遠。
試圖讓生成者變得更具自我批判性，效果往往不佳。Rajasekaran 發現，調整一個獨立的評估者（Evaluator）使其保持懷疑，遠比讓生成者批判自己的工作更具可行性。這種差異是結構性的，而非字句調整的問題：你無法要求作者跳脫出自己的視角，但你可以引入另一個攜帶完全不同指令的代理人，從零開始審視代碼，而不帶任何先前的自我說服。這個想法借鑑自生成對抗網路（Generative Adversarial Network, GAN）——一個網絡負責建構，另一個網路負責挑毛病——並將其移植到撰寫的生成者與審查的評估者上。圖 3 展示了這種結構形成的迴圈。
僅僅更換代理人是不夠的。如果評估者只閱讀代碼，它評判的只是「這段代碼看起來是否正確」，而非「運行起來是否正確」。在前端任務中，Rajasekaran 將評估者與 Playwright MCP 連結，使其能夠像 QA 工程師一樣打開頁面、點擊按鈕、截取螢幕畫面並檢查 DOM（文件物件模型）。這將評判依據從「這段 JSX 看起來不錯」轉變為「我點擊了按鈕，頁面跳轉了，這是截圖」。更換底層模型也有幫助：使用相同模型配上新指令往往仍會保留其盲點。社群中一個常見的校準準則是：告訴評估者在被證實正確之前，預設代碼是損壞的——預設態度應當是懷疑，而非信任。
Claude Code 通過 /goal 將這種結構轉化為一項原語：給予代理人一個條件，並讓它一直運行直到該條件被滿足。一個具代表性的評估者設置和停止條件如下所示。
# Evaluator agent (.claude/agents/reviewer.md)
ROLE: Adversarial code reviewer.
ASSUME: this code is BROKEN until proven otherwise.
DO NOT praise. Find what fails.
CHECK, in order:
1. Does it run? (execute, don’t read)
2. Tests: run them, paste real output.
3. Edge cases the author skipped.
4. Does behavior match the ticket?
USE Playwright MCP: open the page, click,
screenshot, inspect the DOM. Judge behavior,
not intent.
VERDICT: PASS only if every check holds.
Otherwise REJECT + list each reason.
# Stop condition, judged by a fresh small model
/goal all tests in test/auth pass and the lint
step is clean
至關重要地，在每輪執行之後，一個快速的輕量模型會檢查條件是否成立；若不成立，則會運行新一輪執行，而非將控制權交還。任務是否完成由一個全新的模型決定，而不是由執行工作的那個模型說了算。這就是雙人控制原則（Maker-checker principle）——在銀行界已沿用數十年，即輸入大筆轉帳的人與審核轉帳的人必須為不同的人——在停止條件上的應用。（Codex 透過自動化加上代理人設定來實現相同的能力；人不應將 /goal 與僅僅在特定間隔重複運行的 /loop 混淆。）
迴圈的下限取決於其評估者。生成者的水平決定了迴圈能產出什麼，而評估者的水平則決定了它不會產出什麼。在結構上將生成與判斷分離、將評估者訓練為懷疑論者、使其透過實際行動進行驗證，並將最終決定權交給全新的模型——這四個步驟是提升迴圈「說不」能力的關鍵。
在轉向運作良好的迴圈之前，有必要先編錄它們失敗的方式，因為失敗往往比成功更具啟發性，也更為常見。底下的每一種反模式（Anti-pattern）都對應著五個動作之一被忽略或做得糟糕。
[圖 4：每種反模式都是某個動作被略過的結果。這五種失敗與單次執行的五個動作一一對應：探索被略過（盲目迴圈）、交付被略過（糾纏迴圈）、驗證被略過（點頭迴圈 [Nodding Loop]）、持久化被略過（失憶迴圈）、排程被略過（手動迴圈）。]
這是最常見的失敗。迴圈在運行，代理人撰寫代碼，並且由同一個代理人宣告代碼完美。在沒有獨立檢查的情況下，每輪都會產生自我核准的輸出，迴圈以機器般的速度累積看似合理卻有瑕疵的錯誤。其症狀是：迴圈在數百輪執行中從未對自己說過一次「不」——這在任何真實的工作負載中都是統計上的不可能，因而證明了根本不存在真實的檢查機制。修復方法是採用前一節所述的生成者/評估者分離架構。
迴圈發現了值得做的好工作，完成了它，然後卻忘記了它的發生，因為結果僅僅活在被清除掉的上下文視窗中。下一輪執行又重新發現了同樣的工作，或者更糟的是，重新做了一遍並與第一次的嘗試產生衝突。其症狀是：迴圈無法取得累積性的進度，每天早晨都從同一個起點重新開始。修復方法是在磁碟上保留一個狀態檔案——代理人會遺忘，但倉庫不會。
一個擁有四個優質動作但缺乏自動化的迴圈不能稱之為迴圈；它只是一個由人類手動運行隨後被遺忘的腳本。在建構完成的那天，它的表現令人印象深刻，但在注意力轉移的那天它便默默停擺。其症狀是：迴圈的最後一次運行停留在它被演示（Demo）的那一天。修復方法是引入一個不依賴人類記憶的真實觸發器（定時器或事件）。
人類每天早晨依然在手動遞交工作給迴圈——「修復這三個錯誤」——因此迴圈只自動化了「執行（Doing）」，而沒有自動化「探索（Finding）」。這節省的時間遠比想像中要少，因為挑選該做什麼往往才是昂貴的部分。其症狀是：人類每天清晨仍要花費時間決定迴圈該做什麼。修復方法是將探索沉澱為一項技能，好讓迴圈能自行發掘工作。
迴圈在平行運行多個代理人，卻讓它們修改同一個工作目錄，導致它們的編輯產生碰撞，合併過程變成一場無人能解的災難。此症狀僅在平行處理時顯現：單一代理人的迴圈看起來毫無問題，但在五個代理人同時運行的第一個早晨，問題便會爆發。修復方法是為每個任務分配一個隔離的工作區。圖 4 展示了這五種反模式與它們所違反的動作之映射關係。
這五種失敗並非獨立存在。一個缺乏驗證的迴圈往往也缺乏持久化，因為一個對檢查敷衍了事的團隊，通常對其他環節也同樣敷衍。在實務中，它們常成群出現：紀律嚴明的迴圈會安裝所有五個動作，而行事草率的團隊則只安裝探索和交付——這兩個能產生可見輸出的動作——並略過負責安全保障的其他三個動作。下一節將展示三個完整安裝了所有五個動作的真實迴圈。
三個公開的案例在規模上大相徑庭，但共享同一個骨架：一個觸發器按下啟動鍵，一套約束條件使其保持在軌道上，最後由人類檢查點進行把關。「在你入睡時運行」從來不是取決於模型有多強——而是取決於這個骨架有多穩固。
Osmani 在第三節中拆解的分類迴圈每天早晨都會自動運行。有一個細節值得再次強調：自動化調用的是一項技能，而非粘貼在排程中且無人會去更新的巨大指令區塊。這就是單人便可運行的迴圈樣貌——一個人、一部機器，每天早晨自動搞定繁雜的例行公事。
[圖 5：Stripe 的 Minions 流水線（Pipeline）。確定性閘門（藍色）與大語言模型（LLM）步驟（綠色）相互扣合；任何基於規則的任務都會被排除在概率性模型之外。可靠性來自於約束條件，而非模型大小。]
若要研究企業級規模，最佳案例是 Stripe 的 Minions 系統：正如 Stripe 工程師 Steve Kaliski 在《How I AI》播客中所描述，該系統每週合併超過 1,300 個拉取請求，且沒有一行代碼是人工撰寫的。其觸發方式非常輕量——在 Slack 中團隊成員提及（@）機器人，或是加上一個表情符號回應。
使其可靠的關鍵在於模型喚醒之前的準備階段：一個確定性編排器（Deterministic orchestrator）會首先組裝上下文，掃描連結、拉取 Jira 工單、尋找文件，並使用 Sourcegraph 加上 MCP 來定位相關代碼。讓 LLM 自行尋找上下文是最難控制的部分，因此這項工作（其規則可以被寫死編碼）被從模型手中剝離。任何確定性邏輯可以解決的事情，絕不交給概率性模型；在哪裡劃分這條界線，決定了迴圈是否可靠。
最反直覺的一點是：Minions 並非建構於更強大的模型之上。它是開源工具 Goose 的一個分支，其核心主張是：可靠性來自於約束條件的品質，而非模型的大小。它的架構將確定性閘門（Deterministic gates）與富有創造力的 LLM 步驟交織在一起，如圖 5 所示——代理人編寫代碼，一個寫死的流水線運行 Linter 且代理人無法跳過，代理人修復 Linter 報錯，接著一個確定性的步驟執行 Git 提交。其沙箱（Sandbox）是 EC2 上的 Devbox，基於「牛群而非寵物（Cattle not pets）」的理念運行：每個環境皆可隨意替換，因此上千個代理人得以同時運行而互不干擾。值得注意的是，這 1,300 個 PR 依然由人類進行審查——人類並未離場，只是轉換了辦公桌，從編寫代碼轉為審查代碼。
本地的 /loop 和桌面排程任務需要電腦保持開機；一旦關機，迴圈就會停止。若要在電腦關機時運行，正確答案是雲端例程（Cloud Routines）或 GitHub Actions 的排程觸發器。表 IV 對照了這些選項。想要高頻運行且能看到本地檔案？使用本地 /loop，代價是必須保持電腦開機。想要脫離本地狀態運行？選擇雲端排程，代價是至少一小時的執行間隔且每次都需要重新乾淨地克隆（Clone）代碼。沒有任何單一排程器能包辦一切。
排程選項之對照
| 特性（Feature） | 雲端排程（Cloud） | 桌面排程（Desktop） | 本地 /loop 指令 |
|---|---|---|---|
| 運行地點（Where it runs） | 雲端 | 本地機器 | 本地機器 |
| 機器需開機？（Machine on?） | 否 | 是 | 是 |
| 會話需開啟？（Session open?） | 否 | 否 | 是 |
| 最小執行間隔（Min. interval） | 1 小時 | 1 分鐘 | 1 分鐘 |
| 可見本地檔案？（See local files?） | 否 | 是 | 是 |
對於廣泛流傳的數據需保持警惕：諸如「Claude Code 中約 90% 的代碼是其自身編寫的」或大規模遷移速度提升等說法，大多是二手摘要，應視為粗略參考。此處的三個案例皆源於一手資料，比聽起來令人驚嘆的單一數字更具參考價值。
在本地排程與雲端排程之間做出選擇，並非依憑個人喜好，而是自然地源於一個問題：迴圈的工作是與本地機器綁定，還是可以離開本地？ 兩個具體場景能讓這個規則清晰明瞭。假設一個迴圈必須每分鐘檢查一次本地的開發伺服器——這項工作只能在本地運行，因為雲端無法看到你筆記型電腦上的進程，且雲端執行的最小間隔不能低於一小時。現在反過來：假設一個迴圈需要在凌晨三點掃描倉庫中開啟的議題，並在合理的情況下開啟拉取請求——這項工作絕不應該與個人電腦綁定，因為筆記型電腦會被蓋上、會斷電，也會被攜帶出門。對於第二個場景，雲端排程或 CI 排程觸發器才是正確答案，它們運行在人類入睡時依然保持清醒的機器上。
需要避免的扭曲認知是，將本地重複運行視為「在你睡覺時運行」的全部。本地重複運行意味著「當我在場時，多運行幾輪」；雲端排程則意味著「即使我不在場，也能自動運行」。這是兩種不同的能力，混淆它們是人們合上電腦蓋子後，原以為自主運行的迴圈默默停擺、進而感到失望的原因。誠實的界定是：本地排程以需要保持電腦開機為代價，換取高頻率和對本地檔案的存取權；而雲端排程則以較粗的執行間隔和每次需要乾淨克隆為代價，換取真正的自主性。成熟的迴圈通常兩者並用——本地用於緊密的內部檢查，雲端用於通宵的全局掃描。
本筆記中的指令以 Claude Code 為例，但其能力並非其所獨有。Codex 在不同的名稱下提供了相同的五大核心機制，且為其中一方編寫的連接器通常可以稍作修改後用於另一方。表 V 將它們排在一起，好讓讀者不會將指令名稱張冠李戴。這帶來的啟示是：迴圈工程是一套能力，而非單一產品。無論團隊使用哪種工具鏈，都需要問這六個元件是否齊備，而非提供它們的指令品牌是什麼。
跨工具鏈之相同能力對照表
| 核心能力（Capability） | Claude Code 的實現 | Codex 的實現 |
|---|---|---|
| 排程（Scheduling） | /loop 背景工作者 |
自動化（Automations）分頁 |
| 運行至條件滿足（Run until met） | /goal |
自動化重複運行 + 評判 |
| 平行隔離（Parallel isolation） | --worktree |
背景工作區（Background worktree） |
| 子代理人（Sub-agents） | .claude/agents/ |
.codex/agents/ |
| 外部連接器（External conn.） | MCP + 插件 | MCP 連接器 |
| 顯式技能（Explicit skill） | SKILL.md |
$skill-name |
| 關機運行（Machine-off run） | 雲端例程（Cloud Routines） | 雲端（計劃中） |
一個會自我運行的迴圈，同時也是一個會自我出錯的迴圈。它運行得越歡快，出錯時就越悄無聲息。以下四種代價會在無形中累積，且在迴圈運行時都不會發出警報。
[圖 6：四種代價相互強化。未經驗證的輸出（Verification debt）會侵蝕理解（Comprehension rot），進而誘發認知棄守（Cognitive surrender），這使得迴圈運行時間更長並花費更多（Token blowout），進而產生更多未經驗證的輸出。]
這四種代價有一個共同特徵：在迴圈運行時保持沉默。迴圈工程最迷人之處在於它能讓一個人完成一個團隊的工作；而最危險之處也在於此，因為團隊會相互爭論，而一個人加上一堆迴圈則極易變成一個無人質疑的同溫層。
想像一個在夜間開啟了 20 個 PR 且測試全部通過（綠燈）的迴圈。表面上看，這是一次巨大的勝利。但假設這 20 個 PR 中有 3 個包含了測試未覆蓋的隱蔽錯誤。在沒有獨立評估者的情況下，這 3 個 PR 被合併了——這就是驗證債。因為人類在沒有閱讀的情況下合併了 20 個 PR，他們對代碼庫的認知模型現在滯後了 20 個變更——這就是理解退化。因為迴圈運行得如此順暢，人類次日清晨完全停止了閱讀新的一批 PR——這就是認知棄守。又因為迴圈通宵孵化助手並自由重試，其帳單是預估的三倍——這就是 Token 暴增。
這三個隱藏的錯誤現在存在於一個人類不再完全理解的代碼庫中，由一個已經停止審視的人類看守著，最終只有在其中一個錯誤暴露為線上故障時，才會被猛然發現。
這個實際案例的重點在於：這四種代價並非孤立的風險清單，而是同一個失敗呈現出的四個面孔。它們相互強化：迴圈產出未驗證的內容越多，人類理解得就越少；理解得越少，放棄得就越徹底；放棄得越徹底，迴圈在無人看管下運行的時間就越長，帳單也就越龐大。圖 6展示了這種自我強化的惡性循環。對抗這四者的防線是相同的：保持一個有能力說「不」的人類，並安裝一個人類不需要醒著也能運行的檢查機制。
相同的迴圈，由兩個不同的人建構，最終會走向截然相反的終點——而關鍵的差異並不在於迴圈本身。正如 Osmani 所寫，兩個人可以建構相同的迴圈，卻得到相反的結果。其中一人利用迴圈在自己已經掌握的事情上加速：他們閱讀代碼，保持清晰的方向感，迴圈放大了他們原先就具備的判斷力。另一人則使用相同的迴圈，好讓自己再也不需要去理解代碼。六個月後，前者變得更強，而後者則成了一部自己無法解讀的機器的看門人。
迴圈並非其品質由工具本身決定的工具。它強大到能一成不變地放大你所帶給它的一切：帶來理解，它便放大理解；帶來懈怠，它便放大懈怠。它是一個忠實的乘號，而它所乘的對象正是你。
迴圈使生成變得極其廉價——代碼、計畫、PR、修復，幾乎免費。依然稀缺的是判斷力：知道哪個計畫是正確的、哪一行代碼應該被攔下、哪個輸出雖然運行良好但在根本上是錯誤的。迴圈可以生成一百個選項，但無法真正做出選擇；或者更確切地說，它基於「看起來合理」而非「實際正確」做出選擇，而這兩者之間的鴻溝，正是工程師存在的理由。因此，迴圈工程並未貶低判斷力的價值；它剝離了所有不需要判斷力的工作，使判斷力成為唯一留存的核心。
迴圈會執行賦予它的邏輯，但它並不理解你為何想建構它、你真正想要什麼，或者你寧願自己親自看守哪些地方。這些邊界——手動檢查點設在哪裡、何處任其自行運行——無法從迴圈內部讀取出來；它們只活在建造者's 的腦海中，必須被一條一條地寫入。你設計時抱持的心態，決定了迴圈成長出的形狀。基於「快速解脫自己」心態建構的迴圈，與基於「我仍打算作為工程師」心態建構的迴圈，在代碼上可能有九成是完全相同的；其差別僅在於一兩個檢查點，而這決定了六個月後，你是站在迴圈之上，還是被它掏空。
Osmani 的結尾語值得銘記：建構迴圈，但建構它時要像一個意圖保持工程師身分的人，而非僅僅是那個按下啟動鍵的人。這份筆記中所有的技術細節，都是為了服務這一個姿態。評估者、狀態檔案、預算上限、敞開的門：每一種都是保持人類有能力對一部旨在快速說「是」的機器說「不」的方法。迴圈是這一代軟體實務中最強大的工具，恰恰因為它是其建造者最忠實的放大器，而一個忠實的放大器，其價值或危險程度，與輸入其中的判斷力完全等同。
前一節提出了一個值得單獨審視的主張：迴圈使生成變得廉價，而讓判斷力保持稀缺。這不是一個口號，而是一個會對團隊組織方式產生深遠影響的經濟學觀察。
當一種資源變得充裕時，它的價格就會下跌，而围绕它組織的活動也隨之重組。迴圈使代碼、計畫、修復和拉取請求變得極其充裕——單個配備了優秀迴圈的工程師可以產出一個小團隊的產量。過去消耗工程師一整天時間的活動——打字、樣板代碼和機械性的重構——其成本正趨近於零。一個合理的直覺反應是，這會降低工程師的價值。但事實恰趣相反，不過這僅適用於那些牢牢掌握稀缺資源的工程師。
稀缺的資源是決定保留哪些充裕輸出的判斷力。迴圈可以生成一百個候選實現；但它無法告訴你哪一個是正確的，只能告訴你哪一個看起來合理，而「看起來合理」與「正確」之間的鴻溝，正是工程的精髓所在。隨著生成接近免費，工程師的全部價值都濃縮到了這個鴻溝之中。留下來的工作是純粹的判斷力，被蒸餾提純，不再被過去圍繞它的機械性勞動所稀釋。
這帶來了一個令人不安的啟示。一個其價值主要體現在機械性勞動——快速打字、廣泛記憶 API、樂於熬夜應對樣板代碼——的工程師，會發現其價值正在蒸發，因為迴圈會免費完成這一切。而一個價值體現在判斷力的工程師，其價值會被放大，因為迴圈會將其正確的決策執行上百次。同一個工具拓寬了這兩類工程師之間的差距。它並非平等地提升每個人；它乘以了每個人所帶來的基數。
因為迴圈是判斷力的放大器，因此判斷上的失誤也會被同步放大。在舊世界中，一個糟糕的決定代價是手寫一段長度有限的錯誤代碼，其爆炸半徑受限且進展緩慢，足以被中途截獲。在新世界中，一個糟糕的決定會被一部不會停下來詢問對錯的機器，忠實且成批地執行上百次。迴圈移除了過去用以解救工程師的「慢速檔」。你不能再指望進程足夠緩慢、好讓你在中途注意到錯誤，因為這個進程已經沒有慢速檔了。這推高了迴圈無法完成的那一件事之賭注，也是「保持工程師身分」的紀律並非選擇性的多情、而是運作上的必需之原因。
如果判斷力是稀缺資源，那麼實務上的問題就是如何將其花在刀口上。從上述案例與代價中總結出的三項紀律，值得作為常設實務。
對抗理解退化的防線，並非去閱讀迴圈產出的每一行代碼——這會失去使用迴圈的初衷——而是每天閱讀具有代表性的抽樣，並強迫自己解釋每一項抽樣變更：它做了什麼，以及為什麼要這樣做。一旦無法解釋某項變更，就是一個精確的訊號，表明你腦中的地圖已落後於代碼庫。在寧靜的清晨從抽樣的 PR 中發現這一點，遠比在糟糕的夜裡從線上故障中發現要便宜得多。抽樣不需要很大，但需要保持規律且被真正審視。
對抗 Token 暴增的防線，是在迴圈第一次無人看管運行之前設定硬性天花板，而非在收到第一筆令人吃驚的帳單之後。單次運行預算、每日預算和最大重試次數共同確保了通宵空轉的單一 Bug 無法燒光整個額度。這些數字主要目的不是為了省錢，而是作為斷路器（Circuit breaker），將無上限的風險轉化為有上限的風險。一個沒有上限的迴圈，等同於將其消費權限外包給了自己的 Bug。
對抗認知棄守的防線是結構性的，而非僅僅是態度上的。在迴圈中建構至少一個需要人類介入停下的檢查點——不是因為人類每次都會干預，而是因為這個暫停的存在讓人類保持在能夠干預的位置。將每一扇門都焊死、指望永遠不需要進去的工程師，在必須進去的那一天，會發現自己不再持有鑰匙。而留下一扇敞開大門的工程師，則可以隨時走進去查看迴圈在做什麼。這兩個迴圈在代碼上僅相差一個檢查點；但在六個月後由誰掌控大局上，卻有天痕之別。
Stripe 的流水線是終點，而非起點。你的第一個迴圈應該小到幾乎不像一個系統——一個在定時器上檢查某事的小工具。
步驟一：運行 /loop。 在 Claude Code v2.1.72 之後可用，它能在特定間隔重複運行相同的任務。它是會話（Session）作用域的，循環任務將在七天後過期，且運行在本地機器上；關閉電腦，它就會停止。
/loop 5m check the deploy
# 固定：每 5 分鐘運行一次
/loop check the deploy
# 代理人自行調配速度
/loop
# 運行 .claude/loop.md
步驟二：讀取 CI 與議題；先做分類。 重複運行一行指令稱不上是迴圈。給予它一個提示詞，使其在每天早晨審視三件事，並列出哪些值得處理。排程加上自動探索是進入迴圈的入門級別。探索邏輯應當活在技能中，而非排程中。
# .claude/skills/morning-triage/SKILL.md
NAME: morning-triage
WHEN: invoked each morning by automation.
READ:
- CI runs that failed since yesterday
- issues opened in the last 24h
- commits merged since the last run
JUDGE: for each item, is it worth acting on?
Skip noise. Keep only actionable findings.
OUTPUT: write findings + status to
./state/triage.md (one row per finding).
步驟三：加入狀態檔案。 不要把結果留在聊天視窗中。將每一個發現以及處理進度寫入一個 Markdown 檔案（或 Linear 任務看板）。代理人會遺忘，但倉庫不會。
# ./state/triage.md
（迴圈的記憶）
| finding
| source
| status
|
|----------------|----------|----------|
| auth test flaky| CI #4821 | fixing
|
| null deref
| issue 92 | PR open
|
| stale dep
| commit a3| inbox
|
步驟四：加入評估者。 這是最關鍵卻也最容易被忽略的步驟。Claude Code 的 /goal（v2.1.139 之後）會一直運行直到條件滿足，並由另一個獨立的模型來判斷條件是否成立。
/goal all tests in test/auth pass and the lint
step is clean
步驟五：使用工作區實現平行化。 使用 --worktree（或 -w）為每個背景運行的代理人開啟一個獨立的工作區，這樣它們就不會互相干擾。
# 為每個發現開啟一個隔離的工作區
claude --worktree fix/auth-test "draft the fix"
claude --worktree fix/null-deref "draft the fix"
在表 VI 的六個要素中，前兩個決定了迴圈能否運行；後四個則決定了它運行後是否會惹上麻煩。初學者在部署時往往只建構了前兩個，結果得到了一個無人看管、無法停止、對自己盲目點點頭的迴圈。結尾的建議很簡單：第一個迴圈最好小一點，但必須完整安裝說「不」的檢查機制以及人類審查點。
首個迴圈檢查清單（First-Loop Checklist）
| 要素（Element） | 自問（Ask yourself） |
|---|---|
| 探索來源（Discovery source） | 它在定時器上讀取什麼？（CI / 議題 / 提交 / 收件匣） |
| 狀態檔案（State file） | 哪一個磁碟檔案保存了跨輪次的記憶？ |
| 評估者（Evaluator） | 是否存在一個可以說「不」的獨立檢查機制？ |
| 隔離環境（Isolation） | 每個平行的代理人是否都獲得了專屬的工作區？ |
| Token 上限（Token cap） | 你是否設置了消費天花板？如果失控了，誰來阻止它？ |
| 人類審查（Human review） | 哪一個步驟會暫停等待你查看，而非一路自動到底？ |
為了讓檢查清單更加具體，以下是一個極簡但完整的迴圈，它安裝了所有六個要素。它小到可以在一次閱讀中看完，並且包含了真實迴圈所需的所有器官，只是按比例縮小。
# 1. SCHEDULING -- a real trigger
# (.github/workflows/triage.yml)
on:
schedule:
- cron: '0 6 * * *' # 06:00 daily, cloud
# 2. DISCOVERY -- a skill, not a wall of text
# invoked by the workflow:
run: claude --skill morning-triage
# 3. PERSISTENCE -- state on disk
# the skill writes ./state/triage.md
# and commits it back to the repo
# 4. HANDOFF -- one worktree per finding
for finding in $(parse ./state/triage.md); do
claude --worktree "fix/$finding" \
--goal "tests pass and lint is clean" \
"draft a fix for $finding"
done
# 5. VERIFICATION -- a fresh model judges
# /goal's stop check runs after each turn;
# a second reviewer agent picks holes
# 6. HUMAN REVIEW -- the open door
# PRs are opened, never auto-merged;
# anything uncertain lands in ./inbox/
從上到下閱讀，這六段帶有編號的註解正是檢查清單的六個要素，每個要素都由兩三行代碼實現。Cron 行是排程；技能調用是探索；提交的狀態檔案是持久化；每個發現的獨立工作區是交付；/goal 停止檢查搭配審查者是驗證；而絕不自動合併且配備收件匣的規則，則是人類審查點。一個具備這六要素的迴圈，即便再微小，也是一個真正的迴圈。缺少其中任何一個，都是第六節中那五種失敗之一在裝模作樣。
一旦極簡迴圈運作起來，人們便會按捺不住想要擴展它——更多的發現、更多的平行代理人、更短的執行間隔。安全的擴展順序是：在檢查機制被證實有效之後，再將平行化放在最後一步加入。 在增加平行執行的任務量之前，先增加迴圈探索的範圍，並在信任評估者去把關多個平行代理人之前，先證實它能捕捉到真實的錯誤。Stripe 的案例是這條道路的終點，而非起點：其可靠性來自於數年來對確定性閘門的磨礪，而非一上來就做大規模。迴圈是透過先證明自己能攔下一段糟糕的代碼，來贏得運行更多代理人的權利的。
其餘的秘密不在這份筆記中，而在終端機裡。
探索動作依賴於技能（Skill），而非一大堆指令，因為技能可以被重複使用和維護，而粘貼的提示詞則會在無人更新的排程中腐爛。以下是貫穿全文提及的 morning-triage 技能的更完整版本，並附有註解以展示各個部分如何服務於各個動作。
# .claude/skills/morning-triage/SKILL.md
---
name: morning-triage
trigger: invoked by daily automation
---
## Read (the DISCOVERY inputs)
- CI runs failed since the last run
- issues opened in the last 24 hours
- commits merged since yesterday
- the previous ./state/triage.md
## Judge (the part that sets the ceiling)
For each candidate, decide:
- is it actionable now, or noise?
- does it block a release? → priority
- is it already tracked? → skip
Keep only what is worth a worktree today.
## Write (the PERSISTENCE output)
Append to ./state/triage.md:
| finding | source | priority | status |
Commit the file so tomorrow can read it.
## Hand off (prepare the HANDOFF)
For each kept finding, emit a task line:
worktree=fix/<slug>
goal=<stop-condition>
## Stop (the boundary you keep for yourself)
Never merge. Never delete. Anything you are
less than confident about goes to ./inbox/
for a human, not into a PR.
該技能的六個標題中有五個對應著五個動作；第六個標題「Stop（停止）」則是建造者親自寫下的、迴圈無法自主推導的邊界。迴圈會忠實地執行技能中所寫的一切，並忽略所有未寫的內容，因此「Stop」部分並非樣板文字——它是工程師將其保持控制權之意圖永久化沉澱的唯一地方。省略它，迴圈將會帶著它未曾贏得的自信進行合併。
本筆記中所使用的術語釋義
| 術語（Term） | 釋義（Meaning） |
|---|---|
| 迴圈（Loop） | 在內部循環中無需人類參與，即可自主探索、執行、驗證、持久化並重新排程工作的系統。 |
| 安全裝置（Harness） | 武裝單次代理人運行的套件：工具、允許的動作、錯誤恢復與「完成」判定。 |
| 動作（Move） | 迴圈單次執行中的五個步驟之一（探索、交付、驗證、持久化、排程）。 |
| 元件（Part） | 實現上述動作的六個組成部分（自動化、工作區、技能、連接器、子代理人、記憶）。 |
| 生成者（Generator） | 負責編寫代碼或內容的代理人。 |
| 評估者（Evaluator） | 負責評判的獨立代理人，預設抱持懷疑態度，並透過實際行動進行驗證。 |
| 工作區（Worktree） | Git 的一項機制，賦予每個平行運行的代理人自己獨立的工作目錄。 |
| 技能（Skill） | 永久保留在 SKILL.md 檔案中的專案知識。 |
| 連接器（Connector） | 將迴圈連結至外部系統的 MCP 介面。 |
| 記憶（Memory） | 磁碟上的持久化狀態，能跨越任何單次對話存活下來。 |
| 意圖負債（Intent debt） | 反覆向代理人重新解釋專案的經常性成本，可透過建構技能來清償。 |
| 驗證債（Verification debt） | 累積於「能運行」與「正確」之間的未經驗證產出。 |
跨越九個章節，本筆記的論證有著清晰的脊梁。迴圈工程是繼提示詞、上下文和安全裝置之後，堆疊中的第四層架構，而它與其下三層的本質區別在於：它將人類從具體工作的執行位置上徹底抽離。迴圈的單次執行由五個動作組成——探索、交付、驗證、持久化、排程——並由六大元件實現，而迴圈的失敗僅僅是這些動作被略過。
在這些動作中，最難的一環是驗證，因為代理人改自己的試卷總是會給予讚美，而可靠的解決方案是結構性的：引入獨立的評估者，預設抱持懷疑，透過實際行動而非僅僅閱讀來進行檢驗，並由一個全新的輕量模型依據明確的停止條件進行評判。
迴圈已經在實務中運行，從單個工程師的早晨分類到每週合併上千個機器撰寫 PR 的企業級流水線，使其可靠的關鍵在於約束條件的品質，而非模型的大小。
它們會暗中累積四種相互強化的代價——驗證債、理解退化、認知棄守和 Token 暴增——並在某一天集中爆發。由於迴圈是建造者自身特質的放大器，兩個人建構同一個迴圈會產生截然相反的結果，其間的差距僅在於一兩個檢查點，而這決定了日後究竟是誰掌控大局。
值得銘記的一句話，也是整個領域在同一週內達成共識的核心思想：停止向代理人發出提示，轉而設計那套去提示它的系統——但設計它時，要像一個意圖保持工程師身分的人，而非僅僅是那個按下啟動鍵的人。本筆記中所有技術細節皆為此一姿態服務。評估者、狀態檔案、預算上限、敞開的門：每一種都是保持人類有能力對一部旨在快速說「是」的機器說「不」的方法。在這一代軟體實務中，迴圈是最強大的工具，恰恰因為它是其建造者最忠實的放大器，而一個忠實的放大器，其價值或危險程度，與輸入其中的判斷力完全等同。
對於採用迴圈的團隊，有一些實務觀察頻繁出現，值得在此予以說明。
單獨來看，這些都不是什麼驚人的發現。真正讓團隊感到意外的是，一個「運作良好」的迴圈所帶來的愉悅體驗，會以多快的速度侵蝕那些使其運作良好的紀律，而這種侵蝕在問題爆發前是完全無形的。這份攻略到頭來與其說是關乎建構迴圈——這部分在如今確實非常簡單——不如說是關乎在每個給定的早晨，你是否依然能保持作為一個工程師的姿態，去回答迴圈剛剛所做的事情，到底是不是實際正確的。
[1] A. Osmani, “Loop Engineering,” 個人部落格與 Substack, 2026 年 6 月. [2] P. Steinberger, 關於設計提示編碼代理人之迴圈的社交媒體貼文, 2026 年 6 月. [3] B. Cherny, 關於撰寫提示 Claude 迴圈的公開演說, Anthropic, 2026 年 6 月. [4] P. Rajasekaran, “Building long-running agentic applications: the generator/evaluator pattern,” Anthropic 工程部落格, 2026. [5] S. Kaliski, “Stripe’s Minions: 1,300 PRs a week,” How I AI 播客, 2026. [6] “Model Context Protocol (MCP) specification,” 開放標準, 2025–2026. [7] “Goose: an open-source agent framework,” 專案文件, 2025–2026. [8] “Claude Code documentation: /loop, /goal, worktrees, skills, automations,” Anthropic, 2026. [9] HuaShu, Loop Engineering: Stop Asking Me What It Is, 橘皮書（Orange Books）, v260615, 2026 年 6 月.
本研究是一份獨立的會議風格綜合論述，建構於華書（HuaShu）的開放指南《Loop Engineering: Stop Asking Me What It Is》（橘皮書，v260615，2026 年 6 月）框架之上。該框架與文中所引述的公式化表述皆歸功於 Addy Osmani；生成者/評估者研究成果歸功於 Prithvi Rajasekaran（Anthropic）；企業級案例歸功於 Steve Kaliski（Stripe）。所有產品細節可能有所變更；請參閱各工具之官方文件。