給模型一雙手：工具與函式呼叫

握手：模型如何呼叫一個函式

語言模型只能產生文字——那它怎麼「呼叫」程式碼？訣竅是一份合約。你把每個可用工具用結構化的綱要 (schema) 描述給模型（名稱、用途，以及它接受的參數）。當模型想用某個工具時，它不再產生一般散文，而是發出一個結構化的請求，指名工具並填好參數。真正執行函式的是你的程式碼——不是模型——再把結果餵回去。這個模式就是 函式呼叫 (function calling)，是現代 工具使用 (tool use) 的骨幹。

// You give the model this tool definition:
{
  "name": "get_weather",
  "description": "Current forecast for a city at a given time.",
  "parameters": {
    "city": "string",
    "when": "string (ISO time)"
  }
}

// The model, when it decides to use it, emits:
{ "call": "get_weather", "args": { "city": "Taipei", "when": "2026-06-26T15:00" } }

// YOUR code runs get_weather(...) and returns the JSON result to the model.

函式呼叫的合約：你宣告工具；模型請求其一；你的執行環境去執行它。

選對工具——並把參數填對

給模型十個工具，就冒出兩件工作：挑對的那個，並忠實填好它的參數。挑選就是 工具選擇 (tool selection)，它主要是個提示問題——清楚、不重疊的工具描述讓選擇變簡單；模糊或近乎重複的工具則讓模型猶豫或選錯。許多正式環境會把輸出限制成固定形狀（常透過 JSON schema）來強迫參數合法，這樣模型就無法發出殘缺的呼叫。

把工具集保持精簡且彼此正交——每個工具只做一件明顯不同的事。
為模型寫描述，而不是為其他工程師：說清楚何時該用、何時不該用。
執行前先驗證參數；遇到錯誤的呼叫，回傳清楚的錯誤訊息，讓模型能自我修正。
記錄每一次呼叫與結果——你會需要這份軌跡來除錯，搞清楚代理為何那樣做。

入門工具箱

有三個工具出現得太頻繁，幾乎成了預設配備。程式碼直譯器 (code interpreter) 讓模型在沙箱裡寫並執行程式碼——對數學、資料處理，以及任何「跑一遍勝過用猜」的事都極好。網頁瀏覽 (web browsing) 工具讓它抓取即時頁面、搜尋開放網路，正是治療過時知識截止 (knowledge cutoff) 的藥。而 電腦操作 (computer use) 走得最遠：模型看著螢幕、控制滑鼠與鍵盤，去操作那些根本沒有 API 的普通軟體。

注意這道「能力與風險」的階梯。程式碼直譯器有沙箱、相當受控。網頁瀏覽伸進即時網際網路，那裡的頁面可能夾帶惡意指令。電腦操作則可以碰機器上的任何東西。觸及範圍越大，能力越強、能造成傷害的途徑也越多——這正是後面的指南要花真功夫在復原與人類監督上的原因。

用一套協定把它們全插上

如果每個團隊都發明自己一套暴露工具的方式，每個代理都得手工接線。模型上下文協定 (Model Context Protocol，MCP) 是個解決此事的開放標準：工具提供方跑一個 MCP *伺服器 (server)，用統一的形狀公告它的工具、資源與提示，而任何懂 MCP 的代理（即客戶端 (client)*）都能發現並呼叫它們，不需要客製的黏合程式。把一個工具寫成一次 MCP 伺服器，任何相容的代理都能用。