什麼是 Agent Loop?拆解感知-規劃-行動-觀察的代理循環

Agent Loop(代理循環)是一個 AI agent 反覆執行「感知環境、規劃下一步、採取行動、觀察結果」四個環節的迴圈,直到任務完成或觸發停止條件——它是把「單次 LLM 呼叫」升級成「能自主完成多步驟任務」的核心引擎。

這句話寫在投影片上很漂亮。真正麻煩的是,這四個字每一個都會在生產環境出事。

我們去年接一個製造業客戶的採購 agent,要它讀信、比對報價單、更新 ERP。Demo 那天跑了三筆,全對,主管當場拍板。上線第九天它把一張單價欄位空白的報價,當成「單價為零」寫進系統,自動核准了一筆金額異常的採購。沒有人設計它這樣做,它只是忠實地跑完了那個 loop。

Agent Loop 是什麼:拆解四個環節

要理解 Agent Loop 是什麼,先把「一次問答」跟「一個循環」分開。ChatGPT 你問一句它答一句,那是單次推論。Agent 不一樣,它要在沒有人逐步下指令的情況下,自己走完好幾步,所以它需要一個會轉的輪子:

感知(Perceive)——把外部世界的狀態餵進模型。可能是使用者的指令、資料庫查詢結果、上一步工具回傳的內容,或一份 PDF。

規劃(Plan)——模型根據當前狀態,決定下一步要做什麼、呼叫哪個工具、帶什麼參數。

行動(Act)——真的去執行:呼叫 API、寫資料庫、發信、跑一段程式碼。

觀察(Observe)——拿到行動的結果,判斷任務完成了沒。沒完成,就把新結果當作新的「感知」,回到第一步再轉一圈。

輪子轉得順,agent 就顯得聰明。問題是,每個環節在真實環境裡都有各自崩的方式。

環節	它負責什麼	上線最常出的錯
感知	把世界狀態轉成模型看得懂的輸入	髒資料被當成有效訊號(空欄位=0)、context 塞爆導致關鍵資訊被截斷
規劃	決定下一步做什麼	選錯工具、參數幻覺、在兩個步驟間反覆橫跳的死迴圈
行動	真的去改動外部系統	沒有權限邊界,一個錯誤決策就寫進正式庫、扣了真的錢
觀察	判斷成敗、決定要不要繼續	分不清「失敗」和「完成」,要嘛提早收手,要嘛無限空轉燒 token

Demo 環境為什麼看不出這些?因為 Demo 的輸入是乾淨的、路徑是預期的、你在旁邊盯著。生產環境的輸入是歪的、路徑是意外的、而且半夜三點沒人看。感知環節吃到的從來不是投影片上那種整齊的資料;規劃環節面對的分支,遠比你 demo 時試過的多。

真正把 agent 拖垮的,往往不是模型不夠聰明,而是這個 loop 沒有「煞車」跟「儀表板」。它不知道自己第幾圈了,不知道花了多少錢,不知道剛才那個工具其實回傳了錯誤。

我們內部把這件事叫 loop 工程。核心觀念是:模型只是引擎,而引擎需要一整台車——我們稱之為 harness(承載框架)——才能上路。這台車至少要有四樣東西。

一是狀態管理。每一圈的輸入輸出都要被記錄,agent 才能知道自己做過什麼、還剩什麼。沒有狀態,它會重複下同一張單。

二是停止條件。要明確定義「什麼叫完成」「幾圈算超時」「花多少 token 就強制中斷」。前面那個空轉燒錢的案例,就是停止條件沒寫清楚。

三是護欄與人類介入點。凡是會動到錢、動到正式資料、不可逆的行動,一律要求二次確認或人工放行。那筆金額異常的採購,只要在「行動」前加一道「單價為零就攔下來問人」的閘門,就不會發生。

四是可觀測性。每一步的規劃、工具呼叫、回傳結果都要能被記錄和回放。出事之後,你要能打開日誌看到它第七圈在想什麼,而不是對著一個黑盒子聳肩。

這四樣東西,沒有一樣是模型本身給你的,全都要工程師動手包。這也是為什麼我們始終覺得,agent 專案的難點不在選哪個模型,而在有沒有人把這台車的底盤焊好。

我們接案的做法,通常是先派工程師進客戶現場,把真實的髒資料、真實的例外路徑摸過一遍,再回頭設計 loop 的每一道閘門和停止條件。Demo 跑得動不算數,agent 在沒人盯的深夜也不出事、而且真的有人天天在用,才算數。