Vergleich von Agent Memory Providers – Honcho, Mem0, Hindsight und fünf weitere

Moderne Assistenten vergessen immer noch alles, sobald man den Tab schließt, es sei denn, etwas bleibt über das Kontextfenster hinaus bestehen. Agent Memory Provider sind Dienste oder Bibliotheken, die Fakten und Zusammenfassungen über Sitzungen hinweg speichern – oft als Plugins eingebunden, damit das Framework schlank bleibt, während das Gedächtnis skaliert.

Dieser Leitfaden vergleicht acht Backends, die als externe Speicher-Plugins für Hermes Agent ausgeliefert werden – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover und Supermemory – und erklärt, wie sie in breitere AI systems-Stacks passen. Dieselben Anbieter erscheinen in OpenClaw und anderem Agent-Tooling durch Community- oder offizielle Integrationen. Der AI Systems Memory hub listet diesen Artikel neben Cognee und verwandten Leitfäden auf.

Für Hermes-spezifisches begrenztes Kernspeicher-Management (MEMORY.md und USER.md), das Einfrierverhalten und Trigger siehe Hermes Agent Memory System.

Hermes Agent listet acht externe Speicher-Provider-Plugins für persistentes, sitzungsübergreifendes Wissen auf. Es kann immer nur ein externer Provider gleichzeitig aktiv sein. Die integrierten Dateien MEMORY.md und USER.md bleiben daneben geladen – sie wirken additiv, nicht ersetzend.

Externe Abhängigkeiten. Jeder externe Provider außer Holographic erfordert mindestens einen externen Dienstaufruf – ein LLM zur Extraktion des Speichers, ein Embedding-Modell für die semantische Suche oder eine Datenbank wie PostgreSQL zur Speicherung. Diese Abhängigkeiten haben direkte Auswirkungen auf den Datenschutz, die Kosten und die Frage, ob Ihr Speicher-Stack vollständig selbst gehostet werden kann. Hindsight und ByteRover bündeln oder eliminieren die meisten Abhängigkeiten; Honcho, Mem0 und Supermemory erfordern die meisten Komponenten. Wenn ein Provider Ollama oder einen beliebigen OpenAI-kompatiblen Endpunkt unterstützt, können Sie LLM- und Embedding-Aufrufe an ein lokales Modell leiten und Daten somit vollständig von Servern Dritter fernhalten.

Aktivierung mit Hermes Agent

hermes memory setup   # Interaktive Auswahl + Konfiguration
hermes memory status  # Prüfen, was aktiv ist
hermes memory off     # Externen Provider deaktivieren

Oder manuell in ~/.hermes/config.yaml:

memory:
  provider: openviking  # oder honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Provider-Vergleich

Detaillierte Aufschlüsselung

Honcho

Am besten geeignet für: Multi-Agenten-Systeme, sitzungsübergreifenden Kontext, User-Agent-Alignment.

Honcho läuft neben dem bestehenden Speicher – USER.md bleibt unverändert, und Honcho fügt eine zusätzliche Kontextebene hinzu. Es modelliert Konversationen als Peers, die Nachrichten austauschen – jeweils ein Benutzer-Peer und ein KI-Peer pro Hermes-Profil, die sich alle einen Workspace teilen.

Externe Abhängigkeiten: Honcho benötigt ein LLM für die Sitzungszusammenfassung, die Ableitung der Benutzerrepräsentation und dialektisches Denken; ein Embedding-Modell für die semantische Suche über Beobachtungen hinweg; PostgreSQL mit der pgvector-Erweiterung zur Vektorspeicherung; und Redis für das Caching. Die verwaltete Cloud unter api.honcho.dev übernimmt dies für Sie. Für Self-Hosted-Deployments (Docker, K3s oder Fly.io) stellen Sie Ihre eigenen Zugangsdaten bereit. Der LLM-Slot akzeptiert jeden OpenAI-kompatiblen Endpunkt, einschließlich Ollama und vLLM, sodass die Inferenz lokal erfolgen kann. Der Embedding-Slot verwendet standardmäßig openai/text-embedding-3-small, unterstützt aber konfigurierbare Provider über LLM_EMBEDDING_API_KEY und LLM_EMBEDDING_BASE_URL – jeder OpenAI-kompatible Embedding-Server funktioniert, einschließlich lokaler Optionen wie vLLM mit einem BGE-Modell.

Tools: honcho_profile (Peer-Karte lesen/aktualisieren), honcho_search (semantische Suche), honcho_context (Sitzungskontext – Zusammenfassung, Repräsentation, Karte, Nachrichten), honcho_reasoning (LLM-synthetisiert), honcho_conclude (Schlussfolgerungen erstellen/löschen).

Wichtige Konfigurationsparameter:

• contextCadence (Standard 1): Mindestanzahl an Interaktionen zwischen Aktualisierungen der Basisschicht
• dialecticCadence (Standard 2): Mindestanzahl an Interaktionen zwischen peer.chat() LLM-Aufrufen (1-5 empfohlen)
• dialecticDepth (Standard 1): .chat()-Durchläufe pro Aufruf (begrenzt auf 1-3)
• recallMode (Standard ‘hybrid’): hybrid (Auto+Tools), context (nur Injektion), tools (nur Tools)
• writeFrequency (Standard ‘async’): Flush-Intervall: async, turn, session oder Ganzzahl N
• observationMode (Standard ‘directional’): directional (alles an) oder unified (gemeinsamer Pool)

Architektur: Zwei-Schichten-Kontextinjektion – Basisschicht (Sitzungszusammenfassung + Repräsentation + Peer-Karte) + dialektische Ergänzung (LLM-Reasoning). Wählt automatisch zwischen Cold-Start- und Warm-Prompts.

Multi-Peer-Mapping: Der Workspace ist eine gemeinsame Umgebung über alle Profile hinweg. Der Benutzer-Peer (peerName) ist eine globale menschliche Identität. Der KI-Peer (aiPeer) existiert einmal pro Hermes-Profil (hermes als Standard, hermes.<profil> für andere).

Setup:

hermes memory setup  # "honcho" auswählen
# oder Legacy: hermes honcho setup

Konfiguration: $HERMES_HOME/honcho.json (profilspezifisch) oder ~/.honcho/config.json (global).

Profilverwaltung:

hermes profile create coder --clone  # Erstellt hermes.coder mit gemeinsamem Workspace
hermes honcho sync                   # Füllt KI-Peers für bestehende Profile nach

OpenViking

Am besten geeignet für: Self-hosted Wissensmanagement mit strukturierter Durchsicht.

OpenViking bietet eine Dateisystem-Hierarchie mit gestuftem Laden. Es ist kostenlos, selbst gehostet und gibt Ihnen die volle Kontrolle über Ihre Speicherablage.

Externe Abhängigkeiten: OpenViking benötigt ein VLM (Vision-Language Model) für die semantische Verarbeitung und Speicher-Extraktion sowie ein Embedding-Modell für die Vektorsuche – beide sind obligatorisch. Unterstützte VLM-Provider sind OpenAI, Anthropic, DeepSeek, Gemini, Moonshot und vLLM (für lokale Deployments). Für Embeddings werden OpenAI, Volcengine (Doubao), Jina, Voyage und – via Ollama – jedes lokal bereitgestellte Embedding-Modell unterstützt. Der interaktive openviking-server init-Assistent kann den verfügbaren RAM erkennen, geeignete Ollama-Modelle empfehlen (z. B. Qwen3-Embedding 8B für Embeddings, Gemma 4 27B für VLM) und alles automatisch für ein vollständig lokales Setup ohne API-Keys konfigurieren. Eine externe Datenbank ist nicht erforderlich; OpenViking speichert den Speicher im Dateisystem.

Tools: viking_search, viking_read (gestuft), viking_browse, viking_remember, viking_add_resource.

Setup:

pip install openviking
openviking-server init   # interaktiver Assistent (empfiehlt Ollama-Modelle für lokales Setup)
openviking-server
hermes memory setup  # "openviking" auswählen
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Am besten geeignet für: Automatisierte Speicherverwaltung ohne viel Aufwand.

Mem0 übernimmt die Speicher-Extraktion serverseitig über einen LLM-Aufruf bei jeder add-Operation – es liest die Konversation, extrahiert diskrete Fakten, entfernt Duplikate und speichert sie. Die verwaltete Cloud-API übernimmt die gesamte Infrastruktur. Die Open-Source-Bibliothek und der selbst gehostete Server bieten Ihnen die volle Kontrolle.

Externe Abhängigkeiten: Mem0 benötigt ein LLM für die Speicher-Extraktion (Standard: OpenAI gpt-4.1-nano; 20 Provider unterstützt, einschließlich Ollama, vLLM und LM Studio für lokale Modelle) und ein Embedding-Modell für den Abruf (Standard: OpenAI text-embedding-3-small; 10 Provider unterstützt, einschließlich Ollama und HuggingFace für lokale Modelle). Der Speicher nutzt Qdrant unter /tmp/qdrant im Bibliotheksmodus oder PostgreSQL mit pgvector im selbst gehosteten Servermodus – beides kann lokal betrieben werden. Ein vollständig lokaler Mem0-Stack ohne Cloud ist möglich: Ollama für LLM, Ollama für Embeddings und eine lokale Qdrant-Instanz, alles konfiguriert über Memory.from_config.

Tools: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # "mem0" auswählen
echo "MEM0_API_KEY=ihr-key" >> ~/.hermes/.env

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

Hindsight

Am besten geeignet für: Wissensgraph-basierten Abruf mit Entitätsbeziehungen.

Hindsight erstellt einen Wissensgraph Ihres Speichers, indem es Entitäten und Beziehungen extrahiert. Sein einzigartiges reflect-Tool führt eine übergeordnete Synthese durch – es kombiniert mehrere Speicher zu neuen Erkenntnissen. Der Abruf (Recall) führt vier Strategien parallel aus (semantisch, Keyword/BM25, Graph-Traversal, temporal) und führt die Ergebnisse dann mittels Reciprocal Rank Fusion zusammen und ordnet sie neu.

Externe Abhängigkeiten: Hindsight benötigt ein LLM für die Fakten- und Entitätsextraktion bei retain-Aufrufen sowie für die Synthese bei reflect-Aufrufen (Standard: OpenAI; unterstützte Provider sind Anthropic, Gemini, Groq, Ollama, LM Studio und jeder OpenAI-kompatible Endpunkt). Das Embedding-Modell und das Cross-Encoder-Reranking-Modell sind in Hindsight integriert – sie laufen lokal innerhalb des hindsight-all-Pakets und erfordern keine externe API. PostgreSQL ist ebenfalls über eine verwaltete pg0-Datenverzeichnis-Installation im eingebetteten Python enthalten; alternativ können Sie Hindsight auf eine externe PostgreSQL-Instanz verweisen. Für ein vollständig lokales Setup ohne Cloud setzen Sie HINDSIGHT_API_LLM_PROVIDER=ollama und verweisen Sie auf ein lokales Ollama-Modell – retain und recall funktionieren dabei vollständig; reflect erfordert ein Modell mit Tool-Calling-Fähigkeit (z. B. qwen3:8b).

Tools: hindsight_retain, hindsight_recall, hindsight_reflect (einzigartige übergeordnete Synthese).

Setup:

hermes memory setup  # "hindsight" auswählen
echo "HINDSIGHT_API_KEY=ihr-key" >> ~/.hermes/.env

Installiert automatisch hindsight-client (Cloud) oder hindsight-all (Lokal). Erfordert >= 0.4.22.

Konfiguration: $HERMES_HOME/hindsight/config.json

• mode: cloud oder local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (Standard)

Lokale UI: hindsight-embed -p hermes ui start

Holographic

Am besten geeignet für: Datenschutz-orientierte Setups mit rein lokaler Speicherung.

Holographic nutzt die HRR-Algebra (Holographic Reduced Representation) zur Speicherkodierung, ergänzt durch ein Trust-Scoring für die Speicherzuverlässigkeit. Keine Cloud-Abhängigkeit – alles läuft lokal auf Ihrer eigenen Hardware.

Externe Abhängigkeiten: Keine. Holographic benötigt kein LLM, kein Embedding-Modell, keine Datenbank und keine Netzwerkverbindung. Die Speicherkodierung erfolgt vollständig durch die im Prozess laufende HRR-Algebra. Dies macht es unter allen acht Providern einzigartig – es ist der einzige, der mit null externen Aufrufen arbeitet. Der Nachteil ist, dass die Abrufqualität geringer ist als bei embedding-basierter semantischer Suche und keine übergeordnete Synthese wie das reflect-Tool von Hindsight existiert. Für Nutzer, bei denen Datenschutz und ein Betrieb ohne Abhängigkeiten nicht verhandelbar sind, ist Holographic die einzige Option, die dies bedingungslos liefert.

Tools: 2 Tools für Speicheroperationen via HRR-Algebra.

Setup:

hermes memory setup  # "holographic" auswählen

RetainDB

Am besten geeignet für: Hochfrequente Updates mit Delta-Komprimierung.

RetainDB nutzt Delta-Komprimierung, um Speicher-Updates effizient zu speichern, und hybriden Abruf (Vektor + BM25 + Reranking), um relevanten Kontext bereitzustellen. Es ist cloudbasiert mit Kosten von 20 $/Monat, wobei die gesamte Speicherverarbeitung serverseitig erfolgt.

Externe Abhängigkeiten: Die LLM-Aufrufe, die Embedding-Pipeline und das Reranking von RetainDB laufen alle auf der eigenen Cloud-Infrastruktur von RetainDB – Sie stellen lediglich einen RETAINDB_KEY bereit. Die Speicher-Extraktion nutzt serverseitig Claude Sonnet. Es gibt keine Self-Hosting-Option und keinen lokalen Modus. Alle Konversationsdaten werden zur Verarbeitung und Speicherung an RetainDB-Server gesendet. Wenn Datensouveränität oder ein Offline-Betrieb für Ihren Anwendungsfall wichtig sind, ist dieser Provider nicht geeignet.

Tools: retaindb_profile (Benutzerprofil), retaindb_search (semantische Suche), retaindb_context (aufgabenrelevanter Kontext), retaindb_remember (Speichern mit Typ + Wichtigkeit), retaindb_forget (Speicher löschen).

Setup:

hermes memory setup  # "retaindb" auswählen

ByteRover

Am besten geeignet für: Local-first Speicher mit menschenlesbarer, prüfbarer Ablage.

ByteRover speichert den Speicher als strukturierten Markdown-Kontextbaum – eine Hierarchie aus Domänen-, Themen- und Unterthemen-Dateien – anstatt als Embedding-Vektoren oder Datenbank. Ein LLM liest den Quellinhalt, denkt darüber nach und platziert das extrahierte Wissen an der richtigen Stelle in der Hierarchie. Der Abruf erfolgt über MiniSearch (Volltextsuche) mit einem gestuften Fallback auf LLM-gestützte Suche, ohne dass eine Vektordatenbank erforderlich ist.

Externe Abhängigkeiten: ByteRover benötigt ein LLM für die Speicherpflege und Suche (18 Provider unterstützt, einschließlich Anthropic, OpenAI, Google, Ollama und jeder OpenAI-kompatible Endpunkt über den openai-compatible Provider-Slot). Es benötigt kein Embedding-Modell und keine Datenbank – der Kontextbaum ist ein lokales Verzeichnis aus einfachen Markdown-Dateien. Eine Cloud-Synchronisierung ist optional und dient nur der Team-Zusammenarbeit; standardmäßig funktioniert alles vollständig offline. Für ein vollständig autarkes lokales Setup verbinden Sie Ollama als Provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1), dann verlässt kein Datum Ihren Rechner.

Tools: 3 Tools für Speicheroperationen.

Setup:

hermes memory setup  # "byterover" auswählen

Supermemory

Am besten geeignet für: Enterprise-Workflows mit Context Fencing und Sitzungsgraph-Import.

Supermemory bietet Context Fencing (Isolierung des Speichers nach Kontext) und Sitzungsgraph-Import (Import ganzer Konversationsverläufe). Es extrahiert automatisch Erinnerungen, erstellt Benutzerprofile und führt einen hybriden Abruf durch, der semantische und Keyword-Suche kombiniert. Die verwaltete Cloud-API ist das primäre Deployment-Ziel.

Externe Abhängigkeiten: Der Cloud-Service von Supermemory übernimmt alle LLM-Inferenzen und Embeddings serverseitig – Sie stellen lediglich einen Supermemory-API-Key bereit. Self-Hosting ist exklusiv als Add-on im Enterprise-Plan verfügbar und wird auf Cloudflare Workers bereitgestellt; es erfordert, dass Sie PostgreSQL mit der pgvector-Erweiterung (für die Vektorspeicherung) und einen OpenAI-API-Key bereitstellen (obligatorisch, Anthropic und Gemini sind als optionale Ergänzungen verfügbar). Es gibt keinen Pfad für ein Docker-basiertes oder lokales Self-Hosting – die Architektur ist eng mit der Edge-Compute-Umgebung von Cloudflare Workers verknüpft. Für Nutzer, die volle Datensouveränität ohne Enterprise-Vertrag benötigen, ist dieser Provider nicht die richtige Wahl.

Tools: 4 Tools für Speicheroperationen.

Setup:

hermes memory setup  # "supermemory" auswählen

Die Wahl des richtigen Providers

• Benötigen Sie Multi-Agenten-Unterstützung? Honcho
• Wollen Sie Self-hosted und kostenlos? OpenViking oder Holographic
• Wollen Sie Zero-Config? Mem0
• Wollen Sie Wissensgraphen? Hindsight
• Wollen Sie Delta-Komprimierung? RetainDB
• Wollen Sie Bandbreiteneffizienz? ByteRover
• Wollen Sie Enterprise-Funktionen? Supermemory
• Wollen Sie Datenschutz (nur lokal)? Holographic
• Wollen Sie vollständig lokal ohne externe Dienste? Holographic (gar keine Abhängigkeiten) oder Hindsight/Mem0/ByteRover mit Ollama
• Wollen Sie menschenlesbaren, prüfbaren Speicher ohne Embedding-Pipeline? ByteRover

Für vollständige Provider-Konfigurationen im Profilvergleich und reale Workflow-Muster siehe Hermes Agent production setup.

Verwandte Leitfäden

• AI Systems Memory hub — Umfang dieses Subclusters und Links zu Cognee-Leitfäden
• Hermes Agent Memory System — Kern-Speicher (zwei Dateien) vor den Plugins
• Hermes Agent production setup — Profil-Einbindung der Provider in der Praxis