Google и Microsoft представили WebMCP для ИИ-агентов

Когда ИИ-агент заходит на веб-сайт, по сути, он ведет себя как турист, не говорящий на местном языке. Будь то агент на базе LangChain, Claude Code или набирающего популярность фреймворка OpenClaw, ему приходится лишь догадываться, какие кнопки нажимать: парсить «сырой» HTML, отправлять скриншоты мультимодальным моделям и сжигать тысячи токенов просто для того, чтобы найти строку поиска.

Возможно, эта эпоха подходит к концу. На этой неделе команда Google Chrome выпустила WebMCP (Web Model Context Protocol) в качестве ранней предварительной версии в Chrome 146 Canary. WebMCP, разработанный совместно инженерами Google и Microsoft и прошедший инкубацию в группе сообщества по веб-машинному обучению W3C, представляет собой предлагаемый веб-стандарт, который позволяет любому сайту предоставлять структурированные вызываемые инструменты напрямую ИИ-агентам через новый API браузера: navigator.modelContext.

Последствия для корпоративного ИТ-сектора весьма значительны. Вместо того чтобы создавать и поддерживать отдельные бэкенд-серверы MCP на Python или Node.js для подключения своих веб-приложений к ИИ-платформам, команды разработчиков теперь могут упаковать существующую клиентскую логику JavaScript в читаемые для агентов инструменты — без перестройки архитектуры хотя бы одной страницы.

ИИ-агенты — это дорогие и хрупкие «туристы» в интернете

Проблемы с затратами и надежностью при текущих подходах к взаимодействию веб-агентов (браузерных агентов) хорошо известны всем, кто внедрял их в масштабных проектах. Два доминирующих метода — визуальный скрапинг экрана и парсинг DOM — страдают от фундаментальных неэффективностей, которые напрямую бьют по корпоративным бюджетам.

При подходах на основе скриншотов агенты передают изображения в мультимодальные модели (такие как Claude и Gemini) в надежде, что модель сможет определить не только то, что находится на экране, но и где расположены кнопки, поля форм и интерактивные элементы. Каждое изображение потребляет тысячи токенов и может вызывать значительную задержку. При подходах на основе DOM агенты считывают «сырой» HTML и JavaScript — незнакомый язык, полный различных тегов, CSS-правил и структурной разметки, которая не имеет отношения к текущей задаче, но все равно расходует пространство контекстного окна и ресурсы на инференс.

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

Как работает WebMCP: два API, один стандарт

WebMCP предлагает два взаимодополняющих API, которые служат мостом между веб-сайтами и ИИ-агентами.

Декларативный API (Declarative API) обрабатывает стандартные действия, которые можно определить непосредственно в существующих HTML-формах. Для организаций с уже готовыми и хорошо структурированными формами этот путь требует минимальных дополнительных усилий: добавив имена и описания инструментов в существующую разметку формы, разработчики могут сделать эти формы доступными для вызова агентами. Если ваши HTML-формы уже чистые и хорошо структурированы, вы, вероятно, уже на 80% у цели.

Императивный API (Imperative API) обрабатывает более сложные, динамические взаимодействия, требующие выполнения JavaScript. Здесь разработчики определяют более богатые схемы инструментов, концептуально похожие на определения инструментов, отправляемые в конечные точки API OpenAI или Anthropic, но работающие полностью на стороне клиента в браузере. С помощью registerTool() веб-сайт может предоставлять такие функции, как searchProducts(query, filters) или orderPrints(copies, page_size), с полными схемами параметров и описаниями на естественном языке.

Ключевая идея заключается в том, что один вызов инструмента через WebMCP может заменить то, что раньше могло потребовать десятков взаимодействий с браузером. Сайт электронной коммерции, регистрирующий инструмент searchProducts, позволяет агенту сделать один структурированный вызов функции и получить структурированные результаты в формате JSON, вместо того чтобы заставлять агента кликать по выпадающим спискам фильтров, прокручивать результаты с пагинацией и делать скриншоты каждой страницы.

Корпоративный аспект: стоимость, надежность и конец хрупкого скрапинг-парсинга

Для ИТ-директоров, оценивающих внедрение агентного ИИ, WebMCP одновременно решает три хронические проблемы.

Снижение затрат — наиболее быстро поддающаяся количественной оценке выгода. Заменив цепочки захвата скриншотов, вызовов мультимодального инференса и итеративного парсинга DOM одиночными вызовами структурированных инструментов, организации могут рассчитывать на значительное сокращение потребления токенов.

Надежность возрастает, поскольку агентам больше не нужно гадать о структуре страницы. Когда веб-сайт явно публикует контракт инструмента («вот функции, которые я поддерживаю, вот их параметры, вот что они возвращают»), агент действует наверняка, а не на основе предположений. Неудачные взаимодействия из-за изменений пользовательского интерфейса, загрузки динамического контента или двусмысленного определения элементов практически исключаются для любого действия, покрытого зарегистрированным инструментом.

Скорость разработки увеличивается, так как веб-команды могут использовать свой существующий фронтенд-код на JavaScript вместо развертывания отдельной бэкенд-инфраструктуры. В спецификации подчеркивается, что любая задача, которую пользователь может выполнить через пользовательский интерфейс страницы, может быть превращена в инструмент путем повторного использования большей части существующего кода страницы на JavaScript. Командам не нужно изучать новые серверные фреймворки или поддерживать отдельные поверхности API для агентов-потребителей.

Human-in-the-loop по замыслу, а не как afterthought (доработка «на потом»)

Важнейшее архитектурное решение отличает WebMCP от парадигмы полностью автономных агентов, которая доминировала в недавних новостных заголовках. Стандарт явно разработан с расчетом на совместные рабочие процессы с участием человека (human-in-the-loop), а не на неконтролируемую автоматизацию.

По словам Кушала Сагара (Khushal Sagar), штатного инженера-программиста Chrome, в спецификации WebMCP выделены три столпа, лежащих в основе этой философии.

1. Контекст (Context): Все данные, необходимые агентам для понимания того, что делает пользователь, включая контент, который часто в данный момент невидим на экране.

2. Возможности (Capabilities): Действия, которые агент может совершать от имени пользователя: от ответов на вопросы до заполнения форм.

3. Координация (Coordination): Управление передачей контроля между пользователем и агентом, когда агент сталкивается с ситуациями, которые он не может решить автономно.

Авторы спецификации из Google и Microsoft иллюстрируют это на примере сценария с покупками: пользовательница по имени Майя просит своего ИИ-ассистента помочь найти экологичное платье для свадьбы. Агент предлагает продавцов, открывает браузер на сайте платьев и обнаруживает, что на странице представлены такие WebMCP-инструменты, как getDresses() и showDresses(). Когда критерии Майи выходят за рамки базовых фильтров сайта, агент вызывает эти инструменты для получения данных о товарах, использует собственные рассуждения для фильтрации по критерию «подходит для коктейльного дресс-кода», а затем вызывает showDresses(), чтобы обновить страницу, оставив на ней только релевантные результаты. Это плавный цикл человеческого вкуса и возможностей агента — именно тот тип совместного серфинга, для поддержки которого создан WebMCP.

Это не стандарт для headless-браузеров (работающих без графического интерфейса). В спецификации прямо указано, что headless-сценарии и полностью автономные сценарии не являются целью проекта. Для таких вариантов использования авторы ссылаются на существующие протоколы, такие как протокол Agent-to-Agent (A2A) от Google. WebMCP ориентирован на браузер, где присутствует пользователь — он наблюдает за процессом и сотрудничает с системой.

Не замена MCP, а дополнение

WebMCP не является заменой Model Context Protocol от Anthropic, несмотря на общее концептуальное происхождение и часть названия. Он не следует спецификации JSON-RPC, которую MCP использует для клиент-серверного взаимодействия. В то время как MCP работает в качестве бэкенд-протокола, соединяющего ИИ-платформы с поставщиками услуг через размещенные серверы, WebMCP работает полностью на стороне клиента внутри браузера.

Эти отношения носят взаимодополняющий характер. Туристическая компания может поддерживать бэкенд-сервер MCP для прямых интеграций API с ИИ-платформами, такими как ChatGPT или Claude, и одновременно внедрять инструменты WebMCP на своем ориентированном на потребителя веб-сайте, чтобы браузерные агенты могли взаимодействовать с процессом бронирования в контексте активной сессии пользователя. Оба стандарта обслуживают разные паттерны взаимодействия без конфликтов.

Это различие имеет значение для корпоративных архитекторов. Бэкенд-интеграции MCP подходят для автоматизации «сервис-сервис», где не нужен пользовательский интерфейс браузера. WebMCP уместен тогда, когда пользователь присутствует и взаимодействие выигрывает от общего визуального контекста — что описывает подавляющее большинство ориентированных на потребителя веб-взаимодействий, которые волнуют предприятия.

Что дальше: от флага к стандарту

WebMCP в настоящее время доступен в Chrome 146 Canary за флагом «WebMCP for testing» по адресу chrome://flags. Разработчики могут присоединиться к программе раннего ознакомления с Chrome (Early Preview Program) для получения доступа к документации и демоверсиям. Другие браузеры пока не объявляли сроки реализации, хотя то, что Microsoft выступает соавтором спецификации, делает появление поддержки в Edge весьма вероятным.

Наблюдатели отрасли ожидают официальных анонсов от разработчиков браузеров к середине-концу 2026 года, причем Google Cloud Next и Google I/O являются наиболее вероятными площадками для заявлений о более широком развертывании. Спецификация переходит от инкубации в сообществе W3C к официальному черновику (draft) — процесс, который исторически занимает месяцы, но свидетельствует о серьезных институциональных намерениях.

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

Воплотится ли это видение в жизнь, зависит от уровня внедрения — как со стороны производителей браузеров, так и со стороны веб-разработчиков. Но поскольку Google и Microsoft совместно выпускают код, W3C предоставляет институциональную поддержку, а Chrome 146 уже запускает реализацию за флагом, WebMCP преодолел самое трудное препятствие, с которым сталкивается любой веб-стандарт: путь от предложения до работающего программного обеспечения.