Il y a un genre de PR dans les release notes qu'il faut lire deux fois, parce que la première lecture ne te dit pas ce qui s'est vraiment passé. L'entrée pertinente dans les notes de Hermes Agent v0.8.0, c'est celle-ci :
Guidance auto-optimisée pour l'utilisation d'outils GPT/Codex — L'agent a diagnostiqué et corrigé 5 modes de défaillance dans les appels d'outils GPT et Codex via un benchmarking comportemental automatisé, améliorant drastiquement la fiabilité sur les modèles OpenAI. (#6120)
À la première lecture, j'ai cru que c'était quelqu'un qui avait été un peu généreux avec le mot « auto-optimisée ». À la deuxième lecture, j'ai réalisé que c'était littéral. L'agent a fait tourner une suite de benchmarks sur lui-même, repéré des défaillances systématiques dans la façon dont les modèles OpenAI appelaient ses outils, généré des directives ciblées pour corriger ces défaillances, et vérifié que les corrections marchaient. Les humains ont validé le résultat. Mais toute l'étape diagnostiquer et corriger était automatisée.
Ça vaut le coup de décortiquer, parce que c'est le genre de capacité qui se glisse dans une release en une seule ligne et change ce à quoi les releases futures peuvent ressembler.
Le problème concret
L'association de Hermes Agent avec les modèles OpenAI — GPT-5, Codex — était visiblement bancale depuis quelques releases. Les utilisateurs signalaient qu'Anthropic Claude tournait sans accroc tandis que GPT-5 produisait parfois des arguments de mauvaise forme, sautait des étapes, ou perdait le fil de ce qu'il avait déjà fait dans une séquence multi-outils. Ce ne sont pas des bugs subtils ; tu peux les regarder se produire. Mais ils sont aussi exaspérants à corriger à la main, parce que les modes de défaillance sont spécifiques au modèle et dépendent de la formulation du prompt de manières difficiles à deviner.
Selon la description du PR, il y avait cinq schémas récurrents :
- •Sauter les vérifications préalables recommandées avant les appels d'outils destructifs.
- •Produire des arguments d'outil sous forme de chaînes brutes là où le schéma attendait des objets structurés ou des nombres.
- •Perdre le fil de quel appel d'outil avait déjà réussi dans une séquence chaînée, provoquant des doublons.
- •Refuser de réessayer après des erreurs transitoires même quand les directives le demandaient.
- •Dériver de « exécuter le plan » vers « re-planifier le plan » quand le contexte est long.
Aucun de ceux-là n'est théorique. Chacun avait une traînée d'issues GitHub derrière lui.
La boucle qui les a corrigés
L'approche du PR #6120 repose sur trois éléments.
Premièrement, une suite de benchmarks comportementaux automatisés. Un harness fait tourner l'agent sur un ensemble de scénarios synthétiques conçus pour provoquer chacun des cinq modes de défaillance. Pour chaque scénario, le benchmark enregistre ce que le modèle a fait, ce qu'il aurait dû faire, et si la différence correspond à l'un des patterns de défaillance connus.
Deuxièmement, une étape de génération de guidance. Quand le benchmark signale une défaillance, le harness produit des chaînes de guidance candidates — des instructions courtes, spécifiques au modèle, à ajouter au system prompt, ciblant précisément le pattern qui a échoué. Pas « sois plus prudent » ; des trucs comme « avant d'appeler un outil destructif, appelle d'abord l'outil de prévisualisation correspondant avec les mêmes arguments et rapporte sa sortie. » Les candidates sont générées à partir des défaillances réellement observées, pas d'une grille générique.
Troisièmement, une étape de re-benchmarking. Chaque chaîne de guidance candidate est testée sur la même suite de scénarios. Les guidances qui améliorent les scores sont conservées. Celles qui font régresser d'autres scénarios sont écartées. Les chaînes survivantes sont agrégées dans le system prompt GPT/Codex que Hermes livre.
Pourquoi c'est un autre type de chose
Historiquement, les prompts livrés avec un framework d'agent sont écrits par des humains — parfois un seul, parfois une petite équipe — qui se forgent des opinions sur ce qui marche ou pas en parcourant eux-mêmes des conversations. Ce processus a trois problèmes : il ne passe pas à l'échelle sur beaucoup de modèles, il ne peut pas être relancé à moindre coût quand un modèle est mis à jour, et il produit des prompts qui encodent les superstitions d'une personne en même temps que ses vraies observations.
Remplacer la boucle « un humain écrit, un humain évalue » par « un benchmark écrit des candidates, un benchmark les évalue » n'est pas la même chose que laisser une IA s'auto-tuner sans supervision. Les humains valident toujours la guidance finale. Mais le vrai travail — trouver les patterns et proposer des corrections — est maintenant mesurable et reproductible. Quand GPT-6 sortira, le même harness tournera à nouveau. Quand un nouveau mode de défaillance sera signalé, un nouveau scénario sera ajouté et la boucle repartira. Le coût de garder le prompt synchronisé avec le comportement réel du modèle baisse d'un ordre de grandeur.
Les changements apparentés dans la v0.8.0 pointent dans la même direction. La continuation par prefill thinking-only (#5931) gère le cas où un modèle produit un bloc de raisonnement sans bloc de contenu et se retrouve bloqué. Les directives de discipline d'exécution (#5414) ajoutent au system prompt une règle générale : « ne re-planifie pas sauf si quelque chose a vraiment changé ». La coercition des arguments d'appels d'outils (#5265) convertit silencieusement les chaînes en nombres et booléens quand le schéma JSON les attend — exactement l'erreur de typage d'arguments que le benchmark avait détectée. Dans un changelog, ces trois PRs ont l'air sans rapport. Lus avec le PR #6120, ils sont la surface visible d'une campagne délibérée : rendre l'agent plus fiable sur une famille de modèles donnée en mesurant, corrigeant, et re-mesurant.
L'implication silencieuse
Ce qui fait que ça ressemble à un moment charnière, et pas juste à une bonne release, c'est ce que ça laisse entrevoir de l'ingénierie d'agents quand on arrête d'écrire les prompts à la main. Un repo comme Hermes doit cibler douze providers différents et trente modèles différents. Suivre le comportement de chacun manuellement est déjà impossible. Si à la place tu traites « comment devrait-on prompter le modèle X » comme un problème de tuning qu'un harness de benchmarks résout, tu as un processus qui passe à l'échelle avec la taille du zoo de modèles au lieu de s'y noyer.
Rien de tout ça n'était le gros titre de la v0.8.0. Le gros titre, c'était « the intelligence release » et la démo, c'était le changement de modèle en live. Mais le truc silencieux sous le plancher, c'est que Hermes a maintenant un moyen de garder l'agent intelligent sur chaque modèle qu'il supporte, sans qu'un humain passe un week-end par modèle à re-tuner le system prompt. C'est le genre de capacité qui n'apparaîtra pas non plus comme feature dans la prochaine release — elle se manifestera simplement par « la fiabilité GPT sur Hermes continue de s'améliorer » au fil des six releases suivantes.
Et si tu lis les release notes pour le plaisir, comme moi, c'est la forme de la chose qu'il faut surveiller.