Технологии6 мин чтения

Vision-first против CSS-селекторов: почему клики по координатам надежнее

Селекторы ломаются при любом изменении разметки. Vision-анализ держит автоматизацию стабильной, находя элементы по скриншотам, а не по хрупким DOM-путям.

8 апр. 2026 г.

Проблема селекторов в антидетект-рабочих процессах

CSS-селекторы — это стандартный способ, которым инструменты автоматизации находят элементы на странице. Вы пишете путь вроде `button.submit-btn` или `#login-form input[name="email"]`, и скрипт кликает или заполняет его. Это работает, пока разметка не изменится — а в антидетект-рабочих процессах разметка меняется постоянно.

Разные браузер-профили могут видеть разные версии страницы. A/B-тесты, геотаргетированные макеты, баннеры согласия, вызовы обнаружения ботов и динамические имена классов — всё это смещает DOM между сессиями. Селектор, который работает в профиле #1, может не существовать в профиле #12.

Почему селекторы ломаются чаще, чем вы думаете

Динамические имена классов — Фреймворки вроде React, Next.js и Tailwind генерируют хешированные или утилитарные классы, которые меняются между сборками. Селектор, нацеленный на `.css-1a2b3c`, перестаёт работать после следующего развёртывания.
A/B-тестирование — Один и тот же URL может выдавать совершенно разные DOM-структуры разным посетителям. Ваш селектор предполагает один вариант; страница показывает другой.
Баннеры согласия и cookies — Эти оверлеи внедряют новые элементы, смещают z-индексы и иногда оборачивают всю страницу в контейнер, которого не было, когда вы писали селектор.
Оверлеи обнаружения ботов — Cloudflare-вызовы, DataDome-интерстициалы и подобные системы заменяют содержимое страницы своей разметкой. Никакая настройка селектора не поможет, когда самой страницы больше нет.
Различия по локали и геолокации — RTL-макеты, переведённый текст кнопок и региональные компоненты UI — всё это меняет дерево DOM.

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

Как работает взаимодействие, ориентированное на зрение

Ориентированное на зрение означает, что ИИ делает снимок экрана страницы и анализирует его визуально — так же, как человек смотрит на экран. Вместо поиска в DOM конкретного селектора он определяет элементы по их внешнему виду: "синяя кнопка Sign Up в центре страницы".

Процесс прямолинеен:

Сделать снимок экрана текущего состояния страницы
Отправить его модели зрения, которая определяет интерактивные элементы и их позиции
Вернуть нормализованные ограничивающие прямоугольники (координаты) для каждого обнаруженного элемента
Кликнуть, навести или взаимодействовать, используя эти координаты — поиск в DOM не требуется

// Vision-first click flow
await browser_parallel_navigate({ url: "https://target.example/signup" });
const grouped = await browser_parallel_vision_analyze_grouped();
// AI identifies elements visually across all active browsers
// Returns normalized bounding boxes for each element
await browser_parallel_click_normalized_box({ box: signUpButton.box });

Клики по координатам vs клики по селекторам

Клик по селектору говорит "найди элемент по этому пути в DOM и кликни его". Клик по координатам говорит "кликни в эту позицию на экране". Разница имеет значение, когда страницы расходятся.

Подход на основе селекторов

// Breaks if class name changes, element moves, or overlay appears
await page.click("button.btn-primary.submit-action");
// Breaks if form structure changes
await page.fill("#signup-form input[type=email]", "user@mail.com");

Подход на основе зрения

// Works regardless of class names, IDs, or DOM structure
await browser_parallel_screenshot();
const analysis = await browser_parallel_vision_analyze_grouped();
// AI finds "Sign Up" button visually — same as a human would
await browser_parallel_click_normalized_box({ box: analysis.signUp.box });

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

Групповой анализ для пакетных операций

При запуске 20+ браузер-профилей параллельно анализ зрения должен быть эффективным. Ornold использует групповой анализ — он берёт снимки экрана из всех активных сессий, отправляет их пакетом модели зрения и возвращает результаты для каждой сессии в одном вызове.

Это важно по двум причинам:

Эффективность — Один вызов API обрабатывает все сессии вместо N отдельных вызовов. Задержка остаётся примерно постоянной независимо от размера пакета.
Обработка расхождений — ИИ видит фактическое состояние каждой сессии. Если профиль #7 имеет оверлей CAPTCHA, а остальные показывают форму, групповой результат это отражает. Вы можете ветвить логику для каждой сессии вместо предположения, что все страницы выглядят одинаково.

// Grouped vision analysis across all active browsers
const results = await browser_parallel_vision_analyze_grouped();
// results.groups shows which browsers are in which state
// e.g., 15 browsers on the form, 3 on CAPTCHA, 2 on error page

Когда режим DOM всё ещё побеждает

Анализ зрения — не всегда правильный выбор. Взаимодействие на основе DOM (режим по умолчанию Ornold) быстрее, бесплатно и совершенно надёжно для структурированных страниц со стабильной разметкой.

Используйте режим DOM, когда:

Целевая страница имеет стабильный, предсказуемый HTML (например, ваше собственное приложение, известные платформы)
Вы заполняете формы с чёткими полями ввода и метками
Скорость важнее устойчивости — DOM-снимки мгновенны, анализ зрения занимает 1-3 секунды
Вы хотите избежать затрат на vision-кредиты

Используйте режим Vision, когда:

Страницы различаются между профилями (A/B-тесты, геотаргетирование, динамические макеты)
Вы имеете дело с canvas-интерфейсами, страницами, богатыми изображениями, или пользовательскими веб-компонентами
Селекторы постоянно ломаются и стоимость обслуживания высока
Вам нужно проверить, как на самом деле выглядит страница (визуальный QA)

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

Сравнение в реальном мире

Вот что происходит на практике при запуске потока регистрации в 30 сессиях Linken Sphere:

Автоматизация на основе селекторов

25 из 30 сессий завершаются успешно
3 не срабатывают, потому что баннер согласия сместил макет формы
1 не срабатывает, потому что Cloudflare выдал интерстициальную страницу
1 не срабатывает, потому что сайт развернул новую версию во время запуска с другими именами классов
Итого: 83% успеха. Требуется ручное вмешательство для 5 сессий.

Автоматизация на основе зрения

29 из 30 сессий завершаются успешно
1 не срабатывает, потому что страница не загрузилась (timeout сети — не проблема селектора)
Баннеры согласия, смещения макета и изменения имён классов не имели никакого эффекта
Итого: 97% успеха. Требуется один повтор для timeout.

Разрыв увеличивается по мере роста размера пакета. При 50+ профилях автоматизация на основе селекторов обычно требует постоянного обслуживания. Автоматизация на основе зрения остаётся стабильной, потому что адаптируется к тому, что на самом деле на экране.

Настройка режима Vision в Ornold

Включите режим vision при подключении вашего ИИ-агента к Ornold MCP. В мастере панели управления выберите "Оба режима" на шаге 2, чтобы получить инструменты DOM + Vision. Или добавьте флаг вручную:

# Claude Code — enable both DOM and Vision modes
claude mcp add --transport stdio ornold-browser -- npx ornold-mcp --token YOUR_TOKEN --mode both --linken-port 40080

# Codex — in config.toml
[mcp_servers.ornold-browser]
command = "npx"
args = ["ornold-mcp", "--token", "YOUR_TOKEN", "--mode", "both", "--linken-port", "40080"]

Каждый анализ зрения стоит 1 кредит. DOM-снимки бесплатны. С включённым режимом "оба", ИИ-агент использует DOM по умолчанию и переключается на зрение только при необходимости.

Ключевые выводы

CSS-селекторы предполагают стабильный DOM. В антидетект-рабочих процессах DOM — всё, но не стабильный.
Взаимодействие, ориентированное на зрение, находит элементы по внешнему виду, а не по пути. Оно автоматически адаптируется к изменениям макета, оверлеям и A/B-тестам.
Групповой анализ зрения обрабатывает расхождения пакета — каждая сессия анализируется на основе её фактического состояния.
Режим DOM — всё ещё лучший выбор по умолчанию для скорости и стоимости. Используйте зрение, когда страницы непредсказуемы или селекторы постоянно ломаются.
Оба режима могут сосуществовать. Позвольте ИИ-агенту выбрать правильный инструмент для каждого действия.