browser-act

BrowserAct — навык для CLI-автоматизации браузера, предназначенный для агентов, которым нужно работать не только с необработанным HTML, но и с интерфейсами, где содержимое появляется после выполнения JavaScript. Он охватывает навигацию, просмотр и извлечение данных из отрендеренных страниц, работу с несколькими URL, действия в формах, загрузку файлов, скриншоты и захват сетевых ответов XHR, Fetch или HAR. В описании источника отдельно указано, что browser-act следует выбирать, когда требуется открыть страницу, получить динамический контент, обработать verification prompt, поддерживать авторизованную сессию, прокрутить страницу до дополнительных данных или проверить визуальный результат. Навык рассчитан на сценарии, в которых одной HTTP-загрузки недостаточно. Его lightweight extraction режим описан как быстрый способ получить JS-рендеренный контент без открытия полноценной браузерной сессии; источник также позиционирует его как вариант для задач, где обычно применяют WebFetch или curl. Когда требуется интерактивная работа, browser-act предоставляет навигацию и взаимодействие с DOM, заполнение форм, выбор элементов, загрузку файлов, снимки экрана и просмотр сетевых запросов. Это позволяет собирать фактический текст после рендера, проверять состояние страницы, наблюдать ответы API или проходить последовательность действий, а не ограничиваться исходным документом. Отдельная часть навыка посвящена сессиям и изоляции. Browser-act поддерживает управление несколькими браузерами, изоляцию профилей и параллельную работу с несколькими аккаунтами. Такой режим подходит, например, для независимого доступа к разным сессиям, параллельного открытия URL или проверки страниц в разделённых окружениях. Источник описывает также headed mode и remote assist для случаев, когда агенту нужна работа с отображаемым браузером или участие человека. Для chrome-direct предусмотрено подключение к локальному Chrome через CDP, но оно требует явного подтверждения пользователя. Безопасность в этом workflow не является автоматическим разрешением на любые действия. Confirmation Gate требует явного одобрения перед созданием или удалением браузера и перед чувствительными операциями. К таким операциям источник относит вход в аккаунт, отправку формы и загрузку файла. Поэтому навык можно применять для получения данных, снимков экрана и проверки интерфейса, но перед авторизацией, изменением состояния внешнего сервиса или отправкой пользователь должен отдельно подтвердить действие. Само наличие команды или сессии не заменяет проверку правильности URL, цели и данных формы. В frontmatter источника зафиксировано, что cookies, login-сессии, содержимое страниц, учётные данные и данные профиля хранятся и обрабатываются локально и не загружаются наружу. Единственным заявленным внешним исключением является изображение challenge, отправляемое при использовании solve-captcha для verification assistance; содержимое страницы и cookies туда не относятся. Для запуска нужен Python 3.12 или новее и менеджер пакетов uv. Установка, указанная в официальном файле, выполняется командой `uv tool install browser-act-cli --python 3.12`; установка сама требует отдельного подтверждения пользователя, поскольку загружает внешний пакет из PyPI. Файл SKILL.md в репозитории является discovery stub, а не полной инструкцией для всех команд. После загрузки навыка источник требует получить актуальный workflow через `browser-act get-skills core --skill-version 2.0.2`. Это ограничение важно для эксплуатации: подробная последовательность должна соответствовать установленной версии CLI, а не копироваться из устаревшего текста карточки. Навык нельзя считать заменой инструкциям проекта, правилам доступа или ручному решению в неоднозначных ситуациях; он предоставляет средства браузерной автоматизации и контрольные точки подтверждения, но не гарантирует корректность выбранной цели или результата. Практически browser-act подходит для четырёх типов задач. Первый — сбор динамического контента и сетевых ответов со страниц, которые нельзя надёжно проверить статическим запросом. Второй — воспроизводимая проверка интерфейса: открыть маршрут, пройти взаимодействия, сделать снимок экрана и убедиться, что нужный элемент отображается. Третий — работа с несколькими раздельными браузерными профилями или аккаунтами, когда смешивание cookies недопустимо. Четвёртый — контролируемые пользовательские workflow с формами, файлами или verification prompts, где чувствительные шаги должны останавливаться на Confirmation Gate. Во всех случаях сначала следует загрузить workflow текущей версии, проверить адрес и область действия, а затем отдельно подтвердить операции, которые меняют внешнее состояние.