Le modèle de langage comme moteur de décision
Dans Hermes Agent, le modèle de langage n'est pas un simple générateur de texte : il joue le rôle de raisonnement central. À chaque tour de boucle, il reçoit l'ensemble du contexte disponible — instructions système, historique de la session, résultats des actions précédentes — et produit une décision structurée : quelle action entreprendre, avec quels paramètres, et pourquoi.
Cette séparation entre le modèle et le reste du système est intentionnelle. Le modèle ne dispose pas d'un accès direct aux ressources : il formule des intentions que le runtime traduit en appels d'outils concrets. Cela signifie que remplacer ou mettre à jour le modèle via `hermes model` n'affecte pas la configuration des outils ni les règles de validation déjà en place.
- Le modèle produit des intentions, pas des exécutions directes
- Le choix du modèle influence la qualité du raisonnement, pas les permissions
- La commande `hermes model` permet de changer de modèle sans reconfigurer l'agent
Le contexte : ce que l'agent sait à chaque instant
Le contexte est la fenêtre d'information que le modèle consulte à chaque étape. Il comprend les instructions système définies lors de la configuration, les messages échangés dans la session en cours, les résultats des outils appelés précédemment et, selon la configuration, des fragments de mémoire persistante injectés automatiquement. La qualité du contexte conditionne directement la pertinence des décisions.
Un contexte mal structuré ou trop volumineux dégrade les performances : le modèle peut perdre le fil des contraintes initiales ou répéter des actions déjà effectuées. L'hygiène du contexte — savoir ce qu'on y met et ce qu'on en retire — est donc une compétence de configuration à part entière, distincte du choix du modèle ou des outils.
- Instructions système, historique, résultats d'outils et mémoire forment le contexte
- Un contexte surchargé nuit à la cohérence des décisions
- La fenêtre de contexte a une limite physique liée au modèle utilisé
Les outils : la surface d'action de l'agent
Les outils sont les seuls moyens par lesquels l'agent peut agir sur le monde extérieur : lire un fichier, appeler une API, exécuter une commande, interroger une base de données. Chaque outil est déclaré explicitement avec ses permissions, et le runtime refuse toute action non déclarée. Cette liste fermée est ce qui distingue un agent contrôlé d'un script autonome sans garde-fous.
La commande `hermes mcp list` affiche les outils disponibles dans la configuration courante. Ajouter un outil avec `hermes mcp add` ne suffit pas : il faut aussi définir les permissions associées et, si l'outil accède à des ressources sensibles, prévoir une étape de validation avant que le résultat ne soit réinjecté dans le contexte.
- `hermes mcp list` liste les outils actifs
- `hermes mcp add` enregistre un nouvel outil
- Chaque outil doit avoir des permissions explicitement définies
- Un outil non déclaré ne peut pas être appelé par le modèle
La mémoire : persistance entre les sessions
La mémoire dans Hermes Agent désigne la capacité à conserver des informations au-delà d'une session unique. Elle peut prendre plusieurs formes : notes structurées, résumés de sessions passées, faits métier récurrents. Ces éléments sont stockés séparément du contexte de session et injectés sélectivement selon leur pertinence pour la tâche en cours.
Il est important de distinguer ce que l'agent mémorise automatiquement de ce que vous lui demandez explicitement de retenir. Une mémoire non maîtrisée peut introduire des biais persistants ou des informations obsolètes dans les décisions futures. La revue régulière du contenu mémorisé fait partie de la maintenance normale d'un agent en production.
- La mémoire persistante survit à la fermeture de session
- Les fragments mémorisés sont injectés dans le contexte selon leur pertinence
- Une mémoire non révisée peut contenir des informations périmées
La validation : le filet de sécurité de la boucle
Avant qu'une action soit exécutée ou qu'un résultat soit accepté, la couche de validation d'Hermes Agent peut appliquer des règles configurables : vérifier qu'une sortie respecte un schéma attendu, confirmer qu'une action destructrice a bien été approuvée, ou rejeter un résultat d'outil qui sort des plages autorisées. Cette étape n'est pas optionnelle dans un usage sérieux.
La validation n'est pas un mécanisme magique qui garantit l'absence d'erreur : elle réduit la surface des comportements inattendus en imposant des contraintes explicites. Plus les règles de validation sont précises, plus l'agent est prévisible. Définir ces règles demande de connaître les cas limites de votre cas d'usage, ce qui suppose une phase de test avant tout déploiement.
- La validation peut bloquer une action avant exécution
- Les règles de validation sont configurables par cas d'usage
- Une validation absente ne signifie pas que l'agent est fiable
La boucle complète : enchaînement des couches
La boucle agentique complète suit un cycle : le modèle reçoit le contexte, produit une intention, le runtime sélectionne l'outil correspondant, la validation contrôle l'action, l'outil s'exécute, le résultat est réinjecté dans le contexte, et le cycle recommence jusqu'à ce que la tâche soit considérée comme terminée ou qu'une condition d'arrêt soit atteinte. Chaque tour de boucle est traçable.
Comprendre ce cycle permet de diagnostiquer les comportements inattendus : si l'agent tourne en rond, le problème est souvent dans le contexte ou les conditions d'arrêt ; s'il prend des décisions incohérentes, le modèle manque peut-être d'informations pertinentes. La commande `hermes doctor` aide à identifier les anomalies de configuration avant qu'elles ne se manifestent en production.
- Chaque tour de boucle est : contexte → décision → validation → exécution → résultat
- `hermes doctor` détecte les incohérences de configuration
- Les conditions d'arrêt doivent être définies explicitement
Implications pour la confidentialité et la sécurité
L'architecture en couches d'Hermes Agent a des conséquences directes sur la confidentialité : tout ce qui entre dans le contexte — y compris les résultats d'outils — est traité par le modèle. Si le modèle est hébergé à distance, ces données transitent vers un service externe. La configuration du gateway via `hermes gateway setup` permet de choisir où le modèle s'exécute et donc où les données sont traitées.
La sécurité de l'agent dépend autant de la configuration des permissions que du modèle choisi. Un agent avec des outils d'écriture non restreints représente un risque opérationnel réel, indépendamment de la qualité du modèle. L'autonomie accordée à l'agent doit toujours être proportionnée au niveau de confiance établi par les tests et la validation.
- `hermes gateway setup` configure le point d'exécution du modèle
- Les données dans le contexte sont traitées par le modèle, local ou distant
- Les permissions d'outils définissent la surface de risque réelle
- L'autonomie doit être proportionnée au niveau de validation effectué
Sources et méthode
Cette page est une synthèse éditoriale indépendante. Les capacités et commandes doivent être vérifiées dans les sources officielles avant une utilisation en production.