Hermes Agent n’est pas seulement plus intelligent : il prouve maintenant qu’il a terminé

Le mode d’échec le plus fréquent des agents d’IA n’est pas qu’ils ne peuvent pas faire le travail, mais que vous ne pouvez pas être sûr que le travail soit réellement terminé. Ils déclarent avec confiance avoir fini, tout en oubliant un fichier. Ils exécutent un script sans inspecter la sortie. Ils continuent comme si l’étape précédente n’avait pas échoué.

Hermes Agent v0.18.0 — nom de code « The Judgment Release » — repose sur une idée simple : faire en sorte que l’agent prouve qu’il a terminé.

Consultez les notes de version complètes de v0.18.0 pour une liste complète des changements.

De « j’ai l’impression d’avoir fini » à « les preuves disent que c’est fini »

Traditionnellement, un modèle s’arrête quand il décide qu’il a suffisamment répondu. Cette décision est subjective. Avoir l’impression d’avoir fini n’est pas la même chose que répondre aux attentes.

Hermes v0.18.0 introduit deux mécanismes complémentaires qui transforment la fin d’une tâche d’une intuition en un objet vérifiable :

  • Standing Goals : une condition cible persistante contre laquelle l’agent vérifie continuellement ses progrès.
  • Completion Contracts : un accord vérifiable qui définit ce que signifie « terminé », avec des preuves et des étapes de validation.

En résumé : au lieu de lui demander de faire quelque chose et de lui faire confiance quand il dit que c’est fini, vous lui dites ce que signifie « fini », et il vous apporte les preuves.

Pourquoi l’auto-vérification compte

Hermes pouvait déjà appeler des outils, écrire du code, exécuter des tests et gérer des fichiers. Mais tout cela laissait une faille : il ne vérifiait pas activement son propre travail.

v0.18.0 change cela. Après avoir agi, l’agent tente de vérifier que le résultat satisfait les conditions définies. Cela semble mineur, mais cela transforme Hermes d’exécutant pur en exécutant responsable :

  • Il vérifie qu’un fichier existe et correspond aux attentes après l’avoir modifié.
  • Il inspecte les codes de sortie, les journaux et les effets secondaires après avoir exécuté des commandes.
  • Il repasse les critères de finition avant de vous dire que la tâche est terminée.

Ce n’est pas une garantie parfaite, mais cela réduit considérablement le risque de « ça a l’air fini, mais ce n’est pas le cas ».

Standing Goals : la condition de finition comme contrat à long terme

Les Standing Goals permettent de déclarer un objectif à long terme et de faire vérifier continuellement les progrès par l’agent. Cas d’usage typiques :

  • « Convertir tous les chemins codés en dur dans src/utils.py en variables d’environnement. »
  • « Résoudre tous les commentaires TODO du dépôt. »
  • « S’assurer que chaque appel API inclut une logique de retry. »

Ces tâches se résolvent rarement en une seule action. Elles nécessitent de vérifier, modifier et revérifier. Les Standing Goals obligent l’agent à se demander après chaque étape : « Me suis-je rapproché de l’objectif ? L’objectif est-il maintenant atteint ? »

Vous définissez l’objectif ; l’agent planifie, agit, vérifie et itère jusqu’à l’atteindre ou jusqu’à rencontrer un blocage nécessitant une intervention humaine.

Completion Contracts : rendre « terminé » vérifiable

Si les Standing Goals répondent à « quelle est la cible », les Completion Contracts répondent à « comment sait-on que c’est terminé ».

Un Completion Contract peut inclure :

  1. Critères de finition : conditions à remplir, comme l’existence d’un fichier, le passage des tests, le format de sortie correct ou la réussite du build.
  2. Méthode de vérification : l’outil ou la commande utilisé pour valider, comme pytest, curl, grep ou diff.
  3. Gestion des échecs : que faire si la vérification échoue — réessayer, annuler ou suspendre et informer l’utilisateur.

Cette structure rend le comportement de l’agent transparent. Vous pouvez voir exactement quel standard il a utilisé pour juger de la finition, et auditer ce jugement plus tard.

Exemple : laissez l’agent vérifier sa propre correction

Supposons que vous demandiez à Hermes de corriger un bug de gestion des valeurs nulles dans utils/parser.py et d’exiger que les tests passent avant de signaler la finition. Un Completion Contract pourrait ressembler à ceci :

Objectif : Corriger l’exception d’analyse des valeurs nulles dans utils/parser.py
Critères de finition :
  1. Le cas défaillant ne lève plus de TypeError
  2. pytest tests/test_parser.py passe entièrement
  3. Un test de régression couvrant l’exception est ajouté
Méthode de vérification :
  - Exécuter pytest tests/test_parser.py
  - Vérifier que le Git diff inclut des modifications de parser.py et test_parser.py
Gestion des échecs :
  - Si les tests échouent, analyser le log, modifier le code et réessayer jusqu’à 3 fois
  - Si cela échoue encore, suspendre et informer l’utilisateur

Hermes exécutera ce contrat : modifier le code, lancer les tests, inspecter le diff, et ne signalera la finition que lorsque les trois critères seront satisfaits. C’est bien plus fiable que « code modifié, tâche terminée ».

Combiné avec Mixture-of-Agents : une vérification plus prudente

v0.18.0 renforce également Mixture-of-Agents (MoA) : plusieurs modèles agissent comme un jury, chacun raisonnant indépendamment, tandis qu’un agrégateur produit la réponse finale.

Pour l’auto-vérification, MoA apporte de la valeur en :

  • Faisant inspecter les mêmes preuves par plusieurs modèles indépendamment.
  • Vous montrant le raisonnement de chaque modèle de référence.
  • Transformant la réponse finale en une conclusion croisée, pas en la supposition la plus confiante.

C’est comme ajouter une relecture par les pairs au jugement de finition de l’agent.

Ce que les utilisateurs remarqueront

Pour les utilisateurs quotidiens, v0.18.0 apporte trois améliorations concrètes :

  1. Moins de fausses finitions : l’agent se vérifie au lieu de se précipiter pour finir.
  2. Des décisions plus transparentes : vous pouvez voir les critères et les preuves utilisés.
  3. Des tâches longues plus stables : les objectifs persistants et les contrats de finition maintiennent l’automatisation en bonne voie.

Ces changements n’apparaissent pas comme une fonctionnalité spectaculaire, mais dans la manière dont l’agent se comporte.

Limites et recommandations

L’auto-vérification n’est pas magique. Elle est limitée par :

  • L’exhaustivité de vos critères de finition.
  • La capacité de vos outils de vérification à couvrir les usages réels.
  • La précision avec laquelle le modèle interprète les résultats de vérification.

Par conséquent, lors de son utilisation :

  • Rédigez des critères de finition spécifiques et vérifiables.
  • Privilégiez les méthodes de vérification avec des sorties claires et des codes de sortie.
  • Gardez une étape de relecture humaine pour les tâches critiques au lieu de déléguer entièrement le jugement à l’agent.

Points clés

  • Hermes Agent v0.18.0 « The Judgment Release » met l’accent sur l’auto-vérification et la finition prouvable.
  • Les Standing Goals maintiennent l’agent dans une boucle de vérification des progrès contre un objectif à long terme.
  • Les Completion Contracts décomposent « terminé » en critères vérifiables, méthodes de vérification et gestion des échecs.
  • L’agent ne s’arrête plus sur une intuition ; il juge la finition à l’aide de preuves.
  • Avec la validation croisée du Mixture-of-Agents, les jugements de finition deviennent plus prudents et transparents.
  • Les utilisateurs doivent rédiger des critères spécifiques et vérifiables, et conserver une relecture humaine pour les travaux critiques.

Références :