AgentProofBench: investigadores de CMU comprueban si se pueden reutilizar los verificadores de agentes web

Investigadores de Carnegie Mellon University, con Jingjie Ning al frente, han presentado AgentProofBench, un benchmark para verificadores de agentes web. Responde a una pregunta práctica: ¿se puede escribir una sola vez la regla de aceptación de un resultado y usarla después, tanto cuando cambian los requisitos como en la ejecución real? El recurso abarca 97 tareas, 79 familias de tareas y cuatro servicios web. Los verificadores, en forma de programas, los generaron DeepSeek Flash y DeepSeek Pro.

La idea del benchmark es que evaluar un verificador solo por la precisión de sus veredictos no basta. El agente trabaja en una cadena: recibe una instrucción, actúa en un sitio web, pasa una comprobación y solo entonces se entrega el resultado al usuario. Por eso AgentProofBench vincula pruebas emparejadas de una regla de aceptación «congelada» con ejecuciones del agente a partir de los mismos estados iniciales guardados. Cada error de una prueba puede rastrearse hasta sus consecuencias en la ejecución.

Reutilizar o reconstruir

La primera medición se refiere a la robustez ante cambios de requisitos. En 48 familias de tareas se aplicaron dos pruebas: complete-panel y decision-replay. Estas muestran si el programa verificador original sigue siendo válido cuando cambia el requisito o si hay que escribirlo de nuevo.

• Flash: se conservaron 82 de 96 programas originales (alrededor del 85%).
• Pro: se conservaron 79 de 96 (alrededor del 82%).
• La diferencia entre reutilizar y reconstruir, según la métrica BA, se sitúa para Flash en un intervalo de −5,47 a 1,57 puntos porcentuales.
• Para Pro, el mismo intervalo va de −10,16 a 0,00 pp.

El intervalo de Flash incluye el cero, es decir, en estos datos no se observa una pérdida apreciable por reutilizar. En Pro, el límite superior llega justo a cero y el inferior baja casi 10 puntos. En el peor caso, reutilizar sale notablemente más caro, y el benchmark permite medir ese coste.

Errores del panel como indicador de la entrega

La segunda medición atañe a la ejecución y se basa en 22 familias. Los autores analizaron las asignaciones de programas para las que los dos estados iniciales guardados se entregan correctamente y buscaron qué distingue esos casos del resto. Lo que los distingue es la corrección del panel en el estado de despliegue.

• De 33 asignaciones con un panel sin errores, 32 lograron una entrega correcta en ambos estados.
• De 11 asignaciones cuyo panel contenía errores, eso ocurrió solo en una.
• Todas las regresiones de program-gate respecto a las reglas de referencia y todos los casos de entrega retenida correspondieron al grupo con errores en el panel.

La brecha de 97% frente a 9% en una muestra pequeña de 44 asignaciones no puede considerarse definitiva. Pero indica que comprobar el verificador con un panel de pruebas antes del lanzamiento da una señal práctica sobre si el programa puede ponerse en producción.

Línea base para los gates

Los autores compararon distintas estrategias de retroalimentación para el agente. Entre las variantes universales evaluadas, la continuación neutra obtuvo la mayor proporción de entregas correctas; en ella el agente sigue trabajando sin intervención del gate. Esto fija un umbral mínimo: cualquier verificador-gate que se coloque antes de la entrega debe superarlo; de lo contrario, solo añade complejidad y riesgo de rechazos falsos. Hasta ahora no existía un umbral así para los agentes web, y los equipos solían evaluar los gates a ojo.

Qué incluye la publicación y cómo usarla

Junto con el benchmark se han publicado las instrucciones, los estados del entorno, los programas verificadores, las reglas de referencia y las trayectorias de los agentes. El código y la página del proyecto están disponibles en GitHub y en ethanning.github.io/AgentProofBench. El preprint está registrado como arXiv 2610.34634 y apareció en la selección diaria de Hugging Face Daily Papers.

Para los equipos que construyen agentes web con verificación automática del resultado, el benchmark ofrece tres pasos concretos. Primero: medir cuántos verificadores generados sobreviven a un cambio de requisitos y no reconstruirlos sin necesidad. Segundo: revisar el panel de pruebas en busca de errores antes del despliegue, ya que fueron justamente esos errores los que coincidieron con todas las regresiones y las entregas retenidas.

Tercero: comparar siempre el gate con la variante «sin intervención» antes de dar por hecho que mejora el resultado. Las limitaciones también son evidentes: cuatro servicios web y dos modelos de una misma línea ofrecen un panorama estrecho. Aun así, como metodología de evaluación a nivel de requisito y de política de ejecución, el trabajo establece un marco claro.