Oceny WebMCP

Kasper Kulikowski

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

WebMCP obsługuje agentów, którzy korzystają z modeli generatywnej AI. Aby przetestować dowolny system korzystający z generatywnej AI, testy muszą obsługiwać 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 środowisku produkcyjnym, musisz się upewnić, że agenci wiedzą, kiedy 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 cel 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.
• Weryfikowanie udanych ścieżek użytkownika. Czy biorąc pod uwagę zamiar użytkownika, agent może skutecznie przeprowadzić go przez ścieżkę 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 działać nieprawidłowo w przypadku korzystania z nich. 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.	Pracownik obsługi klienta 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 innego narzędzia, co może prowadzić do niejednoznaczności wywołań?
Agent wywołuje narzędzia w niewłaściwej kolejności	Pracownik obsługi klienta dzwoni pod numer checkout, a potem pod numer addToCart.	Czy opisy narzędzi się pokrywają, co wprowadza model LLM w błąd co do wymaganej kolejności? Czy wynik poprzedniego narzędzia zapewnia 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 poprzednie wywołania, aby potwierdzić, że LLM wybiera prawidłowy następny krok?
Agent wywołuje narzędzie z nieprawidłowymi argumentami	Pracownik dzwoni pod numer addToCart, ale dodaje buty zamiast koszulki.	Czy 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 czegoś nie uwzględnia.	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? Czy dane wyjściowe są używane przez model LLM w przypadku kolejnych wywołań i czy są sformatowane w sposób umożliwiający ich łatwe przetworzenie przez model LLM? Czy wynik jest zbyt obszerny? Czy zawiera tylko minimalną ilość niezbędnych informacji, których LLM potrzebuje do wykonania następnego działania?

Narzędzie może w końcu zawieść w każdy sposób, w jaki może zawieść JavaScript. Aby rozwiązać problem, sprawdź te kwestie:

• Czy kod narzędzia prawidłowo obsługuje wszystkie potencjalne błędy i wyjątki czasu działania?
• 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 (ponowienie próby) od poważnej awarii?

Testowanie narzędzi w izolacji

Jeśli agent nie może określić, którego narzędzia użyć w przypadku żądania typu „Chcę małą pizzę”, nie poradzi sobie w skomplikowanej ścieżce 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ą WebMCP zaMaker. Gdy użytkownik wpisze „Chcę małą pizzę”, możesz spodziewać się odpowiedzi modelu wskazującej zamiar wykonania wywołania set_pizza_size z argumentem "size":"Small".

Funkcja expectedCall określa 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 to zrobić, podaj pełną listę narzędzi, które są istotne w przypadku stanu, który chcesz ocenić. Na przykład użytkownik przegląda internet wspólnie z pracownikiem obsługi klienta 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 Ty możesz tylko ocenić te, które udostępniasz.

Teraz, gdy wiesz już, że agent w razie potrzeby wywołuje odpowiednie narzędzie, możesz sprawdzić, czy wywołanie narzędzia ma prawidłowe parametry i czy wynik jest zgodny z oczekiwaniami. Wyróżniamy 2 rodzaje testów: deterministyczne i probabilistyczne.

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 prawidłowo wywołane.
• 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 integracyjnego 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ć funkcje ewaluacyjne.

Użytkownicy mogą kierować do modelu bezpośrednie zapytania, w których pytają o to, do czego służy 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 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 otwarte zapytania, 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 „kawa”.

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ć, jakiego parametru item_id użyć w przypadku parametru order_product.

Testowanie kompleksowe

Napisz testy kompleksowe, aby mieć pewność, że użytkownicy i ich agenci mogą skutecznie realizować swoje cele. Oprócz testowania poszczególnych narzędzi sprawdzasz też, czy działania wieloetapowe są wykonywane w odpowiedniej kolejności.

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

Przykładowa ścieżka użytkownika, który korzysta z 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, które zawierają 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 wykonywać 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łać kilka narzędzi po kolei. Co się stanie, jeśli narzędzie ulegnie awarii w trakcie tego procesu? Na przykład 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ędzia 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 włączoną platformą WebMCP za pomocą dowolnego agenta zgodnego z WebMCP:

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