OpenAI API 中的函式呼叫：它實際在做什麼，以及如何正確使用它

你將使用者的訊息傳給 GPT API，模型沒有回覆自然語言答案，而是回傳一個結構化的 JSON 物件，精確告訴你該呼叫哪個函式以及要帶哪些參數。這就是「函式呼叫」（function calling）——它改變了你能用 LLM 建構的應用類型。

多數開發者聽到「函式呼叫」就以為模型會代你執行程式碼。其實不會。

使用函式呼叫時，LLM 本身不會執行任何函式。它會辨識出適合的函式、收集所有必要參數，並以結構化的 JSON 格式提供資訊。

你的應用仍然負責執行實際邏輯。模型只是告訴你要執行什麼以及用哪些輸入。

這個差異比聽起來更重要，並且會影響你從整合架構到安全性思維的一切設計。

什麼是函式呼叫——以及大家常搞錯的地方

函式呼叫（也稱為工具呼叫）為 OpenAI 模型提供了一種強大而靈活的方式，能與外部系統介接並存取訓練資料之外的資料。

命名本身就是第一個混淆來源。人們以為模型在執行某些東西。其實沒有。

關於函式呼叫有許多名稱與說法，但核心就一句話：「函式呼叫是大型語言模型的一種結構化輸出能力。」LLM 不會自行呼叫任何函式；它只是從你在提示中提供的預先定義函式中，建議應該呼叫哪一個。

第二個混淆點與舊的 API 介面有關。

functions 與 function_call 參數在 API 的 2023-12-01-preview 版本中已被棄用。取代 functions 的是 tools 參數。

如果你跟著仍使用舊 functions 參數的教學在做，你已經在使用被棄用的語法。請改用 tools 與 tool_choice。

函式是工具的一種，由 JSON schema 定義。函式定義讓模型可以將資料傳給你的應用，你的程式碼便能依模型建議去存取資料或執行動作。

就是這個 schema 帶來比單純提示更可靠的優勢——你不是在期待模型正確格式化輸出，而是在 API 層強制結構。

OpenAI API 中的函式呼叫如何運作——逐步說明

工具呼叫是你的應用與模型透過 OpenAI API 之間的多步驟對話。工具呼叫流程有五個高層步驟：以模型可能呼叫的工具發送一次請求……

以下是每個步驟在實務中的呈現方式。

Step 1: Define your function schemas. 你在 tools 參數內，以 JSON 物件描述每個可用函式。schema 包含函式名稱、讓模型決定何時呼叫的自然語言描述，以及遵循 JSON Schema 規範的 parameters 區塊。

你的 description（描述）越具體——在何種情況下可以、應該呼叫該函式——效果越好。但請注意，函式描述是提示的一部分，也會消耗 token。

Step 2: Send the request. 你以使用者訊息與 tools 列表呼叫 Chat Completions API。模型會看到兩者。

Step 3: The model decides whether to call a function.

如果模型檢視提示後判斷為了遵循指示需要呼叫某個可用工具，它就會產生一種特殊的回覆：函式呼叫。例如遇到「巴黎的天氣如何？」這類提示，它可能回覆對 get_weather 工具的呼叫，並以巴黎作為 location 參數。

Step 4: Your code executes the function. 你解析模型回覆、擷取函式名稱與參數，並在你的執行環境中跑實際程式碼。API 回傳的是結構化 JSON——接下來要怎麼做由你決定。

Step 5: Send the result back.

接著你將所有工具定義、原始提示、模型的工具呼叫，以及工具呼叫的輸出一併送回模型，最後取得文字回覆

——類似「巴黎今天的天氣是 25°C。」這樣的結果。

大多數教學略過的一個細節：

當你在函式定義中設定 strict: true 時，Structured Outputs 可保證模型為函式呼叫所產生的引數與你提供的 JSON Schema 完全一致。

將 strict 設為 true 會讓函式呼叫可靠地遵循函式 schema，而非僅是盡力而為。OpenAI 建議永遠啟用嚴格模式。

真的永遠。沒有不啟用的理由。

另外還有並行函式呼叫需要了解。

依使用者查詢而定，如果使用的是 2023 年 11 月 6 日之後發布的最新模型，模型會啟用並行函式呼叫。

這代表像「倫敦和東京的天氣如何？」這樣的一次請求，可以觸發兩個同時的工具呼叫，而不是逐一串接。

函式呼叫的真實世界應用場景

天氣範例之所以常見，是因為簡單。但實際的生產應用更凌亂、也更有意思。

具即時資料的客戶支援流程

函式呼叫在許多用例中都很有用——例如一個 AI 助理在使用者詢問「我的近期訂單是什麼？」之前，需要先從內部系統抓取最新客戶資料，才能生成回覆。

模型會判別意圖、從上下文抽取客戶 ID，並呼叫你的 CRM 內部 API。不需要脆弱的正則表示式，也不需要一個逗號就會壞掉的提示模板。

大規模的結構化資料擷取

另一個強用例是資料擷取管線：抓取原始文字、轉換成結構化資料，並存入資料庫。你可以在數以千計的文件中得到一致的 schema，而不必為每種文件類型手工調整剖析邏輯。

自然語言到 API 的轉換

以 LLM 驅動的資料擷取與標註方案、能將自然語言轉成 API 呼叫或有效資料庫查詢的應用、與知識庫互動的對話式檢索引擎——這些在需要輸出格式保證時都受惠於函式呼叫。當輸出要驅動下游系統時，你無法容忍可變性。

多工具的代理式工作流程

對開發者而言，函式呼叫讓你能取得即時資料，以克服訓練截止的限制，如擷取即時股價、天氣或近期資料庫紀錄。它也讓你能執行動作——把 LLM 從被動觀察者轉變為能修改狀態的主動參與者，例如寄送電子郵件、更新 CRM 或部署程式碼。

與純聊天機器人的關鍵差異在於：模型不僅生成文字，它在協調你系統中的實際操作。

函式呼叫的最佳實務——開發者常犯的錯

這一節多數教學完全略過，因此團隊才會在凌晨兩點除錯怪異的生產故障。

描述寫得太含糊。 模型會依你的函式描述決定何時呼叫它。如果描述很籠統——像「處理使用者請求」——模型就沒有可靠的訊號來觸發。請具體說明觸發條件與預期輸入結構。把描述當作契約，而非標籤。

一次暴露太多函式

函式描述會在輸入提示中消耗大量 token。

在系統提示中載入 50+ 個工具定義會帶來兩個問題：成本與延遲，因為工具定義會吃掉輸入 token；以及準確度下降，因為工具選項越多，模型選對的能力越差。

從你的用例真正需要的最小函式集合開始。

假設模型不會臆造參數。 它會的。

模型可能臆造參數

——特別是對那些沒有明確以 enum 界定的可選欄位。這正是 strict: true 重要的原因：它移除了模型在你 schema 之外發明欄位的可能性。

沒有處理多輪迴圈。 開發者常只做 Happy Path——使用者發問、模型呼叫函式、完成。

模型可能產生不符合你定義 schema 的函式呼叫，或嘗試呼叫你沒有提供的函式。如果模型產生了預期外的函式呼叫，嘗試在 system message 中加入一句：「只使用你被提供的函式。」

為邊界情況做好準備。

略過寫入操作前的確認步驟。

要注意你計畫執行的函式呼叫在真實世界中的影響，尤其是那些會觸發執行程式碼、更新資料庫或發送通知等動作。對具有行動效果的函式，強烈建議在執行前加入使用者確認步驟。

如果某個函式呼叫可能刪除資料、匯款或修改外部狀態，就應該由人先核可。

安全性與可靠性考量

函式呼叫擴展了 LLM 能做的事，也擴大了攻擊者能讓它做的事。

主要威脅是提示注入（prompt injection）。

提示注入的最終目的多種多樣，包括透過下游工具呼叫外洩機密資料、執行不符合預期的動作，或以其他方式改變模型行為。

當你的函式呼叫可以寄信、查資料庫或觸發 webhook 時，一次注入攻擊不只是聊天機器人脫稿演出——而是潛在的資安事件。

隨著 AI 系統從聊天進一步走向呼叫工具與採取行動，提示注入變得更嚴重。藏在網頁、文件或外部工具中的惡意指令，可能嘗試覆寫系統行為、暴露敏感資訊，或觸發模型本不該執行的動作。

緩解策略有幾個具體層次。

在設計工作流程時，避免讓不受信任的資料直接驅動代理行為。只從外部輸入中擷取特定結構化欄位——例如 enum 或經過驗證的 JSON——以限制注入風險在各節點間傳遞。

除此之外，

務必驗證模型產生的函式呼叫。這包含檢查參數、被呼叫的函式，以及確保該呼叫與預期動作一致。

一個不太舒服的事實：

「提示注入，和網路上的詐騙與社交工程一樣，幾乎不可能被完全『解決』。」

這是 OpenAI 自己的評估。實務上的意義是，不要假設模型永遠按預期行事來設計具代理能力、會呼叫函式的系統。深度防禦——驗證、範圍化權限、對具破壞性的操作引入人為審核——才是唯一合理的姿態。

函式呼叫 vs. 提示工程——何時用哪個

這個比較常被提到。簡短答案是：它們解決不同問題，把兩者混為一談會導致該用函式呼叫時過度工程化提示，或該用良好系統提示時設計出脆弱的函式 schema。

提示工程涉及撰寫文字輸入來引導 LLM 的內在推理——例如要求它「逐步思考」。

它形塑模型如何推理。相對地，函式呼叫形塑模型產出的輸出，並將其直接導入你的系統。

工具呼叫是讓 LLM 與外部系統互動的能力。你會用提示工程幫助模型決定使用哪個工具，而工具呼叫則是實際執行動作的機制。你多半兩者都需要，但用途不同。

函式呼叫相較於基於提示的結構化輸出的關鍵技術優勢：

工具呼叫是內建於模型的概念。你不需要浪費 token 與精力去解釋模型應該回傳特定格式。

當你在提示中寫「請以包含欄位 X、Y、Z 的 JSON 回覆」時，你在花費 token 給出模型可能不一致遵守的指示。使用函式呼叫，schema 的強制是在 API 層完成。

如今許多 LLM 平台原生支援的函式呼叫 API，提供以 schema 為核心的正式介面，能嚴格驗證資料並與程式化工作流程整合。

這也是在任何要將資料送入下游系統的情境下，選擇它而非提示工程的現實理由：一旦進入生產，可靠性不是可選項。

實務準則：如果輸出需要驅動下游系統——資料庫寫入、API 呼叫、程式分支決策——用函式呼叫。如果輸出是給人閱讀，提示工程通常就足夠而且更省成本。

重點摘要

如果你想在不同模型之間試驗函式呼叫——GPT-5.4、claude opus 4.7、gemini 3.1 pro——而不想為每個模型分別維護 API 憑證，CometAPI 讓你用單一端點與金鑰存取所有模型，顯著降低跨模型測試的摩擦。

CometAPI 解決基礎設施負擔：

✅ 跨 15+ 模型的統一函式呼叫語法

✅ 單一 API 金鑰——無需為 OpenAI/Anthropic/Google 分別開帳號

✅ 自動 schema 轉換——一次撰寫，到處測試

✅ 內建成本追蹤——即時比較各模型的 token 使用量

用免費點數開始測試 → Get Access