AgentProofBench : des chercheurs de CMU testent la réutilisabilité des vérificateurs d'agents web

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

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

Réutiliser ou reconstruire

La première dimension concerne la robustesse face au changement des exigences. Sur 48 familles de tâches, deux tests ont été appliqués : complete-panel et decision-replay. Ils montrent si le programme-vérificateur initial reste valable quand une exigence change, ou s'il doit être réécrit de zéro.

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

L'intervalle de Flash inclut zéro, ce qui signifie qu'il n'y a pas de perte notable liée à la réutilisation dans ces données. Pour Pro, la borne supérieure touche zéro, tandis que la borne inférieure descend presque jusqu'à 10 points. Dans le pire des cas, la réutilisation coûte sensiblement plus cher, et le benchmark rend ce coût mesurable.

Les erreurs du panel comme indicateur de livraison

La seconde dimension concerne l'exécution et s'appuie 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. Ce qui les distingue, c'est la correction du panel au moment du déploiement.

• Sur 33 affectations avec un panel sans erreur, 32 ont donné une livraison correcte dans les deux états.
• Sur 11 affectations où le panel contenait des erreurs, cela n'est arrivé qu'une seule fois.
• Toutes les régressions de program-gate par rapport aux règles de référence, ainsi que tous les cas de livraison bloquée, se sont produits dans le groupe où le panel contenait des erreurs.

Un écart de 97 % contre 9 % sur un échantillon restreint de 44 affectations ne peut être considéré comme définitif. Mais il montre que tester le vérificateur sur le panel avant son déploiement fournit un signal pratique sur l'opportunité de le mettre en production.

Une ligne de base pour les gates

Les auteurs ont comparé plusieurs stratégies de retour d'information pour l'agent. Parmi les variantes universelles testées, c'est la continuation neutre — où l'agent poursuit simplement son travail sans intervention d'un gate — qui a donné la plus forte proportion de livraisons correctes. Cela fixe un plancher : tout vérificateur-gate placé avant la livraison doit dépasser ce résultat, sinon il ne fait qu'ajouter de la complexité et un risque de refus erronés. Jusqu'à présent, un tel plancher n'existait pas pour les agents web, et les équipes évaluaient souvent leurs gates à l'œil.

Ce que contient la publication et comment l'utiliser

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

Pour les équipes qui construisent des agents web avec vérification automatique des résultats, le benchmark offre trois pistes concrètes. Première : mesurer combien de vérificateurs générés survivent à un changement d'exigences, et ne pas les reconstruire sans nécessité. Deuxième : vérifier le panel de tests pour détecter les erreurs avant le déploiement, puisque ce sont précisément celles-ci qui coïncident avec toutes les régressions et toutes les livraisons bloquées observées.

Troisième : toujours comparer le gate à une option « sans intervention » avant de considérer qu'il améliore le résultat. Les limites sont elles aussi évidentes : quatre services web et deux modèles d'une même gamme ne donnent qu'un aperçu restreint. Mais en tant que méthodologie d'évaluation au niveau des exigences et de la politique d'exécution, ce travail pose un cadre clair.