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 que quelque chose 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 d’une session à l’autre — souvent intégrés en tant que plugins afin que le framework reste léger tout en permettant à la mémoire de s’étendre.

Ce guide compare huit backends qui sont fournis en tant que plugins de mémoire externe Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover et Supermemory — et explique comment ils s’intègrent dans les architectures plus larges des systèmes IA. 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 une mémoire centrale bornée spécifique à Hermes (MEMORY.md et USER.md), le comportement de gel et les déclencheurs, consultez le Système de mémoire de l’Agent Hermes.

L’Agent Hermes répertorie huit plugins de fournisseurs de mémoire externe pour une connaissance persistante et trans-session. Un seul fournisseur externe peut être actif à la fois. Les fichiers intégrés MEMORY.md et USER.md restent chargés à côté — ils sont additionnels, non substituables.

Dépendances externes. Chaque fournisseur externe, sauf 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 mémoire fonctionne 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 grand nombre 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 l’Agent Hermes

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 trans-session, alignement utilisateur-agent.

Honcho fonctionne parallèlement à 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 la mise en 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 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’embedding compatible OpenAI fonctionne, y compris les 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).

Paramètres de configuration clés :

• contextCadence (défaut 1) : Nombre minimum de tours entre les actualisations de la couche de base
• dialecticCadence (défaut 2) : Nombre minimum de tours entre les appels LLM peer.chat() (1-5 recommandé)
• dialecticDepth (défaut 1) : Passages .chat() par invocation (limité à 1-3)
• recallMode (défaut ‘hybrid’) : hybrid (auto+outils), context (injection uniquement), tools (outils uniquement)
• writeFrequency (défaut ‘async’) : Timing de vidage : async, turn, session, ou entier N
• observationMode (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 + carte du pair) + supplément dialectique (raisonnement LLM). Sélectionne automatiquement les prompts à 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.<profile> 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 un espace de travail partagé
hermes honcho sync                   # Remplit les pairs IA pour les profils existants

OpenViking

Idéal pour : la 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 le stockage de votre 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 — tout 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 (p. ex. Qwen3-Embedding 8B pour les embeddings, 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.

Configuration :

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

Mem0

Idéal pour : la 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 (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 (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, 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 : la récupération basée sur des graphes de connaissances avec relations d’entités.

Hindsight construit un graphe de connaissances de votre mémoire, extrayant les entités et les relations. Son outil unique reflect effectue une synthèse trans-mémoire — combinant plusieurs mémoires en nouvelles idées. 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éordonne 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 (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 reclassement cross-encoder sont intégrés dans Hindsight lui-même — ils s’exécutent localement dans le package hindsight-all et ne nécessitent aucune API externe. PostgreSQL est également intégré 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 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’appeler des outils (p. ex. qwen3:8b).

Outils : hindsight_retain, hindsight_recall, hindsight_reflect (synthèse trans-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). 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

Holographic

Idéal pour : les 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 un score de confiance pour la fiabilité de la mémoire. Aucune dépendance cloud — tout s’exécute 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 entièrement effectué par l’algèbre HRR s’exécutant 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 trans-mémoire comme le reflect de Hindsight. Pour les utilisateurs pour lesquels la confidentialité et le fonctionnement sans dépendance sont non négociables, Holographique est la seule option qui le garantit 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 : les 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 + reclassement) pour faire surface au 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 de RetainDB, le pipeline d’embedding et le reclassement s’exécutent 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 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 à la tâche), retaindb_remember (stocker avec type + importance), retaindb_forget (supprimer les mémoires).

Configuration :

hermes memory setup  # sélectionner "retaindb"

ByteRover

Idéal pour : la mémoire locale d’abord avec un 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 en cascade 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 de 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 : les flux de travail d’entreprise avec clôture de contexte et ingestion du graphe de session.

Supermemory fournit la clôture de contexte (isolant la mémoire par contexte) et l’ingestion du graphe de session (importation des historiques de conversation complets). Il extrait automatiquement les mémoires, construit des profils utilisateur et exécute une récupération hybride combinant recherche sémantique et par 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 comme 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 edge Cloudflare Workers. Pour les utilisateurs qui ont besoin d’une souveraineté totale des données sans contrat d’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-vous auto-hébergé et gratuit ? OpenViking ou Holographic
• Voulez-vous zéro configuration ? Mem0
• Voulez-vous des graphes de connaissances ? Hindsight
• Voulez-vous la compression delta ? RetainDB
• Voulez-vous l’efficacité de la bande passante ? ByteRover
• Voulez-vous des fonctionnalités d’entreprise ? Supermemory
• Voulez-vous la confidentialité (local uniquement) ? Holographic
• Voulez-vous entièrement local avec zéro service externe ? Holographique (aucune dépendance du tout) ou Hindsight/Mem0/ByteRover avec Ollama
• Voulez-vous 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 flux de travail réels, consultez Configuration de production de l’Agent Hermes.

Guides connexes

• Hub Mémoire des Systèmes IA — portée 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 de l’Agent Hermes — câblage des profils pour les fournisseurs en pratique