Оценки WebMCP

Kasper Kulikowski

Опубликовано: 19 мая 2026 г.

WebMCP поддерживает агентов, использующих модели генеративного ИИ. Для тестирования любой системы, использующей генеративный ИИ, ваши тесты должны поддерживать вероятностные результаты: один входной параметр может привести к тысячам ответов с различной степенью точности. Этот метод тестирования называется оценкой или evals.

Перед внедрением инструментов в рабочую среду необходимо убедиться, что агенты понимают, когда следует вызывать инструмент, как его использовать и какие ответы допустимы. Необходимо предотвращать возможные сбои до того, как они произойдут.

Напишите оценочные тесты для проверки взаимодействия вашей системы с большой языковой моделью (LLM):

• Убедитесь, что модель понимает назначение вашего инструмента, исходя из его описания и схемы.
• Убедитесь, что модель выбирает правильный инструмент с корректными параметрами для поддержки намерений пользователя.
• Убедитесь, что модель действует на основе полученной информации, например, использует эту информацию для вызова другого инструмента.
• Проверьте успешность выполнения пользовательских сценариев. Сможет ли агент успешно выполнить пользовательский сценарий на моем веб-сайте, учитывая намерения пользователя, используя предоставленные инструменты?

Вам следует продолжать писать классические детерминированные тесты для любого взаимодействия системы, которое не предполагает связи с моделью.

Виды отказов

Разработчики должны тестировать свои системы, чтобы предотвратить сбои до того, как они произойдут. Для этого необходимо понимать, когда система может дать сбой, как самостоятельно, так и при взаимодействии с внешними факторами. В случае с WebMCP может дать сбой сам инструмент, а также агенты могут не работать должным образом.

Инструменты WebMCP могут давать сбои, и агент может дать сбой при работе с инструментами WebMCP. Например, предположим, пользователь хочет добавить футболку в корзину.

Отказ	Пример	Устранение неполадок
Оператор не выбирает правильный инструмент или напрямую вызывает не тот инструмент.	Агент пропускает addToCart и сразу переходит к checkout .	Является ли description инструмента ясным, полным и точно отражающим его функциональность? Является ли functionName интуитивно понятным и описательным? В текущем состоянии/контексте инструмент корректно представлен для LLM? Возможно, схема этого инструмента слишком похожа на схему другого инструмента, что может привести к неоднозначности вызовов?
Агент вызывает инструменты в неправильном порядке.	Агент вызывает checkout , а затем addToCart .	Описания инструментов частично совпадают, что может сбить с толку слушателя курса магистратуры по менеджменту и помешать ему определить необходимую последовательность действий? Предоставляет ли результат работы предыдущего инструмента необходимый контекст для вызова следующего инструмента? Состояние системы обновлено корректно, и все новые инструменты доступны для LLM, как и ожидалось? Сохраняет ли сквозной сценарий использования свою корректность, если определенные инструменты вызываются в другом порядке? Вы тестировали конкретную цепочку вызовов инструмента изолированно, принудительно проверяя предыдущие вызовы, чтобы убедиться, что LLM выбирает правильный следующий шаг?
Агент вызывает инструмент с некорректными аргументами.	Агент вызывает функцию addToCart , но добавляет обувь вместо футболки.	Четко ли определена inputSchema , включая значения enum и хорошее description каждого свойства? Все ли необходимые параметры четко отмечены и проверены? Указывает ли описание аргумента явно, как LLM сопоставить пользовательский ввод с ожидаемыми структурированными данными (например, с конкретным идентификатором или форматом)?

А что, если пользователь захочет посмотреть, что находится в его корзине?

Отказ	Пример	Устранение неполадок
Результат работы инструмента неверен или инструмент что-то упускает.	Пользователь запрашивает просмотр viewCart , но агент выводит общую стоимость корзины вместо названий товаров и цен отдельных товаров.	Содержит ли логика базового инструмента ошибки (проверьте с помощью детерминированных тестов)? Было ли корректно обновлено состояние пользовательского интерфейса и получил ли агент правильную информацию о побочном эффекте? Если выходные данные используются LLM для последующих вызовов, то имеют ли эти выходные данные понятный формат для приема LLM? Вывод слишком многословен? Содержит ли он только минимально необходимую информацию, которая требуется LLM для выполнения следующего действия?

Наконец, инструмент может по какой-либо причине дать сбой в работе JavaScript. Для устранения неполадок изучите следующее:

• Обрабатывает ли код инструмента все потенциальные ошибки и исключения во время выполнения?
• Передаётся ли ошибка обратно агенту и модели корректным образом?
• Являются ли внешние API или сервисы, на которые полагается инструмент, работоспособными?
• Достаточно ли понятна структура ошибок, чтобы модель могла различать временную проблему (повторную попытку) и критическую ошибку?

Тестовые инструменты изолированно

Если оператор не может понять, какой инструмент использовать для запроса, например, «Я хочу маленькую пиццу», у него не будет никаких шансов в сложном пользовательском сценарии.

Тестируя инструменты по отдельности, вы можете оптимизировать свои схемы и описания еще до запуска симуляции в браузере.

СОВЕТ: Вы можете инициировать вызов инструмента WebMCP using navigator.modelContext.executeTool(...) .

Измерьте точность звонков

Взгляните на нашу демонстрацию, WebMCP zaMaker . Когда пользователь запрашивает «Я хочу маленькую пиццу», вы можете ожидать ответа от модели, указывающего на намерение выполнить вызов set_pizza_size с аргументом "size":"Small" .

Функция 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 , и еще один для заказа кофе. Для тестирования сервиса истории заказов вы могли бы отправить фиктивный объект, который возвращает идентификатор кофейного продукта.

В этом примере вы оцениваете, понимает ли модель намерение запроса, выбирает ли правильный инструмент и предоставляет ли этот инструмент необходимую информацию для выполнения действий. Если модель не вызывает 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 .
• Ознакомьтесь с нашим курсом «Создание оценок с помощью ИИ» .