Почему AIPex не использует debugger (CDP) для управления браузером

Недавно AIPex выпустил новую версию. Одна из самых важных возможностей в ней — браузерные задачи могут выполняться в фоне и не мешать обычному рабочему процессу пользователя.

Это не «трюк», а результат осознанного инженерного решения: мы намеренно не строим управление браузером поверх debugger (Chrome DevTools Protocol, CDP).

В этой статье мы разберём, почему большинство решений выбирают debugger, и почему AIPex в большинстве агентных и повседневных сценариев автоматизации выбирает другой путь.

Почему большинство решений для управления браузером выбирают debugger (CDP)

Среди расширений и агентных решений «без миграции» сегодня часто встречаются:

• Manus Browser Operator от Manus
• Claude in Chrome от Anthropic
• open-source nano browser
• «расширенные» варианты Puppeteer / Playwright и похожих инструментов

Как правило, они построены на Chrome DevTools Protocol (CDP), особенно на его debugger-возможностях. Причины довольно просты.

1. Полное покрытие возможностей

CDP открывает почти все ключевые функции браузера, включая:

• навигацию и жизненный цикл страницы
• доступ к DOM и AXTree (Accessibility Tree)
• инъекцию событий (мышь, клавиатура, колесо)
• перехват и модификацию сети
• скриншоты, запись, профилирование производительности

Для сложной автоматизации CDP — это «полномощный интерфейс из коробки».

2. Accessibility Tree (AXTree) хорошо семантизирован

Через CDP можно получить построенное браузером Accessibility Tree:

• каждый узел содержит role / name / state
• естественно подходит для голосовых ассистентов и AI-понимания
• при качественной ARIA-разметке семантика очень хорошая

Поэтому AXTree стал главным способом представления страницы для многих AI-агентов.

3. Зрелая инженерная экосистема

Вокруг CDP сформировалась зрелая экосистема:

• базовые реализации вроде Puppeteer и Playwright
• документация, примеры, опыт сообщества
• понятная цена обучения и интеграции для инженеров автоматизации

Реальная цена debugger (CDP) в десктопных сценариях

CDP мощный, но в десктопном сценарии «работает параллельно с пользователем» он приносит заметные проблемы.

1. Фокус, передний план и UX

CDP не проектировался под «тихую фоновую работу». В реальной среде:

• attach debugger часто приводит к активации вкладки или выводу окна на передний план
• ввод и визуальный фокус могут быть принудительно перехвачены
• даже headless и параметры-обходы не гарантируют одинаковое поведение на разных ОС и браузерах

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

2. Жёсткая привязка к браузеру и среде выполнения

Использование CDP обычно означает:

• необходимость включать debug port
• сильную зависимость от Chrome / Chromium
• слабую поддержку некоторых встроенных WebView, ограниченных сред или не-Chromium браузеров

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

3. Трение из-за безопасности и прав

Debug port, права процессов, настройки сертификатов и похожие вещи в управляемых средах часто вызывают:

• блокировки политиками безопасности
• комплаенс-проверки
• сопротивление со стороны IT/ops

Проблема не в том, что «технически невозможно», а в том, что стоимость трения при развёртывании слишком высока.

Почему управление браузером не обязано требовать debugger

Ключевая цель дизайна AIPex:

Поэтому мы выбрали путь, не центрированный вокруг debugger.

Подход AIPex: семантические DOM-снимки + лёгкие взаимодействия

На стороне страницы AIPex использует чистый JavaScript / TypeScript, чтобы реализовать:

• семантические снимки страницы
• стабильное сопоставление узлов
• лёгкие взаимодействия на основе событий

А не полагаться на AXTree и debug-канал CDP.

1. Семантический снимок, а не debug-дерево

AIPex основан на @aipexstudio/dom-snapshot:

• напрямую обходит DOM-дерево
• извлекает семантику, связанную с доступностью (role / name / state)
• не зависит от Accessibility Tree (AXTree) через CDP

В README явно сказано: это чисто DOM-подход, а не обёртка над CDP.

2. Стабильные, переиспользуемые идентификаторы узлов

Мы автоматически генерируем стабильные data-aipex-nodeid для элементов страницы.

Это даёт:

• долгоживущую связь между «узлом в семантическом снимке» и «реальным DOM-элементом»
• меньше дрейфа, чем у селекторов в debugger-сценариях
• возможность точно найти действуемый элемент по попаданию в тексте

3. Стратегия снимка, ориентированная на интерактивные объекты

Семантический снимок в первую очередь фокусируется на:

• кнопках, ссылках, полях ввода и других интерактивных элементах
• подмножествах UI, относящихся к текущему диалогу/задаче

И фильтрует:

• display: none
• visibility: hidden
• aria-hidden
• inert

Чтобы не «скармливать» агенту бессмысленные или невидимые узлы.

4. Текстовое представление и семантический поиск

Снимок можно преобразовать в читаемый/поисковый текстовый формат (TextSnapshot):

→uid=dom_abc123 RootWebArea "My Page" <body>
uid=dom_def456 button "Отправить" <button>
uid=dom_ghi789 textbox "Email" <input> desc="Введите email"
StaticText "С возвращением"
*uid=dom_jkl012 link "Узнать больше" <a>

Где:

• * — текущий элемент в фокусе
• → — предок фокуса

Такое представление хорошо подходит и для TTS/озвучивания, и для поиска по естественному языку.

5. Примеры семантического поиска

Поддерживаются запросы с разделителем | и glob-поиск:

searchSnapshotText(formatted, "Войти | Login | Sign In");
searchSnapshotText(formatted, "button* | *submit*", {
  useGlob: true,
  contextLevels: 2
});

Найденные строки можно точно сопоставить обратно с DOM-элементами через data-aipex-nodeid.

6. События на стороне страницы вместо debug-инъекции

Взаимодействие выполняется через события на стороне страницы (например click, focus, input):

• через content script или канал сообщений расширения
• в координации с фоновым планировщиком задач
• без debug port
• без принудительного вывода окна на передний план

Инженерный взгляд на семантическое представление веб-страницы

В сценариях браузерной автоматизации и AI-агентов чаще всего используют два вида представления страницы:

DOM Tree

Источник: нативная Document Object Model браузера

Свойства: информация полная, но избыточная, семантика слабая Непосредственное использование неудобно для AI-понимания и управления.

Accessibility Tree (AXTree)

Источник: производное от ARIA-семантики

Свойства: высокая семантика Ограничения:

• зависит от качества ARIA на сайте
• информация узлов не всегда полная
• удалённый доступ часто опирается на CDP

На практике, если полагаться только на AXTree, «восприятие» агента ограничено зрелостью доступности целевого сайта — а реальный веб далёк от идеала.

Выбор AIPex и границы подхода

Семантически обрабатывая DOM Tree, AIPex может (без debugger) добиться:

• фонового выполнения без прерывания пользователя
• более полного представления информации страницы

Важно понимать: для сценариев, где нужны привилегированные возможности браузера (перехват сети, профилирование производительности, системные диалоги разрешений, доступ к файловой системе и т.п.), CDP остаётся незаменимым.

AIPex не «отрицает» debugger — мы просто выбираем более дружелюбный к UX инженерный путь для повседневной автоматизации и агентных сценариев.

Ссылки и источники

• @aipexstudio/dom-snapshot
• Исходники и документация: AIPexStudio/AIPex packages/dom-snapshot
• README (raw): dom-snapshot README