WebMCP — это предлагаемый веб-стандарт, который предоставит ИИ-агентам своего рода ментальную модель возможностей веб-приложения через API браузера, что позволяет сэкономить время и токены.
Одна из важнейших вещей, которые мы поняли об искусственном интеллекте, заключается в том, что его сильные стороны не обязательно связаны с тем, что он умеет «из коробки», а скорее с теми инструментами, которые мы можем ему дать для расширения его базовых возможностей.
Основные базовые модели, с которыми мы часто работаем, справляются с большинством задач средне или неплохо. Если мы хотим, чтобы они справлялись отлично (а мы хотим), нам нужно начать накладывать другие подходы, чтобы расширить их функционал. Это может быть промпт-инжиниринг, добавление более качественного (или большего объема) контекста, отслеживание памяти, написание навыков, включая дополненную генерацию с извлечением (RAG), использование серверов MCP и многое другое.
Тем не менее, все это — вещи, которые мы добавляем к самому ИИ для расширения его возможностей. Что если вместо этого изменить подход и расширить возможности того, с чем ИИ гарантированно будет взаимодействовать? В этом и заключается основная идея WebMCP.
WebMCP — это предлагаемый веб-стандарт и API браузера, который позволяет веб-приложениям представлять функциональность в виде структурированных инструментов, которые ИИ-агенты могут обнаруживать и использовать. Вместо того чтобы агент пытался понять, как работает ваше приложение, исследуя интерфейс, совершая догадки и повторяя итерации, что если мы сможем предоставить всю необходимую метаинформацию заранее?
Наделение агентов «ментальными моделями»
При проектировании интерфейсов мы во многом полагаемся на ментальные модели наших пользователей. Когда мы показываем человеку выпадающий список с надписью «Добавить в корзину», мы рассчитываем на то, что он понимает стандартные шаги процесса оформления заказа, знает, что может найти страницу корзины, нажав на значок корзины в шапке сайта, и так далее. Наши пользователи вырабатывают такое понимание на основе другого похожего опыта работы в интернете и навигации по другим интерфейсам. Но с ИИ это так не работает.
ИИ не формирует автоматически такое же высокоуровневое понимание паттернов интерфейса с течением времени так, как это делают люди. Если эта информация не предоставляется явно через контекст, память, обучение или инструменты, то каждый новый интерфейс может потребовать от агента «начинать все сначала» в понимании того, как работает пользовательский интерфейс.
Если вы когда-нибудь наблюдали за рабочим процессом агента при просмотре веб-страниц, вы, вероятно, видели общий паттерн: агент изучает страницу, определяет нужный элемент, определяет, как с ним взаимодействовать, а затем выполняет действие. В зависимости от агента и браузера, это изучение может включать в себя DOM, информацию о доступности (accessibility), скриншоты или другие API браузера. Если это вызывает изменения на странице, весь процесс начинается заново. Даже кажущиеся простыми задачи, такие как выбор значения из большого выпадающего списка, могут занять у агента несколько минут и множество, множество циклов для фактического выполнения.
Мало того, что это медленно, неэффективно и чревато большим количеством ошибок и возвратов к предыдущим шагам, при нынешней стоимости токенов это может обойтись довольно дорого (в зависимости от сложности страницы и действия, которое агент пытается выполнить). WebMCP стремится изменить это, позволяя веб-приложениям представлять свои возможности в виде структурированных инструментов.
С WebMCP агент может получить описание этих возможностей из браузера — назначение функции, какие входные данные она принимает, какие значения разрешены и т. д., — вместо того чтобы выводить их из отрисованного пользовательского интерфейса. Имея в виду, что WebMCP все еще является предлагаемым API и синтаксис еще не окончательно утвержден (фактически, он недавно изменился с navigator.modelContext на document.modelContext), наш выпадающий список мог бы предложить ИИ примерно следующее:
Здесь мы видим важную информацию, такую как тип ввода, допустимые значения, обязательные поля и описания — все это заранее передается модели. В некотором смысле это очень похоже на семантический HTML: вместо того чтобы заставлять браузер догадываться о значении элемента по его внешнему виду или поведению, мы явно предоставляем информацию о его назначении и семантике. WebMCP применяет аналогичную идею к возможностям приложения, предоставляя агенту структурированное описание того, что он может делать и каких входных данных ожидает.
Это также может быть расширено за счет добавления функционала. Современные веб-приложения уже содержат функции, представляющие действия, которые могут совершать пользователи. Наш пример с покупками, вероятно, включает такие функции, как addToCart() или updateProfile(), которые в настоящее время могут вызываться в ответ на события пользовательского интерфейса, а также могут быть представлены как возможности, доступные агенту.
В чем разница между сервером MCP и WebMCP?
Основное различие заключается в задействовании браузера. Традиционный MCP позволяет ИИ-приложению подключаться к серверу MCP, который предоставляет инструменты и другие возможности. В случае с WebMCP эти инструменты и возможности предоставляются через браузер. MCP и WebMCP не являются конкурентами или заменой друг другу; они служат разным целям в разных контекстах. Их объединяет лишь то, что они предоставляют релевантные инструменты для ИИ, хотя и делают это совершенно по-разному.
Когда мы говорим о сервере MCP (таком как сервер Progress Telerik и Kendo MCP), схема выглядит (примерно) следующим образом:
ИИ-приложение → Клиент MCP → Сервер MCP → Внешний сервис
Для WebMCP это выглядит больше так:
ИИ-агент → Браузер → Веб-приложение → Логика приложения / API
Например, мы используем сервер Telerik MCP, чтобы предоставить вашему ИИ-помощнику по программированию доступ к информации и инструментам, специфичным для Kendo UI и Telerik (например, Upgrade Assistant). С другой стороны, наша поддержка WebMCP позволяет вам выводить эту дополнительную информацию и функциональность (как описано выше в примере с выпадающим списком) непосредственно в наших компонентах Telerik и Kendo UI для ИИ-агентов, взаимодействующих с приложениями, которые их содержат.
Общая цель у обоих подходов одна — оснастить ИИ дополнительными инструментами и контекстом, которые ему необходимы, — но подход отличается.
Нужно ли мне внедрять WebMCP в свое приложение сегодня?
Короткий ответ: нет, это еще не актуально.
Более длинный ответ: пока нет, но надеемся, что скоро! И независимо от того, как изменится синтаксис с настоящего момента и до момента его официального запуска (а я уверен, что он изменится), основная идея, на мой взгляд, заслуживает того, чтобы за ней следить.
Теперь мы переходим в сферу личного мнения, спекуляций о будущем и так называемого «идейного лидерства» (thought leadership), так что отнеситесь к этому абзацу с доля скептицизма. По моему мнению, WebMCP — одна из самых захватывающих вещей, появившихся в сфере ИИ, благодаря всем тем возможностям, которые она открывает для улучшения пользовательского опыта не только для ИИ. В сфере доступности это явление называют «эффектом пандуса» — когда решение приносит пользу не только целевой аудитории, но и гораздо большему количеству людей. Чем более стандартизированным для нас становится предоставление такого рода контекстной информации в веб-приложениях, тем шире ее смогут использовать не только агенты, но потенциально также браузеры, программы чтения с экрана (и другие вспомогательные технологии) и альтернативные устройства ввода. Существуют ли возможности для агентского серфинга, которые могли бы сделать интернет более доступным для большего числа пользователей?
Прямо сейчас некоторая аналогичная информация (имя, описание, роль и состояние) уже передается элементами в DOM — и, как следствие, в дерево доступности — с помощью семантических элементов HTML и ARIA. Сможет ли WebMCP в конечном итоге предложить нам способ создания стандартизированного синтаксиса, дружественного к ИИ, который предоставляет не только эту информацию, но и более глубокое понимание связанного функционала, типов данных и многого другого? В процессе создания веб-ресурсов, более дружественных к агентам, я считаю, у нас есть реальная возможность сделать их более дружественными и для людей.
