MCP-Bench 是什麼？大型語言模型多工具協同的評測重點

當大型語言模型開始同時讀取資料、搜尋文件、建立草稿、查詢外部系統，真正需要驗證的就不再只是「能不能呼叫工具」，而是它能否在模糊需求下選對工具、填對參數、排對步驟，並把中間結果正確地帶進最後答案。這也是 MCP-Bench 論文想補足的評測情境。

不過，任何基準測試的分數都不等於系統已經適合上線。它反映的是特定任務集、伺服器狀態、模型版本、提示詞、代理程式設計與評分規則下的表現。對想導入 AI 代理或 MCP 工具鏈的團隊來說，較好的問題不是「哪個模型分數最高」，而是「這個分數有沒有驗證到我們真正在乎的失敗模式？」

MCP-Bench 是什麼？

MCP-Bench 是一套針對工具使用型 LLM 代理的評測框架，建立在 Model Context Protocol（MCP）情境上。依論文摘要，它串接 28 個具代表性的即時 MCP 伺服器、橫跨 250 種工具，任務涵蓋財務、旅行、科學運算與學術搜尋等領域。研究者希望測試的不是單一 API 呼叫，而是多步驟任務裡的跨工具協同、參數控制與規劃推理。

這個設計很貼近實務的難處。例如使用者只說「整理近期資料並比較選項」，代理必須先理解需求，再從一批工具中挑出合適的工具；後續還要處理查詢結果、依賴順序與例外情況。論文特別把「從未明說工具名稱的模糊指令中找出相關工具」、「把多跳步驟排成可執行軌跡」與「根據中間工具輸出完成回答」列為重點。完整程式、任務與執行方式可在 MCP-Bench 專案庫查閱。

為什麼只測單一工具，常常不夠？

若測試題目直接給出工具名稱、參數格式與明確步驟，模型只要照著做，就可能得到不錯的結果。但真實工作流程通常沒有這麼整齊：工具描述可能相似、輸入欄位有條件限制、前一步結果才決定下一步能否執行，而且不同工具可能讀寫同一份外部狀態。

以一個內容營運任務為例，代理可能要先取得文章資料，再查核資料來源、產出草稿、建立預覽圖片、送出待審核內容。這當中不只涉及文字品質，也有權限、版本、檔案格式、重複執行與人工確認。如果它把正確的工具用在錯誤時間，或把舊查詢結果當成最新資料，最後答案看起來流暢，實際動作仍可能錯誤。

因此，多工具評測應測出「能不能完成」以外的訊號：工具是否選對、參數是否合格、步驟順序是否可重現、輸出是否有根據、失敗時是否安全停止。MCP-Bench 擴大了這些面向的測試，但它也不是對所有產品情境的保證；任何單一基準都無法取代針對自身流程的驗收。

看懂分數前，先拆成六個能力層次

1. 工具發現與選擇

代理是否能從工具名稱、描述與輸入 schema 中辨識用途，並排除「看似相近、其實不符合」的工具？這是多伺服器環境常見的第一道關卡。若只在提示詞中直接指定工具，便測不到這個能力。

2. Schema 與參數正確性

呼叫成功不代表參數正確。日期範圍、時區、單位、分頁、必填欄位與篩選條件，都可能讓同一個工具產生完全不同的結果。評測時要保留原始請求與回應，確認代理不是靠碰巧通過，而是真的符合介面契約。

3. 依賴順序與狀態管理

多工具工作流往往有前後依賴：先建立草稿才能上傳附件，先取得識別碼才能更新資料，先確認權限才能進行寫入。好的代理需要知道哪些操作可重試、哪些操作會造成重複副作用，以及失敗後如何回到可控狀態。

4. 事實依據與輸出品質

工具回傳的中間資料應能追溯到最後結論。若代理在摘要、比較或決策建議中遺漏限制條件、混入未經工具支持的說法，文字即使自然，也不應算完成。可以要求它附上資料來源、時間點與關鍵計算過程，再用預先定義的事後條件驗證。

5. 權限、副作用與人工關卡

讀取資料、建立草稿、發送郵件、刪除內容與修改權限的風險完全不同。評測必須刻意放入需要確認的情境，檢查代理是否在寫入、發佈、付款、刪除或對外通知前停下來請人核准。高風險行為不能只以「任務完成率」評分。

6. 成本、延遲與失敗復原

實際環境有速率限制、網路逾時、伺服器暫停、schema 改版與資料延遲。模型可能在理想環境中答對，卻因不斷重試而變慢或產生額外成本。除了平均成功率，也應量測延遲分位數、呼叫次數、重試情況與可恢復失敗的比例。

建立自己的評測集，比追排行榜更重要

若團隊準備導入多工具代理，建議先把真實、可重複的任務整理成小型評測集。每個任務都應說明使用者目標、允許的工具、預期產物、不可跨越的安全界線，以及可由程式或人工判定的完成條件。題目不必很多，但必須涵蓋日常最重要、最容易出錯與影響最大的流程。

例如內容網站可設計「根據既有文章資料撰寫更新草稿，但不得改動網址、日期、作者、分類與舊媒體」、「上傳新預覽圖前確認尺寸與替代文字」、「缺少可靠資料來源時只能產出待查清單」等任務。這些條件會比抽象問答更接近真正的營運需求，也能看出代理會不會越權。

每次測試都應記錄模型版本、系統提示詞、代理框架版本、MCP 伺服器版本與工具 schema、測試資料時間點，以及完整的工具軌跡。缺少這些紀錄，日後即使分數變高或變低，也很難知道是模型能力、環境資料、工具介面還是評分器改變所造成。

同時，請把失敗結果分類，而不是只累計「失敗」一次。常見類型包括找不到正確工具、選到錯誤工具、schema 驗證失敗、參數語意錯誤、依賴順序錯誤、引用不足、工具逾時、超出權限、重複寫入，以及應該要求人工確認卻沒有停下來。不同類型需要的改善方式並不相同：有些要改工具描述，有些要補充任務上下文，有些則必須收緊權限或把流程拆成不可自動化的兩段。

也別忽略對照組。若一項工作本來由人員在五分鐘內就能安全完成，代理方案除了看完成率，還要比較實際耗時、人工覆核時間、例外處理量與總成本。只有在品質與風險可接受的前提下，效率提升才有意義。這能避免團隊把「展示時能跑完」誤當成「營運上值得採用」。

用「後置條件」驗證，而不是只看最後一句話

一個實用的測試不應只讓評審閱讀最後答案，而要驗證可觀察的結果。以「更新一篇文章」為例，後置條件可以包括：指定欄位確實被更新、網址與作者沒有改變、文章內容沒有殘留錯誤編碼、精選圖片尺寸符合規格、SEO 描述有填寫、沒有未經核准的發佈或刪除動作。這些條件能由 API 回讀、資料庫快照或測試環境日誌確認。

對涉及外部資料的任務，還可驗證引用是否存在、時間範圍是否正確、計算是否可重現。對有副作用的任務，則需檢查是否只在沙盒帳號執行、是否產生重複寫入、是否留下還原紀錄。文字評分仍然有價值，但應作為多個證據之一，而不是唯一裁決。