Hermes Agent oublie vos conversations : les correctifs

Votre agent devait se souvenir

Lundi, vous avez parlé de votre projet à Hermes Agent. Mercredi, il se présente comme s'il ne vous avait jamais rencontré. La promesse d'une mémoire persistante est la raison même pour laquelle vous avez choisi un agent auto-hébergé plutôt que ChatGPT, et maintenant il ressemble au même outil amnésique, en plus de la configuration.

Bonne nouvelle : le système de mémoire d'Hermes Agent est assez simple pour être diagnostiqué de l'extérieur. MEMORY.md et USER.md sont de simples fichiers markdown sur disque. Si l'agent ne se souvient pas, l'une des quatre choses suivantes se produit, et chacune a un correctif précis.

Comment fonctionne réellement la mémoire d'Hermes Agent

Avant de diagnostiquer, il faut comprendre la forme de ce qui est cassé.

Hermes Agent écrit deux types de mémoire dans le répertoire de données (généralement ~/.hermes/memories/) :

MEMORY.md - notes tenues par l'agent sur vos projets, préférences et workflows. Plafonné à environ 2 200 caractères, pour forcer le modèle à hiérarchiser.
USER.md - un profil stable de qui vous êtes : votre rôle, votre stack, votre style de communication.

Au début de chaque session, l'agent lit les deux fichiers et les injecte dans le system prompt. Pendant la session, il les met à jour automatiquement selon ce dont vous avez parlé. Quand la session se termine, les fichiers restent sur disque.

Cette dernière phrase, c'est toute la promesse. Si les fichiers ne sont pas sur disque après un redémarrage, la mémoire ne persiste pas. S'ils sont là et que l'agent oublie quand même, autre chose déraille. Ce sont deux bugs distincts.

Pour une vue plus large du système de mémoire lui-même, voir comment fonctionnent mémoire et skills dans Hermes Agent. Cet article ne couvre que les modes de défaillance.

Schéma montrant les fichiers MEMORY.md et USER.md chargés depuis le disque dans une session Hermes Agent

Cause 1 : Le volume de données n'est pas monté

C'est de loin la cause la plus fréquente. Symptôme : l'agent fonctionne bien pendant toute une conversation, se souvient de ce que vous avez dit il y a cinq minutes, puis le conteneur redémarre et il oublie que vous existez.

Ce qui se passe : les fichiers de mémoire sont écrits dans la couche inscriptible du conteneur au lieu d'un volume persistant. Quand vous faites docker stop puis docker start, cette couche survit. Quand vous faites docker rm (ou docker compose down, ou que l'hôte redémarre et recrée le conteneur), la couche inscriptible est détruite et MEMORY.md meurt avec elle.

Vérifiez d'abord : le répertoire de mémoire existe-t-il vraiment sur votre hôte ?

ls -la ~/.hermes/memories/

Si ce répertoire est vide ou absent alors que l'agent tourne depuis un moment, le conteneur n'écrit pas dedans.

Le correctif : montez ~/.hermes en tant que volume. Avec docker run :

docker run -v ~/.hermes:/root/.hermes ...

Dans docker-compose.yml :

services:
  hermes:
    volumes:
      - ~/.hermes:/root/.hermes

Après le changement, recréez le conteneur (pas seulement un restart) et vérifiez que le répertoire memories se remplit sur l'hôte au fil de votre usage. Le guide Docker d'Hermes Agent couvre le compose complet.

Cause 2 : Volume monté mais mauvaises permissions

Vous avez monté le volume, le répertoire existe sur l'hôte, mais les fichiers restent vides ou les logs de l'agent mentionnent « permission denied » à l'écriture.

Le conteneur et l'hôte partagent le même espace numérique d'UID, et rien ne réconcilie ces numéros par défaut. Si votre agent tourne en UID 1000 dans le conteneur et que le répertoire côté hôte appartient à root, l'écriture échoue silencieusement. Sur Fedora, RHEL et les autres distributions avec SELinux, l'écriture est refusée même quand les permissions Unix standard l'autoriseraient, et Docker ne vous préviendra pas.

Vérifiez la propriété :

ls -ln ~/.hermes/memories/

Correctif, Docker standard : rendez le répertoire hôte inscriptible par le même UID que celui du conteneur :

sudo chown -R $(id -u):$(id -g) ~/.hermes

Correctif, hôtes SELinux : ajoutez le label :Z au mount du volume pour que Docker le réétiquette pour un accès conteneur :

volumes:
  - ~/.hermes:/root/.hermes:Z

Correctif, Docker rootless : le « root » du conteneur est mappé sur votre UID hôte via les user namespaces, pas l'UID 0 réel. Le chown ci-dessus gère déjà ce cas, mais le modèle mental piège ceux qui tentent un sudo sur le fichier et voient l'échec persister.

Cause 3 : La fenêtre de contexte est pleine, pas le fichier mémoire

Symptôme : MEMORY.md est sur disque, il contient les notes de votre projet, un cat montre le contenu, et l'agent agit quand même comme s'il ne s'en souvenait pas. Ce n'est pas un bug de mémoire. C'est un bug de fenêtre de contexte déguisé en bug de mémoire.

Hermes Agent lit MEMORY.md et USER.md dans le system prompt en début de session, mais il porte aussi l'historique de la conversation en cours dans la même fenêtre de contexte. Si la taille combinée dépasse la limite du modèle, les tokens les plus anciens sont tronqués en premier. Même avant la limite dure, l'effet « lost in the middle » entre en jeu : les modèles récupèrent l'information de manière fiable au début et à la fin du contexte, et beaucoup moins bien au milieu.

Le fichier mémoire peut donc être présent et correct, mais au tour 30 d'une longue conversation, le modèle a reçu une version tronquée ou noyée au milieu et se comporte comme s'il ne l'avait jamais vue.

Diagnostics :

Comparez les fenêtres de contexte des modèles. Regardez le modèle configuré. Un modèle à petite fenêtre atteindra la limite bien avant un modèle 200k ou 1M tokens.
Vérifiez la taille de MEMORY.md. S'il est proche du plafond des 2 200 caractères, c'est bon. Si une version ancienne d'Hermes l'a laissé grossir à 20k, taillez.
Regardez la durée de la session en cours. Les sessions uniques longues subissent ça plus souvent que les sessions courtes et fréquentes.

Correctifs :

Passez à un modèle avec une fenêtre plus grande dans votre config.
Élaguez MEMORY.md à la main s'il a dépassé son plafond.
Redémarrez la session périodiquement. Hermes relit la mémoire à neuf en début de session, donc une nouvelle session charge MEMORY.md et USER.md dans un contexte propre.

Le même mode de défaillance est décrit sous un autre angle dans le guide de dépannage Telegram, à la section « les messages arrivent mais l'agent ignore le contenu ». C'est le même bug de fond sur des canaux différents.

Cause 4 : Confusion entre mémoire par chat et mémoire globale

Certains déploiements font tourner un processus Hermes Agent par chat Telegram, d'autres partagent la mémoire entre les chats. Si vous avez dit quelque chose à l'agent dans un DM privé et qu'il ne le sait pas quand vous passez à un groupe, c'est un décalage de portée, pas un bug de persistance.

Diagnostics :

Lisez votre config. S'il y a un motif de répertoire de données par chat, la mémoire est cloisonnée par chat par design.
Si vous êtes sur un setup auto-hébergé avec un seul ~/.hermes partagé entre tous les chats, la mémoire est globale et la cause est ailleurs.
Si vous faites tourner plusieurs processus Hermes contre le même home pour servir des chats différents, vous avez un problème d'un autre ordre : deux processus qui écrivent dans le même MEMORY.md s'écrasent, et le fichier finit dans un état qu'aucun d'eux n'a produit. Ne faites pas ça.

Correctif : décidez quel modèle vous voulez et configurez-le en conséquence. La plupart des opérateurs auto-hébergés veulent une mémoire globale (un vous, un agent, tous les chats). Les déploiements multi-utilisateurs ou multitenants veulent généralement un isolement par chat. Les deux sont valides, mais ils ne sont pas interchangeables.

Illustration de deux bulles de conversation superposées avec un fichier mémoire entre elles et des flèches montrant mémoire partagée versus isolée

Récupérer après un mauvais redémarrage

Si MEMORY.md est corrompu, tronqué à zéro octet ou contient du contenu illisible après un crash ou un arrêt brutal, le chemin de récupération est simple parce que c'est un simple fichier markdown.

Arrêtez l'agent avant de toucher au fichier. Un agent en marche peut écraser votre tentative de récupération.
Cherchez des sauvegardes. Si vous avez suivi les recommandations dans migrer Hermes Agent vers une nouvelle machine, vous avez déjà des snapshots périodiques de ~/.hermes. Restaurez le dernier snapshot valide.
Éditez à la main si nécessaire. MEMORY.md est du markdown. Ouvrez-le dans un éditeur de texte, retirez la section corrompue, sauvegardez. Il n'y a aucun schéma à respecter.
Démarrez l'agent et confirmez que la mémoire récupérée réapparaît à la session suivante.

Si vous n'aviez pas de sauvegardes, c'est le moment d'en mettre en place. Un tar czf hermes-backup-$(date +%F).tar.gz ~/.hermes quotidien en cron prend quelques secondes et vous offre un vrai chemin de récupération pour le prochain incident.

Quand arrêter de débugger et déléguer l'infrastructure

Chaque correctif de cet article est un petit ajustement du câblage du conteneur. Aucun n'est difficile isolément. Ce qui coûte du temps, c'est de les découvrir le jour où l'agent oublie un projet de deux semaines en pleine conversation, et de réaliser que le volume n'a jamais été monté, que les permissions étaient mauvaises, et qu'il n'y a aucune sauvegarde pour revenir en arrière.

Si vous préférez ne plus jamais voir un « permission denied » dans un log Hermes, Hermify fait tourner un Hermes Agent géré sur Telegram avec les mêmes MEMORY.md et USER.md, montés correctement, sauvegardés chaque nuit et restaurables en un clic. Votre mémoire reste la vôtre (les fichiers sont chiffrés au repos et téléchargeables), et le débogage des mounts de volume cesse d'être votre problème.

Pour une vue plus large sur la façon dont ce compromis se règle, voir hébergement d'Hermes Agent versus auto-hébergement.

Démarrez avec Hermify et sautez la checklist de persistance de mémoire pour de bon.