什麼是 tool use(function calling)?LLM 怎麼伸出手做事

Tool use(又稱 function calling)是把 LLM 從「會聊天的 bot」變成「會做事的 bot」的機制。你描述一個函式 — 名字、參數、回傳什麼 — 模型決定何時呼叫它。Provider 的 API 負責協調:模型挑工具、你執行、回傳結果、模型繼續。2026 年幾乎所有 agent 都是「tool-use 迴圈 + 加料」。

基本機制

你用 JSON schema 定義一個工具:

{
  "name": "get_weather",
  "description": "取得某城市的目前天氣",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "例如 Taipei" }
    },
    "required": ["city"]
  }
}

你把這份工具清單跟 prompt 一起送進去。模型看到就可能決定要呼叫。它呼叫時,不是回純文字,而是回一個結構化 tool-use block:「呼叫 get_weather,參數 {city: "Taipei"}」。你的 code:

接到 tool-use request。
實際呼叫 getWeather("Taipei") — 打真的天氣 API。
把結果送回給模型。
模型帶著天氣資料繼續對話。

這個迴圈能跑很多輪。新版 Claude、GPT-5、Gemini 都支援 parallel tool use(一次呼叫多個工具)跟 multi-turn tool use(呼叫 → 回應 → 再呼叫)。

什麼樣才是好工具設計

工具品質就是 agent 品質的大部分。三個原則:

清楚、窄的名字。search_web 贏 do_research。模型挑名字 + 描述跟情境匹配的工具,模糊名字導致挑錯。

**詳細的描述。**描述是 prompt 的一部分。要具體:「回傳 Google 搜尋結果前 10 筆。當 user 問時事或訓練資料以外的事實時用。Code 查詢不要用這個 — 用 search_docs。」

**緊湊、可驗證的輸入 schema。**指定型別,可以的話用 enum(status: 'open' | 'closed')、required vs optional。進來時就驗證 — 模型傳垃圾就回一個 guide 它下一輪修正的錯誤訊息。

**模型實際能用的輸出。**模型要拿來推理的,回結構化資料(JSON)。要被讀出來的,回短文字片段。不要 dump 5 萬 tokens 的 HTML。

LLM 實際會呼叫什麼

真實 agent 會出現的工具類別:

資訊取得 — search_web、fetch_url、query_database、vector_search。
計算 — run_python_code、calculate、parse_csv。Sandboxed code 執行對數學/資料任務很關鍵。
對外動作 — send_email、create_calendar_event、post_message。寫入動作要特別小心。
系統互動 — read_file、write_file、run_shell_command。寫 code 的 agent 的基礎。
領域 API — lookup_customer、create_invoice、update_ticket。你的 business logic。

Anthropic 的 computer use 模式加上 take_screenshot、move_mouse、click、type — 把整個 OS 變成工具。

Tool use 怎麼改變 prompt

有工具可用之後,prompt 從「回答這個」變成「想辦法用這些工具回答這個」。給模型對的工具,它明顯變得更有用,因為它不再幻覺出本來可以查的東西。

強力 pattern:always-on retrieval。給模型一個 search_knowledge_base 工具。Prompt 它「user 問跟我們領域有關的東西時就用這個工具」。模型自己決定何時要 retrieve — 不必硬編 pipeline。

另一個 pattern:特化 sub-agent 包成工具。把另一個 LLM 呼叫(不同模型、不同 prompt、不同工具)包成單一「工具」給父 agent 呼。便宜模型做窄任務、前沿模型做編排。

什麼時候不要加工具

**One-shot 任務。**單次 LLM 呼叫就能解 user 的問題(「總結這段」),工具只是多延遲。
**執行不可靠的工具。**模型會呼叫壞掉的工具、拿到錯、重試、失敗。UX 很差。先修工具。
**模型分不清的工具。**三個近似工具配模糊描述,模型一定挑錯。整併。
**隱藏副作用。**會刪東西、發訊息、移動錢的工具,不能沒有迴圈內明確確認就暴露給模型。包一層權限步驟。

要注意的失敗模式

Production 三個常見:

**Tool-call 無窮迴圈。**模型反覆呼叫同一個工具,因為結果不滿意或不知道還能試什麼。解:步數上限、最近呼叫去重、給模型一條明確「放棄」路徑。

**幻覺工具呼叫。**模型發明一個不存在的工具。新版 API 會驗證並拒絕,舊 code 可能默默亂跑。Server-side 驗證工具名。

**參數錯。**模型傳型別正確但內容錯的資料:city: "使用者選的城市"。嚴格描述跟驗證能抓到,把錯誤訊息送回模型,通常下一輪就修。

跟 MCP 的關係

MCP(Model Context Protocol)是「跨 AI client 暴露工具」的標準方式。MCP server 定義工具的方式跟你在自家 app 定義一樣,但用標準協議讓任何支援 MCP 的 client 都能用。Tool use 是底層能力,MCP 是上面的互通層。