veilletech.frCe qui se passe
L'équipe Copilot Studio de Microsoft, avec Toloka et Hugging Face, publie ThinkingBox, un environnement qui évalue un agent sur ce qu'il laisse dans les systèmes, et ThinkingBox-Bench, 507 scénarios métier répartis sur cinq domaines : vente au détail (98), assurance auto (100), voyage (104), néobanque (104) et conseil (101). Les résultats accompagnent une prépublication arXiv, non relue à ce stade.
L'exemple d'ouverture résume l'idée. Un agent enchaîne neuf appels d'outils corrects, applique bien la politique de remboursement, puis clôt le ticket comme « résolu ». L'état attendu était « en attente » : l'incident de livraison n'était pas réglé. Un correcteur qui lit les appels d'outils n'y voit rien ; la base, si.
Comment l'évaluation fonctionne
Chaque tâche fixe un état de départ, un objectif, des outils MCP, une politique métier et des vérifications exécutables. Un utilisateur simulé détient des informations privées — une référence, une date de naissance — qu'il ne livre que si l'agent les demande.
Chaque tentative tourne dans une session MCP isolée, sur une base réinitialisée. À la fin, un extracteur calcule ce qui a réellement changé, et des juges déterministes le comparent à l'état attendu : une valeur fausse, un effet manquant ou un effet en trop font échouer. 477 tâches sont jugées sur l'état seul ; 30 ajoutent une question binaire sur la réponse.
Chaque tâche est rejouée 20 fois, d'où trois mesures :
- pass@1 : part des tentatives réussies ;
- pass@20 : part des tâches réussies au moins une fois ;
- 20/20 observé : tâches réussies à chacune des vingt tentatives.
Ce que ça montre
Sur 121 680 tentatives valides couvrant 12 modèles, 79 853 ont échoué aux vérifications. Parmi elles, 67,24 % s'étaient terminées proprement : un outil d'écriture appelé, aucune erreur finale. On y trouvait pourtant des valeurs fausses (77,61 %), des effets non voulus (43,30 %) ou des effets manquants (25,36 %), ces catégories se recoupant.
L'écart entre « au moins une fois » et « à chaque fois » est le résultat central. Kimi-K3 réussit 476 tâches sur 507 au moins une fois, mais 68 seulement vingt fois sur vingt. Claude Opus 5 en réussit moins au moins une fois, mais 241 à chaque tentative.
Quatre échecs sur cinq (79,9 %) relèvent de l'usage des outils : l'agent entame le bon parcours, puis ne se remet pas d'une erreur d'outil, d'une précondition non remplie ou d'une recherche vide.
Ce que ça change
Les auteurs en tirent des recommandations qu'ils disent ne pas avoir mesurées :
- Vérifier l'état réel avant de valider, pas le résumé qu'en fait le modèle.
- Classer les erreurs d'outils, pour ne relancer que celles qui se rattrapent.
- Réduire les outils exposés à ce que le parcours exige.
- Exiger une validation humaine sur ce qui coûte cher à annuler.
Pour une évaluation interne : publier une mesure répétée, en précisant s'il s'agit du meilleur de k essais ou de tous.
Comment s'y prendre
Testé sous Linux et WSL, avec Python 3.11+, uv et Docker :
git clone https://github.com/huggingface/OpenEnv
cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen
git clone https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0
uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"Il faut ensuite Typesense 30.1, les serveurs MCP (tb mcp-start) et des
points d'accès de modèles pour l'agent, l'utilisateur simulé et le juge — un
seul peut tenir les trois rôles. Licences : code MIT, données
CDLA-Permissive-2.0, environnement OpenEnv BSD-3-Clause. Les tâches sont des
reconstitutions synthétiques.
Source : The Agent Said It Was Done. The Database Disagreed., blog Hugging Face, 3 octobre 2026. Prépublication : arXiv:2608.19741.