Cuando la automatización con Agents empieza a fallar al escalar, el problema suele estar menos en el modelo o el script que en la capa del entorno del navegador. Aquí se explican cuatro patrones frecuentes, sus señales observables y las prácticas de ingeniería para tratarlos.
Montar un Agent con LangChain, AutoGen o CrewAI y hacer que maneje sitios web mediante Playwright o Puppeteer no es especialmente difícil. Lo difícil es conseguir que siga funcionando de forma continua.
Al principio los problemas suelen pasar desapercibidos. Cuando aumenta el volumen de tareas, las anomalías se concentran: los sitios bloquean tareas, las sesiones de las cuentas caducan de repente o varios Agents se interfieren entre sí al ejecutarse a la vez. La reacción más habitual es revisar el código, para terminar descubriendo que el código no tenía ningún problema.
La causa suele estar en la capa del entorno del navegador. En proyectos con mucha ejecución, los fallos tienden a repetirse en unos pocos patrones. Una vez identificados, su tratamiento no resulta especialmente complicado.
Empezar antes de que el entorno esté listo
Si un entorno de navegador recién creado se usa de inmediato para ejecutar una tarea, es habitual que falle el inicio de sesión, que algunos elementos de la página no terminen de cargar o que aparezca una verificación en el primer paso. La razón es sencilla: ese entorno no tiene historial de visitas, cookies ni trayectoria de navegación. Para la plataforma es un dispositivo completamente desconocido, por lo que su nivel de confianza es naturalmente bajo.
La señal observable es que los fallos se concentran en las primeras tareas después de crear el entorno. Si se mueve la misma tarea a un entorno que lleva un tiempo en uso, suele completarse con normalidad.
La solución es convertir la disponibilidad del entorno en un estado explícito, en lugar de asumir que está listo por defecto. Tras crear un entorno, conviene dejarlo realizar primero una fase de navegación de baja intensidad y asignarle tareas reales solo cuando su estado sea estable. El planificador debe comprobar este paso antes de enviar una tarea, en vez de utilizar el entorno nada más obtenerlo.
Varias tareas compiten por el mismo entorno
Cuando aumenta la concurrencia, el síntoma más evidente es que se acumulan procesos, la memoria se agota y el sistema se vuelve lento. Más difíciles son los fallos ocultos: dos tareas usan sucesivamente el mismo conjunto de cookies y almacenamiento local, el estado de inicio de sesión de A desplaza al de B y, en los registros, parece que una tarea aleatoria falla de vez en cuando. Es complicado localizar la causa.
Aquí conviene tratar los entornos del navegador como recursos que pueden solicitarse y liberarse. Cada tarea solicita un entorno al comenzar y lo libera al terminar, con una relación uno a uno entre tarea y entorno. El almacenamiento de un entorno no es visible para los demás, de modo que el estado de sesión de una tarea no se filtra a otra. Al escalar a decenas de Agents en paralelo, la diferencia frente a «levantar muchos procesos de navegador dentro del script» resulta muy clara.
Si el escenario incluye varias cuentas, el aislamiento debe ser todavía más estricto: cada cuenta debe permanecer vinculada a un entorno fijo, sin solapamiento de parámetros de huella ni de almacenamiento con otras cuentas. PurpleMark aporta precisamente esta capa de aislamiento de entornos y programación centralizada para mantener una correspondencia estable uno a uno entre cuentas y entornos.
La sesión caduca y nadie lo detecta
Este tipo de fallo se pasa por alto con facilidad porque puede no producir ningún error. La tarea sigue avanzando y los registros continúan apareciendo, pero lo que se devuelve en realidad es una página de inicio de sesión o datos vacíos. El problema solo se descubre cuando el resultado ya ha entrado en la canalización de datos, y entonces hay que investigar hacia atrás desde las etapas posteriores, con un coste elevado.
La solución es tratar el estado de inicio de sesión como una condición previa explícita. Antes de comenzar una tarea, se comprueba que la sesión actual siga siendo válida. Si ha caducado, se ejecuta un flujo completo de inicio de sesión en vez de dejar que la tarea continúe con un estado inválido. El estado debe residir en la capa del entorno: cookies, almacenamiento local e historial de navegación se conservan allí y pueden restaurarse por completo al volver a iniciar el entorno, evitando reinicializar cada tarea de cuenta.
Una observación práctica: en cuentas de larga duración, los cambios frecuentes del estado de inicio de sesión pueden parecer una señal anómala para la plataforma y provocar verificaciones adicionales. Conviene evitar inicios de sesión innecesarios.
Un bloqueo detiene todo el lote
Otro tipo de fallo aparece de repente de forma masiva: muchas tareas dejan de entregar resultados al mismo tiempo. El sitio no siempre muestra un rechazo explícito; con mayor frecuencia devuelve contenido degradado o una página vacía, y el Agent continúa con datos sin valor hasta que el problema se hace visible en la etapa de datos.
Ante esta situación, lo primero es diferenciar un bloqueo de un fallo ordinario. Si el mismo grupo de entornos presenta anomalías aproximadamente al mismo tiempo, es muy probable que la causa esté en la capa del entorno. Seguir reintentando solo ampliará el impacto, así que conviene detener y aislar primero esos entornos y después investigar qué activó el problema.
Los desencadenantes habituales se agrupan en tres direcciones: varios entornos usan configuraciones de huella muy parecidas, por ejemplo WebGL, Canvas, listas de fuentes o versiones del motor casi idénticas; la IP de salida, la zona horaria y el idioma no coinciden, como una IP de Estados Unidos con una zona horaria asiática; o los intervalos entre acciones son demasiado regulares y el propio ritmo se convierte en una señal. Hay que alinear la configuración, controlar el ritmo y registrar tanto el estado del entorno como los resultados de las tareas para detectar indicios antes de que el fallo se extienda a todo un lote.
Separar esta capa
Los proyectos maduros suelen separar el entorno del navegador del Agent y gestionarlo como una capa independiente: el Agent se ocupa de la planificación y las decisiones, la capa del entorno de la identidad y el estado, y la ejecución sigue en Playwright o Puppeteer. Tras la separación, queda claro dónde gestionar si la identidad es coherente, si el estado se puede restaurar y si las tareas están realmente aisladas entre sí.
Si se observan en conjunto, los cuatro tipos de fallo anteriores comparten algo: no están en el modelo ni en la lógica del script. El modelo y el código deben seguir mejorando, por supuesto, pero la capacidad de una automatización para funcionar de forma estable a largo plazo suele depender de esta capa inferior.
Este contenido se comparte con fines de investigación técnica y práctica de desarrollo. La automatización debe utilizarse de forma legal y conforme a las normas, respetando los términos de servicio de la plataforma de destino y la legislación local aplicable.
