在自然語言處理的演進過程中，大型語言模型（LLM）展現了強大的文本生成與語意推理能力。然而，傳統生成式模型存在兩大先天限制：知識截止日帶來的資訊滯後性，以及無法直接與外部環境產生交互作用（例如讀取資料庫或執行交易）。
為突破此瓶頸，函式調用（Function Calling / Tool Use） 成為現代生成式架構的核心技術。它讓語言模型從封閉的「文字預測器」演進為具備工具調度能力的「智慧代理中樞（Agent Core）」。
核心概念：模型並非直接「執行」程式碼
Function Calling 最常被誤解的觀念是「模型會自行連網執行程式碼」。實際上，語言模型在推論階段依舊保持無狀態與純文字輸入輸出的本質。
整個調用機制是由客戶端（Client Application）與模型服務（Model API）共同維護的四階段狀態機：

1. 介面宣告（Tool Declaration）：客戶端在 API 請求中，將可用工具的定義（以 JSON Schema / OpenAPI 格式描述）連同對話歷史一併傳給模型。
2. 意圖判斷與參數萃取（Intent & Argument Extraction）：模型在推論時判斷是否需要該工具。若需要，模型將壓抑常規的自然語言輸出，轉而生成符合規格的結構化參數（Function Call payload）。
3. 客戶端執行（Client Execution）：模型不負責對外連線，而是由客戶端接收該 payload，在受控環境下執行對應的 API、資料庫查詢或腳本。
4. 結果注入與彙整（Tool Response Ingestion）：客戶端將執行結果包裝為 ⁠Tool Response⁠ 角色訊息重新送入上下文，引導模型將原始數據轉化為連貫的最終解答。
   工具定義的 JSON Schema 結構拆解
   Function Calling 的本質是以嚴格的 Schema 約束引導 Attention 機制對齊參數。一個標準的工具定義主要包含三個維度：
   {
   "name": "get_stock_quote",
   "description": "取得特定股票代碼的即時股價、漲跌幅與成交量。當使用者詢問股票即時價格或行情時觸發。",
   "parameters": {
   "type": "OBJECT",
   "properties": {
   "ticker": {
   "type": "STRING",
   "description": "標準股票代號，例如 TSLA, AAPL, 2330.TW"
   },
   "market": {
   "type": "STRING",
   "description": "交易市場別",
   "enum": ["US", "TW", "HK"]
   }
   },
   "required": ["ticker"]
   }
   }
   工具宣告的三大架構設計心法
5. 職責單一與語意聚焦（Single Responsibility）
   避免設計過於龐大、包山包海的複合工具（如 ⁠manage_all_data⁠）。工具越單純，模型的語意匹配命中率越高。若需要複雜流程，應拆解為獨立工具讓模型透過思維鏈逐步調度。
6. 利用 Enum 建立閉環邊界（Constrained Values）
   當特定參數只允許固定選項時，務必透過 ⁠enum⁠ 宣告枚舉清單。這能有效阻止模型因「討好心理」而輸出無效或格式相近的非標準字串（例如將幣別代碼強制鎖定為 ⁠["USD", "TWD", "JPY"]⁠）。
7. 動態路由與非工具請求隔離（Intent Routing）
   一個成熟的 Function Calling 實作必須具備「不做任何動作」的判斷力。若使用者僅詢問「什麼是本益比？」，模型應能判定此問題不依賴外部資料庫，直接以一般對話模式回應，而非強制硬套工具。