Agent Loop 工程實作:讓 agent 自我修正而不失控的迴圈設計

上週我們幫一家物流公司排查一個「會自己跑到天亮」的對帳 agent。它負責比對三方運費單據,遇到抓不到的欄位就重試。聽起來很合理。問題是它沒有停損:某天上游 API 回了一個格式怪異的空值,agent 判斷「資料不完整,再試一次」,然後就這樣重試了 2,400 多次,把當月的 token 預算燒掉快一半。沒有人發現,因為它從頭到尾都「看起來在正常工作」。

這就是 agent loop 迴圈設計最容易被忽略的一面。大家都在談怎麼讓 agent 更聰明、更會反思,卻很少人先問:它什麼時候該停下來?

先把迴圈拆開:plan-act-observe-reflect

一個能自我修正的 agent,本質是一個結構化的迴圈,不是一次性的 prompt。我們在生產環境裡實際跑的,是這四個階段的循環:

Plan(規劃):根據當前目標與已知狀態,決定下一步要做什麼。這裡的關鍵是讓 plan 產出「單一、可執行、可驗證」的動作,而不是一次規劃十步。步子邁太大,後面的 observe 就無從對照。

Act(行動):呼叫工具、查資料庫、寫檔案。這一步要包在明確的介面裡,每個工具的輸入輸出都有 schema,失敗時回傳結構化錯誤而不是一段自然語言。

Observe(觀察):把行動的結果餵回去。很多團隊在這裡偷懶,直接把整包 raw response 塞回 context,結果 token 爆炸、模型也抓不到重點。我們的做法是先做一層摘要與正規化,只留下 agent 判斷下一步真正需要的訊號。

Reflect(反思):對照目標,問三個問題——這一步有沒有推進?有沒有出現重複?接下來還值不值得繼續?反思不是每一輪都要動用一次昂貴的模型呼叫,可以用便宜的規則先過濾,只在偵測到異常時才升級到 LLM 判斷。

這個迴圈本身不難寫。難的是,如果只有這四步,它會很樂意永遠跑下去。

讓迴圈不失控的四道閘門

真正決定一個 agent 能不能上生產線的,是控制層。我們把它歸成四類,缺一不可:

最大步數是最粗但最有效的一道保險。任何迴圈都必須有一個硬上限,到了就停,不管它覺得自己「快好了」。這一條就能擋掉前面那個對帳 agent 的災難。

停損條件比步數更聰明。它偵測的是「進展」而非「次數」。我們常用的訊號是:連續幾輪 observe 的結果高度相似、或 agent 反覆呼叫同一個工具卻用幾乎一樣的參數。一旦偵測到,就判定它在打轉,直接中止。判斷「有沒有進展」不需要多花俏——比對前後狀態的雜湊值、或算一下工具呼叫序列的重複率,往往就夠了。

預算上限是財務層的煞車。步數正常、也沒打轉,但如果每一步都在做昂貴的檢索,成本一樣會失控。所以我們會另外掛一個獨立於步數的 token 或金額計數器,觸頂即停。

升級出口是最被低估的一環。前面三道閘門都是「怎麼停」,這一道是「停了之後怎麼辦」。一個成熟的 agent 中止時,不該只丟一句「任務失敗」,而要把完整的 plan-act-observe 軌跡打包交還給人,讓工程師或值班人員三分鐘內看懂它卡在哪。沒有這一步,前面的控制就只是把災難從「燒錢」換成「無聲卡死」。

反思機制的取捨,我們踩過的雷

reflect 這一步最容易做過頭。早期我們讓 agent 每一輪都認真自我批評一次,結果它開始「反思上癮」——花大量步數質疑自己剛做對的事,把簡單任務越做越複雜。後來我們改成分層:預設用規則快速判斷,只有在偵測到重複或錯誤時,才觸發一次深度的 LLM 反思。反思要收斂,不是越多越好。

還有一個容易忽略的點:reflect 的結論必須能反過來修改 plan,否則它就只是空轉的獨白。真正的自我修正,是反思產生的洞察會改變下一輪的規劃輸入——換一個工具、補一個前置查詢、或直接判定此路不通。這個回饋閉環接好了,agent 才算真的會「自我修正」,而不只是自言自語。

說到底,agent loop 迴圈設計的成熟度,不在於它能自主跑多遠,而在於它知道什麼時候該停、停了之後留下多少可追查的線索。這也是我們在幫客戶把 agentic 工作流推上線時,花最多力氣的地方——Demo 裡跑得漂亮的迴圈很多,能在預算內、在出事時安靜交還給人的,才敢真的接到生產流量上。