Mémoire Hermes Agent : limites et bonnes pratiques
Configurez la mémoire Hermes Agent : MEMORY.md, USER.md, limites, session search, hygiène des données et tests de persistance.
Introduction
La mémoire Hermes Agent est un petit état critique à gouverner, pas un historique illimité. Deux fichiers plats — MEMORY.md et USER.md — sont injectés en snapshot figé au démarrage de chaque session, et session_search complète le dispositif en retrouvant vos échanges passés dans la base SQLite locale. Ce tutoriel est utile à un utilisateur Hermes qui veut garder quelques préférences durables sans accumuler un profil opaque. À éviter si vous attendez un système qui retient tout : restez sur une approche plus simple, ou passez à un fournisseur de mémoire externe. Une mauvaise configuration se paie en sessions qui régressent, en doublons impossibles à purger, ou en secrets qui finissent dans le system prompt.
Résumé rapide
| Information | Cible | Pourquoi |
|---|---|---|
| Préférence durable utile dans plusieurs contextes (langue, format, fuseau) | USER.md | Toujours disponible, lisible dans le system prompt |
| Convention de projet, chemin durable, outil installé, piège rencontré | MEMORY.md | Fait durable et révisable par substring |
| Échange précis d'une session terminée | session_search (FTS5 sur SQLite) | Retrouver sans promouvoir en mémoire |
| Procédure récurrente avec critères et ressources | Skill SKILL.md | Chargé à la demande, ne consomme pas le plafond mémoire |
| Résultat reproductible d'une opération (rapport, brief, liste) | Artifact (artifacts/done/) | Versionnable, traçable, hors mémoire |
Comprendre ce que la mémoire fait — et ce qu'elle ne fait pas
La mémoire Hermes n'est ni un historique de conversations ni un mécanisme d'apprentissage. Ce sont deux fichiers Markdown courts, injectés tels quels au démarrage de chaque session, plus une base SQLite qui sert au session_search. MEMORY.md (plafond 2 200 caractères) stocke les notes opérationnelles de l'agent : faits d'environnement, conventions de projet, pièges découverts. USER.md (plafond 1 375 caractères) stocke votre profil : préférences de communication, fuseau, niveau technique, pet peeves. Les deux vivent sous ~/.hermes/memories/ pour le profil par défaut, ou sous ~/.hermes/profiles/<nom>/memories/ pour un profil dédié. L'agent gère ses entrées avec l'outil memory et les actions add, replace et remove ; il n'existe pas d'action read parce que le contenu arrive automatiquement dans le system prompt.
Trois conséquences structurent la suite. Le snapshot est figé : ce qui est écrit pendant une session n'apparaît qu'à la session suivante, jamais dans la session courante, ce qui préserve le prefix cache du LLM. La mémoire ne s'auto-compacte pas : un ajout qui dépasse le plafond échoue proprement, et l'agent doit consolider ou retirer des entrées avant de réessayer. Chaque entrée subit un scan de sécurité qui bloque les patterns d'injection, d'exfiltration de credentials, de backdoor SSH ou les caractères Unicode invisibles. Pour le cadre conceptuel des types de mémoire agentique, voyez Mémoire des agents IA ; pour les usages sémantiques plus lourds, reportez-vous à Mémoire long terme pour agents IA ou à Mémoire vectorielle pour agents IA.
Mémoire, session search, écriture et gouvernance
Choisir entre mémoire et session search
Le piège classique consiste à surcharger MEMORY.md avec des détails ponctuels. Une entrée mémoire doit être un fait durable, actionnable et utile dans plusieurs sessions ; tout ce qui est contextuel va plutôt dans session_search. La mémoire est limitée mais gratuite (elle vit dans le system prompt), tandis que session_search est illimitée et repose sur FTS5 dans ~/.hermes/state.db — retour en ~20 ms, et la possibilité de scroller dans la session retrouvée. Côté utilisateur, hermes sessions list permet de parcourir l'historique ; côté agent, session_search propose trois formes : discovery, scroll et browse. Mémorisez une langue, le chemin d'un projet récurrent, une convention obsolète, un piège récurrent et sa parade. Recherchez plutôt une commande exacte, un résultat de build précédent, une discussion d'hier. Ne conservez pas des chemins temporaires, des logs volumineux, des clés d'API, ni un état transitoire. Pour la distinction contexte utilisateur contre connaissance documentaire, voyez Mémoire agent vs RAG ; pour l'hygiène des données sensibles, voyez Données sensibles et agents IA.
Configurer, écrire, remplacer, supprimer
La configuration tient en trois commandes : hermes memory status pour voir ce qui est actif, hermes memory setup pour ouvrir le picker des fournisseurs externes (Honcho, OpenViking, Mem0, Holographic, RetainDB, ByteRover, Supermemory, Memori ou Hindsight via le catalogue de plugins), et hermes memory off pour désactiver un fournisseur externe. Le mode par défaut reste MEMORY.md et USER.md ; un fournisseur externe s'ajoute par-dessus. L'isolation par profil est la règle : un seul writer par Hermes home, sinon deux agents se concurrencent et finissent par composer un état que personne n'a écrit. Pour séparer des charges, utilisez hermes --profile <nom> ou hermes profile create <nom> ; le fichier de mémoire se déplace alors sous ~/.hermes/profiles/<nom>/memories/.
L'écriture, la mise à jour et la suppression passent par l'outil memory, jamais par édition directe (qui contournerait le scan de sécurité). add ajoute une entrée ; replace localise une entrée par une sous-chaîne courte et unique dans old_text, puis la remplace intégralement par content ; remove supprime selon le même mécanisme. Si la sous-chaîne correspond à plusieurs entrées, l'outil renvoie une erreur et demande un old_text plus précis. La doc officielle liste cinq raisons pour lesquelles « je lui ai dit de se souvenir et il a oublié », qui commencent par « vérifiez que l'écriture a réellement atteint le fichier » : pas d'appel réel à l'outil, écriture en attente via write_approval: true à approuver avec /memory approve all, profil différent, mémoire désactivée, ou session déjà ouverte qui n'a pas rechargé le snapshot. Aucune commande ne prouve mieux qu'une vérification dans une session neuve — et la règle d'or est de ne jamais afficher ni versionner un secret pour démontrer que la mémoire fonctionne.
Limites, erreurs et gouvernance
Les plafonds documentés sont stricts et bornent volontairement le système : memory à 2 200 caractères (8 à 15 entrées), user à 1 375 caractères (5 à 10 entrées), avec un affichage dans le system prompt au format [67% — 1 474/2 200 chars]. Quand une écriture ferait dépasser la limite, l'outil renvoie un message explicite avec l'usage courant et la liste des entrées actuelles ; l'agent doit alors consolider ou retirer des entrées obsolètes, puis réessayer dans le même tour. replace est lui aussi plafonné : remplacer une entrée courte par une version plus longue peut quand même dépasser la limite, et la nouvelle version doit être raccourcie ou une autre entrée retirée. Au-dessus de 80 % d'utilisation, la bonne pratique est de consolider proactivement avant tout nouvel ajout.
La revue mensuelle vérifie cinq points : doublons exacts (la détection automatique rejette les ajouts strictement identiques, mais pas les reformulations) ; formulations ambiguës ; détails datés obsolètes ; entrées redondantes avec un skill (un skill charge à la demande sans coûter de mémoire) ; informations déjà ailleurs, par exemple un chemin de projet dans un AGENTS.md. Pour le périmètre de la procédure réutilisable, voyez Créer un skill Hermes Agent réutilisable.
Exemple concret
Contexte. Vous avez deux charges distinctes : un profil contenu qui rédige des articles français pour FrameworksAgents, et un profil ops qui pilote un bot Telegram d'assistance interne à 12 personnes. Vous voulez que contenu retienne la langue, le ton, la convention typographique française et le chemin du repo, et que ops retienne le format court, le fuseau Europe/Paris et le fait que les logs sensibles passent par un fournisseur externe — sans que les deux profils se polluent.
Mise en place du profil contenu :
hermes profile create contenu --clone
hermes --profile contenu
Une fois la session ouverte, l'agent écrit lui-même les entrées :
USER.md add : "Rédaction en français, ton direct et pédagogique, listes courtes, pas de superlatifs."
MEMORY.md add : "Repo éditorial : ~/code/frameworksagents ; brief dans briefs/ready/, MDX dans src/content/<cluster>/ ; publier via scripts/prepublish_runner.py."
MEMORY.md add : "Stack éditoriale cible : Next.js 16, App Router, MDX, Tailwind v4. Ne pas recommander Pages Router."
Mise en place du profil ops :
USER.md add : "Réponses courtes en français, fuseau Europe/Paris, alertes ops en une phrase."
MEMORY.md add : "Bot Telegram assistance interne, 12 utilisateurs ; logs sensibles délégués à un fournisseur de mémoire externe — ne rien écrire dans MEMORY/USER qui touche aux identifiants."
Test de persistance. Pour chaque profil, fermez la session, ouvrez une session vierge du même profil, posez une question qui doit déclencher la préférence, vérifiez que la langue et le format sont respectés. Remplacez ensuite la préférence par son contraire (old_text="Réponses courtes" → content="Réponses détaillées") et revérifiez dans une nouvelle session. Test négatif enfin : un détail présent seulement dans l'historique (session_search doit le retrouver) ne doit pas avoir été promu en mémoire. Checklist mensuelle : capacité sous 80 % ; aucune entrée redondante avec un skill ; aucun secret ; une seule entrée par fait durable.
Bonnes pratiques
Une entrée = un fait durable et actionnable. Dater ce qui peut expirer. Préférer un lien vers une source de vérité à une copie longue. Relire la mémoire après un changement de projet, d'équipe, de modèle ou de politique de données : un petit état obsolète est plus dangereux qu'une mémoire vide, parce qu'il agit en silence. Isoler les charges par profil avant de songer à un fournisseur de mémoire externe : si deux contextes se polluent, c'est d'abord un problème d'isolation, pas un manque de mémoire. Vérifier la sortie de hermes memory status après une mise à jour de Hermes ; ne jamais afficher un secret pour prouver que la mémoire fonctionne.
Trois lignes de réalité terrain. La mémoire est un snapshot figé au démarrage de session — un changement visible prend toujours effet à la session suivante. Aucun outil ne compacte automatiquement : un dépassement est un échec explicite. Et la mémoire intégrée n'est qu'une partie du dispositif ; pour des volumes plus gros, branchez un fournisseur externe via hermes memory setup en gardant la mémoire intégrée comme couche de base.
Questions fréquentes
Quelle est la différence entre MEMORY.md et USER.md ?
MEMORY.md (2 200 caractères) stocke les notes opérationnelles de l'agent. USER.md (1 375 caractères) stocke votre profil : préférences, fuseau, niveau technique, pet peeves. Les deux sont injectés au démarrage de chaque session.
Pourquoi l'agent oublie-t-il après un redémarrage ?
Trois raisons fréquentes. L'écriture n'a pas réellement eu lieu — un petit modèle local peut confirmer de mémoire sans appeler l'outil memory. Vérifiez ~/.hermes/memories/MEMORY.md. write_approval: true met les écritures en attente ; exécutez /memory pending puis /memory approve all. Vous lisez un profil différent de celui qui a écrit — chaque profil a son propre dossier memories/ sous ~/.hermes/profiles/<nom>/.
Faut-il préférer la mémoire ou session_search ?
La mémoire pour les faits critiques, durables et utiles dans plusieurs sessions. session_search pour retrouver un échange précis dans l'historique. La première coûte des tokens à chaque prompt mais est instantanée ; la seconde est gratuite en appels LLM et illimitée, mais demande une requête. Les deux sont complémentaires.
Comment tester que la mémoire fonctionne ?
Ajoutez une préférence neutre, fermez la session, ouvrez-en une vierge, posez une question qui doit la déclencher, vérifiez l'effet. Remplacez ou supprimez ensuite l'entrée et revérifiez que l'effet disparaît. Un détail présent uniquement dans l'historique doit être retrouvé par session_search, pas promu en mémoire.
Quand activer un fournisseur de mémoire externe ?
Pour un usage solo et quelques préférences, la mémoire intégrée suffit. Activez un fournisseur externe via hermes memory setup quand vous avez besoin de volume, d'une gouvernance partagée entre agents, ou d'extraction automatique en fin de session. Un seul fournisseur est actif à la fois et la mémoire intégrée continue de fonctionner par-dessus.
Articles liés
La mémoire Hermes Agent est un snapshot borné à gouverner plutôt qu'un réservoir à remplir. Gardez peu d'entrées, vérifiables, datées si elles peuvent expirer ; isolez les charges par profil ; testez la persistance entre deux sessions ; et n'oubliez pas que session_search complète la mémoire sans la remplacer. Le point d'entrée pour replacer mémoire, skills, outils et profils dans une même architecture est Hermes Agent : guide pour builders IA.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.