Engenharia10 min de leitura

Como executar dezenas de navegadores antidetect em paralelo sem perder a sincronização

Explicamos a análise visual agrupada, a recuperação de status e os controles de concorrência que mantêm grandes lotes de navegadores operando como um único sistema.

1 de abr. de 2026

O desafio da automação paralela de navegadores

Executar um navegador é simples. Executar 50 navegadores fazendo a mesma coisa simultaneamente é um problema completamente diferente. As páginas carregam em velocidades diferentes, CAPTCHAs aparecem em algumas sessões mas não em outras, e as condições de rede variam entre perfis. Sem coordenação, um lote paralelo rapidamente se torna 50 scripts independentes que divergem.

Ornold trata um lote de navegadores como um único sistema coordenado. Cada ação — navegação, preenchimento de formulários, cliques, resolução de CAPTCHA — é executada em todas as sessões ativas simultaneamente, com tratamento integrado de divergências e falhas.

Como a execução paralela funciona em Ornold

Quando você diz a um agente de IA "abra google.com em todos os navegadores", Ornold não percorre as sessões uma por uma. Ele envia o comando de navegação para todas as sessões ativas em paralelo via CDP (Chrome DevTools Protocol). O mesmo se aplica a cliques, preenchimentos de formulários, capturas de tela e todas as outras ações do navegador.

// This navigates ALL active sessions simultaneously
await browser_parallel_navigate({ url: "https://target.example/signup" });

// This fills the email field in ALL sessions at once
// Each session can get a different value
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

O prefixo "parallel" nos nomes das ferramentas não é apenas uma convenção de nomenclatura — reflete o modelo de execução real. Os comandos se distribuem para todas as sessões, executam simultaneamente e os resultados são coletados antes da próxima etapa.

Análise de visão agrupada

A parte mais difícil da automação paralela é saber o que está em cada tela. Em um lote de 30 navegadores, alguns podem mostrar o formulário de inscrição, outros podem ter um CAPTCHA e alguns podem estar presos em uma tela de carregamento. Você precisa saber o estado de cada sessão antes de decidir o que fazer a seguir.

A análise de visão agrupada de Ornold resolve isso tirando capturas de tela de todas as sessões, analisando-as como um lote e agrupando sessões por seu estado visual:

// Analyze all sessions at once
const analysis = await browser_parallel_vision_analyze_grouped();

// Results are grouped by page state:
// group "signup_form": [session1, session2, ... session25]
// group "captcha": [session26, session27, session28]
// group "error_page": [session29]
// group "loading": [session30]

Isso é fundamentalmente diferente de verificar cada sessão individualmente. Uma chamada de API fornece a imagem completa. O agente de IA pode então ramificar a lógica: resolver CAPTCHAs para as sessões que precisam, tentar novamente a navegação para as que falharam e continuar o fluxo para as que estão prontas.

A análise agrupada é especialmente valiosa quando as páginas divergem devido a testes A/B, direcionamento geográfico ou detecção de bots. Em vez de assumir que todas as sessões estão no mesmo estado, você vê a realidade atual de cada uma.

Concorrência limitada

Executar 50 navegadores em verdadeiro paralelo soa bem até você atingir os limites de recursos. Cada sessão de navegador consome CPU, memória e largura de banda de rede. As chamadas de análise de visão têm limites de taxa de API. Os serviços de resolução de CAPTCHA limitam solicitações simultâneas.

Ornold usa concorrência limitada — processa sessões em lotes controlados em vez de iniciar tudo de uma vez:

Ações do navegador (navegar, clicar, preencher) — Executadas em todas as sessões simultaneamente. Estes são comandos CDP leves que não consomem recursos.
Análise de visão — Processada em grupos (padrão: 12 por vez). As capturas de tela são tiradas em paralelo, mas as chamadas de análise são agrupadas para permanecer dentro dos limites de API.
Resolução de CAPTCHA — As solicitações são enviadas em paralelo, mas o serviço de resolução naturalmente limita com base na capacidade. Ornold gerencia a fila.
Capturas de tela — Capturadas simultaneamente de todas as sessões. Os dados de imagem são transmitidos, não armazenados em buffer na memória.

// Control concurrency for vision analysis
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 12 });

// For very large batches, you can lower concurrency
// to reduce memory pressure
await browser_parallel_vision_analyze_grouped({ maxConcurrency: 6 });

Rastreamento de status e recuperação

Em qualquer operação em lote, algumas sessões falharão. Uma página pode não carregar, um CAPTCHA pode expirar ou um envio de formulário pode retornar um erro. A questão é: como você detecta falhas e se recupera sem reiniciar todo o lote?

Ornold fornece rastreamento de status em tempo real para cada sessão ativa:

// Check the state of all sessions
const status = await browser_status();
// Returns per-session info:
// { id: "session-1", url: "https://target.example/dashboard", state: "ready" }
// { id: "session-2", url: "https://target.example/signup", state: "ready" }
// { id: "session-3", url: "about:blank", state: "error" }

Com dados de status, o agente de IA pode tomar decisões de recuperação:

Sessões na página errada — Navegar novamente para a URL de destino
Sessões com CAPTCHA — Executar o solucionador de CAPTCHA apenas para essas sessões
Sessões com erros — Tirar uma captura de tela para diagnóstico, depois tentar novamente ou pular
Sessões que estão à frente — Aguardar que as sessões mais lentas se atualizem antes da próxima ação em lote

Mantendo as sessões sincronizadas

O maior desafio na automação paralela não é iniciar 50 navegadores — é mantê-los sincronizados conforme o fluxo de trabalho progride. Diferentes páginas carregam em velocidades diferentes. Algumas sessões atingem limites de taxa. Outras são redirecionadas.

Ornold usa semântica de espera para todos: após cada ação paralela, aguarda até que todas as sessões sejam concluídas (ou o tempo limite expire) antes de passar para a próxima etapa. Isso evita que sessões rápidas ultrapassem as lentas.

// Navigate all sessions
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Wait until all sessions show the signup form
await browser_parallel_wait_for({
  text: "Create Account",
  timeoutMs: 15000
});
// Only proceeds when ALL sessions are ready (or timed out)

// Now fill forms — all sessions are on the same page
await browser_parallel_fill({ ref: "email", values: emails });

O tempo limite em `wait_for` atua como uma válvula de segurança. Se uma sessão não conseguir atingir o estado esperado dentro do tempo limite, ela é marcada em vez de bloquear todo o lote para sempre.

Dados por perfil em operações em lote

Paralelo não significa idêntico. Cada perfil de navegador normalmente precisa de dados únicos — diferentes endereços de e-mail, nomes, senhas ou outros valores de formulário. Ornold suporta valores por sessão em comandos em lote:

// Each session gets its own email
await browser_parallel_fill({
  ref: "email",
  values: [
    "user1@mail.com",
    "user2@mail.com",
    "user3@mail.com",
    // ... one per active session
  ]
});

// Each session gets its own password
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

O array de valores é mapeado 1:1 para sessões ativas em ordem. Se você tem 30 sessões ativas, fornece 30 valores. Isso mantém o modelo de execução paralela enquanto permite personalização completa por perfil.

Um fluxo de trabalho paralelo completo

Aqui está um fluxo realista de ponta a ponta para registrar contas em 30 perfis de navegador anti-detecção:

// 1. Start sessions and navigate
await browser_list(); // See available profiles
await browser_parallel_navigate({ url: "https://target.example/signup" });
await browser_parallel_wait_for({ text: "Create Account", timeoutMs: 15000 });

// 2. Fill forms with per-profile data
await browser_parallel_fill({ ref: "email", values: emails });
await browser_parallel_fill({ ref: "password", values: passwords });
await browser_parallel_fill({ ref: "name", values: names });

// 3. Solve CAPTCHAs (detected and solved across all sessions)
await browser_solve_captcha();

// 4. Submit
await browser_parallel_click({ ref: "submit" });

// 5. Verify results
await browser_parallel_wait_for({ text: "Welcome", timeoutMs: 20000 });
const status = await browser_status();
// Check which sessions succeeded and which need recovery

Dicas de dimensionamento

Comece com 5-10 sessões para validar o fluxo de trabalho, depois dimensione. A depuração é muito mais fácil com um lote pequeno.
Use `browser_status()` após cada etapa importante. Não assuma que todas as sessões estão no mesmo estado.
Defina tempos limite razoáveis. Muito curtos e você obterá falhas falsas. Muito longos e sessões presas bloquearão todo o lote.
Para lotes com mais de 30, considere dividi-los em grupos e executá-los sequencialmente. Isso reduz o uso máximo de recursos.
Monitore o uso de recursos do seu navegador anti-detecção. Cada perfil consome RAM — 50 instâncias de Chromium podem facilmente usar 16+ GB.
Mantenha a qualidade do proxy consistente. Qualidade de proxy mista leva a tempos de carregamento mistos, o que causa problemas de sincronização.

Armadilhas comuns

Assumir que todas as sessões veem a mesma página — Elas não veem. Testes A/B, direcionamento geográfico e detecção de bots criam divergências. Sempre verifique com `browser_status()` ou análise agrupada.
Sem lógica de recuperação — Se você não tratar falhas, uma sessão presa pode bloquear todo o lote. Construa tentativas e lógica de pulo.
Ignorar limites de recursos — 50 navegadores + análise de visão + resolução de CAPTCHA podem sobrecarregar uma máquina. Use concorrência limitada.
Pensamento sequencial em um sistema paralelo — Não percorra sessões uma por uma. Use as ferramentas `browser_parallel_*` para agir em todas as sessões de uma vez.
Não validar resultados — Um envio de formulário bem-sucedido não significa que a conta foi criada. Sempre valide o estado final.