Hermes, l'agent harness qui apprend de ses tâches

NousResearch/hermes-agent

Hermes en bref

Hermes est un agent harness open-source pensé pour tourner sur une infrastructure personnelle (serveur, VPS, laptop) et devenir progressivement plus compétent à mesure qu'il travaille.

La différence tient en une idée simple: Hermes embarque une boucle d'apprentissage fermée : il exécute, évalue le résultat, en extrait un skill réutilisable, puis l'affine dans le temps. Concrètement, cela donne un agent qui se souvient des préférences de l'utilisateur, des projets en cours, des workflows qui fonctionnent, et qui les rejoue de mieux en mieux à chaque nouvelle demande similaire.

Comment ça marche techniquement

La boucle d'apprentissage fermée

C'est ici que se joue toute la spécificité de Hermes face à un harness classique. La boucle se déroule en cinq étapes, sans qu'aucune configuration manuelle ne soit nécessaire :

1. Exécution de tâche — l'étape classique d'un agent IA: l'objectif est reçu, décomposé en étapes, et les outils pertinents sont sélectionnés (recherche web, terminal, fichiers, navigateur) puis exécutés.
2. Évaluation du résultat — le résultat obtenu est comparé à l'objectif initial, en tenant compte des corrections explicites et de l'acceptation implicite (une réponse non modifiée équivaut à une validation des résultats).
3. Extraction d'un skill — lorsqu'une approche fonctionne, elle est transformée en un skill structuré, comme une fiche qui décrit « dans ce contexte, cette stratégie marche bien ». Cette création intervient en général après une tâche complexe réussie (5 appels d'outils ou plus), après une erreur corrigée, ou après une correction explicite de l'utilisateur.
4. Affinement du skill — à chaque situation similaire rencontrée par la suite, le résultat est comparé au skill existant, qui se met à jour si une meilleure stratégie apparaît, ou si l'utilisateur change de préférence sur une tache.
5. Recherche de skills — pour une nouvelle tâche, la bibliothèque de skills est interrogée via une recherche, combinée à un résumé produit par le modèle, afin de réutiliser ce qui a déjà fait ses preuves.

Rien à définir à la main : toute cette mécanique est gérée en interne par le système, via un « background review » qui tourne après chaque tour de conversation.

Le système de mémoire et de contexte

Hermes distingue quatre types de fichiers, chacun avec un rôle, un emplacement et des règles de chargement précis.

• MEMORY.md — Notes internes de l'agent : faits sur l'environnement, conventions, leçons apprises, tâches terminées. Emplacement : ~/.hermes/memories/. Limite : 2 200 caractères (~800 tokens). Écrit par l'agent lui-même, via l'outil memory.

• USER.md — Profil utilisateur : préférences, style de communication, niveau technique. Emplacement : ~/.hermes/memories/. Limite : 1 375 caractères (~500 tokens). Écrit par l'agent lui-même, via l'outil memory.

• SOUL.md — Personnalité et ton par défaut de l'instance Hermes (pas propre à un projet). Emplacement : HERMES_HOME (ex. ~/.hermes/SOUL.md) uniquement. Pas de limite stricte, tronqué si trop long. Écrit / personnalisé par l'utilisateur, manuellement.

• AGENTS.md / .hermes.md / CLAUDE.md / .cursorrules — Contexte de projet : architecture, conventions, instructions spécifiques à un dépôt. Emplacement : racine du dépôt Git, avec découverte progressive dans les sous-dossiers. Limite : 20 000 caractères par défaut (tronqué tête/queue). Écrit ou rajouté par l'utilisateur/l'équipe de développement, manuellement.

On vas maintenant voir plus en détail ce qui fait la vraie différence et la vraie force de Hermes sur son utilisation de la mémoire et des skills:

• MEMORY.md et USER.md. Ils sont gérés par l'outil memory, avec trois actions possibles (add, replace, remove), une déduplication automatique, et un mécanisme de rejet quand la limite de caractères est atteinte, l'agent doit alors consolider ou supprimer une entrée existante avant de pouvoir en ajouter une nouvelle. Ce plafond volontairement bas force l'agent à ne garder que l'essentiel, plutôt que d'accumuler du bruit qui alourdirait chaque prompt. En résumé, ce sont les fichiers qui stockent l'environnement et les préférences utilisateurs accumulées au fil du temps.
• Le snapshot est figé au démarrage de session. Les modifications de mémoire faites en cours de session sont bien écrites sur disque immédiatement, mais n'apparaissent dans le prompt système qu'à la session suivante, pour préserver le cache de préfixe du LLM et donc la vitesse d'execution et le coût des tokens à l'utilisation.
• SOUL.md est global, jamais local à un projet. Contrairement à AGENTS.md, il n'est chargé que depuis HERMES_HOME : il définit la personnalité de l'instance Hermes elle-même (ton, humour, formalité), pas celle d'un projet particulier.
• Un seul fichier de contexte projet est chargé par session, avec un ordre de priorité strict : .hermes.md → AGENTS.md → CLAUDE.md → .cursorrules. Le premier trouvé l'emporte, ce qui évite les conflits d'instructions.
• Découverte progressive des sous-dossiers. Dans un monorepo, chaque sous-dossier peut avoir son propre AGENTS.md, chargé uniquement au moment où l'agent y accède réellement (lecture de fichier, commande terminal), cela évite de saturer le contexte au démarrage tout en gardant des instructions précises par module (divulgation progressive).
• Tous ces fichiers passent par un scanner anti-injection avant chargement, qui détecte les tentatives de contournement d'instructions, les caractères invisibles, ou les commandes d'exfiltration de credentials ; un fichier suspect est purement et simplement bloqué.

Hermes propose aussi une recherche de sessions (session_search), indexée en SQLite, qui permet de retrouver n'importe quelle conversation passée même si elle n'est plus dans la mémoire active, sans coût de token tant qu'elle n'est pas interrogée.

À cela s’ajoute la capacité à injecter du contexte manuellement (@chemin/vers/fichier, @url, @git-diff...).

L'architecture d'exécution

Techniquement, Hermes se présente comme un environnement d'éxécution (runtime) doté d'outils intégrés (recherche web, exécution terminal, édition de fichiers, mémoire, délégation, navigateur), organisés en différents outils activables selon la plateforme. L'exécution de code repose sur cinq backends de sandbox, chacun avec son niveau d'isolation: local, Docker, SSH, Singularity, Modal.

Le support des LLM est classique via connexion API, avec les fournisseurs de modèles principaux (Claude, GPT, Gemini), des providers LLM tiers (OpenRouter) et les modèles open-source locaux.

On peut donc avoir accès à Hermes via l'outil CLI, mais aussi une fois configuré directement depuis une messagerie (discord, whatsapp, signal, email, sms et bien d'autres supports).

Les spécificités de Hermes

Mémoire persistante et skills auto-générés

Pour compléter la partie technique sur la mémoire, avec quelques point d'usages: Le contexte, les projets et les préférences restent disponibles d'une session à l'autre, que l'on communique via discord et que l'on passe ensuite par whatsapp par exemple. Les skills générés suivent un standard compatible avec la platforme agentskills.io, ce qui les rend partageables et intégrables via un hub communautaire.

Un détail qui change beaucoup la confiance qu'on peut accorder à ce mécanisme : l'écriture en mémoire et en skills peut être soumise à approbation humaine. Par défaut, l'agent écrit librement (write_approval: false), mais il est possible d'activer une validation explicite pour chaque nouvelle entrée de mémoire ou chaque nouveau skill, avec une file d'attente consultable (/memory pending, /skills pending) et un diff complet avant validation. C'est particulièrement utile si vous utilisez un petit modèle qui pourrait mal juger ce qu'il vient d'apprendre, ou si vous travaillez dans un environnement sensible.

Autre point notable : la revue en arrière-plan qui déclenche ces écritures peut tourner sur un modèle différent (moins coûteux) que le modèle de conversation principal, réduisant de fait le coût en token, sans perte de qualité de capture significative.

Enfin, Hermes ne se limite pas à ses deux fichiers de mémoire internes : il propose plusieurs providers de mémoire externes en plugin (Mem0, Supermemory...), qui tournent en complément de MEMORY.md et USER.md, pour ajouter des capacités de mémoire.

Automation et délégation

Hermes ne se limite pas à répondre en temps réel à des requêtes :

• Tâches planifiées en langage naturel ou via expressions cron, avec livraison des résultats vers n'importe quelle plateforme connectée.
• Sous-agents délégués, créés avec un contexte isolé, une session terminal dédié à chacun, et un ensemble d'outils restreint, permettant de traiter plusieurs flux de travail en parallèle.
• Exécution de code, qui permet à l'agent d'écrire des scripts Python appelant ses propres outils par RPC sandboxé, condensant ainsi un workflow multi-étapes en un seul tour de raisonnement pour l'agent.

Utilisation multi-surfaces

Comme abordé plus haut, Hermes permet l'accès à un même agent, une même mémoire, depuis le CLI, Discord, Slack, WhatsApp, Signal, via un serveur API compatible avec OpenAI, ou il est aussi directement intégrable dans un IDE. Une intégration MCP permet en plus de se connecter à des serveurs externes (GitHub, bases de données, API internes) sans développer de nouvel outil natif. Hermes peut aussi s'exposer lui-même comme serveur MCP (hermes mcp serve), pour être consommé par d'autres agents.

Sandbox et sécurité

Chaque backend de sandbox applique une isolation de namespaces (processus, réseau, système de fichiers) pour limiter la portée d'un code compromis. Des flux de validation de commandes et un blocage des patterns dangereux viennent compléter ce dispositif, avec une attention particulière portée à la détection des tentatives d'injection de prompt.

Le scanner anti-injection s'applique aussi aux skills installés depuis le hub communautaire : chaque skill tiers passe par une analyse de sécurité (exfiltration de données, commandes destructrices, signaux de supply-chain), avec un système de niveaux de confiance (builtin, official, trusted, community) qui détermine si une installation peut être forcée ou reste bloquée. Les bibliothèques de skills et les données de modèle utilisateur restent stockées localement, sans transmission automatique vers un service externe. Les outils sont là, mais il faut bien les configurer pour être sereins avec la sécurité.

Comment l'utiliser et en tirer parti

Installation

Sur macOS ou Linux, une seule commande installe l'ensemble :

Un assistant hermes setup guide ensuite le choix du fournisseur de modèle, des intégrations de messagerie et du backend de sandbox à utiliser. la documentation officiel est disponible ici

En faire un agent harness central

Plusieurs usages concrets se dégagent selon le besoin :

• Assistant CLI pour écrire, relire et exécuter du code directement dans un terminal.
• Bot déployé sur des plateformes de messagerie, avec continuité de contexte d'un canal à l'autre, pour piloter ces projets depuis n'importe ou.
• Couche d'apprentissage par-dessus un autre harness, Hermes peut servir de couche « learning + mémoire » par‑dessus un autre système d’orchestration, avec des outils prévus pour l'extraction/migration des skills et de la mémoire existante, en quelques minutes depuis d'autres frameworks.

Tirer parti de la boucle d'apprentissage

Les bénéfices apparaissent surtout sur des tâches répétitives et structurées : génération de rapports, revue de code, documentation récurrente, tache répétitive sur un back-office. Aussi, structurer le contexte d'un projet avec des skills, bien construit dès le départ sur la façon d’interagir avec vos repos, améliore bien la qualité de la mémoire et des skills produits par Hermes. Enfin, le meilleur indicateur pour vérifier que l'agent progresse réellement reste simple à observer : suivez, tâche après tâche, la proportion de réponses que vous acceptez telles quelles, sans devoir les corriger. Si ce taux augmente au fil du temps sur un même type de tâche, c'est le signe concret que la boucle d'apprentissage fonctionne.

Conclusion : les points forts du projet

Hermes se distingue par un ensemble de choix cohérents plutôt que par une seule fonctionnalité isolée :

• Un agent qui grandit avec l'usage, grâce à sa boucle d'apprentissage fermée.
• Une mémoire structurée en couches (MEMORY.md, USER.md, SOUL.md, AGENTS.md), chacune avec un rôle et des limites précises.
• Un contrôle humain optionnel sur ce que l'agent retient de vous, via l'approbation possible.
• Une architecture d'exécution sérieuse, avec sandbox multi-backends et sécurité renforcée.
• Un écosystème ouvert, sous licence MIT, compatible MCP et agentskills.io.
• Un projet pensé pour un usage développeur, avec une documentation complète, et une intégration simple dans le workflow via CLI ou IDE

Là où un agent exécute et un harness classique orchestre, Hermes ajoute une couche supplémentaire : celle d'un compagnon qui capitalise, tâche après tâche, sur une façon de travailler qui lui est propre. Le projet est open-source et documenté sur son dépôt Github, si vous souhaitez l'explorer plus en détail. NousResearch/hermes-agent