Как дать ИИ-агенту доступ к вашему Chrome: разбираем инструмент chrome-bridge

Любой разработчик или специалист, пытавшийся подключить автономных ИИ-агентов к браузеру, неизбежно сталкивается с фундаментальным тупиком: существующие инструменты либо полностью изолированы от реального пользователя, либо нещадно сжигают токены контекстного окна. В этой статье я разберу архитектуру и практическую работу моста chrome-bridge — легкого Open Source решения, которое передает нейросети управление вашим основным браузером Chrome через accessibility-дерево.

Проблема современных методов управления браузером из ИИ

Если взглянуть на то, как сегодня организуется работа ИИ-агентов в веб-среде, можно выделить несколько типичных подходов, каждый из которых имеет существенные недостатки:

• Классическая автоматизация (Playwright, Selenium): Агент запускает изолированный браузер с чистым профилем. В результате на первом же шаге процесс упирается в авторизацию, 2FA-подтверждения или капчу. Работать в таком режиме с привычными сервисами практически невозможно.
• Удаленная отладка (Remote Debugging): Подключение к уже запущенному браузеру требует старта процесса со специальными флагами, что сбрасывает текущие пользовательские сессии и мешает повседневной работе.
• Вендорские решения и расширения: Инструменты от Anthropic или OpenAI жестко привязаны к собственным экосистемам и подпискам. Например, расширение Anthropic работает исключительно из интерфейса Claude и гоняет данные через облако, а инструменты OpenAI для CLI не дают доступа к локальному браузеру. Встроенные среды вроде браузера в VS Code Copilot также живут в своей изолированной песочнице.

Главный парадокс заключается в том, что на компьютере пользователя уже есть полностью настроенный браузер со всеми авторизациями, вкладками и SSO-сессиями. Задача состояла в создании нейтрального и прозрачного моста между терминалом и расширением Chrome — именно эту брешь и закрывает проект chrome-bridge.

Архитектура chrome-bridge: как устроен локальный мост

Я изучил структуру этого инструмента: вся система построена на минималистичном стеке без внешних зависимостей npm. Архитектура укладывается в цепочку из четырех компонентов:

Расширение Chrome (background.js) <—> WebSocket <—> Локальный Node.js сервер <—> CLI-утилита

Все процессы выполняются локально на машине, код и передаваемые данные не покидают пределы вашей системы. Поскольку интерфейсом взаимодействия служит стандартный shell CLI, мост совместим со всеми популярными агентами и CLI-средами: Claude Code, Cursor, Codex, DeepSeek, Kimi, Qwen, а также с любыми локальными нейросетями. Никаких специфических SDK или серверов MCP при этом не требуется.

Интерпретация страницы через дерево доступности (Accessibility Tree)

Ключевое инженерное решение chrome-bridge — отказ от передачи скриншотов в пользу текстового дерева доступности. Когда агент запрашивает снимок страницы, он получает не массив пикселей, а структурированное дерево элементов с уникальными метками вида @eN.

Пример консольного вывода структуры страницы:

table "Hacker News new | past | comments | ask | show | jobs | submit" @e1
  link "Hacker News" @e5
  link "new" @e6
  link "submit" @e12
  link "login" @e13

Базовый набор команд в терминале выглядит следующим образом:

node cli.mjs snap habr.com              # получение снимка страницы в виде дерева
node cli.mjs click habr.com @e14        # клик по конкретному элементу из дерева
node cli.mjs fill habr.com @e12 "query" # ввод текста в найденное поле
node cli.mjs shot habr.com out.png --max 800 # получение графического скриншота при необходимости

Экономия ресурсов здесь колоссальная. Практические замеры показывают, что текстовое дерево всей страницы занимает около 2,4 КБ, тогда как графический скриншот той же страницы шириной 1000px весит более 16 КБ. Это сокращает расход токенов контекстного окна ИИ в разы. Кроме того, агент перестает ошибаться с координатами на экране и выполняет точечные клики по конкретным идентификаторам элементов.

События, эмуляция ввода и система вердиктов

При автоматизации браузерных действий возникает проблема синтетических событий: стандартные JavaScript-клики не содержат флага isTrusted=true, из-за чего многие современный веб-сервисы их просто игнорируют.

Для решения этой проблемы в chrome-bridge предусмотрен специальный режим --trusted. При его активации клик отправляется через Chrome DevTools Protocol (CDP) с честным флагом доверия. Однако за это приходится платить: использование CDP монтирует отладчик, что становится заметно для внутренних скриптов страницы. Проект не содержит средств маскировки («стелс»-стека), так как изначально проектировался для автоматизации собственных легальных аккаунтов.

Обратная связь и статусы выполнения действий

После выполнения любого действия ИИ-агент получает четкий вердикт о состоянии системы:

• succeeded: действие успешно выполнено, DOM изменился ожидаемым образом;
• needs_human: обнаружена стена авторизации, капча или 2FA — требуется вмешательство человека;
• blocked: получен лимит запросов (rate limit) или блокировка;
• uncertain: событие отправлено, но состояние страницы не изменилось (требуется повторная проверка или смена стратегии).

Например, при тестировании сложного интерфейса Excalidraw обычный клик по холсту вернул статус uncertain. Агент, проанализировав вердикт, сделал скриншот, подтвердил отсутствие результата, переключился на режим --trusted с двойным кликом и успешно создал текстовый блок, который сразу же отобразился в обновленном дереве доступности.

Журналирование команд и реплей сценариев

Встроенный сервер хранит кольцевой журнал всех выполненных команд и их статусов (ok или fail). Команда history --batch out позволяет экспортировать всю последовательность действий в виде готового к запуску скрипта.

При экспорте строго соблюдаются правила безопасности: все чувствительные данные (содержимое команд fill, type, paste) автоматический вырезаются из итогового файла, а упавшие команды закомментируются с указанием текста ошибки. Это позволяет быстро дорабатывать упавшие сценарии автоматизации вручную.

Ограничения и вопросы безопасности

Перед внедрением chrome-bridge в свою повседневную работу важно учитывать несколько встроенных особенностей и ограничений инструмента:

• Локальный доступ: Сервер слушает исключительно адрес 127.0.0.1. Однако стоит помнить, что любой локальный процесс в вашей системе теоретически может отправить запрос к этому порту.
• Canvas и графические элементы: Приложения, построение которых полностью идет на HTML5 Canvas (сложные редакторы, игры), практически не отражаются в accessibility-дереве. Для работы с ними агенту всё же придется использовать режим скриншотов.
• Детекция отладчика: Использование команд CDP легко фиксируется антибот-системами.
• Разрешения расширения: Для полноценной работы плагину требуются права <all_urls> и debugger. Исходный код расширения открыт, состоит всего из одного файла background.js и манифеста, что позволяет легко провести личный аудит безопасности.

Резюме и выводы

Проект chrome-bridge эффективно решает проблему изоляции ИИ-агентов от реального пользовательского браузера. Вместо сложных виртуальных машин и неэффективного разбора скриншотов мы получаем точный, быструю и экономичный инструмент управления открытыми вкладками с сохранением всех ваших авторизаций. В любой момент пользователь может вернуть управление себе нажатием одной кнопки ⏏ на панели расширения.

Источник: habr.com