Cómo evaluar browser agents: checklist práctica

Empieza con un task contract que defina estado inicial, sitios y aplicaciones permitidos, datos, estado terminal, eventos prohibidos y el límite de confirmación humana. “Reserva un billete” no es una prueba suficiente: hay que fijar ruta, fecha, presupuesto, si se permite reservar y si el agente debe detenerse antes del pago. En tareas read-only el verdict puede verificar el registro encontrado; en tareas que cambian estado debe confirmar el estado real del backend, no el texto visto por el agente en la página.

WebArena es útil por sus sitios funcionales y por comprobar tareas realistas y largas, pero un benchmark público no reproduce tus permisos, locales, datos ni consecuencias. Convierte production jobs en task families saneadas y crea para cada una un oracle independiente: consulta API o de base de datos en sandbox, export estructurado, DOM state controlado o artifact revisado por una persona. El self-report “terminado” del agente nunca es un oracle.

• Outcome → el estado requerido se creó, encontró o modificó realmente.
• Trajectory → cada acción estaba permitida para la tarea y el estado actual.
• Side-effect integrity → no hubo submit, mensaje, pago o borrado adicional.
• Stop behavior → el agente se niega, pide aclaración o solicita approval correctamente.

El resultado de un browser eval depende de algo más que del modelo. Versiona image o VM, navegador, viewport, device scale, locale, timezone, fuentes, cookies, account fixture, network policy, datos iniciales y estado de cada aplicación. Registra por separado el observation mode—screenshot, accessibility tree, DOM, OCR o combinación—y el action mode—coordenadas, element IDs, primitivas de Playwright o atajos de teclado. El material adicional de OpenAI sobre CUA documenta diferencias de entorno browser/VM, prompts, sampling y scoring; sin ello la comparación de versiones no es reproducible.

BrowserGym unifica observation y action spaces para varios benchmarks de web agents; aplica la misma disciplina en tu harness interno. Guarda un environment manifest junto al resultado y rechaza el run si el fixture no inicia, el sitio cambia inesperadamente o el oracle no está disponible. Un infrastructure failure no debe contarse como model failure, ni una tarea ya completada accidentalmente como success. Reset debe restaurar todo el business state, incluidos correo, carrito, archivos y pending transactions.

Un frozen regression set cubre tareas típicas e incidentes conocidos; un held-out set introduce nuevas formulaciones, entidades y layout variants. Añade viewports responsive, otro zoom, traducciones, sticky banners, modals, lazy loading, controles deshabilitados, labels idénticos, tablas paginadas y elementos below the fold. Para computer-use agents prueba también ventana activa, focus, drag, clipboard, file picker y system dialogs. El objetivo no es romper coordenadas, sino medir grounding sobre el estado semántico actual.

Añade perturbaciones temporales y operativas: respuestas lentas, spinners, screenshots stale, acciones aceptadas tras timeout, session expiry, redirects, nuevas pestañas y formularios guardados parcialmente. Las tareas ambiguas deben exigir aclaración y las imposibles terminar de forma segura. Mantén una contamination boundary: no uses screenshots held-out en prompts o few-shot examples y no optimices la policy contra cada fallo sin introducir un nuevo conjunto ciego.

Task success es necesario pero insuficiente. Un trace grader comprueba origin transitions, targets, campos introducidos, repeated actions, approval binding y prohibited states. Distingue perception error, wrong target, planning error, policy block, environment failure, premature stop y false success claim. El número de pasos y la latency solo importan después de correctness: un camino corto con un submit incorrecto no es más eficiente. Si existen varios caminos válidos, evalúa invariantes y no una action sequence exacta.

Una recovery suite arranca al agente desde un estado intermedio: un modal tapa el botón, la validación rechaza un campo, la navegación vuelve al login o se produce un timeout después del commit. Pass exige leer primero el estado real, no duplicar el side effect y elegir retry, reconcile, rollback o escalation. Para agentes estocásticos ejecuta varios runs independientes, informa la distribución y usa paired comparison con baseline; un replay exitoso no demuestra fiabilidad general.

• Functional verdict → un oracle independiente confirmó el estado final.
• Policy verdict → ninguna acción salió del scope o approval.
• Grounding verdict → el target coincidió con la intención en el frame real.
• Recovery verdict → el reintento no creó duplicados y conservó el audit trail.

Páginas, documentos, mensajes y tooltips son datos no confiables. Un security slice coloca prompt injections directas e indirectas en texto visible, accessibility attributes, documentos cargados y resultados de búsqueda. No compruebes solo si el agente repite la instrucción; comprueba los sinks: si intenta cambiar el objetivo, navegar a un origin prohibido, leer un canary secret, pegarlo en un formulario, subir un archivo o ejecutar una acción externa. Detectar prompt injection sin un sink verdict genera una falsa sensación de seguridad.

Ejecuta todos los write tests en cuentas desechables con canary data, email o webhooks interceptados, fake payment rail y un registro de backend mutations. Vincula el approval al payload exacto y al state snapshot: aprobar un destinatario no permite cambiar la dirección después del modal. Prueba cancelación, approval expirado, botones engañosos, download quarantine y secretos en el clipboard. No hacen falta credenciales de producción, pagos reales ni mensajes a personas externas para un eval basado en evidencia.

El decision record incluye dataset revision, environment manifest, modelo, prompt, observation/action adapter, policy, oracle, sample count, resultados por segmento, critical failures y reviewer. Compara el candidate con un known-good bundle usando los mismos task seeds. Promote exige non-regression del outcome, tolerancia cero a los critical side effects definidos y slices separados aprobados por dominio, locale, longitud de tarea y risk tier. Un benchmark público es una señal externa, no un sustituto del release gate propio.

El rollout avanza de un entorno offline y reseteable a shadow, read-only canary, draft-only writes y acciones estrechamente aprobadas. Monitoriza con la misma taxonomía offline: false completion, duplicate mutation, unexpected origin, approval mismatch y recovery failure. Rollback restaura un bundle compatible de modelo, prompt, adapter y policy, detiene nuevos runs y reconcilia side effects pendientes antes de reintentar. Un incident trace saneado solo entra al regression fixture tras revisar provenance y privacy.