Un Agent Browser deja que un modelo decida cómo operar una página web en lugar de seguir pasos codificados de antemano. Las diferencias clave están en quién decide, cómo se interpreta la página, cómo se ejecutan las acciones y cuáles son sus límites reales hoy.
La automatización del navegador con scripts es conocida: localizar elementos, definir rutas, añadir manejo de excepciones y ejecutar con estabilidad, hasta que la página cambia de diseño. Si el cambio afecta a un punto clave, puede tocar reescribir todo el script, porque el código reconoce una estructura concreta y la estructura es precisamente lo que más suele cambiar.
Un Agent Browser adopta otro enfoque. Deja que el modelo observe el contenido de la página y decida qué hacer a continuación. Por eso también es menos sensible a los rediseños.
Diferencia 1: quién decide el siguiente paso
En un script tradicional, la ruta la escribe una persona. Dónde hacer clic primero, qué rellenar después y cuánto esperar a continuación queda fijado de antemano. Durante la ejecución, el script solo sigue esas instrucciones.
Un Agent Browser entrega la toma de decisiones al modelo. Tú describes el objetivo, por ejemplo organizar en una tabla el contenido de una fuente según ciertas condiciones. Qué página abrir, si filtrar antes de pasar de página y cómo gestionar una ventana emergente se decide durante la ejecución.
Es fácil subestimar esta diferencia. El coste de mantenimiento se desplaza de escribir código a explicar bien los requisitos. La dificultad técnica baja, pero aumenta la exigencia de describir el objetivo con precisión.
Diferencia 2: cómo sabe qué hay en la página
Los scripts reconocen elementos mediante selectores. Los selectores XPath y CSS apuntan a la posición de un nodo dentro de la estructura. Si cambia esa posición, el selector deja de funcionar.
Un Agent Browser, en cambio, entrega al modelo información de la estructura de la página o una captura. El modelo determina que un elemento es el botón de inicio de sesión, otro es el cuadro de búsqueda y otro muestra el precio de un producto. Se guía más por el significado que por las coordenadas.
El coste también es real. Para que el modelo entienda una página, hay que enviarle la estructura DOM o capturas; cuanto más compleja sea la página, más información habrá que transmitir. En tareas largas, este consumo puede ser importante. Además, cada paso debe esperar a que vuelva la inferencia del modelo, así que el proceso completo es claramente más lento que un script codificado de forma rígida.
Diferencia 3: cómo se ejecutan las acciones
Después de decidir, todavía hay que actuar. Estas herramientas suelen encapsular las capacidades del navegador en acciones invocables: abrir una página, hacer clic, rellenar formularios, iniciar sesión, subir archivos, desplazarse o pasar de página y extraer datos. El modelo indica qué acción llamar y con qué parámetros. El navegador la ejecuta y devuelve el resultado al modelo como entrada para la siguiente ronda.
La descomposición de tareas y la corrección de errores también ocurren en esta capa. Un objetivo se divide en varios pasos y se ejecuta en orden. Si el modelo detecta que tomó una ruta equivocada, puede probar otra entrada en lugar de detenerse inmediatamente con un error. Esto es especialmente importante en páginas con estructuras irregulares, donde la tasa de finalización depende en gran medida de la capacidad de recuperación.
Hasta dónde llega hoy
Las tareas deterministas y con pasos claros ya pueden funcionar: recopilar información pública según condiciones y convertirla en datos estructurados; realizar entradas repetitivas y envíos con formato en sistemas propios; o vigilar una página concreta y avisar cuando cambien precios, existencias o anuncios. Estos escenarios comparten tres rasgos: el recorrido es predecible, los fallos se pueden reintentar y una persona puede comprobar el resultado.
Dónde aún no es estable
La interpretación semántica es el punto donde más fácilmente aparecen problemas. Para decidir si debe pulsar un botón, el modelo tiene que entender primero su significado dentro del negocio. Cuando la página es compleja o el texto contradice lo esperado, surgen errores: entra por el lugar equivocado o extrae el campo incorrecto. Cuanto más profunda sea la cadena de pasos, más fácil es que se acumulen errores. Una pequeña desviación al principio puede ser imposible de corregir después.
Los escenarios de fuerte confrontación son aún más difíciles. Los CAPTCHA, los bloqueos de control de riesgo y la caducidad de la sesión dependen sobre todo del entorno subyacente, no del propio modelo. Por muy capaz que sea, el modelo no puede convertir una solicitud rechazada en una solicitud aceptada. La ejecución alojada en la nube y los proxies gestionados por el proveedor pueden cubrir parte del problema, pero también introducen costes por uso y dependencia de infraestructura de terceros.
Qué conviene evaluar al elegir
Que la ejecución se pueda observar y reproducir suele pasarse por alto, pero cuando algo falla es la principal forma de localizar el problema. También conviene revisar cómo corrige errores: ¿se detiene o intenta otra ruta? Hay que comprobar si se pueden controlar el modelo y el coste, porque las tareas largas suelen salir más caras de lo esperado. También importa la integración con herramientas y flujos personalizados y, por último, cómo se conserva el estado de inicio de sesión. Repetirlo todo porque se perdió la sesión resulta muy molesto.
Aclarar las reglas antes de usarlo
Que algo sea técnicamente posible no significa que esté autorizado. Primero hay que comprobar si los términos del servicio de la plataforma permiten el acceso automatizado y si la frecuencia de solicitudes puede ejercer presión sobre el servicio. Usar estas herramientas para registrar cuentas en masa o ejecutar automáticamente tareas de una plataforma a cambio de beneficios infringe las reglas de la plataforma. La detección del ritmo de operación, las rutas de comportamiento y la consistencia del entorno sigue mejorando, y las medidas suelen afectar a grupos de cuentas a la vez.
Si la tarea es legítima pero varias cuentas necesitan mantener estados de inicio de sesión separados, entra en juego el aislamiento del entorno. PurpleMark, por ejemplo, ofrece entornos independientes para que la sesión y el almacenamiento de cada cuenta no sean visibles para las demás.
Una forma práctica de validar la herramienta es elegir una tarea pequeña, conocida y con pasos claros, dejar que se ejecute de principio a fin, comparar el resultado con el obtenido manualmente, anotar cómo responde a los errores y calcular el tiempo real empleado. Si una tarea pequeña funciona bien, se puede ampliar después. Intentar automatizar todo el proceso desde el principio suele acabar bloqueado en algún paso intermedio.
