AgentProofBench : des chercheurs de CMU testent si les vérificateurs d'agents web sont réutilisables

Des chercheurs de Carnegie Mellon University, menés par Jingjie Ning, présentent AgentProofBench, un benchmark pour les vérificateurs d'agents web. Il répond à une question pratique : peut-on écrire une seule fois une règle d'acceptation du résultat, puis la réutiliser quand les exigences changent et lors de l'exécution réelle ? Le jeu couvre 97 tâches, 79 familles de tâches et quatre services web. Les programmes de vérification ont été générés par DeepSeek Flash et DeepSeek Pro.

L'idée du benchmark : mesurer un vérificateur à la seule exactitude de ses verdicts ne suffit pas. L'agent travaille en chaîne : il reçoit une instruction, agit sur le site, passe la vérification, et ce n'est qu'ensuite que le résultat est livré à l'utilisateur. AgentProofBench relie donc des tests appariés d'une règle d'acceptation « gelée » au lancement de l'agent depuis les mêmes états initiaux sauvegardés. Chaque erreur de test peut ainsi être rattachée à ses conséquences à l'exécution.

Réutiliser ou reconstruire

La première mesure porte sur la robustesse face aux changements d'exigences. Deux tests ont été appliqués à 48 familles de tâches : complete-panel et decision-replay. Ils indiquent si le programme de vérification initial reste valable quand l'exigence change, ou s'il faut le réécrire.

• Flash : 82 des 96 programmes initiaux ont été conservés (environ 85 %).
• Pro : 79 sur 96 ont été conservés (environ 82 %).
• L'écart entre réutilisation et reconstruction sur la métrique BA se situe, pour Flash, dans un intervalle de −5,47 à 1,57 point de pourcentage.
• Pour Pro, le même intervalle va de −10,16 à 0,00 pp.

L'intervalle de Flash inclut zéro : ces données ne montrent donc pas de perte notable due à la réutilisation. Chez Pro, la borne supérieure s'arrête à zéro, tandis que la borne inférieure descend à près de 10 points. Dans le pire cas, la réutilisation coûte nettement plus cher, et le benchmark rend ce coût mesurable.

Les erreurs du panel, indicateur de la livraison

La seconde mesure concerne l'exécution et repose sur 22 familles. Les auteurs ont examiné les affectations de programmes pour lesquelles les deux états initiaux sauvegardés sont livrés correctement, et ont cherché ce qui distingue ces cas des autres. Le facteur distinctif est la justesse du panel dans l'état de déploiement.

• Sur 33 affectations dont le panel ne contient aucune erreur, 32 ont produit une livraison correcte dans les deux états.
• Sur 11 affectations dont le panel contenait des erreurs, une seule y est parvenue.
• Toutes les régressions du program-gate par rapport aux règles de référence, ainsi que tous les cas de livraison bloquée, appartiennent au groupe dont le panel contient des erreurs.

L'écart de 97 % contre 9 % porte sur un petit échantillon de 44 affectations et ne peut pas être considéré comme définitif. Il montre néanmoins que tester le vérificateur sur un panel de tests avant le lancement fournit un signal pratique pour décider si le programme peut être mis en production.

Une base de référence pour les gates

Les auteurs ont comparé des stratégies de retour d'information vers l'agent. Parmi les variantes universelles testées, la plus forte proportion de livraisons correctes vient de la continuation neutre, où l'agent poursuit simplement son travail sans intervention du gate. Cela fixe un plancher : tout gate de vérification placé avant la livraison doit le dépasser, faute de quoi il n'ajoute que de la complexité et un risque de faux refus. Jusqu'ici, les agents web ne disposaient pas d'un tel plancher, et les équipes évaluaient souvent leurs gates à l'œil.

Ce que contient la publication et comment l'utiliser

Le benchmark est publié avec les instructions, les états de l'environnement, les programmes de vérification, les règles de référence et les trajectoires des agents. Le code et la page du projet sont disponibles sur GitHub et sur ethanning.github.io/AgentProofBench. Le preprint est enregistré sous la référence arXiv 2610.34634 et figure dans la sélection quotidienne Hugging Face Daily Papers.

Pour les équipes qui conçoivent des agents web avec vérification automatique du résultat, le benchmark suggère trois démarches concrètes. Premièrement : mesurer combien de vérificateurs générés survivent à un changement d'exigences, et ne pas les reconstruire sans nécessité. Deuxièmement : rechercher les erreurs du panel de tests avant le déploiement, car ce sont elles qui coïncident avec toutes les régressions et toutes les livraisons bloquées.

Troisièmement : toujours comparer le gate à la variante « sans intervention » avant de conclure qu'il améliore le résultat. Les limites sont elles aussi évidentes : quatre services web et deux modèles d'une même famille donnent un tableau étroit. Mais comme méthode d'évaluation au niveau de l'exigence et de la politique d'exécution, ce travail pose un cadre clair.