Vergleich der Agent-Memory-Provider: Capture Policy und Self-Hosting

Aktualisiert im September 2026: Hinzufügung von Mnemosyne und Memori, Erweiterung der Konfiguration für Honcho und Hindsight sowie Hinzufügung eines Vergleichs der Erfassungsrichtlinien neben der ursprünglichen Infrastruktur-Tabelle.

Moderne Assistenten vergessen immer noch alles, wenn Sie den Tab schließen, es sei denn, etwas bleibt außerhalb des Kontextfensters erhalten. Agent Memory Provider sind Dienste oder Bibliotheken, die Fakten und Zusammenfassungen über Sitzungen hinweg speichern – oft als Plugins angebunden, damit das Framework schlank bleibt, während das Gedächtnis skaliert.

Dieser Leitfaden vergleicht die Speicher-Backends, die als externe Speicher-Plugins für Hermes Agent ausgeliefert werden – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne und Memori – und erklärt, wie sie in größere KI-Systeme-Stacks eingebunden werden. Die gleichen Anbieter erscheinen in OpenClaw und anderen Agent-Tools über Community- oder offizielle Integrationen. Der KI-Systeme Speicher-Hub listet diesen Artikel neben Cognee und verwandten Leitfäden auf.

Für die hermes-spezifische begrenzte Kernspeicher (MEMORY.md und USER.md), das Einfrieren-Verhalten und Trigger siehe Hermes Agent Speichersystem. Für Kontext dazu, wie die nativen Speicher-Provider von Hermes zu seinem wachsenden Adoption-Vorteil gegenüber OpenClaw beitragen – einschließlich GitHub-Sterne, OpenRouter-Token-Rankings und Ökosystem-Größenvergleiche – siehe OpenClaw vs Hermes Agent: Sterne, Downloads & Nutzung 2026.

Es gibt eine weitere Achse, die genauso wichtig ist wie die Abrufqualität: Speichergovernance. Provider unterscheiden sich erheblich darin, was sie automatisch erfassen, ob assistant-generierte Ausgaben zu dauerhaftem Gedächtnis werden können, ob Reflexionen als Fakten gespeichert werden, wie Widersprüche aufgelöst werden und ob ein Mensch eine Schreiboperation überprüfen kann, bevor sie zum zukünftigen Kontext wird. Für langlebige Agenten können diese Unterschiede wichtiger sein als ein paar weitere Punkte in einem Recall-Benchmark – siehe Selbstverstärkende Speicher-Schleifen in KI-Agenten für die Gründe, warum automatische Erfassung einen generierten Schluss in eine zukünftige Prämisse verwandeln kann, und Mnemosyne für Hermes Agent: Lokaler Speicher Quickstart für eine durchgeführte konservative Konfiguration.

Hermes Agent listet zehn externe Speicher-Provider-Plugins für persistente, sitzungsübergreifende Kenntnisse – die ursprünglichen acht plus Mnemosyne und Memori. Nur ein externer Provider kann gleichzeitig aktiv sein. Die eingebauten MEMORY.md und USER.md bleiben daneben geladen – additiv, nicht ersetzend.

Externe Abhängigkeiten. Jeder externe Provider außer Holographic erfordert mindestens einen externen Dienstaufruf – ein LLM für die Extraktion von Merkmalen, 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 Speicher-Stack vollständig self-hosted laufen kann. Hindsight, ByteRover und Mnemosyne bündeln oder eliminieren die meisten Abhängigkeiten; Honcho, Mem0 und Supermemory erfordern die meisten beweglichen Teile. Wo ein Provider Ollama oder einen OpenAI-kompatiblen Endpoint unterstützt, können Sie LLM- und Embedding-Aufrufe an ein lokales Modell routen und Daten vollständig von Drittanbieter-Servern fernhalten.

Aktivierung mit Hermes Agent

Die folgenden Befehlszeilenschritte spiegeln die Tabellen im Hermes Agent CLI-Spickzettel wider.

hermes memory setup   # Interaktiver Auswahlmenü + 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, mnemosyne, memori

Provider-Vergleich

Erfassungsrichtlinie und Governance

Speicherung und Abhängigkeiten beantworten die Frage „Kann ich das ausführen?". Die folgende Tabelle beantwortet eine andere Frage, die für langlebige Agenten genauso wichtig ist: Was wird ohne Aufforderung geschrieben, und kann ein Mensch oder eine Richtlinie eingreifen, bevor es dauerhaft wird? Siehe Selbstverstärkende Speicher-Schleifen in KI-Agenten für die Gründe, warum diese Achse wichtig ist.

Dies sind architektonische Risikokategorien, keine Qualitätsscores – ein sorgfältig konfigurierter, raffinierter Provider kann in der Praxis sicherer sein als ein schlecht konfigurierter, einfacher.

Detaillierte Aufschlüsselung

Honcho

Ideal für: Multi-Agenten-Systeme, sitzungsübergreifender Kontext, User-Agent-Ausrichtung.

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

Externe Abhängigkeiten: Honcho erfordert ein LLM für Sitzungs-Zusammenfassungen, Nutzerrepräsentationsableitung und dialektische Schlussfolgerung; ein Embedding-Modell für semantische Suche über Beobachtungen hinweg; PostgreSQL mit der pgvector-Erweiterung für Vektorspeicherung; und Redis für Caching. Die verwaltete Cloud auf api.honcho.dev übernimmt all dies für Sie. Für Self-hosted-Deployment (Docker, K3s oder Fly.io) stellen Sie Ihre eigenen Zugangsdaten bereit. Der LLM-Slot akzeptiert jeden OpenAI-kompatiblen Endpoint, einschließlich Ollama und vLLM, sodass Inferenz lokal bleiben 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.

Werkzeuge: 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 Konfigurations-Knobs:

• contextCadence (Standard 1): Minimale Umkehrungen zwischen Basisschicht-Aktualisierung
• dialecticCadence (Standard 2): Minimale Umkehrungen zwischen peer.chat() LLM-Aufrufen (1-5 empfohlen)
• dialecticDepth (Standard 1): .chat() Pässe pro Aufruf (eingeklemmt auf 1-3)
• recallMode (Standard ‘hybrid’): hybrid (auto+Werkzeuge), context (nur injizieren), tools (nur Werkzeuge)
• writeFrequency (Standard ‘async’): Flush-Timing: async, turn, session oder ganze Zahl N
• observationMode (Standard ‘directional’): directional (alle ein) oder unified (geteilter Pool)

Beobachtungsmodi und Selbstmodellierung. directional, der Standard für neue Konfigurationen, lässt sowohl das User- als auch das KI-Peer sich selbst und den jeweils anderen beobachten – reichhaltigere dialektische Schlussfolgerung, bedeutet aber auch, dass KI-autoreierte Nachrichten zu Honchos Modell der KI selbst beitragen. unified ist die konservativere Option: Die KI modelliert den Nutzer aus Nutzernachrichten, ohne die entsprechende Selbstbeobachtungsschleife aus ihrer eigenen Ausgabe zu bauen. Jeder, der sich speziell vor generierten Schlüssen sorgt, die in zukünftige Schlussfolgerungen zurückfließen – siehe Selbstverstärkende Speicher-Schleifen in KI-Agenten – sollte unified als sichereren Standard betrachten.

Architektur: Zweischichtige Kontextinjection – Basisschicht (Sitzungszusammenfassung + Repräsentation + Peer-Karte) + dialektisches Supplement (LLM-Schlussfolgerung). Wählt automatisch Cold-Start- vs. Warm-Prompts.

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

Setup:

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 geteiltem Workspace
hermes honcho sync                   # Befüllt KI-Peers für bestehende Profile

OpenViking

Ideal für: Self-hosted Wissensmanagement mit strukturiertem Stöbern.

OpenViking bietet eine Dateisystemhierarchie mit gestufter Laden. Es ist gratis, self-hosted und gibt Ihnen die volle Kontrolle über Ihre Speicherspeicherung.

Externe Abhängigkeiten: OpenViking erfordert ein VLM (Vision-Language-Modell) für semantische Verarbeitung und Merkmal-Extraktion sowie ein Embedding-Modell für Vektorsuche – beide sind erforderlich. Unterstützte VLM-Provider umfassen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot und vLLM (für lokale Installation). Für Embeddings umfassen unterstützte Provider OpenAI, Volcengine (Doubao), Jina, Voyage und – über Ollama – jedes lokal ausgelieferte 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 eine vollständig lokale, API-Schlüssel-freie Einrichtung konfigurieren. Es ist keine externe Datenbank erforderlich; OpenViking speichert Speicher im Dateisystem.

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

Nutzerspeicher vs. Agentenspeicher. Das Identitätsmodell von OpenViking kann den Speichernamensraum des Nutzers von einem optionalen Assistenten-Peer trennen. Diese Trennung ist für die Speicherhygiene wichtig: Fakten über den Nutzer und vom Agenten generierte Erfahrung müssen nicht dieselbe Retention-Richtlinie teilen, was eine nützliche Eigenschaft ist, wenn Sie vom Nutzer-autoreierten Zustand isolierte Assistenten-autoreierte Zustände wollen.

Setup:

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

Mem0

Ideal für: Handoff-Speicher-Management mit automatischer Extraktion.

Mem0 behandelt Merkmal-Extraktion serverseitig über einen LLM-Aufruf bei jeder add-Operation – es liest das Gespräch, extrahierte diskrete Fakten, entdoppelt und speichert sie. Die verwaltete Cloud-API übernimmt alle Infrastrukturen. Die Open-Source-Bibliothek und der Self-hosted-Server geben Ihnen volle Kontrolle.

Externe Abhängigkeiten: Mem0 erfordert ein LLM für Merkmal-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). Speicherung verwendet Qdrant unter /tmp/qdrant im Bibliotheksmodus oder PostgreSQL mit pgvector im Self-hosted-Servermodus – beide können lokal ausgeführt werden. Ein vollständig lokaler, Cloud-freier Mem0-Stack ist erreichbar: Ollama für LLM, Ollama für Embeddings und eine lokale Qdrant-Instanz, alle konfiguriert über Memory.from_config.

Mem0 ist im Wesentlichen ein Extraktionssystem: Ein LLM wandelt konversationelles Material in diskrete Erinnerungen um und führt Entdoppelung und Aktualisierungslogik durch. Das ist bequem, bedeutet aber, dass die Herkunft der Extraktion wichtig ist – ein generierter Assistenten-Schluss kann strukturell ununterscheidbar von einem vom Nutzer geäußerten Fakt werden, es sei denn, der Erfassungspfad filtert ihn heraus, bevor die Extraktion läuft.

Werkzeuge: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # "mem0" auswählen
echo "MEM0_API_KEY=Ihr-Schlüssel" >> ~/.hermes/.env

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

Hindsight

Ideal für: Wissensgraph-basiertes Recall mit Entitätsbeziehungen.

Hindsight baut einen Wissensgraph Ihres Speichers auf, indem es Entitäten und Beziehungen extrahiert. Sein einzigartiges reflect-Werkzeug führt Synthese über mehrere Speicher durch – es kombiniert mehrere Erinnerungen zu neuen Erkenntnissen. Recall führt vier Retrieval-Strategien parallel aus (semantisch, Keyword/BM25, Graphen-Durchlauf, zeitlich) und verschmilzt und sortiert Ergebnisse anschließend neu, используя den gegenseitigen Rang-Fusionsansatz.

Externe Abhängigkeiten: Hindsight erfordert ein LLM für Fakt- und Entität-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 Endpoint). Embeddings und Reranking verwenden standardmäßig in-prozess lokale Modelle (SentenceTransformers; das fette Docker/hindsight-all-Image bündelt BGE + MiniLM), und Sie können diese gegen andere lokale Modelle oder einen externen OpenAI-kompatiblen / TEI-Endpoint austauschen – zum Beispiel Qwen3-Embedding-0.6B und BGE-reranker-v2-m3 auf CPU. PostgreSQL wird über einen verwalteten pg0-Datenverzeichnis gebündelt, oder Sie können Hindsight auf eine externe PostgreSQL-Instanz zeigen. Für einen vollständig lokalen generativen Pfad, setzen Sie HINDSIGHT_API_LLM_PROVIDER auf einen OpenAI-kompatiblen lokalen Server (Ollama oder llama.cpp); retain und recall funktionieren vollständig, und reflect benötigt ein tool-calling-fähiges Modell.

Werkzeuge: hindsight_retain, hindsight_recall, hindsight_reflect (einzigartige Synthese über mehrere Speicher hinweg).

Setup:

hermes plugins install hindsight
hermes memory setup hindsight   # local_external für einen separaten Hindsight-API auswählen

Cloud-Modus akzeptiert weiterhin einen API-Schlüssel in ~/.hermes/.env. Self-hosted-Installation verwendet Docker Compose gegen eingebettetes oder bestehendes PostgreSQL – siehe den unten verlinkten Durchgang. Erfordert ein aktuelles Hindsight-Client/API-Paar (Plugin-Dokumente zitieren >= 0.4.22).

Konfiguration: $HERMES_HOME/hindsight/config.json

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

Lokale UI: hindsight-embed -p hermes ui start

Für den vollständigen Self-hosted-Durchgang – Docker Compose, lokale Embeddings und Reranking, Schreibweg-Kontrolle (auto_retain) und Hermes local_external-Verdrahtung – siehe Hindsight für Hermes Agent: Self-Hosted Speicher mit lokalen LLMs.

Für konservative Speicherhygiene ist es lohnenswert, auto_retain=false zu setzen, während auto_recall=true bleibt – semantisches Recall bleibt verfügbar, aber abgeschlossene Umkehrungen betreten nicht mehr automatisch den Langzeitspeicher. Betrachten Sie reflect-Ausgaben als abgeleitetes Wissen, das über Speicher hinweg synthetisiert wurde, und nicht als unabhängige Beobachtung mit dem gleichen Beweisgewicht wie die Speicher, aus denen es aufgebaut wurde.

Holographic

Ideal für: Datenschutz-fokussierte Setups mit nur lokaler Speicherung.

Holographic verwendet HRR (Holographic Reduced Representation) Algebra für Speicher-Kodierung, mit Trust-Scoring für 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 Speicherkodierung erfolgt vollständig über HRR-Algebra, die in-prozess läuft. Das macht es einzigartig unter allen Providern in diesem Vergleich – es ist der einzige, der mit null externen Aufrufen arbeitet. Der Nachteil ist, dass die Abrufqualität niedriger ist als bei Embedding-basierter semantischer Suche, und es gibt keine Synthese über mehrere Speicher hinweg wie bei Hindights reflect. Für Benutzer, bei denen Datenschutz und Abhängigkeits-freier Betrieb unverhandelbar sind, ist Holographic die einzige Option, die dies bedingungslos liefert.

auto_extract ist standardmäßig auf false gesetzt, sodass Holographic primär als kleine explizite Faktendatenbank mit Trust-Scores operieren kann, statt als autonome Transkript-zu-Speicher-Pipeline. Zusammen mit seinen Null-Abhängigkeiten macht es es zu einer der zwei einfachsten Optionen – neben Mnemosyne – für Leser, die absichtlich keine automatische Erfassung wollen.

Werkzeuge: 2 Werkzeuge für Speicheroperationen über HRR-Algebra.

Setup:

hermes memory setup  # "holographic" auswählen

RetainDB

Ideal für: Hochfrequente Aktualisierungen mit Delta-Kompression.

RetainDB verwendet Delta-Kompression, um Speicher-Updates effizient zu speichern, und Hybrid-Retrieval (Vektor + BM25 + Reranking), um relevanten Kontext an die Oberfläche zu bringen. Es ist Cloud-basiert mit einer Kosten von 20 €/Monat, wobei alle Speicherverarbeitung 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. Merkmal-Extraktion verwendet Claude Sonnet serverseitig. Es gibt keine Self-Hosting-Option und keinen lokalen Modus. Alle Gesprächsdaten werden an RetainDB-Server gesendet für Verarbeitung und Speicherung. Wenn Datensouveränität oder Offline-Betrieb für Ihren Anwendungsfall wichtig ist, ist dieser Provider nicht geeignet.

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

RetainDBs Hermes-Integration ist über eine Remote-Speicherdatenbank hinausgewachsen – es umfasst jetzt dialektische Synthese und ein Agenten-Selbstmodell, was es architektonisch näher an Honcho als an einen einfachen Vektorspeicher bringt. Das ist nützlich für Kontinuität, erhöht aber auch die Bedeutung, Quellfakten von generierter Interpretation zu trennen, dieselbe Besorgnis, die für Honchos directional-Modus gilt.

Setup:

hermes memory setup  # "retaindb" auswählen

Mnemosyne

Ideal für: Lokal-first-Speicher mit granularen Retention-Steuerelementen, inspizierbarer SQLite-Speicherung, strukturierten Fakten, zeitlichem Speicher und konfigurierbarer Konsolidierung.

Mnemosyne ist nicht einer der ursprünglichen Hermes-bündelten Speicher-Provider – es wird als separater Hermes-Provider-Plugin geliefert, integriert aber über dieselbe MemoryProvider-Schnittstelle. Sein Hauptvorteil ist Kontrolle: Konversation-Autosave kann nach Rolle eingeschränkt oder vollständig mit sync_roles: [] deaktiviert werden, Tool-Ergebnis-Protokollierung ist standardmäßig aus, explizite remember/recall/forget-Operationen bleiben unabhängig verfügbar, und neuere Versionen enthalten optionale Self-Echo-Unterdrückung um Kontext-Kompressionsgrenzen.

Externe Abhängigkeiten: Keine für die core-Installation; das embeddings-Extra fügt lokale Vektorsuche hinzu. Speicherung ist lokales SQLite mit FTS5 und optionaler Vektor-Retrieval. Das System unterhält auch Arbeitspeicher, episodischen Speicher, strukturierte Fakten, zeitliche Tripel, kanonische Fakten und Konsolidierung.

Mnemosyne implementiert auch provider-spezifische gestufte Schreibvorgänge für Hermes memory.write_approval, obwohl externe Provider-Genehmigung noch nicht über Hermes standardisiert ist, so dass dieser Pfad gegen die exakt eingesetzten Versionen getestet werden sollte. Die zusätzliche Raffinesse hat einen Preis: abgeleitete Speicher erzeugen mehr Lebenszyklus-Zustände, die inspiziert und aufgeräumt werden müssen. Neueste Mnemosyne-Releases haben speziell Konfliktvalidierung, Löschverhalten und Self-Echo-Verarbeitung verschärft – siehe Selbstverstärkende Speicher-Schleifen in KI-Agenten für die Produktions-Audit, die die Konfliktvalidierungsänderung motivierte.

Setup:

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

Für vollständige Installation und einen konservativen Konfigurations-Durchgang, siehe Mnemosyne für Hermes Agent: Lokaler Speicher Quickstart.

Memori

Ideal für: Agenten, bei denen Ausführungshistorie genauso wichtig ist wie Gesprächshistorie.

Memori ist eine neuere Hermes-Integration, die sich auf Tool-wissendes strukturiertes Speicher konzentriert. Es erfasst abgeschlossene Umkehrungen zusammen mit verfügbarer Ausführungskontext – Tool-Nutzung, Workflow-Schritte, Entscheidungen, Ergebnisse und Einschränkungen – was für das Erinnern von operativer Arbeit hervorragend ist, aber auch eine größere Rückkopplungsfläche schafft, da Aktionen, Modell-Entscheidungen und Tool-Ergebnisse alle zu dauerhaftem strukturierten Speicher werden können.

Im Gegensatz zu Providern, die primär einen großen Speicherblock vor jeder Umkehrung injizieren, stellt Memori explizite Recall- und Recall-Zusammenfassungs-Werkzeuge bereit, sodass der Agent operativen Kontext abrufen kann, wenn er es tatsächlich braucht, statt bei jedem Prompt. Das reduziert Prompt-Verschmutzung, entfernt aber allein nicht das schreibseitige Rückkopplungsrisiko – abgeschlossene Umkehrungen und Ausführungsspuren können weiterhin im Hintergrund automatisch erfasst werden, daher eignet sich Memori besser für Benutzer, die wollen, dass ein Agent aus früheren Arbeiten lernt, als für Installationen, die strenge explizite Retention erfordern.

Setup:

pip install hermes-memori
hermes memory setup  # "memori" auswählen

ByteRover

Ideal für: Lokal-first-Speicher mit menschenlesbarer, überprüfbarer Speicherung.

ByteRover speichert Speicher als strukturierten Markdown-Kontextbaum – eine Hierarchie von Domain-, Themen- und Untertemperaturdateien – statt Embedding-Vektoren oder einer Datenbank. Ein LLM liest Quellinhalt, schlüsselt darüber und platziert extrahiertes Wissen an der richtigen Stelle in der Hierarchie. Retrieval ist MiniSearch-Volltextsuche mit gestufter Fallback zu LLM-gestützter Suche, ohne dass ein Vektordatenbank erforderlich ist.

Externe Abhängigkeiten: ByteRover erfordert ein LLM für Speicher-Kuration und Suche (18 Provider unterstützt, einschließlich Anthropic, OpenAI, Google, Ollama und jeden OpenAI-kompatiblen Endpoint über den openai-compatible-Provider-Slot). Es benötigt kein Embedding-Modell und keine Datenbank – der Kontextbaum ist ein lokales Verzeichnis von reinen Markdown-Dateien. Cloud-Sync ist optional und wird nur für Team-Zusammenarbeit verwendet; alles funktioniert standardmäßig vollständig offline. Für eine vollständig selbstenthaltene lokale Einrichtung, verbinden Sie Ollama als Provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1) und keine Daten verlassen Ihr Gerät.

Hermes bietet auto_extract: false an, um automatische Kurations-Hooks zu deaktivieren, was ByteRover in die Gruppe der Provider einordnet, in denen automatische Erfassung Opt-in statt Standard ist, nahe an Holographic und Mnemosyne.

Werkzeuge: 3 Werkzeuge für Speicheroperationen.

Setup:

hermes memory setup  # "byterover" auswählen

Supermemory

Ideal für: Enterprise-Workflows mit Kontext-Absperrung und Sitzungsgraph-Ingest.

Supermemory bietet Kontext-Absperrung (Isolierung von Speicher nach Kontext) und Sitzungsgraph-Ingest (Import ganzer Gesprächshistorien). Es extrahiert Speicher automatisch, baut Nutzerprofile und führt Hybrid-Retrieval aus, das semantische und Keywordsuche kombiniert. Die verwaltete Cloud-API ist das primäre Deployment-Ziel.

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

Die aktuelle Hermes-Integration schreibt eine volle Sitzung durch Supermemorys Konversations-Endpoint als Einheit, puffert die Konversation und ingested sie am Sitzungs-Ende, Reset oder Kompression. Das produziert reichhaltigeren Entitäts- und Profil-Kontext als isolierte Fakt-Schreibvorgänge, bedeutet aber auch, dass generierter Assistententext Teil des Materials ist, das der Merkmal-Extraktions-Pipeline präsentiert wird, nicht nur von Nutzeräußerungen.

Werkzeuge: 4 Werkzeuge für Speicheroperationen.

Setup:

hermes memory setup  # "supermemory" auswählen

Wie man auswählt

Statt einen globalen Gewinner zu wählen, passen Sie den Provider an die Aufgabe an:

• Einfachster lokaler expliziter Speicher: Holographic — null Abhängigkeiten, auto_extract standardmäßig aus
• Lokaler Speicher mit reichhaltigeren Lebenszyklus-Steuerelementen: Mnemosyne — SQLite, granulare Retention, Self-Echo-Unterdrückung
• Graphen-lastige Synthese: Hindsight — Wissensgraph plus reflect
• Peer- oder Nutzermodellierung: Honcho — dialektische Schlussfolgerung, unified-Modus für konservative Selbstmodellierung
• Dateisystem-artiges Wissen: OpenViking — gestufte viking://-Hierarchie
• Handoff-automatische Extraktion: Mem0 — Konfigurations-freie LLM-basierte Fakt-Extraktion
• Operative/Tool-wissende Speicher: Memori — Turn- und Execution-Trace-Erfassung
• Menschenlesbar, überprüfbar, keine Embedding-Pipeline: ByteRover — reiner Markdown-Kontextbaum
• Enterprise-Kontext-Absperrung: Supermemory — Sitzungsgraph-Ingest, Cloudflare-gehostet
• Hochfrequente Updates, kein Self-Hosting benötigt: RetainDB — Delta-Kompression, dialektisches Selbstmodell

Für vollständige profil-weise Provider-Konfigurationen und reale Workflow-Muster, siehe Hermes Agent Produktions-Setup.

Das breitere Drittanbieter-Hermes-Speicher-Ökosystem

Hermes dokumentiert eine Paket/Plugin-Schnittstelle für externe Speicher-Provider, einschließlich von Benutzern installierter Verzeichnisse und Python-Einstiegs-punkte, sodass das Ökosystem jetzt über die Provider mit vollständigen Abschnitten oben hinausgeht. Ein paar sind es wert, ohne einen vollständigen Abschnitt für jedes zu wissen:

• Scope Recall behandelt SQLite als dauerhafte Wahrheit, während es rohe Konversationserfassung separat scoppt, mit einem optionalen turn-closure-audit-Begleiter für konservative post-turn Überprüfung – es trennt rohe Journal-Evidenz von dauerhaftem semantischem Speicher, anstatt jede erfasste Umkehrung als sofort äquivalentes Langzeitwissen zu behandeln.
• Cognee ist eine Wissensgraph/ECL-Ingest-Pipeline und kein Hermes-Konversationsspeicher-Plugin. Es exceliert bei strukturiertem Projekt- oder institutionellem Speicher, ist aber automatischer als ein expliziter Faktenspeicher; siehe den Self-Hosting Cognee Quickstart und Das richtige LLM für Cognee wählen statt es als Drop-in-Hermes-Provider zu behandeln.
• AgentMemory betont Quellereignisse, Überprüfbarkeit und Löschsemantik – relevant nach den oben diskutierten verwaisten abgeleiteten Rekord-Problemen für Mnemosyne.
• XMemo liefert konservative Standards: Automatische Timeline-Erfassung kann aus bleiben, und Löschung kann eingeschränkt werden. Die Adoption ist noch früh genug, dass sie keinen vollständigen Abschnitt verdient.

Verwandte Leitfäden

• KI-Systeme Speicher-Hub – Umfang dieses Subclusters und Links zu Cognee-Leitfäden
• Selbstverstärkende Speicher-Schleifen in KI-Agenten – warum Erfassungsrichtlinie und Genehmigungsgates wichtig sind, im Detail
• Mnemosyne für Hermes Agent: Lokaler Speicher Quickstart – vollständige Installation und konservative Konfiguration für den oben behandelten Mnemosyne-Provider
• Hermes Agent Speichersystem – Kern-Zwei-Datei-Speicher vor Plugins
• Hermes Agent Produktions-Setup – Profil-Verdrahtung für Provider in der Praxis