使用 Evals 測試 WebMCP

Kasper Kulikowski

發售日期：2026 年 5 月 19 日，最後更新日期：2026 年 5 月 28 日

說明影片	網頁	擴充功能	Chrome 狀態	意圖
GitHub	來源試用		總覽	實驗意圖

WebMCP 支援使用生成式 AI 模型的代理程式。要測試任何使用生成式人工智慧的系統，您的測試需要支援機率結果：一個輸入可能會產生數千個準確度各異的答案。這種測試技術稱為 evaluations 或 evals。

將工具發布至正式環境前，請務必確認代理程式瞭解何時應呼叫工具、如何執行工具，以及可接受的答案。在發生故障前，找出並解決問題。

編寫評估程序，測試您的系統與大型語言模型 (LLM) 的交互點：

• 根據工具的描述和架構，檢查模型是否理解工具的用途。
• 驗證模型是否選擇了合適的工具和正確的參數來支援使用者意圖。
• 確認模型是否正在根據接收到的資訊採取行動，例如使用資訊呼叫另一個工具。
• 驗證使用者流程是否成功。根據使用者的意圖，代理商能否使用提供的工具成功完成使用者在我網站上的操作流程？

對於任何不與模型通訊的系統交互，都應該繼續編寫經典的確定性測試。

故障模式

開發人員應該對系統進行測試，以防止故障發生。為此，你需要瞭解系統何時可能出現故障，包括系統本身故障和與外部因素相互作用時出現故障。對於 WebMCP，工具本身可能會發生故障，代理程式可能無法如預期般使用這些工具。

WebMCP 工具可能會發生故障，代理程式在使用 WebMCP 工具時也可能會遇到故障。 例如，假設您的用戶想要將一件 T 恤加入購物車。

失敗	範例	疑難排解
代理未能選擇正確的工具或直接呼叫了錯誤的工具。	代理跳過 addToCart，直接前往 checkout。	該工具的description是否清晰、完整且準確地反映了該工具的功能？ functionName 是否直觀且具有描述性？ 在目前狀態/上下文中，該工具是否已正確暴露給 LLM？ 該工具的架構是否可能與另一個工具過於相似，從而導致呼叫歧義？
代理人錯誤地呼叫了工具。	代理呼叫 checkout，然後呼叫 addToCart。	工具描述是否重疊，導致 LLM 對所需順序感到困惑？ 前一個工具的輸出是否為下一個工具呼叫提供了必要的上下文？ 狀態是否已正確更新，並且是否按預期向 LLM 提供了任何新工具？ 如果某些工具的呼叫順序不同，端到端的使用場景是否仍然正確？ 您是否透過強制執行前面的呼叫來單獨測試特定的工具呼叫鏈，以確認 LLM 選擇正確的下一步？
代理呼叫工具時參數不正確	代理人撥打了addToCart電話，但卻加了鞋子而不是 T 恤。	inputSchema 是否定義清晰，包括 enum 值以及每個屬性的良好 description？ 所有必需參數是否都已明確標記和檢查？ 論證描述是否明確指導 LLM 如何將使用者輸入映射到預期的結構化資料（例如特定的 ID 或格式）？

如果用戶想查看購物車裡的商品呢？

失敗	範例	疑難排解
工具輸出不正確或工具遺漏了某些內容。	使用者請求viewCart，但代理商輸出的是購物車總價，而不是產品名稱和單一價格。	底層工具邏輯是否有缺陷（透過確定性測試進行檢查）？ UI 狀態是否正確更新？代理是否收到了關於副作用的正確訊息？ 如果 LLM 將輸出用於後續調用，輸出格式是否清晰，以便於 LLM 接收？ 輸出資訊是否過於冗長？它是否只包含 LLM 下一步行動所需的最基本資訊？

最後，任何工具都可能以 JavaScript 失敗的方式運作。若要排除故障，請檢查以下內容：

• 該工具程式碼是否能正確處理所有潛在的執行時間錯誤和異常？
• 錯誤是否能正常回饋給代理人和模型？
• 該工具所依賴的外部 API 或服務是否運作正常？
• 錯誤結構是否足夠清晰，以至於模型能夠區分暫時性問題（重試）和嚴重故障？

單獨測試工具

如果客服人員連「我要一份小披薩」這樣的請求該呼叫哪個工具都搞不清楚，那麼在複雜的使用者流程中，客服人員就毫無勝算。

透過單獨測試工具，您可以在執行瀏覽器模擬之前優化您的架構和描述。

測量通話準確率

來看看我們的演示，WebMCP zaMaker。 當使用者提示「我想要一個小披薩」時，您可以預期會收到一個模型回應，表示打算執行帶有 "size":"Small" 參數的 set_pizza_size 呼叫。

expectedCall 函式會定義預期的函式和引數。這種做法可確保代理程式會根據提供的結構定義，選擇正確的工具來支援使用者意圖。

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

expectedCall 用於執行確定性測試，並以規則為依據：

您可以將 WebMCP 工具繫結至元件的生命週期，也就是說，您必須在應用程式狀態符合 WebMCP 預期時進行測試。如要管理這項設定，請提供與您想評估的狀態相關的完整工具清單。舉例來說，使用者與服務專員共同瀏覽網頁，並開啟 WebMCP zaMaker。

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

開啟後，WebMCP 會顯示 add_topping、set_pizza_size 和 set_pizza_style 工具。如要準確測試這些個別工具，請納入所有工具，建立模擬的完整狀態。

注意：代理程式可能可以存取其他工具，但您只能評估自己提供的工具。

現在您已瞭解代理程式會視需要呼叫正確的工具，接下來可以測試工具呼叫是否具有正確的參數，以及結果是否符合預期。分為兩個步驟：確定性測試和機率性測試。

執行確定性測試

由於 WebMCP 工具是以 JavaScript 或 HTML 註解建構而成，您可以編寫確定性測試，執行下列工作：

• 驗證工具邏輯。
• 確認依附元件是否已正確呼叫。
• 確認使用者介面已如預期更新，以及任何其他刻意產生的副作用。
• 確認傳回的資訊符合預期值。
• 驗證測試參數。

舉例來說，如果工具使用 SearchComponent 函式，您可以傳遞 SearchComponent 的模擬項目進行測試。請記得模擬工具運作的環境，盡可能取得最佳結果。這與您編寫其他應用程式整合測試時使用的技術相同。

執行機率測試

如要讓模型輸出內容正確呼叫下一個工具，您需要編寫評估。

使用者可以直接向模型發出查詢，明確詢問工具的具體功能，或發出含糊不清的查詢，暗示應該使用某個工具。例如，「在我的披薩上加義大利辣香腸」就是一個直接查詢。 「我要披薩上全是肉」這句話比較含糊，需要模型理解它需要 add_topping 工具，以及哪些配料可以被定義為肉。

在建立評估資料集時，既要包含測試基線工具執行情況的直接查詢，也要包含測試模型推理和工具選擇邏輯的開放式查詢。

如果你經營咖啡店，你可以為要求客服人員重新訂購上個月訂購過的同款咖啡的用戶提供支援。寫一個工具來搜尋先前的訂單，OrderHistoryService，再寫一個工具來訂購咖啡。若要測試訂單歷史記錄服務，您可以傳送一個返回咖啡產品 ID 的模擬請求。

在這個例子中，你需要評估模型是否理解查詢的意圖，是否選擇了正確的工具，以及該工具是否提供了採取行動所需的正確資訊。 如果模型不呼叫 get_order_history，它就不知道該用哪一個 item_id 來取代 order_product。

端對端測試

編寫端到端測試，以確保用戶及其代理程式能夠成功完成他們的旅程。除了測試各個工具之外，還要測試多步驟操作是否以正確的順序執行。

例如，你經營一家網路服飾店。一位用戶詢問其代理人：“我想買一件黑色夾克和一條牛仔褲。” 能否提供一下所用材料的明細？

一次成功的代理之旅可能如下圖所示：

1. 進入服裝類。
2. 找一件所需的衣物（順序不重要）。
3. 尋找特定項目（search_clothes）。
4. 取得包含材料清單的產品詳細資訊（get_product_details）。
5. 對每個所需物品重複步驟 2-4。

當代理人到達步驟 2 時，它可以先搜尋黑色衣服，也可以先搜尋牛仔褲，順序並不重要。但是，其餘步驟必須依序執行。

編寫端對端評估程序，以驗證代理是否按預期順序呼叫工具：

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

評估鏈條中途故障

有時，代理人可能需要依序呼叫多個工具。如果在過程中某個工具發生故障會發生什麼事？例如，用戶想用優惠碼訂購披薩：

“我想要一份小份的香蒜醬披薩。” 使用我的優惠碼，FreePizza。

代理商有可能在 add_discount_coupon 處出錯，並繼續以全價結帳購買披薩。若要測試 add_discount_coupon 工具，您可以手動執行此工具呼叫序列，而無需與模型交互，以模擬此場景。將你的應用程式調整到你預期該工具會失效的狀態。在這種情況下，這是在 start_checkout 工具之後。然後，您可以單獨評估 add_discount_coupon。

使用 WebMCP 進行實驗

開始嘗試單獨評估各種工具，並使用任何相容於 WebMCP 的代理程式評估您自己的啟用 WebMCP 的網站：

• 在 GitHub 上下載我們的 實驗性評估工具。
• 查看我們的課程，建立 AI 評估。