Когда в последний раз вам приходилось вручную заполнять однотипную форму или кликать по бесконечным «далее» в корпоративном портале? browser-use предлагает альтернативу — делегировать эту рутину AI-агенту. Но работает ли это вне демо-сценариев?
Что на самом деле делает browser-use
Это не просто ещё один Puppeteer или Playwright. Библиотека добавляет слой абстракции, где:
- DOM-элементы описываются через natural language («кнопка логина» вместо
#login-btn) - Навигация строится как цепочка intent-based действий («купи билет на завтра в Берлин»)
- Скриншоты и HTML передаются в LLM для принятия решений
Пример конфига для автоматизации тестового входа:
const agent = new BrowserUseAgent({
goals: [
"Navigate to example.com",
"Find login form",
"Enter test credentials",
"Verify dashboard appears"
],
model: "claude-3-sonnet" // Под капотом — RAG с DOM-анализом
});
На практике это напоминает ранние версии AutoGPT, но заточенные именно под браузерные сценарии.
Где это реально полезно
Из нетривиальных кейсов, которые я тестировал:
Тестирование accessibility
Агент может симулировать навигацию через screen reader, находя проблемы, которые не ловят axe-core и подобные инструменты. В одном из проектов он обнаружил missing aria-labels в динамически подгружаемых таблицах.
Миграция данных между SaaS
Перенос 300+ записей из старой CRM в новую занял 15 минут вместо планируемых двух дней. Пришлось допиливать селекторы для кастомных grid’ов, но базовый сценарий работал из коробки.
Парсинг legacy-порталов
Где нет нормального API, а SPA рендерится через 15 слоёв обфускации. Агент смог «прочитать» интерфейс как человек и извлечь данные с 92% точностью.
Ограничения, которые бьют по productivity
-
Цена ошибки
Когда агент перепутал «Delete account» с «Logout» в админке, мне пришлось экстренно откатывать бэкап. Теперь для деструктивных действий добавляю explicit confirmations. -
Latency
Каждое действие требует общения с LLM. На сложных формах время выполнения может быть в 10-20 раз хуже, чем у хардкодного скрипта. -
Хрупкость
Если дизайн меняется с «Sign In» на «Log in», человек адаптируется мгновенно, а агент может сломаться. Приходится дублировать альтернативные описания.
Как интегрировать в существующие проекты
Лучший паттерн, который я нашёл — использовать browser-use для discovery phase, а затем перекладывать логику на традиционные инструменты:
- Запускаем агента с exploratory goals
- Логгируем все его действия и использованные селекторы
- Переносим рабочую последовательность в Playwright-скрипт
Для проектов с часто меняющимся UI имеет смысл оставить гибридный подход, где агент пересматривает селекторы при каждом major-релизе.
Если ваш продукт — это один большой WYSIWYG-редактор вроде Webflow, возможно, browser-use станет основным инструментом тестирования. Для остальных — это пока что дорогой, но любопытный эксперимент. Особенно если вы уже провалились с попытками внедрить традиционные E2E-тесты.