為企業 AI 代理準備工具呼叫資料集：本地工作流程

大多數企業 AI 代理專案在同一個節點停滯：代理可以進行對話，但無法在正確的時間以正確的參數可靠地呼叫正確的內部工具。根本原因幾乎總是相同的——模型從未在反映組織實際工具的工具呼叫資料上訓練。

單靠提示工程無法解決這個問題。您可以在系統提示中塞滿函式定義和少量示例，但一旦有 40 個以上功能重疊的內部工具，基於提示的方法就會達到上限。模型會混淆相似的工具、產生幻覺參數，或不管上下文都預設使用最常見的工具。

解決方法很直接：在特定於您環境的工具呼叫資料上微調模型。挑戰在於，這些資料不存在，直到您創建它——對企業而言，創建過程必須完全在本地進行，因為工具定義本身是敏感的。

為何代理需要工具呼叫訓練資料

AI 代理選擇和呼叫工具的能力是習得的行為，而非自發的。基礎模型甚至指令調整的模型都具備通用的工具呼叫能力，但這些能力是在公開的 API 模式上訓練的——天氣 API、搜尋引擎、計算器函式等。企業工具與此完全不同。

典型的企業擁有用於 CRM 資料查詢、ERP 交易、文件管理、合規檢查、審批工作流程以及數十個領域專屬操作的內部 API。每個工具都有特定的參數格式、必要的驗證上下文，以及關於何時應該或不應該呼叫的業務規則。

當您在企業專屬工具呼叫樣本上微調時，三件事會得到可測量的改善。首先，工具選擇準確率從 60–70%（僅提示）躍升至 90–95%（微調後）。其次，參數格式化錯誤減少 80% 以上，因為模型學習了確切的模式。第三，模型學習了負面樣本——何時不呼叫工具——這減少了不必要的 API 呼叫及相關成本。

工具呼叫資料集格式

無論您在微調哪個模型系列，每個工具呼叫訓練樣本都具有相同的結構。格式由五個組件組成：

系統提示：定義代理的角色和通用指令。在所有樣本中保持一致。

函式定義：可用工具的 JSON 模式描述——名稱、描述、參數（含類型和限制），以及必填欄位。

用戶查詢：應觸發特定工具呼叫的自然語言請求。

預期函式呼叫：模型應選擇的工具名稱。

預期參數：模型應傳遞給工具的確切 JSON 參數。

一個實際的訓練樣本如下：

{
  "messages": [
    {
      "role": "system",
      "content": "You are an enterprise assistant with access to internal tools."
    },
    {
      "role": "user",
      "content": "Pull the Q3 revenue numbers for the EMEA region."
    }
  ],
  "tools": [
    {
      "name": "query_financial_report",
      "description": "Retrieves financial metrics by quarter, region, and metric type.",
      "parameters": {
        "quarter": "string (Q1-Q4)",
        "year": "integer",
        "region": "string",
        "metric": "string"
      }
    }
  ],
  "expected_call": {
    "name": "query_financial_report",
    "arguments": {
      "quarter": "Q3",
      "year": 2026,
      "region": "EMEA",
      "metric": "revenue"
    }
  }
}

每個工具需要 50–200 個樣本才能進行可靠的微調。對於擁有 30 個工具的系統，這意味著共需 1,500–6,000 個樣本。聽起來很多，但準備管線使其變得可管理。

常見源文件

企業工具呼叫資料集是從大多數組織中已存在的文件建立的：

API 文件：OpenAPI/Swagger 規格是最豐富的來源。它們包含端點定義、參數模式，通常還有示例請求。如果您的內部 API 有規格文件，您已經完成了 40%。

內部 Wiki 和操作手冊：這些包含何時使用哪個工具以及如何使用的自然語言描述。它們是用戶查詢變體的來源——真實用戶描述任務的方式。

工作流程定義：BPMN 圖、Jira 工作流程、審批鏈。這些編碼了工具 A 的輸出成為工具 B 輸入的多步驟工具呼叫序列。

標準操作程序（SOP）：直接對應工具呼叫鏈的逐步指令。「首先在 CRM 中查找客戶。然後檢查其信用狀態。然後創建訂單。」每一步都是一個工具呼叫。

支援票和聊天日誌：觸發手動工具使用的真實用戶查詢。這些是生成真實查詢變體的黃金資源，因為它們捕捉了人們實際表達請求的方式——包括拼寫錯誤、縮寫等。

準備管線

端對端管線有五個階段。每個階段都可以在本地運行，無外部依賴。

第一階段：從 API 規格提取工具定義

解析 OpenAPI/Swagger 規格以提取函式模式。對每個端點，捕捉名稱、描述、HTTP 方法、路徑參數、查詢參數、請求主體模式和回應模式。將這些轉換為目標模型期望的工具呼叫 JSON 格式。

如果您有 30 個內部 API，平均每個有 8 個端點，此階段產生 240 個原始工具定義。並非所有這些都與您的代理相關——過濾到代理實際應使用的子集。

第二階段：生成用戶查詢變體

對每個工具，創建 50–200 個應觸發它的自然語言查詢。從 Wiki 文件和 SOP 中的查詢開始。然後使用本地 LLM（透過 Ollama 運行的 Llama 3 70B 效果良好）生成變體。

關鍵是多樣性：正式查詢（「查詢帳戶 ID 44891 的客戶帳戶狀態」）、非正式查詢（「帳戶 44891 的狀態是什麼」）、模糊查詢（「檢查那個帳戶」），以及需要參數推斷的查詢（「提取上季度的 EMEA 數字」——模型必須推斷當前年份）。

第三階段：創建預期呼叫/回應對

對每個查詢-工具組合，定義預期的函式呼叫和參數。這是最耗費人力的階段，需要領域專業知識。創建這些樣本的人必須了解正確的工具和正確的參數映射。

這是領域專家發揮價值的地方。一個每天使用這些 API 三年的工程師，一天可以產生 200 個樣本。不熟悉 API 的人會產生錯誤，這些錯誤會傳播到微調後的模型中。

第四階段：驗證和去重

執行自動驗證：參數是否與工具的模式匹配？必填欄位是否存在？枚舉值是否有效？然後檢查重複項——具有相同預期呼叫的類似查詢增加了噪音而沒有增加學習訊號。

也驗證負面樣本：包含不應觸發任何工具呼叫的查詢。「今天天氣怎麼樣？」不應呼叫您的內部 CRM API。模型需要學習克制。

第五階段：匯出為 JSONL

將驗證後的樣本格式化為您的微調框架期望的模式的 JSONL。對大多數開源模型（Llama、Mistral、Qwen），這是帶有工具呼叫擴展的 ChatML 格式。匯出訓練集（80%）和驗證集（20%）。

本地部署要求

工具呼叫資料集是企業生產的最敏感的資料準備製品之一。原因如下。

工具定義本身揭示了內部 API 架構。擁有您工具呼叫資料集的攻擊者知道每個內部端點、每個參數模式，以及工具描述中編碼的每條業務規則。這是組織運營基礎設施的藍圖。

訓練樣本揭示了使用模式——哪些查詢映射到哪些工具、哪些參數常見，以及不同系統如何連接。這是競爭對手或對手會發現有價值的運營情報。

對受監管行業而言，情況更為嚴峻。金融機構的工具呼叫資料集精確揭示了交易如何執行、合規檢查如何進行，以及存在哪些審批工作流程。在大多數框架下，將此資料傳送至雲端 LLM 服務商進行合成增強是違規行為。

整個管線——從 API 規格解析到合成查詢生成到 JSONL 匯出——必須在組織控制的基礎設施上運行。

使用本地 LLM 進行合成增強

查詢生成階段從 LLM 輔助中受益巨大。本地模型每分鐘可以生成 10 個查詢變體，每個措辭都足夠不同以增加訓練價值。

在您的本地 GPU 基礎設施上透過 Ollama 運行一個有能力的模型（Llama 3.3 70B 或 Qwen 2.5 72B）。提供一個工具定義和由領域專家撰寫的 5 個種子查詢，然後要求 50 個變體。審查輸出——預計在品質過濾後保留 70–80%。

增強提示很重要。指定領域、用戶角色（初級分析師、資深交易員、客服代理）和正式程度。這產生了多樣化的查詢，涵蓋組織中不同人群表達請求的範圍。

對於 5,000 個樣本的資料集，合成增強將領域專家的工作量從約 200 小時減少到約 50 小時。專家撰寫種子樣本並審查生成的樣本，而不是從頭撰寫每個樣本。

品質驗證

兩個品質檢查決定您的工具呼叫資料集是否可投入生產。

覆蓋範圍測試：每個工具是否有足夠的樣本？繪製每個工具的樣本分布圖。如果 5 個工具有 200 個以上的樣本，而 10 個工具少於 20 個，模型將偏向代表性好的工具。最低可行覆蓋範圍是每個工具 50 個樣本。

邊緣案例覆蓋範圍：對每個工具，驗證您有涵蓋以下情況的樣本：所有必需的參數組合、可選參數使用、從上下文推斷參數（例如從日期推斷「當前季度」）、需要順序呼叫的多工具查詢，以及類似工具用途但不應觸發它的查詢。

在資料集的 20% 上執行快速驗證微調。如果模型在保留樣本上的工具選擇準確率超過 85%，資料集品質就足夠了。低於 85% 時，尋找系統性錯誤——通常幾個定義不清晰的工具要為大多數錯誤負責。

實際考量

資料集大小：對於 30 個工具的系統，目標是共 3,000–6,000 個樣本。低於 1,500 個，您會在較少常見的工具上看到工具混淆。超過 10,000 個，收益遞減，除非您的工具格外複雜。

更新頻率：內部 API 會改變。預算進行季度資料集更新——新端點、棄用的工具、修改的模式。過時的工具呼叫資料集會產生呼叫不再存在的端點的模型。

多輪序列：真實的代理互動涉及工具呼叫鏈。包含代理呼叫工具 A、處理結果、然後呼叫工具 B 的多輪樣本。這些佔生產使用的 20–30%，在大多數資料集中代表性不足。

錯誤處理：包含正確回應是要求澄清而非猜測參數的樣本。「更新帳戶」太模糊——模型應詢問哪個帳戶以及什麼更新，而不是用假造的參數呼叫 API。

工具呼叫資料集是企業 AI 代理專案中槓桿作用最高的製品。做對了，代理就能工作。做錯了，任何提示工程都無法彌補。

延伸閱讀

• 為微調建立工具呼叫訓練資料集 — 工具呼叫資料集格式和微調工作流程的基礎指南。
• 企業 AI 代理的資料準備 — 企業代理部署的所有資料準備要求的更廣泛視角。
• 為企業建立 AI 代理知識庫 — 如何準備工具呼叫代理查詢的知識層。