Tecnologia6 min de leitura

Vision-first vs seletores CSS: por que cliques por coordenadas são mais robustos

Seletores quebram quando o markup muda. A análise visual mantém a automação estável ao localizar elementos por capturas de tela em vez de caminhos DOM frágeis.

8 de abr. de 2026

O problema dos seletores em fluxos de trabalho antideteção

Os seletores CSS são a forma padrão como as ferramentas de automação encontram elementos em uma página. Você escreve um caminho como `button.submit-btn` ou `#login-form input[name="email"]`, e o script clica ou o preenche. Isso funciona até que a marcação mude — e em fluxos de trabalho antideteção, a marcação muda constantemente.

Diferentes perfis de navegador podem ver diferentes versões de página. Testes A/B, layouts direcionados geograficamente, banners de consentimento, desafios de detecção de bots e nomes de classe dinâmicos deslocam o DOM entre sessões. Um seletor que funciona no perfil #1 pode não existir no perfil #12.

Por que os seletores quebram com mais frequência do que você pensa

Nomes de classe dinâmicos — Frameworks como React, Next.js e Tailwind geram classes com hash ou utilitárias que mudam entre compilações. Um seletor direcionado a `.css-1a2b3c` para de funcionar após a próxima implantação.
Testes A/B — A mesma URL pode servir estruturas DOM completamente diferentes para visitantes diferentes. Seu seletor assume uma variante; a página mostra outra.
Banners de consentimento e cookies — Essas sobreposições injetam novos elementos, deslocam z-indexes e às vezes envolvem a página inteira em um contêiner que não existia quando você escreveu o seletor.
Sobreposições de detecção de bots — Desafios do Cloudflare, intersticiais do DataDome e sistemas similares substituem o conteúdo da página por sua própria marcação. Nenhum ajuste de seletor ajuda quando a página em si desapareceu.
Diferenças de localidade e geolocalização — Layouts RTL, texto de botão traduzido e componentes de UI específicos da região mudam a árvore DOM.

Em um script de navegador único, você percebe e corrige esses problemas um de cada vez. Em um lote de 50 perfis, um seletor quebrado falha silenciosamente em dezenas de sessões antes que alguém perceba.

Como funciona a interação orientada por visão

Orientado por visão significa que a IA tira uma captura de tela da página e a analisa visualmente — da mesma forma que um humano olharia para uma tela. Em vez de procurar no DOM por um seletor específico, ela identifica elementos por sua aparência: "o botão Sign Up azul no centro da página".

O fluxo é direto:

Tirar uma captura de tela do estado atual da página
Enviá-la para um modelo de visão que identifique elementos interativos e suas posições
Retornar caixas delimitadoras normalizadas (coordenadas) para cada elemento detectado
Clicar, passar o mouse ou interagir usando essas coordenadas — nenhuma pesquisa DOM necessária

// 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 });

Cliques de coordenadas vs cliques de seletor

Um clique de seletor diz "encontre o elemento neste caminho DOM e clique nele". Um clique de coordenadas diz "clique nesta posição na tela". A diferença importa quando as páginas divergem.

Abordagem baseada em seletor

// 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");

Abordagem baseada em visão

// 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 });

A abordagem baseada em visão não se importa com nomes de classe, IDs ou profundidade de aninhamento. Se o botão estiver visível na tela, será encontrado. Isso é especialmente poderoso em cenários antideteção onde cada perfil pode renderizar uma página ligeiramente diferente.

Análise agrupada para operações em lote

Ao executar 20+ perfis de navegador em paralelo, a análise de visão precisa ser eficiente. Ornold usa análise agrupada — ela tira capturas de tela de todas as sessões ativas, as envia como lote para o modelo de visão e retorna resultados para cada sessão em uma chamada.

Isso importa por duas razões:

Eficiência — Uma chamada de API lida com todas as sessões em vez de N chamadas separadas. A latência permanece aproximadamente constante independentemente do tamanho do lote.
Tratamento de divergência — A IA vê o estado real de cada sessão. Se o perfil #7 tiver uma sobreposição CAPTCHA enquanto os outros mostram o formulário, o resultado agrupado reflete isso. Você pode ramificar a lógica por sessão em vez de assumir que todas as páginas parecem iguais.

// 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

Quando o modo DOM ainda vence

A análise de visão nem sempre é a escolha certa. A interação baseada em DOM (modo padrão do Ornold) é mais rápida, gratuita e perfeitamente confiável para páginas estruturadas com marcação estável.

Use o modo DOM quando:

A página de destino tem HTML estável e previsível (por exemplo, seu próprio aplicativo, plataformas conhecidas)
Você está preenchendo formulários com campos de entrada e rótulos claros
A velocidade importa mais do que a resiliência — snapshots DOM são instantâneos, análise de visão leva 1-3 segundos
Você quer evitar custos de crédito de visão

Use o modo Vision quando:

As páginas variam entre perfis (testes A/B, direcionamento geográfico, layouts dinâmicos)
Você está lidando com UIs baseadas em canvas, páginas ricas em imagens ou componentes web personalizados
Os seletores quebram constantemente e o custo de manutenção é alto
Você precisa verificar como a página realmente se parece (QA visual)

Você pode ativar ambos os modos ao mesmo tempo. O agente de IA escolhe automaticamente a melhor abordagem para cada ação — DOM para preenchimentos de formulários simples, visão para páginas complexas ou imprevisíveis.

Comparação do mundo real

Aqui está o que acontece na prática ao executar um fluxo de registro em 30 sessões do Linken Sphere:

Automação baseada em seletor

25 de 30 sessões são concluídas com sucesso
3 falham porque um banner de consentimento deslocou o layout do formulário
1 falha porque o Cloudflare serviu uma página intersticial
1 falha porque o site implantou uma nova versão durante a execução com nomes de classe diferentes
Total: 83% de taxa de sucesso. Intervenção manual necessária para 5 sessões.

Automação baseada em visão

29 de 30 sessões são concluídas com sucesso
1 falha porque a página não carregou (timeout de rede — não é um problema de seletor)
Banners de consentimento, deslocamentos de layout e mudanças de nomes de classe não tiveram efeito
Total: 97% de taxa de sucesso. Uma tentativa novamente necessária para o timeout.

A lacuna se amplia conforme o tamanho do lote aumenta. Com 50+ perfis, a automação baseada em seletor normalmente requer manutenção constante. A automação baseada em visão permanece estável porque se adapta ao que realmente está na tela.

Configurando o modo Vision no Ornold

Ative o modo vision ao conectar seu agente de IA ao Ornold MCP. No assistente do painel de controle, selecione "Ambos os modos" na Etapa 2 para obter ferramentas DOM + Vision. Ou adicione o sinalizador manualmente:

# 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"]

Cada análise de visão custa 1 crédito. Snapshots DOM são gratuitos. Com o modo "ambos" ativado, o agente de IA usa DOM por padrão e alterna para visão apenas quando necessário.

Principais conclusões

Os seletores CSS assumem um DOM estável. Em fluxos de trabalho antideteção, o DOM é qualquer coisa menos estável.
A interação orientada por visão encontra elementos por aparência, não por caminho. Ela se adapta automaticamente a mudanças de layout, sobreposições e testes A/B.
A análise de visão agrupada lida com divergência de lote — cada sessão é analisada com base em seu estado real.
O modo DOM ainda é a melhor escolha padrão para velocidade e custo. Use visão quando as páginas são imprevisíveis ou os seletores quebram constantemente.
Ambos os modos podem coexistir. Deixe o agente de IA escolher a ferramenta certa para cada ação.