Antes de dejar que un AI Agent opere sitios web, valida la cadena entre el entorno y el Agent con cuatro niveles: prueba de humo de un paso, tareas de varios pasos, concurrencia y carga, e inyección de fallos, cada uno con sus métricas.
Que algo funcione una vez en un entorno de demostración no significa que la misma cadena pueda usarse de forma fiable todos los días.
Para evaluarla, hay que separar las pruebas: validar el entorno en su propia capa, validar el Agent en la suya y, al final, comprobar si ambos siguen siendo estables cuando se conectan.
Prueba de humo de un paso: cuatro acciones por separado
La prueba de humo hace solo cuatro cosas y cada una se ejecuta de forma independiente, sin encadenarlas: abrir una página concreta; localizar un elemento; hacer clic; recuperar el texto de ese elemento. Si las cuatro pasan, las bases de conexión, sesión y acceso a elementos están operativas.
Limitarse a cuatro acciones reduce mucho la superficie de fallo. Si no se abre la página, el problema suele estar en la salida de red o en los permisos de acceso. Si abre pero no se encuentra el elemento, quizá la página todavía no terminó de cargar o el método de localización depende demasiado del diseño actual. Si se localiza pero no se puede hacer clic, revisa si está cubierto o dentro de un iframe. Si el texto devuelto está vacío, confirma primero que se lee el contenido renderizado y no el HTML inicial.
Hay tres cifras que vigilar: tasa de éxito por paso, tiempo por paso y distribución de tipos de error. Deben ser estables ya en la fase de humo. Si la tasa de éxito de un solo paso oscila apenas entre el 80 y el 90 %, las pruebas posteriores pierden sentido.
Tareas de varios pasos: las ramas importan más que el número de pasos
Encadena las cuatro acciones en una tarea real, por ejemplo rellenar un formulario, recorrer varias páginas, filtrar por condiciones y guardar el resultado localmente. Añadir pasos es solo un cambio cuantitativo; la dificultad real son las ramas: aparece un aviso, desaparece el elemento objetivo, la página redirige por sí sola o surge una verificación que exige confirmación humana.
Aquí importa la tasa de finalización de la tarea, no la tasa de éxito de cada paso. Tras un fallo, es más importante que el Agent pueda ajustar la ruta y reconocer cuándo debe detenerse y reportarlo con claridad que terminar siempre el recorrido completo.
Otra cifra fácil de pasar por alto es el número de intervenciones humanas. Si la misma tarea se ejecuta veinte veces, cuántas veces hubo intervención y en qué paso se bloqueó cada ejecución pueden mostrar mejor la madurez de la cadena que la tasa global de finalización.
Concurrencia e inyección de fallos
Cuando una cadena individual es estable, se añade concurrencia. Se inician varios entornos a la vez con el mismo tipo de tarea y se observa si se interfieren entre sí y si la tasa de fallos empeora al aumentar la concurrencia. En esta fase, los fallos suelen venir de presión sobre recursos o sesiones, no necesariamente de un error en la lógica del Agent.
La inyección de fallos es una de las pruebas que más se omiten y también una de las más necesarias. Hay que provocar a propósito timeouts, desaparición de elementos, expiración de sesiones y CAPTCHAs, y observar la reacción: tras un timeout, ¿un reintento tiene éxito o el proceso queda bloqueado? Tras expirar la sesión, ¿se informa claramente del error o se sigue avanzando con credenciales inválidas?
Registra tres métricas: curva de tasa de fallos bajo concurrencia, tasa de recuperación tras una anomalía y tiempo adicional causado por cada anomalía. Una tasa de recuperación baja indica que la cadena solo funciona cuando todo va bien.
Validar por separado la capa del entorno
Las pruebas anteriores se realizan dentro de un entorno, pero cuando se combinan varios hay que validar una capa adicional: cada entorno debe poder iniciarse de forma independiente, mantener su propia sesión y caché y usar su propia IP de salida.
Los equipos que operan varias cuentas suelen gestionar un entorno por cuenta. Herramientas como PurpleMark proporcionan aislamiento de entornos para dar a cada cuenta un espacio de ejecución independiente. En la prueba, se inician varios entornos en paralelo y se confirma que Cookies, cachés y salidas no se mezclen entre ellos.
En esta capa se observan tres cifras: tasa de éxito al iniciar el entorno, cruce de datos entre entornos (debería ser cero en condiciones normales) y continuidad de la sesión después de reconstruir un entorno.
Cómo atribuir un fallo
Cuando la cadena falla, un error habitual es modificar de inmediato el script del Agent. El orden más razonable es comprobar primero que el entorno inicia y que la sesión no ha expirado, revisar después la salida de red y los nodos, y solo al final sospechar de la localización de elementos y la planificación de tareas del Agent. Invertir el orden lleva a cambiar repetidamente la parte equivocada.
Las cuatro acciones de la prueba de humo también sirven para atribuir la causa. Ante cualquier fallo, vuelve a ejecutar esas cuatro acciones por separado y observa qué eslabón se rompe primero. La mayoría de las veces, la respuesta aparece ahí.
