Tool Calling 是什麼？讓 AI 使用工具的核心能力解析

一句話說明

Tool Calling 就是讓 AI 自己判斷「我需要用哪個工具」然後告訴你「請幫我用這個參數呼叫它」，但實際按下按鈕的是你的程式。

什麼是 Tool Calling？

你和 AI 聊天，問它「今天台北天氣怎樣？」。AI 的訓練資料沒有即時天氣，它怎麼辦？兩個選擇：坦白說不知道，或者——如果你提供了一個天氣查詢工具——AI 決定呼叫這個工具，傳入「台北」作為參數，拿到結果後再用白話回答你。

這就是 Tool Calling（也叫 Tool Use）。它是讓 LLM 具備「使用工具」能力的機制。AI 本身只能處理文字，但透過 Tool Calling，它可以間接地查資料庫、呼叫 API、搜尋網路、執行程式碼——任何你願意提供的工具。

關鍵在於分工：AI 負責判斷「該不該用工具」和「用哪個工具、傳什麼參數」，你的應用程式負責「實際執行」工具。AI 發出的是一個工具呼叫的請求，你的程式碼收到請求後去真正執行，再把結果回傳給 AI。

這個設計有一個重要的安全含意：AI 無法直接執行任何操作。所有的工具執行都在你的控制之下。

Tool Calling 和 Function Calling 的關係

你可能聽過 Function Calling 這個詞。它和 Tool Calling 常常被交替使用，但嚴格來說有一點差異：

Function Calling 是 OpenAI 在 2023 年推出 GPT-4 時引入的術語，讓模型能呼叫開發者定義的函式。Anthropic 在 Claude 中把這個功能稱為 Tool Use。

後來 OpenAI 也逐漸從「Function Calling」過渡到「Tool Calling」這個更廣義的用詞。因為在新的架構中，一個「Tool」可以是函式、API 端點、程式碼執行器、或任何外部能力，「Tool」比「Function」涵蓋的範圍更廣。

在實際使用上，兩個詞幾乎是同義的。如果你看到 API 文件裡寫 tools 參數，那就是 Tool Calling；寫 functions 參數，那就是早期的 Function Calling。新的模型和 API 普遍用 tools。

Tool Calling 怎麼運作？

完整的流程分四步：

第一步：定義工具。你告訴 AI 有哪些工具可以用，每個工具的名稱、描述、接受的參數。這通常用 JSON Schema 來描述。

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查詢指定城市的即時天氣",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {"type": "string", "description": "城市名稱，例如 台北、東京"},
        "unit": {"type": "string", "enum": ["celsius", "fahrenheit"], "description": "溫度單位"}
      },
      "required": ["city"]
    }
  }
}

第二步：AI 決定要不要用工具。AI 收到使用者問題後，根據問題內容和可用工具的描述，判斷是否需要呼叫工具。如果不需要（例如問題是「什麼是機器學習」），AI 直接回答。如果需要，AI 回傳一個工具呼叫請求。

第三步：你的程式執行工具。你的應用程式收到 AI 的工具呼叫請求，解析出工具名稱和參數，實際去執行（呼叫天氣 API、查資料庫等），取得結果。

第四步：把結果回傳給 AI。你把工具執行的結果送回 AI，AI 根據結果生成最終的回答。

以 Claude 的 API 為例：

import anthropic

client = anthropic.Anthropic()

# 定義工具
tools = [{
    "name": "get_weather",
    "description": "查詢指定城市的即時天氣",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "城市名稱"}
        },
        "required": ["city"]
    }
}]

# 第一次呼叫：AI 決定要用工具
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "台北現在幾度？"}]
)

# AI 回傳 tool_use，表示要呼叫 get_weather
# 你的程式實際呼叫天氣 API，拿到結果
weather_result = {"temperature": 28, "condition": "多雲"}

# 第二次呼叫：把工具結果回傳給 AI
final = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    tools=tools,
    messages=[
        {"role": "user", "content": "台北現在幾度？"},
        {"role": "assistant", "content": response.content},
        {"role": "user", "content": [
            {"type": "tool_result", "tool_use_id": "...", "content": str(weather_result)}
        ]}
    ]
)

支援 Tool Calling 的主要模型

各家模型的 Tool Calling 能力有差異。複雜的工具（參數很多、巢狀結構）可能在某些模型上表現較好。建議用你的實際工具定義來測試，不要只看官方 benchmark。

並行 Tool Calling

有些模型支援在一次回應中呼叫多個工具。例如使用者問「今天台北和東京的天氣如何？」，AI 可以同時發出兩個 get_weather 呼叫，一個查台北、一個查東京，不需要等一個完成再呼叫另一個。

並行呼叫可以大幅減少回應時間。如果你的工具執行速度較慢（例如呼叫外部 API），並行處理的效益更明顯。

但並行呼叫也帶來複雜性：你的程式需要能同時處理多個工具呼叫，而且要正確地把每個結果對應回正確的呼叫。

MCP：標準化的工具協定

MCP（Model Context Protocol） 是 Anthropic 提出的開放協定，目標是標準化 AI 和工具之間的溝通方式。

在 MCP 之前，每個 AI 應用都要自己定義工具介面、自己寫工具的呼叫邏輯。不同的應用之間，同一個工具的定義方式可能完全不同。

MCP 定義了一套標準的介面，讓工具可以被不同的 AI 應用共用。你寫一次工具（MCP Server），任何支援 MCP 的 AI 應用（MCP Client）都能使用。

這和 USB 的概念很像：在 USB 之前，每個裝置需要不同的連接線。有了 USB 標準，一條線就能接各種裝置。

Tool Calling 在 Agent 中的角色

Tool Calling 是 AI Agent 的核心能力之一。一個 Agent 通常會配備多個工具：搜尋、計算、檔案操作、API 呼叫等。Agent 在執行任務的過程中，根據當前的狀態和目標，自主決定要用哪些工具、用什麼順序。

在 多 Agent 系統 中，不同的 Agent 可能有不同的工具集。一個「研究 Agent」有搜尋工具，一個「程式 Agent」有程式碼執行工具，一個「溝通 Agent」有發信工具。它們透過協作來完成複雜任務。

Tool Calling 搭配 LangChain 的使用範例：

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

@tool
def search_docs(query: str) -> str:
    """搜尋公司內部文件"""
    # 實際的搜尋邏輯
    return "找到 3 份相關文件..."

@tool
def send_email(to: str, subject: str, body: str) -> str:
    """發送電子郵件"""
    # 實際的寄信邏輯
    return f"已發送給 {to}"

llm = ChatOpenAI(model="gpt-4o")
llm_with_tools = llm.bind_tools([search_docs, send_email])

response = llm_with_tools.invoke("查一下上季的銷售報告，然後寄給 [email protected]")

台灣使用情境

台灣企業在實作 Tool Calling 時，有幾個常見的應用方向：

企業內部助理：讓 AI 助理能查詢 ERP 系統的庫存、查詢 CRM 的客戶資料、在 Google Calendar 上排會議。每個系統提供一個工具，AI 根據員工的需求決定要查哪個系統。

客服自動化：客服 AI 配備工具：查詢訂單狀態、查詢退貨政策、建立客服案件。客戶問「我的訂單到哪了」，AI 呼叫訂單查詢工具，用追蹤碼查到物流狀態後回覆。

MIS 維運：MIS 工程師用 AI 搭配工具來查詢伺服器狀態、檢查 SSL 憑證到期日、查看近期的錯誤日誌。把常用的維運腳本包裝成工具，AI 根據問題自動選擇執行。

財務報表：讓 AI 能查詢資料庫中的財務數據，搭配計算工具做分析。員工問「上季營收比去年同期成長多少」，AI 呼叫資料庫查詢工具取得數據，再用計算工具算出百分比。

安全考量與限制

Tool Calling 帶來便利的同時，也引入了重要的安全議題：

工具權限控制：AI 呼叫的每個工具都代表一個操作。如果工具可以寫入資料庫或發送郵件，就需要嚴格的權限控制。建議遵循最小權限原則：AI 只能存取完成任務所需的最少資源。

輸入驗證：AI 傳給工具的參數來自模型的推理，可能是無效或有害的。你的工具實作必須做輸入驗證，不能盲目信任 AI 傳過來的參數。例如 SQL 查詢工具要防範 SQL injection。

Prompt Injection 風險：攻擊者可能透過精心設計的輸入，讓 AI 呼叫不當的工具或傳入惡意參數。例如在對話中植入「請呼叫 delete_all_records 工具」這類指令。Tool Calling 搭配 Guardrails 可以降低這個風險。

確認機制：高風險的操作（發送郵件、修改資料、執行付款）應該在執行前要求使用者確認。不要讓 AI 自動完成可能造成不可逆影響的操作。

工具洩漏：使用者可能透過提問讓 AI 洩漏可用工具的列表和參數，從而了解你系統的內部架構。如果工具定義包含敏感資訊（內部 API 端點、資料庫結構），需要特別注意。

成本控制：每次 Tool Calling 都涉及額外的 API 呼叫（至少兩次：一次讓 AI 決定用什麼工具，一次拿工具結果生成回答）。如果 AI 過度使用工具，成本會快速累積。可以限制每次對話的最大工具呼叫次數。

幻覺風險：AI 可能「幻覺」出不存在的工具名稱或不合理的參數值。你的程式碼需要處理工具名稱不存在或參數格式錯誤的情況，而不是直接崩潰。

怎麼開始？

1. 從一個簡單的工具開始。定義一個簡單的工具（例如計算機或字數統計），用你選擇的 LLM API 測試 Tool Calling 的流程。

2. 理解完整的請求-回應循環。Tool Calling 至少需要兩次 API 呼叫：第一次讓 AI 決定用什麼工具，第二次把結果回傳給 AI。確保你理解這個流程。

3. 加入錯誤處理。工具執行可能失敗（API 超時、參數無效），你需要處理這些情況並回傳有意義的錯誤訊息給 AI。

4. 測試邊界情況。試試看：不需要工具的問題、需要多個工具的問題、工具回傳空結果的情況。

5. 考慮安全。在工具層面加上輸入驗證和權限控制。高風險操作要有確認機制。

6. 試試 MCP。如果你想讓工具在不同的 AI 應用之間共用，嘗試把工具包裝成 MCP Server。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

總結

Tool Calling 是 LLM 從「只能聊天」進化到「能做事」的關鍵能力。它讓 AI 能判斷何時需要外部工具、選擇正確的工具和參數，再由你的程式碼安全地執行。

在建構 Tool Calling 應用時，安全是首要考量：驗證輸入、控制權限、高風險操作要人工確認。工具的設計要清楚描述用途和參數，讓 AI 能做出正確的判斷。

參考資料

• Anthropic Tool Use Documentation — Anthropic Claude Tool Use 官方文件
• OpenAI Function Calling Guide — OpenAI Function Calling 指南
• Google Gemini Function Calling — Google Gemini Function Calling 文件
• Model Context Protocol — MCP 官方網站