Vergleich von Agent Memory Providern — Honcho, Mem0, Hindsight und fünf weitere

Moderne Assistenten vergessen nach dem Schließen des Tabs immer noch alles, es sei denn, etwas bleibt über das Kontextfenster hinaus bestehen. Agent Memory Provider (Speicheranbieter für Agenten) sind Dienste oder Bibliotheken, die Fakten und Zusammenfassungen über Sitzungen hinweg halten – oft als Plugins integriert, damit das Framework schlank bleibt, während der Speicher skaliert.

Dieser Leitfaden vergleicht acht Backends, die als externe Speicher-Plugins für den Hermes Agent ausgeliefert werden – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover und Supermemory – und erklärt, wie sie in breitere AI-Systeme-Stacks passen. Dieselben Anbieter erscheinen auch in OpenClaw und anderen Agent-Tools über Community- oder offizielle Integrationen. Das AI Systems Memory Hub listet diesen Artikel zusammen mit Cognee und verwandten Leitfäden auf.

Für Hermes-spezifisches begrenztes Kernspeicher (MEMORY.md und USER.md), Einfrierungsverhalten und Auslöser siehe Hermes Agent Memory System. Für den Kontext, wie Hermes’ acht native Speicheranbieter zu seinem wachsenden Vorteil gegenüber OpenClaw beitragen – einschließlich GitHub-Sterne, OpenRouter-Token-Rankings und Vergleiche der Ökosystemgröße – siehe OpenClaw vs Hermes Agent: Sterne, Downloads & Nutzung 2026.

Hermes Agent listet acht externe Speicher-Plugins für persistentes, sitzungsübergreifendes Wissen auf. Es kann nur ein externer Anbieter gleichzeitig aktiv sein. Die eingebauten Dateien MEMORY.md und USER.md bleiben daneben geladen – additiv, nicht als Ersatz.

Externe Abhängigkeiten. Jeder externe Anbieter außer Holographic erfordert mindestens einen externen Dienstanruf – ein LLM für die Speicherextraktion, ein Embedding-Modell für die semantische Suche oder eine Datenbank wie PostgreSQL für die Speicherung. Diese Abhängigkeiten haben direkte Auswirkungen auf Datenschutz, Kosten und ob Ihr Speicher-Stack vollständig selbst gehostet laufen kann. Hindsight und ByteRover bündeln oder eliminieren die meisten Abhängigkeiten; Honcho, Mem0 und Supermemory erfordern die meisten beweglichen Teile. Wenn ein Anbieter Ollama oder jeden OpenAI-kompatiblen Endpunkt unterstützt, können Sie LLM- und Embedding-Aufrufe an ein lokales Modell weiterleiten und Daten vollständig von Drittanbieter-Servern fernhalten.

Aktivierung mit Hermes Agent

Die folgenden Befehlszeilenschritte spiegeln die Tabellen im Hermes Agent CLI Cheat Sheet wider.

hermes memory setup   # Interaktiver Auswahl-Assistent + Konfiguration
hermes memory status  # Prüfen, was aktiv ist
hermes memory off     # Externen Anbieter deaktivieren

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

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

Anbietervergleich

Detaillierte Aufschlüsselung

Honcho

Am besten für: Multi-Agent-Systeme, sitzungsübergreifenden Kontext, Benutzer-Agent-Ausrichtung.

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

Externe Abhängigkeiten: Honcho erfordert ein LLM für Sitzungs zusammenfassungen, Ableitung der Benutzerrepräsentation und dialektisches Reasoning; ein Embedding-Modell für die semantische Suche über Beobachtungen; PostgreSQL mit der pgvector-Erweiterung für die Vektorspeicherung; und Redis für das Caching. Die verwaltete Cloud unter api.honcho.dev übernimmt all dies für Sie. Für selbstgehostete Bereitstellungen (Docker, K3s oder Fly.io) stellen Sie Ihre eigenen Anmeldedaten bereit. Der LLM-Slot akzeptiert jeden OpenAI-kompatiblen Endpunkt, einschließlich Ollama und vLLM, sodass die Inferenz vor Ort bleiben kann. Der Embedding-Slot standardisiert auf openai/text-embedding-3-small, unterstützt aber konfigurierbare Anbieter ü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 (Schlüsse erstellen/löschen).

Wichtige Konfigurationsschalter:

• contextCadence (Standard 1): Minimale Runden zwischen Aktualisierung der Basisschicht
• dialecticCadence (Standard 2): Minimale Runden zwischen peer.chat()-LLM-Aufrufen (1-5 empfohlen)
• dialecticDepth (Standard 1): .chat()-Durchgänge pro Aufruf (begrenzt auf 1-3)
• recallMode (Standard ‘hybrid’): hybrid (auto+tools), context (nur injizieren), tools (nur Tools)
• writeFrequency (Standard ‘async’): Flush-Timing: async, turn, session oder Integer N
• observationMode (Standard ‘directional’): directional (alle an) oder unified (gemeinsamer Pool)

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

Multi-Peer-Zuordnung: Workspace ist eine gemeinsame Umgebung über Profile hinweg. Benutzer-Peer (peerName) ist eine globale menschliche Identität. AI-Peer (aiPeer) ist eins pro Hermes-Profil (hermes Standard, hermes.<Profil> für andere).

Einrichtung:

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

Konfiguration: $HERMES_HOME/honcho.json (profil-lokal) oder ~/.honcho/config.json (global).

Profilverwaltung:

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

OpenViking

Am besten für: selbstgehostetes Wissensmanagement mit strukturiertem Durchsuchen.

OpenViking bietet eine Dateisystemhierarchie mit gestaffeltem Laden. Es ist kostenlos, selbst gehostet, und gibt Ihnen volle Kontrolle über Ihre Speicherspeicherung.

Externe Abhängigkeiten: OpenViking erfordert ein VLM (Vision-Language-Modell) für die semantische Verarbeitung und Speicherextraktion sowie ein Embedding-Modell für die Vektorsuche – beide sind obligatorisch. Unterstützte VLM-Anbieter umfassen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot und vLLM (für lokale Bereitstellung). Für Embeddings umfassen die unterstützten Anbieter OpenAI, Volcengine (Doubao), Jina, Voyage und – über Ollama – jedes lokal bereitgestellte Embedding-Modell. Der interaktive Assistent openviking-server init kann verfügbaren RAM erkennen und geeignete Ollama-Modelle empfehlen (z.B. Qwen3-Embedding 8B für Embeddings, Gemma 4 27B für VLM) und alles automatisch konfigurieren für ein vollständig lokales Setup ohne API-Schlüssel. Es ist keine externe Datenbank erforderlich; OpenViking speichert den Speicher im Dateisystem.

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

Einrichtung:

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 für: pflegeleichtiges Speichermanagement mit automatischer Extraktion.

Mem0 übernimmt die Speicherextraktion serverseitig über einen LLM-Aufruf bei jeder add-Operation – es liest die Konversation, extrahiert diskrete Fakten, dedupliziert und speichert sie. Die verwaltete Cloud-API übernimmt die gesamte Infrastruktur. Die Open-Source-Bibliothek und der selbstgehostete Server geben Ihnen volle Kontrolle.

Externe Abhängigkeiten: Mem0 erfordert ein LLM für die Speicherextraktion (Standard: OpenAI gpt-4.1-nano; 20 Anbieter 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 Anbieter unterstützt, einschließlich Ollama und HuggingFace für lokale Modelle). Die Speicherung verwendet Qdrant unter /tmp/qdrant im Bibliotheksmodus oder PostgreSQL mit pgvector im selbstgehosteten Servermodus – beide können lokal laufen. Ein vollständig lokaler, cloud-freier Mem0-Stack ist erreichbar: Ollama für LLM, Ollama für Embeddings und eine lokale Qdrant-Instanz, alles konfigurierbar über Memory.from_config.

Tools: mem0_profile, mem0_search, mem0_conclude.

Einrichtung:

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

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

Hindsight

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

Hindsight baut einen Wissensgraphen Ihres Speichers auf, indem es Entitäten und Beziehungen extrahiert. Sein einzigartiges reflect-Tool führt eine cross-memory-Synthese durch – es kombiniert mehrere Erinnerungen zu neuen Erkenntnissen. Der Abruf führt vier Suchstrategien parallel aus (semantisch, Keyword/BM25, Graphtraversierung, temporal), verschmilzt und sortiert die Ergebnisse dann neu unter Verwendung der reziproken Rangfusion.

Externe Abhängigkeiten: Hindsight erfordert ein LLM für die Fakt- und Entitätsextraktion bei retain-Aufrufen und für die Synthese bei reflect-Aufrufen (Standard: OpenAI; unterstützte Anbieter umfassen Anthropic, Gemini, Groq, Ollama, LM Studio und jeden OpenAI-kompatiblen Endpunkt). Das Embedding-Modell und das Cross-Encoder-Reranking-Modell sind in Hindsight selbst gebündelt – sie laufen lokal innerhalb des hindsight-all-Pakets und erfordern keine externe API. PostgreSQL ist ebenfalls mit der eingebetteten Python-Installation über ein verwaltetes pg0-Datenverzeichnis gebündelt; Sie können Hindsight alternativ auf eine externe PostgreSQL-Instanz verweisen. Für ein vollständig lokales, cloud-freies Setup setzen Sie HINDSIGHT_API_LLM_PROVIDER=ollama und verweisen auf ein lokales Ollama-Modell – retain und recall funktionieren vollständig; reflect erfordert ein modell mit Tool-Calling-Fähigkeiten (z.B. qwen3:8b).

Tools: hindsight_retain, hindsight_recall, hindsight_reflect (einzigartige Cross-Memory-Synthese).

Einrichtung:

hermes memory setup  # "hindsight" auswählen
echo "HINDSIGHT_API_KEY=your-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 für: datenschutzfokussierte Setups mit ausschließlich lokaler Speicherung.

Holographic verwendet HRR (Holographic Reduced Representation)-Algebra für die Speicherkodierung, mit Vertrauensbewertung für die Zuverlässigkeit des Speichers. Keine Cloud-Abhängigkeit – alles läuft lokal auf Ihrer eigenen Hardware.

Externe Abhängigkeiten: Keine. Holographic erfordert kein LLM, kein Embedding-Modell, keine Datenbank und keine Netzwerkverbindung. Die Speicherkodierung erfolgt vollständig durch HRR-Algebra im Prozess. Dies macht es einzigartig unter allen acht Anbietern – es ist der einzige, der mit null externen Aufrufen operiert. Der Kompromiss ist, dass die Abrufqualität niedriger ist als bei embedding-basierter semantischer Suche, und es gibt keine Cross-Memory-Synthese wie Hindsights reflect. Für Benutzer, für die Datenschutz und operation ohne Abhängigkeiten nicht verhandelbar sind, ist Holographic die einzige Option, die dies bedingungslos liefert.

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

Einrichtung:

hermes memory setup  # "holographic" auswählen

RetainDB

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

RetainDB verwendet Delta-Kompression, um Speicherupdates effizient zu speichern, und hybriden Abruf (Vektor + BM25 + Reranking), um relevante Kontexte zu finden. Es ist cloud-basiert mit Kosten von 20 $/Monat, wobei die gesamte Speicherverarbeitung serverseitig erfolgt.

Externe Abhängigkeiten: RetainDBs LLM-Aufrufe, Embedding-Pipeline und Reranking laufen alle auf RetainDBs eigener Cloud-Infrastruktur – Sie stellen nur einen RETAINDB_KEY bereit. Die Speicherextraktion verwendet Claude Sonnet serverseitig. Es gibt keine Option zum Selbsthosting und keinen lokalen Modus. Alle Konversationsdaten werden an RetainDB-Server gesendet zur Verarbeitung und Speicherung. Wenn Datenhoheit oder Offline-Betrieb für Ihren Anwendungsfall wichtig sind, ist dieser Anbieter nicht geeignet.

Tools: retaindb_profile (Benutzerprofil), retaindb_search (semantische Suche), retaindb_context (aufgabe-relevanter Kontext), retaindb_remember (speichern mit Typ + Wichtigkeit), retaindb_forget (Erinnerungen löschen).

Einrichtung:

hermes memory setup  # "retaindb" auswählen

ByteRover

Am besten für: lokal-first Speicher mit menschlich lesbarem, überprüfbarem Speicher.

ByteRover speichert Speicher als strukturierten Markdown-Kontextbaum – eine Hierarchie von Domain-, Topic- und Subtopic-Dateien – anstatt von Embedding-Vektoren oder einer Datenbank. Ein LLM liest Quellinhalte, reasoniert darüber und platziert extrahiertes Wissen an der richtigen Stelle in der Hierarchie. Der Abruf erfolgt über MiniSearch-Volltextsuche mit gestaffeltem Fallback zu LLM-gestützter Suche, ohne dass eine Vektordatenbank erforderlich ist.

Externe Abhängigkeiten: ByteRover erfordert ein LLM für die Speicherkuration und Suche (18 Anbieter unterstützt, einschließlich Anthropic, OpenAI, Google, Ollama und jeden OpenAI-kompatiblen Endpunkt über den openai-compatible-Anbieter-Slot). Es erfordert kein Embedding-Modell und keine Datenbank – der Kontextbaum ist ein lokales Verzeichnis von einfachen Markdown-Dateien. Cloud-Sync ist optional und wird nur für Team-Zusammenarbeit verwendet; alles funktioniert standardmäßig vollständig offline. Für ein vollständig eigenständiges lokales Setup verbinden Sie Ollama als Anbieter (brv providers connect openai-compatible --base-url http://localhost:11434/v1) und keine Daten verlassen Ihren Rechner.

Tools: 3 Tools für Speicheroperationen.

Einrichtung:

hermes memory setup  # "byterover" auswählen

Supermemory

Am besten für: Enterprise-Workflows mit Kontextabschirmung und Sitzungsgraph-Import.

Supermemory bietet Kontextabschirmung (Isolierung des Speichers nach Kontext) und Sitzungsgraph-Import (Import ganzer Konversationsverläufe). Es extrahiert automatisch Erinnerungen, baut Benutzerprofile auf und führt hybriden Abruf aus, der semantische und Keyword-Suche kombiniert. Die verwaltete Cloud-API ist das primäre Bereitstellungsziel.

Externe Abhängigkeiten: Supermemorys Cloud-Service übernimmt alle LLM-Inferenz und Embedding serverseitig – Sie stellen nur einen Supermemory-API-Schlüssel bereit. Selbsthosting ist ausschließlich als Enterprise-Plan-Zusatz verfügbar und wird auf Cloudflare Workers bereitgestellt; es erfordert, dass Sie PostgreSQL mit der pgvector-Erweiterung (für Vektorspeicherung) und einen OpenAI-API-Schlüssel bereitstellen (obligatorisch, mit Anthropic und Gemini als optionale Zusätze). Es gibt keinen Docker-basierten oder lokalen Selbsthosting-Pfad – die Architektur ist eng mit Cloudflare Workers Edge-Compute gekoppelt. Für Benutzer, die volle Datenhoheit ohne Enterprise-Vertrag benötigen, ist dieser Anbieter die richtige Wahl nicht.

Tools: 4 Tools für Speicheroperationen.

Einrichtung:

hermes memory setup  # "supermemory" auswählen

Wie Sie wählen

• Brauchen Sie Multi-Agent-Unterstützung? Honcho
• Möchten Sie selbst gehostet und kostenlos? OpenViking oder Holographic
• Möchten Sie Zero-Config? Mem0
• Möchten Sie Wissensgraphen? Hindsight
• Möchten Sie Delta-Kompression? RetainDB
• Möchten Sie Bandbreiteneffizienz? ByteRover
• Möchten Sie Enterprise-Features? Supermemory
• Möchten Sie Datenschutz (nur lokal)? Holographic
• Möchten Sie vollständig lokal mit null externen Diensten? Holographic (keine Abhängigkeiten) oder Hindsight/Mem0/ByteRover mit Ollama
• Möchten Sie menschlich lesbaren, überprüfbaren Speicher ohne Embedding-Pipeline? ByteRover

Für vollständige Profil-für-Profil-Anbieterkonfigurationen 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-Zwei-Dateien-Speicher vor Plugins
• Hermes Agent Production Setup – Profil-Verkabelung für Anbieter in der Praxis