Browser Use против Skyvern: чем управлять браузер-агентом

Задача звучит одинаково для обоих проектов: дать языковой модели браузер и заставить её пройти по сайту так, как это сделал бы человек — залогиниться, заполнить форму, вытащить данные из таблицы. Browser Use и Skyvern решают её по-разному. Первый делает ставку на извлечение структуры страницы и передачу её в модель текстом. Второй смотрит на скриншоты и работает через компьютерное зрение плюс LLM. От этого выбора зависит, сколько токенов вы сожжёте, насколько агент переживёт редизайн сайта и сколько строк кода вам придётся написать.

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

Как устроен каждый из них

Browser Use: страница как текст

Browser Use — это Python-библиотека поверх Playwright*. Она парсит DOM** открытой страницы, выделяет интерактивные элементы (кнопки, поля, ссылки), нумерует их и отдаёт модели компактное текстовое описание. Модель отвечает, какой элемент нажать или что ввести, а библиотека выполняет действие через Playwright.

Плюс подхода — экономия. Текстовое дерево элементов дешевле по токенам, чем поток скриншотов, и работает с любой моделью, умеющей в function calling: GPT-4-класса, Claude, локальные модели через совместимый API. Минус — если сайт рисует интерфейс на canvas или прячет логику за нестандартными виджетами, извлечённое дерево бедное, и агент промахивается.

Skyvern: страница как картинка

Skyvern делает упор на зрение. Он снимает скриншот, прогоняет его через набор моделей (в том числе для детекции элементов) и решает, куда кликнуть, по визуальному расположению, а не по позиции в DOM. Идея в том, что кнопка «Оформить заказ» остаётся кнопкой «Оформить заказ» даже после того, как верстальщик переписал половину классов и вложенность тегов.

За устойчивость платят вычислениями: обработка изображений мультимодальной моделью дороже и медленнее, чем разбор текстового дерева. Skyvern поставляется как сервис с API и своим форматом задач-воркфлоу, что удобно для повторяющихся сценариев, но добавляет слой абстракции над «просто напиши промпт».

Где что выбирать

Разница между «текстом» и «картинкой» переводится в практические сценарии довольно прямо.

• Разовый скрипт под конкретный сайт, где вы контролируете верстку — Browser Use. Быстрый старт, минимум инфраструктуры, дешевле по токенам.
• Массовый обход десятков внешних сайтов с непредсказуемой версткой — Skyvern. Зрение прощает разброс в разметке.
• Сайты с тяжёлым JS, canvas-интерфейсами, нестандартными виджетами — Skyvern, потому что DOM тут малоинформативен.
• Встраивание в существующий Python-пайплайн как библиотека — Browser Use, он изначально задуман как импортируемый пакет.
• Повторяющиеся бизнес-процессы с человеком в контуре (подтверждение шага) — у Skyvern это заложено в модель воркфлоу.

Сравнение по осям

Таблица описывает логику проектов, а не фиксированный список фич: и там, и там подход дополняют. Browser Use умеет подмешивать скриншоты для сложных случаев, Skyvern использует DOM как подсказку. Границы размываются от релиза к релизу.

Устойчивость браузер-агента определяется не тем, насколько умная модель за ним стоит, а тем, что ломается первым, когда сайт меняет верстку в следующий вторник.

Сколько это стоит на практике

Прямой ценник ни у одного проекта не «зашит»: оба open-source, платите вы за токены модели и за инфраструктуру, на которой крутится браузер. Реальная стоимость складывается из трёх частей.

1. Токены модели. Скриншот-подход Skyvern генерирует больше входных токенов на каждый шаг. При сотнях шагов в день разница ощутима в счёте за API.
2. Компьют под браузер. Каждая сессия — это запущенный headless-браузер. Параллельный обход десятков сайтов требует памяти и CPU независимо от выбранного фреймворка.
3. Время на сопровождение. Дешёвый по токенам агент, который падает после каждого редизайна целевого сайта, в итоге может выйти дороже за счёт часов на починку промптов.

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

Что проверить перед выбором

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

• Ваш целевой сайт отдаёт вменяемый DOM или прячет всё за canvas и shadow-DOM.
• Как часто меняется верстка целевых сайтов — если это чужие ресурсы, часто и без предупреждения.
• Нужен ли человек в контуре для подтверждения критичных шагов вроде оплаты.
• Есть ли антибот-защита: капчи и поведенческие проверки ломают оба подхода, и это отдельная головная боль вне зоны ответственности фреймворка.
• Какую модель вы готовы использовать и укладывается ли её стоимость в бюджет при вашем числе шагов.

* Playwright — библиотека для программного управления браузером: открыть страницу, кликнуть, ввести текст, снять скриншот. Разработана Microsoft, работает с Chromium, Firefox и WebKit.

** DOM (Document Object Model) — дерево объектов, в которое браузер разбирает HTML-страницу. Именно по нему код находит кнопки и поля, чтобы с ними взаимодействовать.