循環工程入門

幾個月前，開發者的夜晚往往是這樣的：打開編碼代理，輸入指令，等待，閲讀返回內容，將錯誤粘貼到聊天中，再次等待，稍作調整後重復，直到功能真正生效或到了睡覺時間。代理確實在做實際工作，但人類仍需全程陪同，就像駕駛一輛每三秒就需要扶一下方向盤的汽車。

如今，越來越多的工程師的夜晚已變得不同。他們寫下一句指令，合上筆記本電腦，第二天早上回來時看到的是拉取請求草稿、分類的問題列表或綠色CI構建，以及代理嘗試過程和原因的清晰記錄。沒有人站在旁邊輸入下一個提示。改變的不是模型，而是模型周圍構建的系統。

這個轉變的名稱就是循環工程，它在2026年6月的一週內從小眾術語變成了各大平台熱議的話題。本文介紹該術語的起源、其衍生的研究、循環的構成以及如何構建一個小型循環。

循環工程的實際含義

循環工程是設計提示、檢查、記憶和重新運行AI代理的系統，而不是由人來手動逐輪完成所有工作。工作單位不再是單個提示或單個對話，而是一個循環：模型執行行動、從環境獲取反饋、利用反饋決定下一步行為，並持續進行直至滿足真實的可檢查條件。

這與它所取代的方式形成對比。鏈式操作按固定順序執行：步驟A到B到C，各步驟固定。而循環是動態的：代理可能從A到B，發現B不成功後修改方法，然後才進入C，甚至完全回到A。循環持續直到任務真正完成、觸發停止條件或代理確定無法繼續。這與“問一次、得到答案、複製出來”的工作形態根本不同。

另一個值得思考的框架是“遞歸目標”概念：你定義目的——如“使測試套件通過”或“分類所有開放問題並修復簡單的”——代理自行迭代：檢查代碼、進行更改、運行檢查、讀取結果、決定下一步。技能從寫一句好提示轉變為設計一個值得信賴並可以離開的循環。

術語幾乎一夜之間成型

時間線是故事的一部分。2026年6月7日，開發者Peter Steinberger（OpenClaw代理項目）發佈推文稱相關技能已經改變：不應再對編碼代理進行提示，而應設計代理為你提示的循環。該推文數天內獲得超過650萬次瀏覽，並主導了接下來一週的代理相關對話。

第二天，谷歌工程師兼作者Addy Osmani發表了題為“循環工程”的文章，將Steinberger的論斷具體化為結構：自動化、工作樹、技能、連接器和子代理，以及第六個基礎組件——外部記憶。這篇文章將病毒式觀點轉化為可供他人構建和討論的詞彙。

不僅是外部人士如此主張。Anthropic Claude Code負責人Boris Cherny引用Osmani的話説：“我不再提示Claude了。我運行循環來提示Claude，並決定下一步做什麼。我的工作是編寫循環。”當最常用的編碼代理構建者表示他不再直接提示代理時，這個想法顯然已超越邊緣觀點。

時間線合理：到2026年中，編碼代理已足夠優秀，能夠長時間無人值守運行，自行從錯誤中恢復，而無需每兩三步就修正。當單個代理運行可長達一小時並觸及數十個文件時，瓶頸不再是提示的精確性，而是你構建的循環是否能在整個小時（包括無人監督的部分）保持代理高效、受控並指向正確目標。

所處位置：提示、上下文、框架、循環

循環工程並非憑空出現，它是層層遞進的最新一層，每一層包裹而非取代前一層。

提示工程最先出現，約2022-2024年，重點是措辭：為模型分配角色、分解任務、提供示例、要求逐步推理。它優化表達，天花板有限。

上下文工程隨之而來，約2025年，焦點從詞語本身轉向模型響應時所見的一切：對話歷史、檢索文檔、工具輸出等。Shopify的Tobi Lütke在2025年中給出了一個定義：提供任務可能被模型解決所需的所有上下文。Anthropic在2025年9月將其形式化為在推理過程中策劃和維護最佳可用令牌集。提示工程成為上下文工程的一個組成部分。

框架工程於2026年初出現，代理在真實生產環境中開始進行更長時間、更自主的多步驟工作。框架是代理的完整環境——腳手架、工具、約束和捕獲錯誤的反饋循環。它使代理可靠而非僅僅有能力，幷包含前兩層：框架包含上下文，上下文包含提示。

循環工程位於三者之上。框架工程關注代理所需的環境，而循環工程關注更具體的問題：什麼循環使代理朝着目標工作，循環何時停止？這些層次沒有取代之前的層次。你仍需編寫提示、策劃上下文、構建框架。循環工程是將所有這些付諸行動並賦予節奏的部分。

術語背後的研究

循環工程容易被看作2026年6月一週內發明的事物，但其機制已有近五年曆史，瞭解其譜系有助於真正理解而非重複趨勢文章。

直接祖先是ReAct模式（Reason加Act），2022年由Yao等人提出。核心思想是推理步驟與行動步驟交錯：模型思考、行動、觀察結果、再次思考、再次行動。這種交錯——推理、行動、觀察、重複——是幾乎所有現代編碼代理仍在運行的基本循環。

一年後，2023年Shinn等人的Reflexion引入了記憶和自我批評。Reflexion代理運行三個不同角色：Actor進行工作，Evaluator對結果評分，Self-Reflection將口頭經驗寫入情景記憶，代理在下次嘗試時讀取。這是循環在會話中可見改善的機制，無需重新訓練模型。

Anthropic在2024年12月的《構建有效代理》指南中提到了另外兩種模式：評估者-優化者模式，一個模型生成候選方案，另一個模型對照標準檢查並反饋，直至通過；協調者-工作者模式，中央模型動態將大任務拆分為小任務，每個任務分配獨立上下文窗口的工作者，然後合併結果。這些正是Osmani文章中“子代理”和“工作樹”的形式化版本。

回顧這些研究的目的是説明“循環工程”是一個產品名稱和集合性短語，而研究方向自2022年以來一直在積累成果。2026年6月的事件沒有發明循環，而是給了普通開發者一個理由和詞彙去有意識地構建循環。

循環的解剖結構

去掉包裝後，一個真正可靠的循環通常具有相同的幾個組件。

它需要一個具有可測試終止條件的目標。“讓應用更好”使代理無法檢查，要麼永遠運行，要麼任意停止。“讓認證模塊的所有測試通過”是可機械檢查的，這就是關鍵區別。

它需要一套與實際環境交互的工具：代碼執行（查看是否運行）、文件系統訪問（讀寫）、終端（命令）、測試運行器和linter（生成真實反饋）。循環的反饋僅與產生反饋的工具一樣可靠。能推理但不能運行代碼的代理只是猜測。

它需要上下文管理。每次迭代都會增加記錄——代碼、錯誤、決策——而上下文窗口大小固定。若不管理，長循環要麼超出窗口，要麼更嚴重的是，隨着記錄增長，注意力變得不集中，這就是所謂的上下文腐化。

它需要明確的終止和升級邏輯：真實成功條件、真實失敗條件（最大迭代次數、令牌或時間預算、重複相同錯誤無進展）以及定義好的路徑。

循環工程中的三大難題

上下文管理：循環在適當位置保留定義、目標和初始事實，同時過濾掉過時信息。常見失敗是上下文增長到代理關注無關細節而忽略真正重要的事情。一種常見解決方法是摘要步驟，在每次迭代後壓縮最相關的信息。

終止：循環何時停止？許多循環因終止條件模糊而永遠運行，或因過度保守而提前停止。明確的可檢查條件是唯一可靠的方法。當循環無法成功時，升級和責任轉移是必要的。

驗證：代理認為完成與實際情況是否完成之間存在差距。最有效的驗證是工具化的：實際運行測試、檢查語法、驗證文件狀態。人類複審在關鍵點仍然重要，但應儘可能機械化和檢查化，以最小化依賴。

構建第一個循環

本文以簡單偽代碼示例結束（省略）。理解循環工程意味着從“問一次”的心態轉向設計循環。技能從編寫提示轉變為設計值得信賴的循環，而這是一項完全不同的技能。