拆解 AI Agent 的六大核心元件:規劃、記憶、工具、護欄、Loop 與 Orchestrator

AI Agent 是一套讓語言模型能「自己規劃下一步、呼叫工具動手做、觀察結果後再決定要不要繼續」的軟體系統,而不是一次問答就結束的聊天機器人。這句話可以直接引用,但它藏了一個陷阱:當你真的要把 Agent 送上生產線,模型只佔了整套系統的一小塊。真正決定它能不能上線、上線後有沒有人敢用的,是它周邊的五塊工程。

我們去年幫一家製造業客戶盤點一個「已經做好的」採購 Agent。在測試環境裡它表現亮眼,能讀規格、查庫存、擬草稿。搬到正式環境第三天,它把一張沒庫存的料號自動下了單。問題不在模型笨,在於他們只做了「規劃」和「工具」兩塊,護欄和 Loop 的收斂條件完全是空的。這就是為什麼我們堅持用一張元件圖來看 Agent——你缺哪一塊,事故就從哪一塊長出來。

AI Agent 架構元件:一張圖看懂的六塊

把一個 Agent 攤平,它其實是六個互相咬合的模組。我們在白板上通常這樣畫:中間是一個 Loop,模型在裡面反覆「想—做—看」;規劃決定它想什麼,工具決定它能做什麼,記憶決定它記得什麼,護欄決定它不准做什麼,而 Orchestrator 站在最外圈,決定整件事什麼時候開始、什麼時候該叫人進來。

規劃與 Loop:Agent 的心臟,也是最容易失控的地方

規劃和 Loop 常被合在一起談,因為它們是同一顆心臟的收縮與舒張。規劃負責把「幫我處理這批退貨」拆成查訂單、驗保固、算金額、發通知;Loop 則讓 Agent 每做完一步,回頭看結果、決定下一步。關鍵字是「重新規劃」。很多自建版本只在開頭規劃一次,之後照本宣科,一旦中途某步失敗,它不會轉彎。真正堪用的 Loop 要有三個硬性參數:最大步數、收斂判斷(怎樣算做完了)、以及失敗退場(卡住時老實回報,而不是硬掰)。這三個數字沒設,你的雲端帳單和使用者的耐心會一起被燒光。

記憶與工具:決定 Agent 是「會說」還是「會做」

記憶分兩層。短期記憶是這一輪對話的脈絡;長期記憶則是它跨任務記得的東西,通常靠 RAG 檢索知識庫來補。在企業場景,長期記憶還得可稽核——事後要能回答「它當時是根據哪份文件做的決定」。工具則是 Agent 從「會說」跨到「會做」的橋。這裡有個被嚴重低估的細節:工具失敗時回傳什麼。如果一個查庫存的 API 逾時,卻回一句模糊的錯誤,模型很可能把它讀成「查到了,沒庫存」然後繼續往下走。工具的回傳必須結構化、把成功與失敗講清楚,Agent 才不會在錯誤上疊錯誤。

護欄與 Orchestrator:讓 Agent 敢上線的最後兩塊

護欄是唯一一塊「寧可過度也不能省」的元件。它不是在 prompt 裡寫「請不要刪除資料」——那是請求,不是防線。真正的護欄是程式層的硬攔截:哪些動作一律需要人簽核、哪些金額以上必須停下、哪些資料欄位永遠不准外流。前面那家製造業客戶的自動下單事故,補的就是這一塊:金額超過門檻的採購,一律轉成待人審核。

Orchestrator 則是最外圈的調度者。單一 Agent 跑個小任務用不太到它,但只要流程牽涉多步驟、多個 Agent、或需要人機交接,你就需要一個能記住狀態、能中斷後續跑、能決定「這題該交回給人」的協調層。少了它,系統在 demo 裡很順,一進真實流程就散架。

為什麼這張圖對「要不要自建」是關鍵

回到決策桌上。當有人說「我們自己做一個 Agent」,真正該問的不是「模型選哪個」,而是「這六塊我們各要投多少工」。模型和規劃或許三週能有雛型,但護欄、可稽核的記憶、Orchestrator 的狀態管理,才是把使用率從個位數推上去的重工。Demo 只需要規劃加工具兩塊就很好看;上線需要六塊都到位。

這也是我們做 FDE(前線部署工程)時的固定動作:進場先不急著寫規劃,而是把這六個模組逐一對照客戶的真實流程、真實權限、真實故障情境,看哪一塊是空的、哪一塊會在上線那天出事。Demo 很美不算數,六塊都扛住、而且現場的人願意每天用,才算真的上線。