當人類仍需坐在鍵盤前，逐行指導智能體工作時，核心能力是編寫提示詞。如今，智能體已能接收一個目標，然後自行運行，新的核心能力便是迴圈工程。

文章作者：CyrilXBT

文章編譯、來源：ME News

在 2026 年 6 月，一週之內，三個人各自獨立地得出了同一個結論。

OpenClaw 的開發者 Peter Steinberger 公開表示，人們應該停止直接為編程智能體撰寫提示詞，轉而設計能夠自動向智能體發出指令的迴圈系統。

幾乎在同一時間，Anthropic Claude Code 的負責人 Boris Cherny 也表示，他已不再直接向 Claude 輸入提示詞。現在，他運行的是一套能夠自動調用 Claude、判斷下一步該做什麼的迴圈，而他真正的工作，是編寫和設計這些迴圈。

幾天後，Google 工程師 Addy Osmani 對這一實踐進行了系統總結，並給出了一個名字：

Loop Engineering，循環工程。

他們並不是憑空創造了這種工作方式，而是為一種已經悄然發生的變化命名。

在這之前，底層工具已跨越了一個關鍵臨界點：編程智能體開始能在無人值守的情況下完成真正的任務；自動調度的成本足夠低，反覆定時運行一項任務不再顯得浪費；單次智能體運行的成本也下降到一個新水平——與其花大量時間精心思考一次，不如讓智能體嘗試五次，成本可能反而更低。

這正是這份路線圖存在的原因。

當人類仍需坐在鍵盤前，逐行指導智能體工作時，核心能力是編寫提示詞。如今，智能體已能接收一個目標，然後自行運行，新的核心能力便是迴圈工程。

以下是一條從提示詞操作者走向系統設計者的完整 20 步路徑。必須按順序推進，因為在這條路徑中，步驟之間的先後關係，往往比任何單獨一個步驟都更加重要。

循環工程並非一種「掌握了」或「沒掌握」的單一技能，而是一套層層疊加的能力棧。每一層，都依賴下方基礎是否足夠牢固。

例如，在第 10 步尚未建立真正的停止條件前，就直接建置第 14 步的自動排程觸發器，只會得到一個能在無人監管下自動浪費資金的系統。過去它至少只會在你盯著螢幕時浪費資源，現在它能自行持續燒錢。

同樣，如果在完成第 6 步和第 7 步的可靠驗證機制之前，就先搭建第 11 步的持久化記憶層，你可能會把一個過於寬鬆、不斷放行錯誤結果的「評審者」所總結出的經驗認真保存下來。

這不僅不會幫助系統進步，反而會讓錯誤經驗不斷累積，使記憶層從「暫時無用」變成「主動有害」。

因此，跳過某些步驟並不只是少實現一個功能。更嚴重的問題在於，你會把那些看起來令人興奮的高級能力，建立在一個根本無法支撐它們的基礎之上，並且往往要等到系統已經規模化運行、造成實際後果之後，才會發現問題。

真正的第一步並不涉及任何技術。

你必須承認，在當前的工作流程中，限制效率的因素往往已不再是模型能力，而是你本人仍然停留在循環之中。

每當你坐在電腦前等待模型回應、閱讀結果，再輸入下一條指令時，你就成為了整個系統中最慢的環節。

模型可以執行、驗證和重試，而這些操作的速度遠遠快於人類逐步監督它完成任務的速度。

這一步沒有對應的提示詞，它是一項認知決策。

在你真正接受這一點之前，後續所有步驟看起來都會像是不必要的額外工作，而不是它們真正的意義——移除系統中最大的效率瓶頸。

當模型輸出出現問題時，人們最自然的反應，通常是在原來的提示詞中再增加一條規則。

幾個月後，這種做法會築起一堵由規則組成的高牆：內容密集、彼此矛盾，長到模型無法在工作記憶中同時處理所有要求。

最終，模型往往只能根據最近出現或看起來最顯眼的內容進行模式匹配，並在不知不覺中忽略其他規則。

Circular engineering has completely transformed this mindset.

當問題出現時，你不再只是向提示詞裡添加一條新要求，而是為系統增加一個新的組件，例如：

• 增加一個獨立驗證步驟；
• 新增一個記憶檔案；
• 新增一個定時觸發器；
• 增加一個結構化評審環節。

As the capabilities of external systems continue to improve, prompts should become shorter, not longer.

無論具體任務屬於哪個領域，循環中的每一次運行，都可以拆解為五個基本動作：

Identify, Handover, Verify, Persist, Schedule.

識別（Discovery）

弄清楚真正需要完成的任務是什麼。

交接（Handoff）

Assign the task to the model, agent, or tool responsible for execution.

驗證（Verification）

Check the results against actual standards.

持久化（Persistence）

記錄本次運行發生了什麼、學到了什麼，避免經驗在下一次運行時遺失。

調度（Scheduling）

決定這套流程何時再次運行。

大多數人的現有工作流程，僅明確包含了前兩個動作：識別任務 和 交接任務，而且通常是在聊天窗口中手動完成的。

另外三個動作要麼根本不存在，要麼隱藏在人類自己的大腦中。

The core of circular engineering is to explicitly define all five actions and automate them as much as possible.

在開始搭建系統之前，先選擇一項你已經在重複執行、並且能夠明確描述質量標準的任務。

不要選擇最困難的問題，也不要選擇完全沒有先例的創新任務。

第一個候選任務應該滿足三個條件：

1. 你需要反覆執行它；
2. 它擁有可以寫下來的明確標準；
3. 它有一個容易識別的「完成狀態」。

換句話說，一位同事看到結果後，應該能夠迅速判斷這項任務是否被正確完成。

這一限制比表面上看起來更加重要。

如果一項任務沒有清晰的完成標準，就無法構建真正的驗證環節。而一個沒有可靠驗證機制的循環，並不是真正的循環，只是一次無人監督的猜測。

這是大多數人最容易跳過的一步，卻也是決定後續系統能否正常運行的關鍵步驟。

在為智能體編寫任何指令之前，先用清晰、自然的語言寫下：一個正確結果究竟應該是什麼樣子。

你需要的是具體、可檢查的標準，而不是「感覺不錯」「看起來專業」之類模糊的質量判斷。

可使用以下模板：

任務名稱：[任務名稱]

完成定義（Definition of Done，DoD）：

• [具體、可檢查的標準 1]
• [具體、可檢查的標準 2]
• [具體、可檢查的標準 3]

即使最終輸出看起來完整且經過精心潤色，只要缺少上述任何一項，這項任務就不能被視為已經完成。

如果你無法為當前選擇的任務填寫這份模板，就應該回到第 4 步，重新選擇一項更適合構建循環的任務。

This is the most important architectural decision in all circular systems.

負責生成結果的角色，與負責檢查結果的角色，必須彼此分離。

原因是，當模型在生成內容後立即審查自己的輸出時，往往會傾向於為剛剛生成的答案辯護，而不是真正從批判的角度審視其中的問題。

在一套合理的循環中，至少應該存在兩個獨立角色：

構建者（Builder）

建造者擁有一定的創造空間，負責生成第一個版本的結果。

評審者（Judge）

評審者接收建構者的輸出，以及第 5 步制定的完成定義，並依據這些標準判斷結果是否合格。

理想情況下，評審者還應該能夠訪問建設者無法訪問的獨立證據，例如：

• 測試套件；
• 原始資料；
• 實時數據；
• 權威資料庫；
• Original task brief.

這樣，評審者的判斷才能建立在真實證據上，而不是用與構建者相同的思路，再生成一次主觀意見。

如果評審者只能看到建構者的輸出，它最多只能判斷結果「看起來是否連貫」。

它無法判斷結果是否真正正確。

因此，評審者必須擁有可核對的客觀依據，也就是 Ground Truth。根據具體語境，可將其理解為「基準事實」「真實數據」或「權威依據」。

For different tasks, the objective criteria also vary.

編程任務

The objective basis is the test suite and the actual output generated by the code during execution.

內容生產任務

客觀依據為原始資料和內容簡報。評審者需將原始資料與生成稿件並排比較。

研究任務

The objective basis is the original documents, papers, datasets, or authoritative sources explicitly required for the task.

如果你無法明確說出評審者需要依據什麼進行檢查，那麼你的迴圈就還沒有真正的驗證機制，無論評審者的措辭聽起來多麼自信。

構建者的輸出和評審者的結論，都必須採用明確定義的結構，而非僅為自由流動的自然語言。

否則，下一階段的管理員將無法獲得穩定且可靠的資訊以進行判斷和路由。

構建者可採用以下輸出格式：

建造者輸出：

• 最終交付內容；
• 對結果的信賴程度；
• Known uncertainties.

評審者可採用以下輸出格式：

評審結論：

• PASS：通過；
• FAIL：失敗；
• 需要修改；
• 發現的具體問題；
• The objective criteria or original evidence used for this inspection.

在接入自動調度和自動重試之前，請先親自手動運行一次完整的「構建者—評審者」流程。

仔細閱讀評審者提供的判斷，並問自己：

• 你是否同意它的結論？
• 它有沒有放過一個你明知存在錯誤的結果？
• 它有沒有錯誤地否定了原本合格的結果？

如果評審者通過了一個你知道是錯誤的結果，或者否定了一個實際上沒有問題的結果，應當先修正客觀依據或完成標準，再繼續搭建系統。

自動化一個錯誤的驗證步驟，只會讓系統以更快的速度產生錯誤結果。

為了讓上述五個步驟更加具體，我們可以觀察一個常見任務：把一份原始資料轉化為一篇完整文章。

第 5 步：制定完成定義

本任務的完成標準可以是：

• 草稿中的每一項事實，都能夠追溯到原始資料中的明確內容；
• 草稿符合簡報中的所有具體要求，包括篇幅、語氣和結構；
• 原文的核心論點得到清晰保留，沒有被無意義的填充內容稀釋。

第 6 步：構建者生成草稿

構建者接收原始資料和內容簡報，生成一版草稿。

與此同時，它還需要明確列出寫作過程中存在的不確定性，例如：

• 某個數字是否真的出現在原始資料中；
• 該結論是原文明確表述，還是由模型自行推斷；
• 該事實是否缺乏足夠的來源。

第 7 步：審核者對照原文檢查

評審者同時接收草稿和原始資料，而非僅接收草稿。

它需要分別檢查完成定義中的三個標準，並對每一項標準單獨給予通過或失敗的結論，而不是將所有維度壓縮成一個模糊的綜合分數。

將三個不同標準合併成一個總體判斷，會掩蓋究竟是哪一個維度出現了問題。這是許多原本能夠運行的循環，逐漸失去反饋價值的最常見原因。

第 8 步：結構化交接

評審者的結論應為一個結構化物件，而非一段充滿保留措辭的自然語言。

它需要輸出三個明確的通過或失敗結果，並針對每一項失敗提供具體原因。

第 9 步：手動驗證評審機制

在系統自動運行之前，手動執行一次完整流程，能夠幫助你發現評審者是否過於寬鬆或過於嚴格。

過於寬鬆的審稿人，可能因為文章寫得流暢，就放過其中虛構的數據。

過於嚴格的審稿者，可能因某種從未寫入簡報的個人風格偏好，錯誤地否決一篇合格的文章。

這兩種問題在首次設置時都很常見。

而在系統無人值守地運行 50 次之後再發現它們，遠比第一次手動測試時解決問題更加昂貴。

管理器（Manager）負責讀取評審者的判斷，並決定下一步操作。

停止條件也應存在於管理器中，且必須以明確的硬性邏輯撰寫，而非一條模型可透過自我解釋繞過的軟性指令。

例如：

停止條件：

• 最大修改次數：3 次；
• 當第三次審核仍失敗時，請將完整歷史記錄提交給人工處理，不得啟動第四次修改；
• 品質標準：必須顯示每一項定義均為 PASS；
• 預算上限：如果任務成本超過 X，或運行時間超過 Y，不論當前狀態如何，都必須立即停止。

一個沒有真正停止條件的循環不是系統，而是一項等待暴露風險的負債。

為何「當結果足夠好時停止」之類的軟性指令不可靠？

因為這只是一條建議。

當模型已連續修改多次仍未通過時，為了為任務提供一個看似令人滿意的結局，它很可能說服自己相信「這一版已經足夠接近標準」，從而自行降低判斷門檻。

In contrast, iterative counts checked mechanically by code or explicit rules that managers cannot bypass through reasoning do not suffer from this issue.

如果一套循環每次啟動時都從零開始，它就不會記得上一次運行學到了什麼。

因此，需要增加一個簡單的持久化層。

可以為每一條真正的新經驗建立一個檔案，並在檔案頂部用一句話概括：

• 學到了什麼；
• 修正了什麼；
• 為什麼這項經驗重要。

關鍵原則是：僅記錄尚未在其他地方儲存的新知識。

重複的記憶不是知識，而是噪音。

要讓持久化機制長期有效，必須在寫入時保持克制。

人們很容易產生記錄所有運行細節的衝動，但這樣只會重現第 2 步提到的「臃腫提示詞」問題，只不過這次，膨脹的對象從提示詞變成了記憶資料夾。

真正值得記錄的經驗，是那些一旦遺忘，就需要花費大量時間重新發現的內容，而不是某次按預期順利完成的普通運行記錄。

單純增加持久化機制，最終也會產生與超長提示詞類似的問題。

隨著時間推移，系統會累積幾十個檔案，其中許多內容只是對同一問題的略微不同表述。

因此，應按照固定週期對記憶檔案進行整理。每週執行一次通常是一個合理的頻率。

整理過程包括：

• 審查現有記憶；
• 合併重複內容；
• 將多個相似經驗壓縮成一條更明確的原則；
• 刪除已被證明錯誤或過時的內容。

目標不是累積越來越多的文件，而是獲得數量更少、資訊密度更高的知識。

很多人會完全跳過這一步，因為它不會立刻帶來肉眼可見的新能力，只是在預防未來的問題。

But precisely because it lacks immediate feedback, it should be clearly scheduled in, rather than waiting until someone discovers that the memory folder has become difficult to manage.

在現實中，這種「以後有空再整理」的任務通常永遠不會發生，直到系統性能因大量矛盾、過時和半相關的記憶爭奪上下文窗口而開始下降。

每次新任務開始時，讓迴圈先掃描記憶檔案中的一句話摘要，判斷哪些經驗與當前任務真正相關，並只載入這些相關內容。

同時，還應當明確要求系統：如果現有記憶沒有任何內容適用於當前任務，就直接說明沒有適用經驗。

不要因為記憶系統已經存在，就強行把過去的經驗套用到一個完全不同的新問題上。

接下來，需要決定這套循環在沒有人工啟動的情況下何時自動運行。

觸發方式可能包括：

• Cron 定時任務；
• 文件變更監聽器；
• 基於日曆的週期觸發器；
• 當某個外部事件或狀態發生變化時觸發。

這一步會將一套只能由你手動啟動的系統，轉變為一套能在你睡覺時繼續運行的系統。

諷刺的是，這通常是整份清單中最容易實現的一步，卻也是許多人即使已經完成其他組件，仍然遲遲沒有實施的一步。

在將迴圈用於任何重要任務之前，需主動針對四種故障模式進行測試。

測試一：無法完成的任務

給系統一個真正無法解決的任務版本，確認管理器能夠按照停止條件退出，而不是無限迴圈。

如果一套循環只在能夠成功完成的任務上接受過測試，它就從未證明自己擁有優雅失敗的能力。

測試二：看起來合理但實際錯誤的結果

向評審者提供一個你明確知道存在細微錯誤的輸出。

這個結果應該讀起來非常流暢，但包含一個你有意植入的事實或邏輯錯誤。

觀察評審者能否發現問題，而不是僅僅因為內容聽起來合理就予以通過。

測試三：構建者與評審者共享模型盲區

如果構建者和評審者使用同一個底層模型，可以故意加入該模型經常犯的典型錯誤，觀察評審者是否會放過它。

如果評審者與構建者擁有相同的盲區，那麼第 6 步所設計的角色分離就失去了意義。

測試四：計算最壞情況下的運行成本

Based on the maximum number of modifications, using the most expensive model invocation and the longest output within a reasonable range, calculate the total cost this loop would consume under the worst-case scenario.

然後誠實地問自己：

如果這筆數字出現在真實賬單上，你是否會感到不安？

在處理重要任務之前，完成這四項測試，可提前發現絕大多數潛在問題。

否則，這些問題很可能會首次出現在客戶或管理者面前，或直接體現在你的帳單上，而非出現在你主動控制的測試中。

當迴圈能穩定運行後，不要讓所有角色都使用同一個你最喜歡的模型。

在循環中，不同角色對模型能力的要求並不相同。

Builder

建築者通常應使用能力最強的模型。

因為它承擔主要的複雜推理和內容生成工作。如果在這裡使用能力不足的模型，第一版結果的質量會下降，後續可能需要更多修改輪次。

最終，修正低品質初稿所消耗的成本，可能高於一開始就使用更強模型的成本。

審核者

審核者負責根據明確標準進行檢查，通常不需要太強的創造力。

當標準足夠具體時，一個規模更小、成本更低、速度更快的模型，往往也能可靠地完成評審任務。

一個小型模型若依據極其明確的檢查清單運作，其穩定性可能接近大型模型，但成本和延遲均顯著更低。

管理員

管理器僅根據預先編寫的規則進行路由，幾乎從不需要使用最昂貴的模型。

它的任務是執行已定義好的邏輯，而不是進行開放式推理。

此外，無論建造者和審查者表現如何，管理器在每輪迭代中至少都會運行一次，因此其單次調用成本尤其值得關注。

合理的分層配置通常是：

• 強模型負責構建；
• 便宜而穩定的模型負責常規審查；
• 低成本模型或規則程式負責路由和管理。

在循環系統中，真正的顯著成本優化通常來自於這種模型角色匹配。

很多人認為控制成本意味著減少循環數量或修改次數。實際上，更有效的方法，是讓模型成本與循環中每個角色的實際難度相匹配。

第一個循環成功後，人們很容易立即嘗試同時建構多個循環，平行處理五種不同任務。

即使當前架構已經能夠支援這種擴展，也應當克制這種衝動。

你應該先讓第一個迴圈穩定運行足夠長的時間，直到你真正不再需要密切檢查它的每一次輸出。

這並不是指某次所有人都在認真觀看的演示恰好成功，而是指它經過一段真實運行後，仍然能夠持續通過人工抽查。

只有達到這一狀態，才應該開始構建第二個循環。

第二個循環最好處理一種與第一個循環明顯不同的任務。

This is the only way to verify whether the underlying architecture truly has generalizability, rather than just becoming increasingly fine-tuned for the same task.

當你同時運行多個循環後，需要建立一個統一的監控視圖，集中追蹤所有循環的成本和停止條件觸發情況，而不是分別查看每一個循環。

單獨來看，一套循環的任務預算可能完全合理。

但如果十套循環都各自在預算範圍內運行，它們的總成本仍然可能達到一個令人意外的水平。

由於每個循環的獨立數據看起來都很正常，這種風險通常要到匯總帳單出現時才會被發現。

除了成功完成的任務之外，還需專門記錄每一次停止條件的觸發。

如果某個循環頻繁觸及最大修改次數，而其他循環很少出現這種情況，它傳遞的訊號可能不是「這項任務特別困難」，而是：

• 評審標準設定不合理；
• 評審者過於嚴格，導致任何結果都無法通過；
• 系統檢查了錯誤的客觀依據；
• 完成定義本身存在問題。

如果僅追蹤成功結果，並將每次人工升級視為彼此無關的偶發事件，這種設計層面的模式就不會被發現。

判斷思維轉變是否真正完成，最明顯的標準，是你日常關注的指標發生了變化。

提示詞操作者關心的是：

• 今天寫了多少條有效提示詞；
• 哪條提示詞效果最好；
• 如何將提示詞寫得更為精巧

系統設計者關心的是：

• 目前有多少組循環正在運行；
• 每套循環的可靠性如何；
• 系統為自己釋放了多少時間；
• 哪些工作已經不再需要人工監督。

如果你仍然以輸入了多少條提示詞來衡量自己的生產力，那麼無論技術上已經搭建了多少個迴圈，第 1 步要求的思維轉變都還未真正完成。

最後一步已不再完全關於你自己的系統。

它用於驗證你是否真正理解了這套方法。

你需要嘗試在不依賴複雜術語的情況下，向另一個人解釋五個基本動作：

Identify, Handover, Verify, Persist, Schedule.

如果你能僅靠這五個動作和前面的步驟，帶領另一個人建構出他的第一個循環，就代表你已實現了本路線圖所描述的真正轉變。

你不再是那個待在迴圈內部、不斷輸入下一條指令的人。

你成為了站在循環之外、設計系統並觀察它自行運行的人。

跳過步驟後，會悄然累積的四種成本

在文章結尾，有必要給出一個警告。

跳過這份路線圖中的步驟，往往不會立即導致系統崩潰。

它的失敗通常是安靜的，甚至在很長一段時間內都難以察覺，直到問題已累積到相當嚴重的程度。

當你跳過第 6 步和第 7 步，沒有建立真正獨立的評審者，也沒有提供可靠的客觀依據時，驗證債務就會開始累積。

迴圈表面上看起來仍然在正常運作，因為產生的結果「看起來還不錯」。

直到某個錯誤在幾十次運行中不斷累積，最終被人發現時，你才會意識到，系統從一開始就沒有真正判斷結果是否正確。

當你跳過第 20 步時，就可能出現理解退化。

你仍在運行自己曾經構建的迴圈，卻已無法清楚解釋每個組件為何存在，也無法在系統故障時有效調試。

原因在於，你從未真正內化這套架構背後的邏輯。

如果第 1 步從未真正完成，就會出現認知投降。

即使驗證系統已透過長期運行證明其可靠性，你仍會因習慣而手動複查每一項輸出。

這種行為看似謹慎，實則抵消了建構系統的全部意義。

如果跳過第 10 步，沒有為迴圈設定真正的停止條件，就可能出現 Token 消耗和呼叫成本的失控。

你通常不會在系統開始失控的第一时间意識到問題，而是直到最終賬單出現，才發現循環已經進行了大量無效調用。

上述所有成本均可避免。

避免它們的方法，始終是同一種紀律：

按順序建構，不要跳過那些看起來不夠精彩的步驟。

真正發揮作用的，往往正是那些最枯燥的部分：

• Clear completion definition;
• Reliable stop conditions;
• Verifiable objective evidence;
• Independent review mechanism.

相比之下，那些聽起來更有吸引力的部分——巧妙的提示詞、複雜的系統架構圖——遠沒有人們想像中那麼重要。

真正決定系統質量的，是你所構建的系統是否知道：

• 什麼時候自己是正確的；
• 什麼時候自己是錯誤的；
• 什麼時候必須停止。

This is the entire difference between a prompt operator and a system designer.

區別不在於誰更聰明，也不在於誰能寫出更華麗的提示詞。

真正的區別，在於你是否有足夠的紀律，認真構建那些枯燥、容易被跳過，卻真正決定系統可靠性的部分。