Браузерный агент: когда нужен, как думать о надёжности, чем опасен

Задача: каждый понедельник экспортировать отчёт из трёх SaaS и свести в одну таблицу. Путь первый — API: у одной системы есть, у второй только Enterprise, у третьей нет. Путь второй — scraping: работает, пока вёрстка не поменяется, а потом ломается молча. Путь третий — браузерный агент, который буквально открывает сайт, кликает кнопки и скачивает файл. Где агент выигрывает? Когда нет API, когда UI стабильный для человека, но нестабильный в разметке, когда шаги зависят от контекста («всплыло уведомление — закрой»). Где проигрывает? Когда нужна скорость (в 10–100 раз медленнее API), когда нужны тысячи повторов в час, когда отладка каждого шага стоит дороже, чем написать интеграцию.

Браузерные агенты делятся на две школы. Первая — vision-based: агент делает скриншот, LLM с vision смотрит на картинку и решает «кликни на жёлтую кнопку справа». Вторая — DOM-based: агент извлекает структуру страницы, LLM решает «нажми элемент с id=submit», фреймворк вызывает обработчик. Vision работает там, где DOM не помогает: canvas, сложный SVG, элементы поверх картинки. Но дороже, медленнее и галлюцинирует координаты на свежих лайаутах. DOM быстрее и точнее, но слепнет на визуальных элементах без семантики. Современные фреймворки (browser-use, Stagehand) комбинируют оба подхода: DOM как базовый слой, vision — как страховка для сложных мест.

Агент нажал «Submit». Задача выполнена? Не факт. Может, появилась ошибка валидации. Может, загрузился спиннер, и настоящий результат будет через 5 секунд. Может, страница ушла в редирект, и то, что вы видите — уже совсем другая страница. Главный источник багов в браузерных агентах — не клики, а понимание, что именно произошло после клика. Наивный подход — «после клика подожди 2 секунды». Ломается на первом же медленном ответе. Чуть лучше — ждать появления конкретного элемента. Но на что ждать? Если после Submit должна появиться надпись «Спасибо за заказ», а её нет — это ошибка или просто ещё не отрисовалось? Правильный паттерн — явные критерии успеха для каждого шага. «После Submit должен появиться либо элемент X (успех), либо элемент Y (ошибка). Жду до 10 секунд. Если ничего — непонятное состояние, эскалация.» Без этого агент накапливает ошибку на каждом шаге, и через три шага уже кликает вслепую. Золотое правило: каждый шаг агента должен иметь предикат проверки, а не фиксированную задержку.

Когда браузерный агент ломается, первое желание — починить код: добавить таймаут, обработчик, try/catch. Почти всегда это неправильный слой. Большинство провалов — это либо проблема инструкции (агент не понимает задачу), либо проблема детерминизма среды (попап, A/B-тест, сбой сети). Чинится сверху, не в коде. Инструкция: явно описывайте помехи. «Если появился cookie-попап — закрой. reCAPTCHA — остановись и позови человека. A/B-версия — ищи кнопку по тексту, не по селектору.» Правки на две минуты, экономия часов отладки. Детерминизм: preparation-фаза перед стартом. Очистить cookies, установить локаль, прокинуть session token. Чем меньше сюрпризов — тем реже агент ломается посреди задачи.

Последняя тема — и самая важная. У браузерного агента есть доступ к интернету, вашим куки, вкладкам, буферу обмена. Одна ошибка — и агент логинится в чужой аккаунт, публикует пост вместо draft, отправляет деньги не туда. Базовое правило: никакого прод-доступа по умолчанию. Изолированная сессия — свежий профиль браузера, sandbox, прокси, тестовый аккаунт. Прод-креды — только после того, как убедились, что агент делает что нужно. Второе: явные границы. Whitelist доменов, подтверждение на оплату/удаление/отправку, лог каждого шага с timestamp и скриншотом. Никогда не давайте полный доступ к кошельку или главному аккаунту — тесты покрывают известное, прод приносит неизвестное.