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

Mis à jour en septembre 2026 : ajout de Mnemosyne et Memori, expansion des configurations Honcho et Hindsight, et ajout d’un tableau comparatif des politiques de capture en plus du tableau d’infrastructure original.

Les assistants modernes oublient encore tout lorsque vous fermez l’onglet, à moins qu’une information ne persiste 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 entre les sessions — souvent intégrés en tant que plugins afin que le cadre reste léger pendant que la mémoire se développe.

Ce guide compare les backends de mémoire fournis en tant que plugins externes de mémoire pour Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne et Memori — et explique comment ils s’insèrent dans des piles de systèmes IA plus larges. Les mêmes fournisseurs apparaissent dans OpenClaw et d’autres outils d’agents via des intégrations communautaires ou officielles. L’hub Mémoire des Systèmes IA** liste cet article avec Cognee et des guides connexes.

Pour la mémoire de base 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. Pour un contexte sur la façon dont les fournisseurs de mémoire natifs de Hermes contribuent à son avantage croissant en adoption par rapport à OpenClaw — y compris les étoiles GitHub, les classements de jetons OpenRouter et les comparaisons de la taille de l’écosystème — consultez OpenClaw vs Hermes Agent : Étoiles, Téléchargements & Utilisation 2026.

Il existe un autre axe tout aussi important 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 exécution longue, ces différences peuvent être plus importantes que quelques points supplémentaires sur un benchmark de rappel — voir Boucles de mémoire auto-renforçantes dans les agents IA pour comprendre pourquoi la capture automatique peut transformer une conclusion générée en une prémisse future, et Mnemosyne pour l’Agent Hermes : Guide de démarrage rapide local pour une configuration conservatrice détaillée.

Hermes Agent répertorie dix plugins de fournisseurs de mémoire externes pour une connaissance persistante et trans-sessionnelle — 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, pas en remplacement.

Dépendances externes. Tous les fournisseurs externes, à l’exception de Holographic, nécessitent au moins un appel à un 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 s’exécuter entièrement en auto-hébergement. Hindsight, ByteRover et Mnemosyne incluent ou éliminent la plupart des dépendances ; Honcho, Mem0 et Supermemory nécessitent le plus de composantes mobiles. Si un fournisseur prend en charge Ollama ou tout point de terminaison compatible OpenAI, vous pouvez rediriger les appels LLM et d’incorporation vers un modèle local et garder les données hors des serveurs tiers complètement.

Activation avec l’Agent Hermes

Les étapes en ligne de commande ci-dessous reflètent les tableaux de la fiche de triche CLI de 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, mnemosyne, memori

Comparaison des fournisseurs

Politique de capture et gouvernance

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

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

Analyse détaillée

Honcho

Meilleur pour : systèmes multi-agents, contexte trans-sessionnel, alignement utilisateur-agent.

Honcho s’exécute 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ésumation de session, la dérivation de la représentation 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 vectoriel ; et Redis pour la mise en cache. Le cloud géré sur 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 en local. Le slot d’incorporation a par défaut openai/text-embedding-3-small mais prend en charge les fournisseurs configurables via LLM_EMBEDDING_API_KEY et LLM_EMBEDDING_BASE_URL — tout serveur d’incorporation compatible OpenAI fonctionne, y compris les options locales comme vLLM avec un modèle BGE.

Outils : honcho_profile (lecture/mise à jour de la fiche de 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 clés :

• contextCadence (par défaut 1) : tours minimaux entre les rafraîchissements de la couche de base
• dialecticCadence (par défaut 2) : tours minimaux entre les appels LLM peer.chat() (1-5 recommandé)
• dialecticDepth (par défaut 1) : passes .chat() par appel (borné entre 1 et 3)
• recallMode (par défaut ‘hybrid’) : hybrid (auto+outils), context (injection uniquement), tools (outils uniquement)
• writeFrequency (par défaut ‘async’) : minutage de l’écriture : async, turn, session, ou entier N
• observationMode (par défaut ‘directional’) : directional (tout actif) ou unified (pool partagé)

Modes d’observation et auto-modélisation. directional, le mode par défaut pour les nouvelles configurations, permet à la fois aux pairs utilisateur et IA d’observer eux-mêmes et l’un l’autre — un 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 utilisateur sans construire la boucle d’auto-observation correspondante à partir de sa propre sortie. Toute personne particulièrement préoccupée par les conclusions générées qui réagissent sur le raisonnement futur — voir Boucles de mémoire auto-renforçantes dans les agents IA — devrait considérer unified comme le choix par défaut plus sûr.

Architecture : Injection de contexte à deux couches — couche de base (résumé de session + représentation + fiche de pair) + supplément dialectique (raisonnement LLM). Sélectionne automatiquement les prompts de démarrage à froid ou à 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).

Installation :

hermes memory setup  # sélectionnez "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

Meilleur 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 un 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 le VLM) et tout configurer automatiquement pour une configuration entièrement locale, sans clé d’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 par rapport à mémoire agent. Le modèle d’identité d’OpenViking peut séparer l’espace de mémoire de l’utilisateur d’un pair assistant optionnel. Cette séparation compte 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 souhaitez isoler l’état rédigé par l’assistant de l’état rédigé par l’utilisateur.

Installation :

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

Mem0

Meilleur 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 à chaque opération add — il lit la conversation, extrait des faits discrets, supprime les doublons 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’incorporation 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 sur /tmp/qdrant en mode bibliothèque, ou PostgreSQL avec pgvector en mode serveur auto-hébergé — les deux peuvent s’exécuter localement. Une pile Mem0 entièrement locale, sans cloud, est réalisable : Ollama pour le LLM, Ollama pour les incorporations, et une instance Qdrant locale, le tout configuré 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 compte — 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 l’exécution de l’extraction.

Outils : mem0_profile, mem0_search, mem0_conclude.

Installation :

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

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

Hindsight

Meilleur pour : rappel basé sur des graphes de connaissances avec des 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 inter-mémoires — combinant plusieurs mémoires pour de nouvelles intuitions. Le rappel exécute 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.

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 ; fournisseurs pris en charge incluent Anthropic, Gemini, Groq, Ollama, LM Studio et tout point de terminaison compatible OpenAI). Les incorporations et la réorganisation ont par défaut des modèles locaux en processus (SentenceTransformers ; l’image Docker grasse hindsight-all inclut BGE + MiniLM), et vous pouvez les remplacer par d’autres modèles locaux ou un point de terminaison externe compatible OpenAI / TEI — par exemple Qwen3-Embedding-0.6B et BGE-reranker-v2-m3 sur CPU. PostgreSQL est inclus via un répertoire de données pg0 géré, ou vous pouvez pointer Hindsight vers une instance PostgreSQL externe. Pour un chemin génératif entièrement local, définissez HINDSIGHT_API_LLM_PROVIDER vers un serveur local compatible OpenAI (Ollama ou llama.cpp) ; retain et recall fonctionnent entièrement, et reflect a besoin d’un modèle capable d’appels d’outils.

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

Installation :

hermes plugins install hindsight
hermes memory setup hindsight   # sélectionnez local_external pour une API Hindsight séparée

Le mode cloud accepte toujours une clé d’API dans ~/.hermes/.env. L’installation auto-hébergée utilise Docker Compose contre PostgreSQL embarqué ou existant — voir le guide détaillé lié ci-dessous. Nécessite une paire client/API Hindsight à jour (les docs du plugin citent >= 0.4.22).

Configuration : $HERMES_HOME/hindsight/config.json

• mode : cloud, local, ou local_external
• 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

Pour le guide complet d’auto-hébergement — Docker Compose, incorporations et réorganisation locales, contrôle de la voie d’écriture (auto_retain), et câblage local_external de Hermes — voir Hindsight pour l’Agent Hermes : Mémoire auto-hébergée avec LLM locaux.

Pour une hygiène de mémoire conservatrice, la définition de auto_retain=false tout en laissant auto_recall=true mérite d’être envisagée — 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 connaissance dérivée synthétisée à travers les mémoires, et non comme une observation indépendante avec le même poids probant que les mémoires dont elle a été tirée.

Holographic

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

Holographic utilise l’algèbre HRR (Holographic Reduced Representation) pour l’encodage de mémoire, avec un scoring de confiance pour la fiabilité de la mémoire. Aucune dépendance au 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’incorporation, aucune base de données et aucune connexion réseau. L’encodage de mémoire est effectué entièrement via l’algèbre HRR exécutée en 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 les incorporations, et qu’il n’y a pas de synthèse inter-mémoires 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 le propose inconditionnellement.

auto_extract est défini sur false par défaut, de sorte que Holographic peut fonctionner principalement comme une 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é avec ses zéro dépendances, cela en fait l’une des deux options les plus simples — avec 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.

Installation :

hermes memory setup  # sélectionnez "holographic"

RetainDB

Meilleur 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éorganisation) pour présenter un contexte pertinent. C’est basé sur le cloud 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, le pipeline d’incorporation et la réorganisation de RetainDB s’exécutent tous sur l’infrastructure cloud de RetainDB — vous ne fournissez qu’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 pas de 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 comptent 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).

L’intégration Hermes de RetainDB a grandi au-delà d’une base de données de mémoire distante — elle inclut maintenant la synthèse dialectique et un auto-modèle d’agent, ce qui la place architecturalement plus près d’Honcho que d’un simple magasin vectoriel. C’est utile pour la continuité, mais augmente également 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 d’Honcho.

Installation :

hermes memory setup  # sélectionnez "retaindb"

Mnemosyne

Meilleur pour : mémoire local-first avec des 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 inclus dans Hermes — il est fourni 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 des conversations 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 rappel/oubli restent disponibles quelle que soit la situation, et les versions plus récentes incluent une suppression optionnelle de l’écho auto autour des frontières 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 une récupération vectorielle optionnelle. Le système maintient également la mémoire de travail, la mémoire épisodique, les faits structurés, les triplets temporels, les faits canoniques et la consolidation.

Mnemosyne met également en œuvre des écritures en file 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, de sorte que ce chemin doit être testé contre les versions exactes déployées. La sophistication supplémentaire a un coût : la mémoire dérivée crée plus d’états de cycle de vie à inspecter et à nettoyer. Les dernières versions de Mnemosyne ont spécifiquement resserré la validation de conflits, le comportement de suppression et la gestion de l’écho auto — voir Boucles de mémoire auto-renforçantes dans les agents IA pour l’audit de production qui a motivé le changement de validation des conflits.

Installation :

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

Pour l’installation complète et un guide de configuration conservatrice, voir Mnemosyne pour l’Agent Hermes : Guide de démarrage rapide local.

Memori

Meilleur 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 la 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 surface de rétroaction plus grande, 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 qu’à chaque prompt. Cela réduit la pollution du prompt mais n’élimine pas à lui seul le risque de rétroaction côté écriture — les tours terminés et les traces d’exécution peuvent toujours être capturés automatiquement en arrière-plan, de sorte que Memori convient aux utilisateurs qui veulent qu’un agent apprenne du travail précédent plus qu’aux installations nécessitant une rétention explicite stricte.

Installation :

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

ByteRover

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

ByteRover stocke la mémoire sous forme d’arbre de contexte markdown structuré — une hiérarchie de fichiers de domaine, de sujet et de sous-sujet — plutôt que de vecteurs d’incorporation ou d’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 propulsée par LLM, sans base de données vectorielle requise.

Dépendances externes : ByteRover nécessite un LLM pour la curation de la 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 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.

Hermes expose auto_extract: false pour désactiver les crochets de curation automatique, ce qui place ByteRover près 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.

Installation :

hermes memory setup  # sélectionnez "byterover"

Supermemory

Meilleur pour : flux de travail d’entreprise avec clôture de contexte et ingestion de graphes de session.

Supermemory fournit la clôture de contexte (isolement de la mémoire par contexte) et l’ingestion de graphes de session (importation de l’historique de conversation entier). 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 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’incorporation côté serveur — vous ne fournissez qu’une clé d’API Supermemory. L’auto-hébergement est disponible exclusivement en tant qu’option de plan d’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é d’API OpenAI (obligatoire, avec Anthropic et Gemini en options supplémentaires). Il n’y a pas de chemin d’auto-hébergement basé sur Docker ou local — l’architecture est étroitement couplée au calcul d’extrémité 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.

L’intégration Hermes actuelle écrit une session complète à travers le point de terminaison de conversation de Supermemory en tant qu’unité, mettant en tampon la conversation et l’ingérant à la fin de la session, au réinitialisation ou à la compression. Cela produit un contexte d’entité et de profil plus riche que les é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, et non seulement les déclarations utilisateur.

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

Installation :

hermes memory setup  # sélectionnez "supermemory"

Comment choisir

Plutôt que de choisir un vainqueur 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 des contrôles de cycle de vie plus riches : Mnemosyne — SQLite, rétention granulaire, suppression de l’écho auto
• Synthèse axée sur les graphes : Hindsight — graphe de connaissances plus reflect
• Modélisation de pair ou utilisateur : Honcho — raisonnement dialectique, mode unified pour l’auto-modélisation conservatrice
• Connaissances de type 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 des tours et des traces d’exécution
• Lisible par l’homme, auditable, sans pipeline d’incorporation : ByteRover — arbre de contexte markdown simple
• Clôture de contexte d’entreprise : Supermemory — ingestion de graphes de session, hébergé par Cloudflare
• Mises à jour à haute fréquence, pas besoin d’auto-hébergement : RetainDB — compression delta, auto-modèle dialectique

Pour les configurations de fournisseurs par profil et les modèles de flux de travail dans le monde réel, voir Configuration de production de l’Agent Hermes.

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

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

• Scope Recall traite SQLite comme une vérité durable tout en gardant la capture brute de la conversation séparée, avec un compagnon optionnel turn-closure-audit pour une revue post-tour conservatrice — il sépare la preuve du journal brut 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 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 d’auto-hébergement de Cognee et Choisir le bon LLM pour Cognee au lieu de le traiter comme un fournisseur Hermes de remplacement.
• AgentMemory met l’accent sur les événements sources, l’auditabilité et la sémantique de suppression — pertinent après les problèmes de records dérivés orphelins discutés pour Mnemosyne ci-dessus.
• XMemo offre des valeurs par défaut conservatrices : la capture automatique de chronologie 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

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