Przetestuj WebMCP za pomocą Evals

Kasper Kulikowski

Data publikacji: 19 maja 2026 r., ostatnia aktualizacja: 28 maja 2026 r.

Film z wyjaśnieniem	Sieć	Rozszerzenia	Stan Chrome	Intencja
GitHub	Testowanie Origin		Wyświetl	Zamiar przeprowadzenia eksperymentu

WebMCP obsługuje agentów, którzy korzystają z modeli generatywnej AI. Aby testować dowolny system korzystający z generatywnej AI, musisz mieć testy obsługujące wyniki probabilistyczne: jedno wejście może prowadzić do tysięcy odpowiedzi o różnym stopniu dokładności. Ta technika testowania jest nazywana ocenami.

Zanim udostępnisz narzędzia w wersji produkcyjnej, musisz potwierdzić, że agenci wiedzą, kiedy należy wywołać narzędzie, jak je wykonać i jakie odpowiedzi są akceptowalne. Zapobiegaj możliwym problemom, zanim się pojawią.

Pisz oceny, aby przetestować punkty styku systemu z dużym modelem językowym (LLM):

• Sprawdź, czy model rozumie przeznaczenie narzędzia na podstawie jego opisu i schematu.
• Sprawdź, czy model wybiera odpowiednie narzędzie z prawidłowymi parametrami, aby realizować intencje użytkownika.
• Sprawdź, czy model działa na podstawie otrzymanych informacji, np. wykorzystuje je do wywołania innego narzędzia.
• Weryfikuj udane ścieżki użytkowników. Czy biorąc pod uwagę zamiar użytkownika, agent może z powodzeniem zrealizować ścieżkę użytkownika w mojej witrynie za pomocą udostępnionych narzędzi?

W przypadku interakcji z systemem, które nie komunikują się z modelem, nadal należy pisać klasyczne testy deterministyczne.

Rodzaje błędów

Deweloperzy powinni testować swoje systemy, aby zapobiegać awariom. Aby to zrobić, musisz wiedzieć, kiedy system może zawieść, zarówno samodzielnie, jak i w interakcji z czynnikami zewnętrznymi. W przypadku WebMCP samo narzędzie może ulec awarii, a agenci mogą nie móc z niego korzystać zgodnie z oczekiwaniami.

Narzędzia WebMCP mogą działać nieprawidłowo, a agent może nie działać prawidłowo z narzędziami WebMCP. Załóżmy na przykład, że użytkownik chce dodać koszulkę do koszyka.

Niepowodzenie	Przykład	Rozwiązywanie problemów
Agent nie wybiera prawidłowego narzędzia lub bezpośrednio wywołuje nieprawidłowe narzędzie.	Agent pomija addToCart i przechodzi bezpośrednio do checkout.	Czy description narzędzia jest jasny, kompletny i dokładnie odzwierciedla jego działanie? Czy functionName jest intuicyjny i opisowy? Czy narzędzie jest prawidłowo udostępniane LLM w bieżącym stanie lub kontekście? Czy schemat tego narzędzia jest zbyt podobny do schematu innego narzędzia, co może prowadzić do niejednoznaczności wywołań?
Agent wywołuje narzędzia w niewłaściwej kolejności	Agent wywołuje kolejno funkcje checkout i addToCart.	Czy opisy narzędzi się pokrywają, co wprowadza model LLM w błąd co do wymaganej kolejności? Czy dane wyjściowe poprzedniego narzędzia zapewniają niezbędny kontekst dla następnego wywołania narzędzia? Czy stan jest prawidłowo aktualizowany, a nowe narzędzia są udostępniane LLM zgodnie z oczekiwaniami? Czy przypadek użycia typu end-to-end jest nadal prawidłowy, jeśli niektóre narzędzia są wywoływane w innej kolejności? Czy przetestowano konkretny łańcuch wywołań narzędzi w izolacji, wymuszając potwierdzenie poprzednich wywołań, aby sprawdzić, czy LLM wybiera prawidłowy następny krok?
Agent wywołuje narzędzie z nieprawidłowymi argumentami	Agent dzwoni pod numer addToCart, ale dodaje buty zamiast koszulki.	Czy typ inputSchema jest jasno zdefiniowany, w tym wartości enum i odpowiedni description dla każdej właściwości? Czy wszystkie wymagane parametry są wyraźnie oznaczone i sprawdzone? Czy opis argumentu wyraźnie instruuje LLM, jak mapować dane wejściowe użytkownika na oczekiwane dane strukturalne (np. konkretny identyfikator lub format)?

Co zrobić, jeśli użytkownik chce sprawdzić zawartość koszyka?

Niepowodzenie	Przykład	Rozwiązywanie problemów
Dane wyjściowe narzędzia są nieprawidłowe lub narzędzie pomija pewne informacje.	Użytkownik prosi o viewCart, ale agent podaje łączny koszt koszyka zamiast nazw produktów i cen poszczególnych produktów.	Czy logika narzędzia ma błędy (sprawdź za pomocą testów deterministycznych)? Czy stan interfejsu został prawidłowo zaktualizowany i czy agent otrzymał właściwe informacje o skutku ubocznym? Jeśli dane wyjściowe są używane przez model LLM w kolejnych wywołaniach, czy są one sformatowane w sposób umożliwiający ich łatwe przetworzenie przez model LLM? Czy wynik jest zbyt rozwlekły? Czy zawiera tylko minimalną ilość niezbędnych informacji, których LLM potrzebuje do wykonania kolejnego działania?

Narzędzie może w każdy sposób zawieść, tak jak JavaScript. Aby rozwiązać ten problem, sprawdź:

• Czy kod narzędzia prawidłowo obsługuje wszystkie potencjalne błędy środowiska wykonawczego i wyjątki?
• Czy błąd jest zgłaszany agentowi i modelowi w odpowiedni sposób?
• Czy zewnętrzne interfejsy API lub usługi, na których polega narzędzie, działają prawidłowo?
• Czy struktura błędu jest wystarczająco jasna, aby model mógł odróżnić problem tymczasowy (ponów próbę) od krytycznej awarii?

Testowanie narzędzi w izolacji

Jeśli agent nie może określić, którego narzędzia użyć w przypadku prośby takiej jak „Chcę małą pizzę”, nie będzie w stanie poradzić sobie ze złożonymi ścieżkami użytkownika.

Testując narzędzia osobno, możesz zoptymalizować schematy i opisy, zanim przeprowadzisz symulację w przeglądarce.

Dokładność pomiaru połączeń

Zapoznaj się z naszą wersją demonstracyjną, czyli WebMCP zaMaker. Gdy użytkownik wpisze „Chcę małą pizzę”, możesz spodziewać się odpowiedzi modelu wskazującej na zamiar wykonania wywołania set_pizza_size z argumentem "size":"Small".

Funkcja expectedCall definiuje oczekiwaną funkcję i argument. Dzięki temu agent wybierze odpowiednie narzędzie do realizacji intencji użytkownika na podstawie podanego schematu.

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

expectedCall służy do przeprowadzania testu deterministycznego opartego na regułach:

Narzędzia WebMCP można powiązać z cyklem życia komponentu, co oznacza, że musisz przeprowadzić test, gdy stan aplikacji jest zgodny z oczekiwaniami WebMCP. Aby zarządzać tym ustawieniem, podaj pełną listę narzędzi, które są istotne w przypadku stanu, który chcesz ocenić. Na przykład użytkownik przegląda stronę wspólnie z agentem i otwiera 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" }
   }
 ]
...

Po otwarciu WebMCP udostępnia narzędzia add_topping, set_pizza_size i set_pizza_style. Aby dokładnie przetestować poszczególne narzędzia, musisz uwzględnić wszystkie narzędzia, aby utworzyć symulowany, kompletny stan.

UWAGA: pracownik może mieć dostęp do dodatkowych narzędzi, ale najlepsze, co możesz zrobić, to ocenić narzędzia, które udostępniasz.

Teraz, gdy wiesz już, że agent wzywa odpowiednie narzędzie w razie potrzeby, możesz sprawdzić, czy wywołanie narzędzia ma prawidłowe parametry i czy wynik jest zgodny z oczekiwaniami. Składają się one z 2 etapów: testów deterministycznych i probabilistycznych.

Przeprowadzanie testów deterministycznych

Narzędzia WebMCP są tworzone w JavaScript lub jako adnotacje HTML, więc możesz pisać testy deterministyczne, aby wykonywać te zadania:

• Sprawdź logikę narzędzia.
• Sprawdź, czy zależności zostały wywołane prawidłowo.
• Sprawdź, czy interfejs użytkownika został zaktualizowany zgodnie z oczekiwaniami, a także czy wystąpiły inne zamierzone efekty uboczne.
• Sprawdź, czy zwrócone informacje są zgodne z oczekiwaną wartością.
• Sprawdź parametry testu.

Jeśli na przykład Twoje narzędzie korzysta z funkcji SearchComponent, możesz przetestować je, przekazując symulację SearchComponent. Aby uzyskać jak najlepsze wyniki, pamiętaj, aby symulować środowisko, w którym narzędzie będzie działać. Jest to ta sama technika, której używasz podczas pisania innego testu integracji aplikacji.

Przeprowadzanie testów probabilistycznych

Jeśli chcesz, aby model wygenerował dane wyjściowe modelu, które umożliwią prawidłowe wywołanie kolejnych narzędzi, musisz napisać evals.

Użytkownicy mogą przesyłać do modelu bezpośrednie zapytania, w których pytają konkretnie o to, co robi narzędzie, lub niejednoznaczne zapytania, które sugerują, że należy użyć narzędzia. Na przykład „Dodaj pepperoni do mojej pizzy” to bezpośrednie zapytanie. „Chcę, żeby na mojej pizzy było całe mięso” to bardziej niejednoznaczne zdanie, które wymaga od modelu zrozumienia, że potrzebuje narzędzia add_topping, i określenia, które dodatki można zdefiniować jako mięso.

Podczas tworzenia zbiorów danych do oceny uwzględnij zarówno bezpośrednie zapytania, które testują podstawowe działanie narzędzia, jak i zapytania otwarte, które testują logikę rozumowania modelu i wyboru narzędzia.

Jeśli prowadzisz kawiarnię, możesz obsługiwać użytkowników, którzy proszą agenta o ponowne zamówienie tej samej kawy, którą zamówili w zeszłym miesiącu. Napisz narzędzie do wyszukiwania poprzednich zamówień, OrderHistoryService, i kolejne do zamawiania kawy. Aby przetestować usługę historii zamówień, możesz wysłać symulację, która zwraca identyfikator produktu do kawy.

W tym przykładzie oceniasz, czy model rozumie intencje zapytania, wybiera odpowiednie narzędzie i czy to narzędzie dostarcza właściwych informacji, które pozwalają podjąć działanie. Jeśli model nie wywoła funkcji get_order_history, nie będzie wiedzieć, jakiej funkcji item_id użyć w przypadku order_product.

Testowanie kompleksowe

Napisz testy kompleksowe, aby mieć pewność, że użytkownicy i ich agenci mogą pomyślnie przejść całą ścieżkę. Oprócz testowania poszczególnych narzędzi sprawdzasz też, czy działania wieloetapowe są wykonywane we właściwej kolejności.

Załóżmy, że prowadzisz internetowy sklep odzieżowy. Użytkownik pyta agenta: „Chcę kupić czarną kurtkę i parę dżinsów. Czy możesz podać szczegółowe informacje o użytych materiałach?

Przykładowa ścieżka z użyciem agenta:

1. Przejdź do kategorii odzieży.
2. Znajdź jeden z zamówionych elementów odzieży (kolejność nie ma znaczenia).
3. Znajdź konkretny element (search_clothes).
4. Uzyskaj szczegóły produktu zawierające listę materiałów (get_product_details).
5. Powtórz kroki 2–4 w przypadku każdego żądanego elementu.

Gdy agent dotrze do kroku 2, może wyszukać najpierw czarne lub dżinsy. Kolejność nie ma znaczenia. Pozostałe kroki należy jednak wykonać po kolei.

Napisz test kompleksowy, aby sprawdzić, czy agent wywołuje narzędzia w oczekiwanej kolejności:

{
  "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" }
            }
          ]
        }
      ]
    }
  ]
}

Ocena błędów w środku łańcucha

Czasami agent musi wywoływać wiele narzędzi po kolei. Co się stanie, jeśli narzędzie ulegnie awarii w trakcie tego procesu? Załóżmy na przykład, że użytkownik chce zamówić pizzę, używając kodu kuponu:

„Chcę małą pizzę pesto. Użyj mojego kodu promocyjnego: FreePizza”.

Może się zdarzyć, że agent nie poradzi sobie z add_discount_coupon i przejdzie do płatności za pizzę w pełnej cenie. Aby przetestować narzędzie add_discount_coupon, możesz ręcznie wykonać tę sekwencję wywołań narzędzi bez interakcji z modelem, aby zasymulować ten scenariusz. Doprowadź aplikację do stanu, w którym narzędzie prawdopodobnie zawiedzie. W tym przypadku jest to narzędzie start_checkout. Następnie możesz ocenić add_discount_coupon w izolacji.

Eksperymentowanie z WebMCP

Zacznij eksperymentować z ocenami narzędzi w izolacji i oceniać własne witryny z obsługą WebMCP za pomocą dowolnego agenta zgodnego z WebMCP:

• Pobierz nasze eksperymentalne narzędzia do oceny z GitHuba.
• Zapoznaj się z naszym kursem Tworzenie ocen AI.