迴圈工程入門

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

如今，越來越多的工程師的夜晚已變得不同。他們寫下一句指令，合上筆記型電腦，第二天早上回來時看到的是拉取請求草稿、分類的問題列表或綠色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（生成真實反饋）。迴圈的反饋僅與產生反饋的工具一樣可靠。能推理但不能執行程式碼的代理只是猜測。

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

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

迴圈工程中的三大難題

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

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

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

構建第一個迴圈

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