Ingeniería10 min de lectura

Cómo ejecutar decenas de navegadores antidetección en paralelo sin perder la sincronización

Desglosamos el análisis visual agrupado, la recuperación de estado y los controles de concurrencia que permiten que grandes lotes de navegadores funcionen como un solo sistema.

1 abr 2026

El desafío de la automatización paralela de navegadores

Ejecutar un navegador es sencillo. Ejecutar 50 navegadores haciendo lo mismo simultáneamente es un problema completamente diferente. Las páginas se cargan a diferentes velocidades, los CAPTCHA aparecen en algunas sesiones pero no en otras, y las condiciones de red varían entre perfiles. Sin coordinación, un lote paralelo rápidamente se convierte en 50 scripts independientes que se desvían.

Ornold trata un lote de navegadores como un único sistema coordinado. Cada acción — navegación, relleno de formularios, clics, resolución de CAPTCHA — se ejecuta en todas las sesiones activas simultáneamente, con manejo integrado de divergencias y fallos.

Cómo funciona la ejecución paralela en Ornold

Cuando le dices a un agente de IA "abre google.com en todos los navegadores", Ornold no recorre las sesiones una por una. Envía el comando de navegación a todas las sesiones activas en paralelo a través de CDP (Chrome DevTools Protocol). Lo mismo se aplica a clics, rellenos de formularios, capturas de pantalla y todas las demás acciones del 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)
});

El prefijo "parallel" en los nombres de las herramientas no es solo una convención de nomenclatura — refleja el modelo de ejecución real. Los comandos se distribuyen a todas las sesiones, se ejecutan concurrentemente y los resultados se recopilan antes del siguiente paso.

Análisis de visión agrupado

La parte más difícil de la automatización paralela es saber qué hay en cada pantalla. En un lote de 30 navegadores, algunos pueden mostrar el formulario de registro, otros pueden tener un CAPTCHA y algunos pueden estar atrapados en una pantalla de carga. Necesitas saber el estado de cada sesión antes de decidir qué hacer a continuación.

El análisis de visión agrupado de Ornold resuelve esto tomando capturas de pantalla de todas las sesiones, analizándolas como un lote y agrupando sesiones por su 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]

Esto es fundamentalmente diferente de verificar cada sesión individualmente. Una llamada a la API te da la imagen completa. El agente de IA puede entonces ramificar la lógica: resolver CAPTCHA para las sesiones que lo necesitan, reintentar la navegación para las que fallaron y continuar el flujo para las que están listas.

El análisis agrupado es especialmente valioso cuando las páginas divergen debido a pruebas A/B, geolocalización o detección de bots. En lugar de asumir que todas las sesiones están en el mismo estado, ves la realidad actual de cada una.

Concurrencia acotada

Ejecutar 50 navegadores en verdadero paralelo suena bien hasta que alcanzas los límites de recursos. Cada sesión de navegador consume CPU, memoria y ancho de banda de red. Las llamadas de análisis de visión tienen límites de velocidad de API. Los servicios de resolución de CAPTCHA limitan las solicitudes concurrentes.

Ornold utiliza concurrencia acotada — procesa sesiones en lotes controlados en lugar de lanzar todo a la vez:

Acciones del navegador (navegar, hacer clic, rellenar) — Se ejecutan en todas las sesiones simultáneamente. Estos son comandos CDP ligeros que no consumen recursos.
Análisis de visión — Procesado en grupos (predeterminado: 12 a la vez). Las capturas de pantalla se toman en paralelo, pero las llamadas de análisis se agrupan para mantenerse dentro de los límites de API.
Resolución de CAPTCHA — Las solicitudes se envían en paralelo, pero el servicio de resolución limita naturalmente según la capacidad. Ornold maneja la cola.
Capturas de pantalla — Capturadas simultáneamente de todas las sesiones. Los datos de imagen se transmiten, no se almacenan en búfer en memoria.

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

Seguimiento de estado y recuperación

En cualquier operación por lotes, algunas sesiones fallarán. Una página podría no cargarse, un CAPTCHA podría agotar el tiempo o un envío de formulario podría devolver un error. La pregunta es: ¿cómo detectas fallos y te recuperas sin reiniciar todo el lote?

Ornold proporciona seguimiento de estado en tiempo real para cada sesión activa:

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

Con datos de estado, el agente de IA puede tomar decisiones de recuperación:

Sesiones en la página incorrecta — Navegar nuevamente a la URL de destino
Sesiones con CAPTCHA — Ejecutar el solucionador de CAPTCHA solo para esas sesiones
Sesiones con errores — Tomar una captura de pantalla para diagnóstico, luego reintentar u omitir
Sesiones que están adelantadas — Esperar a que las sesiones más lentas se pongan al día antes de la siguiente acción por lotes

Mantener las sesiones sincronizadas

El mayor desafío en la automatización paralela no es iniciar 50 navegadores — es mantenerlos sincronizados mientras avanza el flujo de trabajo. Las diferentes páginas se cargan a diferentes velocidades. Algunas sesiones alcanzan límites de velocidad. Otras se redirigen.

Ornold utiliza semántica de espera para todos: después de cada acción paralela, espera hasta que todas las sesiones se completen (o agoten el tiempo) antes de pasar al siguiente paso. Esto evita que las sesiones rápidas se adelanten a las 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 });

El tiempo de espera en `wait_for` actúa como una válvula de seguridad. Si una sesión no puede alcanzar el estado esperado dentro del tiempo de espera, se marca en lugar de bloquear todo el lote para siempre.

Datos por perfil en operaciones por lotes

Paralelo no significa idéntico. Cada perfil de navegador típicamente necesita datos únicos — diferentes direcciones de correo electrónico, nombres, contraseñas u otros valores de formulario. Ornold admite valores por sesión en comandos por lotes:

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

El array de valores se asigna 1:1 a las sesiones activas en orden. Si tienes 30 sesiones activas, proporcionas 30 valores. Esto mantiene el modelo de ejecución paralela mientras permite personalización completa por perfil.

Un flujo de trabajo paralelo completo

Aquí hay un flujo realista de extremo a extremo para registrar cuentas en 30 perfiles de navegador antideteción:

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

Consejos de escalado

Comienza con 5-10 sesiones para validar el flujo de trabajo, luego escala. La depuración es mucho más fácil con un lote pequeño.
Usa `browser_status()` después de cada paso importante. No asumas que todas las sesiones están en el mismo estado.
Establece tiempos de espera razonables. Demasiado cortos y obtendrás fallos falsos. Demasiado largos y las sesiones atrapadas bloquearán todo el lote.
Para lotes de más de 30, considera dividirlos en grupos y ejecutarlos secuencialmente. Esto reduce el uso de recursos máximo.
Monitorea el uso de recursos de tu navegador antideteción. Cada perfil consume RAM — 50 instancias de Chromium pueden usar fácilmente 16+ GB.
Mantén la calidad del proxy consistente. La calidad mixta del proxy lleva a tiempos de carga mixtos, lo que causa problemas de sincronización.

Errores comunes

Asumir que todas las sesiones ven la misma página — No lo hacen. Las pruebas A/B, la geolocalización y la detección de bots crean divergencia. Siempre verifica con `browser_status()` o análisis agrupado.
Sin lógica de recuperación — Si no manejas fallos, una sesión atrapada puede bloquear todo el lote. Construye reintentos y lógica de omisión.
Ignorar límites de recursos — 50 navegadores + análisis de visión + resolución de CAPTCHA pueden sobrecargar una máquina. Usa concurrencia acotada.
Pensamiento secuencial en un sistema paralelo — No recorras sesiones una por una. Usa las herramientas `browser_parallel_*` para actuar en todas las sesiones a la vez.
No validar resultados — Un envío de formulario exitoso no significa que la cuenta fue creada. Siempre verifica el estado final.