Идея поручить LLM управление браузером вместо человека выглядит заманчиво: агент сам заполняет формы, собирает данные со страниц, проходит многошаговые сценарии вроде бронирования билетов. За последний год появилось сразу несколько заметных реализаций — от OpenAI Operator до открытых проектов вроде WebVoyager и BrowserGym. Однако практические тесты показывают, что разрыв между демо-роликом и реальным продакшеном остаётся большим.
Главная проблема не в том, что модели не понимают задачу. Проблема в том, что веб рассчитан на человека, а не на программного агента. Капчи, модальные окна, динамическая подгрузка контента, нестандартные элементы управления — каждый из этих факторов может сломать сценарий, который в демо работал безупречно.
Что обещают и что показывают бенчмарки
OpenAI запустила Operator в январе 2025 года как исследовательский прототип. Агент использует GPT-4o с возможностью делать скриншоты экрана, кликать по пиксельным координатам и вводить текст. В официальном блоге компания приводит результат 38,1% успешных выполнений на бенчмарке WebArena и 58,1% на OSWorld — это заметно выше, чем у предшественников, но всё ещё далеко от человеческой производительности (78% и 72% соответственно).
Исследовательский проект WebVoyager, опубликованный в мае 2024 года командой из нескольких университетов, показал схожую картину. На наборе из 643 задач с реальных сайтов агент на базе GPT-4V достиг успешности 59,1% при автоматической оценке и 83,3% при ручной верификации. Разница между автоматической и ручной оценкой — важный сигнал: метрики могут завышать или занижать реальную эффективность в зависимости от того, как именно проверяется результат.
Бенчмарк | Model | Успешность (авто) | Успешность (ручная) | Источник
——–|——-|——————-|———————|———
WebArena | GPT-4o (Operator) | 38,1% | — | OpenAI blog, Jan 2025
OSWorld | GPT-4o (Operator) | 58,1% | — | OpenAI blog, Jan 2025
WebVoyager (live web) | GPT-4V | 59,1% | 83,3% | WebVoyager paper, May 2024
WebVoyager (live web) | Gemini Pro | 44,7% | 69,2% | WebVoyager paper, May 2024
Цифры говорят о том, что даже лучшие модели справляются лишь с половиной-двумя третями задач. Для сценариев, где ошибка стоит времени или денег, этого недостаточно.
Практические ограничения: капчи, модалки и динамический DOM
В тестах Operator пользователи из сообщества Reddit и X регулярно сообщают об одних и тех же проблемах. Агент «застревает» на страницах входа, где требуется двухфакторная аутентификация — он может бесконечно пытаться ввести код, не понимая, что нужно переключиться на другое устройство. Капчи от Google и Cloudflare блокируют агента намертво: компьютерное зрение модели не всегда корректно выделяет область с изображением, а попытки эмулировать движения мыши выглядят подозрительно для антибот-систем.
Другая категория проблем — модальные окна и всплывающие подсказки. Агент видит скриншот страницы, но не всегда может определить, что поверх основного контента появился overlay, который нужно закрыть. В результате клик уходит не туда, и сценарий ломается.
WebVoyager в своей работе тоже фиксирует эти ограничения. В статье авторы отмечают, что агенты на основе скриншотов (screenshot-based) теряют информацию о DOM-структуре: они не знают, какие элементы доступны для клика, а какие заблокированы CSS-свойствами. Это приводит к тому, что агент пытается кликнуть в элемент, который визуально виден, но программно недоступен.
Когда браузерные агенты всё-таки полезны
Несмотря на ограничения, есть сценарии, где агенты с доступом к браузеру уже работают стабильно. Это задачи с предсказуемой структурой страниц и минимальным числом нестандартных элементов.
Разработчики из сообщества BrowserGym (открытый фреймворк для тестирования агентов) выделяют три типа задач, где screenshot-based агенты показывают приемлемые результаты:
- Сбор данных с сайтов со статичной вёрсткой — например, мониторинг цен на маркетплейсах.
- Заполнение форм с известными полями при условии, что нет капчи.
- Тестирование собственных веб-приложений, где разработчик контролирует DOM и может убрать мешающие элементы.
Во всех этих случаях агент работает в контролируемой среде. Если сайт может изменить структуру или добавить новый элемент, надёжность падает.
Контрпример: почему API часто лучше браузера
Парадокс браузерных агентов в том, что они решают проблему, которую можно обойти через API. Для сбора данных с Amazon или Booking.com существуют партнёрские API — они работают в десятки раз быстрее и не ломаются при смене дизайна. Для автоматизации тестирования есть Playwright и Selenium с явными селекторами, а не с компьютерным зрением.
Браузерные агенты оправданы только тогда, когда API нет или он предоставляет недостаточно данных. Например, агрегаторы авиабилетов часто не имеют открытого API для сравнения цен, и единственный способ получить данные — парсинг страниц. Но даже в этом случае screenshot-based подход уступает прямому парсингу DOM: парсеры видят скрытые элементы и атрибуты, а агент на основе скриншота — нет.
Что тестировать и где смотреть развитие
Если вы рассматриваете браузерные агенты для своего проекта, начните с простого: выберите 3-5 типовых задач и прогоните их через Operator (если есть доступ) или через открытый WebVoyager с локальной LLM. Замеряйте не только успешность, но и типы ошибок — это покажет, какие сценарии требуют ручного вмешательства.
Следите за обновлениями в репозитории BrowserGym — это основной open-source инструмент для тестирования GUI-агентов, и он активно развивается. Выход новых бенчмарков (например, VisualWebArena, о котором объявили в июне 2025) даст более объективную картину.
Также обратите внимание на гибридные подходы: агенты, которые используют одновременно скриншоты и DOM-дерево. Проект SeeClick от китайской команды Alibaba показывает, что комбинация двух модальностей повышает точность кликов на 15-20% по сравнению с чисто screenshot-based методами. Это направление выглядит перспективнее, чем попытки «натаскать» модель на пиксельную разметку.
Браузерные агенты — не панацея, а ещё один инструмент с чётко очерченной областью применимости. Для автоматизации рутинных действий на статичных сайтах они уже пригодны. Для сложных многошаговых сценариев на современных веб-приложениях — пока нет. И это нормально: технология идёт от демо к продакшену, и путь этот не быстрый.