Tool calling 是什麼:讓 AI 真的動手

你叫 AI 幫你訂會議室，它回你一段漂亮文字：「好的，我會幫你安排。」這不算完成任務。

真正完成任務，是它知道要查哪些人有空、呼叫行事曆 API、建立 event、寄出邀請、回報會議連結。中間那個從「會說」到「會做」的轉折，就是 tool calling。

Tool calling(function calling)是讓 AI 模型在需要外部資料或動作時，用結構化格式請求一個工具;真正的工具執行通常由你的應用程式或平台完成，再把結果交回模型。

簡短版：tool calling 是把 LLM 從聊天介面接到現實系統的插座。

Tool calling 解的不是智商，是手腳

LLM 本身很會處理文字，但它有三個天然限制。

第一，它不知道最新或私有資料。你的庫存、CRM、Notion、ERP、GitHub issue，不在模型參數裡。

第二，它不能憑空執行動作。模型可以寫出「建立退款」這幾個字，但不會真的碰到你的金流系統。

第三，自然語言太鬆。使用者說「幫我改成下週三下午」，工程系統需要的是明確欄位：日期、時間、時區、參與者、權限。

Tool calling 就是在中間加一層翻譯：模型讀懂人的意圖，輸出結構化的工具名稱與參數;系統負責檢查、執行、回傳結果。

它怎麼運作

最典型流程是五步。

1. 開發者把可用工具定義給模型，例如 get_weather、create_invoice、search_docs。
2. 使用者提出需求。
3. 模型判斷需要哪個工具，輸出工具呼叫與參數。
4. 應用程式端執行工具，例如真的打 API、查資料庫、跑計算。
5. 應用程式把工具結果送回模型，模型再整理成人能讀的答案。

用天氣例子看：

{
  "name": "get_weather",
  "arguments": {
    "location": "Taipei",
    "unit": "celsius"
  }
}

這段不是最終答案。它是模型在說：「我需要呼叫 get_weather，地點是台北，溫度單位用攝氏。」

接下來你的程式才真的去查天氣 API。API 回來後，模型再把結果寫成「台北目前 27 度，下午有陣雨機率」這種回答。

關鍵點是：模型提出工具請求，但你控制工具怎麼執行。

Function calling、tool calling、tool use 差在哪

這三個詞常常混用，但可以這樣理解。

名稱	常見語境	重點
Function calling	OpenAI、Google Gemini 等 API 文件	以 JSON schema 定義函式名稱與參數，讓模型輸出可被程式呼叫的結構
Tool calling	跨平台通用說法	工具不一定只是函式，也可能是搜尋、檔案、瀏覽器、程式執行、MCP server
Tool use	Anthropic / Claude 常見用語	強調模型使用工具的整個迴圈，包含 client-side 與 server-side tools

實務上不用太糾結。對 builder 來說，重點是同一件事：把模型的自然語言判斷，轉成可檢查、可執行、可記錄的系統動作。

它跟 API 差在哪

API 是工具本身。Tool calling 是「模型什麼時候該用哪個 API、帶什麼參數」的決策層。

如果你寫一般程式：

await calendar.createEvent({
  title: "產品會議",
  start: "2026-04-29T15:00:00+08:00"
});

這是工程師事先決定好要呼叫哪支 API。

如果用 tool calling，使用者可以說：「幫我下週三下午約產品會議，找一下 Alice 跟 Bob 都有空的時間。」模型先判斷要查空檔，可能呼叫 list_free_slots;再根據結果呼叫 create_event;最後回覆使用者。

API 是手。Tool calling 是讓模型決定何時伸手，但仍由你的系統決定這隻手能碰什麼。

它跟 RAG 差在哪

RAG 主要是「查資料再回答」。Tool calling 是「需要時呼叫工具」。

問題	比較適合
「我們退費政策第 7 條怎麼寫？」	RAG
「幫我查這位客戶最近三張訂單」	Tool calling
「根據公司文件回答，再開一張客服 ticket」	RAG + tool calling
「讀 GitHub issue、修 code、開 PR」	Tool calling + agent workflow

兩者常常一起用。RAG 負責找知識，tool calling 負責查系統或做動作。真正的企業 agent 幾乎不會只靠其中一個。

它跟 MCP 差在哪

MCP(Model Context Protocol)不是 tool calling 的替代品，而是工具與資料如何被 AI 應用發現、描述、連接的一種通用協定。

可以把層次分成三層：

層次	解什麼問題
Tool calling	模型要不要呼叫工具、呼叫哪個、參數是什麼
MCP	工具、資源、prompt 怎麼用標準協定暴露給 AI 應用
實際 API / 系統	真正讀資料、寫資料、執行動作的地方

換句話說，MCP server 可以暴露 search_orders、create_ticket 這些工具;模型仍然需要透過 tool calling 這類機制來選工具、填參數、拿結果。

最容易誤會的地方：模型不是作業系統

很多 demo 看起來像「AI 自己上網、自己寫檔、自己下單」。這種說法很吸睛，但不精確。

生產系統裡，你應該把 tool calling 當成受控的請求機制，不是把公司系統交給模型。

幾個基本原則：

工具要窄。 refund_order 比 run_sql 安全。create_draft_refund 又比 refund_order 安全。

參數要嚴。 能用 enum 就不要用自由文字。能要求日期格式就不要讓模型猜。schema 越清楚，錯誤越少。

高風險動作要有人審。 寄信、退款、刪資料、改價格、動 production database，都不該讓模型直接放行。

每次工具呼叫都要記錄。 誰要求、模型選了什麼工具、參數是什麼、工具回什麼、最後採取什麼動作。沒有 log，就沒有可追責性。

外部內容要當成不可信輸入。 如果模型透過工具讀 email、網頁、issue，裡面可能藏 prompt injection。讀到資料不等於可以照資料裡的指令做事。

對台灣團隊的判斷

台灣很多 AI 導入案卡住，不是因為模型不夠強，而是因為公司流程沒有被做成可被安全呼叫的工具。

例如客服部門說要 AI agent，但退費規則只存在資深客服腦中;業務說要自動整理 CRM，但欄位定義每個人填法不同;製造業想接 ERP，但權限、測試環境、審核流程都還沒切出來。

這時候不要先問「用哪個模型」。先問：

1. 哪些動作真的值得自動化？
2. 哪些資料可以被讀？哪些不能？
3. 哪些工具只能草稿，不能直接執行？
4. 哪些工具呼叫一定要主管、人類客服或工程師確認？
5. 失敗時要怎麼回滾、怎麼通知、怎麼留紀錄？

Tool calling 的價值不是讓 AI 看起來更神。它的價值是把工作流程拆成可授權、可測試、可觀察的工具。

一句話收尾

Tool calling 是 AI agent 的基本功。

沒有它，LLM 多半只是會聊天的文字引擎。有了它，LLM 才能查資料、跑計算、開 ticket、建會議、改草稿、串 workflow。

但它也把一個新問題丟回給 builder:你敢讓模型碰哪些工具？碰到什麼程度？誰負責最後那一下？

把這三個問題想清楚，tool calling 才會從漂亮 demo 變成能上線的產品。

周詠晴（編輯：廖玄同），《Tool calling 是什麼:讓 AI 真的動手》，矽基前沿 [Si]gnals，2026-04-26。https://signals.tw/articles/what-is-tool-calling/