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

Moderne Assistenten vergessen nach wie vor alles, sobald Sie den Tab schließen, es sei denn, etwas bleibt über das Kontextfenster hinaus erhalten. Agent-Memory-Provider sind Dienste oder Bibliotheken, die Fakten und Zusammenfassungen über Sitzungen hinweg speichern – oft als Plugins integriert, damit das Framework schlank bleibt, während die Speicherkapazität skaliert.

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

Für spezifisches, begrenztes Kerngedächtnis von Hermes (MEMORY.md und USER.md), Einfrierungsverhalten und Trigger siehe Hermes Agent Memory System.

Der Hermes Agent listet acht externe Memory-Provider-Plugins für persistente, sitzungübergreifende Wissensspeicherung auf. Nur ein externer Provider kann gleichzeitig aktiv sein. Die integrierten Dateien MEMORY.md und USER.md bleiben parallel geladen – sie ergänzen sich, statt zu ersetzen.

Externe Abhängigkeiten. Jeder externe Provider außer Holographic erfordert mindestens einen externen Service-Aufruf – ein LLM zur Memory-Extraktion, ein Embedding-Modell für semantische Suche oder eine Datenbank wie PostgreSQL für die Speicherung. Diese Abhängigkeiten haben direkte Auswirkungen auf Datenschutz, Kosten und ob Ihr Memory-Stack vollständig self-hosted betrieben werden kann. Hindsight und ByteRover bündeln oder eliminieren die meisten Abhängigkeiten; Honcho, Mem0 und Supermemory erfordern die meisten beweglichen Teile. Wo ein Provider 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

hermes memory setup   # Interaktiver Auswahl- und Konfigurationsassistent
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-Agent-Systeme, sitzungübergreifenden Kontext, User-Agent-Ausrichtung.

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

Externe Abhängigkeiten: Honcho erfordert ein LLM für Sitzungszusammenfassungen, die Ableitung der User-Repräsentation und dialektisches Reasoning; ein Embedding-Modell für semantische Suche über Beobachtungen; PostgreSQL mit der pgvector-Erweiterung für Vektorspeicherung; und Redis für das Caching. Die gemanagte Cloud unter api.honcho.dev übernimmt all dies für Sie. Für selbsthosted-Deployments (Docker, K3s oder Fly.io) stellen Sie Ihre eigenen Credentials bereit. Der LLM-Slot akzeptiert jeden OpenAI-kompatiblen Endpunkt, einschließlich Ollama und vLLM, sodass Inferenz vor Ort bleiben kann. Der Embedding-Slot standardisiert auf 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-Card lesen/aktualisieren), honcho_search (semantische Suche), honcho_context (Sitzungskontext – Zusammenfassung, Repräsentation, Card, Nachrichten), honcho_reasoning (LLM-synthetisiert), honcho_conclude (Schlüsse erstellen/löschen).

Wichtige Konfigurationsparameter:

• contextCadence (Standard 1): Minimale Turns zwischen Aktualisierung der Basisschicht
• dialecticCadence (Standard 2): Minimale Turns zwischen peer.chat() LLM-Aufrufen (1-5 empfohlen)
• dialecticDepth (Standard 1): .chat()-Pässe 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 ganzzahliges N
• observationMode (Standard ‘directional’): directional (alle an) oder unified (gemeinsamer Pool)

Architektur: Zweischichtige Kontextinjektion – Basisschicht (Sitzungszusammenfassung + Repräsentation + Peer-Card) + dialektisches Supplement (LLM-Reasoning). Automatische Auswahl zwischen Cold-Start- und Warm-Prompts.

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

Setup:

hermes memory setup  # wähle "honcho"
# oder legacy: hermes honcho setup

Konfiguration: $HERMES_HOME/honcho.json (profillokal) 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 geeignet für: selbsthosted Knowledge Management mit strukturierter Navigation.

OpenViking bietet eine Dateisystem-Hierarchie mit gestaffeltem Laden. Es ist kostenlos, self-hosted, und gibt Ihnen volle Kontrolle über Ihre Memory-Speicherung.

Externe Abhängigkeiten: OpenViking erfordert ein VLM (Vision-Language-Modell) für semantische Verarbeitung und Memory-Extraktion sowie ein Embedding-Modell für Vektorsuche – beide sind obligatorisch. Unterstützte VLM-Provider umfassen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot und vLLM (für lokale Deployment). Für Embeddings umfassen die unterstützten Provider 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 für ein vollständig lokales, API-Key-freies Setup konfigurieren. Keine externe Datenbank ist erforderlich; OpenViking speichert Memory im Dateisystem.

Tools: viking_search, viking_read (gestaffelt), 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  # wähle "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Am besten geeignet für: Memory-Management ohne manuelle Eingriffe mit automatischer Extraktion.

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

Externe Abhängigkeiten: Mem0 erfordert ein LLM für die Memory-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 Retrieval (Standard: OpenAI text-embedding-3-small; 10 Provider 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 selbsthosted Server-Modus – 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 konfiguriert über Memory.from_config.

Tools: mem0_profile, mem0_search, mem0_conclude.

Setup:

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

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

Hindsight

Am besten geeignet für: wissensgraphbasiertes Recall mit Entitätsbeziehungen.

Hindsight baut einen Wissensgraphen Ihres Memory auf, extrahiert Entitäten und Beziehungen. Sein einzigartiges reflect-Tool führt sitzungübergreifende Synthese durch – es kombiniert mehrere Memories zu neuen Erkenntnissen. Recall führt vier Retrieval-Strategien parallel aus (semantisch, Keyword/BM25, Graph-Traversierung, temporal), fusioniert und sortiert dann die Ergebnisse neu mittels reciprocal rank fusion.

Externe Abhängigkeiten: Hindsight erfordert ein LLM für Fakten- und Entitäts-Extraktion bei retain-Aufrufen und für Synthese bei reflect-Aufrufen (Standard: OpenAI; unterstützte Provider 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 in die eingebettete Python-Installation über ein gemanagtes pg0-Datendirectory gebündelt; Sie können Hindsight alternativ auf eine externe PostgreSQL-Instanz zeigen. Für ein vollständig lokales, cloud-freies Setup setzen Sie HINDSIGHT_API_LLM_PROVIDER=ollama und zeigen auf ein lokales Ollama-Modell – retain und recall funktionieren vollständig; reflect erfordert ein tool-calling-fähiges Modell (z.B. qwen3:8b).

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

Setup:

hermes memory setup  # wähle "hindsight"
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 geeignet für: datenschutzfokusierte Setups mit ausschließlich lokaler Speicherung.

Holographic verwendet HRR (Holographic Reduced Representation)-Algebra für die Memory-Kodierung, mit Trust-Scoring für die Memory-Zuverlässigkeit. 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 Memory-Kodierung erfolgt vollständig durch HRR-Algebra, die im Prozess läuft. Dies macht es einzigartig unter allen acht Providern – es ist der einzige, der mit null externen Aufrufen operiert. Der Nachteil ist, dass die Retrieval-Qualität niedriger ist als bei embedding-basierter semantischer Suche, und es gibt keine sitzungübergreifende Synthese wie Hindsights reflect. Für Benutzer, für die Datenschutz und Null-Abhängigkeits-Betrieb nicht verhandelbar sind, ist Holographic die einzige Option, die dies bedingungslos liefert.

Tools: 2 Tools für Memory-Operationen über HRR-Algebra.

Setup:

hermes memory setup  # wähle "holographic"

RetainDB

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

RetainDB verwendet Delta-Kompression, um Memory-Updates effizient zu speichern, und hybrides Retrieval (Vektor + BM25 + Reranking), um relevanten Kontext zu liefern. Es ist cloud-basiert mit Kosten von 20 $/Monat, wobei die gesamte Memory-Verarbeitung serverseitig erfolgt.

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

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

Setup:

hermes memory setup  # wähle "retaindb"

ByteRover

Am besten geeignet für: lokal-first Memory mit menschenlesbarer, auditierbarer Speicherung.

ByteRover speichert Memory als strukturierten Markdown-Kontextbaum – eine Hierarchie von Domänen-, Themen- und Subthemen-Dateien – anstatt als Embedding-Vektoren oder eine Datenbank. Ein LLM liest Quellinhalte, reasoniert darüber und platziert extrahiertes Wissen an der richtigen Stelle in der Hierarchie. Retrieval ist 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 Memory-Kuration und Suche (18 Provider unterstützt, einschließlich Anthropic, OpenAI, Google, Ollama und jeden OpenAI-kompatiblen Endpunkt über den openai-compatible Provider-Slot). Es erfordert kein Embedding-Modell und keine Datenbank – der Kontextbaum ist ein lokales Verzeichnis von plain Markdown-Dateien. Cloud-Sync ist optional und wird nur für Team-Kollaboration verwendet; alles funktioniert standardmäßig vollständig offline. Für ein vollständig eigenständiges lokales Setup verbinden Sie Ollama als Provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) und keine Daten verlassen Ihr Gerät.

Tools: 3 Tools für Memory-Operationen.

Setup:

hermes memory setup  # wähle "byterover"

Supermemory

Am besten geeignet für: Enterprise-Workflows mit Context Fencing und Session-Graph-Ingest.

Supermemory bietet Context Fencing (Isolierung von Memory nach Kontext) und Session-Graph-Ingest (Import ganzer Konversationsverläufe). Es extrahiert automatisch Memories, baut User-Profile auf und führt hybrides Retrieval durch, das semantische und Keyword-Suche kombiniert. Die gemanagte Cloud-API ist das primäre Deployment-Ziel.

Externe Abhängigkeiten: Supermemorys Cloud-Service übernimmt die gesamte LLM-Inferenz und Embedding serverseitig – Sie liefern nur einen Supermemory-API-Schlüssel. Selbsthosting ist ausschließlich als Enterprise-Plan-Add-on verfügbar und wird auf Cloudflare Workers deployed; es erfordert, dass Sie PostgreSQL mit der pgvector-Erweiterung (für Vektorspeicherung) und einen OpenAI-API-Schlüssel (obligatorisch, mit Anthropic und Gemini als optionale Zusätze) bereitstellen. 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 Provider die falsche Wahl.

Tools: 4 Tools für Memory-Operationen.

Setup:

hermes memory setup  # wähle "supermemory"

Wie man wählt

• Brauchen Sie Multi-Agent-Unterstützung? Honcho
• Möchten Sie selbsthosted 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 Services? Holographic (keine Abhängigkeiten überhaupt) oder Hindsight/Mem0/ByteRover mit Ollama
• Möchten Sie menschenlesbares, auditierbares Memory ohne Embedding-Pipeline? ByteRover

Für vollständige provider-spezifische Konfigurationen nach Profil und Workflow-Mustern in der Praxis, 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-Memory vor Plugins
• Hermes Agent production setup — Profil-Verkabelung für Provider in der Praxis