agent-browser: браузерная автоматизация для AI-агента без тонны DOM-шума

Автоматизация браузера для AI-агента обычно начинается бодро: открыл страницу, нашёл кнопку, кликнул. А потом интерфейс меняет className, селектор перестаёт работать, в контекст летит половина DOM — и «автономность» превращается в отладку Playwright-скрипта.

agent-browser предлагает посмотреть на эту проблему иначе. Это нативный CLI на Rust для браузерной автоматизации, рассчитанный именно на агентов, а не на ручное написание E2E-тестов.

Не DOM, а доступное представление страницы

Главная идея — агент получает не полный HTML и не только картинку, а компактное дерево доступности:

- heading "Настройки" [ref=e1]
- textbox "Email" [ref=e2]
- button "Сохранить" [ref=e3]

Дальше действие выглядит предсказуемо:

agent-browser click @e3

Это не магия и не замена хорошим тестам. Но такой контракт заметно удобнее, когда интерфейсом управляет LLM:

1. Меньше контекста. Вместо тысяч строк DOM агент видит только то, с чем пользователь реально может взаимодействовать.
2. Меньше догадок. ref=e3 привязан к конкретному элементу из текущего snapshot, не нужно заново изобретать CSS-селектор.
3. Лучше связь с accessibility. Если кнопка или поле не попали в дерево, это часто уже симптом проблемы интерфейса, а не просто неудобство для робота.

Где это полезнее обычного Playwright

У Playwright и подобных инструментов другая сильная сторона: детерминированные регрессионные тесты, которые должны одинаково проходить в CI. Там локаторы, data-testid и строгие ожидания — правильный выбор.

agent-browser интересен в сценариях, где путь заранее неизвестен или интерфейс живёт слишком быстро:

• агент проверяет новый лендинг после деплоя: CTA, формы, 404 и базовую навигацию;
• саппорт-бот повторяет шаги пользователя, чтобы собрать воспроизведение бага;
• агент исследует незнакомую админку перед тем, как предложить автоматизацию;
• нужно быстро собрать рабочий сценарий, а потом перенести его в устойчивый Playwright-тест.

То есть это скорее слой exploration и operations, а не повод выбросить ваш тестовый стек в окно.

Что в нём стоит проверять на практике

Проект уже умеет не только переходы и клики: есть формы, скриншоты, cookies и storage, вкладки, network/debug-инструменты, запись видео и CDP-режим. Есть нативные сборки для Linux, macOS и Windows.

Старт выглядит без экзотики:

npm install -g agent-browser
agent-browser install
agent-browser open https://example.com
agent-browser snapshot -i

Но внедрять его лучше с ограничениями:

1. Только отдельный browser profile для агента — не давайте ему куки от личных аккаунтов по умолчанию.
2. Запрет на необратимые действия: платежи, удаление данных, публикация и отправка сообщений должны требовать отдельного подтверждения.
3. Логи и скриншоты для каждого запуска. Иначе после ошибки останется только красивая легенда агента о том, что «всё было сделано».
4. Критичные сценарии фиксировать в тестах. Если агент нашёл устойчивый путь, закрепите его обычным Playwright-тестом с нормальными локаторами.

Вывод

Самое ценное в agent-browser — не очередное обещание «AI сам покликает». Ценность в попытке дать агенту компактный, проверяемый интерфейс к браузеру: accessibility tree, refs и CLI-команды вместо бесконечного HTML-потока.

Для exploratory-задач и операционных проверок это выглядит практично. Для боевых транзакций без guardrails — всё ещё плохая идея, просто теперь она написана на Rust.

Источник: agent-browser на GitHub и документация проекта.