Function Calling 是什麼?AI 怎麼呼叫外部工具

文章屬性:AI 概念解析
核心結論:Function Calling 讓 AI 模型不再只是「回答問題」,而是能輸出「該呼叫哪個函式、帶什麼參數」的結構化請求;實際執行永遠是你的程式碼在做,模型本身不會真的去操作資料庫或發 API。
適用對象:自己串接 AI API 的開發者、想搞懂 AI 助理怎麼「動手做事」的人、分不清 Function Calling / Structured Outputs / MCP 差在哪的讀者

📌 快速答案

一句話答案:Function Calling 是 AI 模型輸出「要呼叫哪個函式、帶什麼參數」的結構化請求,由你的程式執行後把結果送回模型,模型本身不會真的動手做事。

🚦 先講結論:什麼時候該用 Function Calling?

把場景攤開來看最快:

你想讓 AI 查你的訂單系統、資料庫、內部 API,或觸發實際動作(訂機票、發通知、控制裝置) → 用 Function Calling。
你只是想讓 AI 回答使用者時,順便把答案包成固定格式的 JSON(方便前端渲染) → 用 Structured Outputs(見下文)。
你想讓 AI 連上一大批外部工具伺服器,不想為每個服務各寫一套串接 → 那是 MCP(Model Context Protocol)在解決的連接層問題,Function Calling 是它底下實際「呼叫工具」用的機制。

三個概念常被混在一起講,但對應的其實是三個不同層次的問題:要不要動手(Function Calling)、輸出格式要不要保證(Structured Outputs)、工具要怎麼統一插拔(MCP)。這篇文章專注拆解第一個。

🔍 為什麼你要在乎這件事

如果你曾經自己串過 Prompt Caching 之類的 AI API,大概也遇過更早的一個痛點:模型本身沒有手,不能真的幫你查資料庫、訂機票、發 email。你只能把資料整理好貼進提示詞,讓模型「用讀過的資料回答」——但這樣做不到即時查詢、觸發不了真實動作,資料一多提示詞也會爆炸。

Function Calling 補的正是這一塊。你先告訴模型「有哪些工具可以用、每個工具要帶什麼參數」,模型看到使用者的問題後自己判斷該不該呼叫、呼叫哪一個、參數怎麼填,再把這個「呼叫請求」交還給你的程式去實際執行。

如果你看過站上介紹 RAG(檢索增強生成) 的文章,可以順便理解兩者的分工差異:RAG 負責「把外部資料塞進提示詞讓模型讀」,解決的是模型不知道的事;Function Calling 負責「讓模型主動觸發動作、即時查詢」,解決的是模型不能動手做的事。需要即時互動或寫入動作時,Function Calling 更合適;只是要模型讀懂大量背景資料時,RAG 更合適,兩者也可以合併使用。

🧪 原理拆解

Function Calling 到底在「呼叫」什麼

先講清楚一個常見誤解:模型本身完全不會連網、不會碰你的資料庫、不會真的發出 API 請求。它做的事情只有一件——根據你提供的工具說明(名稱、用途、參數格式),判斷這次對話該不該用工具、該用哪一個、參數該填什麼,然後把判斷結果以結構化資料(通常是 JSON)吐回來。

真正動手的永遠是你的應用程式:收到模型的呼叫請求 → 你的程式碼執行對應邏輯(查資料庫、打內部 API、控制裝置)→ 把執行結果整理好送回模型 → 模型才根據結果產生最終給使用者看的回覆。整個過程模型是「決策者」,你的程式是「執行者」,權限與風險控管完全掌握在你手上。

完整流程:5 個步驟怎麼跑

以 OpenAI 官方文件的描述為例,Function Calling 是一場多輪對話,固定跑五步:

你的應用程式帶著「工具清單」向模型送出請求
模型判斷需要用工具,回傳一個工具呼叫請求(函式名稱+參數)
你的程式執行對應的函式,拿到結果
你的應用程式把執行結果包成新的一輪請求,再送回模型
模型根據結果產生最終回覆(或判斷還需要再呼叫其他工具,重複步驟 2–4)

Anthropic 的 Claude 也是同樣的迴圈:Claude 回應時如果決定用工具,stop_reason 會標成 tool_use,內容區塊裡帶著工具名稱與參數;你的程式執行完之後,要把結果包成 tool_result 送回去,對話才能繼續。Google Gemini 的流程概念一致,差別在細節命名與設定方式。

三大家怎麼做:OpenAI、Anthropic、Google Gemini

三家的核心概念相同,但控制呼叫行為的參數與模式命名各自不同,混著查文件很容易踩錯:

廠商 API	預設模式(可不呼叫)	強制一定呼叫	Schema 強制對齊
OpenAI	`tool_choice: "auto"`	`"required"` 或指定 `{"type":"function","name":...}`	`strict: true`(底層借用 Structured Outputs)
Anthropic Claude	`tool_choice: {"type":"auto"}`	`{"type":"any"}`(任一工具)或 `{"type":"tool","name":...}`(指定)	`strict: true`(Strict tool use)
Google Gemini	`mode: "AUTO"`	`mode: "ANY"`	`mode: "VALIDATED"`(Preview 階段)

平行呼叫(一次判斷要用好幾個工具)三家預設都允許,也都提供關閉開關:OpenAI 用 parallel_tool_calls: false,Anthropic 在 tool_choice 裡加 disable_parallel_tool_use: true,Gemini 官方文件則說明彼此獨立、不互相依賴的函式會自動被判斷為可平行呼叫。Gemini 另一個容易被忽略的細節是它的函式宣告只吃部分子集的 OpenAPI Schema,不是完整 JSON Schema,複雜巢狀結構在 ANY 模式下有機率被拒絕,設計時要留意。

Function Calling vs Structured Outputs,別再搞混

這兩個常被放在一起講,是因為 OpenAI 的 strict: true 底層真的是共用 Structured Outputs 這套引擎,但用途完全不同:

Function Calling:目的是連接你系統裡的工具、資料、動作,模型判斷完之後,執行權在你手上。
Structured Outputs:目的是讓模型「回給使用者看」的最終答案本身符合你定義的 JSON Schema——例如你想讓模型輸出固定欄位的 JSON,方便前端直接拿去渲染,這裡沒有「呼叫工具」的動作,純粹是格式保證。

OpenAI 官方文件把這個分野講得很白話:如果是要把模型接到系統裡的工具、函式、資料,用 Function Calling;如果只是想讓模型回應使用者時輸出的格式固定,用 response_format 的 json_schema。兩者也能同時用——工具呼叫的參數一樣可以套用嚴格 schema 驗證。

寫好工具定義的實務原則

三家官方文件對「怎麼寫好工具說明」的建議高度一致,整理成幾條可以直接照做的原則:

描述寫清楚、寫具體:Anthropic 官方建議每個工具至少 3–4 句話說明用途、何時用、何時不用、每個參數的意義,工具說明的品質是影響呼叫準確率最大的因素。
能用程式決定的參數,不要丟給模型填:如果系統已經知道 order_id,就不要在 schema 裡放這個欄位讓模型自己猜,直接用程式碼帶入即可。
相關操作合併成一個工具:與其開 create_pr、review_pr、merge_pr 三個工具,不如做一個工具搭配 action 參數,減少模型選錯工具的機率。
一開始開放的工具數量別太多:OpenAI 建議一輪對話開放的工具盡量控制在 20 個以內(軟性建議),工具多的場景改用工具搜尋機制,讓不常用的工具用到才載入。
回傳結果只給模型真正需要的資訊:Anthropic 建議工具的回傳值用穩定、語意清楚的識別碼(例如 slug、UUID),別把整包內部資料結構原封不動丟回去,徒增模型要消化的 token。

💡 總結:站長的實務觀察

站長自己串過幾個小工具(幫部落格查文章、跑腳本類任務)接 Function Calling,實際感受是:多數呼叫失敗不是模型「笨」,而是工具說明寫得不夠具體——參數用途講不清楚、沒講清楚什麼情況不該呼叫,模型就會亂猜。官方文件反覆強調「像跟一個只看得到你給的資訊的新人交代任務」這個心法,實際用起來確實有感:把工具說明寫到連完全不懂系統背景的人都能照著操作,呼叫準確率會明顯提升,這比換模型版本更立竿見影。

另一個常被忽略的細節是 strict 模式的取捨。三家都提供嚴格模式保證輸出一定符合 schema,但這不是沒有代價——OpenAI 的 strict: true 要求所有欄位都設為必填(選填欄位要用 null 型別技巧繞過),schema 設計會變得比較僵硬;不需要 100% 保證格式、想保留一點模型彈性判斷空間的場景,可以先從非嚴格模式開始測,觀察失敗率再決定要不要上嚴格模式,不用一開始就把路走死。以上內容依 OpenAI、Anthropic、Google 官方文件於 2026-07-09 查證撰寫,各家參數名稱與模式如有異動,請以當下官方頁面為準。

❓ 常見問題

Q:Function Calling 會不會讓 AI 自己亂執行危險操作(例如刪除資料、亂花錢)?

不會「自己」執行——這是最常被誤解的一點。模型只會輸出「我想呼叫這個工具、帶這些參數」的請求,真正按下執行鍵的永遠是你的程式碼。要不要真的執行、要不要先跳出確認,完全是應用程式邏輯決定的事,跟模型本身無關。

Q:一定要開 strict / Schema 強制模式嗎?

不一定。三家官方文件都建議「盡量開啟」以避免格式跑掉造成程式解析失敗,但開啟後 schema 設計限制較多(例如 OpenAI 要求所有欄位必填)。工具簡單、參數少的情境,不開嚴格模式也能跑得穩;工具複雜、下游程式對格式很敏感時,才值得換嚴格模式換取穩定度。

Q:Function Calling 跟站上介紹過的 MCP 概念是同一件事嗎?

不是,但兩者常被放在一起講。Function Calling 是「模型怎麼呼叫單一工具」的機制層;MCP(Model Context Protocol)是「怎麼用同一套協定接上一大批工具與資料來源」的連接層標準——可以把 MCP 想成幫你把很多工具用統一格式包好,模型底層實際呼叫時走的還是 Function Calling 這套機制。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Function calling — OpenAI API 官方文件 — 2026-07-09 查證
Structured model outputs — OpenAI API 官方文件 — 2026-07-09 查證
Tool use with Claude — Claude Platform Docs — 2026-07-09 查證
Define tools — Claude Platform Docs — 2026-07-09 查證
Function calling with the Gemini API — Google AI for Developers — 2026-07-09 查證

⚠️ 本文核心機制與參數名稱以第一級官方文件為準,各家 API 常態性調整參數與模式命名,使用前請以當下官方頁面為準。

📅 本文查證戳記:2026-07-09 依據 OpenAI、Anthropic、Google 官方文件撰寫。