工具呼叫 Tool Calling
既然你已了解脈絡如何運作，接下來看看 AI 模型如何不只產生文字。它們其實可以透過工具呼叫動態地執行動作並擷取資訊。
還記得我們把 AI 模型比作 API 端點嗎？工具呼叫就像讓這些模型能自行呼叫「其他」API，就彷彿 AI 模型能學會新技能。
用個比喻：想像你在電話裡幫朋友做晚餐。你可以根據已知給他們指示，但你看不到他們冰箱裡有什麼，也無法品嚐他們做的食物。
現在想像你的朋友傳來冰箱內容的照片，或告訴你烤箱的精確溫度。突然間，你就能提供更好的建議，因為你能取得即時資訊。這本質上就是工具呼叫為 AI 模型帶來的能力。
工具呼叫的運作方式#
當開發者建立 AI 應用程式時，可以定義 AI 模型可使用的特定「工具」。這些工具就像特殊能力，讓模型的能力不只侷限於思考並以文字回應。
你很可能已經在不知不覺中用過工具呼叫！當你請 ChatGPT 產生圖片、搜尋網路或執行程式碼時，它其實是在背後使用工具。
以下是底層的運作流程：
- AI 模型接收你的請求，並辨識到需要額外的能力
- 它會以 JSON（結構化資料格式）格式化一個特殊回應，指定要使用的工具以及要傳遞的參數
- 應用程式執行該工具並回傳結果
- AI 模型將這些結果納入其上下文，並持續進行對話
為什麼工具對寫程式很重要#
在開發軟體時，工具非常強大，因為它們讓 AI 模型能夠：
- 在你的程式碼庫中讀寫檔案
- 搜尋程式碼，找出相關的函式或模式
- 執行 shell 指令，用來測試程式碼或安裝套件
- 存取說明文件，或在網路上搜尋最新資訊
- 透過執行 linter 或測試來檢查錯誤
沒有工具時，AI 模型只能依賴你在脈絡中明確提供的資訊；有了工具，它可以主動探索並與你的程式碼庫互動。
工具呼叫包含哪些內容？#
每個工具都有三個主要組成部分：
- 名稱，例如
read_file或search_web - 描述，說明模型應在何時與如何使用該工具
- 參數，即工具運作所需的輸入
以下是一個可能的工具定義範例：
{
"name": "read_file",
"description": "從程式碼庫讀取檔案內容",
"parameters": {
"filepath": "要讀取的檔案路徑"
}
}當 AI 模型要使用此工具時，會產生如下回應：
{
"tool": "read_file",
"parameters": {
"filepath": "src/components/Button.tsx"
}
}應用程式接著讀取該檔案，並將其內容加入對話脈絡，讓模型理解你的 Button 元件並提出相關的修改建議。
哪些是工具定義的核心部分？
- 名稱
- 描述
- 參數綱要
- 供應商 API 金鑰
工具成本#
還記得我們談過的 token 與定價嗎？工具呼叫會透過兩種方式消耗 token：
- 工具定義 會被包含在輸入脈絡中（通常每個工具數百個 token）
- 工具結果 會被加入至輸出脈絡中（視工具回傳內容而定）
這代表大量使用工具的對話會更快填滿脈絡視窗，並且成本更高。但這樣的取捨通常值得，因為 AI 在能存取即時資訊時會更有幫助。
當發生工具呼叫時，AI 模型會重新評估直至該次呼叫為止的脈絡。在像 Cursor 這樣的工具中，這表示你會看到更多快取的輸入 token 使用量，因為我們會將脈絡重新傳回模型。
工具呼叫會以哪兩種方式影響 token 使用量？
- 工具定義會增加輸入 token
- 工具結果會增加輸出 token
- 工具一旦定義後，呼叫就是免費的
- 串流會消除 token 成本
超越內建工具#
最近出現了一個名為 MCP（Model Context Protocol，模型上下文協議）的新標準。可以把它想成一種讓 AI 模型在各種應用中使用並整合工具的通用方式。
就像 USB 成為連接裝置與電腦的標準一樣，MCP 旨在成為連接工具與 AI 模型的標準。這表示開發者可以一次打造工具，讓它能在許多不同的 AI 應用中運作。
例如，你可以使用 MCP 連接 Figma 以存取設計檔、連接 Linear 以檢視與管理 Issue，或甚至連接資料庫直接查詢你的資料。你也可以建立自己的 MCP 伺服器，與內部工具與 API 整合。
現在你已了解工具呼叫，接著看看當我們讓 AI 模型依序使用多個工具時會發生什麼事。這就是 agents 開始發揮作用、變得有趣的地方。