Loop Engineering 讓 Agent 做完事

我把 Loop Engineering 拆成一套能直接拿去用的 Agent 完成任務模板。

我前陣子一直在折騰 Agent 工作流，心裡憋著一股火。Prompt 寫得挺像樣，工具也接上了，甚至上下文我都餵得很講究，可結果還是老樣子：它會開始做，也會很熱情地回報進展，但一到真正複雜的任務，就開始飄。要嘛第一輪輸出看著對，第二輪就把自己帶溝裡；要嘛它知道「該做什麼」，卻不知道「做到什麼程度算結束」。最煩的是，它還特別會裝作已經完成了。你讓它修一個專案，它給你一堆看起來很像回事的中間產物，最後留下半成品，像是把「努力」當成交付。

我後來才意識到，問題不只是 Prompt，也不只是 Context。Prompt 解決的是「怎麼說」，Context Engineering 解決的是「該知道什麼」，但真正讓長任務落地的，是循環本身：執行、檢查、修正、再執行。也就是這篇知乎文章裡講的 Loop Engineering。原文把它和 Prompt Engineering、Context Engineering 放在一條線上講，我覺得這個拆法挺對味。因為很多人現在卡住的，不是不會讓 AI 開始幹活，而是不會讓它把活做完。

這篇文章的價值，不在於又發明了一個新詞，而在於它把一個很煩但很真實的問題說透了：當任務變複雜，Agent 不能只靠一次性指令，而要靠迭代式執行機制。你得讓它自己看結果、自己發現偏差、自己修正路徑。說白了，Loop Engineering 不是「讓 AI 更聰明」，而是「讓 AI 更像一個會收尾的幹活的人」。

Prompt 只能起跑，不能衝線

但這個階段的侷限性也很明顯：適合相對明確的任務（寫文案、總結文章、提取要點），一旦任務變複雜，Prompt 就不夠用了。

這句話我太熟了。Prompt Engineering 最好用的時候，就是任務邊界很清楚：寫個摘要、改個標題、提煉要點、生成一段程式碼片段。輸入和輸出都比較明確，模型只要照著做，通常不會太離譜。但一旦任務開始有狀態、有依賴、有中間判斷，單次 Prompt 就開始發虛。它沒有辦法天然知道「這一步做完之後，下一步該怎麼接」。

我自己最早踩坑是在做一個文件整理 Agent 的時候。第一輪我給它一個很完整的指令：讀取資料、分類、輸出結構化結果。結果它每次都能給我一個「像樣」的答案，但分類標準總在變，前後不一致，最後你根本沒法把它接進後續流程。那時候我還以為是 Prompt 不夠細，後來發現不是細不細的問題，是一次性指令本來就不適合這種多階段任務。

翻譯一下就是：如果任務需要多步推進，你不能只問「請給我答案」，而要設計「每一步之後怎麼判斷是否繼續」。Prompt 的職責只是啟動，真正決定交付品質的是循環控制。

實操上，我會先把任務拆成幾類，看看哪些是單輪可完成的，哪些必須多輪收斂。單輪任務繼續用 Prompt；多輪任務直接別硬扛，改成循環式流程。你可以先寫出三個最基本的問題：現在完成了嗎？如果沒完成，差在哪？下一輪應該改什麼？

• 適合單輪：摘要、改寫、資訊提取、固定格式生成。
• 適合循環：程式碼修復、研究歸納、複雜規劃、跨檔案編輯、長任務執行。

Context Engineering 負責餵對資訊，但還不夠

當任務複雜之後，AI 需要知道的更多。它要看的是專案背景、程式碼結構、目標指令、歷史決策、團隊規範……把哪些資訊放進模型上下文裡，是這個階段要解決的問題。

這段其實講的是我最認可的一層：上下文不是越多越好，而是越對越好。很多人一上來就把所有材料塞給模型，結果模型看得很累，輸出也很散。Context Engineering 的關鍵不是「填滿視窗」，而是把模型做判斷真正需要的資訊放進去。專案背景、歷史決策、程式碼結構、團隊規範，這些東西不是裝飾品，它們決定模型會不會在錯誤的軌道上越跑越遠。

我在做程式碼審查助手時就吃過這個虧。最開始我只給它 diff，讓它評審。結果它的建議很像一個剛進專案的人，語氣很認真，判斷很自信，但經常忽略倉庫裡已有的約定。後來我把目錄結構、相關模組的歷史改動、lint 規則、測試約束一起餵進去，它的建議才開始像「真在這個專案裡幹過活」。

但這裡有個坑：Context Engineering 只能解決「做對」，不能保證「做完」。你給它更好的背景，它更容易判斷方向；可如果任務本身需要反覆試錯，單次上下文再漂亮也沒用。模型還是會卡在中途，或者在某個局部最優裡停住。

翻譯一下就是：上下文負責減少誤判，循環負責推動收斂。前者讓它少走歪路，後者讓它別半路停工。兩者不是替代關係，是配合關係。

實操上，我建議把上下文分成三層來準備。第一層是任務目標，第二層是目前狀態，第三層是約束和歷史。別把所有資料平鋪進去，最好按「決策優先級」組織。模型先看目標，再看狀態，最後看約束。這樣它在每輪循環裡都能快速定位自己現在在哪。

• 目標：最終要交付什麼。
• 狀態：目前已經完成了什麼。
• 約束：不能違反什麼規則。

Loop Engineering 的核心不是循環，是收斂

Context Engineering 讓 AI「做對」，Loop Engineering 解決的是「做完成」。

這句是整篇文章最值錢的地方。因為「循環」這個詞很容易讓人理解偏了，覺得就是多跑幾輪而已。不是。Loop Engineering 真正關注的不是「多跑」，而是「怎麼從不確定狀態逐步逼近完成態」。如果沒有收斂機制，循環只會變成重複勞動；如果有收斂機制，每一輪都會減少不確定性。

我見過太多 Agent 流程死在「繼續執行」這一步。模型每輪都在產出，但沒人定義什麼叫進步。於是它會在同一個錯誤方向上越修越遠，或者因為局部結果看起來不錯，就誤以為全局已經完成。這個時候你再給它更長的上下文，也沒用。因為問題不是資訊不夠，而是缺少一個明確的停止條件和校驗標準。

翻譯一下就是：Loop 不是讓模型一直幹，而是讓每一輪都帶著檢查點。你得規定，輸出必須經過驗證，驗證不過就回滾或修正，驗證通過才進入下一步。沒有這個機制，所謂「Agent」很容易退化成「自動復讀機」。

實操上，我會給每個循環加三個固定動作：執行、檢查、修正。執行負責產生結果，檢查負責判斷結果是否達標，修正負責針對偏差重新嘗試。你可以把檢查寫成規則，也可以寫成另一輪模型判斷，但一定要有明確標準。別讓模型自己宣布自己完成了，這事我已經被坑過太多次了。

如果你做的是程式碼類任務，我建議檢查至少包含三項：語法是否正確、測試是否通過、結果是否符合目標。如果你做的是研究類任務，檢查至少包含：資訊來源是否可靠、結論是否和材料一致、有沒有遺漏關鍵反例。

失敗後修改，比一把梭更像真實工作流

Agent 處理長任務時，需要反覆執行、自行檢查成果、失敗後修改、試錯了累積經驗。

這句話聽起來很樸素，但它其實點出了長任務最真實的樣子。現實裡的工作從來不是「一次寫對」。你寫程式會報錯，改文件會漏段落，做方案會被打回，整理資料會發現欄位不一致。Agent 如果想真的像一個能幹活的系統，就不能只會生成，還得會失敗、會修正、會記住問題。

我自己最有感的是做自動化測試修復的時候。第一輪模型經常會給出一個看起來合理的補丁，但跑完測試還是掛。以前我會很煩，覺得它沒理解問題。後來我改成讓它先看失敗日誌，再定位失敗點，再提出修復方案，最後才動手改程式碼。效果立刻不一樣了。因為它不是在空中猜，而是在錯誤資訊裡迭代。

翻譯一下就是：失敗不是流程外的意外，而是流程的一部分。你要把失敗當成下一輪輸入，而不是當成流程結束。只要失敗資訊能進入下一輪，Agent 就會越來越接近正確答案。

實操上，我會把失敗類型分門別類。比如語法錯誤、依賴錯誤、邏輯錯誤、格式錯誤、目標偏差。不同失敗對應不同修正策略。這樣 Agent 不會每次都從頭亂試，而是能針對性地調整。

• 語法錯：先修最小可執行版本。
• 邏輯錯：回看目標和約束。
• 格式錯：強化輸出模板。
• 目標偏差：重新注入任務定義。

別讓 Agent 自己猜完成標準

資訊給少了，AI 缺少判斷依據；資訊給錯了，它可能在錯誤的方向上越走越遠；資訊給多了，它又抓不住重點。

這段話其實也能拿來解釋為什麼很多 Agent 總是「差一點」。不是它不會做，而是它不知道什麼叫「做到位」。完成標準如果不清楚，模型就會自己發明標準，而它發明出來的標準通常不可靠。它會偏愛看起來完整、語言漂亮、結構工整的結果，但未必真能交付。

我以前寫過一個內容生成流程，最開始只要求「輸出一篇完整文章」。結果模型每次都能交，但總有一種「已經寫完了但沒說到點上」的感覺。後來我把完成標準拆成了幾個可驗證項：是否包含目標主題、是否覆蓋核心觀點、是否提供可執行步驟、是否引用了指定來源。加上這些後，結果立刻穩定很多。

翻譯一下就是：完成標準要顯式化，而且最好是可檢查的。不要只寫「請認真完成」，這種話對模型沒有約束力。你得告訴它，什麼算完成，什麼算未完成，什麼情況要繼續循環。

實操上，我會建議每個 Agent 任務都配一個 checklist。這個 checklist 不需要長，但必須具體。比如「包含 3 個步驟」「引用 2 個來源」「輸出可直接複製的模板」「測試通過後再結束」。只要標準能被檢查，循環就有了方向。

我特別建議把「完成」和「滿意」分開。模型可能覺得自己已經很努力了，但你的標準不是努力，是交付。別心軟，交付標準要硬一點，不然流程會一直拖。

把循環寫成流程，不要寫成願望

如果只看概念，Loop Engineering 很容易被講成一句很空的話：讓 AI 反覆做、反覆改、直到完成。可真正落地時，你需要的是流程，而不是願望。流程意味著每一步都有輸入、輸出、判斷、轉移條件。沒有這些，循環只是一個漂亮的口號。

我現在更願意把它理解成四個固定件：目標、狀態、動作、判定。目標決定方向，狀態告訴你現在在哪，動作負責推進，判定決定要不要繼續。只要這四個件齊了，Agent 才能從「會做」變成「做完」。

這也是我覺得這篇知乎文章有用的地方。它沒有把 Loop Engineering 說成什麼神秘能力，而是把它放回工程問題裡：怎麼組織一套能反覆執行、能自我修正、能最終收斂的機制。說白了，這就是把「聰明」變成「可交付」。

實操上，你可以先從一個最小閉環開始，不要一上來就搞複雜架構。先做一個「生成-檢查-修正」的三段式流程，跑通之後再加記憶、加工具、加多輪分支。很多人失敗不是因為想得不夠大，而是因為一開始就把系統做得太花，最後誰也不知道哪裡出了問題。

你可以直接拿去用的模板

下面這個模板我建議你直接複製，然後按自己的任務改。它的重點不是文風，而是結構：目標、上下文、執行、檢查、修正、停止條件，全都放進去。你可以把它用在程式碼 Agent、研究 Agent、寫作 Agent，甚至是內部自動化流程裡。

# Loop Engineering Agent Template

## 任務目標
你要完成的最終結果是：
- [寫清楚最終交付物]

## 當前上下文
你現在已知的資訊包括：
- 專案背景：
- 當前狀態：
- 相關檔案/資料：
- 約束條件：
- 歷史決策：

## 執行規則
1. 先閱讀任務目標和上下文。
2. 制定當前輪次的最小可執行計畫。
3. 執行計畫，輸出結果。
4. 自檢結果是否滿足完成標準。
5. 如果未滿足，說明失敗原因並修正。
6. 重複 3-5，直到滿足停止條件。

## 完成標準
只有同時滿足以下條件，才算完成：
- [條件 1]
- [條件 2]
- [條件 3]

## 失敗分類與修正策略
- 如果是格式錯誤：修正輸出結構。
- 如果是邏輯錯誤：回到目標和約束重新判斷。
- 如果是資訊不足：請求補充上下文或暫停執行。
- 如果是測試失敗：根據失敗日誌定位問題並重試。

## 每輪輸出格式
### 當前輪次
- 輪次編號：
- 當前動作：
- 產出結果：
- 自檢結論：
- 是否繼續：是 / 否
- 下一步計畫：

## 停止條件
滿足以下任一條件時停止：
- 所有完成標準通過。
- 連續 [N] 輪沒有實質進展。
- 缺少關鍵上下文，無法繼續。
- 出現不可恢復錯誤。

## 最終輸出
請輸出：
1. 最終結果
2. 完成情況說明
3. 仍然存在的風險或未解決問題

我建議你在這個模板外面再加一層「檢查器」。如果是程式碼任務，就讓檢查器跑測試；如果是寫作任務，就讓檢查器查結構和事實；如果是研究任務，就讓檢查器核對引用和結論。這樣循環才不會只停留在「模型自評」。

另外，別忘了給循環設定上限。無限循環聽起來很優雅，實際上就是浪費 token 和時間。你應該明確告訴系統：最多跑幾輪，沒收斂就停下來，轉人工或轉更強的工具。這個邊界非常重要，不然系統會把「堅持」誤解成「死磕」。

如果你想看原文，可以從這裡開始：知乎文章《全網爆火的 Loop 到底是什麼？》。我這篇是基於原文思路做的工程化拆解，很多表達和模板是我自己整理的，方便你直接拿去改進自己的 Agent 流程。

我再補兩個相關參考：OpenAI Agents 文件、Anthropic Research，還有 LangChain。它們都在不同層面說明了一件事：長任務不是靠一次回答完成的，而是靠可控的循環推進。