Cloudflare обновила Kitesurf — браузерный движок для ИИ-агентов, работающий на инфраструктуре Cloudflare Workers. Главным изменением стала поддержка WebMCP: сайты могут предоставлять агенту доступные действия в виде программных инструментов, а не заставлять его искать элементы интерфейса и имитировать клики.
Компания также расширила поддержку веб-стандартов, оптимизировала операции с DOM и обеспечила Kitesurf полное покрытие API платформы Browser Run. Согласно сообщению Cloudflare, движок теперь проходит более 730 000 подтестов Web Platform Tests — примерно на 500 000 больше, чем при первом анонсе проекта в августе.
Эти показатели и заявления о производительности исходят от самой Cloudflare. Независимых сравнительных тестов Kitesurf с Chrome, Chromium или другими браузерными движками в доступных материалах нет.
WebMCP заменяет часть кликов вызовами инструментов
Обычная браузерная автоматизация зависит от структуры страницы: агент ищет кнопку, поле или ссылку по селектору, выполняет действие и проверяет результат. Такой сценарий может перестать работать после изменения верстки, появления всплывающего окна или задержки при загрузке интерфейса.
WebMCP предлагает другой способ взаимодействия. Сайт публикует набор доступных инструментов, которые агент может обнаружить и вызвать программно. Например, вместо поиска элементов формы агент теоретически может обратиться к функции поиска рейсов или смены региона, если разработчик сайта предусмотрел такие возможности.
В демонстрации Cloudflare сервис Radar предоставляет Kitesurf инструменты с названиями navigate-to и set-location. Посмотреть их можно в публичной песочнице браузера через раздел WebMCP в панели DevTools. Для подключения внешнего агента Cloudflare предлагает использовать MCP-клиент с WebSocket-адресом Browser Run и токеном авторизации.
Это не означает, что Kitesurf сможет управлять любым сайтом через WebMCP. Программные инструменты должны быть доступны на стороне конкретного ресурса либо добавлены средствами Cloudflare. На сайтах без такой интеграции агенту по-прежнему потребуется обычная работа с DOM, селекторами и событиями.
Совместимость выросла до 730 000 подтестов WPT
После первоначального выпуска разработчики Kitesurf добавили несколько механизмов, необходимых современным JavaScript-приложениям:
- разрешение модулей по URL;
- загрузку JSON-модулей;
- обработку import maps;
- импорт через модульный реестр Cloudflare Workers;
- более предсказуемую загрузку и изоляцию iframe;
- улучшенное отображение текста внутри фреймов для разных языков и кодировок.
Для проверки реализации веб-стандартов команда использует Web Platform Tests. Это открытый набор тестов, над которым совместно работают разработчики браузеров и участники веб-сообщества; его репозиторий опубликован на GitHub.
По данным Cloudflare, Kitesurf проходит свыше 730 000 подтестов WPT. При запуске проекта результат был примерно на 500 000 меньше. Рост показывает, что движок научился обрабатывать больше браузерных API и сценариев, однако число нельзя напрямую интерпретировать как процент совместимости с Chrome.
В WPT входят разные группы тестов, а итог зависит от выбранной конфигурации, версии набора и условий запуска. Cloudflare не приводит в публикации сопоставимый результат для других браузеров в той же среде. Поэтому показатель полезен прежде всего как внутренняя динамика развития Kitesurf, а не как доказательство его равенства полноценному Chromium.
Оптимизации нацелены на цикл работы агента
Для браузерного агента важна не только скорость первой загрузки страницы. Задержка накапливается при каждом повторении цикла: получить состояние страницы, передать его модели, выбрать действие, выполнить команду и проверить результат.
Cloudflare сообщает, что оптимизировала обход DOM, обработку таймеров и получение шрифтов. Цель изменений — уменьшить время, в течение которого модель ожидает браузерный движок. По утверждению компании, добавление новых веб-API не привело к заметному росту общего времени выполнения и потребления CPU относительно стартовой версии Kitesurf; в некоторых внутренних сценариях показатели улучшились.
Подробных результатов по отдельным сайтам, конфигурациям и типам нагрузки Cloudflare не опубликовала. Командам, рассматривающим Kitesurf для рабочих агентов, стоит измерять не только время открытия страницы, но и продолжительность полного задания: количество неудачных действий, повторных обращений к модели и восстановлений после изменения DOM.
Browser Run получил единый набор способов управления
Kitesurf теперь поддерживает всю заявленную поверхность API Cloudflare Browser Run. Управлять браузером можно через Chrome DevTools Protocol, Playwright, Puppeteer или MCP. Документация открытого Chrome DevTools Protocol показывает базовую модель удаленного управления вкладками, сетью и DOM, а Playwright предоставляет более высокий уровень автоматизации.
Для разработчиков, уже использующих Browser Run, это должно упростить эксперимент: Kitesurf можно выбрать как вариант браузера без полной переработки существующей интеграции. Фактическая переносимость сценария все равно зависит от используемых API и особенностей сайта.
Расширилась и поддержка Quick Actions — готовых операций для создания скриншотов, извлечения HTML и генерации PDF. Ранее они были доступны для Kitesurf через REST API, а теперь их можно вызывать внутри Worker-скрипта с помощью привязки `env.BROWSER.quickAction()`. В приведенном Cloudflare примере разработчик передает URL, выбирает действие `screenshot` и указывает `kitesurf` в качестве браузера.
Рендеринг в терминале пока стоит считать демонстрацией архитектуры
Kitesurf разделяет выполнение кода страницы и формирование изображения. Компонент PageScript обрабатывает сессию и запускает код сайта, а PageRenderer преобразует рассчитанное состояние страницы в визуальный результат. Такое разделение позволяет оставить выполнение недоверенного кода на стороне Cloudflare, а отображение перенести в другой Worker или клиентское приложение.
В обновленной демонстрации PageRenderer выводит страницу через графический протокол Kitty, который поддерживают терминалы Kitty, Ghostty и WezTerm. Cloudflare также показала текстовый режим на основе ANSI для окружений без графического интерфейса.
Терминальный вывод может пригодиться при отладке агентов на удаленных серверах или в средах разработки без рабочего стола. При этом публикация не подтверждает, что такой рендеринг уже является стабильной частью всех тарифов и сценариев Browser Run. Пока его разумнее рассматривать как демонстрацию возможностей раздельной архитектуры Kitesurf.
Что проверить перед переносом агента на Kitesurf
Разработчикам стоит начать не с синтетического показателя WPT, а с нескольких реальных задач своего агента. Полезно сравнить Kitesurf с текущим браузером по четырем параметрам:
- проходит ли авторизация и корректно ли загружаются iframe;
- работают ли используемые JavaScript-модули и динамические интерфейсы;
- сколько времени занимает полный агентный цикл, включая обращения к модели;
- как часто сценарий требует повторного клика, нового селектора или ручного восстановления.
Отдельно следует проверить, действительно ли целевой сайт предоставляет WebMCP-инструменты. Наличие поддержки протокола в браузере само по себе не делает доступными функции сайта. Если WebMCP нет, надежность по-прежнему будет зависеть от качества DOM-автоматизации.
Обновление сокращает разрыв между экспериментальным движком Cloudflare и привычными средствами браузерной автоматизации, но опубликованные цифры пока описывают прежде всего прогресс самого проекта. Для решения о рабочем внедрении нужны тесты на конкретных сайтах, а также проверка API, которые использует агент.
