Comparaison des Agent Memory Providers — Honcho, Mem0, Hindsight et cinq autres

Les assistants modernes oublient encore tout dès que vous fermez l’onglet, à moins que quelque chose ne persiste au-delà de la fenêtre de contexte. Les fournisseurs de mémoire d’agents sont des services ou des bibliothèques qui conservent des faits et des résumés à travers les sessions — souvent intégrés sous forme de plugins afin que le framework reste léger tout en permettant à la mémoire de passer à l’échelle.

Ce guide compare huit backends 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 des piles AI systems plus larges. Les mêmes fournisseurs apparaissent dans OpenClaw et d’autres outils d’agents via des intégrations communautaires ou officielles. Le AI Systems Memory hub répertorie cet article aux côtés de Cognee et des guides connexes.

Pour la mémoire de cœur bornée spécifique à Hermes (MEMORY.md et USER.md), le comportement de gel et les déclencheurs, consultez Hermes Agent Memory System.

Hermes Agent répertorie huit plugins de fournisseurs de mémoire externe pour une connaissance persistante et multi-sessions. Un seul fournisseur externe peut être actif à la fois. Les fichiers intégrés MEMORY.md et USER.md restent chargés en parallèle — ils sont additifs et non de 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 la 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é pour votre pile de mémoire de fonctionner entièrement en auto-hébergement. Hindsight et ByteRover regroupent ou éliminent la plupart des dépendances ; Honcho, Mem0 et Supermemory nécessitent le plus d’éléments 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 ainsi garder vos données entièrement hors des serveurs tiers.

Activation avec 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 multi-sessions, alignement utilisateur-agent.

Honcho fonctionne aux côtés de la mémoire existante — USER.md reste inchangé, 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, le tout partageant un espace de travail.

Dépendances externes : Honcho nécessite un LLM pour la synthèse 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 managé à 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 créneau LLM accepte n’importe quel point de terminaison compatible OpenAI, y compris Ollama et vLLM, afin que l’inférence puisse rester sur site. Le créneau d’embedding utilise par défaut openai/text-embedding-3-small mais supporte des fournisseurs configurables via LLM_EMBEDDING_API_KEY et LLM_EMBEDDING_BASE_URL — n’importe quel serveur d’embedding compatible OpenAI fonctionne, y compris des 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).

Réglages de configuration clés :

• contextCadence (par défaut 1) : Nombre minimum de tours entre deux rafraîchissements de la couche de base
• dialecticCadence (par défaut 2) : Nombre minimum de tours entre les appels LLM peer.chat() (1-5 recommandé)
• dialecticDepth (par défaut 1) : Passages .chat() par invocation (limité entre 1 et 3)
• recallMode (par défaut ‘hybrid’) : hybrid (auto+outils), context (injection uniquement), tools (outils uniquement)
• writeFrequency (par défaut ‘async’) : Fréquence 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 entre des prompts de démarrage à froid (cold-start) ou à chaud (warm).

Mapping 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 unique par profil Hermes (hermes par défaut, hermes.<profile> pour les autres).

Configuration :

hermes memory setup  # sélectionnez "honcho"
# ou version héritée : hermes honcho setup

Config : $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 : gestion des connaissances auto-hébergée avec navigation structurée.

OpenViking fournit une hiérarchie de système de fichiers avec un 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 la mémoire, ainsi qu’un modèle d’embedding pour la recherche vectorielle — les deux sont obligatoires. Les fournisseurs de VLM supportés incluent OpenAI, Anthropic, DeepSeek, Gemini, Moonshot et vLLM (pour le déploiement local). Pour les embeddings, les fournisseurs supportés 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 appropriés (par exemple, Qwen3-Embedding 8B pour les embeddings, Gemma 4 27B pour le VLM) et tout configurer automatiquement pour une installation 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 l'installation locale)
openviking-server
hermes memory setup  # sélectionnez "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 la mémoire côté serveur via un appel LLM à chaque opération add — il lit la conversation, extrait des faits distincts, dédoublonne et les stocke. L’API cloud managé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 la mémoire (par défaut : OpenAI gpt-4.1-nano ; 20 fournisseurs supportés, incluant 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 supportés, incluant 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, le tout configuré via Memory.from_config.

Outils : mem0_profile, mem0_search, mem0_conclude.

Configuration :

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

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

Hindsight

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

Hindsight construit un graphe de connaissances de votre mémoire, en extrayant les entités et les relations. Son outil unique reflect effectue une synthèse multi-mémoire — combinant plusieurs souvenirs en de nouvelles perspectives. Le rappel utilise quatre stratégies de récupération en parallèle (sémantique, mot-clé/BM25, parcours de graphe, temporel), puis fusionne et réordonne les résultats en utilisant la fusion de rang réciproque (reciprocal rank fusion).

Dépendances externes : Hindsight nécessite un LLM pour l’extraction de faits et d’entités lors des appels retain, et pour la synthèse lors des appels reflect (par défaut : OpenAI ; les fournisseurs supportés incluent Anthropic, Gemini, Groq, Ollama, LM Studio et tout point de terminaison compatible OpenAI). Le modèle d’embedding et le modèle de reranking cross-encoder sont intégrés à Hindsight lui-même — ils s’exécutent localement dans le package hindsight-all et ne nécessitent aucune API externe. PostgreSQL est également inclus avec l’installation Python embarquée via un répertoire de données pg0 géré ; vous pouvez alternativement diriger Hindsight vers une instance PostgreSQL externe. Pour une configuration entièrement locale et sans cloud, réglez 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 de l’appel d’outils (par exemple, qwen3:8b).

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

Configuration :

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

Installe automatiquement hindsight-client (cloud) ou hindsight-all (local). Nécessite >= 0.4.22.

Config : $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)

UI locale : hindsight-embed -p hermes ui start

Holographic

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

Holographic utilise l’algèbre HRR (Holographic Reduced Representation) pour l’encodage 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 ni LLM, ni modèle d’embedding, ni base de données, ni connexion réseau. L’encodage de la mémoire est effectué entièrement via l’algèbre HRR s’exécutant en interne. Cela le rend unique parmi les huit fournisseurs — c’est le seul qui fonctionne avec zéro appel externe. La contrepartie est que la qualité de la récupération est inférieure à une recherche sémantique basée sur l’embedding, et il n’y a pas de synthèse multi-mémoire comme le 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 inconditionnellement.

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

Configuration :

hermes memory setup  # sélectionnez "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 une récupération hybride (vecteur + BM25 + reranking) pour faire émerger le contexte pertinent. C’est un service basé sur le cloud avec un coût de 20 $/mois, tout le traitement de la mémoire étant géré côté serveur.

Dépendances externes : Les appels LLM de RetainDB, le pipeline d’embedding et le reranking s’exécutent tous sur l’infrastructure cloud propre à RetainDB — vous ne fournissez qu’une RETAINDB_KEY. L’extraction de la mémoire utilise Claude Sonnet côté serveur. Il n’existe pas d’option d’auto-hébergement ni de mode local. Toutes les données de conversation sont envoyées aux serveurs de RetainDB pour traitement et stockage. Si la souveraineté des données ou le fonctionnement hors ligne est important pour votre cas d’utilisation, ce fournisseur ne convient pas.

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).

Configuration :

hermes memory setup  # sélectionnez "retaindb"

ByteRover

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

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

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

Configuration :

hermes memory setup  # sélectionnez "byterover"

Supermemory

Idéal pour : flux de travail d’entreprise avec context fencing et ingestion de graphe de session.

Supermemory propose le context fencing (isolation de la mémoire par contexte) et l’ingestion de 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 recherche sémantique et par mot-clé. L’API cloud managé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 ne fournissez qu’une clé API Supermemory. L’auto-hébergement est disponible exclusivement en tant qu’extension de plan entreprise et se déploie sur Cloudflare Workers ; il nécessite que vous fournissiez PostgreSQL avec l’extension pgvector (pour le stockage vectoriel) et une clé API OpenAI (obligatoire, avec Anthropic et Gemini en ajouts optionnels). Il n’existe pas de voie d’auto-hébergement basée sur Docker ou locale — l’architecture est étroitement liée à l’edge compute de 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électionnez "supermemory"

Comment choisir

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

Pour des configurations de fournisseurs complètes profil par profil et des modèles de flux de travail réels, consultez Hermes Agent production setup.

Guides connexes

• AI Systems Memory hub — portée de ce sous-cluster et liens vers les guides Cognee
• Hermes Agent Memory System — mémoire de base à deux fichiers avant les plugins
• Hermes Agent production setup — câblage des profils pour les fournisseurs en pratique