Скриншоты — проклятие AI-агентов. Наконец-то появился выход
Если вы хоть раз запускали AI-агента для работы с сайтами, вы знаете эту боль. Агент открывает страницу, делает скриншот, прогоняет его через мультимодальную модель — и ждет 10 секунд, сжигая сотни тысяч токенов. Потом щелкает кнопку, снова скриншот... Это безумие. Мы привыкли, что по-другому нельзя. Но в апреле 2026 года появился черновик спецификации WebMCP, который разом ломает эту парадигму.
WebMCP — это расширение протокола Model Context Protocol (MCP) для веба. Вместо картинок агент получает структурированное DOM-дерево с координатами интерактивных элементов, атрибутами и текстовым контентом. Никаких скриншотов — только чистый JSON с metadata. Скорость? Вместо 5-10 секунд на снятие скриншота — 50 миллисекунд на передачу схемы. Экономия токенов — до 90% по сравнению с мультимодальным анализом.
Суть: WebMCP превращает любой сайт в API для AI-агента. Агент получает не картинку, а полную карту страницы: какие кнопки, где форма ввода, какие ссылки — и может действовать сразу.
Давайте разберем, как это работает и почему это меняет правила игры.
Откуда взялась идея — и почему именно сейчас
Проблема скриншотов не нова. Еще в 2024-2025 годах появились обходные пути: TextWeb пытался выдергивать текст вручную, Screen Vision учил нейронки понимать пиксели. Но корень зла — в самом подходе. Мультимодальные модели (даже GPT-4.5, Gemini 2.5 Ultra) тратят кучу ресурсов на распознавание кнопок и текста, хотя вся необходимая информация уже есть в DOM.
WebMCP родился как ответ на этот абсурд. Разработчики из Anthropic и нескольких opensource-команд (включая ребят из проекта Agent-browser от Vercel) осознали: если агент может парсить DOM напрямую, зачем делать скриншот? Черновик спецификации опубликовали в конце марта 2026 года, и уже к началу мая его поддержали многие фреймворки.
Кстати, это отличный ответ на критику мультимодальных ИИ: мол, они дороги, медленны и неуклюжи. WebMCP предлагает принципиально другой путь — без картинок.
Как это выглядит на практике: молниеносная навигация
Представим типичную задачу: агент заходит на сайт авиакомпании, выбирает рейс из Москвы в Берлин, заполняет форму и оплачивает. Со скриншотами: открыли страницу -> скриншот -> отправили в LLM -> LLM распознала -> сгенерировала действие -> клик -> новый скриншот... Пауза между шагами — 8-12 секунд. Итог: покупка билета занимает 2-3 минуты.
WebMCP: браузер (или прокси-слой) отдает DOM-дерево в виде JSON по протоколу MCP. Агент получает список всех интерактивных элементов с координатами и состояниями (активна/неактивна кнопка, есть ошибки в полях). Он выбирает селектор, кликает. Весь цикл — 200-300 мс. Билет куплен за 15 секунд.
Но есть нюанс: DOM может быть огромным. Для страниц с тысячами элементов полная выгрузка весит больше, чем сжатый JPEG. Поэтому WebMCP использует умный фильтр: передает только кликабельные и видимые узлы, плюс их текстовую близость. Тесты показывают, что типичный размер ответа — 5-15 КБ против 200-800 КБ для скриншота.
Неудивительно, что проект TextWeb уже адаптируется под WebMCP: авторы говорят, что новый протокол делает их подход (выдергивание текста) вторичным.
Экономия железа и денег: конкретные цифры
Приведу данные из первых бенчмарков, опубликованных командой WebMCP 2 мая 2026 года. Протестировали трех популярных агентов: браузерного ассистента на базе LM Studio MCP с локальной моделью, облачного агента на Claude 4.5 и гибридного на Llama 5. Задачи: бронирование отеля, поиск товара на маркетплейсе, регистрация на сайте.
| Метрика | Со скриншотами (мультимодальные) | WebMCP |
|---|---|---|
| Среднее время на шаг | 6.4 с | 0.28 с |
| Токенов на шаг (вход) | ~45 000 | ~1 200 |
| Общая стоимость задачи (10 шагов) | $0.35 (через API) | $0.01 |
| Успешность выполнения | 94% | 98% |
Да, успешность выше — потому что нет ошибок распознавания текста на скриншоте. Особенно на сайтах с нестандартными шрифтами или темными темами. Агент просто читает actual HTML content.
Кстати, Screen Vision, который делал упор на скриншоты, сейчас экстренно добавляет поддержку WebMCP. Создатели признают: в лобовых тестах на сложных SPAPage (например, Google Sheets) скриншоты падают, а WebMCP справляется.
Темная сторона: безопасность и сопротивление сайтов
Не все так радужно. WebMCP по сути дает агенту доступ к полному DOM, включая скрытые поля, метаданные, возможно, защищенные элементы. Это мощный инструмент, но и риск: злой агент может прочитать содержимое страниц, которое не видит пользователь (например, данные с модальных окон, которые не отрисовываются).
Спецификация включает зоны privacy: сайты могут запрещать передачу определенных полей (с паролями, токенами) через атрибут data-webmcp-exclude. Но это опционально. На практике уже появились сервисы (типа Cloudflare), которые начали блокировать WebMCP-запросы, считая их автоматизированным scraping'ом.
Кстати, это похоже на ситуацию с кризисом MCP-серверов, где 52% endpoint'ов оказались мертвыми. WebMCP может постичь та же участь, если владельцы сайтов не захотят поддерживать новый протокол. Но, к счастью, спецификация работает и без явной поддержки: можно внедрить на уровне браузера или расширения с помощью JavaScript (хотя это уже менее безопасно).
Что это меняет для разработчиков и веб-сервисов
Если раньше AI-агенты были дорогой игрушкой для хакеров и энтузиастов, то WebMCP делает их дешевыми и быстрыми. Это прямая дорога к массовому использованию: персональные ассистенты, которые покупают билеты, бронируют столики, управляют подписками — все это станет реальностью уже в 2026–2027.
Веб-сервисам придется адаптироваться: если ваш сайт не отдает корректный DOM (с перегруженным JavaScript, динамическими ID), агенты на WebMCP будут работать плохо. Google и Яндекс уже задумываются о том, чтобы ранжировать страницы по их пригодности для AI-агентов — новый SEO-фактор. Шутка? Вовсе нет.
Кстати, проект WordPress.com и AI-агенты как раз показывает, как MCP уже интегрируется в CMS: теперь WebMCP позволит агентам не только писать посты, но и настраивать тему, менять блоки — без скриншотов, через структурированное взаимодействие.
Неочевидный прогноз: конец эры визуального распознавания для веб-агентов?
Многие скажут: но как же капчи, сложные графики, защищенные области? WebMCP не отменяет мультимодальность полностью. Для задач, где визуальная информация критична (например, анализ графика на сайте), по-прежнему нужны скриншоты. Но для 90% повседневных действий — заполнение форм, клики, навигация — WebMCP станет стандартом.
Совет для разработчиков: не ждите, пока ваш любимый фреймворк официально поддержит WebMCP. Можно уже сейчас написать простой MCP-сервер, который будет выгружать DOM через браузерное расширение или headless-браузер. Пример кода? Не буду, гуглите — но это банально 50 строк на Node.js. Главное — начать тестировать свои агенты в новом формате.
WebMCP не идеален. Он зависит от готовности площадок и борьбы с безопасностью. Но это первый реальный шаг к тому, чтобы AI-агенты перестали быть дорогими калеками, которые смотрят на мир через грязное стекло скриншота. Возможно, через год мы будем вспоминать мультимодальный подход к вебу так же, как сейчас вспоминаем dial-up модемы — с улыбкой и ужасом.
