Автономные браузерные ИИ-агенты: тестирование веба и скрейпинг

Что автономные браузерные ИИ-агенты умеют на самом деле

Короткий ответ: навигация и сбор данных у браузерных агентов получаются сносно, заполнение форм держится на стабильной вёрстке, а многозвенные сценарии с оплатой остаются лотереей.

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

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

Класс задач	Реальное состояние	Где ломается
Навигация и сбор данных	Работает сносно	Редкие выпадающие меню, ленивая загрузка контента
Заполнение форм	Работает при стабильной вёрстке	Нестандартные виджеты, смена селекторов после релиза
Многозвенные процессы с оплатой	Пока лотерея	Лишний клик, повторная отправка, потерянная корзина

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

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

Третий класс — сквозные бизнес-процессы с оплатой. Здесь цена ошибки максимальна, а допуск по надёжности минимален. Один неверный клик — и вместо заказа получаем списание, дубль заявки или пустую корзину на кассе.

Рынок при этом двигается быстро. «Яндекс Браузер» открыл закрытый альфа-тест «Алисы» в режиме ИИ-агента: она сама выбирает пункты меню, заполняет формы и жмёт ссылки, а разработчики заявляют об адаптации к изменениям на веб-страницах — подробности альфа-теста. Отдельная ветка решений бьёт в главную боль всех агентов — экраны авторизации и антибот-защиту: Kimi WebBridge от Moonshot AI работает как расширение плюс локальный daemon и управляет вашим реальным браузером через Chrome DevTools Protocol, а не через headless-прослойку.

Для инженера вывод простой: агент — это усилитель, а не замена тестировщика. И прежде чем подключать его к живым системам, стоит разобраться, как ограничивать доступ к инструментам и данным — об этом мы подробно писали в материале про MCP-протокол и корпоративные базы данных.

Под капотом: дерево доступности, скриншоты и Chrome DevTools Protocol

Браузерный агент работает в три слоя: воспринимает страницу как дерево доступности плюс визуальный снимок, принимает решение языковой моделью и исполняет действие через Chrome DevTools Protocol (CDP) — внедрённым скриптом либо кликом по координатам.

Начнём с восприятия. Дерево доступности — это текстовая карта интерфейса: роли, подписи, состояния вроде «кнопка, нажата», «поле, обязательно». Для модели это идеальный вход: компактно, без CSS-шума и разметки на тысячи строк. Именно поэтому агенты цепляются за подписи и роли, а не за имена классов.

Одного дерева мало. Половина современного интерфейса — это графические полотна, иконки без подписи, выпадашки с перекрытием. Поэтому агент делает скриншот и накладывает на него нумерованные метки, а модели отдаёт картинку с легендой. Так работает связка «дерево плюс визуальный снимок»: текст даёт смысл, картинка — геометрию.

Дальше решение. На рутинных шагах держат дешёвые и быстрые Gemini Flash или DeepSeek, на планировании и разборе завалов подключают Claude Sonnet, Gemini Pro, ChatGPT. Разделение по цене здесь не роскошь, а необходимость.

Исполнение — самая приземлённая часть. Через CDP агент выполняет внедрённый скрипт, ставит фокус, печатает текст, а если не вышло — стреляет мышью по координатам. Клик по пикселям работает всегда, но ничего не знает о смысле страницы: промах на 20–30 пикселей, и вы уже нажали не ту кнопку.

Теперь про узкое горлышко. Опыт публичных разборов показывает: тормозит не модель, а ожидание динамического контента и нестабильные селекторы. Гидратация интерфейса, подгрузка карточек, анимации — агент щёлкает по элементу раньше, чем он стал кликабельным.

Селекторы ломаются ещё охотнее. Классы генерирует сборщик, разметку перетасовывает A/B-тест, и вчерашний сценарий сыпется на ровном месте. Отсюда и движение к работе в реальном браузере: Kimi WebBridge от Moonshot AI идёт как браузерное расширение плюс локальный демон и управляет живым окном по CDP — разбор инструмента как раз про экраны авторизации и антибот-защиту.

Масштаб проблемы честно измерили в исследовании Decodo: 45 агентов проверили по десяти способностям, и ни один не набрал максимум. «Яндекс» в альфа-тесте «Алисы» как ИИ-агента отдельно подчёркивает адаптацию к изменениям на страницах — детали теста на Хабре. А наш материал про MCP и корпоративные базы данных показывает, как тот же слой инструментов подключают к внутренним системам.

Kimi WebBridge, Playwright и BrowserMCP: сравнительная таблица подходов

Четыре ветки различаются точкой подключения: Playwright управляет движком напрямую, визуальные драйверы идут через интерфейс, MCP-мосты отдают браузер языковой модели, а расширения-агенты вроде Kimi WebBridge работают в реальном профиле по Chrome DevTools Protocol.

Выбор здесь не про «что современнее», а про то, где именно ломается ваш конвейер обработки. Классический Playwright выигрывает на скорости и повторяемости, но спотыкается о капчу и формы с поведенческим анализом. Агентные подходы берут эту планку, зато приносят недетерминированность и счёт за токены.

Ветка решения	Способ подключения	Прохождение авторизации	Устойчивость к антибот-защите	Скорость	Стоимость запуска	Пригодность для непрерывной интеграции
Playwright в безголовом режиме	Библиотека внутри тестового процесса, движок запускается напрямую	Сохранённое состояние сессии или разовый вход через API	Низкая: отпечатки безголового движка распознаются, нужны патчи и подмена параметров	Высокая, секунды на сценарий, параллельные исполнители	Только время инженера, открытый исходный код	Отличная: детерминированные проверки, стабильные отчёты
Визуальные драйверы с записью действий	Через интерфейс, управление реальным окном браузера	Ручной вход оператора, затем запись сессии	Средняя: живой браузер, но следы автоматизации остаются	Средняя, зависит от отрисовки интерфейса	Низкий порог входа, но поддержка сценариев дорожает со временем	Слабая: локаторы хрупкие, правки делаются руками
MCP-мост к браузеру (BrowserMCP)	Сервер по протоколу MCP, модель получает набор инструментов браузера	Наследует сессии из профиля пользователя	Выше средней: реальный профиль и живые cookie	Ниже: каждый шаг проходит через модель	Подписка на модель плюс расход токенов	Ограниченная: недетерминированность требует внешнего контроля
Расширение-агент (Kimi WebBridge)	Расширение плюс локальный демон, управление реальным браузером по Chrome DevTools Protocol	Наследует живые сессии пользователя, экран входа проходится один раз	Наивысшая из четырёх: реальный браузер и его отпечатки	Зависит от модели, медленнее скриптовых сценариев	Подписка или токены плюс настройка рабочей машины	Точечная: годится для разведки и починки, не для регрессии

Механику самого моста мы разбирали в материале про MCP-протокол и корпоративные базы данных: логика та же — модель получает описанные инструменты вместо сырых вызовов. Подробный разбор Kimi WebBridge с замерами есть в обзоре команды разработчиков.

Отдельный вектор — браузерные агенты первого эшелона. «Яндекс» открыл закрытый альфа-тест «Алисы» в режиме ИИ-агента: помощник сам выбирает пункты меню, заполняет формы и адаптируется к изменениям разметки, о чём сообщает Хабр. Для тестировщика это скорее сигнал: защита интерфейсов будет подстраиваться под агентов, значит ставка на «просто живой браузер» тоже перестанет быть беспроигрышной.

Практический вывод простой. Регрессию держите на Playwright, сложные входы и проверку гипотез отдавайте агенту, а MCP-мост используйте там, где нужен диалог с моделью поверх уже открытой сессии. Если работаете с клиентскими данными, маскируйте их до отправки во внешние API: правовые нормы динамичны и требуют предварительной проверки юристами компании.

Тестирование веб-интерфейсов: где агент реально экономит часы

Автономный браузерный агент реально экономит часы на четырёх задачах: самовосстанавливающиеся локаторы, генерация черновиков E2E-сценариев из пользовательских историй, разбор упавших прогонов и проверка доступности с адаптивной вёрсткой. Всё остальное — пока маркетинг.

Начнём с самой больной темы. Тест падает не потому, что функциональность сломалась, а потому что верстальщик переименовал класс, обернул кнопку в лишний div или поменял порядок блоков. Раньше это лечили руками, ползая по DevTools.

Теперь агент получает разметку страницы, дерево доступности и смысл шага («нажать кнопку оформления заказа») и предлагает новый локатор. Работает это на Claude Sonnet или Gemini Pro — модели уверенно сопоставляют смысл элемента с узлами дерева.

Базу всё равно держите на стабильных опорах — data-testid, ролях и доступных именах. Тогда агенту остаётся тонкая настройка, а не переписывание селектора с нуля.

from playwright.sync_api import sync_playwright

API_KEY = "<API_KEY>"  # ключ к LLM, которая чинит локаторы

def heal(page, old_selector, intent):
    dom = page.content()
    # агент видит разметку и смысл шага, а не только строку селектора
    return agent_suggest(dom, intent, api_key=API_KEY)

with sync_playwright() as p:
    page = p.chromium.launch().new_page()
    page.goto("https://shop.example.test/cart")
    page.get_by_test_id("checkout").click()   # стабильная опора
    page.get_by_role("button", name="Оплатить").click()

Второй сценарий — генерация черновика. Пользовательскую историю в духе «как покупатель я хочу оформить заказ в один клик» агент разворачивает в десяток шагов с проверками. Экономия — часы на шаблонном коде, но черновик всё равно проходит ревью инженера. Тот же принцип, что и в вайбкодинге плагинов для видеоредактора: машина пишет каркас, человек отвечает за логику.

Самое ценное — разбор упавших прогонов. Агент видит лог, скриншот и снимок разметки, а дальше раскладывает падения по двум корзинам.

Признак	Мигающее падение	Настоящий баг
Повтор на том же коммите	проходит	падает стабильно
Текст ошибки	таймаут, гонка	несовпадение данных
Скриншот	пустой скелет загрузки	сломанный элемент

Универсальной доли мигающих падений не существует — она сильно гуляет от проекта к проекту, и подгонять её под красивую цифру не стоит. А вот про общий уровень зрелости агентов есть честные данные: в исследовании Decodo specialists прогнали 45 агентов по десяти способностям, и ни один не набрал максимум. Вендорские обещания и реальная производительность пока расходятся.

Доступность и адаптив — третья зона, где агент работает быстрее человека. Он проходит страницы, ищет картинки без альтернативного текста, ловит слабый контраст, проверяет порядок фокуса и прогоняет вёрстку на вьюпортах от 375 до 1440 px. Инженеры Яндекса, кстати, публиковали сравнение Kimi WebBridge и Playwright — полезно, если выбираете движок под такие прогоны.

После редизайна агент сравнит скриншоты и подскажет, какие проверки отвалились. Данные для сценариев он может тянуть и из корпоративных источников — про это у нас был отдельный разбор MCP-протокола и корпоративных баз.

Сложный скрейпинг: динамический контент, сессии и антибот-защита

Динамический контент, авторизацию и антибот-защиту надёжнее всего обходить не парсером, а живой сессией реального браузера: агент работает в уже открытом профиле, где куки, токены и отпечаток устройства давно сохранены.

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

По данным обзора Kimi WebBridge от Moonshot AI, свежий подход устроен именно так: браузерное расширение плюс локальный фоновый процесс управляют вашим настоящим браузером по Chrome DevTools Protocol. Экраны авторизации при этом никто не «взламывает» — они уже пройдены человеком.

Частота запросов решает не меньше, чем сессия. Аккуратные интервалы, кэш уже полученных страниц и повторные попытки с экспоненциальной задержкой дают предсказуемую нагрузку: пауза растёт как «базовая × 2 в степени номера попытки», и к ней добавляют случайный разброс, чтобы запросы не шли ровным строем.

Капчу разумнее отдавать профильному сервису распознавания, а аудиоразновидность — модели распознавания речи. Для второго сценария подойдёт локальный Whisper: в нашем разборе голосового ввода офлайн показано, как он поднимается без обращения к внешним API.

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

Отдельно держите в голове, что публичные правила обхода сайта и правовые регламенты динамичны и требуют предварительной проверки юристами компании. Инженерно безопаснее держать агента в закрытом контуре и не выгружать наружу лишние данные.

Инженерная безопасность: маскирование, изоляция и локальные контуры

Безопасность браузерного агента держится на четырёх опорах: обезличивание данных до отправки во внешний API, отдельный изолированный профиль браузера, локальные модели для чувствительных задач и сквозное логирование каждого действия.

Агент работает не с абстрактными данными, а с живой страницей. Он видит форму заявки, поля с фамилией клиента, телефоном, номером договора и переносит всё это в контекст облачной модели. Если ничего не предпринимать, чувствительные поля уезжают наружу буквально пачками.

Лечится это на уровне прокси между агентом и моделью. Персональные значения подменяются маркерами вида <PHONE_1> и <EMAIL_1>, а обратная подстановка происходит уже на нашей стороне, после ответа модели. Модель рассуждает о структуре формы, но не видит самих данных.

Правило двух рук — не перестраховка. По данным исследования Decodo, специалисты прогнали 45 агентов по десяти способностям, и ни один не набрал максимальные 20 баллов. Заявления вендоров о возможностях пока расходятся с реальной производительностью.

Дальше — браузерный профиль. Агент живёт в отдельной копии браузера: без сохранённых паролей, без рабочей почты, без куки боевых сессий. Идеально — контейнер или виртуальная машина, которую можно снести и поднять заново. Если инструмент управляет вашим реальным браузером по Chrome DevTools Protocol, как Kimi WebBridge, изоляция становится обязательной, а не опциональной.

Боевые админ-панели для агента закрыты. Тестирование идёт на стенде с обезличенной копией данных, а доступ в продакшен выдаётся узкими сценариями. Об этом же думали в «Яндексе», когда запускали альфа-тест ИИ-агента в «Яндекс Браузере»: Алиса нажимает ссылки и заполняет формы так же, как человек, значит, права нужно резать заранее.

Слой	Инженерная мера
Данные	Маскирование в прокси до вызова модели
Браузер	Отдельный профиль, чистые куки, контейнер
Сеть	Прокси со списком разрешённых доменов, внутренний DNS
Модель	Локальный контур для чувствительных полей
Доступ	Ключи с коротким сроком жизни, ротация, аудит
Действия	Подтверждение человеком для необратимых операций

Чувствительные сценарии логично уводить на локальные модели: тогда содержимое страницы вообще не покидает периметр. Как это поднять на ноутбуке, разбирали в материале про локальные LLM в Ollama. Для тяжёлых задач можно оставить облако, но только с обезличенными полями.

И финальный слой — наблюдаемость. Каждый шаг агента логируется: снимок DOM, скриншот, вызванный инструмент, ответ модели, время. Ключи доступа выдаются с ограниченными правами и коротким сроком жизни, отзываются по первому подозрению.

Отдельная тонкость — поведение агента как пользователя. Сессия живёт в одном профиле, значит, случайный переход по ссылке из письма может занести его в чужой кабинет. Сетевой контур с белым списком доменов снимает этот риск почти полностью.

Правовые нормы динамичны и требуют предварительной проверки юристами компании. Инженерная часть при этом понятна: меньше сырых данных наружу, уже права, больше следов в логах.

Что дальше: Алиса в режиме ИИ-агента, ChatGPT Atlas и Comet

Потребительский фронт автономных агентов в 2026-м держат три браузера: «Яндекс Браузер» с закрытой альфой «Алисы», ChatGPT Atlas с агентскими функциями на платных тарифах и Perplexity Comet, открытый для всех желающих.

«Яндекс» открыл приём заявок на закрытое альфа-тестирование первого в России бесплатного браузерного ИИ-агента. «Алиса» в режиме агента работает с браузером так же, как человек: выбирает пункты меню, заполняет формы, нажимает ссылки. Отдельно подчёркивается адаптация к изменениям на веб-страницах — агент не сыпется, когда верстка поехала, а кнопка переехала в другой угол (Хабр, Comss).

Зарубежный лагерь устроен иначе: там агент давно прикручен к платной подписке. В ChatGPT Atlas автономные функции доступны только на тарифах Plus и Pro, причём агент управляет и самим браузером (например, закрывает неактуальные вкладки), и содержимым страниц. Perplexity Comet с начала октября открыт для всех: раньше скачать его могли лишь подписчики Perplexity Max за 200 долларов в месяц.

Есть и третья ветка — агенты, растущие не из ассистента, а из инструментов тестирования. Kimi WebBridge от Moonshot AI работает как расширение браузера плюс локальный демон и рулит вашим настоящим браузером через Chrome DevTools Protocol. Это снимает главную боль автономных сценариев — прохождение экранов авторизации, где автоматизация без реального окна традиционно спотыкается.

Куда всё едет? Прогноз простой: агент переезжает из демо в повседневный инструмент тестировщика, но не вместо автотестов, а рядом с ними. Детерминированные проверки остаются каркасом: они воспроизводимы, дешёвы и не зависят от настроения модели. Агент подключается там, где каркас буксует — разведка нового интерфейса, поиск сценариев, работа с живыми страницами, которые переписывают каждую неделю.

Свои инструменты агент получает через стандартизированные протоколы — об этом мы разбирали в материале про MCP-протокол и корпоративные базы данных.

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

Часто задаваемые вопросы (FAQ)