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

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

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

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

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

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

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

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

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

一、啥是 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 檢查它們的進度和結果。

二、提示詞是輸入，loop 是過程

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

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

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

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

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

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

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

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

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

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

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

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

我舉個例子你就懂了：

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

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

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

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

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

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

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

三、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。

本文來自微信公眾號：字母 AI，作者：苗正