Mnemosyne pour l’Agent Hermes : Prise en main rapide de la mémoire locale
Mémoire locale Hermes avec écritures contrôlées.
Mnemosyne est un fournisseur de mémoire local-first pour Hermes Agent, stockant la mémoire de travail, les faits structurés, les données temporelles et l’historique épisodique dans un SQLite local — aucun service hébergé, aucun appel réseau obligatoire, et un contrôle d’écriture inhabituellement granulaire.
Sa propriété la plus utile n’est pas la qualité brute de rappel. C’est le niveau de contrôle qu’il expose sur le parcours d’écriture : l’enregistrement automatique des conversations peut être restreint par rôle ou désactivé tout court, la journalisation des résultats d’outils est désactivée par défaut, les opérations explicites de mémorisation et d’oubli restent disponibles en permanence, et les versions récentes ajoutent une suppression d’écho de soi sur option autour des limites de compression du contexte. Cette combinaison en fait un choix raisonnable lorsque vous souhaitez une mémoire persistante sans transformer automatiquement chaque conversation en connaissance permanente.
Cette discipline du parcours d’écriture est importante car la mémoire des agents présente un mode d’échec bien documenté : une inférence du modèle peut être capturée, récupérée plus tard comme s’il s’agissait d’une observation, et utilisée pour justifier une version encore plus forte d’elle-même. Boucles de mémoire auto-renforçantes dans les agents IA couvre ce mode d’échec en profondeur ; ce guide se concentre sur la configuration concrète de Mnemosyne qui le limite en pratique. Pour savoir où se situe Mnemosyne par rapport aux autres fournisseurs de mémoire Hermes, voir Comparaison des fournisseurs de mémoire d’agent.
Mnemosyne en une minute
Un fournisseur de mémoire typique effectue une version de la capture, de l’extraction, du stockage, de la récupération, puis de l’injection dans un futur prompt. Mnemosyne ajoute plusieurs couches distinctes autour de cette boucle de base : mémoire de travail, rappel sémantique et lexicale, faits structurés, informations temporelles, liens d’entités, mémoire épisodique, consolidation, faits canoniques et validation de mémoire. Le stockage est local SQLite avec FTS5 et une récupération vectorielle optionnelle, ce qui le rend considérablement plus inspectable qu’un produit de mémoire uniquement cloud et plus capable qu’un simple fichier MEMORY.md.
Très brièvement, par rapport au reste de l’écosystème de fournisseurs Hermes : Holographic est plus simple et délibérément orienté stockage de faits ; Hindsight met l’accent sur la récupération hybride, les graphes de connaissances et la réflexion ; Honcho met l’accent sur la modélisation des pairs et des utilisateurs avec raisonnement dialectique ; Mem0 met l’accent sur l’extraction automatique de faits par LLM ; et Mnemosyne combine stockage SQLite local, rappel hybride, consolidation, faits structurés et contrôles de rétention inhabituellement granulaires. Le détail complet, y compris les exigences d’infrastructure et les notes d’auto-hébergement pour chaque fournisseur, est dans Comparaison des fournisseurs de mémoire d’agent.
Versions actuelles
À la fin septembre 2026, la version stable publiée sur PyPI est mnemosyne-memory 3.15.1, avec la branche 4.0 disponible en version préliminaire. Pour une installation Hermes de production, commencez par la version stable, sauf si vous avez spécifiquement besoin d’un correctif ou d’une fonctionnalité 4.0 et êtes prêt à tester la migration de base de données et le changement de comportement. Vérifiez votre version installée avec :
hermes mnemosyne version
Installer Mnemosyne dans Hermes
Activez d’abord l’environnement virtuel propre à Hermes si vous avez utilisé l’installation locale standard :
source ~/.hermes/hermes-agent/venv/bin/activate
Pour la prise en charge de l’encodage local, installez le paquet principal avec le supplément embeddings ainsi que le wrapper de plugin Hermes :
python -m pip install \
"mnemosyne-memory[embeddings]" \
mnemosyne-hermes
Enregistrez ensuite le plugin :
mnemosyne-hermes install
Si vous remplacez un enregistrement de plugin existant :
mnemosyne-hermes install --force
Activez le fournisseur et redémarrez le passerelle :
hermes config set memory.provider mnemosyne
hermes gateway restart
Vérifiez avec :
hermes memory status
La sortie attendue ressemble à :
Provider: mnemosyne
Plugin: installed
Status: available
Installations Docker et serveurs persistants
Si Hermes fonctionne dans une installation Docker persistante ou basée sur une image, installez dans un environnement virtuel latéral sur le répertoire Hermes monté plutôt que dans l’environnement Python reconstruisible du conteneur, afin que le plugin survive aux reconstructions d’image :
export HERMES_HOME=/opt/data
VENV="$HERMES_HOME/.mnemosyne/venv"
python3 -m venv "$VENV"
"$VENV/bin/python" -m pip install --upgrade "mnemosyne-memory[embeddings]" mnemosyne-hermes
"$VENV/bin/mnemosyne-hermes" install --mode wrapper --python "$VENV/bin/python"
hermes config set memory.provider mnemosyne
L’environnement virtuel latéral doit utiliser la même version majeure/mineure de Python que la passerelle Hermes en cours d’exécution — ne pointez pas vers un python3 non lié de PATH. Redémarrez le conteneur ou le service réel ensuite et vérifiez avec "$VENV/bin/mnemosyne-hermes" status en même temps que hermes memory status.
Ne désactivez pas l’ensemble de l’outillage mémoire Hermes
Gardez deux concepts séparés : la mémoire intégrée propre à Hermes (MEMORY.md / USER.md, détaillée dans Système de mémoire de l’agent Hermes) et le fournisseur externe (Mnemosyne). N’exécutez pas négligemment hermes tools disable memory lors de la configuration d’un fournisseur externe — selon la version de Hermes, cette commande peut aussi masquer les outils des fournisseurs de mémoire externes. Utilisez plutôt la configuration du fournisseur, comme indiqué ci-dessous.
État de base et inspection
hermes memory status
hermes mnemosyne stats
hermes mnemosyne stats --global
hermes mnemosyne inspect "query"
Exportez une sauvegarde portable :
hermes mnemosyne export \
--output ~/mnemosyne-backup.json
La base de données sous-jacente se trouve normalement sous ~/.hermes/mnemosyne/data/mnemosyne.db. Comme c’est du SQLite, l’inspection et la sauvegarde sont straightforward avec des outils standard. Pour le reste des commandes de passerelle, de session et de diagnostic référencées dans ce guide, la fiche de triche de l’CLI de l’agent Hermes est une référence plus rapide que de fouiller la sortie --help.
La politique de rétention par défaut mérite attention
Le premier contrôle à comprendre est sync_roles. Les valeurs par défaut de Mnemosyne sont déjà plus conservatrices que les premières versions — la synchronisation automatique de Hermes porte par défaut sur les tours de l’utilisateur plutôt que sur les tours utilisateur et assistant — mais pour une rétention explicite stricte, désactiver complètement l’enregistrement automatique des tours vaut le coup. Modifiez ~/.hermes/config.yaml :
memory:
provider: mnemosyne
mnemosyne:
sync_roles: []
Une liste vide signifie que les tours de conversation ordinaires ne sont pas automatiquement enregistrés par sync_turn(). Les opérations explicites mnemosyne_remember continuent de fonctionner quel que soit le contexte — la conversation normale cesse de flow automatiquement dans la mémoire, tandis qu’un « mémorise ceci » explicite atteint toujours Mnemosyne.
Désactiver la journalisation automatique des résultats d’outils
Mnemosyne peut aussi journaliser les exécutions d’outils comme mémoire. Pour une configuration conservatrice, laissez cela désactivé dans ~/.hermes/.env :
MNEMOSYNE_LOG_TOOLS=0
C’est déjà la valeur par défaut, mais définir explicitement documente la politique plutôt que de s’appuyer sur une hypothèse sur les valeurs par défaut. Redémarrez Hermes ensuite :
hermes gateway restart
Avec sync_roles: [] et MNEMOSYNE_LOG_TOOLS=0 ensemble, les deux principaux parcours d’écriture automatiques — l’enregistrement automatique de la conversation et l’enregistrement automatique des résultats d’outils — sont désactivés.
Conserver le rappel automatique
Désactiver les écritures automatiques n’impose pas de désactiver le rappel. Une politique utile conserve la rétention automatique désactivée tandis que le rappel automatique, la mémorisation explicite et l’oubli explicite restent activés — la mémoire devrait être facile à lire et difficile à écrire, ce qui est proche de l’opposé d’une valeur par défaut « capturer tout et trier plus tard ».
Ajouter une instruction d’agent durable
La configuration du fournisseur bloque la capture au niveau du fournisseur, mais le modèle peut toujours décider d’appeler un outil d’écriture explicite de sa propre initiative. Ajoutez une politique explicite dans SOUL.md :
## Politique de mémoire à long terme
Mnemosyne est le fournisseur de mémoire à long terme.
N’écrivez rien dans Mnemosyne sauf si l’utilisateur vous demande explicitement
de mémoriser, enregistrer, retenir ou stocker cette information.
Si une information semble utile pour les sessions futures mais que l’utilisateur
n’a pas explicitement demandé qu’elle soit mémorisée, demandez la permission avant
d’appeler mnemosyne_remember ou un autre outil d’écriture Mnemosyne.
Ne créez pas de mémoires durables à partir de votre propre raisonnement, de vos
hypothèses, de vos résumés, de vos interprétations, de vos conclusions ou de vos
préférences inférées.
Ne créez pas de mémoires durables à partir de la sortie des outils sauf si
l’utilisateur demande explicitement que ce résultat soit mémorisé.
Lors du stockage d’une mémoire approuvée, conservez ce que l’utilisateur a
réellement énoncé. Ne l’enrichissez pas de contexte ou de conclusions inférées.
Lire et rappeler les mémoires de Mnemosyne est autorisé sans demander la permission.
Redémarrez la passerelle et démarrez une nouvelle session ensuite :
hermes gateway restart
/new
Ceci est une politique appliquée par le modèle, et non une limite de permission stricte — elle complète la configuration au niveau du fournisseur ci-dessus plutôt que de la remplacer.
Et memory.write_approval ?
Hermes prend en charge memory.write_approval: true pour les écritures dans MEMORY.md / USER.md intégrées, et Mnemosyne implémente son propre stockage en attente spécifique au fournisseur pour les écritures explicites dans les versions récentes. C’est prometteur, mais il y a une réserve architecturale à prendre au sérieux : Hermes n’expose pas encore un contrat d’approbation uniforme et neutre vis-à-vis du fournisseur pour tous les fournisseurs de mémoire externes, et l’implémentation en attente/application de Mnemosyne est spécifique au fournisseur plutôt qu’une partie d’une norme partagée. N’assumez pas que l’approbation fonctionne correctement juste parce que la clé de configuration est présente — testez-la contre vos versions exactes de Hermes et Mnemosyne. Jusqu’à ce que l’approbation indépendante du fournisseur mûrisse, combiner sync_roles: [], MNEMOSYNE_LOG_TOOLS=0 et la politique SOUL.md d’écriture explicite ci-dessus vous donne une base fiable, avec le parcours d’approbation testé séparément si vous comptez vous y fier.
Activer la suppression d’écho de soi
Mnemosyne actuel propose aussi une suppression d’écho de soi optionnelle :
MNEMOSYNE_SELF_ECHO_ENABLED=1
Placez ceci dans ~/.hermes/.env, puis redémarrez :
hermes gateway restart
La suppression d’écho de soi cible spécifiquement les limites de compression du contexte — son but est de réduire les cas où une mémoire que le fournisseur vient de créer est immédiatement renvoyée à l’agent comme s’il s’agissait d’un contexte indépendant. Elle est délibérément en meilleur effort et ne remplace pas le filtrage d’écriture : les contrôles d’écriture empêchent les mémoires douteuses d’entrer en premier lieu, tandis que les contrôles d’écho de soi empêchent la sortie récente du fournisseur de rebondir directement. Les deux comptent, et l’un ne remplace pas l’autre.
Une configuration Mnemosyne conservatrice
Mettant les pièces ensemble, une configuration de départ pour un agent d’ingénierie personnel auto-hébergé ressemble à ceci. Dans ~/.hermes/config.yaml :
memory:
provider: mnemosyne
mnemosyne:
sync_roles: []
Dans ~/.hermes/.env :
MNEMOSYNE_LOG_TOOLS=0
MNEMOSYNE_SELF_ECHO_ENABLED=1
Et dans SOUL.md, au minimum :
Ne stockez la mémoire à long terme que si l’utilisateur le demande explicitement.
Ne promouvez pas de conclusions générées par le modèle ou de sortie d’outils
dans la mémoire durable sans permission explicite.
Tester que la conversation ordinaire n’est pas conservée
Vérifiez d’abord le nombre de base :
hermes mnemosyne stats
Démarrez une nouvelle session Hermes et faites une déclaration factuelle simple sans demander à l’agent de la mémoriser, par exemple :
PurpleOtter uses port 48123.
Ensuite, cherchez-la :
hermes mnemosyne inspect "PurpleOtter"
Attendu : Results for 'PurpleOtter': 0. Revérifiez aussi hermes mnemosyne stats — le compteur de mémoire de travail ne devrait pas avoir augmenté à cause de ce tour ordinaire.
Tester la mémoire explicite
Maintenant, faites le même type de déclaration, mais demandez explicitement la rétention :
Remember that BlueKoala uses port 17321.
Inspectez-le, puis démarrez une nouvelle session et demandez-le :
hermes mnemosyne inspect "BlueKoala"
/new
What port does BlueKoala use?
Hermes devrait récupérer la valeur correctement — cette paire de tests isole la politique du parcours d’écriture (rien n’entre sans demander) du mécanisme de récupération (ce qui entre ressort de façon fiable).
Tester la journalisation des outils
Avec MNEMOSYNE_LOG_TOOLS=0 défini, demandez à Hermes d’exécuter une commande distinctive et unique :
Use the terminal tool to run:
echo tool-canary-834729
Puis cherchez la chaîne canary :
hermes mnemosyne inspect "tool-canary-834729"
Attendu : 0 results. C’est un test bien plus fort que de simplement faire confiance au fait que la variable d’environnement est respectée partout.
Inspecter la base de données
Comme le stockage est SQLite, le schéma interne est directement inspectable :
sqlite3 ~/.hermes/mnemosyne/data/mnemosyne.db '.tables'
Selon la version, vous pouvez voir des tables telles que working_memory, episodic_memory, facts, consolidated_facts, gists, graph_edges, memoria_facts et memory_embeddings. C’est important lors de la suppression d’un test — un système de mémoire peut supprimer avec succès une ligne de mémoire de travail tout en laissant un fait dérivé, un résumé ou un objet de graphe derrière. Mnemosyne a eu de vrais bogues dans ce domaine impliquant des enregistrements dérivés orphelins, et les versions récentes ont resserré à la fois la suppression et les diagnostics en conséquence. Préférez les parcours de suppression et de doctor/réparation pris en charge par le fournisseur plutôt que de supprimer manuellement des lignes SQLite sauf si vous comprenez entièrement le schéma actuel.
Supprimer la mémoire de travail de portée session
Une subtilité : les mémoires de travail de Mnemosyne peuvent être de portée session, donc une ligne avec scope = session peut ne pas être visible par une suppression autonome opérant dans la session default. Lors du débogage, inspectez la portée directement :
SELECT id, session_id, scope, content
FROM working_memory;
Le fournisseur ou l’API a besoin de la bonne portée de session pour modifier les enregistrements locaux de session — une autre raison de préférer les outils d’administration pris en charge aux modifications SQL brutes.
Consolidation : ne pas se presser vers sleep()
Mnemosyne peut consolider la mémoire de travail en représentations plus longues, ce qui est utile mais est une opération mutative. Avant d’activer une consolidation automatique agressive, inspectez ce qui est réellement capturé, vérifiez que les tours ordinaires n’entrent pas dans la mémoire inattendument, vérifiez la suppression de bout en bout, et sauvegardez la base de données. Puis expérimentez avec :
hermes mnemosyne sleep
Les récents changements de Mnemosyne ont rendu la gestion des conflits plus conservatrice — la similarité sémantique seule ne prouve plus qu’une mémoire devrait invalider une autre, ce qui est exactement la direction dans laquelle un système de mémoire d’agent durable devrait se diriger, comme couvert dans Boucles de mémoire auto-renforçantes dans les agents IA.
Sauvegarder avant les mises à niveau
Créez un export portable avant tout changement significatif :
hermes mnemosyne export \
--output ~/mnemosyne-backup.json
Pour les installations importantes, copiez aussi la base de données locale ou le répertoire de données avant les mises à niveau majeures. Mnemosyne 4.x est actuellement une ligne de version préliminaire, donc une mise à niveau de version majeure mérite plus de précaution qu’une mise à jour de correctif de routine.
Configuration finale recommandée
Pour une installation Hermes longue durée où l’exactitude de la mémoire compte plus que de tout mémoriser, la configuration durable est : stockage local Mnemosyne activé, rappel automatique activé, enregistrement automatique de la conversation désactivé, enregistrement automatique des messages assistant désactivé, journalisation des résultats d’outils désactivée, mémorisation et oubli explicites activés, suppression d’écho de soi activée, recherche de session activée, et revue humaine pour les écritures sensibles souhaitable une fois le parcours d’approbation testé. Cela fait fonctionner Mnemosyne principalement comme un stock de mémoire à long terme curaté plutôt que comme une archive de transcription — l’objectif n’est pas de faire en sorte que Hermes se souvienne de tout ce qu’il a jamais dit, mais de faire en sorte qu’il se souvienne des choses qui seront encore vraies lorsque la session suivante commencera. Si vous exécutez plusieurs profils avec des fournisseurs ou des politiques de rétention différents, Installation de production de l’agent Hermes couvre le câblage au niveau du profil pour les garder cohérents. Si vous préférez exécuter la mémoire comme un service Docker séparé avec un graphe de connaissances et une opération de réflexion, Hindsight pour l’agent Hermes est le guide du fournisseur externe basé sur Docker.
