Как дать ИИ-агенту доступ к вашему настоящему Chrome через accessibility-дерево
Современные ИИ-агенты уже умеют выполнять действия в браузере, однако на практике такой сценарий часто упирается в ограничения. Playwright и Selenium обычно запускают отдельный экземпляр браузера с чистым профилем. В нём нет сохранённых сессий, корпоративного SSO и привычных авторизаций, поэтому первым препятствием становятся логин, двухфакторная аутентификация или CAPTCHA.
Другой вариант - подключиться к уже работающему Chrome через remote debugging. Он действительно позволяет использовать активный профиль, но требует запуска браузера со специальным флагом и может нарушить обычный пользовательский сценарий. MCP-серверы для браузера добавляют собственные конфигурации и требования совместимости, а для взаимодействия нередко используют скриншоты, которые быстро расходуют контекст модели.
Вендорские инструменты решают проблему лишь внутри своих экосистем. Расширение Anthropic управляет Chrome из Claude, расширение OpenAI связано с десктопным приложением, а браузер в VS Code Copilot работает в отдельной среде со своим профилем. Десктопные агенты с режимом computer use также действуют в песочнице и не получают доступ к повседневной пользовательской сессии.
Получается парадокс: почти у каждого уже есть настроенный и авторизованный браузер, но дать его стороннему агенту напрямую обычно невозможно. Проект chrome-bridge предлагает нейтральный мост между расширением Chrome и терминалом. Его идея описана в материале о том, как реализовать ИИ-агенты для браузера через accessibility-дерево.
Как устроен chrome-bridge
Проект состоит из небольшого расширения Chrome, локального Node-сервера и CLI. Вся схема выглядит так: расширение передаёт команды по WebSocket на локальный сервер, а тот предоставляет интерфейс командной строки. Облачная инфраструктура не используется, аккаунты не требуются, а данные остаются на компьютере пользователя.
Клиентом выступает обычный shell. Поэтому с системой может работать любой агент, способный выполнять терминальные команды: Claude Code, Cursor, Codex, GLM, Kimi, Qwen, DeepSeek или локальная языковая модель. Не нужны отдельный SDK, MCP-совместимость или привязка к конкретной версии модели. В этом и заключается практическая ценность решения: автоматизация браузера с помощью ИИ становится независимой от поставщика платформы.
Вместо постоянных изображений страницы агент получает accessibility tree - текстовое представление интерфейса со ссылками на интерактивные элементы. Кнопки, поля и ссылки получают идентификаторы вида `@eN`, по которым модель может обращаться к нужному объекту. На тестовой странице полное дерево занимало около 2,4 КБ, тогда как скриншот аналогичной области шириной 1000 пикселей - примерно 16 КБ.
Экономия касается не только размера контекста. Модель не пытается определить координаты кнопки на картинке, а выбирает конкретный элемент из структурированного описания. Такие идентификаторы сохраняются между последовательными снимками дерева и становятся недействительными после навигации. После перехода на другую страницу агент должен получить новый `snap`.
Именно такой подход лежит в основе сценария "управление Chrome через ИИ-агента": модель видит структуру интерфейса, отправляет команду по имени элемента и получает результат выполнения. Для обычных сайтов это зачастую надёжнее, дешевле и быстрее, чем постоянная передача изображений.
Доверенные события и реальные ограничения
Синтетические клики не всегда воспринимаются страницей как действия пользователя. У таких событий отсутствует флаг `isTrusted`, поэтому некоторые приложения их игнорируют. Для подобных случаев предусмотрен режим `--trusted`: событие отправляется через DevTools Input и получает признак доверенного действия.
У этого метода есть обратная сторона. Команды, связанные с CDP, включая работу с сетью, создание скриншотов и доверенные клики, подключают отладчик, а веб-страница или антибот-система может это обнаружить. Проект не пытается маскировать такое подключение: он предназначен для работы со своими аккаунтами на собственной машине, а не для обхода защит сторонних сервисов.
При этом браузерная автоматизация без скриншотов не означает полный отказ от изображений. Canvas-приложения, графические редакторы и сложные визуальные интерфейсы плохо отражаются в accessibility tree. В таких случаях агенту всё ещё может понадобиться снимок экрана, особенно если состояние объекта нельзя выразить обычным текстом.
Почему важны вердикты
После каждой команды агент должен понимать не только факт отправки события, но и его результат. Поэтому сервер возвращает понятные статусы: `succeeded`, если действие прошло успешно; `needs_human`, если требуется участие пользователя, например при логине; `blocked`, если сервис применил ограничение; и `uncertain`, если событие отправлено, но однозначного изменения не обнаружено.
Проверка на Excalidraw показала пользу такого подхода. Обычный клик по canvas завершился статусом `uncertain`: команда ушла, но интерфейс не изменился. Скриншот подтвердил отсутствие результата. После доверенного двойного клика появился текстовый элемент, который затем отобразился в accessibility tree. Агент получил не иллюзию успеха, а честную диагностику и возможность выбрать следующий шаг.
Дополнительную надёжность даёт кольцевой журнал команд. Каждая операция записывается во время выполнения с результатом `ok` или `fail`. С помощью `history --batch out` журнал можно экспортировать в виде сценария для повторного запуска. Неудачная строка сохраняется как комментарий вместе с описанием ошибки, а чувствительные значения, переданные через `fill`, `type` или `paste`, удаляются.
Такой реплей удобен для продолжения частично выполненной последовательности, но не является полностью идемпотентным. Если команда клика уже сработала, повторный запуск выполнит её снова. Поэтому после сбоя остаток сценария иногда приходится корректировать вручную.
Безопасность и область применения
Сервер принимает подключения только на `127.0.0.1` и не отвечает на запросы, поступающие со страниц. Однако любой процесс на локальном компьютере потенциально может обратиться к нему, поэтому инструмент следует запускать на доверенной машине и учитывать модель угроз.
Расширению необходимы разрешения `
По сути, chrome-bridge не пытается превратить браузерного агента в универсальную автономную систему. Он решает более узкую, но важную задачу: позволяет ИИ работать с тем Chrome, которым человек уже пользуется каждый день. Агент получает открытые вкладки, сохранённые входы и SSO, а человек сохраняет контроль над подтверждениями и нестандартными ситуациями.
Такой формат особенно полезен для повторяющихся операций: проверки кабинетов, обработки внутренних веб-систем, заполнения форм, анализа рабочих панелей и запуска локальных сценариев. При этом критичные действия - платежи, изменение прав доступа, удаление данных и прохождение CAPTCHA - разумно оставлять под контролем пользователя.
Главное преимущество подхода заключается в сочетании локальности, структурированного представления интерфейса и независимости от конкретной модели. Вместо дорогих скриншотных циклов агент получает компактное дерево элементов, а вместо закрытой экосистемы - обычный терминальный интерфейс. Подробный разбор архитектуры и практических ограничений доступен в публикации о браузерной автоматизации без скриншотов.