工具調用微調：如何用小型模型構建可靠的 AI 代理

AI 代理在 2026 年無處不在。每個自動化平台、每個無代碼構建器、每個工作流程工具都有「AI 代理」功能。它們幾乎都以相同的方式工作：將用戶的消息發送給 GPT-4，詢問它應該調用哪個工具，解析結構化響應，執行工具。

問題：這種模式昂貴、在邊緣情況下不可靠，並且完全依賴雲 API。

解決方案：針對你的特定工具 schema 微調小型模型。你得到更可靠的工具選擇、一致的結構化輸出，以及每次查詢零成本。

工具調用實際需要什麼

當 AI 代理「調用工具」時，以下是模型實際執行的操作：

1. 接收用戶消息 + 可用工具列表（及其 schema）
2. 決定要調用哪個工具（如果有的話）
3. 生成函數名稱和結構化參數（JSON）
4. 以特定格式返回工具調用

第 2 步和第 3 步是模型的貢獻。第 2 步是分類（哪個工具匹配用戶意圖？）。第 3 步是結構化輸出生成（生成匹配 schema 的有效 JSON）。

這兩者都不需要前沿模型的智能。分類是模式匹配。結構化輸出是模板跟隨。這些正是微調小型模型匹配或超越 GPT-4 的任務。

為什麼通用模型在工具調用上失敗

使用 GPT-4 或通用開源模型進行工具調用大多數時候是有效的。但失敗模式是特定且令人沮喪的：

幻覺函數名稱

模型創造了你的 schema 中不存在的工具名稱。「search_database」而不是「query_db」。「send_notification」而不是「notify_user」。接近到足以讓人理解，但錯誤到足以使你的管道崩潰。

錯誤的參數類型

schema 說 user_id 是整數。模型返回 "user_id": "42"（字符串）。你的下游 API 拒絕它。代理靜默失敗或在循環中重試。

不必要的工具調用

用戶提出一個不需要任何工具的簡單問題。模型無論如何都調用工具——因為它被告知工具可用，它試圖提供幫助。現在你有了一個浪費的 API 調用和更慢的響應。

格式不一致

不同的 API 調用產生不同的 JSON 結構。有時模型將響應包裹在 markdown 代碼塊中。有時它在 JSON 周圍添加解釋性文字。有時鍵的順序改變。每個不一致都是一個解析邊緣案例。

規模成本

每個工具調用決策都需要花錢。GPT-4o 工具調用：每百萬 token $2.50-$10。對於每天處理 10,000 次決策的代理，僅「路由」步驟就花費 $75-$300/月——在任何實際工作完成之前。

微調如何修復這個問題

微調教會模型你的特定工具、你的特定 schema 和你的特定調用模式。結果：

準確率提升來自特異性。通用模型處理數千種可能的工具 schema。你的微調模型處理你的 5-20 個工具。它不需要泛化——它需要對你的特定工具每次都是正確的。

工具調用微調的資料集格式

訓練資料遵循對話格式，工具調用作為特殊消息類型。以下是結構：

範例 1：簡單工具調用

{
  "messages": [
    {
      "role": "system",
      "content": "你是一個可以訪問以下工具的助手：\n\n- get_order_status(order_id: string)：返回訂單的當前狀態\n- search_products(query: string, category?: string)：搜索產品目錄\n- create_support_ticket(subject: string, description: string, priority: 'low' | 'medium' | 'high')：創建支援票"
    },
    {
      "role": "user",
      "content": "我的訂單 #ORD-2847 的狀態是什麼？"
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "function": {
            "name": "get_order_status",
            "arguments": "{\"order_id\": \"ORD-2847\"}"
          }
        }
      ]
    },
    {
      "role": "tool",
      "content": "{\"status\": \"shipped\", \"tracking\": \"1Z999AA10123456784\", \"eta\": \"2026-02-24\"}"
    },
    {
      "role": "assistant",
      "content": "你的訂單 #ORD-2847 已發貨！追蹤號碼是 1Z999AA10123456784，預計送達日期是 2026 年 2 月 24 日。"
    }
  ]
}

範例 2：不需要工具

{
  "messages": [
    {
      "role": "system",
      "content": "你是一個可以訪問以下工具的助手：[相同工具]"
    },
    {
      "role": "user",
      "content": "你們的退貨政策是什麼？"
    },
    {
      "role": "assistant",
      "content": "我們的退貨政策允許在購買後 30 天內退貨全額退款。物品必須保持原始狀態。你想讓我幫你開始退貨流程嗎？"
    }
  ]
}

包含模型不應該調用工具的範例至關重要。如果沒有這些，模型就會學會總是調用某些東西。

範例 3：多工具調用

{
  "messages": [
    {
      "role": "system",
      "content": "你是一個可以訪問以下工具的助手：[相同工具]"
    },
    {
      "role": "user",
      "content": "我在訂單 #ORD-2847 中收到了錯誤的商品。我需要提交投訴。"
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "function": {
            "name": "get_order_status",
            "arguments": "{\"order_id\": \"ORD-2847\"}"
          }
        },
        {
          "function": {
            "name": "create_support_ticket",
            "arguments": "{\"subject\": \"收到錯誤商品 - ORD-2847\", \"description\": \"客戶報告在訂單 ORD-2847 中收到了錯誤的商品。\", \"priority\": \"high\"}"
          }
        }
      ]
    }
  ]
}

構建訓練資料集

第一步：定義你的工具 Schema

列出你的代理可以調用的每個工具。對於每個工具，定義：

• 函數名稱（與你的代碼期望的完全一致）
• 參數（名稱、類型、必填/可選）
• 返回類型
• 何時使用它（自然語言描述）

從小開始。5-10 個工具是第一次微調運行的最佳點。你以後可以擴展。

第二步：生成訓練範例

對於每個工具，創建 20-40 個涵蓋以下方面的範例：

• 明確的調用： 用戶意圖明顯映射到一個工具
• 模糊案例： 用戶意圖可以映射到多個工具（在你偏好的路由上訓練模型）
• 無工具案例： 模型應該直接回答而不調用任何工具的問題
• 多工具案例： 需要順序或並行工具調用的場景
• 邊緣案例： 不尋常的措辭、缺失信息（模型應該請求澄清）、無效請求

對於 5-10 個工具的代理，200-500 個總範例通常就足夠了。品質比數量更重要。

第三步：格式化為 JSONL

將你的範例轉換為上面顯示的對話格式，每行一個 JSON 對象。這是在 Ertas 上微調和大多數其他平台的標準格式。

第四步：微調

將 JSONL 資料集上傳到 Ertas，選擇基礎模型（Llama 3.1 8B Instruct 或 Qwen 2.5 7B Instruct 是不錯的選擇——使用 Instruct 變體，而不是 Base），配置訓練並運行。

特別使用 Instruct 變體，因為工具調用需要將結構化輸出與自然語言響應混合。Base 模型難以處理這種組合。

第五步：評估

針對 50-100 個範例的保留集進行測試。測量：

• 工具選擇準確率： 它選擇了正確的工具嗎？
• 參數正確性： 所有參數是否存在、類型正確、值正確？
• 無調用準確率： 當不需要工具時，它是否正確避免調用工具？
• 格式合規性： 每次輸出是否都是有效且可解析的 JSON？

部署你的工具調用模型

使用 Ollama 進行本地推理

將你的微調模型匯出為 GGUF，導入到 Ollama，並通過其 API 提供服務。Ollama 的 OpenAI 相容端點意味著你現有的代理框架（LangChain、CrewAI 等）只需更改一行 URL 就可以工作。

與 n8n 整合

對於 n8n 工作流程，將 OpenAI 節點替換為指向你的微調模型的 Ollama 節點。工作流程邏輯保持不變——只有模型端點改變。API 成本從每月幾百美元降至零。

與 Make.com 整合

對於 Make.com 自動化，使用 HTTP 模塊調用你的 Ollama API 端點。模型以 JSON 格式返回工具調用，Make.com 可以解析並路由到後續模塊。

何時你仍然需要 GPT-4 進行工具調用

微調小型模型在帶有定義明確模式的固定工具 schema 上表現出色。它們不是每個場景的正確選擇：

• 動態工具發現： 如果可用工具因會話而改變（插件系統、用戶配置的操作），通用模型的靈活性是有價值的
• 複雜的多步驟推理： 如果工具選擇需要多跳推理，較大的模型更好地處理規劃
• 非常大的工具集（50 個以上）： 超過 50 個工具時，分類問題變得更難
• 沒有訓練資料的新工具： 如果你頻繁添加工具且無法每次重新訓練，通用模型的零樣本能力有助於彌補差距

對於大多數帶有 5-20 個定義明確工具的生產代理，微調的 8B 模型是更好的選擇——更可靠、更快、成本無限便宜。

開始

1. 列出你的代理工具及其 schema
2. 創建 200-500 個訓練範例（包括無工具和邊緣案例）
3. 格式化為 JSONL
4. 在 Ertas 上微調——選擇 Llama 3.1 8B Instruct 或 Qwen 2.5 7B Instruct
5. 在保留範例上評估
6. 通過 Ollama 部署並連接到你的自動化平台
7. 在生產中監控準確率，並定期用新範例重新訓練

你的 AI 代理的大腦不需要花費每百萬 token $10。一次微調，本地運行，永遠不再為工具路由付費。

---

參考資料：Weights & Biases — Fine-tuning LLMs for Function Calling、Hugging Face — Function Calling Fine-Tuning with xLAM、Parlance Labs — Fine-Tuning for Function Calling。