Mnemosyne pour l’agent Hermes : démarrage 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. Il stocke la mémoire de travail, les faits structurés, les données temporelles et l’historique épisodique dans une base SQLite locale — sans service hébergé, sans appel réseau obligatoire, et avec un contrôle d’écriture d’une granularité inhabituelle.
Sa propriété la plus utile n’est pas la qualité brute de la récupération. C’est le niveau de contrôle qu’il expose sur le chemin d’écriture : l’enregistrement automatique des conversations peut être restreint par rôle ou désactivé purement et simplement, 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 toutes circonstances, et les dernières versions ajoutent une suppression optionnelle de l’auto-écho (self-echo) 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 chemin d’écriture est importante car la mémoire des agents présente un mode de défaillance bien documenté : les propres inférences d’un modèle peuvent être capturées, récupérées plus tard comme si c’étaient des observations, et utilisées pour justifier une version encore plus forte d’elles-mêmes. Boucles de mémoire auto-renforçantes dans les agents IA couvre ce mode de défaillance en profondeur ; ce guide se concentre sur la configuration concrète de Mnemosyne qui le limite en pratique. Pour savoir où Mnemosyne se situe par rapport aux autres backends de mémoire Hermes, consultez Comparaison des fournisseurs de mémoire pour agents.
Mnemosyne en une minute
Un fournisseur de mémoire typique effectue une version de la séquence suivante : capture, extraction, stockage, récupération, puis injection dans un prompt futur. Mnemosyne ajoute plusieurs couches distinctes autour de cette boucle de base : mémoire de travail, rappel sémantique et lexical, faits structurés, information temporelle, liens d’entités, mémoire épisodique, consolidation, faits canoniques et validation de la mémoire. Le stockage est basé sur SQLite local 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 basée sur des LLM ; et Mnemosyne combine le stockage SQLite local, le rappel hybride, la consolidation, les faits structurés et des contrôles de rétention d’une granularité inhabituelle. Le détail complet, y compris les exigences d’infrastructure et les notes sur l’auto-hébergement pour chaque fournisseur, se trouve dans Comparaison des fournisseurs de mémoire pour agents.
Versions actuelles
En septembre 2026, la version stable PyPI est mnemosyne-memory 3.15.1, avec la branche 4.0 disponible en pré-version. Pour une installation Hermes de production, commencez par la version stable sauf si vous avez spécifiquement besoin d’une correction ou d’une fonctionnalité 4.0 et êtes prêt à tester la migration de la base de données et le changement de comportement. Vérifiez votre version installée avec :
hermes mnemosyne version
Installation de Mnemosyne dans Hermes
Activez d’abord l’environnement virtuel de 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 package principal avec le supplément embeddings plus 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 la 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 s’exécute dans un déploiement Docker persistant ou basé sur une image, installez-le dans un environnement virtuel latéral sur le dossier Hermes monté plutôt que dans l’environnement Python reconstruisable 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 le pointez pas vers un python3 non relié de PATH. Redémarrez le conteneur ou le service réel ensuite et vérifiez avec "$VENV/bin/mnemosyne-hermes" status ainsi que hermes memory status.
Ne désactivez pas l’ensemble des outils de mémoire Hermes
Gardez deux concepts séparés : la mémoire intégrée de Hermes elle-même (MEMORY.md / USER.md, couverte en détail dans Système de mémoire de l’agent Hermes) et le fournisseur externe (Mnemosyne). Ne lancez 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.
Statut et inspection de base
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. Étant donné qu’il s’agit de SQLite, l’inspection et la sauvegarde sont simples avec des outils standard. Pour le reste des commandes de passerelle, de session et de diagnostic référencées tout au long de ce guide, la fiche mémo de la CLI de l’agent Hermes est une référence plus rapide que de fouiller dans 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 actuelles sont déjà plus conservatrices que les premières versions — la synchronisation automatique de Hermes a par défaut les tours de l’utilisateur plutôt que ceux de l’utilisateur et de l’assistant — mais pour une rétention stricte uniquement explicite, la désactivation complète de l’enregistrement automatique des tours vaut la peine d’un pas supplémentaire. Éditez ~/.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 quoi qu’il arrive — la conversation normale cesse de couler automatiquement dans la mémoire, tandis qu’une demande explicite de « mémorise ceci » 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 le définir explicitement documente la politique plutôt que de compter sur une supposition au sujet des valeurs par défaut. Redémarrez Hermes ensuite :
hermes gateway restart
Avec sync_roles: [] et MNEMOSYNE_LOG_TOOLS=0 ensemble, les deux principaux chemins d’écriture automatiques — l’enregistrement automatique des conversations et l’enregistrement automatique des résultats d’outils — sont désactivés.
Conserver le rappel automatique
Désactiver les écritures automatiques n’exige pas de désactiver le rappel. Une politique utile maintient la rétention automatique désactivée tout en gardant le rappel automatique, la mémorisation explicite et l’oubli explicite 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 à SOUL.md :
## Politique de mémoire à long terme
Mnemosyne est le fournisseur de mémoire à long terme.
N'écrivez rien dans Mnemosyne à moins que l'utilisateur ne vous demande explicitement de
mémoriser, sauvegarder, conserver ou stocker cette information.
Si une information semble utile pour des 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, hypothèses,
résumés, interprétations, conclusions ou préférences inférées.
Ne créez pas de mémoires durables à partir de la sortie d'outils à moins que l'utilisateur
ne demande explicitement que ce résultat soit mémorisé.
Lors de l'enregistrement d'une mémoire approuvée, conservez ce que l'utilisateur a réellement
déclaré. Ne l'embellissez pas avec du contexte ou des conclusions inférés.
La lecture et la récupération des mémoires Mnemosyne sont autorisées sans demander la
permission.
Redémarrez la passerelle et lancez une nouvelle session ensuite :
hermes gateway restart
/new
C’est une politique appliquée par le modèle, pas une limite de permission dure — 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 des MEMORY.md / USER.md intégrés, et Mnemosyne implémente son propre étagement spécifique au fournisseur pour les écritures explicites dans les dernières versions. C’est prometteur, mais il y a une réserve architecturale qu’il convient de prendre au sérieux : Hermes n’expose pas encore un contrat d’approbation uniforme, neutre par rapport au fournisseur, pour tous les fournisseurs de mémoire externes, et l’implémentation d’attente/application de Mnemosyne est spécifique au fournisseur plutôt qu’une partie d’une norme partagée. Ne supposez pas que l’approbation fonctionne correctement simplement parce que la clé de configuration est présente — testez-la contre vos versions exactes de Hermes et de 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 offre une base fiable, avec le chemin d’approbation testé séparément si vous comptez en dépendre.
Activer la suppression de l’auto-écho
Les versions actuelles de Mnemosyne offrent également une suppression optionnelle de l’auto-écho :
MNEMOSYNE_SELF_ECHO_ENABLED=1
Placez ceci dans ~/.hermes/.env, puis redémarrez :
hermes gateway restart
La suppression de l’auto-écho cible spécifiquement les limites de compression du contexte — son but est de réduire les cas où la mémoire que le fournisseur vient de créer est immédiatement renvoyée à l’agent comme si c’était un contexte indépendant. Elle est intentionnellement au mieux d’effort et ne remplace pas le filtrage d’écriture : les contrôles d’écriture empêchent les mémoires douteuses d’entrer dès le départ, tandis que les contrôles d’auto-écho empêchent la sortie récente du fournisseur de rebondir directement. Les deux comptent, et l’un ne se substitue pas à l’autre.
Une configuration Mnemosyne conservatrice
En 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 :
N'enregistrez de mémoire à long terme que lorsque l'utilisateur le demande explicitement.
Ne promouvez pas les conclusions générées par le modèle ou la sortie d'outils en mémoire
durable sans permission explicite.
Tester que la conversation ordinaire n’est pas retenue
Vérifiez d’abord le nombre de base :
hermes mnemosyne stats
Lancez une nouvelle session Hermes et dites une déclaration factuelle ordinaire sans demander à l’agent de la mémoriser, par exemple :
PurpleOtter uses port 48123.
Ensuite, recherchez-la :
hermes mnemosyne inspect "PurpleOtter"
Attendu : Results for 'PurpleOtter': 0. Vérifiez aussi hermes mnemosyne stats à nouveau — le compteur de la mémoire de travail n’aurait pas dû augmenter à cause de ce tour ordinaire.
Tester la mémoire explicite
Dites maintenant le même type de déclaration, mais demandez explicitement la rétention :
Remember that BlueKoala uses port 17321.
Inspectez-la, puis lancez une nouvelle session et demandez-la :
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 chemin d’écriture (rien n’entre sans demande) du mécanisme de récupération (ce qui entre ressort de manière 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 recherchez la chaîne canari :
hermes mnemosyne inspect "tool-canary-834729"
Attendu : 0 results. C’est un test beaucoup plus fort que de se fier simplement au fait que la variable d’environnement est honorée partout.
Inspection de la base de données
Étant donné que 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. Cela compte lors des tests de suppression — 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 graphique derrière. Mnemosyne a eu de vrais bugs dans ce domaine impliquant des enregistrements dérivés orphelins, et les dernières versions ont resserré à la fois la suppression et les diagnostics en conséquence. Préférez les chemins de suppression et de réparation pris en charge par le fournisseur plutôt que de supprimer manuellement des lignes SQLite à moins que vous ne compreniez parfaitement le schéma actuel.
Suppression de 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 portée de session correcte pour modifier les enregistrements locaux à la session — une autre raison de préférer les outils d’administration pris en charge aux modifications SQL brutes.
Consolidation : ne vous précipitez pas sur 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 inattendument dans la mémoire, vérifiez la suppression de bout en bout, et sauvegardez la base de données. Puis expérimentez avec :
hermes mnemosyne sleep
Les changements récents de Mnemosyne ont rendu le traitement des conflits plus conservateur — la similarité sémantique seule ne prouve plus qu’une mémoire doit 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.
Sauvegarde avant les mises à niveau
Créez une exportation 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 pré-version, donc une mise à niveau de version majeure mérite plus de prudence qu’une mise à jour de routine.
Configuration finale recommandée
Pour une installation Hermes de longue durée où la précision de la mémoire compte plus que le fait de tout retenir, la configuration durable est : stockage local Mnemosyne activé, rappel automatique activé, enregistrement automatique des conversations désactivé, enregistrement automatique des messages de l’assistant désactivé, journalisation des résultats d’outils désactivée, mémorisation et oubli explicites activés, suppression de l’auto-écho activée, recherche de session activée, et revue humaine souhaitable pour les écritures sensibles une fois le chemin d’approbation testé. Cela permet à Mnemosyne de fonctionner principalement comme un magasin de mémoire à long terme curated plutôt qu’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 prochaine session commencera. Si vous faites fonctionner plusieurs profils avec des fournisseurs ou des politiques de rétention différents, Configuration de production de l’agent Hermes couvre le câblage au niveau du profil pour les garder cohérents.
