Memoire

Introduction

Hermes Agent dispose d'un systeme de memoire a deux niveaux : une memoire integree basee sur deux fichiers texte (MEMORY.md et USER.md), et la possibilite d'activer un provider de memoire externe parmi neuf options. Cette page explique le fonctionnement de chaque niveau, les differences entre eux, et comment gerer les informations conservees.

La memoire integree est toujours active. Les providers externes sont additifs : ils s'ajoutent a la memoire integree sans la remplacer. Un seul provider externe peut etre actif a la fois.

Comment fonctionne la memoire integree

La memoire integree repose sur deux fichiers stockes dans ~/.hermes/memories/ :

Ces deux fichiers sont injectes dans le prompt systeme au debut de chaque session sous forme d'un snapshot gele. L'agent gere sa propre memoire via l'outil memory avec trois actions : add (ajouter), replace (remplacer par correspondance de sous-chaine), et remove (supprimer).

Le snapshot est capture une fois au lancement de la session et ne change jamais en cours de session. Cela preserve le cache de prefixe du LLM pour les performances. Les modifications de memoire effectuees pendant une session sont persistees sur disque immediatement, mais n'apparaissent dans le prompt systeme qu'a la session suivante.

La memoire integree inclut egalement :

• session_search : un outil de recherche plein texte (FTS5) dans l'historique des conversations, stocke dans ~/.hermes/state.db
• Learning Journey (/journey) : une timeline visuelle de tout ce que l'agent a appris, avec possibilite de supprimer ou editer des entrees

Questions couvertes

q-061: Comment fonctionne la memoire integree de Hermes Agent ?

La memoire integree fonctionne en deux couches :

1. MEMORY.md et USER.md : deux fichiers texte a taille limitee (2 200 et 1 375 caracteres) stockes dans ~/.hermes/memories/. Ils sont injectes comme snapshot gele dans le prompt systeme au debut de chaque session. L'agent les gere via l'outil memory avec les actions add, replace (par sous-chaine unique) et remove.

2. session_search : toutes les conversations CLI et messaging sont stockees dans une base SQLite (~/.hermes/state.db) avec indexation FTS5. L'agent peut rechercher des conversations passees sans appel LLM. L'outil supporte trois modes : decouverte (recherche par mot-cle), defilement (navigation dans une session), et parcours (sessions recentes).

La memoire integree est toujours active, meme quand un provider externe est configure. Les limites de caracteres sont strictes : si un ajout depasse la capacite, l'outil retourne une erreur au lieu de supprimer silencieusement des entrees. L'agent doit alors consolider ou supprimer des entrees avant de reessayer.

Source : Persistent Memory, commit b4f8c491.

q-062: Quelle difference entre MEMORY.md, USER.md et un provider de memoire externe ?

MEMORY.md est le carnet de notes de l'agent : faits sur l'environnement, conventions de projet, lecons apprises. USER.md est le profil utilisateur : preferences, style de communication, niveau technique. Les deux sont geres par l'agent lui-meme.

Un provider externe ajoute des capacites que la memoire integree n'a pas : recherche semantique, graphes de connaissances, extraction automatique de faits, modelisation utilisateur cross-session. Il ne remplace jamais la memoire integree -- il la complete.

Source : Persistent Memory, Memory Providers, commit b4f8c491.

q-063: Quels providers de memoire externe Hermes Agent propose-t-il ?

Hermes Agent propose 9 providers de memoire externe (la documentation en liste 8 dans le guide principal, plus Memori) :

La selection et configuration se fait via hermes memory setup (assistant interactif) ou manuellement dans config.yaml :

memory:
  provider: openviking   # ou honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, memori

Source : Memory Providers, commit b4f8c491.

q-064: Comment choisir entre Honcho, Mem0, Hindsight et OpenViking ?

Le choix depend de vos besoins en matiere de stockage, de cout et de cas d'usage :

Honcho est le meilleur choix pour les systemes multi-agents avec contexte cross-session. Il modelise l'utilisateur via un raisonnement dialectique (l'IA raisonne sur ce qu'elle sait de vous) et injecte un resume de session dans le contexte. Necessite une cle API (cloud) ou une instance self-hosted. Configuration riche : cadence de contexte, profondeur du raisonnement, mode de rappel.

OpenViking est ideal pour le self-hosting avec une navigation structuree. Il organise les connaissances en arborescence avec des URIs viking:// et charge le contexte par niveaux (L0 ~100 tokens, L1 ~2k, L2 complet). Extraction automatique en 6 categories (profil, preferences, entites, evenements, cas, patterns). Gratuit, open-source (AGPL-3.0), par Volcengine/ByteDance.

Mem0 est le choix pour une gestion de memoire sans intervention : extraction automatique de faits par LLM cote serveur, recherche semantique avec re-ranking, deduplication automatique. Trois modes : Platform (cloud Mem0), self-hosted dashboard (Docker), et OSS (in-process avec votre propre LLM + vector store). Bon compromis si vous voulez que la memoire se gere toute seule.

Hindsight est le choix pour le rappel base sur un graphe de connaissances. Il offre hindsight_reflect, un outil de synthese cross-memoire unique qu'aucun autre provider ne propose. Deux modes : cloud (cle API) ou local (PostgreSQL embarque). Retention automatique des tours de conversation avec suivi par document de session.

Tableau de decision rapide :

Source : Memory Providers, commit b4f8c491.

q-065: Comment empecher la memoire de conserver une information sensible ?

Plusieurs mecanismes existent pour controler ce que la memoire conserve :

1. Desactiver la memoire integree :

# Dans ~/.hermes/config.yaml
memory:
  memory_enabled: false
  user_profile_enabled: false

2. Activer l'approbation des ecritures (write_approval) :

memory:
  write_approval: true   # false par defaut

Quand write_approval: true, chaque ecriture memoire -- qu'elle vienne d'un tour de conversation ou de la revue d'auto-amelioration en arriere-plan -- necessite votre approbation. Dans le CLI interactif, les ecritures vous sont presentees en ligne. Sur les plateformes de messaging, elles sont mises en attente (/memory pending) pour revue.

Commandes de revue :

/memory pending             # lister les ecritures en attente
/memory approve <id>        # approuver une ecriture (ou 'all')
/memory reject <id>         # rejeter une ecriture (ou 'all')
/memory approval on         # activer le portillon (ou 'off')

3. Scanning de securite integre : les entrees de memoire sont scannees pour les patterns d'injection et d'exfiltration avant d'etre acceptees. Le contenu correspondant a des patterns de menace (injection de prompt, exfiltration de credentials, backdoors SSH) ou contenant des caracteres Unicode invisibles est bloque.

4. Suppression manuelle : utilisez hermes journey delete pour supprimer des entrees de memoire existantes, ou demandez a l'agent d'utiliser l'outil memory avec l'action remove.

5. Desactiver le provider externe :

hermes memory off

Source : Persistent Memory, Security guide, commit b4f8c491.

q-066: Comment rechercher une information dans les sessions passees ?

Trois methodes sont disponibles :

1. L'outil session_search (utilise par l'agent) : L'agent peut rechercher dans l'historique de toutes les sessions CLI et messaging via FTS5 (recherche plein texte) sur la base SQLite ~/.hermes/state.db. Trois modes d'appel :

• Decouverte : recherche par mot-cle, retourne les sessions pertinentes avec le contexte autour de la correspondance
• Defilement : navigation avant/arriere dans une session specifique
• Parcours : liste des sessions recentes

Les resultats sont des messages reels de la base -- pas de resume LLM, pas de troncature.

2. La commande CLI hermes sessions list :

hermes sessions list    # Parcourir les sessions passees

3. Le Learning Journey (/journey) :

hermes journey          # Timeline visuelle de tout l'apprentissage
hermes journey list     # Lister les identifiants des noeuds (skills et memory chunks)

La difference cle entre session_search et la memoire persistante : la memoire (MEMORY.md) contient les faits critiques toujours presents dans le contexte (~1 300 tokens, cout fixe par session). session_search est pour les requetes ponctuelles du type "avons-nous discute de X la semaine derniere ?" -- recherche a la demande, sans cout de tokens jusqu'a l'appel.

Source : Persistent Memory, commit b4f8c491.

q-067: Comment supprimer ou corriger une memoire erronee ?

Pour la memoire integree (MEMORY.md / USER.md) :

L'agent peut corriger une entree avec l'outil memory :

• replace : remplace une entree par son contenu mis a jour, en utilisant une sous-chaine unique pour identifier l'entree a modifier
• remove : supprime une entree qui n'est plus pertinente, egalement par sous-chaine unique

Exemple de remplacement :

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

Si la sous-chaine correspond a plusieurs entrees, une erreur est retournee demandant une correspondance plus specifique.

Via le Learning Journey :

hermes journey list              # Lister les identifiants
hermes journey delete <node>     # Supprimer un noeud (les skills sont archives, les memory chunks supprimes)
hermes journey edit <node>       # Ouvrir le contenu dans $EDITOR

Pour les providers externes : Chaque provider expose ses propres outils de suppression :

• Honcho : honcho_conclude (create/delete conclusions)
• OpenViking : viking_forget (supprimer par URI viking://)
• Mem0 : mem0_delete (supprimer par ID), mem0_update (mettre a jour par ID)
• Hindsight : pas d'outil de suppression dedie (gere via l'API Hindsight)
• Holographic : fact_store avec action remove
• Supermemory : supermemory_forget (par ID ou meilleure correspondance)

Prevention : activez write_approval: true pour que chaque ecriture memoire necessite votre approbation avant d'etre persistee. C'est la reponse a "l'agent a sauvegarde une supposition erronee a mon sujet".

Source : Persistent Memory, Memory Providers, commit b4f8c491.

q-068: La memoire Hermes Agent est-elle partagee entre plusieurs profils ?

Non. Chaque profil possede sa propre memoire, sa propre base de sessions, et son propre repertoire de skills. Ils sont completement isoles.

L'isolation s'applique a tous les niveaux :

Si vous voulez creer un nouveau profil avec les memoires et sessions existantes, utilisez :

hermes profile create newname --clone-all    # Copie tout depuis le profil actif
hermes profile create newname --clone-from <profil>  # Copie depuis un profil specifique

Pour Honcho specifiquement, les profils partagent un workspace commun mais chaque profil a son propre AI peer avec une identite et des observations independantes. Le user peer est partage entre les profils dans le meme workspace.

Source : FAQ - Profiles, Memory Providers - Profile Isolation, commit b4f8c491.

q-069: Comment sauvegarder et restaurer la memoire Hermes Agent ?

Sauvegarde complete de l'installation :

hermes backup

Cree un zip de tout ~/.hermes/ -- config, cles API, memoires, skills, sessions, et profils. Le fichier est sauvegarde dans ~/hermes-backup-<timestamp>.zip.

Restauration sur une nouvelle machine :

# Sur la machine source
scp ~/hermes-backup-<timestamp>.zip newmachine:~/

# Sur la nouvelle machine (apres avoir installe Hermes)
hermes import ~/hermes-backup-<timestamp>.zip
hermes setup   # Verifier les cles API et la config provider

Export d'un profil unique :

# Sur la machine source
hermes profile export work ./work-backup.tar.gz

# Sur la machine cible
hermes profile import ./work-backup.tar.gz work

L'export de profil inclut toutes les memoires, sessions et skills, mais exclut les credentials (.env et auth.json) pour un partage securise.

Sauvegarde manuelle (rsync) :

rsync -av --exclude='hermes-agent' ~/.hermes/ newmachine:~/.hermes/

Note importante : hermes backup produit un snapshot coherent meme quand Hermes est actif. L'archive restauree exclut les fichiers d'execution locaux comme gateway.pid et cron.pid.

Source : FAQ - Exporting Hermes, FAQ - hermes backup vs hermes profile export, commit b4f8c491.

q-070: Comment verifier ce qui est injecte dans le contexte depuis la memoire ?

Pour la memoire integree (MEMORY.md / USER.md) :

Le contenu injecte est visible directement dans le prompt systeme au debut de chaque session. Le format est le suivant :

══════════════════════════════════════════════
MEMORY (your personal notes) [67% -- 1,474/2,200 chars]
══════════════════════════════════════════════
User's project is a Rust web service at ~/code/myapi using Axum + SQLx
§
This machine runs Ubuntu 22.04, has Docker and Podman installed
§
User prefers concise responses, dislikes verbose explanations

L'en-tete indique :

• Le store (MEMORY ou USER PROFILE)
• Le pourcentage d'utilisation et le nombre de caracteres
• Les entrees individuelles separees par §

Pour les providers externes :

Chaque provider injecte son propre contexte dans le prompt systeme. Le contenu et le format dependent du provider. Par exemple, Honcho injecte un resume de session, une representation utilisateur, et une carte de peer. OpenViking injecte par niveaux (L0, L1, L2).

Pour verifier l'etat de la memoire :

hermes memory status     # Verifier quel provider est actif
hermes memory off        # Desactiver le provider externe

Pour voir les fichiers de memoire directement :

cat ~/.hermes/memories/MEMORY.md
cat ~/.hermes/memories/USER.md

Pour auditer ce que l'agent a appris :

hermes journey           # Timeline visuelle de tout l'apprentissage
hermes journey list      # Liste des identifiants de noeuds

Notifications de mise a jour : vous pouvez configurer le niveau de notification quand la memoire est modifiee :

display:
  memory_notifications: on    # off | on (defaut) | verbose

Le mode verbose affiche un apercu compact de ce qui a change (par exemple 💾 Memory ➕ User prefers terse replies).

Source : Persistent Memory - How Memory Appears in the System Prompt, Memory Providers, commit b4f8c491.

Sources

• Documentation officielle Hermes Agent -- Persistent Memory
• Documentation officielle Hermes Agent -- Memory Providers
• Documentation officielle Hermes Agent -- Security guide
• Documentation officielle Hermes Agent -- FAQ
• Depot GitHub NousResearch/hermes-agent, commit b4f8c491d3452926deb7628edbdb6fe2a85ff576

Liens internes proposes

• Configurer Hermes Agent
• Modeles et providers
• FAQ
• Sources
• Methodologie