Comment fonctionne la mémoire d’Hermes

Hermes se souvient d’une session à l’autre avec deux petits fichiers et un index de recherche, et le choix de conception qui compte, c’est que les deux fichiers sont bornés : un fichier de notes personnelles de 2 200 caractères et un profil utilisateur de 1 375, injectés dans l’invite système comme un instantané figé au début d’une session. C’est une réponse délibérément différente du Markdown sans limite d’OpenClaw, et elle explique comment Hermes se comporte quand c’est plein.

Les deux fichiers

• MEMORY.md : les notes propres de l’agent. Faits sur l’environnement, conventions, particularités des outils, travail accompli ; environ huit à quinze entrées.
• USER.md : le profil utilisateur. Nom, rôle, fuseau horaire, préférences de communication, agacements ; environ cinq à dix entrées.
• Les deux vivent dans le répertoire Hermes de votre compte et sont gérés par l’agent via un outil de mémoire avec ajout, remplacement et suppression. Il n’y a pas de lecture, parce que le contenu est déjà dans l’invite.

L’instantané est figé à dessein : il est capturé une fois au début de la session et ne change jamais en cours de route, ce qui préserve le cache de préfixe du modèle. La mémoire paie donc aux frontières de session. Sur les messageries, une discussion est une session continue qui survit aux redémarrages, et la pratique documentée consiste à ouvrir une nouvelle session aux frontières naturelles, une tâche terminée, un changement de sujet, le début d’une journée, pour que les fichiers mis à jour soient relus.

Ce qu’il enregistre sans qu’on le lui demande

• Les préférences, les faits sur l’environnement, les corrections, les conventions, le travail accompli, et les demandes explicites de se souvenir de quelque chose.
• Pas les banalités, pas les faits qu’une recherche web renvoie, pas les vidages bruts, pas le contexte de débogage ponctuel, et pas ce que les fichiers de contexte disent déjà.

La mémoire ne se compacte pas d’elle-même : quand une écriture dépasserait la limite, l’outil de mémoire renvoie une erreur au lieu de supprimer des entrées en silence.

Quand c’est plein

Une écriture qui dépasserait la limite échoue avec une erreur qui liste les entrées actuelles et l’occupation, et l’agent fait de la place dans le même tour : il fusionne les entrées qui se recoupent par remplacement, retire celles qui sont périmées, puis ajoute. La documentation recommande de consolider au-delà de quatre-vingts pour cent, que l’en-tête de l’invite affiche. Les entrées compactes et denses sont la pratique : une ligne qui réunit le système, le gestionnaire de paquets, le shell et l’éditeur vaut mieux que quatre.

La recherche comble les trous

Les fichiers portent l’essentiel jusqu’à la session suivante ; un outil de recherche de sessions comble les trous une fois l’ancien contexte disparu, et des fournisseurs de mémoire peuvent se brancher en troisième couche, des fichiers intégrés aux services externes. Hermes vs OpenClaw met cela en regard des notes sans limite d’OpenClaw et de sa consolidation en arrière-plan.

Pourquoi la limite est la fonctionnalité

Une mémoire bornée ne peut ni gonfler l’invite ni dériver en transcription, et l’agent doit décider de ce qui compte, ce qui est le principe même d’une boucle d’auto-amélioration. Le coût, c’est une habitude de rangement et une frontière de session de temps en temps. Sur Diali, les fichiers vivent dans le bac à sable de l’assistant avec des sauvegardes disponibles, et les sessions tournent sur une passerelle qui reste en marche, si bien que les frontières sont la seule partie qui vous reste. Hermes hébergé sur Diali est la version hébergée ; le fonctionnement de la mémoire d’OpenClaw est la réponse de l’autre moteur.

• Deux fichiers, des limites strictes, un instantané figé par session.
• Les frontières sont le moment où la mémoire paie ; ouvrez une nouvelle session à dessein.
• Plein est une erreur à corriger, jamais une suppression silencieuse.