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

Mis à jour en septembre 2026 : ajout de Mnemosyne et Memori, extension des configurations Honcho et Hindsight, et ajout d’un tableau comparatif des politiques de capture aux côtés du tableau d’infrastructure d’origine.

Les assistants modernes oublient 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 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 sous forme de plugins afin que le framework reste léger tout en permettant à la mémoire de s’étendre.

Ce guide compare les backends de mémoire livrés 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 les 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 hub Mémoire des systèmes d’IA recense cet article aux côtés de Cognee et des guides associés.

Pour la mémoire centrale bornée spécifique à Hermes (MEMORY.md et USER.md), le comportement de gel et les déclencheurs, voir Système de mémoire de Hermes Agent. Le câblage des fournisseurs est une couche d’une hiérarchie de connaissances d’agent plus large — fichiers d’identité, mémoire résidente, compétences, wikis et banques de mémoire, chacun ayant son propre déclencheur d’injection — cartographiée dans Contexte hiérarchique : une hiérarchie de connaissances pour les agents d’IA. Pour le contexte sur la manière dont les fournisseurs de mémoire natifs de Hermes contribuent à son avantage croissant d’adoption par rapport à OpenClaw — y compris les étoiles GitHub, les classements de tokens OpenRouter et les comparaisons de taille de l’écosystème — voir OpenClaw vs Hermes Agent : Étoiles, Téléchargements et Utilisation 2026.

Il existe un autre axe aussi important que la qualité de récupération : la gouvernance de la mémoire. Les fournisseurs diffèrent considérablement quant à 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 à longue durée, ces différences peuvent compter davantage 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 une prémisse future, et Mnemosyne pour Hermes Agent : Prise en main rapide de la mémoire locale pour une configuration conservative détaillée.

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

Dépendances externes. Tout 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’encodage 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é d’exécuter votre pile de mémoire entièrement en auto-hébergement. Hindsight, ByteRover et Mnemosyne regroupent ou éliminent le plus de 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 orienter les appels LLM et d’encodage 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 tables 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 à la question « puis-je exécuter ceci ? ». Le tableau ci-dessous répond à une autre question tout aussi importante pour les agents à longue durée : qu’est-ce qui est écrit sans être demandé, et un humain ou une politique peut-ils intervenir avant que ce 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 notes de qualité — un fournisseur sophistiqué soigneusement configuré peut être plus sûr en pratique qu’un fournisseur simple mal configuré.

Décomposition détaillée

Honcho

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

Honcho s’exécute aux côtés de la mémoire existante — USER.md reste inchangé, 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 le résumé de session, la dérivation de la représentation utilisateur et le raisonnement dialectique ; un modèle d’encodage pour la recherche sémantique entre 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, de sorte que l’inférence peut rester sur site. Le slot d’encodage par défaut est 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’encodage 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).

Principaux réglages de configuration :

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

Modes d’observation et auto-modélisation. directional, la valeur par défaut pour les configurations neuves, permet à la fois aux pairs utilisateur et IA de s’observer eux-mêmes et les uns les autres — raisonnement dialectique plus riche, mais cela signifie aussi que les messages créés par l’IA contribuent au modèle d’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 est spécifiquement préoccupé par les conclusions générées qui alimentent en retour le raisonnement futur — voir Boucles de mémoire auto-renforçantes dans les agents d’IA — devrait traiter unified comme la valeur par défaut plus sûre.

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

Installation :

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

Meilleur pour : gestion des connaissances auto-hébergées avec navigation structurée.

OpenViking fournit une hiérarchie système de fichiers avec chargement par niveaux. Il est gratuit, en auto-hébergement, et vous donne le 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’encodage 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 encodages, les fournisseurs pris en charge incluent OpenAI, Volcengine (Doubao), Jina, Voyage et — via Ollama — tout modèle d’encodage servi localement. L’assistant interactif openviking-server init peut détecter la RAM disponible et recommander des modèles Ollama adaptés (par ex. Qwen3-Embedding 8B pour les encodages, Gemma 4 27B pour VLM) et configurer tout automatiquement pour un réglage entièrement local, 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 (hiérarchisé), viking_browse, viking_remember, viking_add_resource.

Mémoire utilisateur vs mémoire d’agent. Le modèle d’identité d’OpenViking peut séparer l’espace de mémoire utilisateur de l’espace 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 voulez isoler l’état créé par l’assistant de l’état créé par l’utilisateur.

Installation :

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

Mem0

Meilleur pour : gestion de mémoire en mode mains libres avec extraction automatique.

Mem0 gère l’extraction de mémoire côté serveur via un appel LLM pour 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 le contrôle total.

Dépendances externes : Mem0 nécessite un LLM pour l’extraction de mémoire (valeur 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’encodage pour la récupération (valeur 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 encodages, 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 l’élimine avant l’exécution de l’extraction.

Outils : mem0_profile, mem0_search, mem0_conclude.

Installation :

pip install mem0ai
hermes memory setup  # sélectionner "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 un graphe de connaissances avec des relations entre 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 en nouvelles perspectives. 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 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 (valeur par défaut : OpenAI ; les fournisseurs pris en charge incluent Anthropic, Gemini, Groq, Ollama, LM Studio et tout point de terminaison compatible OpenAI). Les encodages et la réorganisation sont par défaut des modèles locaux dans le processus (SentenceTransformers ; l’image Docker grasse/hindsight-all regroupe 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 regroupé via un répertoire de données pg0 géré, ou vous pouvez orienter Hindsight vers une instance PostgreSQL externe. Pour un chemin génératif entièrement local, définissez HINDSIGHT_API_LLM_PROVIDER sur 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électionner 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 intégré ou existant — voir le parcours lié ci-dessous. Nécessite une paire client/API Hindsight actuelle (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 (valeur par défaut)

UI locale : hindsight-embed -p hermes ui start

Pour le parcours auto-hébergé complet — Docker Compose, encodages locaux et réorganisation, contrôle du chemin d’écriture (auto_retain), et câblage local_external Hermes — voir Hindsight pour Hermes Agent : Mémoire auto-hébergée avec LLM locaux. OpenCode, le CLI Cursor et les autres harnais de codage utilisent un paquet différent, avec une banque par dépôt : Mémoire Hindsight pour OpenCode, Cursor et autres agents de codage.

Pour une hygiène de mémoire conservatrice, définir auto_retain=false tout en laissant auto_recall=true mérite d’être envisagé — le rappel sémantique reste disponible, mais les tours terminés n’entrent plus automatiquement dans la mémoire à long terme. Traiter la sortie reflect comme des connaissances dérivées synthétisées entre les mémoires, et non comme une observation indépendante avec le même poids probant que les mémoires sur lesquelles elle a été construite.

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 une notation 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’encodage, aucune base de données et aucune connexion réseau. L’encodage de mémoire est effectué entièrement via l’algèbre HRR s’exécutant 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 revers est que la qualité de récupération est inférieure à la recherche sémantique basée sur les encodages, et qu’il n’y a pas de synthèse inter-mémoires comme le reflect de Hindsight. Pour les utilisateurs pour qui la confidentialité et le fonctionnement sans dépendance ne sont négociables, Holographic est la seule option qui offre cela inconditionnellement.

auto_extract est désactivé par défaut, de sorte que Holographic peut fonctionner principalement en tant que petite base de données de faits explicites avec des scores de confiance plutôt qu’en tant que 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.

Installation :

hermes memory setup  # sélectionner "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 mettre en surface le contexte pertinent. Il 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 de RetainDB, le pipeline d’encodage et la réorganisation s’exécutent tous sur l’infrastructure cloud propre 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 traitement et stockage. Si la souveraineté des données ou le fonctionnement hors ligne comptent pour votre cas d’usage, 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 distante — elle inclut désormais une synthèse dialectique et un auto-modèle d’agent, ce qui la place architecturalement plus proche d’Honcho que d’un simple magasin vectoriel. C’est utile pour la continuité, mais augmente aussi l’importance de séparer les faits sources de l’interprétation générée, la même préoccupation que celle qui s’applique au mode directional d’Honcho.

Installation :

hermes memory setup  # sélectionner "retaindb"

Mnemosyne

Meilleur pour : mémoire locale par défaut 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 regroupés originaux de Hermes — il est livré comme un plugin de fournisseur Hermes séparé mais s’intègre via la même interface MemoryProvider. Son principal avantage est le contrôle : l’autosauvegarde de conversation peut être restreinte par rôle ou désactivée entièrement avec sync_roles: [], la journalisation des résultats d’outils est désactivée par défaut, les opérations explicites remember/recall/forget restent disponibles quelle que soit la situation, et les versions plus récentes incluent une suppression facultative de l’écho de soi aux alentours des frontières de compression du contexte.

Dépendances externes : Aucune pour l’installation core ; le supplément embeddings ajoute la recherche vectorielle locale. Le stockage est local SQLite avec FTS5 et recherche 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 implémente également 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, 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 sorties récentes 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.

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 parcours de configuration conservatrice, voir Mnemosyne pour Hermes Agent : Prise en main rapide de la mémoire locale.

Memori

Meilleur pour : les agents pour lesquels 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 d’outils, étapes du 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 retour d’information, 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 de rappel explicites 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 des invites mais n’élimine pas à lui seul le risque de retour d’information 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 de travaux précédents plus qu’aux installations exigeant une rétention stricte en mode explicite uniquement.

Installation :

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

ByteRover

Meilleur pour : mémoire locale par défaut avec stockage lisible et auditable par l’homme.

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’encodage 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 hiérarchisé 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’encodage et aucune base de données — l’arbre de contexte est un répertoire local de fichiers Markdown plaines. La synchronisation cloud est facultative et utilisée uniquement pour la collaboration d’équipe ; tout fonctionne entièrement hors ligne par défaut. Pour un réglage local 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 hooks de curation automatiques, ce qui place ByteRover près de Holographic et Mnemosyne dans le groupe de fournisseurs où la capture automatique est activable plutôt que par défaut.

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

Installation :

hermes memory setup  # sélectionner "byterover"

Supermemory

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

Supermemory fournit la clôture de contexte (isolant la mémoire par contexte) et l’ingestion de graphe de session (important des historiques de conversation entiers). Il extrait automatiquement des mémoires, construit des profils utilisateurs 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’encodage côté serveur — vous ne fournissez qu’une clé d’API Supermemory. L’auto-hébergement est disponible exclusivement en tant qu’ajout de 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é d’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 de bordure 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 via le point de terminaison de conversation de Supermemory en tant qu’unité, en tamponnant la conversation et en l’ingérant à la fin de 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, et non seulement des énoncés de l’utilisateur.

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

Installation :

hermes memory setup  # sélectionner "supermemory"

Comment choisir

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

• Mémoire explicite locale 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 axée sur les graphes : Hindsight — graphe de connaissances plus reflect
• Modélisation de pair ou d’utilisateur : Honcho — raisonnement dialectique, mode unified pour l’auto-modélisation conservative
• Connaissances de type système de fichiers : OpenViking — hiérarchie viking:// hiérarchisée
• Extraction automatique mains libres : 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 et auditable par l’homme, sans pipeline d’encodage : ByteRover — arbre de contexte Markdown plain
• Clôture de contexte d’entreprise : Supermemory — ingestion de graphe 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 fournisseur par profil complètes et les modèles de flux de travail du monde réel, voir Installation de production Hermes Agent.

L’écosystème élargi de mémoire tiers de Hermes

Hermes documente une interface 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, de sorte que l’écosystème s’étend désormais au-delà des fournisseurs avec des sections complètes ci-dessus. Quelques-uns méritent d’être connus sans ajouter de section complète chacun :

• Scope Recall traite SQLite comme vérité durable tout en gardant la capture brute de conversation séparée par portée, avec un compagnon facultatif turn-closure-audit pour une revue post-tour conservatrice — il sépare les preuves du journal brut de la mémoire sémantique durable au lieu de traiter chaque tour capturé comme immédiatement équivalent à une connaissance à long terme.
• Cognee est un pipeline d’ingestion graphe de connaissances / ECL et non un plugin de mémoire conversationnelle Hermes. Il excelle dans la mémoire de projet ou d’institution structurée, mais est plus automatique qu’un magasin de faits explicite ; voir la Prise en main rapide de l’auto-hébergement de Cognee et Choisir le bon LLM pour Cognee plutôt que de le traiter comme un fournisseur Hermes à insérer en remplacement.
• AgentMemory met l’accent sur les événements sources, l’auditabilité et les sémantiques de suppression — pertinent après les problèmes de registres dérivés orphelins discutés pour Mnemosyne ci-dessus.
• XMemo est livré avec 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 encore mériter une section complète.

Guides associés

• Hub 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 : Prise en main rapide de la mémoire locale — installation complète et configuration conservative pour le fournisseur Mnemosyne traité ci-dessus
• Système de mémoire de Hermes Agent — mémoire centrale à deux fichiers avant les plugins
• Installation de production Hermes Agent — câblage des fournisseurs en pratique par profil