昨天談 RAG,把外部知識即時檢索進來餵給模型,讓它「看著資料回答」;但無論資料撈得多準,模型終究只是被動地回答你丟過去的那一題。真正棘手的任務往往不是一問一答就能了結——你要它查天氣、算數字、寫進資料庫、再根據結果決定下一步,這需要模型自己會「規劃、動手、看結果、再修正」。今天講的就是這個升級:工具呼叫(function calling / tool use)讓模型能實際去操作外部函式,ReAct 讓它推理與行動交錯進行,而 agentic loop 把「觀察→思考→行動」串成一個會自我推進的循環。這是從「聊天機器人」走向「會辦事的 agent」的分水嶺。
📖 學
工具呼叫的本質:模型不執行工具,它只是「決定要呼叫」
function calling 最常見的誤解,是以為模型自己跑了那段程式。實際上模型一行程式都沒執行——它做的只是「輸出一段結構化的請求」,說「我想呼叫 get_weather 這個函式,參數是 {city: "台北"}」,然後真正去執行的是你的程式碼。整個流程是一趟接力:你先在 API 呼叫裡附上一份工具清單(每個工具有名稱、用途說明、以及參數的 JSON schema),模型看完使用者問題後,若判斷需要某個工具,就不直接回答,而是回傳一個 tool-call 物件,裡面是工具名與它「填好的」參數;你的程式接到後實際去執行那個函式(打 API、查資料庫、算數),把回傳結果(tool result)再塞回對話送給模型;模型這才拿著真實結果生成最終答案。關鍵在於:模型負責「決策與填參數」,你的執行環境負責「真的動手」,兩者職責分明。理解這一點,才不會把 agent 的能力邊界想錯。
模型怎麼決定呼叫哪個工具、參數怎麼填
模型選工具、填參數,靠的幾乎全是你寫的工具描述(description)和參數 schema——這也是為什麼「工具寫得好不好」直接決定 agent 準不準。模型在生成時,會把每個工具的名稱與說明當成 prompt 的一部分來理解,像讀一份 API 文件一樣判斷「這一題該用哪個工具」。所以描述必須寫清楚這工具「做什麼、什麼時候該用、什麼時候不該用」,語焉不詳的描述會讓模型選錯工具或該用時不用。參數則由 JSON schema 約束:你宣告每個欄位的型別、是否必填、列舉值(enum)、格式,模型就照著把使用者的自然語言拆解、對應、填進正確欄位——把「幫我訂明天下午三點兩個人的位子」解析成 {date, time, party_size}。現代模型多半支援強制結構化輸出(constrained decoding),確保吐出來的一定是合法 JSON,不會是自由文字讓你 parse 到崩潰。Anthropic 有一篇《Writing tools for agents》專門講怎麼把工具寫得讓模型好用,核心就一句:工具介面是給模型讀的文件,要像對待人類工程師的 API 一樣認真設計。
ReAct:推理與行動交錯,才不會盲目亂動
ReAct(Reasoning + Acting)是 2022 年 Yao 等人提出的框架,核心洞見是:讓模型「先想再動、動完再想」,比只想不動或只動不想都強。它把模型的輸出組織成 Thought(推理)→ Action(行動)→ Observation(觀察工具回傳)的循環交錯:模型先寫一段思考「我要回答這題得先知道 X,所以我該查 A」,接著發出行動(呼叫工具),拿到觀察結果後再寫下一段思考「原來 X 是這樣,那我還需要 Y」,再行動……直到它認為資訊夠了才給最終答案。這種交錯之所以有效,是因為 Thought 讓模型能追蹤計畫、處理例外、根據新資訊調整策略;而 Action 讓它不必憑記憶硬掰,能去真實世界取得資料。純推理(chain-of-thought)容易脫離現實地一路推導到錯的結論,純行動則像沒頭蒼蠅亂試工具;ReAct 把兩者綁在一起,推理引導行動、行動修正推理,決策軌跡還變得可讀、可稽核——你能看到 agent「為什麼」這樣做。今天大多數 agent 框架的骨架,都是 ReAct 的變體。
Agentic loop:觀察→思考→行動的循環,與「什麼時候該停」
把 ReAct 的一輪一輪自動接起來,就是 agentic loop——agent 與單次 prompt 最本質的差別。它的骨架是一個 while 迴圈:模型觀察當前狀態(對話歷史、上一步工具結果)→ 思考下一步 → 產生行動(呼叫工具或宣告完成)→ 執行工具、把結果併回上下文 → 回到迴圈開頭。每一圈,模型都拿著「到目前為止累積的所有觀察」重新判斷,直到任務完成。這裡最容易被忽略、卻最關鍵的是停止條件(termination):模型什麼時候該停下來給答案?正常情況是模型主動不再呼叫工具、直接輸出最終回覆就代表它認為做完了。但你不能只靠模型自覺——必須加上硬性護欄:最大迭代次數(跑超過 N 圈就強制中止)、預算/token 上限、逾時、以及偵測重複行動(連續三次呼叫同一工具同一參數就攔下)。少了這些護欄,一個判斷失誤的 agent 會在迴圈裡永遠打轉,或悄悄燒掉你一大筆 API 費用。「會不會自己停」是玩具 demo 和能上線系統的分水嶺。
多工具、記憶與規劃:任務一複雜,協調就是難點
任務一旦需要多個工具、多個步驟,agent 的難題就從「會不會用工具」變成「怎麼協調」。工具一多(搜尋、計算、寫檔、發信、查資料庫十幾個),模型選錯工具的機率就上升,實務上要靠清楚的工具描述、必要時分群或分層(先選類別再選具體工具)、甚至用一個 orchestrator 模型負責拆解任務、把子任務分派給專門的 worker——Anthropic 在《Building Effective Agents》裡把這種 orchestrator-workers 列為處理「複雜度不可預測」任務的關鍵模式。記憶則分兩種:短期記憶就是當前這段對話與工具結果構成的上下文,agent 靠它維持任務狀態;長期記憶則把跨對話該記住的東西(使用者偏好、過往結論)存到外部(常是向量庫,接回昨天講的 RAG),需要時再檢索回來。規劃能力也是分水嶺:強的 agent 會先在腦中列出多步計畫再逐步執行,遇到失敗還能回頭改計畫,而不是走一步算一步。這些協調機制,才是把 agent 從「單一工具的玩具」推向「能完成真實工作流」的地方。
常見失敗模式:無限迴圈、工具幻覺、上下文爆炸
Agent 的失敗模式和 RAG 不一樣,得認得它們才防得住。第一是無限迴圈:agent 卡在某個子目標上反覆呼叫同一組工具、每次都拿到差不多的結果卻不會換策略,原地打轉燒錢——這就是為什麼硬性停止條件與重複偵測是必需品,不是選配。第二是工具幻覺(tool hallucination):模型「發明」一個根本不存在的工具去呼叫,或是幫某個真工具填了它 schema 裡沒有的參數、亂造一個看似合理的參數值;工具寫得含糊、或工具清單太雜時特別容易發生。第三是上下文爆炸:agentic loop 每跑一圈就把新的工具結果堆進上下文,幾十圈下來上下文塞爆,不只成本與延遲飆高,還會觸發昨天提過的「lost in the middle」——關鍵資訊淹沒在中段被模型忽略。緩解手段包括定期摘要壓縮歷史、只保留近幾步的完整結果、把久遠的觀察搬去外部記憶。第四是錯誤放大:早一步填錯參數、拿到錯結果,後面每一步都建立在錯的基礎上,越走越偏。這些不是模型「不夠聰明」的問題,而是系統設計沒把護欄做足。
破除迷思:接個 API 不等於 agent,越自動也不等於越好
關於 agent 有三個要正面拆穿的迷思。其一,「agent 就是接個 API 讓模型呼叫就好」——錯。能呼叫工具只是最低門檻;真正難、也真正決定成敗的是迴圈控制、停止條件、錯誤處理、記憶管理、以及工具介面的設計。少了這些,你得到的是一個會亂燒錢、會卡死、會亂填參數的東西,不是能託付工作的 agent。其二,「越自動、給越多自主權越好」——不對。自主度越高,出錯時的破壞力與不可預測性也越高;Anthropic 的建議反而是能用固定流程(workflow)解決的就別上完全自主的 agent,先追求可控與可預測,把自主權留給「複雜度真的無法預先寫死」的場景。其三,「agent 一定比單次 prompt 準」——常常反而更不準。多一步就多一個出錯環節,錯誤還會在迴圈裡逐步放大;對於一問就能答、不需外部行動的任務,直接一次 prompt 又快、又便宜、又穩,硬套 agent 只是徒增延遲、成本與失敗點。判準很簡單:任務需不需要「取得外部資訊或執行真實動作、且步驟無法事先寫死」——需要,才值得動用 agent。
生態近況:MCP 正在成為 agent 接工具的通用插座
工具呼叫能不能規模化,卡在一個很現實的問題:每接一個新工具或資料源,就得寫一套專屬串接,N 個模型接 M 個工具是 N×M 的整合地獄。Anthropic 在 2024 年底提出的 MCP(Model Context Protocol)就是要解掉這題——它是一個開放標準,像 USB-C 一樣,讓任何 agent 用同一套協定去連任何工具與資料源,把 N×M 變成 N+M。這件事在 2025 到 2026 之間迅速成為產業共識:OpenAI、Google DeepMind、Microsoft 等陸續採用,生態長出上萬個 MCP server,2025 年底 Anthropic 更把 MCP 捐給 Linux 基金會底下新成立的 Agentic AI Foundation,交由社群治理,標誌它從「單一公司的專案」變成產業共用的基礎設施。MCP 官方的 2026 roadmap 把重點放在傳輸的可擴充性、agent 之間的通訊、治理成熟度與企業級就緒——一句話,2025 是證明 agent 能動,2026 是要證明它能在企業規模下到處都能動。對你的實務意義是:未來給 agent 接工具,越來越可能是「接上一個現成的 MCP server」,而不是每次從零手刻串接。
🧠 記
- Function calling 的本質是模型「輸出結構化的呼叫請求並填好參數」,真正執行工具的是你的程式;模型負責決策,執行環境負責動手,結果要再餵回模型才生成最終答案。
- 模型選工具、填參數幾乎全靠工具的 description 與 JSON schema——工具介面是寫給模型讀的文件,寫得好壞直接決定 agent 準不準。
- ReAct 讓 Thought→Action→Observation 交錯循環:推理引導行動、行動修正推理,比純推理或純行動都強,決策軌跡還可讀可稽核。
- Agentic loop 是「觀察→思考→行動」的自動迴圈,與單次 prompt 的本質差別;停止條件(最大迭代、預算上限、重複偵測)是玩具與可上線系統的分水嶺。
- 三大失敗模式:無限迴圈(原地打轉燒錢)、工具幻覺(呼叫不存在的工具或亂填參數)、上下文爆炸(歷史堆爆、成本延遲飆高又 lost in the middle)。
- 三個迷思要破:接個 API 不等於 agent(難在迴圈控制與護欄)、越自動不等於越好(能用固定流程就別全自主)、agent 不必然比單次 prompt 準(多一步多一個錯);需要外部行動且步驟無法寫死,才值得用 agent。
✍️ 實踐
親手跑一遍最小的 tool-use 迴圈,你對 agent 的直覺會完全不同。給自己 40 分鐘:
- 定義一個工具(5 分鐘):選任一支援 function calling 的模型 API,寫一個最簡單的工具,例如
get_time(timezone)或calculate(expression),附上清楚的 description 與 JSON schema。 - 接第一趟呼叫(10 分鐘):問模型一題需要用到該工具的問題(如「現在東京幾點?」),觀察它回傳的不是答案,而是一個 tool-call 物件,看清楚它填了什麼參數。
- 手動執行並餵回(10 分鐘):在你的程式裡真的執行那個函式,把結果作為 tool result 塞回對話再送一次,確認模型這次才給出最終答案——親眼看到「決策」與「執行」是分開的兩趟。
- 包成迴圈加護欄(10 分鐘):把上面兩趟包進一個 while 迴圈,讓模型可以連續呼叫工具,並加上「最多跑 5 圈就強制停」的計數器;故意問一個它答不出來的題,看它會不會亂繞,體會停止條件的重要。
- 記一筆(5 分鐘):寫下這次觀察到的一個失敗徵兆(選錯工具?參數填錯?想無限繞?),這就是你未來設計 agent 時要防的第一個坑。
🔗 延伸學習
- Building Effective AI Agents(Anthropic 工程部落格):Anthropic 談 workflow 與 agent 的區別、以及 orchestrator-workers、evaluator-optimizer 等實用設計模式,並主張「能簡單就別複雜、能不全自主就別全自主」。
- ReAct: Synergizing Reasoning and Acting in Language Models(原始論文):提出 Thought-Action-Observation 交錯範式的原典,理解今天所有 agent 迴圈的思想源頭。
- Writing tools for AI agents(Anthropic 工程部落格):專講怎麼把工具的介面與描述寫得讓模型好用,直接對應「工具寫得好不好決定 agent 準不準」這一點。
- The 2026 MCP Roadmap(Model Context Protocol 官方部落格):MCP 官方 2026 路線圖,看 agent 接工具的通用協定往可擴充性、agent 通訊與企業就緒的方向走。
💬 問 AI
想真正吃透工具呼叫的機制,最好的方式是拿一個具體任務,讓 AI 陪你把整個 agentic loop 推演一遍、順便找出你會踩的坑。把下面的提示詞複製給你常用的 AI,填入你自己的情境:
我想搞懂 AI agent 的工具呼叫(function calling / tool use)機制,請當我的老師。
我的情境:我想做一個能[填入你的任務,例如:查詢多個城市天氣並比較後給出旅遊建議]的 agent。
請依序幫我:
1. 列出這個任務需要哪些工具,並為其中一個工具寫出完整的 description 與 JSON schema,說明你為什麼這樣寫。
2. 用 Thought→Action→Observation 的格式,手動演一遍這個 agent 完成任務的完整 agentic loop,讓我看到每一步它在想什麼、呼叫什麼、拿到什麼。
3. 指出這個設計最可能出現的 3 個失敗模式(如無限迴圈、工具幻覺、上下文爆炸),以及各自該加什麼護欄或停止條件。
4. 最後誠實評估:這個任務「真的需要 agent」嗎?還是用固定流程 workflow 或單次 prompt 更划算?為什麼？