Google détaille la boucle d’évaluation d’Agents CLI et met en garde contre les scores globaux

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Le blog des développeurs de Google a publié le 28 octobre 2026 un pas-à-pas sur les commandes d’évaluation d’Agents CLI, un outil pour construire des agents d’IA. L’article utilise un petit agent de démonstration pour montrer une boucle : exécuter des cas de test, noter les résultats, comparer les exécutions et agir sur l’écart. Son avertissement central est qu’un score global peut tromper, et qu’il faut donc lire les résultats cas par cas.

Le blog des développeurs de Google a publié le 28 octobre 2026 un pas-à-pas sur les commandes d’évaluation d’Agents CLI, un outil pour construire des agents d’IA. L’article utilise un petit agent de démonstration pour montrer une boucle : exécuter des cas de test, noter les résultats, comparer les exécutions et agir sur l’écart. Son avertissement central est qu’un score global peut tromper, et qu’il faut donc lire les résultats cas par cas. Les comparaisons de scores viennent d’une démonstration à quatre cas, pas d’un banc d’essai de produits réels ; le billet cite séparément une étude de Google.

L’espace de noms eval compte cinq commandes, chacune avec un rôle. eval generate exécute l’agent sur un jeu de cas. eval grade note les traces produites. eval compare met deux fichiers de résultats côte à côte. eval analyze regroupe les échecs par thèmes. eval optimize lance une passe automatique qui améliore l’invite de l’agent. Les auteurs appellent l’ensemble l’escalade de colline : modifier l’agent, relancer les cas, garder le changement si le score monte et l’annuler s’il baisse.

La démonstration utilise un modèle LangChain livré avec Agents CLI v1.8.0. Une mesure d’évaluation personnalisée, confiée à gemini-3.8-flash, note chaque réponse de 1 à 5 pour l’exactitude, la pertinence et la clarté. Les auteurs étendent le jeu par défaut, qui n’a qu’un cas, à quatre : une salutation, deux questions météo et une question hors sujet. La moyenne de référence est de 4,0 sur 5, avec un écart type de 1,41. Les auteurs jugent cette dispersion saine, car un 5,0 partout signifierait soit un agent parfait, soit un jeu trop facile pour montrer des différences.

Ils introduisent ensuite une erreur réaliste : un développeur colle un personnage de cuisinier dans l’invite système de l’agent météo. Le lint, les tests unitaires et la vérification des types passent, et l’agent fonctionne encore. La moyenne tombe à 2,75. La comparaison cas par cas montre où se situe le dégât. La salutation perd un point sur le ton, le cas hors sujet perd deux points pour dérive de périmètre, et le cas sf_weather perd deux points parce que l’agent cesse d’appeler son outil météo et invente des valeurs. Pour les auteurs, seule une évaluation de bout en bout qui note le comportement en contexte détecte ce genre de défaut.

La seconde expérience remplace le modèle de l’agent, gemini-3.8-flash, par gemini-2.5-flash. Selon l’article, la moyenne passe de nouveau de 4,00 à 2,75, mais la vue par cas diffère. Le modèle moins cher égale l’original sur la salutation et sur une question météo, perd un point sur l’autre, et la baisse visible vient du cas hors sujet, où il refuse avec une esquive disant que l’événement n’a pas encore eu lieu. Les auteurs préviennent qu’une invite réglée pour un modèle peut perdre en efficacité sur un autre, et que le modèle juge doit rester fixe pour que la comparaison soit équitable.

L’article traite aussi de la planification et des limites. Agents CLI ne fournit pas de planificateur ; une équipe peut lancer generate et grade chaque nuit avec cron ou Cloud Scheduler, et ajouter un script qui sort avec un code non nul quand la moyenne baisse au-delà d’un seuil. eval optimize fonctionne pour les projets ADK via le cadre GEPA, pas pour l’extension LangChain. Il ne modifie que l’invite et peut relever un score en s’ajustant trop à la formulation de la mesure ; une personne examine donc les candidats. Google rapporte aussi sa propre étude contrôlée : des agents de code utilisant l’outil ont lancé quatre fois plus d’évaluations, mais modifié l’agent après une évaluation à peu près aussi souvent que le groupe de référence. C’est une affirmation de Google, sans données dans l’article.

La leçon pratique est modeste. Gardez le jeu quotidien assez petit pour tourner à chaque changement, conservez les fichiers de résultats complets et pas seulement les scores, et lisez l’écart cas par cas avant de croire une moyenne. Un outil ne fournit pas le jugement sur les cas qui comptent, que l’équipe doit apporter elle-même.

Sources

FAQ

Que font les cinq commandes eval d’Agents CLI ?

eval generate exécute l’agent sur un jeu de cas, eval grade note les traces, eval compare met deux résultats côte à côte, eval analyze regroupe les échecs par thèmes et eval optimize améliore l’invite de façon automatique. Les auteurs appellent la boucle escalade de colline : modifier, relancer, garder si le score monte.

Que montrait réellement la démonstration à quatre cas ?

C’était une démonstration à quatre cas, pas un banc d’essai. La moyenne de référence était de 4,0 sur 5 ; un personnage de cuisinier collé par erreur l’a ramenée à 2,75 et l’outil météo n’était plus appelé. Avec gemini-2.5-flash la moyenne est aussi de 2,75, mais la baisse vient surtout du cas hors sujet. Il faut lire les écarts cas par cas.

Quelles limites s’appliquent à la méthode et aux affirmations de l’article ?

eval optimize ne vaut que pour les projets ADK, ne change que l’invite et peut s’ajuster trop à la formulation de la mesure ; une personne relit les candidats. Le modèle juge doit rester fixe et un changement de modèle demande sa propre invite. Le constat des quatre fois plus d’évaluations vient d’une étude de Google, sans données.