2026 年 6 月，有三個人，不約而同地在同一個星期內，想到了同一件事。
OpenClaw 的開發者 Peter Steinberger 公開表示，你應該停止對程式碼 Agent 下指令，轉而設計能對它們下指令的循環。幾乎在同一時間，Anthropic 的 Claude Code 負責人 Boris Cherny 說，他不再直接對 Claude 下指令，而是由他寫的循環來對 Claude 下指令並決定下一步行動，他真正的工作是撰寫這些循環。幾天後，Google 工程師 Addy Osmani 將這個概念寫成文章，並賦予它一個名稱：循環工程（Loop Engineering）。
沒有人是從零開始發明這套做法。他們只是為已經發生的事情命名，因為底層的工具早已悄悄跨越了某個門檻。程式碼 Agent 已經變得足夠可靠，可以自主完成真實任務。排程成本變得足夠低廉，讓定時重複執行任務不再顯得浪費。單次執行 Agent 的成本已大幅下降，以至於嘗試五次所花的錢，可能比仔細思考一次還要少。
正是這個門檻，催生了這份路線圖。當人類需要坐在鍵盤前，逐行指導 Agent 時，提示工程（Prompting）是必備技能。而現在，當 Agent 可以被賦予一個目標並讓它自行運作時，循環工程（Loop Engineering）才是關鍵技能。這是一條從前者邁向後者的完整 20 步路徑，按照順序排列，因為這個順序比任何單一步驟都更重要。
在列出步驟之前，先說明為何順序如此重要。循環工程並非一項要嘛會、要嘛不會的單一技能。它是一個堆疊，每一層都依賴於下一層的穩固。在擁有真正的停止條件（第 10 步）之前，先建立排程觸發器（第 14 步），只會讓你自動化一個無人監控時也能浪費錢的系統，而不僅僅是你在看著的時候浪費。在擁有真正的驗證機制（第 6、7 步）之前，先建立持續化儲存（第 11 步），代表你只是在仔細記錄從一個可能對錯誤輸出照單全收的「評判官」那裡學到的教訓，這會讓持續化層變得有害，而不只是無用。在這份清單上跳步，不僅僅是錯過一個功能而已。它意味著在一個無法支撐它們的基礎上，建造那些看起來很吸引人的部分，並且只能在問題大規模發生之後，才會發現這一點。
第一階段：心態轉變（第 1 至 4 步）
第 1 步：承認你自己才是瓶頸，而不是模型
第一個真正的步驟並非技術性的。是承認你當前工作流程中的限制因素，並非模型的能力，而是你自己在循環中的存在。每次你坐下來等待回應、閱讀它、然後輸入下一條指令，你都是這個系統中慢得多的部分。模型的執行、驗證和重試速度，遠比你監督它做這些事要快。
這一步沒有附帶任何提示。它是一個決定。在你真正相信這一點之前，後續的每一步都會感覺像是不必要的開銷，而不是它真正的樣子——移除真正的瓶頸。
第 2 步：停止混淆「更長的提示」與「更好的系統」
當事情出錯時，本能反應是對同一條提示添加更多指令。幾個月下來，這會產生一條又長又充滿矛盾規則的提示，模型無法同時將其全部記在工作記憶中，因此它會匹配最顯眼的部分，並悄悄忽略其餘部分。
循環工程完全取代了這種本能。你不再向提示添加規則，而是向系統添加一個組件。一個驗證步驟。一個記憶檔案。一個排程觸發器。提示本身應該隨著周圍系統能力的增強而變短，而不是相反。
第 3 步：學習將每個任務視為五個動作
循環中的任何一次單一輪次，無論具體領域為何，都可以分解為五個動作：發現（釐清實際需要做什麼）、交接（將任務傳遞給執行者）、驗證（根據實際情況檢查結果）、持續化（記錄發生的事，以免遺失）、排程（決定何時再次執行）。
大多數人當前的工作流程中，只有兩個動作是明確的：發現和交接，而且是在聊天視窗中手動完成。其他三個動作要嘛不存在，要嘛在人腦中無形地發生。循環工程就是將這五個動作全部明確化、自動化的實踐。
第 4 步：找出你的第一個真正的候選任務
在開始構建任何東西之前，先挑選一個你已經重複在做、並且其標準是你可以應要求寫下來的任務。不是你最難的問題。也不是完全新穎的任務。一個具有真實、可識別的「完成定義」的任務，同事看一眼就能立即同意任務是否正確完成。這個限制條件比看起來更重要。一個沒有明確完成定義的任務，無法為其構建第三步的驗證，而一個沒有真正驗證的循環，就不是一個循環，它只是一個無人監控的猜測。
第二階段：構建第一個循環（第 5 至 9 步）
第 5 步：在撰寫任何提示之前，先寫下完成定義
這一步是大多數人會跳過的，也決定了之後的一切是否有效。在你為 Agent 撰寫任何一條指令之前，先用白話文寫下，一個正確的結果究竟長什麼樣子。具體的、可檢驗的標準，而不是一種模糊的品質感覺。
[任務名稱] 的完成定義：
- [具體的、可檢驗的標準 1]
- [具體的、可檢驗的標準 2]
- [具體的、可檢驗的標準 3] 如果缺少上述任何一項，即使輸出看起來完整或精美，此任務也「未」完成。
如果你無法為你選擇的任務填寫這個表格，請回到第 4 步，選擇另一個任務。
第 6 步：將執行者與評判官分開
任何循環中最重要的架構決策。負責產出結果的角色和負責檢查結果的角色必須分開，因為模型在生成結果的同一口氣中審查自己的輸出，往往傾向於為該輸出辯護，而不是真正地審視它。
執行者擁有創意空間，並產出初步嘗試。評判官則接收執行者的輸出以及第 5 步的完成定義，除此之外別無其他，以免被說服。理想情況下，評判官還能取得執行者沒有的東西——測試套件、原始來源文件、即時資料——這樣它的判斷才能來自真實證據，而不是僅由與第一份意見相同方式形成的第二意見。
第 7 步：為評判官提供真實依據，而不僅僅是意見
一個只看見執行者輸出結果的評判官，只能告訴你結果看起來是否連貫。它無法告訴你結果是否真正正確。對於程式碼任務，真實依據是測試套件和實際的執行輸出。對於內容任務，是原始來源材料和客戶簡報，與草稿並列。對於研究任務，是應該被使用的實際文件。
如果你無法說出你的評判官將要檢查的具體真實依據是什麼，那麼你的循環就還沒有真正的驗證，無論評判官的口吻聽起來多麼自信。
第 8 步：先撰寫交接格式，再撰寫交接提示
執行者的輸出和評判官的判斷，都需要一個定義好的結構，而不是連綿不絕的散文，否則下一步的「管理者」就沒有任何可靠的東西可以進行路由。
執行者輸出：交付物 + 信心水準 + 已知不確定性
評判官判決：通過 / 失敗 / 需要修改 + 發現的具體問題 + 這是根據哪個真實依據檢查的
第 9 步：在自動化任何事之前，先手動按順序完整執行一次
在設定排程或自動重試之前，請自己手動完整地按照「執行者→評判官」的順序執行一次。批判性地閱讀評判官的判決。你會同意它的判斷嗎？如果評判官通過了你明知是錯的內容，或者否決了實際上沒問題的內容，請在繼續前進之前修正真實依據或標準。自動化一個有缺陷的驗證步驟，只會更快地產生有缺陷的結果。
一個貫穿第 5 至 9 步的實例
為了讓這最後五個步驟更具體，這裡展示它們如何在一個真實、常見的任務中運作：將一份原始來源文件轉換成一篇完成的內容。
完成定義（來自第 5 步）：草稿中的每個事實性主張都能追溯到來源文件中實際存在的內容。草稿滿足客戶簡報中的每個具體要求：長度、語氣、所需結構。核心論點清晰呈現，沒有被填充內容稀釋。
執行者（來自第 6 步）接收來源和客戶簡報，產出草稿，並附帶一份明確聲明，說明它在寫作過程中對哪些部分不確定——一個不確定是否完全在來源中的數字，一個它推斷而非直接找到的主張。
評判官（來自第 7 步）接收草稿和原始來源，並將它們並排放置，絕不單獨看草稿。它會分別檢查三個完成定義標準中的每一個，針對每個標準分別返回「通過」或「失敗」，而不是一個混合的總體分數。將三個不同的檢查合併成一個判斷，恰恰會隱藏究竟是哪個維度真正失敗了，這是一個正常運作的循環悄悄停止提供有用反饋的最常見方式。
交接格式（來自第 8 步）意味著評判官的判決以一個結構化物件的形式送達，而不是一段帶有保留的散文——三個明確的通過或失敗結果，並附上任何失敗的具體原因。
根據第 9 步，在自動化任何事之前手動執行一次，正是為了捕捉那些評判官過於寬容（因寫作風格精美而通過了帶有捏造統計數據的草稿）或過於嚴格（因從未在客戶簡報中出現的風格偏好而否決草稿）的情況。這兩種失敗模式在第一次嘗試時都很常見，而且手動捕捉一次的成本，遠低於在循環已經無人監控運行了五十次之後才發現。
第三階段：為循環添加缺失的組件（第 10 至 14 步）
第 10 步：構建管理者及其停止條件
管理者讀取評判官的判決，並決定下一步該怎麼做。這也是循環的停止條件所在之處，它必須被寫成硬性邏輯，而不是一條模型可以自我說服繞過的軟性指令。
停止條件：
- 最大修改次數：3 次。在第 3 次失敗的判決後，將完整歷史記錄升級給人類處理，不要嘗試第 4 次循環。
- 品質門檻：完成定義中的每一項都必須顯示「通過」。
- 預算上限：如果此任務超過 [X] 成本或 [Y] 時間，無論當前狀態如何，立即停止。
一個沒有真正停止條件的循環不是一個系統。它是一個潛在的負債，等待著任務真正變得無法解決的那一天到來。軟性指令在這裡失敗的具體原因值得理解，而不僅僅是接受。「在它夠好的時候停下來」這個指令在提示中只是一個建議，而一個承受足夠壓力（已經失敗了幾次修改）的模型，往往會說服自己相信當前的嘗試已經足夠接近、可以通過，正是因為它想為這個任務產生一個令人滿意的解決方案。一個由程式碼或明確規則（管理者無法繞過）機械地檢查的硬性迭代計數器，則沒有這種失敗模式。
第 11 步：添加持續化儲存，讓循環能在多次運行中記住資訊
一個每次運行都從零開始的循環，對於上次學到的東西沒有任何記憶。添加一個簡單的持續化層：每個真正的新教訓建立一個檔案，頂部有一行摘要，記錄學到了什麼、修正了什麼以及為什麼重要。關鍵是，只記錄尚未在其他地方捕獲的內容——重複的記憶是雜訊，不是知識。
讓這一步長期真正有效的紀律，是在寫入時的克制。本能反應是記錄會話中發生的所有事情，這恰恰會產生這份路線圖在第 2 步警告過的臃腫記錄問題，只是把它移到了記憶資料夾而非提示中。一個值得寫下來的教訓，是那些如果被遺忘就需要花費真實時間重新發現的東西，而不是那些完全按預期成功的例行工作記錄。
第 12 步：按計劃進行整合
僅靠持續化儲存最終會產生與臃腫提示相同的問題：數十個文件，其中許多都在說同一件事的不同版本。按照一個定期計劃（每週一次是合理的），審查記憶檔案，合併重複的內容成為更精煉的教訓，並刪除任何後來被證明是錯誤的內容。目標是更少的檔案，但每個密度更高，而不是一個不斷增長的堆積。
這一步是大多數人完全跳過的，因為它本身不會產生任何可見的新能力，它只是預防未來的問題。這種隱形特性正是它需要被明確排程的原因，而不是留待有人注意到記憶資料夾變得難以管理時才進行。實際上，這意味著直到循環的表現已經開始在相互矛盾、半相關的教訓爭奪同一上下文視窗的壓力下退化時，這件事才會發生。
第 13 步：添加回顧步驟
在任何新循環開始時，讓循環掃描記憶中的一行摘要，識別哪些教訓與當前任務相關，並僅載入那些相關的。明確指示它，當記憶中沒有任何東西適用時要說出來，而不是僅僅因為記憶存在，就將一個不相關的過去教訓硬套到新的情況上。
第 14 步：添加排程觸發器
決定這個循環何時運行，而不需要你手動啟動它。一個 cron 任務。一個檔案監控器。一個由日曆驅動的定期觸發器。這一步是將一個「按需運行」的系統，轉變為一個「在你睡覺時運行」的系統。這通常是這整個清單中最簡單的一步，也是大多數人在構建了其他所有東西後，卻從不費心去實現的一步。
第四階段：規模化與強化（第 15 至 18 步）
第 15 步：在信任循環之前，對其進行壓力測試
在依賴這個循環處理任何真實任務之前，刻意針對四種失敗模式進行測試。
- 給它一個真正無法解決的任務版本，並確認管理者確實會停止，而不是無限循環。一個只在它能完成的任務上測試過的循環，從未真正證明它知道如何優雅地失敗。
- 給評判官一個你明知有微妙錯誤的輸出——一個讀起來很好，但包含你刻意植入的特定事實或邏輯錯誤的輸出——並確認它確實能捕捉到這個缺陷，而不是讓聽起來合理的內容通過。
- 如果執行者和評判官共享同一個底層模型，給評判官一個該模型典型會犯的錯誤，看看它是否會讓這個錯誤通過。一個與執行者共享盲點的評判官，完全違背了第 6 步中將它們分開的目的。
- 計算循環運行到其最大修改限制時的最壞情況成本，使用你最昂貴的模型呼叫和最長的合理輸出，並誠實地判斷這個數字出現在真實帳單上是否會讓你感到震驚。
在信任一個循環處理重要事務之前，運行這四個測試，可以捕捉到絕大多數原本會首次出現在客戶、老闆或你自己的銀行帳單面前的失敗，而不是在你刻意進行的控制測試中出現。
第 16 步：將任務路由到正確的模型，而不是每次都使用同一個
一旦循環運作起來，要抵制將循環的每個部分都運行在你最喜歡的單一模型上的習慣。執行者角色通常受益於你最強大的模型，因為它正在進行實際的困難推理，一個較弱的模型在這裡會產生更差的初稿，需要花費更多修改週期來修復，比一開始就產生好結果所花的成本更高。
評判官角色，根據特定的書面標準進行檢查，通常在更小、更便宜、更快的模型上表現得同樣可靠，因為它不需要創造力，只需要一致性。一個較小的模型，根據一個極其詳細的檢查清單進行檢查，其表現常常能媲美一個大型模型，而成本和延遲卻只有一小部分。
管理者，根據你已經寫下的規則進行路由，幾乎從不需要你最昂貴的模型，因為它的工作是執行你已經指定的邏輯，而不是開放式推理。而且無論執行者和評判官的表現如何，它至少每輪迭代運行一次，這使得它的每次呼叫成本比它的原始能力更重要。
這種分層方法——昂貴的模型用於構建，便宜且一致的模型用於判斷例行檢查，便宜的模型用於路由——通常是循環中真正節省成本的地方。大多數人認為成本控制意味著更少的循環或更少的修改。實際上，它來自於將模型成本與你已經構建的循環中每個特定角色的實際難度相匹配。
第 17 步：擴展到第二個循環，而不是同時擴展到五個
第一個循環成功後，誘惑是立即再構建幾個，並行處理五個不同的任務，因為架構理論上現在支持了。抵制這個誘惑，比感覺舒適的時間更長一點。讓一個循環足夠可靠地運行，直到你真正不再密切檢查它的輸出——意味著它在真實的時間跨度內，持續通過你自己的手動抽查，而不僅僅是一次大家都仔細觀看的成功示範運行。只有這樣，才開始第二個循環，針對一個不同的任務。理想情況下，選擇一個與第一個任務完全不同領域的任務，這樣你是在測試底層骨架是否通用，而不僅僅是進一步調整同一個任務。
第 18 步：為所有正在運行的循環提供一個統一視圖
一旦你有多個循環在運行，要追蹤所有循環的成本和停止條件觸發的統一視圖，而不是孤立地看每個循環。一個單一循環，有合理的每任務預算，單獨看起來完全沒問題。十個各自在預算內的循環，加起來仍然可能產生一個驚人的總數，而沒有人注意到，直到總帳單送達，正是因為每個單獨循環的追蹤看起來都很好。
特別記錄每一次停止條件的觸發，而不僅僅是成功的完成。一個不斷達到其修改上限的循環，而其他循環很少這樣，這告訴你的是它的評判官標準校準不當——太嚴格以至於永遠無法通過，或者根據錯誤的真實依據進行檢查——而不是底層任務本身很難。如果你只追蹤成功，並將每一次升級視為一個孤立的、不起眼的事件，而不是關於該特定循環設計的數據點，那麼這種模式是看不見的。
第五階段：成為系統設計師（第 19 和 20 步）
第 19 步：停止用撰寫了多少提示來衡量自己
轉變已經發生的最明顯跡象，是你日常關注點的改變。一個提示設計師會追蹤自己寫了多少好的提示。一個系統設計師會追蹤有多少循環在運行，每個循環的可靠性如何，以及那些不再需要監督的系統為自己節省了多少時間。如果你仍然在用輸入的提示數量來衡量自己的生產力，那麼無論你技術上構建了多少個循環，來自第一步的心態轉變都還沒有完全落地。
第 20 步：教會其他人這五個動作
最後一步實際上不再關乎你自己的系統了。它關乎確認你是否真正內化了這個轉變，方法是向其他人解釋它，而不使用行話。發現、交接、驗證、持續化、排程。如果你能僅使用這五個動作和上述步驟，引導另一個人構建他們自己的第一個循環，那麼你就完成了這份路線圖所描述的實際轉變。你不再是循環內部、輸入下一條指令的那個人。你是設計了它、站在外部、看著它運行的那個人。
跳步會悄悄累積的四種成本
值得以一個警告作為結尾，因為在這份路線圖上跳步，並不會大聲地失敗，它會悄悄地失敗，以一種只在很久以後才顯現的方式。
驗證債 在你跳過第 6 和第 7 步時累積：構建沒有真正評判官或真實依據的循環。循環看起來像在運作，因為輸出看起來不錯——直到一個錯誤在數十次運行中悄然複合，然後才有人注意到。
理解力腐化 在你跳過第 20 步時發生：運行你曾經構建、但一旦崩潰就無法解釋或除錯的循環，因為你從未需要內化每個部分存在的原因。
認知投降 發生在第 1 步從未真正落地時：當你出於習慣，在驗證系統已經證明自己之後很久，仍然手動仔細檢查每個輸出，這完全違背了構建系統的初衷。
代幣爆炸 是你跳過第 10 步時會發生的事：運行沒有真正停止條件的循環，只有在帳單送達時才發現實際成本。
這些成本中的每一個都是可以避免的，而且每一個都可以通過同樣的紀律來避免。按順序構建步驟。不要跳過那些看起來不吸引人的步驟。那些無聊的步驟——完成定義、停止條件、真實依據——才是真正在做功的部分。那些聽起來有趣的東西——巧妙的提示、精密的架構圖——比起你構建的系統是否真正知道它何時是對的、何時是錯的、以及何時該停止，其重要性要小得多。
這就是提示設計師和系統設計師之間的完整區別。不是聰明才智。而是關於那些構建起來無聊、又容易被跳過的部分的紀律。
關注 @cyrilXBT 以獲取這份路線圖中每一步背後確切的循環模板和執行者-評判官-管理者設定。
