agent-browser

agent-browser — это скрытый discovery-stub для CLI автоматизации браузера, опубликованный Vercel. Он предназначен для задач, где агенту нужно открыть сайт, перейти по страницам, заполнить форму, нажать кнопку, сделать screenshot, извлечь данные, проверить web-приложение или провести exploratory QA. Источник описывает работу через Chrome или Chromium по CDP и компактные accessibility snapshots с короткими ссылками на элементы. Такой интерфейс помогает сначала увидеть доступное состояние страницы, а затем обращаться к найденным элементам без длинного полного DOM-описания. Первый обязательный шаг не состоит в копировании примеров из самого stub-файла. Перед запуском команды нужно получить актуальное содержимое встроенного CLI: agent-browser skills get core загружает основной workflow, а параметр --full добавляет полный reference и шаблоны. Это сделано намеренно: stub сообщает, что практические команды и troubleshooting должны соответствовать установленной версии, поэтому старый текст карточки не должен считаться полным руководством. Для расширенных сценариев предусмотрены специализированные skills get: electron для VS Code, Slack, Discord, Figma, Notion и Spotify; slack для рабочих пространств Slack; dogfood для exploratory testing и QA; derive-client для записи HAR и вывода самостоятельного API-клиента; vercel-sandbox для Vercel Sandbox; agentcore для браузеров AWS Bedrock AgentCore. Полный список доступных модулей можно запросить через skills list. Установка источника состоит из двух обычных шагов: установить npm-пакет agent-browser глобально и выполнить agent-browser install, который готовит браузерное окружение. Сам stub заявляет, что это быстрый нативный Rust CLI, а не Node-обёртка; он поддерживает Chrome/Chromium через CDP и не требует строить автоматизацию вокруг Playwright или Puppeteer. Описанные возможности включают сессии, authentication vault, сохранение состояния и видеозапись. Это делает инструмент пригодным как для разовой проверки страницы, так и для повторяемого сценария, где состояние браузера должно сохраняться между действиями. Но конкретный синтаксис команд и параметры нужно брать из core skill установленной версии. Набор сценариев широк, но общий порядок остаётся одинаковым: запустить актуальный workflow, открыть нужную сессию, получить accessibility snapshot, выбрать ссылку элемента, выполнить действие и проверить новое состояние. Для QA это может быть проверка формы, навигации или поведения web-приложения; для исследования — чтение отрендеренного интерфейса и извлечение видимых данных; для desktop-автоматизации — работа с Electron-приложением через специальный модуль. Наличие screenshots и video recording помогает сохранить доказательство, но само по себе не подтверждает корректность продукта: ожидаемый результат и assertions остаются ответственностью конкретного тестового сценария. Отдельно источник описывает Observability Dashboard. Он работает независимо от browser sessions на порту 4848 и может открываться через проксированный адрес вида dashboard.agent-browser.localhost. Агенту рекомендуется оставаться на dashboard origin: вкладки сессий, состояние и stream-трафик проксируются внутренне, поэтому порты отдельных сессий не нужно выставлять наружу. Это ограничение важно для локального окружения и не означает, что dashboard заменяет авторизацию или контроль доступа к тестируемому сайту. Карточка не должна выдавать этот файл за полную справку. В frontmatter он помечен как hidden и перечисляет разрешённые Bash-вызовы agent-browser или npx agent-browser, поэтому запуск зависит от наличия CLI и браузера в окружении. Не следует угадывать команды, параметры сессий или формат ссылок: сначала загрузите core skill, затем проверьте команду на безопасной тестовой странице. Stub также не обещает, что любой сайт доступен без входа, что accessibility-дерево содержит все технические узлы или что сохранённое состояние безопасно для чужой машины; credentials, cookies и видео нужно обрабатывать по правилам конкретной среды.