函式呼叫

3 秒看懂

大型模型的“函式呼叫”不是讓模型執行程式碼，而是讓模型輸出結構化的呼叫意圖——它根據你的描述，決定該呼叫哪個函式、用什麼引數，然後把結果以約定的 JSON 格式返回給你的程式，由你的程式去實際執行。

一句話：模型做“大腦”，你的程式碼做“手腳”。

3 分鐘產業解釋

在 AI 應用裡，大語言模型雖然能聊天、寫文章，但無法直接查詢即時資料庫、傳送郵件、控制智慧家居。函式呼叫就是用來打通這層隔閡的橋樑。其工作流程可概括為三步：

1. 定義工具：開發者將可用的函式（如 get_weather(city, date)）及引數說明，以 JSON Schema 的形式傳給模型。
2. 模型決定：當用戶問“北京明天天氣怎樣？”，模型不會直接回答天氣，而是輸出一個結構體，如 {“name”:“get_weather”,“parameters”:{“city”:“北京”,“date”:“2026-01-25”}}。
3. 程式執行並反饋：你的程式碼實際呼叫天氣 API，把結果（如“晴，-5°C”）拼回對話，讓模型生成最終的自然語言回覆。

這種做法把 LLM 從“知識庫”變成“意圖路由器”，有效規避幻覺、利用外部即時資料、安全可控地執行有副作用的操作。目前主流的閉源/開源模型 API（如 OpenAI、Anthropic、Gemini、Qwen、DeepSeek 等）均已內建函式呼叫支援，雲端廠商和開源架構（LangChain、Semantic Kernel）也圍繞它建置了龐大的工具呼叫生態。

15 分鐘專家深入

函式呼叫看似簡單，但要將非結構化的自然語言可靠地對映到嚴格型別的函式簽名上，需要解決語義消歧、引數填充、多輪反問、並行呼叫、錯誤修正等一系列工程難題。當前產業的做法主要有兩個層次：

1. 協議與格式層

• OpenAI 風格（tools / tool_choice）：在 Chat Completions API 中，通過 tools 欄位傳入函式列表，tool_choice 控制呼叫策略（自動/強制/不呼叫）。響應中的 tool_calls 包含 id、function.name 和 function.arguments（JSON 字串）。後續將執行結果封裝成 role: tool 訊息回傳，模型據此生成最終答案。
• Anthropic 的 tool use 塊：類似，但根植在 Content Blocks 體系下，強調交疊思考（chain-of-thought）與工具呼叫的交替進行。
• 通用化趨勢：各廠商介面趨同，但細節（如是否支援多工具並行呼叫、引數流式返回、拒答方式）仍有差異，多模型適配層（如 LiteLLM）將這些抽象統一。

2. 模型能力層

函式呼叫不是簡單的外掛，而是模型需要內建的一種結構化輸出能力。訓練資料中會混入大量的工具呼叫對話示例，讓模型學會：

• 從使用者模糊表述中提取精確引數（“深圳”需要轉為“Shenzhen”還是城市程式碼？）
• 在資訊不足時主動反問（“您要查哪個城市的天氣？”）
• 呼叫失敗時，根據錯誤資訊調整引數重試
• 安全邊界：拒絕呼叫危險函式（如轉賬），或在敏感欄位（身份證號）上要求人工確認

目前頂尖模型（GPT‑4、Claude 3.5 Sonnet 等）的函式呼叫準確率在公開基準（如 BFCL）上整體約 80%，但面對複雜巢狀引數、長上下文干擾、多函式聯合呼叫時，仍有較明顯衰減。

3. 並行與流式呼叫

一次使用者請求可能需要同時呼叫多個無關函式（例如“查北京天氣、上海天氣，並把結果發我郵箱”），模型需支援一次返回多條 tool_calls。流式場景下，引數需要逐塊生成並即時解析，對 parser 的魯棒性要求極高，業界常用部分 JSON 解析器（partial json parser）來處理不完整的引數片段。

技術原理

核心機制

大語言模型本質上是一個機率生成器，通過監督微調（SFT）和人類反饋強化學習（RLHF），模型被訓練成在遇到工具呼叫場景時，輸出符合特定語法的文本——而不是自由文本。對模型而言，“函式呼叫”就是在生成一種特殊的程式碼序列。

以典型的工具呼叫實現為例，底層流程如下：

使用者輸入 (經過聊天模板包裝)
    ↓
[System Prompt + User Message]
    ↓
Token 序列 → Transformer 解碼
    ↓
若模型決定呼叫工具，輸出包含特殊標記的結構化文本
例如：
（模型生成包含特殊標記的 JSON，如 ）
    ↓
API 層攔截該特殊標記塊，解析為結構化呼叫物件
    ↓
返回給客戶端，客戶端執行真實函式

關鍵點：

• token 級控制：模型在訓練中學習到，當生成某個特殊 token（如 <|tool_call|>）時，後續必須生成合法的函式名和 JSON 引數。
• 有限狀態機約束：部分推論引擎（如 llama.cpp 的 GBNF 語法、Outlines、guidance）會在解碼時強制下一個 token 必須符合 JSON Schema，從而保證 100% 格式正確。OpenAI 等閉源 API 也採用了類似的內部約束技術，但不是所有模型都原生支援。
• 引數準確性：模型從上下文和不明確的使用者輸入中推斷缺失引數是核心挑戰。常見技術包括：Few-shot 示例（提示中包含幾個呼叫範例）、Chain-of-Thought 推論（讓模型先思考再寫引數）、自我驗證（生成引數後再檢查合理性）。

並行呼叫示例（序列維度）

使用者: “查北京、上海 2026-01-26 天氣”
模型輸出:
[
  {“id”:“call_1”,“function”:{“name”:“get_weather”},“arguments”:{“city”:“北京”,“date”:“2026-01-26”}},
  {“id”:“call_2”,“function”:{“name”:“get_weather”},“arguments”:{“city”:“上海”,“date”:“2026-01-26”}}
]

兩次呼叫可同時發起，結果收集後一次性返回模型彙總。

---

技術演進史

• 2022 年末 ~ 2023 年初：思維鏈、ReAct 模式興起，研究者在提示詞中手寫工具呼叫語法（如“Action: search”、“Action Input: …”，LangChain 早期 Agent 均基於此）。
• 2023 年 6 月：OpenAI 為 GPT‑3.5/4 釋出原生的 Function Calling 支援，首次將工具呼叫作為 API 的第一公民，極大提高了可靠性和開發體驗。
• 2023 下半年 ~ 2024 年：Anthropic 推出 tool use；Google Gemini 支援函式呼叫；開源模型（Llama、Mistral、Qwen 等）通過格式指令或微調追趕該能力。2024 年，並行呼叫支援幾乎成標配。
• 2024 年：走向更細粒度的控制：structured outputs（強制 JSON 模式，不僅僅函式呼叫）、工具呼叫的流式返回、工具呼叫代理（如 OpenAI 的 GPT Actions、Anthropic 的 MCP 協議），以及將工具呼叫融入多 Agent 編排。

---

技術路線對比

維度	OpenAI 函式呼叫 (Chat Completions)	Anthropic Tool Use	開源方案 (格式指令+微調)	LangChain / Agent 架構
實現方式	API 原生 tools + tool_choice	Content Block 原生 tool_use	提示詞注入函式列表，模型輸出特定格式文本，應用層解析	將函式描述注入提示，模型生成文本後正則/JSON 解析
格式可靠性	極高（內部約束解碼）	極高（內部約束解碼）	中等~高（依賴模型指令遵循度，可用語法約束引擎提升）	中低（需要大量 prompt 工程和容錯處理）
並行呼叫	原生支援多條 tool_calls	支援，但非同步流式體驗依賴客戶端	取決於模型自身能力，部分模型支援	依賴模型輸出，架構常輔以並行策略
流式引數返回	支援流式 tool calls（Beta）	支援（通過 content_block_delta）	部分推論引擎支援 token 流輸出，需客戶端拼接	自實現難度高
強制呼叫模式	tool_choice:“required” 強制模型必須呼叫函式	通過系統提示引導不強制	可提示“必須返回工具呼叫”但不保證	不可靠
安全與權限	API 不執行函式，責任在開發者	同左	同左	同左
典型應用場景	企業級助手、AI 代理、數字員工	長文件分析、程式設計助手、研究代理	本地部署、離線場景、資料敏感環境	快速原型、複雜 Agent 流程（多步、條件分支）

【說明】上表能力對比基於 2025 年初主流模型與架構的公開文件，具體數字/版本號未引用外部資料，細節可能存在廠商更新而變動。

---

上下游

上游：

• 基座模型訓練：需要大量工具呼叫對話資料，通常是合成數據（用強模型生成）或人類標註。
• 推論引擎/架構：vLLM、TensorRT-LLM、llama.cpp 等需支援結構化輸出和工具呼叫解析的最佳化。
• 工具 API 提供方：天氣服務、航班查詢、資料庫、CRM 系統等，要求介面文件詳細、引數型別明確。

下游：

• AI 助手/Agent：個人助理、企業知識庫助手、編碼助手（如 Copilot）。
• 自動化流程：RPA 與 LLM 結合，處理發票、客服工單自動填寫。
• 智慧硬體：智慧音箱、車載語音、機器人，將語音指令轉為裝置 API 呼叫。
• 多 Agent 協作系統：多個函式呼叫 Agent 分工協作，完成採購、排程等複雜任務。

---

關鍵指標

由於缺少檢索證據，以下為產業通用的定性衡量維度，具體數值請參考各模型最新的 BFCL 等基準報告：

1. 函式選擇準確率 (Accuracy)：當用戶意圖明確時，模型是否選擇正確的函式。
2. 引數填充完整性與合理性：必要引數是否全部提取，引數值是否匹配語義（如相對日期“明天”轉為絕對日期）。
3. 幻覺引數率：生成不在選項中的、或無意義的引數值（如虛構的機場程式碼）。
4. 拒答/反問率：資訊不足時，模型不會瞎猜，而是反問缺失引數——“請問哪個城市？”
5. 格式合規率：輸出 JSON 是否可解析，是否符合函式定義的型別。
6. 延遲：從 prompt 到返回完整函式呼叫的時間，首 token 延遲尤為重要。
7. 多函式聯合呼叫成功率：同時涉及 3 個以上不同函式的複雜任務，工具呼叫順序、依賴關係是否正確。
8. 安全攔截率：對高風險函式（如大額支付、刪除資料），模型在引數驗證或使用者確認前的呼叫攔截比例。

【基準資料】截至本文撰寫日，BFCL 等公開排行榜提供了詳細的函式呼叫評估資料，具體數值會隨模型更新而變化，請以最新官方排行榜為準。

---

供需與市場資料

（本節資料缺乏公開檢索源，主要基於產業趨勢的定性描述及 [行業估算]）

• 需求側：幾乎所有企業級 AI 落地專案都需要打通外部資料與系統，函式呼叫是必備元件。產業觀察顯示，大量 AI 應用 PoC 會涉及工具呼叫/函式呼叫能力。
• 供給側：閉源模型以 API 形式提供標準服務，邊際成本體現在推論算力上；開源模型通過微調即可獲得該能力，門檻持續降低。2024 年起，中小引數模型（7B~13B）在函式呼叫上的表現迅速追趕大型模型，推動端側和離線部署。
• 價格：函式呼叫的 API 呼叫與普通對話呼叫通常同價，但複雜工具定義會佔用更多 context token，導致成本上升。企業級的函式呼叫閘道器、權限管理、審計工具成為新的軟體市場（例如工具呼叫防火牆）。
• 趨勢：函式呼叫正從“單個 API 能力”演變為“Agent 基礎設施協議”（如 MCP、A2A），市場從模型介面層上移到了工具呼叫平台與安全治理層。

---

代表公司與資本對映

模型層：

• OpenAI（閉源）、Anthropic（閉源）、Google（閉源）、Meta（開源 Llama 系列）、阿里（Qwen 系列）、深度求索（DeepSeek 系列）、Mistral AI、智譜（GLM）等。

架構/中間層：

• LangChain、LlamaIndex、Semantic Kernel（微軟）、CrewAI、AutoGen、Dify 等提供函式呼叫編排的抽象。

基礎設施：

• 各雲端廠商（AWS Bedrock、Azure AI、GCP Vertex AI）提供託管函式呼叫 API；推論最佳化公司如 Fireworks AI、Together AI、Groq 也提供相容 OpenAI 函式呼叫介面的低延遲服務。

資本關注點：

• 純粹的“函式呼叫”能力已難構成壁壘，資本更看重上下文工程（如何高效組織函式描述、歷史呼叫、使用者資料）和安全可控的工具呼叫閘道器——能記錄、重放、阻斷每一次呼叫，並符合企業審計要求。工具身份認證、權限代理、呼叫鏈追溯成為新興的創業方向。

---

產業對映

1. 替代傳統 API 編排邏輯：過去需要寫大量 if-else、意圖分類器、槽填充的對話系統，現在可以被一個函式呼叫模型替代，極大降低開發成本。可觀察提供“低程式碼 Agent 工廠”的平台型公司。
2. 從模型到 Agent 的範式遷移：函式呼叫是 Agent 的“手”。公司能力應看其是否擁有一套完整的工具呼叫治理體系（權限、閘道器、監控），而非模型本身。
3. 安全與合規是痛點也是護城河：企業大規模上線 AI Agent 時，最擔心模型“亂調函式”（如誤刪生產資料）。因此函式呼叫的安全沙箱、呼叫回滾、人類審批工作流將成為必選項，相關安全公司可能獲得更多產業合作機會。
4. 端側部署的井噴：當小型模型（如 3B~8B）的函式呼叫可靠度達到商用門檻，智慧硬體、車載、IoT 將出現更多方案，帶動模型壓縮/加速晶片和邊緣推論架構的需求觀察。
5. 風險提示：開源模型快速追平能力，導致閉源 API 的函式呼叫溢價空間縮小；LLM 推論成本持續下降，但工具呼叫的序列化呼叫可能仍比單輪對話貴 3~5 倍，在大規模場景下毛利承壓。

---

常見誤讀糾偏

誤讀 1：“函式呼叫就是讓 AI 代替程式設計師寫程式碼執行”

實際：模型只生成呼叫意圖和引數，絕不執行程式碼。所有執行都由開發者的函式（或經開發者授權的沙箱）完成。模型本身沒有執行環境，這是一個安全意義上的根本隔離。將“function calling”理解為“寫好的服務被模型選擇並傳參”而非“模型寫一段程式碼跑起來”。

誤讀 2：“只要把函式定義扔進 prompt，模型就能完美工作”

實際：函式定義的質量、描述的自然度、引數約束的明確性，對準確率有巨大影響。prompt 中函式的排列順序也可能引發偏好偏差；多函式干擾下，語義相似的函式容易混淆。這不是即插即用的黑盒，需要持續的函式描述最佳化和線上評估，這被稱為“函式呼叫提示工程”，是運維 Agent 的核心工作之一。

---

學習路徑

1. 入門：閱讀 OpenAI 或 Anthropic 官方的 Function Calling/Tool Use 文件，用 Python 寫一個簡單的天氣查詢助手，理解 tools、tool_choice 和 tool role 的訊息流轉。
2. 實踐：在 LangChain 中建置一個 Agent，整合搜尋、計算器、資料庫三種工具，體驗多工具協調、錯誤處理。嘗試用 Llama 等開源模型 + Ollama 本地搭建，觀察與閉源模型的能力差距。
3. 深入原理：研究約束解碼（GBNF 語法、lm-format-enforcer、xgrammar）在函式呼叫的應用，瞭解如何在解碼階段保證輸出格式。學習模型微調資料集的構造——如何從真實 API 文件自動合成多樣的工具呼叫對話。
4. 架構設計：閱讀 MCP（Model Context Protocol）規範，理解工具提供方與 LLM 之間標準化通訊的價值。分析企業級函式呼叫閘道器的架構要點：身份認證、呼叫審計、頻率限制、引數脫敏。
5. 評估體系：關注 BFCL、ToolBench、τ-bench 等評測基準，學會自己構造測試集，用全自動評分+人工稽核的方式評判你部署的 Agent 的函式呼叫質量。

---

一句話總結

函式呼叫是把大語言模型從“聊天玩具”變成“業務執行引擎”的核心契約——它用結構化的意圖表達替代了非結構化的自由文本，在安全邊界內讓模型指揮現實世界的數字化服務。

---

延伸閱讀與來源

• OpenAI 官方文件：Function Calling （platform.openai.com）
• Anthropic 官方文件：Tool use （docs.anthropic.com）
• Berkeley Function Calling Leaderboard （gorilla.cs.berkeley.edu）
• 《A Survey on Tool Learning with Foundation Models》 （arXiv 2024 綜述）
• LangChain Tool Calling 概念指南（python.langchain.com）
• 模型上下文協議 MCP 規範（modelcontextprotocol.io）

【免責宣告】本文撰寫時未能獲得即時檢索資料，部分市場趨勢、效能區間的描述基於公開常識和業界公開資訊推斷，已標為定性/估算。具體技術規格、排行數值請以原廠最新文件和權威基準為準。