作者注：用一個密鑰、一套固定腳本和一次注入失敗，橫向對比多個模型的多輪工具調用能力，得到可復現、可複查的結論。
選模型做 Agent 時，很多團隊都遇到過同一個問題。單輪問答裏各家模型表現差不多，一進入“調用工具 → 拿到結果 → 再調用 → 處理報錯 → 給出結構化答案”的多輪循環，差異就出來了。本文介紹 一個密鑰測多個模型的多輪工具調用小測試，幫你用很低的成本，把這種差異變成可以記錄和複查的數據。
這不是一份模型排行榜。 本文不提供任何未經實測的跑分，只講如何設計測試，讓你在自己的業務場景裏得出結論。測試的關鍵是控制變量：同一個密鑰、同一套工具定義、同一段 Mock 數據，只改變模型名稱。通過 API易 apiyi.com 這類聚合平臺，一個密鑰就能調用 DeepSeek、Gemini、Qwen、Claude、GPT 等多家模型，橫向對比時少了很多切換成本。
核心價值：讀完本文，你能搭出一個 5 步可復現的多輪工具調用測試。它能覆蓋工具選擇、參數校驗、調用 ID 回傳、失敗重試和最終 JSON 校驗這五個關鍵環節。
多輪工具調用小測試核心要點
設計多輪工具調用測試之前，先明確“可復現”指什麼。同一份輸入在不同時間、由不同人運行，應該得到同一類可以比較的結果。單次的漂亮輸出不能作爲結論。下表是整個測試的骨架。
| 要點 | 說明 | 價值 |
|---|---|---|
| 一個密鑰、多個模型 | 所有模型走同一個接口入口，只改 model 字段 | 排除網絡、鑑權、SDK 版本帶來的干擾 |
| 固定 Mock 工具 | 工具返回值寫死，不連真實數據庫或外部服務 | 每次運行看到的工具結果完全一致 |
| 注入一次失敗 | 某個工具第一次調用固定返回可重試錯誤 | 觀察模型能否正確重試，會不會編造數據 |
| 結構化終點 | 最終答案必須是符合 Schema 的 JSON | 可以用程序自動判定通過或失敗 |
| 完整留痕 | 保存請求參數、原始響應、usage 與耗時 | 結論可複查，換模型版本後可以迴歸 |
多輪工具調用測試爲什麼要“小”
測試要小，因爲大測試很難復現。真實業務裏的工具鏈可能有十幾個工具、依賴外部系統，任何一處波動都會被誤認爲是模型的問題。一個好的小測試只需要 2 到 3 個只讀工具，加一次人爲注入的失敗，就能覆蓋多輪循環裏最容易出錯的環節。
測試還要“完整”。它必須跑完整個循環，不能只看模型第一輪會不會發起工具調用。很多模型第一輪表現很好，問題出在第二、三輪：沒有帶上正確的調用 ID，拿到錯誤後直接放棄，或者在沒有數據的情況下自己編一個物流單號。這些問題只有把循環跑到最後一輪才看得出來。
用一個密鑰測多個模型的設計原則
控制變量是對比測試的前提。如果 A 模型用官方 SDK、B 模型用第三方 SDK，C 模型又換了一個代理地址，最後的差異就分不清來自模型還是來自鏈路。統一入口之後，鑑權方式、重試策略、超時設置和日誌格式都保持一致，唯一的變量就是模型本身。
多輪工具調用小測試快速上手
本節不貼代碼，只列出參數、工具定義和執行步驟。你可以用任何熟悉的語言實現，Python、Node.js 或 Shell 腳本都可以。重點是每一項配置都寫進一個固定的配置文件，並隨測試結果一起保存。
第 1 步：統一接口與運行參數
先確定接口入口和採樣參數。API易 同時兼容 OpenAI 與 Anthropic 兩種接口格式，同一個密鑰既可以用 Chat Completions 風格調用，也可以用 Messages 風格調用。下表列出建議固定的配置項。
| 配置項 | 建議值 | 說明 |
|---|---|---|
| base_url（OpenAI 格式） | https://api.apiyi.com/v1 |
通過 API易 統一入口調用，具體地址以 docs.apiyi.com 文檔爲準 |
| base_url（Anthropic 格式） | 參照 API易 文檔中的 Anthropic 兼容地址 | 用於測試 tool_use / tool_result 協議 |
| api_key | 同一個密鑰 | 所有模型共用，排除鑑權差異 |
| temperature | 0 或儘量低 | 降低隨機性；部分推理模型不支持時記錄實際值 |
| max_tokens | 固定值 | 避免因輸出被截斷而誤判 |
| tool_choice | auto | 觀察模型自主決策，不強制調用 |
| 最大循環輪數 | 固定上限，例如 6 輪 | 防止模型陷入無限重試 |
| 每個模型運行次數 | 固定次數，例如 5 次 | 用多次結果判斷穩定性，不看單次表現 |
🚀 快速開始建議：可以先在 API易 apiyi.com 註冊並獲取一個密鑰，用同一個密鑰依次調用候選模型。確認每個模型都能返回正常的工具調用響應後，再開始正式測試。接入說明見 docs.apiyi.com。
第 2 步：定義 2 到 3 個只讀工具
工具設計有兩個要求：只讀、確定。只讀是爲了防止測試中誤觸發寫操作，確定是爲了保證每次返回值相同。推薦用一個虛構的訂單查詢場景，包含兩個工具：
- get_order：參數爲 order_id（字符串，格式固定爲 “ORD-” 加數字）。固定返回訂單狀態、商品名和物流單號 tracking_no。
- get_shipping：參數爲 tracking_no（字符串）。第一次調用固定返回錯誤，錯誤內容包含 error 爲 timeout、retryable 爲 true；第二次及以後返回固定的物流狀態和預計送達日期。
- 可選的干擾工具 get_coupon：與問題無關，用來觀察模型會不會多餘調用。
參數 Schema 要寫嚴格：字段類型、必填項、正則格式都要明確。模型生成的參數要先經過 Schema 校驗再交給 Mock 函數。校驗失敗要記錄爲一次“參數錯誤”，不要悄悄修正。
第 3 步：編寫固定的提示詞與用戶問題
System 提示詞只寫規則，不寫答案。可以要求模型只根據工具返回的數據回答；工具報錯且可重試時最多重試 2 次；最終只輸出一個 JSON 對象，字段包括 order_status、shipping_status、eta 和 data_source。用戶問題固定爲一句話，例如“幫我查一下訂單 ORD-10086 現在到哪了”。
提示詞一旦確定就不再修改。如果測試中發現某個模型因爲提示詞歧義而失敗，正確的做法是新開一個版本號，所有模型用新版本重測，而不是隻給這一個模型改提示詞。
第 4 步：執行循環並注入失敗
執行邏輯按以下順序進行：
- 發送 system 與 user 消息，以及工具定義。
- 如果響應裏有工具調用，依次校驗參數，執行對應 Mock 函數，把結果按協議要求回傳。
- 對 get_shipping 的第一次調用，固定返回可重試錯誤。
- 重複第 2 步，直到模型給出不含工具調用的最終回覆，或達到最大輪數。
- 用 JSON Schema 校驗最終回覆，並保存全部消息、原始響應與每輪 usage。
注入失敗是整個測試最有區分度的部分。理想行爲是模型識別出 retryable 爲 true，用相同參數再調用一次 get_shipping。常見的問題行爲有三種：直接向用戶道歉並結束；編造一個物流狀態；修改參數後反覆重試，直到超出輪數上限。
第 5 步：按清單打分並留痕
每次運行結束後，用程序逐項判定，儘量不靠人工主觀打分。人工只負責複查程序標記爲異常的樣本。
多輪工具調用協議差異：OpenAI 與 Anthropic 格式
同一個測試要在兩種接口格式下都能運行，就要先了解協議細節的差異。協議裏很小的差別也會導致“curl 能通、客戶端不行”這類問題。建議先用最小請求確認協議正確，再開始比較模型能力。
| 環節 | OpenAI 兼容格式 | Anthropic 兼容格式 |
|---|---|---|
| 工具定義 | tools 數組，每項 type 爲 function，參數寫在 parameters | tools 數組，參數 Schema 寫在 input_schema |
| 模型發起調用 | assistant 消息中的 tool_calls，每個帶 id | assistant 內容塊中的 tool_use，每個帶 id |
| 參數形態 | arguments 通常是 JSON 字符串，需要自行解析 | input 直接是 JSON 對象 |
| 回傳結果 | role 爲 tool 的消息，攜帶 tool_call_id | user 消息中的 tool_result 內容塊，攜帶 tool_use_id |
| 標記錯誤 | 一般在結果內容裏自定義錯誤字段 | tool_result 支持 is_error 標記 |
| 並行調用 | 一次響應可能包含多個 tool_calls | 一次響應可能包含多個 tool_use 塊 |
有幾個坑最容易踩。第一，OpenAI 格式下 arguments 是字符串，部分模型偶爾會輸出多餘字符，導致解析失敗。這一項本身就該計入評分，而不是在代碼裏做容錯。第二，回傳結果時 ID 必須和發起調用的 ID 一一對應，並行調用時尤其要注意順序。第三，有的模型會在同一條回覆裏既輸出文本又發起工具調用，處理邏輯要同時兼容這兩種內容。
💡 技術建議：通過 API易 apiyi.com 的統一入口，可以用同一個密鑰分別走 OpenAI 格式和 Anthropic 格式運行同一套測試。這樣能區分問題出在模型本身，還是出在協議適配層。
多輪工具調用評分清單與記錄模板
評分清單是讓結論可復現的關鍵。每一項都要能被程序判定，並且和真實業務風險對應。下表是推薦的檢查項，你可以根據業務增刪。
| 檢查項 | 判定方式 | 對應的業務風險 |
|---|---|---|
| 工具選擇正確 | 第一輪調用 get_order，沒有調用干擾工具 | 多餘調用增加延遲和成本 |
| 參數通過校驗 | 參數滿足 Schema，包括類型、必填和格式 | 錯誤參數會打到真實系統 |
| 調用 ID 正確對應 | 回傳結果與發起調用的 ID 一致 | 多輪上下文錯亂 |
| 重試行爲合理 | 收到可重試錯誤後，用相同參數重試且不超過上限 | 放棄過早或無限重試 |
| 無編造數據 | 最終答案中的字段都能在工具返回值中找到 | 幻覺直接影響用戶 |
| 最終 JSON 合法 | 通過 JSON Schema 校驗，無多餘文本 | 下游解析失敗 |
| 輪數與 Token 用量 | 記錄總輪數、輸入與輸出 Token | 評估成本與延遲 |
每個模型跑完固定次數後，彙總成一張結果表。建議的列包括：模型 ID、接口格式、運行序號、通過項數、失敗項明細、總輪數、輸入 Token、輸出 Token、耗時、測試日期。表頭和配置文件一起放進版本庫。模型升級或換新版本時，用同一套腳本重跑一遍就能做迴歸對比。
多輪工具調用的成本口徑怎麼記
Token 用量要按每輪分別記錄，不能只看最後一輪。多輪循環裏，每一輪都會把之前的消息和工具結果重新作爲輸入發送，所以輸入 Token 會逐輪累加。重試越多，成本越高。這也是“重試行爲合理”這一項值得單獨打分的原因。
計算費用時，用 usage 中的輸入、輸出 Token（如果有緩存命中，還有緩存 Token）分別乘以對應單價。所有模型的輸入單價、輸出單價、緩存價格和計費口徑，都以 API易 價格頁 docs.apiyi.com/models 的實際數據爲準。 本文不列具體數字，因爲價格會調整，寫死在文章裏很容易過時。
一個密鑰測多個模型：候選模型清單
候選模型建議覆蓋不同廠商和不同定位，例如一個高性價比模型、一個主力模型、一個推理較強的模型。下表只列模型系列和測試關注點，不給出結論，結論應該來自你的實測數據。
| 模型系列 | 建議測試的關注點 | 推薦接口格式 | 可用平臺 |
|---|---|---|---|
| DeepSeek 系列 | 參數字符串解析穩定性、注入失敗後的重試 | OpenAI 兼容 | API易 apiyi.com、官方 API |
| Gemini 系列 | 並行調用傾向、最終 JSON 是否夾帶文本 | OpenAI 兼容 | API易 apiyi.com、官方 API |
| Qwen 系列 | 干擾工具的誤調用、多輪 ID 對應 | OpenAI 兼容 | API易 apiyi.com、官方 API |
| Claude 系列 | tool_result 的 is_error 處理、輪數控制 | Anthropic 兼容 | API易 apiyi.com、官方 API |
| GPT 系列 | 嚴格 Schema 遵循、Token 用量 | OpenAI 兼容 | API易 apiyi.com、官方 API |
具體可用的模型 ID 和版本，以 API易 模型列表爲準。記錄結果時一定要寫完整的模型 ID，不要只寫系列名。同一系列的不同版本，在工具調用上的表現可能差別很大。
💡 選擇建議：選哪個模型，取決於你的工具複雜度、對幻覺的容忍度和成本預算。建議在 API易 apiyi.com 上用同一個密鑰把候選模型各跑一輪，再結合 docs.apiyi.com/models 的價格數據做綜合判斷。
常見問題 FAQ
Q1：什麼是多輪工具調用小測試？
它是一個規模很小、結果確定的測試。用 2 到 3 個 Mock 工具和一次注入失敗，讓模型完整跑一遍“調用工具、處理結果、重試、輸出結構化答案”的循環，再用程序逐項判定是否通過。它關注的是循環能否穩定跑完，不是模型的知識水平。
Q2：爲什麼強調一個密鑰測多個模型？
爲了控制變量。不同的密鑰、SDK 和代理地址會帶來鑑權、超時和協議適配上的差異，讓對比結果失真。統一入口之後，唯一變化的只有 model 字段，測出來的差異才能歸因到模型本身。
Q3：temperature 設爲 0 就能保證完全復現嗎？
不能完全保證。即使 temperature 爲 0，部分模型的輸出仍有輕微波動，推理類模型還可能不支持調低該參數。所以測試要固定運行多次，看通過率和失敗分佈，而不是隻看某一次的結果。實際使用的參數值也要記錄下來。
Q4：這個測試適合哪些場景？
– **Agent 選型**：上線前比較候選模型在工具循環上的穩定性。
– **模型升級迴歸**：新版本發佈後，用同一套腳本重跑，確認沒有退化。
– **協議遷移驗證**：從 OpenAI 格式切換到 Anthropic 格式時，確認適配層沒有問題。
Q5：如何快速開始調用這些模型？
1. 訪問 API易 apiyi.com 註冊賬號並獲取密鑰。
2. 閱讀 docs.apiyi.com，確認 OpenAI 兼容地址和 Anthropic 兼容地址。
3. 按本文第 1 步的參數表配置，先用最小請求確認每個模型都能返回工具調用。
API易 支持本文提到的多家模型統一接入，切換模型只需修改 model 字段。
Q6：測試成本怎麼估算？
成本約等於“模型數 × 運行次數 × 每次運行的累計 Token × 單價”。多輪循環的輸入 Token 會逐輪累加，重試會進一步增加用量。單價和緩存計費規則以 API易 價格頁 docs.apiyi.com/models 的實際數據爲準。建議先每個模型跑 1 次估算用量，再決定正式運行的次數。
Q7：這個測試有哪些侷限？
小測試只能覆蓋典型的失敗模式，不能代表所有複雜業務。Mock 工具返回的數據很乾淨，真實系統可能返回格式混亂或超長的數據。測試通過之後，建議再加入業務中真實出現過的異常樣本，逐步擴充用例。
多輪工具調用小測試核心要點 Key Takeaways
- 控制變量優先：用一個密鑰、一套配置，只改變 model 字段。
- 工具只讀且確定：Mock 返回值寫死，保證每次運行看到相同數據。
- 必須注入失敗：一次可重試錯誤，最能區分模型的循環處理能力。
- 評分程序化：每個檢查項都能自動判定，人工只負責複查異常。
- 完整留痕：保存原始響應、每輪 usage 和完整模型 ID，方便迴歸。
- 價格以官方頁爲準：成本計算以 API易 價格頁 docs.apiyi.com/models 爲準。
- 統一入口更省事：藉助 API易 兼容 OpenAI 與 Anthropic 格式，一套腳本可以覆蓋兩種協議。
總結
一個密鑰測多個模型的多輪工具調用小測試，核心在三點：
- 可復現：固定配置、固定 Mock 數據、固定提示詞版本，並多次運行。
- 可判定：用 Schema 校驗和評分清單代替主觀印象。
- 可迴歸：完整留痕，模型升級後能用同一套腳本快速重測。
這套方法不會告訴你“哪個模型最好”，但能告訴你在你的工具鏈裏，哪個模型更穩定、更省 Token，失敗時的表現也更可控。建議先用本文的訂單查詢場景跑通流程，再替換成自己業務裏的工具。
推薦通過 API易 apiyi.com 用同一個密鑰完成多模型的橫向驗證。接入方式見 docs.apiyi.com，價格與計費口徑以 docs.apiyi.com/models 爲準。
📚 參考資料
- OpenAI 函數調用文檔：tools、tool_calls 與 tool 角色消息的協議說明
- 鏈接：
platform.openai.com/docs/guides/function-calling -
說明：理解 OpenAI 兼容格式下參數字符串與 tool_call_id 的處理方式
-
Anthropic 工具使用文檔：tool_use 與 tool_result 內容塊說明
- 鏈接：
docs.anthropic.com/en/docs/build-with-claude/tool-use -
說明：瞭解 input_schema、tool_use_id 與 is_error 的用法
-
API易 文檔中心：統一接口接入說明
- 鏈接：
docs.apiyi.com -
說明：查看 OpenAI 與 Anthropic 兼容地址及調用示例
-
API易 模型與價格頁：模型列表與計費口徑
- 鏈接：
docs.apiyi.com/models - 說明：所有輸入、輸出與緩存單價以此頁面實際數據爲準
作者：APIYI 技術團隊
技術交流：歡迎在 API易 apiyi.com 網站首頁聯繫我們，更多接入資料可訪問 docs.apiyi.com 文檔中心
