Как тестировать WebMCP с помощью Evals

Kasper Kulikowski
Kasper Kulikowski

Дата публикации: 19 мая 2026 г. Последнее обновление: 28 мая 2026 г.

Объяснение Веб Расширения Статус Chrome Намерение
GitHub Эксперимент с источником – эксперимент с источником Открыть Намерение провести эксперимент

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

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

Напишите оценки, чтобы проверить точки взаимодействия вашей системы с большой языковой моделью (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 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" }
            }
          ]
        }
      ]
    }
  ]
}

Как оценивать сбои в середине цепочки

Примеры вызовов функций для пользователя, который хочет заказать пиццу со скидкой
Когда пользователь хочет заказать пиццу с купоном на скидку, последовательно вызывается цепочка инструментов: start_pizza_creator, set_pizza_style, set_pizza_size, start_checkout, add_discount_coupon и complete_checkout. Операция add_discount_coupon не удалась, но процесс был завершен, поэтому пользователь не получил скидку.

Иногда агенту нужно последовательно использовать несколько инструментов. Что произойдет, если инструмент перестанет работать в середине процесса? Например, пользователь хочет заказать пиццу, используя промокод:

"Я хочу маленькую пиццу с песто. Используй мой промокод: FreePizza".

Возможно, агент не сможет найти пиццу по цене add_discount_coupon и перейдет к оформлению заказа по полной цене. Чтобы протестировать инструмент add_discount_coupon, вы можете вручную выполнить эту последовательность вызовов инструмента, не взаимодействуя с моделью, чтобы имитировать этот сценарий. Приведите приложение в состояние, в котором, по вашему мнению, инструмент не сможет работать. В этом случае это инструмент start_checkout. Затем вы можете оценить add_discount_coupon отдельно.

Экспериментируйте с WebMCP

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