這裡是工具使用在實際運作中的機制。當您在 Claude 或 GPT-4 等 API 發送訊息時，也會一併傳送一組工具定義 — 每個定義都是描述函數名稱、參數（含類型與說明）以及功能的 JSON 結構。模型會將這些定義視為上下文的一部分，當它判斷呼叫工具能幫助回答用戶問題時，會停止生成文字，而是輸出結構化的工具呼叫物件：函數名稱與欲傳遞的參數。您的應用程式程式碼隨後會執行該函數（呼叫 API、查詢資料庫、執行計算），並將結果以新訊息形式回傳給模型。模型讀取結果後會繼續生成回應。這並非模型「執行程式碼」 — 而是模型產生結構化輸出，由您的應用程式進行解析並採取行動。
工具定義的品質至關重要。模型會根據名稱與描述來選擇工具，因此一個名稱為 search_docs 且描述為「根據自然語言查詢在內部知識庫中搜尋相關文件」的工具會被正確使用，而名稱為 sd 且沒有描述的工具則會讓模型感到困惑。參數描述同樣重要 — 如果有 date 參數，請指定預期格式（例如「ISO 8601，如 2025-03-15」），否則模型會自行猜測。在 Claude API 中，您還可以新增 tool_choice 參數，強制模型使用特定工具、讓其自由選擇，或完全禁止使用工具。OpenAI 的 API 也有類似的控制機制。正確設定這些定義，往往是工具使用整合能否穩定運作與是否在邊界案例中失效的關鍵差異。
平行工具呼叫是個容易被忽略但對效能影響重大的功能。當模型需要從多個來源收集資訊 — 例如檢查三個城市的天氣 — 它可以在單一回應中產生多個工具呼叫。您的應用程式會同時執行這些呼叫，並一次性回傳所有結果。Claude、GPT-4 和 Gemini 都支援此功能。另一種方式（順序呼叫，每次往返一次）會增加延遲，且延遲會快速累積。如果您正在建立工具使用整合，請從一開始就設計執行層以處理工具呼叫陣列。
常見的陷阱是工具使用並非確定性行為。相同的提示與工具組合，可能會導致模型呼叫不同工具、傳遞不同參數，甚至完全不使用工具。這對測試與可靠性至關重要。生產系統通常會在工具呼叫輸出中加入驗證邏輯 — 檢查必要參數是否存在、值是否在預期範圍內、函數名稱是否與已知工具匹配。有些團隊會加入重試機制：如果模型產生格式錯誤的工具呼叫，錯誤會以工具結果形式回傳，並給予模型再次嘗試的機會。這種「自我修正」模式在實務中效果驚人，且成本遠低於試圖在事前預防所有錯誤。
AI 模型中工具使用的歷史意外地短暫。OpenAI 於 2023 年 6 月在 GPT-3.5 和 GPT-4 中引入「函數呼叫」功能，這立即改變了可實現的應用範圍。在此之前，開發者會透過提示工程讓模型輸出特定格式的 JSON，再用脆弱的正則表達式解析 — 虽然有效，但極不穩定。Anthropic 於 2024 年為 Claude 引入工具使用功能，隨後 Google 為 Gemini 做了相同處理。API 的設計逐漸趨於一致：您以 JSON 結構定義工具，模型輸出結構化呼叫，您負責執行。2024 年底引入的 MCP 則在這套機制之上新增了標準化的發現與傳輸層，使工具能跨應用程式共用，而無需為每個應用程式重新定義。