Автоматизация браузера

VibeOS включает полный набор инструментов для автоматизации браузера с несколькими вариантами бэкенда:

Облачный режим Browserbase через Browserbase для управляемых облачных браузеров и антибот-инструментов
Облачный режим Browser Use через Browser Use как альтернативный облачный провайдер браузеров
Облачный режим Firecrawl через Firecrawl для облачных браузеров со встроенным парсингом
Локальный режим Camofox через Camofox для локального антидетекционного просмотра (спуфинг отпечатков на основе Firefox)
Локальный CDP семейства Chromium — подключайте инструменты браузера к вашему собственному Chrome, Brave, Chromium или Edge с помощью /browser connect
Локальный режим браузера через CLI agent-browser и локальную установку Chromium

Во всех режимах агент может перемещаться по веб-сайтам, взаимодействовать с элементами страницы, заполнять формы и извлекать информацию.

Обзор

Страницы представлены в виде деревьев доступности (текстовых снимков), что делает их идеальными для LLM-агентов. Интерактивные элементы получают идентификаторы ссылок (например, @e1, @e2), которые агент использует для кликов и ввода текста.

Ключевые возможности:

Мультипровайдерное облачное выполнение — Browserbase, Browser Use или Firecrawl — без необходимости в локальном браузере
Интеграция с локальным семейством Chromium — подключайтесь к вашему работающему Chrome, Brave, Chromium или Edge через CDP для практического просмотра
Встроенная скрытность — случайные отпечатки, решение CAPTCHA, резидентные прокси (Browserbase)
Изоляция сессий — каждая задача получает собственную сессию браузера
Автоматическая очистка — неактивные сессии закрываются по тайм-ауту
Визуальный анализ — скриншот + анализ с помощью ИИ для визуального понимания

Настройка

Подписчики Nous

Если у вас есть платная подписка на Nous Portal, вы можете использовать автоматизацию браузера через Tool Gateway без отдельных ключей API. Новые установки могут выполнить vibeos setup --portal для входа и включения всех инструментов шлюза сразу; существующие установки могут выбрать Nous Subscription в качестве провайдера браузера через vibeos model или vibeos tools.

Облачный режим Browserbase

Для использования облачных браузеров, управляемых Browserbase, добавьте:

# Добавьте в ~/.vibeos/.env
BROWSERBASE_API_KEY=***
BROWSERBASE_PROJECT_ID=your-project-id-here

Получите учетные данные на browserbase.com.

Облачный режим Browser Use

Для использования Browser Use в качестве облачного провайдера браузера добавьте:

# Добавьте в ~/.vibeos/.env
BROWSER_USE_API_KEY=***

Получите ключ API на browser-use.com. Browser Use предоставляет облачный браузер через свой REST API. Если установлены учетные данные и Browserbase, и Browser Use, приоритет отдается Browserbase.

Облачный режим Firecrawl

Для использования Firecrawl в качестве облачного провайдера браузера добавьте:

# Добавьте в ~/.vibeos/.env
FIRECRAWL_API_KEY=fc-***

Получите ключ API на firecrawl.dev. Затем выберите Firecrawl в качестве провайдера браузера:

vibeos setup tools
# → Browser Automation → Firecrawl

Дополнительные настройки:

# Самостоятельно размещенный экземпляр Firecrawl (по умолчанию: https://api.firecrawl.dev)
FIRECRAWL_API_URL=http://localhost:3002

# TTL сессии в секундах (по умолчанию: 300)
FIRECRAWL_BROWSER_TTL=600

Гибридная маршрутизация: облако для публичных URL, локально для LAN/localhost

Когда настроен облачный провайдер, VibeOS автоматически запускает локальный сайдкар Chromium для URL, которые разрешаются в частный/петлевой/LAN-адрес (localhost, 127.0.0.1, 192.168.x.x, 10.x.x.x, 172.16-31.x.x, *.local, *.lan, *.internal, IPv6 loopback ::1, link-local 169.254.x.x). Публичные URL продолжают использовать облачного провайдера в том же разговоре.

Это решает распространенную проблему рабочего процесса «я разрабатываю локально, но использую Browserbase» — агент может сделать скриншот вашей панели управления на http://localhost:3000 И спарсить https://github.com без переключения провайдеров или отключения защиты SSRF. Облачный провайдер никогда не видит частный URL.

Функция включена по умолчанию. Чтобы отключить ее (все URL направляются настроенному облачному провайдеру, как раньше):

# ~/.vibeos/config.yaml
browser:
  cloud_provider: browserbase
  auto_local_for_private_urls: false

При отключенной автоматической маршрутизации частные URL отклоняются с сообщением "Blocked: URL targets a private or internal address", если только вы также не установите browser.allow_private_urls: true (что позволит облачному провайдеру пытаться их открыть — обычно не сработает, так как Browserbase и другие не могут достичь вашей LAN).

Требования: локальный сайдкар использует тот же CLI agent-browser, что и чистый локальный режим, поэтому он должен быть установлен (vibeos setup tools → Browser Automation устанавливает его автоматически). Перенаправления после навигации с публичного URL на частный адрес по-прежнему блокируются (вы не можете использовать трюк с перенаправлением на внутренний адрес, чтобы достичь вашей LAN через публичный путь).

Локальный режим Camofox

Camofox — это самостоятельно размещаемый Node.js-сервер, оборачивающий Camoufox (форк Firefox со спуфингом отпечатков на C++). Он обеспечивает локальный антидетекционный просмотр без облачных зависимостей.

# Сначала клонируйте сервер браузера Camofox
git clone https://github.com/jo-inc/camofox-browser
cd camofox-browser

# Соберите и запустите с Docker, используя настройки контейнера по умолчанию
# (автоматически определяет архитектуру: aarch64 на M1/M2, x86_64 на Intel)
make up

# Остановите и удалите контейнер по умолчанию
make down

# Принудительная чистая пересборка (например, после обновления VERSION/RELEASE)
make reset

# Просто загрузите бинарные файлы без сборки
make fetch

# Явно укажите архитектуру или версию
make up ARCH=x86_64
make up VERSION=135.0.1 RELEASE=beta.24

make up немедленно запускает контейнер по умолчанию. Если вам нужны пользовательские настройки времени выполнения, такие как большая куча Node, VNC или постоянный каталог профиля, сначала соберите образ, а затем запустите его самостоятельно:

# Соберите образ без запуска контейнера по умолчанию
make build

# Запустите с сохранением состояния, VNC-просмотром в реальном времени и большей кучей Node
mkdir -p ~/.camofox-docker
docker run -d \
  --name camofox-browser \
  --restart unless-stopped \
  -p 9377:9377 \
  -p 6080:6080 \
  -p 5901:5900 \
  -e CAMOFOX_PORT=9377 \
  -e ENABLE_VNC=1 \
  -e VNC_BIND=0.0.0.0 \
  -e VNC_RESOLUTION=1920x1080 \
  -e MAX_OLD_SPACE_SIZE=2048 \
  -v ~/.camofox-docker:/root/.camofox \
  camofox-browser:135.0.1-aarch64

С включенным VNC браузер работает в режиме с графическим интерфейсом, и за ним можно наблюдать в реальном времени в вашем браузере по адресу http://localhost:6080 (noVNC). Вы также можете подключить нативный VNC-клиент к localhost:5901.

Если вы уже запустили make up, остановите и удалите этот контейнер по умолчанию перед запуском пользовательского:

make down
# затем выполните пользовательскую команду docker run выше

Затем установите в ~/.vibeos/.env:

CAMOFOX_URL=http://localhost:9377

Если Camofox работает в Docker и вы хотите, чтобы он открывал веб-приложения, обслуживаемые с хост-машины, включите перезапись адресов loopback. CAMOFOX_URL по-прежнему должен указывать на опубликованный хостом API управления, но URL страниц, такие как http://127.0.0.1:3000, должны открываться изнутри контейнера как http://host.docker.internal:3000:

# ~/.vibeos/config.yaml
browser:
  camofox:
    rewrite_loopback_urls: true
    loopback_host_alias: host.docker.internal  # по умолчанию; при необходимости используйте LAN IP

Эквивалентные переменные окружения:

CAMOFOX_REWRITE_LOOPBACK_URLS=true
CAMOFOX_LOOPBACK_HOST_ALIAS=host.docker.internal

Перезапись применяется только к URL навигации по страницам с loopback-хостами (localhost, 127.0.0.1, ::1). Она не изменяет CAMOFOX_URL. Оставьте ее отключенной для установок Camofox не в Docker, где браузер уже работает на хосте и loopback-адреса корректны.

Или настройте через vibeos tools → Browser Automation → Camofox.

Когда CAMOFOX_URL установлен, все инструменты браузера автоматически маршрутизируются через Camofox вместо Browserbase или agent-browser.

Постоянные сессии браузера

По умолчанию каждая сессия Camofox получает случайную идентичность — файлы cookie и данные входа не сохраняются между перезапусками агента. Чтобы включить постоянные сессии браузера, добавьте следующее в ~/.vibeos/config.yaml:

browser:
  camofox:
    managed_persistence: true

Затем полностью перезапустите VibeOS, чтобы новая конфигурация была применена.

Важен правильный путь вложенности

VibeOS читает browser.camofox.managed_persistence, а не managed_persistence на верхнем уровне. Частая ошибка — написать:

# ❌ Неправильно — VibeOS игнорирует это
managed_persistence: true

Если флаг размещен по неправильному пути, VibeOS молча возвращается к случайному эфемерному userId, и ваше состояние входа будет потеряно при каждой сессии.

Что делает VibeOS

Отправляет детерминированный userId в рамках профиля на Camofox, чтобы сервер мог повторно использовать тот же профиль Firefox между сессиями.
Пропускает уничтожение контекста на стороне сервера при очистке, чтобы файлы cookie и данные входа сохранялись между задачами агента.
Привязывает userId к активному профилю VibeOS, поэтому разные профили VibeOS получают разные профили браузера (изоляция профилей).

Что VibeOS не делает

Он не принуждает к сохранению состояния на сервере Camofox. VibeOS только отправляет стабильный userId; сервер должен соблюдать его, сопоставляя этот userId с постоянным каталогом профиля Firefox.
Если ваша сборка сервера Camofox обрабатывает каждый запрос как эфемерный (например, всегда вызывает browser.newContext() без загрузки сохраненного профиля), VibeOS не может сделать эти сессии постоянными. Убедитесь, что вы используете сборку Camofox, которая реализует сохранение профиля на основе userId.

Проверка работоспособности

Запустите VibeOS и ваш сервер Camofox.
Откройте Google (или любой сайт с входом) в задаче браузера и войдите вручную.
Завершите задачу браузера обычным образом.
Запустите новую задачу браузера.
Снова откройте тот же сайт — вы должны оставаться в системе.

Если на шаге 5 вас выйдет из системы, сервер Camofox не соблюдает стабильный userId. Перепроверьте путь вашей конфигурации, подтвердите, что вы полностью перезапустили VibeOS после редактирования config.yaml, и убедитесь, что версия вашего сервера Camofox поддерживает постоянные профили для каждого пользователя.

Где хранятся данные

VibeOS получает стабильный userId из каталога в рамках профиля ~/.vibeos/browser_auth/camofox/ (или эквивалентного под $VIBEOS_HOME для нестандартных профилей). Фактические данные профиля браузера хранятся на стороне сервера Camofox, привязанные к этому userId. Чтобы полностью сбросить постоянный профиль, очистите его на сервере Camofox и удалите соответствующий каталог состояния профиля VibeOS.

Внешне управляемые сессии Camofox

Когда другое приложение управляет видимым браузером Camofox (настольный ассистент, пользовательская интеграция, другой агент), настройте VibeOS для работы внутри той же идентичности вместо создания собственного изолированного профиля.

Три параметра управляют поведением:

Настройка	Переменная окружения	Эффект
`browser.camofox.user_id`	`CAMOFOX_USER_ID`	`userId` Camofox, который VibeOS использует при создании вкладок. Установка этого параметра переводит сессию в режим «внешнего управления».
`browser.camofox.session_key`	`CAMOFOX_SESSION_KEY`	`sessionKey` (также известный как `listItemId`), отправляемый при создании вкладки. Используется для сопоставления существующей вкладки при принятии. По умолчанию используется значение для каждой задачи, если не установлено.
`browser.camofox.adopt_existing_tab`	`CAMOFOX_ADOPT_EXISTING_TAB`	Если true, VibeOS вызывает `GET /tabs?userId=`<user_id>` при первом использовании и повторно использует существующую вкладку перед созданием новой.

Переменные окружения имеют приоритет над config.yaml. Любая форма работает:

browser:
  camofox:
    user_id: shared-camofox
    session_key: visible-tab
    adopt_existing_tab: true

CAMOFOX_USER_ID=shared-camofox
CAMOFOX_SESSION_KEY=visible-tab
CAMOFOX_ADOPT_EXISTING_TAB=true

Что меняется, когда установлен user_id:

VibeOS пропускает разрушительную очистку в конце задачи (так же, как managed_persistence: true). Вкладка/файлы cookie/профиль другого приложения сохраняются.
VibeOS не вызывает DELETE /sessions/<user_id>` — эта конечная точка удаляет все данные пользователя, поэтому она уничтожила бы сессию внешнего приложения, если бы сработала.

Как работает принятие вкладки (когда adopt_existing_tab: true):

При первом вызове инструмента браузера после запуска процесса VibeOS отправляет GET /tabs?userId=<user_id>` (тайм-аут 5 секунд).
Если какая-либо вкладка в ответе имеет listItemId == session_key, VibeOS принимает самую последнюю созданную в этой группе.
В противном случае VibeOS принимает самую последнюю созданную вкладку для пользователя (любой listItemId).
Если вкладок не существует или запрос не удался, VibeOS возвращается к созданию новой вкладки при следующей операции.

Принятие срабатывает только до тех пор, пока tab_id не будет заполнен для сессии. Если внешнее приложение закроет принятую вкладку во время выполнения, следующий вызов инструмента браузера вызовет ошибку Camofox — VibeOS не перезапрашивает новую вкладку при каждом вызове.

Выбор session_key: если вы хотите, чтобы VibeOS надежно подключался к конкретной существующей вкладке, установите session_key в значение listItemId, которое внешнее приложение использовало при ее создании. Если вы оставите session_key неустановленным и установите только user_id, VibeOS сгенерирует session_key для каждой задачи (task_<id>`) — VibeOS будет использовать общие файлы cookie и профиль с внешним приложением, но откроет свою собственную вкладку рядом, а не будет повторно использовать существующую.

Примечание о параллелизме: внешнее приложение и VibeOS могут одновременно управлять одним и тем же userId Camofox, но Camofox не координирует фокус на вкладках между клиентами. Координируйте владение на уровне приложения (например, внешнее приложение приостанавливается, пока работает VibeOS).

VNC-просмотр в реальном времени

Когда Camofox работает в режиме с графическим интерфейсом (с видимым окном браузера), он предоставляет порт VNC в своем ответе проверки работоспособности. VibeOS автоматически обнаруживает это и включает URL VNC в ответы навигации, чтобы агент мог предоставить ссылку для просмотра браузера в реальном времени.

Локальный браузер семейства Chromium через CDP (`/browser connect`)

Вместо облачного провайдера вы можете подключить инструменты браузера VibeOS к вашему собственному работающему Chrome, Brave, Chromium или Edge через протокол Chrome DevTools Protocol (CDP). Это полезно, когда вы хотите видеть, что делает агент в реальном времени, взаимодействовать со страницами, требующими ваших собственных файлов cookie/сессий, или избежать затрат на облачный браузер.

примечание

/browser connect — это slash-команда интерактивного CLI — она не отправляется через шлюз. Если вы попытаетесь выполнить ее в WebUI, Telegram, Discord или другом чате шлюза, сообщение будет отправлено агенту как обычный текст, и команда не выполнится. Запустите VibeOS из терминала (vibeos или vibeos chat) и выполните /browser connect там.

В CLI используйте:

/browser connect                 # Автозапуск/подключение к локальному браузеру семейства Chromium на http://127.0.0.1:9222
/browser connect ws://host:port  # Подключение к конкретной конечной точке CDP
/browser status                  # Проверка текущего подключения
/browser disconnect              # Отключение и возврат в облачный/локальный режим

Если браузер еще не запущен с удаленной отладкой, VibeOS попытается автоматически запустить поддерживаемый браузер семейства Chromium с флагом --remote-debugging-port=9222. Обнаружение включает Brave, Google Chrome, Chromium и Microsoft Edge, с распространенными путями установки Linux, такими как /opt/brave-bin/brave и /snap/bin/brave.

подсказка

Чтобы вручную запустить браузер семейства Chromium с включенным CDP, используйте выделенный каталог пользовательских данных, чтобы порт отладки действительно запустился, даже если браузер уже работает с вашим обычным профилем:

# Linux — Brave
brave-browser \
  --remote-debugging-port=9222 \
  --user-data-dir=$HOME/.vibeos/chrome-debug \
  --no-first-run \
  --no-default-browser-check &

# Linux — Google Chrome
google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=$HOME/.vibeos/chrome-debug \
  --no-first-run \
  --no-default-browser-check &

# macOS — Brave
"/Applications/Brave Browser.app/Contents/MacOS/Brave Browser" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/.vibeos/chrome-debug" \
  --no-first-run \
  --no-default-browser-check &

# macOS — Google Chrome
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/.vibeos/chrome-debug" \
  --no-first-run \
  --no-default-browser-check &

Затем запустите CLI VibeOS и выполните /browser connect.

Зачем нужен --user-data-dir? Без него запуск браузера семейства Chromium, когда обычный экземпляр уже работает, обычно открывает новое окно в существующем процессе — а этот существующий процесс не был запущен с --remote-debugging-port, поэтому порт 9222 никогда не открывается. Выделенный каталог пользовательских данных заставляет запустить новый процесс браузера, в котором порт отладки действительно слушает. --no-first-run --no-default-browser-check пропускает мастер первого запуска для нового профиля.

При подключении через CDP все инструменты браузера (browser_navigate, browser_click и т.д.) работают с вашим работающим экземпляром браузера вместо запуска облачной сессии.

WSL2 + Windows Chrome: предпочитайте MCP вместо `/browser connect`

Если VibeOS работает внутри WSL2, но окно Chrome, которым вы хотите управлять, работает на хосте Windows, /browser connect часто не является лучшим путем.

Почему:

/browser connect ожидает, что VibeOS сам сможет достичь рабочей конечной точки CDP
современные сессии живой отладки Chrome часто предоставляют конечную точку, доступную только на хосте, которая не может быть напрямую достигнута из WSL так же, как классический порт 9222
даже когда Windows Chrome доступен для отладки, наиболее чистая интеграция часто заключается в том, чтобы позволить MCP-серверу браузера на стороне Windows подключиться к Chrome, а VibeOS будет общаться с этим MCP-сервером

Для такой настройки предпочитайте chrome-devtools-mcp через поддержку MCP в VibeOS.

См. руководство по MCP для практической настройки:

Использование MCP с VibeOS

Локальный режим браузера

Если вы не установили никаких облачных учетных данных и не используете /browser connect, VibeOS все равно может использовать инструменты браузера через локальную установку Chromium, управляемую agent-browser.

Дополнительные переменные окружения

# Резидентные прокси для лучшего решения CAPTCHA (по умолчанию: "true")
BROWSERBASE_PROXIES=true

# Продвинутая скрытность с пользовательским Chromium — требуется тарифный план Scale (по умолчанию: "false")
BROWSERBASE_ADVANCED_STEALTH=false

# Повторное подключение сессии после отключений — требуется платный план (по умолчанию: "true")
BROWSERBASE_KEEP_ALIVE=true

# Пользовательский тайм-аут сессии в секундах (максимум 21600 = 6 часов) (по умолчанию: настройка проекта)
# Примеры: 600 (10мин), 1800 (30мин), 21600 (6ч макс)
BROWSERBASE_SESSION_TIMEOUT=1800

# Тайм-аут бездействия перед автоматической очисткой в секундах (по умолчанию: 120)
BROWSER_INACTIVITY_TIMEOUT=120

# Дополнительные флаги запуска Chromium (через запятую или новую строку). VibeOS автоматически добавляет
# `--no-sandbox,--disable-dev-shm-usage`, когда обнаруживает root или ограниченные AppArmor
# непривилегированные пользовательские пространства имен (Ubuntu 23.10+, DGX Spark, многие образы контейнеров),
# поэтому большинству пользователей не нужно устанавливать это. Установите вручную, только если вам нужен флаг,
# который VibeOS не добавляет автоматически; установка отключает автоматическое добавление.
AGENT_BROWSER_ARGS=--no-sandbox

Установка CLI agent-browser

npm install -g agent-browser
# Или установите локально в репозитории:
npm install

к сведению

Набор инструментов browser должен быть включен в список toolsets вашей конфигурации или активирован через vibeos config set toolsets '["vibeos-cli", "browser"]'.

Доступные инструменты

`browser_navigate`

Перейти по URL. Должен быть вызван перед любым другим инструментом браузера. Инициализирует сессию Browserbase.

Navigate to https://github.com/NousResearch

подсказка

Для простого получения информации предпочитайте web_search или web_extract — они быстрее и дешевле. Используйте инструменты браузера, когда вам нужно взаимодействовать со страницей (нажимать кнопки, заполнять формы, обрабатывать динамический контент).

`browser_snapshot`

Получить текстовый снимок дерева доступности текущей страницы. Возвращает интерактивные элементы с идентификаторами ссылок, такими как @e1, @e2, для использования с browser_click и browser_type.

full=false (по умолчанию): Компактное представление, показывающее только интерактивные элементы
full=true: Полное содержимое страницы

Снимки длиной более 8000 символов автоматически обобщаются LLM.

`browser_click`

Нажать на элемент, идентифицированный по его идентификатору ссылки из снимка.

Click @e5 to press the "Sign In" button

`browser_type`

Ввести текст в поле ввода. Сначала очищает поле, затем вводит новый текст.

Type "vibeos agent" into the search field @e3

`browser_scroll`

Прокрутить страницу вверх или вниз, чтобы показать больше содержимого.

Scroll down to see more results

`browser_press`

Нажать клавишу на клавиатуре. Полезно для отправки форм или навигации.

Press Enter to submit the form

Поддерживаемые клавиши: Enter, Tab, Escape, ArrowDown, ArrowUp и другие.

`browser_back`

Вернуться на предыдущую страницу в истории браузера.

`browser_get_images`

Вывести список всех изображений на текущей странице с их URL и альтернативным текстом. Полезно для поиска изображений для анализа.

`browser_vision`

Сделать скриншот и проанализировать его с помощью ИИ-зрения. Используйте это, когда текстовые снимки не захватывают важную визуальную информацию — особенно полезно для CAPTCHA, сложных макетов или задач визуальной верификации.

Скриншот сохраняется постоянно, и путь к файлу возвращается вместе с анализом ИИ. На платформах обмена сообщениями (Telegram, Discord, Slack, WhatsApp) вы можете попросить агента поделиться скриншотом — он будет отправлен как нативное вложение фотографии через механизм MEDIA:.

What does the chart on this page show?

Скриншоты хранятся в ~/.vibeos/cache/screenshots/ и автоматически удаляются через 24 часа.

`browser_console`

Получить вывод консоли браузера (сообщения log/warn/error) и неперехваченные исключения JavaScript с текущей страницы. Необходим для обнаружения скрытых ошибок JS, которые не отображаются в дереве доступности.

Check the browser console for any JavaScript errors

Используйте clear=True, чтобы очистить консоль после чтения, чтобы последующие вызовы показывали только новые сообщения.

browser_console также выполняет JavaScript при вызове с аргументом expression — та же форма, что и в консоли DevTools, результат возвращается разобранным (объекты, сериализованные в JSON, становятся словарями; примитивные значения остаются примитивными).

browser_console(expression="document.querySelector('h1').textContent")
browser_console(expression="JSON.stringify(performance.timing)")

Когда для текущей сессии активен CDP-супервизор (типично для любой сессии, которая выполнила browser_navigate против бэкенда, поддерживающего CDP), выполнение происходит через постоянный WebSocket супервизора — без затрат на запуск подпроцесса. В противном случае выполнение передается стандартному пути CLI agent-browser. Поведение идентично в обоих случаях; меняется только задержка.

`browser_cdp`

Прямой проход протокола Chrome DevTools Protocol — запасной вариант для операций браузера, не охваченных другими инструментами. Используйте для обработки нативных диалогов, выполнения кода в iframe, управления cookie/сетью или любой команды CDP, необходимой агенту.

Доступен только когда конечная точка CDP достижима при запуске сессии — то есть когда /browser connect подключился к работающему Chrome, Brave, Chromium или Edge, или установлен browser.cdp_url в config.yaml. Режим локального агента-браузера по умолчанию, Camofox и облачные провайдеры (Browserbase, Browser Use, Firecrawl) в настоящее время не предоставляют CDP этому инструменту — у облачных провайдеров есть URL CDP для каждой сессии, но маршрутизация живой сессии — это последующее улучшение.

Справочник методов CDP: https://chromedevtools.github.io/devtools-protocol/ — агент может использовать web_extract для страницы конкретного метода, чтобы найти параметры и форму возврата.

Распространенные шаблоны:

# Список вкладок (уровень браузера, без target_id)
browser_cdp(method="Target.getTargets")

# Обработка нативного JS-диалога на вкладке
browser_cdp(method="Page.handleJavaScriptDialog",
            params={"accept": true, "promptText": ""},
            target_id="<tabId>")

# Выполнение JS в конкретной вкладке
browser_cdp(method="Runtime.evaluate",
            params={"expression": "document.title", "returnByValue": true},
            target_id="<tabId>")

# Получение всех cookie
browser_cdp(method="Network.getAllCookies")

Методы уровня браузера (Target.*, Browser.*, Storage.*) опускают target_id. Методы уровня страницы (Page.*, Runtime.*, DOM.*, Emulation.*) требуют target_id из Target.getTargets. Каждый вызов без сохранения состояния независим — сессии не сохраняются между вызовами.

Кросс-оригинные iframe: передайте frame_id (из browser_snapshot.frame_tree.children[], где is_oopif=true), чтобы направить вызов CDP через живую се

Обзор​

Настройка​

Облачный режим Browserbase​

Облачный режим Browser Use​

Облачный режим Firecrawl​

Гибридная маршрутизация: облако для публичных URL, локально для LAN/localhost​

Локальный режим Camofox​

Постоянные сессии браузера​

Что делает VibeOS​

Что VibeOS не делает​

Проверка работоспособности​

Где хранятся данные​

Внешне управляемые сессии Camofox​

VNC-просмотр в реальном времени​

Локальный браузер семейства Chromium через CDP (/browser connect)​

WSL2 + Windows Chrome: предпочитайте MCP вместо /browser connect​

Локальный режим браузера​

Дополнительные переменные окружения​

Установка CLI agent-browser​

Доступные инструменты​

browser_navigate​

browser_snapshot​

browser_click​

browser_type​

browser_scroll​

browser_press​

browser_back​

browser_get_images​

browser_vision​

browser_console​

browser_cdp​