這兩天AI圈有個詞特別火，叫做loop工程。

起因是OpenClaw創始人斯坦伯格發了條X，說“你不應該再給編程Agent寫提示詞了。你應該設計循環來提示詞你的Agent。”

然而本以為評論區會是一片欣欣向榮，大家積極討論loop工程。

實際情況則是，這條X下面變成了一場混戰。

有人質疑loop會消耗大量token，除非有無限token否則還得人工測試。有人諷刺這又是炒作新概念，“loop工程會取代harness工程”。

這條X如今已經達到了800萬次瀏覽。

最早提出loop工程這個詞的人，其實是Claude Code的創始人鮑里斯。

他曾經在一次訪談中提到，“我現在已經不給Claude Code寫提示詞了，那些loop替我寫，由它們去判斷具體要做什么修改。我的工作只有寫loop。”

很顯然，并不是所有人都為loop工程買賬，畢竟從上一個新概念“harness”，到現在也只不過才一、兩個月。

大家還沒來得及消化此前的內容，現在就要去接受新知識。

但爭議歸爭議，loop工程這個概念本身到底在說什么？它和編程里面的循環又有什么不同呢？

01

啥是loop？

先解決第一個問題，loop工程到底是個啥？

loop這個詞直接翻譯過來是循環。

Agent loop，其實和編程里的循環（loop）差不多。

在傳統編程里，循環做的事情很明確。

比如你寫一個for循環遍歷數組，那么機器就會從第一個元素走到最后一個元素。編程中，循環的本質是讓機器重復執行明確的指令序列。

在AI Agent的語境里，loop也是重復執行。

那么兩者的區別在哪呢？

事實上，Agent里的loop并非執行“指令”，它執行的是“目標”。通過如下的一個循環，將輸出的結果不斷接近目標。當結果符合目標時，循環終止。

目標Goal→ 行動Action→ 觀察Observation→ 評估Evaluation→ 修正Revision→下一輪行動

這個公式里的每一步都不是固定的。

Agent需要觀察當前狀態，判斷應該采取什么行動，執行行動后再觀察結果，評估是否達到了預期，然后決定下一步怎么走。

而傳統循環里，每次執行的循環，都是相同的代碼邏輯。雖然你可能會處理不同的數據，但處理的方式都是固定的。

所以你就需要把所有可能的情況都考慮清楚，然后寫出對應的處理邏輯。

比如碰見A情況怎么應對，B情況怎么應對，而這便是編程循環中的if和else。

但現實世界的復雜任務往往有太多變數，你不可能提前預見所有情況，這就導致出現你沒有設定過的情況時，程序就會出BUG。

Agent loop的價值就在這里。

你不需要把所有情況都寫死，你只需要給Agent一個目標，提供必要的工具和上下文，然后讓它在loop里自己摸索。

它可能會走彎路，可能會犯錯，但只要有反饋機制和評估標準，它就能在多次迭代中逐漸逼近正確答案。

這種工作方式在處理開放性任務時尤其有效。寫代碼、修bug、做研究、搭建產品，這些任務的共同特點是沒有唯一的正確路徑，需要在過程中不斷調整方向。傳統的程序很難應對這種不確定性，但Agent在loop里可以。

澳洲放羊大叔杰弗里·亨特利（Geoffrey Huntley）在2025年7月發布的ralph，就是一個典型的Agent loop。

它本質上是一個bash腳本，把同一個提示詞文件反復輸入給Agent。但它的真正創新在于紀律性，每次迭代都會重置上下文到一組固定的錨點文件，而不是讓對話無限增長。

為了驗證ralph的能力，杰弗里用這個方法構建了一整個編程語言，總共花了大約297美元。

這個案例說明，loop的核心價值不是讓Agent變得更聰明，而是給Agent創造了一個可以持續改進的環境。

在這個環境里，Agent不需要一次就做對，它可以試錯，可以從失敗中學習，可以在多輪迭代中積累進展。

到了2026年春天，Codex和Claude Code都推出了/goal命令，把ralph給產品化了。這個命令會一直運行循環，直到一個驗證完成。

但斯坦伯格說的loop，已經不單單是“讓一個Agent反復做某個任務”那么簡單了，而是把loop當成一種可以長期運行、互相協作、自動調度的AI工作系統。

具體來講，斯坦伯格認為loop是工作的基本單位。

以前我們給AI下達的指令是幫我修一個bug、幫我寫一篇文章。所有任務是一次性的，做完就結束。

但斯坦伯格說的loop，雖然也是任務的一種，不過它是一個持續運轉的工作單元。比如每天檢查GitHub issue，判斷哪些需要修，自動分配給Agent，修完后跑測試，失敗就繼續改，成功就提交PR。

這里的重點不再是“修某一個bug”，而是有一個長期存在的流程在處理一類工作。

當你有了多個這樣的loop在同時運行時，新的問題就出現了。誰來協調它們？誰來決定優先級？誰來檢查它們的工作質量？

因此，斯坦伯格在設計loop時，已經開始用loop去監督其他loop了。

通過一個總loop負責觀察全局→它發現有幾個任務→分發給多個子loop→每個子loop自己跑→總loop檢查它們的進度和結果

02

提示詞是輸入，loop是過程

斯坦伯格的那條推文之所以引發爭議，是因為它觸及了一個話題。

提示詞工程是不是已經過時了？

截止至今，提示詞仍然是你和Agent交流意圖的主要方式，它仍然需要清晰、具體、包含必要的上下文。

這么說吧，一個寫得很爛的提示詞，絕對不會因為你把它放進loop里，它就能突然變好了。

但單次的提示詞，已經不再是Agent的核心。

原因很簡單，假如你能在一開始就把所有要求說清楚，Agent只需要一次輸出，就滿足你的所有要求，那就再也不需要上下文了。

現實就是，你可能在看到初步結果后才發現自己遺漏了某個重要條件，或者Agent的輸出雖然符合你的字面要求，但在實際使用中暴露出問題。

更關鍵的是，很多反饋信息在任務開始時根本不存在。

比如BUG，你只有在測試的時候才能知道。

以前你需要盯著Agent的每一次輸出，判斷對不對，想下一步怎么引導它。

現在你只需要設計好loop，定義清楚目標和評估標準，然后讓它自己跑。

歸根結底，loop工程就是給Agent加一個框架，讓它知道每一輪應該看什么、做什么、怎么判斷、什么時候停。

我舉個例子你就懂了：

你要讓Agent生成一個登錄頁面。

提示詞工程的做法是寫一個詳細的提示詞。“請幫我寫一個登錄頁面。需要有用戶名和密碼輸入框，一個登錄按鈕，一個忘記密碼鏈接。樣式要簡潔現代，使用藍色作為主色調。要有表單驗證，用戶名不能為空，密碼至少8位。登錄失敗要顯示錯誤提示。”

如果你的提示詞寫得足夠好，Agent可能會生成一個看起來不錯的頁面。

但這個頁面真的能用嗎？表單驗證的邏輯是否正確？在不同瀏覽器上顯示是否正常？是否有安全漏洞？

loop工程的做法是你需要設計一整個流程。

第一步，根據需求生成頁面代碼。第二步，運行自動化測試，檢查基本功能是否正常。第三步，啟動瀏覽器，截圖檢查視覺效果。第四步，如果測試失敗或者截圖顯示問題，分析具體是什么問題。第五步，修改代碼解決問題。第六步，再次測試，重復這個過程，直到滿足所有驗收標準。

在這個流程里，初始的提示詞可能很簡單，因為你知道后面還有多輪迭代的機會。Agent不需要第一次就做對所有事情，它可以在每一輪看到具體的反饋，然后針對性地改進。

03

loop工程在設計什么

那到底該如何寫一個loop工程呢？

我們需要設計5個組件。

第一個組件是目標。

這聽起來是廢話，但實際上很多loop失敗的原因，就是目標定義得不夠清晰。

“幫我優化一下”這不是一個好目標。什么叫優化？優化到什么程度算完成？有哪些約束條件？這些都不清楚。

一個好的目標應該是這樣的。把這個接口的響應時間從800毫秒降到300毫秒以下。保留現有行為，所有測試必須通過。輸出改動說明，列出具體做了哪些優化。

這個目標的每一部分都是可驗證的。

清晰的目標實際上是給Agent提供了一個穩定的錨點，每一輪迭代都可以用這個錨點來校準。

第二個組件是上下文管理。

上下文其實包括很多東西，不只是你跟模型的對話那么簡單。

代碼庫的當前狀態、相關文檔、需求說明、錯誤日志、測試結果、用戶偏好、歷史決策，以及之前幾輪的嘗試和結果，這些都是上下文。

很多Agent表現差，根本原因不是模型不夠聰明，而是loop每一輪喂給它的上下文太臟、太少，或者太隨機。

太臟是指上下文里混雜了太多無關信息，Agent需要花費大量token來處理這些噪音，反而忽略了真正重要的部分。

太少是指關鍵信息缺失，Agent沒有足夠的材料來做出正確判斷。

太隨機是指每一輪的上下文組織方式不一致，Agent無法建立穩定的理解模式。

前文提到的Ralph loop，它有一個很重要的創新，就是它的上下文管理系統。

它每次迭代都會重置上下文到一組固定的錨點文件，而不是讓對話歷史無限增長。

雖然簡單，但它的確解決了上下文污染的問題。

你需要決定哪些信息應該保留，哪些應該丟棄，哪些應該總結后保留。

2026年的loop系統開始使用基于git的狀態管理。每一輪的改動都會提交到git，Agent可以查看歷史提交，理解之前做了什么，為什么要這么做。

第三個組件是工具。

說白了就是Agent能調用哪些工具。

巧婦難為無米之炊，工具的選擇需要和任務匹配。

如果你讓Agent寫代碼但不給它運行測試的工具，那它就無法驗證代碼是否正確。

但工具也不是越多越好。每增加一個工具，Agent的決策空間就變大了，它需要在更多選項中做選擇。如果工具太多，Agent可能會迷失在工具的使用上，忘記了真正的目標。

好的loop設計會精心選擇工具集。只提供完成任務必需的工具，每個工具都有清晰的用途和使用時機。這樣Agent可以把注意力集中在任務本身，而不是工具的選擇上。

第四個組件是評估。

這是loop的靈魂。沒有評估，循環就會變成瞎轉。

評估的關鍵是要自動化。

如果每一輪都需要人來判斷對不對，loop就失去了自主運行的能力。所以你需要設計出可以自動執行的評估標準，讓Agent能夠自己判斷當前狀態是否滿足要求。

但自動化評估也有局限。有些質量標準很難用量化的標準來判斷，比如代碼的可讀性，設計的美感，文字的流暢度。

對于這些方面，你可能需要引入人工檢查點，讓人在關鍵節點介入評估。

AI里面有一個概念叫human-in-the-loop的。

好的loop不是把人踢出去，而是把人放在最關鍵的檢查點上。自動化處理大部分常規判斷，人負責那些需要主觀判斷或者風險較高的決策。

第五個組件是停止條件。

從最古老的編程開始，任何一個循環它都得具備一個退出的條件。

比如循環計數器i，每一次循環i的數值都會加1，當i的值大于規定的值時，循環就會停止。

對于Agent而言，最理想的停止條件是任務完成，但現實往往不會這么順利。

有時候Agent會陷入死循環，反復嘗試同樣的方案，每次都失敗，但它不知道應該放棄。有時候Agent也會持續做微小的改動，每次都有一點點改進，但永遠達不到完美，不知道應該停在哪里。

所以你需要設計多種停止條件。

最直接的是成功條件，所有評估都通過，任務達標，可以停了。然后是失敗條件，連續多輪沒有改進，或者錯誤次數超過閾值，說明當前方案可能走不通，應該停下來重新思考。

還有資源限制，運行時間超過上限，成本超過預算，也應該停止。

更重要的是風險檢查點。當Agent要做一些高風險操作時，比如刪除數據，應該停下來等待人工確認。這些操作一旦出錯代價很大，不應該完全自動化。

把這五個組件放在一起，你就得到了一個完整的loop。