browser-use: агент, который умеет кликать в браузере

MAATRIX

Есть сайты без API — только форма логина, кнопки и таблицы, рассчитанные на человека с мышкой. Раньше единственным выходом было писать хрупкий скрипт под конкретную вёрстку конкретной страницы. browser-use предлагает другой подход: дать языковой модели «зрение» в виде структуры страницы и позволить ей самой решать, куда кликнуть. Разберём, как это устроено на самом деле, и почему это не серебряная пуля.

Что такое browser-use и зачем он нужен

browser-use — открытый проект (Python-библиотека поверх Playwright), который превращает браузер в инструмент для ИИ-агента. Идея простая: вы формулируете задачу на естественном языке («зайди в личный кабинет, найди счета за август, скачай их»), а агент сам выполняет цепочку действий — открывает страницы, кликает элементы, заполняет поля, читает результат.

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

Проект развивается быстро, версии API и поведение моделей меняются от релиза к релизу, поэтому вместо конкретных номеров версий — общие принципы работы и структура задачи, которая с высокой вероятностью останется актуальной.

Как это работает: цикл наблюдение-решение-действие

В основе browser-use лежит цикл, знакомый по любым агентным системам, но применённый к вебу:

1. Наблюдение (snapshot). Агент запрашивает у браузера текущее состояние страницы — не скриншот в чистом виде, а структурированное представление: дерево доступности (accessibility tree) или размеченный DOM, где у каждого интерактивного элемента (кнопка, поле ввода, ссылка) есть свой идентификатор, роль (button, link, textbox) и видимый текст. Это тот же принцип, на котором строятся инструменты автоматизации тестирования — снимок структуры, а не пикселей.
2. Решение. Этот снимок вместе с историей предыдущих шагов и исходной задачей отправляется языковой модели. Модель анализирует, что видно на странице, и решает: кликнуть элемент с таким-то идентификатором, ввести текст в такое-то поле, прокрутить страницу, перейти по ссылке, либо признать задачу выполненной.
3. Действие. browser-use транслирует решение модели в реальный вызов Playwright (page.click(), page.fill() и так далее) и выполняет его в браузере.
4. Повтор. Цикл начинается заново: новый снимок после действия, новое решение, новое действие — пока задача не будет выполнена или не сработает ограничение (лимит шагов, таймаут, явная ошибка).

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

Опционально снимок может дополняться скриншотом с подсвеченными (bounding box) интерактивными элементами — так называемый visual grounding. Это повышает точность распознавания на визуально сложных интерфейсах, но не убирает фундаментальную проблему: модель всё равно принимает решение на основе интерпретации, а не гарантированного знания.

Установка и минимальный рабочий пример

Базовая установка на сервере (Ubuntu/Debian) выглядит примерно так:

python3 -m venv browser-use-env
source browser-use-env/bin/activate
pip install browser-use
playwright install chromium --with-deps

Последняя команда критична — Playwright ставит свою собственную сборку Chromium и системные зависимости (шрифты, библиотеки рендеринга), без которых браузер просто не запустится в headless-режиме на чистом сервере.

Минимальный сценарий (концептуально, без привязки к конкретной версии API):

import asyncio
from browser_use import Agent
from langchain_openai import ChatOpenAI  # или другой поддерживаемый провайдер

async def main():
    agent = Agent(
        task="Зайди на example.com, найди раздел 'Тарифы' и выпиши список цен",
        llm=ChatOpenAI(model="gpt-4o"),
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

На практике вам почти всегда понадобится:

• Ограничение числа шагов (max_steps или аналог) — без него агент, застрявший в цикле, может выполнять действия десятки раз подряд, пока не кончится лимит времени или токенов. Эта проблема детально разобрана в статье про агента, который зациклился и сжёг лимиты — сценарий там про LLM-агентов в целом, но с browser-use он актуален ничуть не меньше: каждый шаг цикла — это отдельный запрос к модели, и застревание съедает бюджет быстро.
• Логирование каждого шага — какой снимок получен, какое действие выбрано, — иначе разобраться, почему агент «поехал не туда», постфактум почти невозможно.
• Headless-браузер с достаточным объёмом RAM — Chromium под нагрузкой из нескольких параллельных сессий требует заметно больше памяти, чем кажется на глаз; на слабом VPS агент будет либо падать по OOM, либо работать ощутимо медленнее.

Практические сценарии применения

Автоматизация интерфейсов без API. Это основной и самый оправданный случай использования. Некоторые системы — старые корпоративные порталы, отдельные админ-панели закрытых сервисов, внутренние CRM без документированного API — предоставляют доступ только через веб-интерфейс, рассчитанный на человека. Если задача разовая или редкая (например, раз в месяц выгрузить отчёт из системы, у которой нет экспорта иначе как через клик по кнопке), написать полноценную интеграцию бывает не оправдано по трудозатратам — а browser-use-агент справляется без написания кода под конкретный сайт.

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

Прототипирование перед «настоящей» интеграцией. Когда неясно, стоит ли вообще автоматизировать взаимодействие с сайтом, browser-use-агент позволяет быстро проверить осуществимость сценария, прежде чем вкладываться в написание постоянного парсера или искать недокументированный API.

Что browser-use не заменяет: там, где у сервиса есть нормальный REST/GraphQL API, использовать агента для кликов вместо прямого вызова API — это медленнее, дороже (каждый шаг — вызов модели) и менее надёжно. Браузерная автоматизация — это решение для случая, когда программного интерфейса нет, а не универсальный способ работы с вебом.

Честный разбор: почему это ненадёжно

Здесь стоит остановиться подробно, потому что маркетинговые описания подобных инструментов почти всегда преуменьшают эту часть.

Веб-интерфейсы спроектированы для человека, а не для агента. Человек видит страницу целиком, интуитивно понимает визуальную иерархию («это главная кнопка, это второстепенная ссылка мелким шрифтом»), помнит контекст предыдущих действий и распознаёт нестандартные паттерны (всплывающее окно, баннер cookie, модальное окно с ошибкой) почти мгновенно. Агент реконструирует всё это из структурного снимка, и реконструкция несовершенна: два визуально похожих элемента могут быть неразличимы в разметке, скрытый элемент может оказаться в снимке как «видимый», а действительно важная кнопка — потеряться среди десятков вложенных div.

Структура страниц меняется без предупреждения. Сайт обновил вёрстку, поменял идентификаторы элементов, добавил новый шаг в форму (например, подтверждение по SMS) — и сценарий, который вчера работал, сегодня даёт сбой или совершает не то действие. В отличие от программного API, у которого версионирование и обратная совместимость — часть контракта, у веб-интерфейса таких гарантий нет вообще: дизайнер поменял кнопку — автоматизация сломалась, и никто не обязан вас предупреждать.

Защита от автоматизированного доступа. Многие сайты целенаправленно детектируют бот-подобное поведение: слишком равномерные интервалы между действиями, отсутствие характерных для человека паттернов (движения мыши, задержки перед кликом), специфичные заголовки headless-браузера. Результат — капча, блокировка IP, требование дополнительной верификации. Это не баг агента, а осознанное противодействие со стороны сайта, и обходить его специально — плохая идея как с этической, так и с практической точки зрения (риск блокировки аккаунта или IP).

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

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

Безопасность: границы вместо полной автономии

Если агент взаимодействует с реальными сайтами — особенно если он может вводить данные, совершать покупки или менять настройки аккаунтов — общий принцип из статьи о песочнице для агента применим и здесь: изоляция среды исполнения (контейнер, разграничение файловой системы) — это половина дела; вторая половина — явные границы дозволенного действия, а не полная свобода.

Практические меры, которые стоит внедрить до того, как агент получит доступ к «боевым» сайтам:

• Явный список разрешённых доменов. Агент должен работать только с сайтами из белого списка, а не «куда решит перейти». Большинство реализаций поддерживают ограничение по allowed_domains или аналогичный механизм — используйте его, не полагайтесь на то, что модель «сама не пойдёт куда не надо».
• Человеческое подтверждение перед необратимыми действиями. Оплата, отправка формы с реальными данными, удаление записи, изменение пароля — такие шаги должны требовать явного подтверждения человеком (пауза в выполнении с запросом на подтверждение), а не выполняться автономно по решению модели. Разница между «прочитать страницу и собрать данные» и «нажать кнопку "Оплатить"» — это разница между низким и высоким риском, и она должна быть явно закодирована в логике агента, а не оставлена на усмотрение LLM.
• Отдельная учётная запись с минимальными правами, а не основной аккаунт с полным доступом — если агент совершит ошибку, ущерб должен быть ограничен тем, к чему у этой учётки вообще есть доступ.
• Логирование каждого действия с возможностью отката там, где это применимо (например, черновик формы вместо немедленной отправки).
• Лимит шагов и таймаут на сессию — уже упомянутая защита от зацикливания, но она же ограничивает и масштаб потенциального ущерба от неверной интерпретации задачи: чем быстрее агент останавливается при аномальном поведении, тем меньше урона он успевает нанести.

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

Развёртывание: где запускать агента

headless Chromium под управлением browser-use — процесс требовательный к памяти и стабильности сети, и гонять его на слабом тарифе или домашнем ПК с нестабильным интернетом — плохая идея: сессия браузера, разорванная из-за обрыва связи посреди выполнения многошаговой задачи, оставляет систему в неопределённом состоянии (форма частично заполнена, платёж где-то на середине flow).

Практический минимум для одного агента с одной активной браузерной сессией — 2 vCPU и 4 ГБ RAM; при нескольких параллельных сессиях или при добавлении визуального grounding со скриншотами память стоит закладывать с запасом. Схема разворачивания похожа на любой другой ИИ-агент на сервере: изолированное окружение (виртуальное окружение Python или Docker-контейнер), стабильный аутбаунд-трафик, статичный IP если сайт требует консистентного адреса между сессиями, и постоянный аптайм — если задачи выполняются по расписанию, а не только по запросу. Общие принципы подготовки VPS под такие сценарии подробно разобраны в статье о том, как поднять агента на LangChain на сервере — конкретный фреймворк там другой, но требования к инфраструктуре (память, сеть, изоляция) пересекаются почти полностью. Если хочется собрать несколько таких агентов в единый workflow с визуальным конструктором — стоит присмотреться к варианту с n8n и ИИ-агентами на своём сервере, где browser-use может быть одним из шагов в более широком автоматизированном процессе.

Частые вопросы