Comparatif des fournisseurs de mémoire pour agents : politique de capture et auto-hébergement

Mise à jour en septembre 2026 : ajout de Mnemosyne et Memori, extension de la configuration Honcho et Hindsight, et ajout d’une comparaison des politiques de capture à côté du tableau d’infrastructure original.

Les assistants modernes oublient toujours tout lorsque vous fermez l’onglet, à moins que quelque chose ne soit persisté au-delà de la fenêtre de contexte. Les fournisseurs de mémoire pour agents sont des services ou des bibliothèques qui conservent des faits et des résumés d’une session à l’autre — souvent intégrés en tant que plugins afin que le framework reste léger pendant que la mémoire évolue.

Ce guide compare les arrière-plans de mémoire livrés en tant que plugins de mémoire externe pour Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne et Memori — et explique comment ils s’insèrent dans des piles systèmes d’IA plus larges. Les mêmes fournisseurs apparaissent dans OpenClaw et d’autres outils d’agents via des intégrations communautaires ou officielles. Le centre de mémoire des systèmes d’IA répertorie cet article aux côtés de Cognee et des guides associés.

Pour la mémoire de noyau bornée spécifique à Hermes (MEMORY.md et USER.md), le comportement de gel et les déclencheurs, voir Système de mémoire Hermes Agent. Pour le contexte sur la façon dont les fournisseurs de mémoire natifs de Hermes contribuent à son avantage d’adoption croissant par rapport à OpenClaw — y compris les étoiles GitHub, les classements de jetons OpenRouter et les comparaisons de taille de l’écosystème — voir OpenClaw vs Hermes Agent : Étoiles, Téléchargements & Utilisation 2026.

Il existe un autre axe qui compte autant que la qualité de récupération : la gouvernance de la mémoire. Les fournisseurs diffèrent considérablement sur ce qu’ils capturent automatiquement, si la sortie générée par l’assistant peut devenir une mémoire durable, si les réflexions sont stockées en tant que faits, comment les contradictions sont résolues, et si un humain peut examiner une écriture avant qu’elle ne devienne un contexte futur. Pour les agents en cours d’exécution longue, ces différences peuvent être plus importantes que quelques points de plus sur un benchmark de rappel — voir Boucles de mémoire auto-renforçantes dans les agents d’IA pour comprendre pourquoi la capture automatique peut transformer une conclusion générée en prémisse future, et Mnemosyne pour Hermes Agent : Démarrage rapide mémoire locale pour un exemple de configuration conservatrice.

Hermes Agent répertorie dix plugins de fournisseurs de mémoire externe pour une connaissance persistante et inter-sessions — les huit originaux plus Mnemosyne et Memori. Un seul fournisseur externe peut être actif à la fois. Les fichiers intégrés MEMORY.md et USER.md restent chargés à ses côtés — de manière additive, et non en remplacement.

Dépendances externes. Tous les fournisseurs externes, à l’exception de Holographic, nécessitent au moins un appel de service externe — un LLM pour l’extraction de mémoire, un modèle d’incorporation pour la recherche sémantique, ou une base de données comme PostgreSQL pour le stockage. Ces dépendances ont des implications directes sur la confidentialité, le coût, et si votre pile de mémoire peut être entièrement auto-hébergée. Hindsight, ByteRover et Mnemosyne regroupent ou éliminent la plupart des dépendances ; Honcho, Mem0 et Supermemory nécessitent le plus de composants mobiles. Là où un fournisseur prend en charge Ollama ou tout point de terminaison compatible OpenAI, vous pouvez router les appels LLM et d’incorporation vers un modèle local et garder les données hors des serveurs tiers entièrement.

Activation avec Hermes Agent

Les étapes en ligne de commande ci-dessous reflètent les tableaux de la Fiche de triche CLI Hermes Agent.

hermes memory setup   # Sélecteur interactif + configuration
hermes memory status  # Vérifier ce qui est actif
hermes memory off     # Désactiver le fournisseur externe

Ou manuellement dans ~/.hermes/config.yaml :

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

Comparaison des fournisseurs

Politique de capture et gouvernance

Le stockage et les dépendances répondent à “puis-je faire tourner cela ?” Le tableau ci-dessous répond à une autre question qui compte autant pour les agents en cours d’exécution longue : ce qui est écrit sans être demandé, et peut un humain ou une politique intervenir avant que cela ne devienne durable ? Voir Boucles de mémoire auto-renforçantes dans les agents d’IA pour comprendre pourquoi cet axe est important.

Ce sont des catégories de risque architecturaux, et non des scores de qualité — un fournisseur sophistiqué soigneusement configuré peut être plus sûr en pratique qu’un simple fournisseur mal configuré.

Détail détaillé

Honcho

Idéal pour : systèmes multi-agents, contexte inter-sessions, alignement utilisateur-agent.

Honcho fonctionne aux côtés de la mémoire existante — USER.md reste tel quel, et Honcho ajoute une couche supplémentaire de contexte. Il modélise les conversations comme des pairs échangeant des messages — un pair utilisateur plus un pair IA par profil Hermes, tous partageant un espace de travail.

Dépendances externes : Honcho nécessite un LLM pour la résumation de session, la dérivation de la représentation de l’utilisateur et le raisonnement dialectique ; un modèle d’incorporation pour la recherche sémantique à travers les observations ; PostgreSQL avec l’extension pgvector pour le stockage de vecteurs ; et Redis pour la mise en cache. Le nuage géré à api.honcho.dev gère tout cela pour vous. Pour les déploiements auto-hébergés (Docker, K3s ou Fly.io), vous fournissez vos propres identifiants. Le slot LLM accepte tout point de terminaison compatible OpenAI, y compris Ollama et vLLM, donc l’inférence peut rester sur site. Le slot d’incorporation utilise par défaut openai/text-embedding-3-small mais prend en charge des fournisseurs configurables via LLM_EMBEDDING_API_KEY et LLM_EMBEDDING_BASE_URL — tout serveur d’incorporation compatible OpenAI fonctionne, y compris des options locales comme vLLM avec un modèle BGE.

Outils : honcho_profile (lire/mettre à jour la carte du pair), honcho_search (recherche sémantique), honcho_context (contexte de session — résumé, représentation, carte, messages), honcho_reasoning (synthétisé par LLM), honcho_conclude (créer/supprimer des conclusions).

Réglages de configuration clés :

• contextCadence (défaut 1) : Minimum de tours entre les rafraîchissements de la couche de base
• dialecticCadence (défaut 2) : Minimum de tours entre les appels LLM de peer.chat() (1-5 recommandé)
• dialecticDepth (défaut 1) : Passes de .chat() par invocation (limité à 1-3)
• recallMode (défaut ‘hybrid’) : hybrid (auto + outils), context (injection uniquement), tools (outils uniquement)
• writeFrequency (défaut ‘async’) : Temporalisation de l’écriture : async, turn, session, ou entier N
• observationMode (défaut ‘directional’) : directional (tous activés) ou unified (pool partagé)

Modes d’observation et auto-modélisation. directional, le défaut pour les configurations neuves, permet aux pairs utilisateur et IA d’observer eux-mêmes et les uns les autres — raisonnement dialectique plus riche, mais cela signifie aussi que les messages rédigés par l’IA contribuent au modèle de Honcho de l’IA elle-même. unified est l’option plus conservatrice : l’IA modélise l’utilisateur à partir des messages de l’utilisateur sans construire la boucle d’auto-observation correspondante à partir de sa propre sortie. Quiconque s’inquiète spécifiquement de conclusions générées qui réagissent sur le raisonnement futur — voir Boucles de mémoire auto-renforçantes dans les agents d’IA — devrait traiter unified comme le défaut plus sûr.

Architecture : Injection de contexte à deux couches — couche de base (résumé de session + représentation + carte du pair) + supplément dialectique (raisonnement LLM). Sélectionne automatiquement les prompts de démarrage à froid vs chauds.

Cartographie multi-pairs : L’espace de travail est un environnement partagé entre les profils. Le pair utilisateur (peerName) est une identité humaine globale. Le pair IA (aiPeer) est un par profil Hermes (hermes par défaut, hermes.<profile> pour les autres).

Configuration :

hermes memory setup  # sélectionner "honcho"
# ou legacy : hermes honcho setup

Configuration : $HERMES_HOME/honcho.json (spécifique au profil) ou ~/.honcho/config.json (global).

Gestion des profils :

hermes profile create coder --clone  # Crée hermes.coder avec espace de travail partagé
hermes honcho sync                   # Remplit les pairs IA pour les profils existants

OpenViking

Idéal pour : gestion de connaissances auto-hébergée avec navigation structurée.

OpenViking fournit une hiérarchie de système de fichiers avec chargement par niveaux. C’est gratuit, auto-hébergé, et vous donne le contrôle total sur votre stockage de mémoire.

Dépendances externes : OpenViking nécessite un VLM (modèle de vision-langage) pour le traitement sémantique et l’extraction de mémoire, et un modèle d’incorporation pour la recherche vectorielle — les deux sont obligatoires. Les fournisseurs de VLM pris en charge incluent OpenAI, Anthropic, DeepSeek, Gemini, Moonshot et vLLM (pour le déploiement local). Pour les incorporations, les fournisseurs pris en charge incluent OpenAI, Volcengine (Doubao), Jina, Voyage et — via Ollama — tout modèle d’incorporation servi localement. L’assistant interactif openviking-server init peut détecter la RAM disponible et recommander des modèles Ollama appropriés (par ex. Qwen3-Embedding 8B pour les incorporations, Gemma 4 27B pour VLM) et configurer tout automatiquement pour une configuration entièrement locale, sans clé API. Aucune base de données externe n’est requise ; OpenViking stocke la mémoire dans le système de fichiers.

Outils : viking_search, viking_read (par niveaux), viking_browse, viking_remember, viking_add_resource.

Mémoire utilisateur vs mémoire agent. Le modèle d’identité d’OpenViking peut séparer l’espace de noms de mémoire de l’utilisateur d’un pair assistant facultatif. Cette séparation est importante pour l’hygiène de la mémoire : les faits sur l’utilisateur et l’expérience générée par l’agent n’ont pas besoin de partager la même politique de rétention, ce qui est une propriété utile si vous voulez isoler l’état rédigé par l’assistant de l’état rédigé par l’utilisateur.

Configuration :

pip install openviking
openviking-server init   # assistant interactif (recommande des modèles Ollama pour configuration locale)
openviking-server
hermes memory setup  # sélectionner "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Idéal pour : gestion de mémoire sans intervention avec extraction automatique.

Mem0 gère l’extraction de mémoire côté serveur via un appel LLM sur chaque opération add — il lit la conversation, extrait des faits discrets, déduplique et les stocke. L’API de nuage géré gère toute l’infrastructure. La bibliothèque open-source et le serveur auto-hébergé vous donnent le contrôle total.

Dépendances externes : Mem0 nécessite un LLM pour l’extraction de mémoire (défaut : OpenAI gpt-4.1-nano ; 20 fournisseurs pris en charge, y compris Ollama, vLLM et LM Studio pour les modèles locaux) et un modèle d’incorporation pour la récupération (défaut : OpenAI text-embedding-3-small ; 10 fournisseurs pris en charge, y compris Ollama et HuggingFace pour les modèles locaux). Le stockage utilise Qdrant à /tmp/qdrant en mode bibliothèque, ou PostgreSQL avec pgvector en mode serveur auto-hébergé — les deux peuvent tourner localement. Une pile Mem0 entièrement locale, sans nuage est réalisable : Ollama pour le LLM, Ollama pour les incorporations, et une instance Qdrant locale, tous configurés via Memory.from_config.

Mem0 est fondamentalement un système d’extraction : un LLM transforme le matériel conversationnel en mémoires discrètes et effectue la logique de déduplication et de mise à jour. C’est pratique, mais cela signifie que la provenance de l’extraction est importante — une conclusion d’assistant générée peut devenir structurellement indistinguable d’un fait énoncé par l’utilisateur à moins que le chemin de capture ne le filtre avant que l’extraction ne s’exécute.

Outils : mem0_profile, mem0_search, mem0_conclude.

Configuration :

pip install mem0ai
hermes memory setup  # sélectionner "mem0"
echo "MEM0_API_KEY=votre-cle" >> ~/.hermes/.env

Configuration : $HERMES_HOME/mem0.json (user_id : hermes-user, agent_id : hermes).

Hindsight

Idéal pour : rappel basé sur un graphe de connaissances avec des relations d’entités.

Hindsight construit un graphe de connaissances de votre mémoire, extrayant les entités et les relations. Son outil reflect unique effectue une synthèse inter-mémoires — combinant plusieurs mémoires en nouvelles intuitions. Le rappel exécute quatre stratégies de récupération en parallèle (sémantique, mot-clé/BM25, traversée de graphe, temporelle), puis fusionne et réordonne les résultats en utilisant la fusion de rangs réciproques.

Dépendances externes : Hindsight nécessite un LLM pour l’extraction de faits et d’entités sur les appels retain, et pour la synthèse sur les appels reflect (défaut : OpenAI ; les fournisseurs pris en charge incluent Anthropic, Gemini, Groq, Ollama, LM Studio et tout point de terminaison compatible OpenAI). Le modèle d’incorporation et le modèle de réordonnancement par codage croisé sont regroupés à l’intérieur de Hindsight lui-même — ils tournent localement au sein du package hindsight-all et ne nécessitent aucune API externe. PostgreSQL est également regroupé avec l’installation Python intégrée via un répertoire de données pg0 géré ; vous pouvez alternativement pointer Hindsight vers une instance PostgreSQL externe. Pour une configuration entièrement locale, sans nuage, configurez HINDSIGHT_API_LLM_PROVIDER=ollama et pointez vers un modèle Ollama local — retain et recall fonctionnent pleinement ; reflect nécessite un modèle capable d’appels d’outils (par ex. qwen3:8b).

Outils : hindsight_retain, hindsight_recall, hindsight_reflect (synthèse inter-mémoires unique).

Configuration :

hermes memory setup  # sélectionner "hindsight"
echo "HINDSIGHT_API_KEY=votre-cle" >> ~/.hermes/.env

Installe automatiquement hindsight-client (nuage) ou hindsight-all (local). Requiert >= 0.4.22.

Configuration : $HERMES_HOME/hindsight/config.json

• mode : cloud ou local
• recall_budget : low / mid / high
• memory_mode : hybrid / context / tools
• auto_retain / auto_recall : true (défaut)

Interface locale : hindsight-embed -p hermes ui start

Pour une hygiène de mémoire conservatrice, configurer auto_retain=false tout en laissant auto_recall=true vaut la peine d’être considéré — le rappel sémantique reste disponible, mais les tours terminés n’entrent plus automatiquement dans la mémoire à long terme. Traitez la sortie de reflect comme une connaissance dérivée synthétisée à travers les mémoires, et non comme une observation indépendante ayant le même poids probant que les mémoires dont elle a été construite.

Holographic

Idéal pour : configurations axées sur la confidentialité avec stockage local uniquement.

Holographic utilise l’algèbre HRR (Holographic Reduced Representation) pour l’encodage de mémoire, avec une notation de confiance pour la fiabilité de la mémoire. Aucune dépendance au nuage — tout tourne localement sur votre propre matériel.

Dépendances externes : Aucune. Holographic ne nécessite aucun LLM, aucun modèle d’incorporation, aucune base de données et aucune connexion réseau. L’encodage de mémoire est effectué entièrement par l’algèbre HRR exécutée dans le processus. Cela le rend unique parmi tous les fournisseurs de cette comparaison — c’est le seul qui fonctionne avec zéro appel externe. Le compromis est que la qualité de récupération est inférieure à la recherche sémantique basée sur l’incorporation, et qu’il n’y a pas de synthèse inter-mémoires comme la reflect de Hindsight. Pour les utilisateurs pour qui la confidentialité et le fonctionnement sans dépendance sont non négociables, Holographic est la seule option qui le fournit de manière inconditionnelle.

auto_extract est false par défaut, donc Holographic peut fonctionner principalement en tant que petite base de données de faits explicite avec des scores de confiance plutôt que comme un pipeline autonome de transcription vers mémoire. Combiné à ses zéro dépendances, cela en fait l’une des deux options les plus simples — aux côtés de Mnemosyne — pour les lecteurs qui ne veulent délibérément pas de capture automatique.

Outils : 2 outils pour les opérations de mémoire via l’algèbre HRR.

Configuration :

hermes memory setup  # sélectionner "holographic"

RetainDB

Idéal pour : mises à jour de haute fréquence avec compression différentielle.

RetainDB utilise la compression différentielle pour stocker efficacement les mises à jour de mémoire et la récupération hybride (vecteur + BM25 + réordonnancement) pour faire surface au contexte pertinent. C’est basé sur le nuage avec un coût de 20 $/mois, avec tout le traitement de mémoire géré côté serveur.

Dépendances externes : Les appels LLM de RetainDB, le pipeline d’incorporation et le réordonnancement tournent tous sur l’infrastructure de nuage de RetainDB elle-même — vous ne fournissez qu’une RETAINDB_KEY. L’extraction de mémoire utilise Claude Sonnet côté serveur. Il n’y a aucune option d’auto-hébergement et aucun mode local. Toutes les données de conversation sont envoyées aux serveurs RetainDB pour le traitement et le stockage. Si la souveraineté des données ou le fonctionnement hors ligne sont importants pour votre cas d’utilisation, ce fournisseur n’est pas adapté.

Outils : retaindb_profile (profil utilisateur), retaindb_search (recherche sémantique), retaindb_context (contexte pertinent pour la tâche), retaindb_remember (stocker avec type + importance), retaindb_forget (supprimer des mémoires).

L’intégration Hermes de RetainDB a grandi au-delà d’une base de données de mémoire à distance — elle inclut maintenant la synthèse dialectique et un auto-modèle d’agent, ce qui le place architecturalement plus proche de Honcho que d’un simple magasin de vecteurs. C’est utile pour la continuité, mais cela soulève aussi l’importance de séparer les faits sources de l’interprétation générée, la même préoccupation qui s’applique au mode directional de Honcho.

Configuration :

hermes memory setup  # sélectionner "retaindb"

Mnemosyne

Idéal pour : mémoire local-first avec contrôles de rétention granulaires, stockage SQLite inspectable, faits structurés, mémoire temporelle et consolidation configurable.

Mnemosyne n’est pas l’un des fournisseurs de mémoire originaux regroupés de Hermes — il est livré en tant que plugin de fournisseur Hermes séparé mais s’intègre via la même interface MemoryProvider. Son principal avantage est le contrôle : l’enregistrement automatique de la conversation peut être restreint par rôle ou désactivé entièrement avec sync_roles: [], la journalisation des résultats d’outils est désactivée par défaut, les opérations explicites de se souvenir/rappeler/oublier restent disponibles quelle que soit la situation, et les versions plus récentes incluent une suppression facultative de l’écho de soi autour des limites de compression de contexte.

Dépendances externes : Aucune pour l’installation core ; l’extra embeddings ajoute la recherche vectorielle locale. Le stockage est SQLite local avec FTS5 et récupération vectorielle optionnelle. Le système maintient également la mémoire de travail, la mémoire épisodique, les faits structurés, les triples temporels, les faits canoniques et la consolidation.

Mnemosyne met également en œuvre des écritures en file d’attente spécifiques au fournisseur pour memory.write_approval de Hermes, bien que l’approbation des fournisseurs externes ne soit pas encore standardisée à travers Hermes, donc ce chemin doit être testé contre les versions exactes déployées. L’ajout de sophistication a un coût : la mémoire dérivée crée plus d’états de cycle de vie à inspecter et à nettoyer. Les récentes versions de Mnemosyne ont spécifiquement resserré la validation de conflit, le comportement de suppression et le traitement de l’écho de soi — voir Boucles de mémoire auto-renforçantes dans les agents d’IA pour l’audit de production qui a motivé le changement de validation de conflit.

Configuration :

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

Pour une installation complète et un parcours de configuration conservatrice, voir Mnemosyne pour Hermes Agent : Démarrage rapide mémoire locale.

Memori

Idéal pour : agents où l’historique d’exécution compte autant que l’historique de conversation.

Memori est une intégration Hermes plus récente axée sur une mémoire structurée consciente des outils. Il capture les tours terminés ensemble avec le contexte d’exécution disponible — utilisation des outils, étapes de flux de travail, décisions, résultats et contraintes — ce qui est excellent pour se souvenir du travail opérationnel, mais crée aussi une plus grande surface de rétroaction, car les actions, les décisions du modèle et les résultats des outils peuvent tous devenir une mémoire structurée durable.

Contrairement aux fournisseurs qui injectent principalement un grand bloc de mémoire avant chaque tour, Memori expose des outils explicites de rappel et de résumé de rappel, permettant à l’agent de récupérer le contexte opérationnel lorsqu’il en a réellement besoin plutôt que sur chaque invite. Cela réduit la pollution de l’invite, mais ne supprime pas à elle seule le risque de rétroaction du côté écriture — les tours terminés et les traces d’exécution peuvent encore être capturés automatiquement en arrière-plan, donc Memori convient aux utilisateurs qui veulent qu’un agent apprenne des travaux précédents plus qu’aux installations exigeant une rétention explicite stricte.

Configuration :

pip install hermes-memori
hermes memory setup  # sélectionner "memori"

ByteRover

Idéal pour : mémoire local-first avec stockage lisible par l’homme et auditable.

ByteRover stocke la mémoire en tant qu’arbre de contexte markdown structuré — une hiérarchie de fichiers de domaine, sujet et sous-sujet — plutôt que des vecteurs d’incorporation ou une base de données. Un LLM lit le contenu source, raisonne dessus et place les connaissances extraites au bon endroit dans la hiérarchie. La récupération est une recherche plein texte MiniSearch avec repli par niveaux vers une recherche alimentée par LLM, sans base de données vectorielle requise.

Dépendances externes : ByteRover nécessite un LLM pour la curation de mémoire et la recherche (18 fournisseurs pris en charge, y compris Anthropic, OpenAI, Google, Ollama et tout point de terminaison compatible OpenAI via le slot de fournisseur openai-compatible). Il ne nécessite aucun modèle d’incorporation et aucune base de données — l’arbre de contexte est un répertoire local de fichiers markdown simples. La synchronisation du nuage est facultative et n’est utilisée que pour la collaboration d’équipe ; tout fonctionne entièrement hors ligne par défaut. Pour une configuration locale entièrement autonome, connectez Ollama en tant que fournisseur (brv providers connect openai-compatible --base-url http://localhost:11434/v1) et aucune donnée ne quitte votre machine.

Hermes expose auto_extract: false pour désactiver les crochets de curation automatiques, ce qui place ByteRover proche de Holographic et Mnemosyne dans le groupe de fournisseurs où la capture automatique est opt-in plutôt que par défaut.

Outils : 3 outils pour les opérations de mémoire.

Configuration :

hermes memory setup  # sélectionner "byterover"

Supermemory

Idéal pour : flux de travail d’entreprise avec clôture de contexte et ingestion du graphe de session.

Supermemory fournit la clôture de contexte (isolement de la mémoire par contexte) et l’ingestion du graphe de session (importation d’historiques de conversation entiers). Il extrait automatiquement les mémoires, construit des profils utilisateur et exécute une récupération hybride combinant la recherche sémantique et par mots-clés. L’API de nuage gérée est la cible de déploiement principale.

Dépendances externes : Le service de nuage de Supermemory gère toute l’inférence LLM et l’incorporation côté serveur — vous ne fournissez qu’une clé API Supermemory. L’auto-hébergement est disponible exclusivement en tant qu’ajout de plan d’entreprise et se déploie sur Cloudflare Workers ; il vous oblige à fournir PostgreSQL avec l’extension pgvector (pour le stockage de vecteurs) et une clé API OpenAI (obligatoire, avec Anthropic et Gemini comme ajouts facultatifs). Il n’y a aucun chemin d’auto-hébergement basé sur Docker ou local — l’architecture est étroitement couplée au calcul de bord Cloudflare Workers. Pour les utilisateurs qui ont besoin de pleine souveraineté des données sans contrat d’entreprise, ce fournisseur n’est pas le bon choix.

L’intégration Hermes actuelle écrit une session complète à travers le point de terminaison de conversation de Supermemory en tant qu’unité, tamponnant la conversation et l’ingérant à la fin de la session, au réinitialisation ou à la compression. Cela produit un contexte d’entités et de profil plus riche que des écritures de faits isolées, mais cela signifie aussi que le texte d’assistant généré fait partie du matériel présenté au pipeline d’extraction de mémoire, pas seulement des déclarations utilisateur.

Outils : 4 outils pour les opérations de mémoire.

Configuration :

hermes memory setup  # sélectionner "supermemory"

Comment choisir

Plutôt que de choisir un gagnant global, associez le fournisseur à la tâche :

• Mémoire locale explicite la plus simple : Holographic — zéro dépendances, auto_extract désactivé par défaut
• Mémoire locale avec contrôles de cycle de vie plus riches : Mnemosyne — SQLite, rétention granulaire, suppression de l’écho de soi
• Synthèse lourde en graphe : Hindsight — graphe de connaissances plus reflect
• Modélisation de pair ou utilisateur : Honcho — raisonnement dialectique, mode unified pour l’auto-modélisation conservatrice
• Connaissance de style système de fichiers : OpenViking — hiérarchie viking:// par niveaux
• Extraction automatique sans intervention : Mem0 — extraction de faits basée sur LLM sans configuration
• Mémoire opérationnelle/consciente des outils : Memori — capture de tour et de trace d’exécution
• Lisible par l’homme, auditable, pas de pipeline d’incorporation : ByteRover — arbre de contexte markdown simple
• Clôture de contexte d’entreprise : Supermemory — ingestion du graphe de session, hébergé par Cloudflare
• Mises à jour de haute fréquence, pas besoin d’auto-hébergement : RetainDB — compression différentielle, auto-modèle dialectique

Pour des configurations de fournisseur par profil complètes et des modèles de flux de travail réels, voir Configuration de production Hermes Agent.

L’écosystème plus large de mémoire Hermes tiers

Hermes documente une interface de paquet/plugin pour les fournisseurs de mémoire externes, y compris les répertoires installés par l’utilisateur et les points d’entrée Python, donc l’écosystème s’étend maintenant au-delà des fournisseurs avec des sections complètes ci-dessus. Quelques-uns valent la peine d’être connus sans ajouter une section complète pour chacun :

• Scope Recall traite SQLite comme vérité durable tout en gardant la capture de conversation brute limitée séparément, avec un compagnon facultatif turn-closure-audit pour une revue post-tour conservatrice — il sépare les preuves de journal brutes de la mémoire sémantique durable au lieu de traiter chaque tour capturé comme une connaissance à long terme immédiatement équivalente.
• Cognee est un pipeline d’ingestion de graphe de connaissances / ECL plutôt qu’un plugin de mémoire conversationnelle Hermes. Il excelle dans la mémoire de projet ou institutionnelle structurée, mais est plus automatique qu’un magasin de faits explicite ; voir le Démarrage rapide Auto-Hébergement de Cognee et Choisir le bon LLM pour Cognee plutôt que de le traiter comme un fournisseur Hermes à brancher.
• AgentMemory met l’accent sur les événements sources, l’auditabilité et la sémantique de suppression — pertinent après les problèmes d’enregistrements dérivés orphelins discutés pour Mnemosyne ci-dessus.
• XMemo livre des valeurs par défaut conservatrices : la capture de chronologie automatique peut rester désactivée, et la suppression peut être contrainte. L’adoption est encore assez précoce pour ne pas justifier une section complète.

Guides associés

• Centre de mémoire des systèmes d’IA — portée de ce sous-cluster et liens vers les guides Cognee
• Boucles de mémoire auto-renforçantes dans les agents d’IA — pourquoi la politique de capture et les portes d’approbation comptent, en détail
• Mnemosyne pour Hermes Agent : Démarrage rapide mémoire locale — installation complète et configuration conservatrice pour le fournisseur Mnemosyne couvert ci-dessus
• Système de mémoire Hermes Agent — mémoire de deux fichiers de base avant les plugins
• Configuration de production Hermes Agent — câblage des profils pour les fournisseurs en pratique