第 4 章 · 工具呼叫、結構化輸出與多模態：從「聊天」到「程式」

前三章的 AI 只會產生文字。但真正有用的應用，需要它能查資料庫、算數學、寄信、讀圖。這一章是整門課的關鍵橋樑：教 AI 從「會聊天」變成「會做事」。很多課會跳過這章直接講 agent，那會讓你學得很懸空——因為 agent 的本質，就是建立在這一章的「工具呼叫」之上。

💡 這一章你會懂：AI 怎麼「呼叫工具」、怎麼吐出「程式能直接用」的結構化資料、以及它其實早就不只會處理文字了。

Tool Use（工具呼叫）：模型不「執行」，它「請求執行」

第 1 章說過，模型不會算數、不知道今天天氣、碰不到你的資料庫。解法不是硬要它會，而是給它工具、讓它開口要。

這裡先接回第 1 章最核心的一句話：模型從頭到尾只會做一件事——產生文字。所以「工具呼叫」聽起來很神，其實一點都不神奇：模型並沒有突然長出手腳，它做的，依然只是「產生一段文字」——只是這段文字的內容剛好是「我想用哪個工具、帶什麼參數」。真正動手去執行的，是模型外面那層你的程式。

關鍵在於理解這個分工——模型不會、也不能真的去執行任何動作，它只會「產生一個要求」：

sequenceDiagram
    participant U as 使用者
    participant M as 模型
    participant Y as 你的程式
    U->>M: 台北現在天氣如何？
    M->>Y: 我想呼叫 get_weather(城市="台北")
    Y->>Y: 真正去查天氣 API
    Y->>M: 結果：18°C 小雨
    M->>U: 台北現在 18 度、下小雨，記得帶傘。

流程拆解：

1. 你事先告訴模型：「你有一個工具叫 get_weather，需要一個參數 城市」。
2. 使用者問天氣，模型判斷「這題要用工具」，於是回傳一個工具呼叫請求（要用 get_weather、參數是「台北」）。
3. 真正去執行的是你的程式——你去查天氣 API，拿到結果。
4. 你把結果餵回給模型，它再用自然語言回答使用者。

⚠️ 這是整個 AI Agent 世界最重要的觀念之一：權限與安全都在「你的程式」這一層。模型只是「開口要」，要不要真的執行、能不能執行、執行前要不要先問使用者——全是你決定。第 9 章會看到，這一層就是所謂的 harness。

模型是怎麼「決定」要用哪個工具的？

新手常有個誤會，以為模型內部有一套「if 使用者問天氣，就呼叫天氣工具」的規則。其實沒有。它判斷「這題該用哪個工具」的方式，跟它猜下一個字是同一套機制：它看過的訓練資料裡，「使用者問天氣 → 接著出現一段呼叫天氣工具的文字」這種模式出現過無數次，於是當你問天氣，它算出「接下來最該產生的，是一段 get_weather 的呼叫」。

所以有個很實際的推論：工具的 description（說明）寫得好不好，直接決定模型會不會、以及何時會用它。因為模型是靠「讀你寫的說明」來判斷這個工具適合什麼場景的——說明含糊，它就亂用或不用；說明清楚，它才點得準。這其實就是第 2 章「Prompt 工程」的延伸：工具說明也是一種 prompt。

再看「交棒」與「接回」這兩個動作，把機制講透一層：

• 交棒（模型 → 你的程式）：模型產生的工具呼叫，本質上只是一段結構化的文字（通常是一小段 JSON，寫著工具名稱和參數）。你的程式收到後，才根據這段文字，真的去呼叫對應的函式。
• 接回（你的程式 → 模型）：你把執行結果當成一則新訊息，附回對話裡再送給模型。對模型來說，這就像對話又多了一輪；它把這個結果讀進 context（第 3 章的工作記憶），再據此產生給使用者的自然語言回答。

換句話說，模型全程都待在「產生文字 → 讀文字」的世界裡，從沒真的碰過天氣 API。它負責『動腦』（判斷該用什麼、怎麼解讀結果），你的程式負責『動手』。這個分工，正是後面第 7 章 agent「自己規劃、反覆用工具」能成立的地基——但那是後話，這章先把「一次工具呼叫」徹底搞懂。

🔧 動手試試：如果你手邊有能用工具的 API 或平台（例如 Claude、GPT 的 function calling），先只給模型一個 get_weather 工具，然後問它「1 加 1 等於多少？」。觀察它不會硬去呼叫天氣工具——這會讓你很有感：模型是真的在「判斷該不該用」，而不是逢問必呼叫。

工具長什麼樣子

一個工具就是「名字 + 說明 + 參數格式」。說明寫得越清楚，模型越知道何時該用它：

{
  "name": "get_weather",
  "description": "查詢某城市的即時天氣。當使用者詢問天氣、氣溫、是否下雨時呼叫。",
  "input_schema": {
    "type": "object",
    "properties": { "city": { "type": "string", "description": "城市名稱" } },
    "required": ["city"]
  }
}

逐行看懂這份「工具說明書」，你就懂了工具呼叫的全部：

• name：工具的代號，模型要呼叫時就報這個名字。
• description：最關鍵的一行。它不是給人看的註解，而是給模型看的使用時機說明——上面這句白紙黑字告訴模型「問天氣、氣溫、下不下雨時，用我」。這句寫爛了，模型就用錯或漏用。
• input_schema：規定參數長什麼樣。這裡宣告要一個字串 city（並用 description 說明它是城市名稱），而 required 表示這個參數非給不可。模型產生呼叫時，就會乖乖照這個格式填。

你會發現一件事：這份工具說明本身，就是一份 JSON schema——也就是下一節「結構化輸出」要講的東西。這不是巧合：工具呼叫和結構化輸出，底層是同一套「用 schema 約束模型產出格式」的技術，只是用在不同地方。

一個工具不夠？模型會自己挑

實務上你通常會一次給模型一整套工具（查天氣、查資料庫、寄信、算數學……），而不是只有一個。這時模型的工作就多一步：先從這一籃工具裡挑出對的那個，再填參數。挑選的依據，一樣是每個工具的 description。

舉個具體場景：你同時給了 get_weather（查天氣）和 calculator（計算機）兩個工具——

• 使用者問「台北幾度？」→ 模型挑 get_weather。
• 使用者問「38.5 乘以 7 是多少？」→ 模型挑 calculator，把算式交出去（呼應第 1 章：算數學這種它天生不擅長的事，就該外包給工具）。
• 使用者問「你好嗎？」→ 模型一個都不挑，直接用文字回答。

💡 記憶點：給模型工具，不等於強迫它用。用不用、用哪個，是模型每一輪自己判斷的——判斷的線索，就是你替每個工具寫的那句 description。所以「把工具說明寫清楚」是這整套技術裡最划算的投資。

結構化輸出：讓 AI 吐出「程式能直接吃」的資料

聊天回覆是給「人」看的自然語言；但要接進程式，你需要固定格式的資料，通常是 JSON。這就是結構化輸出（Structured Output）。

先解釋一下 JSON 是什麼（新手友善版）：它是一種「電腦之間交換資料的通用格式」，長得像一份標了欄位的表格，用 { "欄位": 值 } 的方式把資料寫清楚。程式最愛這種格式，因為它可以一行就精準取到「name 這個欄位的值」，不用去猜。

差別很關鍵：

❌ 自由回覆：「這位客戶叫王小明，今年 30 歲，想升級到企業版。」
   → 程式很難穩定地從這句話抽出欄位。

✅ 結構化輸出：{ "name": "王小明", "age": 30, "plan": "enterprise" }
   → 程式一行就能取用，穩定可靠。

為什麼「自由回覆」對程式是惡夢？因為自然語言太自由了：同樣的意思，模型這次寫「今年 30 歲」，下次可能寫「三十歲」「年齡 30」「30 y/o」。程式要應付這無限多種寫法，等於做不完。而結構化輸出把出口收窄成一種固定形狀，程式就能穩穩地接。

現代模型可以保證輸出符合你給的 JSON 格式（照著一份 schema 產生），不會多一句廢話。這讓 AI 能安穩地當「資料處理管線的一個環節」，而不只是聊天窗口。

這件事的機制也值得點一句：它其實是「工具呼叫」的雙胞胎。你一樣是給模型一份 schema（規定欄位、型別、哪些必填），只是這次不是叫它「呼叫工具」，而是叫它「照這個格式，把答案填出來」。背後同一套「用 schema 把模型的產出框住」的功夫。

一個很有畫面的真實場景——發票／收據抽欄位：你有一堆雜亂的收據文字，想整理成資料庫。與其自己寫一堆規則去剖析，不如給模型一份 schema，叫它把每張收據都吐成同一種形狀：

{
  "store": "全家便利商店",
  "date": "2026-07-09",
  "total": 138,
  "items": [
    { "name": "御飯糰", "price": 45 },
    { "name": "拿鐵", "price": 55 }
  ]
}

不管原始收據寫得多亂，出來的都是這種乾淨、欄位固定的資料，程式接著就能直接存進資料庫、加總、做報表。這就是為什麼「結構化輸出」是把 AI 接進系統的關鍵一步。

💡 記憶點：工具呼叫讓 AI 能「動作」，結構化輸出讓 AI 能「交付程式可用的資料」。這兩個加起來，AI 才真正能被「串進系統」。

🔧 動手試試：找一段亂七八糟的文字（例如一封訂購 email、一張收據拍照後轉的文字），叫模型「只回傳 JSON，包含 name、date、total 三個欄位，不要任何多餘說明」。再把要求改成「請整理一下這筆訂單」對比一下——你會直接看到「有沒有給格式」對程式友善度的天差地別。

⚠️ 小提醒：就算模型「保證」格式正確，欄位裡的內容它還是可能猜錯或幻覺（回想第 1 章）。格式對，不代表值一定對——抽出來的金額、日期，該驗還是要驗。

多模態：它早就不只會讀文字了

**多模態（Multimodal）**指模型能處理文字以外的輸入／輸出：

它是怎麼「看懂」圖的？其實跟第 1 章的道理一脈相承：模型會先把圖片也切成一塊塊、轉成它熟悉的那種「數字向量」（回想第 1 章的 embedding），跟文字放進**同一個「意思空間」**裡一起處理。所以對模型來說，「一張貓的照片」和「貓」這個字，在它腦中的位置是相近的——這就是它能「看圖說話」的底層原因：它不是真的用眼睛看，而是把影像也翻譯成它讀得懂的數字，再繼續它最拿手的「猜下一個字」。

這打開了大量應用：拍一張冰箱照片問「能煮什麼」、上傳一份合約問「有什麼風險條款」、給一張設計稿叫它「刻成網頁」。

再補幾個更貼近日常的場景，讓你有感它多好用：

• 看圖回答：對著一張爆掉的程式錯誤截圖問「這是什麼錯、怎麼修」，它能直接讀截圖裡的錯誤訊息給你解法。
• 讀圖表：丟一張營收長條圖，叫它「幫我用一句話總結趨勢」，它能看懂哪根高哪根低。
• 抽文件欄位：把一份 PDF 合約丟給它，配上上一節的「結構化輸出」，叫它把「甲方、乙方、金額、到期日」抽成 JSON——多模態負責讀進來、結構化輸出負責吐成程式能用的格式，兩個技巧串起來威力很大。

💡 實務提醒：圖片、文件會消耗大量 token（回想第 3 章的桌面）。高解析圖很貴，用不到那麼清楚時記得先縮圖。

🔧 動手試試：拿一張你手機裡的照片（發票、菜單、白板筆記都行）丟給支援看圖的模型，先問「這張圖裡有什麼？」，再進一步叫它「把裡面的品項和價格整理成 JSON」。你會同時體驗到「多模態」和「結構化輸出」兩個本章重點。

串流（Streaming）：為什麼 ChatGPT 是一個字一個字蹦出來

你有沒有發現 AI 回覆是逐字浮現的？這叫串流（streaming）：模型每猜出一個 token 就馬上傳給你，不用等整段講完。

這件事會發生，正是因為第 1 章講的——模型本來就是一個 token、一個 token 接龍產生文字的。串流只是「每生一個就馬上寄出去」，而不是「全部生完再一次寄」。所以它不是什麼額外的黑科技，而是順著模型的本性做的最佳化。

好處有二：①體感快很多（不用盯著空白轉圈）；②長輸出不會因為等太久而連線逾時。做任何有使用者在等的 AI 產品，串流幾乎是標配。

💡 小提醒：串流雖然體感好，但也有取捨——因為內容是「邊生邊送」的，你沒辦法等它全部講完才做檢查。如果你需要「先驗證整包 JSON 格式對不對、有沒有違規內容再顯示給使用者」，有時反而會選擇不串流、等完整結果。體感與可控性之間，要看場景權衡。

成本、延遲與模型選擇：別用大砲打小鳥

同一家廠商通常有好幾種尺寸的模型：旗艦（最聰明、最貴、最慢）、中階、輕量（最快、最便宜）。實務上最省的做法是混搭：

這裡的「延遲」也順帶解釋一下：指的是「你送出問題，到拿到回答」中間等的時間。模型越大、要生的字越多，通常就越慢。所以選型不只看「聰不聰明」和「多少錢」，還要看「使用者願不願意等這麼久」——一個即時客服機器人，快，往往比聰明一點點更重要。

💡 一個常見架構：先用便宜模型做「路由判斷」，把難的才丟給貴模型。這正是下一章「工作流設計模式」之一——Routing（路由）。

🔧 動手試試：挑一個你自己會用到的任務（例如「幫我把這段話分類成『客訴／詢價／其他』」），分別用同一家的「輕量版」和「旗艦版」模型各跑幾次，比較它們的答案品質、回應速度、以及大概的花費。你會親身體會「不是每件事都值得動用最貴的模型」。

重點回顧

• Tool Use：模型不執行、只「請求」；它判斷「該用哪個工具」用的是跟猜下一個字同一套機制，所以工具的 description 寫得好不好，直接決定它會不會用對。真正執行與權限控管在你的程式那一層（伏筆：harness）。
• 交棒與接回：模型全程只在「產生文字 / 讀文字」——它產生工具呼叫（一段 JSON），你的程式去執行，再把結果附回對話餵給它。模型動腦、程式動手。
• 結構化輸出（JSON）：跟工具呼叫是雙胞胎，都靠「用 schema 框住模型產出」。它讓 AI 交付「程式能直接用」的資料（抽發票、剖合約），是接進系統的關鍵；但格式對不代表內容對，該驗還是要驗。
• 多模態：影像、語音、文件都能處理（原理是把它們也轉成數字向量，跟文字放進同一個意思空間），配上結構化輸出威力更大，但要留意 token 成本。
• 串流：模型本來就逐字產生，串流只是「邊生邊送」，改善體感、避免逾時，是產品標配；但需要先驗證整包結果時可能選擇不串流。
• 模型選擇：大小模型混搭，別用大砲打小鳥；同時考量聰明度、成本與延遲。

「工具」加「迴圈」就等於 agent——但在做出會自己亂跑的 agent 之前，先學它更穩、更可控的哥哥：AI Workflow。下一章見。