第 4 章 — AI 代理與工具呼叫
LLM Primer V: Building Real-World LLM Applications 章節走讀的第四篇。這一章把代理當成一個「對著工具跑迴圈的語言模型」處理 — 工具 schema、記憶層、多代理接線都得先工程好,那個迴圈才能被信任去做真的事。
這一章為什麼存在
一個「文字進、文字出」的無狀態模型是計算機。生產級的工作要把它變成一個追著目標、跨多步走的行動者 — 呼叫這個工具、再呼叫那個、決定要把哪個結果摘要給使用者、任務完成就停下來。這個動作在圖上看起來簡單,實際上並不簡單。代理會遊蕩、會兜圈、會叫錯工具、會編工具吃不下的參數、會忘記自己已經拿到的東西、會做超出授權的事。第 4 章講的是把那個迴圈維持得可讀、被約束的工程 — schema、記憶紀律,以及把「看起來像樣的 demo」變成「生產級行動者」的多代理結構。
4.1 代理架構是組合、不是選擇
基底迴圈是 ReAct:對現況推理、動作是呼叫工具、觀察結果、然後重複直到目標達成或步數預算用完。生產系統會在基底之上組合三種擴增,而不是二選一或三選一。原生 function calling — 供應商在解碼時把工具參數約束在 JSON Schema 內 — 把 I/O 契約收緊,迴圈就不用再從畸形呼叫救回來。Plan-and-Execute 風格的顯式計畫給長跨度任務先擠出一個計畫,只有世界變了才重跑 planner。工作流編排把任務裡已知的轉換寫成一張圖,只把階段內的決策留給模型,這是大多數企業部署會收斂到的形狀,因為它把「已知的」跟「需要判斷的」分開。反思迴圈、跨成本分層艦隊的多模型路由、專家型子代理都以進一步擴增的形式坐在旁邊。
4.2 工具呼叫機制 — schema 就是契約
每一個工具都有 schema,而 schema 就是迴圈對模型強制的那份契約。屬性級的描述是給模型看的文件、不是給人類讀者看的;enum 在領域允許的地方把參數空間封閉;idempotency key 讓迴圈能安全重試同一次工具呼叫、不會把效果乘兩倍;有結構的可重試錯誤讓模型能乾淨地救回來,而不是靠猜。工具要小 — 一個工具做一件明確的事 — 因為一個掛著十個可選旗標的胖工具,就是模型會叫錯的工具。ask_user 這種工具要明白列在目錄裡,讓代理有合法的方式升級模糊性,而不是把參數編出來。並行只在工具聲明獨立時才安全;迴圈把「聲明獨立」的工具當可並行、其他一律嚴格序列。每一起「代理做了錯事」的真實生產事故,追到根源都是某個工具的 schema 沒說清楚它的參數是什麼意思。
4.3 三層記憶:短期、長期、語意
代理需要記憶,因為一個任務很少能塞在一回合裡。短期記憶是一個滑窗,蓋在最近對話上,配上「滑不掉」的釘住訊息 — system prompt、當前目標、正在跑的計畫 — 以及對滑出窗外那段對話的定期摘要。長期記憶是一個向量儲存,裡面裝的是「經確認才寫入」的精煉事實,而不是每一次觀察都寫,並且在迴圈的多個點去取用,而不是只在開頭。語意記憶是一張三元組知識圖,給那些需要結構化組合而不是相似度的查詢用 — 「誰向誰報告」、「哪些商品屬於哪一類」這種向量儲存會壓平的關係。三層是分開儲存的,因為它們是分開用的,而紀律是把讀跟寫路由到對的那一層,不要把所有東西塞進一個嵌入索引裡。
第 4 章接下來會怎麼走
代理跟 RAG 都會產出隨機性的 trace。使用者抱怨、日誌上有一百個跨三個工具、八次模型呼叫的 span,而團隊得決定失敗是檢索回歸、prompt 漂移、工具 schema 有問題、還是代理在對一個壞掉的下游系統做出正確選擇。這個問題沒辦法在沒有「把 trace 變成可量測 pass/fail 訊號」的紀律下回答。第 5 章就是那個紀律 — LLM-as-judge、RAG Triad、代理的軌跡測試,以及那個把生產環境的 trace 餵回下一輪發布 gate 的評估集的持續迴圈。
下一篇 — 第 5 章:評估 LLM 應用。把「隨機性 trace」變成「團隊能對之發布的 pass/fail 訊號」的評估紀律。
refund_order 跟 ask_user 例子的工具 schema 樣板,以及帶取用與回寫邏輯的三層記憶儲存。第 IV 卷把 MCP 的細節挖深,第 V 卷聚焦在迴圈本身。在 Amazon 查看 LLM Primer V →