Твои агенты управляют настоящим браузером.
Не фейковым.
AgentsRoom встраивает настоящий браузер Chromium в каждый проект и поставляется с сервером AgentsRoom Browser MCP, который позволяет твоим ИИ-агентам им управлять. Твой QA-агент открывает сайт на localhost, кликает кнопки, заполняет формы, делает скриншоты, читает консоль и проверяет, что фича реально работает, прежде чем сказать done. End-to-end browser automation для Claude Code, Codex, OpenCode, Gemini CLI и Aider, с нулевой конфигурацией Playwright.
Сочетай это с Agent Teams: Dev-агент выпускает фичу, QA-агент загружает сайт localhost во встроенном браузере, прогоняет сценарий проверки, делает скриншот результата и согласовывает. Нативная browser automation тоже в roadmap, с планируемыми будущими MCP-серверами для приложений React Native и Electron, чтобы агенты также могли тестировать мобильные и desktop приложения.
Демо AgentsRoom Browser MCP: end-to-end тестирование веб-приложения под управлением QA-агента Claude Code через встроенный браузер Chromium.
Browser Automation в AgentsRoom: две вещи в одной. Первое: настоящий браузер Chromium, встроенный в каждый room проекта, с URL-баром, back/forward, reload, history, скриншотом в clipboard, open-in-default-browser, постоянными cookies и localStorage на проект. Второе: сервер AgentsRoom Browser MCP (agentsroom-browser), который выставляет этот браузер твоим ИИ-агентам через Model Context Protocol. Агент получает чистый, scriptable интерфейс: navigate, click, type, screenshot, evaluate JavaScript, ждать элемент, get page state, get console logs, go back, go forward, reload.
Почему это важно? Потому что вся обещание ИИ-агентов кодинга разваливается, когда агент говорит 'feature shipped' но никогда не открывает страницу чтобы проверить. Большинство агентов сегодня полагаются на запуск unit-тестов, потом надеются. С настоящим browser MCP агент загружает localhost-сервер, прогоняет user flow, видит то что увидел бы человек-пользователь, и только тогда согласовывает. Роль QA Engineer agent наконец-то имеет инструменты которые ей нужны для настоящего QA, а не только статического анализа.
Технический setup невидим для тебя. Когда ты ставишь галку 'Browser access' на агенте, AgentsRoom мерджит запись agentsroom-browser в .mcp.json твоего проекта и агент стартует с доступными инструментами браузера. Мост WebSocket, работающий на loopback-порту (127.0.0.1, назначаемый OS, регенерируемый при каждом boot, аутентифицируемый 32-байтовым hex-токеном), соединяет MCP-subprocess с WebContentsView Chromium в Electron-приложении. Каждый клик, каждый ввод, каждый скриншот: JSON-RPC вызов. Агент видит настоящий браузер, не stub.
Панель Browser AgentsRoom: URL-бар, history, скриншот и полная поверхность контроля MCP для ИИ-агентов чтобы навигировать, кликать, вводить и проверять.
Настоящий браузер, не Playwright stub
Большинство демок ИИ-агентов, говорящих о browser automation, используют headless Playwright-инстанс, спавнящийся при каждом вызове инструмента. Это работает для бенчмарков, но это болезненно в реальной жизни: ты не видишь что делает агент, каждая навигация respawnит Chromium, cookies теряются, localStorage пуст, твой dev-сервер думает что каждый визит: новая сессия. AgentsRoom берёт другой угол. Браузер уже открыт в твоём room проекта (ты сам им пользуешься, как обычным браузером), и агент управляет этим браузером. Сессии, cookies, localStorage, состояние логина: всё сохранено.
Каждый клик и ввод от агента триггерит настоящий нативный dispatch через WebContentsView Electron, с правильными key-events, mouse-events и DOM-мутациями. Скриншоты: настоящие PNG, захваченные с реально отрендеренной страницы (не DOM-to-image хак). Логи консоли буферизуются и queryable, включая warnings и errors. Агент видит то же самое, что увидел бы ты с открытыми DevTools: настоящую производительность, настоящее network-поведение, настоящий CORS, настоящий auth.
Cross-room изоляция обеспечивается. AgentsRoom создаёт один Chromium WebContentsView на проект, со своей session-партицией (persist:agentsroom-browser-<projectId>). Cookies проекта A никогда не утекают в проект B. Когда ты переключаешь проект, предыдущий браузер скрывается и новый выходит online со своим состоянием. Агент всегда приземляется на правильном проекте, с правильными credentials.
Слой MCP намеренно мал и без зависимостей. Subprocess browser-mcp-server.cjs говорит на протоколе MCP 2024-11-05 через stdio (initialize, tools/list, tools/call) и переводит его в JSON-RPC вызовы по loopback WebSocket-мосту. По сравнению с тяжёлым SDK-based сервером, остаётся быстрым (первый вызов инструмента sub-100ms) и легко дебажится. После каждого действия меняющего страницу (клик, ввод, navigate, reload, back, forward), ответ включает base64 PNG-скриншот, ограниченный 1.6 MB, так что агент всегда видит результат того что только что сделал. Это оказалось одной из самых больших побед по надёжности: агенты, которые видят экран, делают правильное намного чаще чем агенты которые надеются.
Тулкит Browser MCP который получают твои агенты
Каждый ИИ-агент с browser-доступом стартует с этими инструментами. Они выставлены через стандартный MCP, так что любой совместимый CLI их видит: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Открыть URL во встроенном браузере. Smart URL handling: localhost:3000 становится http://localhost:3000 вместо триггера диалога 'cannot open application'. Возвращает финальный URL и скриншот страницы после загрузки.
browser_click
Кликнуть на элемент по селектору или по видимому тексту. Настоящий нативный click event, не JavaScript-dispatch. Возвращает post-click скриншот, так что агент видит результат своего действия.
browser_type
Ввести текст в input или textarea. Поддерживает горячие клавиши и submit. Настоящие key-events, обработчики onChange страницы срабатывают. Возвращает скриншот после ввода.
browser_screenshot
Захватить текущий viewport как PNG. Полезно для проверок визуальной регрессии, design QA, before-and-after сравнений или для шеринга состояния бага с остальной командой.
browser_evaluate
Запустить выражение JavaScript в main world страницы. Получить обратно сериализованный результат. Используется агентами для чтения состояния страницы, query DOM, инспекции Redux store или триггера действия которое не имеет видимой кнопки.
browser_wait_for
Ждать появления элемента, изменения URL, завершения сетевого запроса или возврата true произвольным JavaScript. Избегает классической гонки 'агент кликает слишком быстро'.
browser_get_state
Прочитать текущий URL, заголовок, viewport, scroll-позицию и структурированный snapshot доступных элементов страницы. Основной input агента, когда ему надо спланировать следующее действие.
browser_get_logs
Вытащить буфер консоли (log, warn, error). Агент может видеть те же React warnings, hydration-ошибки, network failures и runtime exceptions, которые видел бы ты в DevTools. Bug-репорты становятся 'вот ошибка из консоли'.
browser_go_back / forward / reload
Стандартная навигация браузера, scriptable. Используется агентами для возврата когда flow идёт не так, или для re-теста страницы после hot reload от Vite, Next.js или Expo Metro.
Что агенты реально делают с браузером
Настоящие воркфлоу которые можно построить уже сегодня, с ролью QA Engineer и Agent Teams.
End-to-end smoke-тест на каждом хендоффе
Подключи команду Dev в QA. QA-агент навигирует на твой dev-сервер localhost, прокликивает критичные пути (signup, checkout, dashboard), делает скриншот результата и согласовывает только если ничего не падает. Лови регрессии до того как человек откроет страницу.
QA визуальной регрессии
Before-and-after скриншоты на UI-изменениях. Агент загружает страницу на предыдущем коммите, скриншот, переключает branch, скриншот, просит Claude сравнить. Дешёвый QA визуального diff без Percy или Chromatic в петле.
Охота на ошибки в консоли
Агент навигирует по приложению, вызывает browser_get_logs, находит React hydration warnings, useEffect warnings, network 404, CORS errors, deprecation notices. Репортит их как список рисков в payload хендоффа команды, следующий Dev-агент их фиксит.
Тестирование валидации форм
Агент заполняет форму валидными данными, пустыми полями, edge-кейсами (XSS-строки, очень длинные input, non-ASCII). Проверяет сообщения валидации, сетевые запросы, редиректы. Настоящий QA форм, не unit-тесты.
Аудит accessibility
Агент проходит по странице, query accessibility tree через browser_get_state и browser_evaluate, проверяет alt-тексты, ARIA-атрибуты, focus management, навигацию с клавиатуры. Репортит проблемы со скриншотами.
Design QA против Figma
Сочетай с фичей Figma to AI agents. Агент загружает Figma-frame, скриншот, загружает страницу localhost, скриншот, сравнивает spacings, шрифты, цвета, alignments. Заводит список несоответствий.
Проверка тоннеля live preview
Сочетай с localhost-тоннелем AgentsRoom. Агент навигирует на публичный HTTPS preview URL (не localhost), проверяет что сайт доступен из внешнего мира, делает скриншот и подтверждает что stakeholder может реально открыть ссылку.
Воспроизведение бага клиента из публичного тикета бэклога
Приходит публичный тикет бэклога с URL и шагами для воспроизведения. QA-агент открывает URL, следует шагам, ловит ошибку консоли, прикрепляет скриншот, делает хендофф к Dev с чистым repro. Конец циклам 'cannot reproduce'.
Как агент получает браузер
Открой вкладку Browser в room
В room проекта правая панель выставляет три вкладки: Files, Changes, Browser. Кликни Browser. Панель расширяется, sidebar сворачивается, и появляется настоящий Chromium-вид. Введи URL или выбери из истории проекта.
Поставь галку 'Browser access' на агенте
Открой модал Edit Agent, разверни Capabilities, поставь галку Browser access. AgentsRoom мерджит запись agentsroom-browser в .mcp.json твоего проекта и агент увидит инструменты браузера при следующем старте.
<project>/.mcp.jsonАгент стартует с browser MCP
При спавне агента Claude (или Codex, Gemini и т.д.) инициализирует MCP-сервер agentsroom-browser, листует свои инструменты (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_go_back, browser_go_forward, browser_reload), и с этого момента может управлять браузером.
Агент использует браузер
Агент навигирует, кликает, вводит, делает скриншоты, читает консоль. Каждое действие идёт через мост loopback WebSocket (127.0.0.1, порт назначаемый OS, 32-байтовый hex-токен, регенерируемый при каждом boot desktop-приложения). После каждого действия меняющего страницу, скриншот возвращается inline, так что агент визуально проверяет свой ход.
Авто-таргет на localhost или твой тоннель
Если localhost-тоннель работает, первая навигация приземляется на URL тоннеля. Иначе, на первый обнаруженный dev-сервер. Иначе, https://localhost:3000. Совмещённое с Dev Terminals, агент буквально стартует dev-сервер, потом открывает его в браузере, потом тестит.
Проверка, скриншот, хендофф
Когда подключено в Agent Teams, QA-нод прогоняет свои сценарии, ловит скриншоты, ставит flags.qaPassed в payload хендоффа. Следующий агент наследует вердикт. Pass идёт к PM, fail возвращается к Dev с тест-хинтами.
Под капотом
Для любопытных. Стек browser automation мал намеренно.
У каждого проекта один Chromium WebContentsView (современное Electron API, не deprecated BrowserView), наложенный на главное окно с bounds стримящимися из React-renderer. Per-project session-партиция держит cookies, localStorage и аутентификацию изолированными между проектами. Default offscreen bounds позволяют агентам вызывать browser-инструменты даже до того как человек откроет вкладку Browser, с 5-секундовым timeout на скриншотах чтобы избежать зависаний.
Лёгкий WebSocket-сервер (browser-bridge.ts) работает на loopback-порту, выбранном OS, привязанном только к 127.0.0.1. Аутентификация использует 32-байтовый hex-токен, регенерируемый при каждом boot desktop. Bridge-файл ~/.agentsroom/browser-bridge.json держит текущий порт, токен и PID, атомарно переписываемый при каждом boot, так что MCP-subprocess всегда подхватывает свежие credentials с автоматическим retry.
Сам MCP-сервер: browser-mcp-server.cjs, zero-dependency Node-скрипт, реализующий протокол MCP 2024-11-05 через stdio (initialize, tools/list, tools/call). Говорит JSON-RPC мосту WebSocket через hand-rolled WebSocket-клиент (нет ws, нет @modelcontextprotocol/sdk). Маленький, быстрый, легко аудитится. Бандлится как extraResources файл в desktop-приложении, так что каждая установка ставится с ним готовым к работе.
Нативная поддержка браузера (first-class фича браузера за пределами MCP) в roadmap AgentsRoom. Помимо этого, долгосрочный план включает дополнительные MCP, чтобы агенты также могли управлять non-web таргетами: React Native MCP для мобильных приложений и Electron MCP для desktop-приложений. Та же идея, тот же UX: агент не просто пишет код, он реально прогоняет работающее приложение.
FAQ
Чем это отличается от Playwright MCP или browser-инструментов на основе Puppeteer?
MCP на основе Playwright и Puppeteer спавнят свежий headless-браузер при каждой сессии. Это нормально для stateless-задач, но теряет cookies, localStorage и auth между вызовами, и человек не может видеть что делает агент. AgentsRoom Browser: тот же браузер которым человек пользуется внутри приложения, с постоянной per-project сессией, видимой пользователю в реальном времени. Агент управляет окном которое можно видеть и в которое можно вмешаться в любой момент. Это более честная, более debuggable browser automation.
Это работает со всеми ИИ-провайдерами или только с Claude Code?
Это работает с каждым провайдером, поддерживаемым AgentsRoom: Claude Code, Codex CLI, OpenCode, Gemini CLI и Aider. Browser-инструменты выставлены через стандартный Model Context Protocol, который все эти CLI читают из .mcp.json. Агент никогда не знает, что он в AgentsRoom, он просто видит набор MCP-инструментов и использует их как использовал бы любой другой инструмент.
Может ли агент управлять удалённым сайтом или только localhost?
Оба. Введи любой URL и поехали. Localhost (и формы host:port) smart-detected, префиксуются http:// и открываются напрямую. Публичные сайты работают как в любом обычном браузере, с cookies и состоянием логина сохранёнными per project. Совмещённое с localhost-тоннелем AgentsRoom, агент также может управлять твоим локальным dev-сервером через публичный HTTPS URL, что полезно для cross-network и mobile QA.
Безопасен ли browser MCP? Что мешает злоупотреблению?
Мост привязывается только к 127.0.0.1, никогда к 0.0.0.0. Порт назначается OS (никакого фиксированного порта для collision-prone сканирования). 32-байтовый hex-токен требуется при каждом подключении, регенерируется при каждом boot desktop. MCP-subprocess получает credentials только через env-переменные, никогда в каком-либо commit-нутом файле. Browser-доступ opt-in на агента в модале Edit Agent. Если ты его убираешь, запись .mcp.json удаляется и агент больше не может использовать инструменты.
Видит ли агент консоль браузера (errors, warnings, network)?
Да, через browser_get_logs. Буфер держит сообщения console.log, console.warn и console.error из main world страницы. Многие реальные баги (React hydration errors, useEffect warnings, CORS failures) всплывают только в консоли, никогда в unit-тестах, так что это оказывается одним из самых сигнальных инструментов для QA-агента.
Что происходит со скриншотами возвращаемыми агенту? Стоят ли они много токенов?
После каждого действия меняющего страницу, base64 PNG-скриншот добавляется к ответу инструмента, ограниченный 1.6 MB. Выше этого, отправляется text marker. Скриншоты критичны для надёжности (агент, который видит экран, делает намного меньше ошибок), так что trade-off стоит того. Если ты хочешь отключить скриншоты по причинам бюджета, простые browser_evaluate вызовы возвращают только текст.
Может ли агент заполнить форму логина? Сохранять свою сессию?
Да. Cookies и localStorage сохраняются per project под session-партицией persist:agentsroom-browser-<projectId>. Агент может залогиниться раз через browser_type и browser_click и оставаться залогинен в остальной части run. Когда ты переключаешь проект, сессия меняется, так что credentials никогда не утекают между проектами.
Сломается ли агент если dev-сервер не работает?
Он навигирует на URL и видит страницу ошибки Chromium. Может прочитать эту ошибку через browser_get_state и browser_get_logs и реагировать соответственно: попросить тебя стартовать сервер, или вызвать команду Dev Terminals чтобы стартовать его. С Agent Teams и Dev Terminals, можно подключить воркфлоу, который стартует сервер, ждёт, потом открывает браузер, всё без вмешательства человека.
Поддерживаются ли мобильные и desktop приложения тоже?
Web выпускается сегодня, через встроенный Chromium и AgentsRoom Browser MCP. Roadmap включает нативный AgentsRoom Browser как first-class фичу браузера. Помимо этого, планируются дополнительные MCP-серверы: React Native MCP, чтобы агенты могли управлять Expo-бандлами iOS и Android, и Electron MCP, чтобы агенты могли управлять desktop-приложениями которые не web. Та же логика агента, применённая к non-web таргетам.
Может ли человек поставить агента на паузу и взять управление браузером?
Да. Браузер: тот же Chromium-вид которым пользуется человек. В любой момент кликни в панели Browser и ты в управлении. Как только перестанешь взаимодействовать, агент может возобновить свои tool-вызовы. Нет концепции 'agent-locked browser', это разделяемая поверхность, ровно как сессия pair-programming.
Дай своим агентам настоящие глаза в браузере
Поставь галку Browser access на любом агенте в AgentsRoom. Browser MCP стартует автоматически. Твой QA-агент наконец-то тестит то что выпускает.
Приложение-компаньон: следите за агентами на ходу
Работает с Claude, Codex, OpenCode, Gemini CLI и Aider
Отправляйте баги и запросы прямо в ваш публичный бэклог.