Comparaison des fournisseurs de mémoire pour agents — Honcho, Mem0, Hindsight et cinq autres

Les assistants modernes oublient toujours tout lorsque vous fermez l’onglet, à moins qu’un élément ne persiste au-delà de la fenêtre de contexte. Les fournisseurs de mémoire d’agent sont des services ou des bibliothèques qui conservent des faits et des résumés entre les sessions — souvent intégrés en tant que plugins afin que le cadre reste léger tandis que la mémoire évolue.

Ce guide compare huit backends qui sont livrés en tant que plugins de mémoire externe pour Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover et Supermemory — et explique comment ils s’intègrent dans les architectures systèmes IA plus larges. Les mêmes fournisseurs apparaissent dans OpenClaw et d’autres outils d’agent via des intégrations communautaires ou officielles. Le hub Mémoire des Systèmes IA liste cet article aux côtés de Cognee et des guides connexes.

Pour la mémoire centrale bornée spécifique à Hermes (MEMORY.md et USER.md), le comportement de figement et les déclencheurs, consultez Système de mémoire de l’agent Hermes. Pour comprendre comment les huit fournisseurs de mémoire natifs d’Hermes contribuent à son avantage croissant en termes d’adoption par rapport à OpenClaw — y compris les étoiles GitHub, les classements de jetons OpenRouter et les comparaisons de taille de l’écosystème — consultez OpenClaw vs Hermes Agent : Étoiles, Téléchargements et Utilisation 2026.

Hermes Agent répertorie huit plugins de fournisseurs de mémoire externe pour une connaissance persistante et transversale aux sessions. Un seul fournisseur externe peut être actif à la fois. Les fichiers intégrés MEMORY.md et USER.md restent chargés à côté — c’est additif, pas un remplacement.

Dépendances externes. Chaque fournisseur externe, à l’exception de Holographic, nécessite au moins un appel de service externe — un LLM pour l’extraction de mémoire, un modèle d’embedding 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 la possibilité que votre pile de mémoire soit entièrement auto-hébergée. Hindsight et ByteRover regroupent ou éliminent la plupart des dépendances ; Honcho, Mem0 et Supermemory nécessitent le plus de composants mobiles. Lorsqu’un fournisseur prend en charge Ollama ou tout point de terminaison compatible OpenAI, vous pouvez router les appels LLM et d’embedding vers un modèle local et garder les données hors des serveurs tiers.

Activation avec Hermes Agent

Les étapes en ligne de commande ci-dessous reflètent les tableaux de la fiche de référence 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

Comparaison des fournisseurs

Analyse détaillée

Honcho

Idéal pour : systèmes multi-agents, contexte transversal aux 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 de contexte supplémentaire. 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ésumé de session, la dérivation de la représentation utilisateur et le raisonnement dialectique ; un modèle d’embedding pour la recherche sémantique à travers les observations ; PostgreSQL avec l’extension pgvector pour le stockage vectoriel ; et Redis pour le cache. Le cloud 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, afin que l’inférence puisse rester sur site. Le slot d’embedding est par défaut sur openai/text-embedding-3-small mais prend en charge les fournisseurs configurables via LLM_EMBEDDING_API_KEY et LLM_EMBEDDING_BASE_URL — n’importe quel serveur d’embedding compatible OpenAI fonctionne, y compris les options locales comme vLLM avec un modèle BGE.

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

Paramètres de configuration clés :

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

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

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.<profil> pour les autres).

Configuration :

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

Configuration : $HERMES_HOME/honcho.json (local 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 des 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 un contrôle total sur votre stockage de mémoire.

Dépendances externes : OpenViking nécessite un VLM (modèle vision-langage) pour le traitement sémantique et l’extraction de mémoire, et un modèle d’embedding pour la recherche vectorielle — les deux sont obligatoires. Les fournisseurs VLM pris en charge incluent OpenAI, Anthropic, DeepSeek, Gemini, Moonshot et vLLM (pour le déploiement local). Pour les embeddings, les fournisseurs pris en charge incluent OpenAI, Volcengine (Doubao), Jina, Voyage et — via Ollama — n’importe quel modèle d’embedding servi localement. L’assistant interactif openviking-server init peut détecter la RAM disponible et recommander des modèles Ollama adaptés (ex. Qwen3-Embedding 8B pour les embeddings, Gemma 4 27B pour le VLM) et configurer tout automatiquement pour une configuration entièrement locale et 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.

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 la mémoire sans intervention avec extraction automatique.

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

Dépendances externes : Mem0 nécessite un LLM pour l’extraction de mémoire (par 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’embedding pour la récupération (par 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 fonctionner localement. Une pile Mem0 entièrement locale et sans cloud est réalisable : Ollama pour le LLM, Ollama pour les embeddings, et une instance Qdrant locale, tout configuré via Memory.from_config.

Outils : mem0_profile, mem0_search, mem0_conclude.

Configuration :

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

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

Hindsight

Idéal pour : rappel basé sur les graphes de connaissances avec relations d’entités.

Hindsight construit un graphe de connaissances de votre mémoire, extrayant des entités et des relations. Son outil unique reflect effectue une synthèse croisée de la mémoire — combinant plusieurs souvenirs en nouvelles perspectives. La récupération exécute quatre stratégies de récupération en parallèle (sémantique, mot-clé/BM25, traversal de graphe, temporel), puis fusionne et réorganise les résultats en utilisant la fusion de rang réciproque.

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 (par défaut : OpenAI ; fournisseurs pris en charge incluent Anthropic, Gemini, Groq, Ollama, LM Studio et tout point de terminaison compatible OpenAI). Le modèle d’embedding et le modèle de ré-ranking cross-encoder sont intégrés dans Hindsight lui-même — ils fonctionnent localement au sein du paquet hindsight-all et ne nécessitent aucune API externe. PostgreSQL est également intégré avec l’installation Python embarqué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 et sans cloud, définissez HINDSIGHT_API_LLM_PROVIDER=ollama et pointez-le vers un modèle Ollama local — retain et recall fonctionnent pleinement ; reflect nécessite un modèle capable d’appels d’outils (ex. qwen3:8b).

Outils : hindsight_retain, hindsight_recall, hindsight_reflect (synthèse croisée de mémoire unique).

Configuration :

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

Installe automatiquement hindsight-client (cloud) ou hindsight-all (local). Nécessite >= 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 (par défaut)

Interface locale : hindsight-embed -p hermes ui start

Holographic

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

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

Dépendances externes : Aucune. Holographic ne nécessite aucun LLM, aucun modèle d’embedding, aucune base de données et aucune connexion réseau. Le codage de la mémoire est effectué entièrement par l’algèbre HRR fonctionnant dans le processus. Cela le rend unique parmi les huit fournisseurs — c’est le seul qui fonctionne avec zéro appel externe. Le compromis est que la qualité de récupération est inférieure à celle de la recherche sémantique basée sur les embeddings, et il n’y a pas de synthèse croisée de mémoire comme 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 offre cela sans condition.

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 haute fréquence avec compression delta.

RetainDB utilise la compression delta pour stocker efficacement les mises à jour de mémoire et la récupération hybride (vectorielle + BM25 + ré-ranking) pour faire émerger un contexte pertinent. C’est basé sur le cloud avec un coût de 20 $/mois, avec tout le traitement de la mémoire géré côté serveur.

Dépendances externes : Les appels LLM, le pipeline d’embedding et le ré-ranking de RetainDB tournent tous sur l’infrastructure cloud propre à RetainDB — vous fournissez uniquement une RETAINDB_KEY. L’extraction de mémoire utilise Claude Sonnet côté serveur. Il n’y a pas d’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 est important 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 à la tâche), retaindb_remember (stocker avec type + importance), retaindb_forget (supprimer les souvenirs).

Configuration :

hermes memory setup  # sélectionner "retaindb"

ByteRover

Idéal pour : mémoire axée sur le local avec stockage lisible par l’homme et auditable.

ByteRover stocke la mémoire comme un arbre de contexte markdown structuré — une hiérarchie de fichiers de domaine, de sujet et de sous-sujet — plutôt que des vecteurs d’embedding 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 en texte plein 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 et la recherche de mémoire (18 fournisseurs pris en charge, y compris Anthropic, OpenAI, Google, Ollama et tout point de terminaison compatible OpenAI via le slot fournisseur openai-compatible). Il ne nécessite aucun modèle d’embedding et aucune base de données — l’arbre de contexte est un répertoire local de fichiers markdown bruts. La synchronisation cloud est optionnelle et utilisée uniquement pour la collaboration d’équipe ; tout fonctionne entièrement hors ligne par défaut. Pour une configuration locale entièrement autonome, connectez Ollama comme fournisseur (brv providers connect openai-compatible --base-url http://localhost:11434/v1) et aucune donnée ne quitte votre machine.

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

Configuration :

hermes memory setup  # sélectionner "byterover"

Supermemory

Idéal pour : workflows d’entreprise avec clôture de contexte et ingestion de graph de session.

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

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

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

Configuration :

hermes memory setup  # sélectionner "supermemory"

Comment choisir

• Besoin de support multi-agent ? Honcho
• Voulez auto-hébergé et gratuit ? OpenViking ou Holographic
• Voulez zéro configuration ? Mem0
• Voulez des graphes de connaissances ? Hindsight
• Voulez la compression delta ? RetainDB
• Voulez l’efficacité de la bande passante ? ByteRover
• Voulez des fonctionnalités d’entreprise ? Supermemory
• Voulez la confidentialité (local uniquement) ? Holographic
• Voulez entièrement local avec zéro services externes ? Holographic (aucune dépendance du tout) ou Hindsight/Mem0/ByteRover avec Ollama
• Voulez une mémoire lisible par l’homme et auditable sans pipeline d’embedding ? ByteRover

Pour les configurations de fournisseur par profil complètes et les modèles de workflow réels, consultez Configuration de production Hermes Agent.

Guides connexes

• Hub Mémoire des Systèmes IA — périmètre de ce sous-cluster et liens vers les guides Cognee
• Système de mémoire de l’agent Hermes — mémoire centrale à deux fichiers avant les plugins
• Configuration de production Hermes Agent — câblage des profils pour les fournisseurs en pratique