Agent-Memory-Anbieter im Vergleich: Capture Policy und Self-Hosting

Aktualisiert im September 2026: Mnemosyne und Memori hinzugefügt, Konfiguration für Honcho und Hindsight erweitert und ein Vergleich der Erfassungsstrategien (Capture Policies) neben der ursprünglichen Infrastruktur-Tabelle hinzugefügt.

Moderne Assistenten vergessen weiterhin alles, sobald Sie den Tab schließen, es sei denn, etwas wird über das Kontextfenster hinaus persistiert. Agent-Memory-Provider sind Dienste oder Bibliotheken, die Fakten und Zusammenfassungen über Sitzungen hinweg speichern — oft als Plugins angebunden, sodass das Framework schlank bleibt, während sich das Gedächtnis skaliert.

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

Für den hermes-spezifischen, begrenzten Kern-Speicher (MEMORY.md und USER.md), das Einfrieren des Verhaltens und Trigger siehe Hermes Agent Memory System. Für Kontext darüber, wie die nativen Memory-Provider von Hermes zu ihrem wachsenden Vorsprung gegenüber OpenClaw beitragen — einschließlich GitHub-Sterne, OpenRouter-Token-Rankings und Größenvergleiche der Ökosysteme — siehe OpenClaw vs Hermes Agent: Stars, Downloads & Usage 2026.

Es gibt einen weiteren Aspekt, der genauso wichtig ist wie die Qualität der Abrufbarkeit (Retrieval): Speichergovernance. Die Provider unterscheiden sich drastisch darin, was sie automatisch erfassen, ob von dem Assistenten erzeugte Ausgaben dauerhaftes Gedächtnis werden können, ob Reflexionen als Fakten gespeichert werden, wie Widersprüche aufgelöst werden und ob ein Mensch einen Schreibvorgang überprüfen kann, bevor er zum zukünftigen Kontext wird. Für langlebige Agenten können diese Unterschiede wichtiger sein als ein paar zusätzliche Punkte auf einem Recall-Benchmark — siehe Self-Reinforcing Memory Loops in AI Agents um zu verstehen, warum automatische Erfassung einen generierten Schluss zu einer zukünftigen Prämisse machen kann, und Mnemosyne for Hermes Agent: Local Memory Quickstart für eine ausgearbeitete konservative Konfiguration.

Hermes Agent listet zehn externe Memory-Provider-Plugins für persistentes, sitzungsübergreifendes Wissen — die ursprünglichen acht plus Mnemosyne und Memori. Nur ein externer Provider kann zur gleichen Zeit aktiv sein. Die eingebauten MEMORY.md und USER.md bleiben daneben geladen — additiv, nicht als Ersatz.

Externe Abhängigkeiten. Jeder externe Provider mit Ausnahme von Holographic erfordert mindestens einen externen Dienstaufruf — ein LLM für die Gedächtnisextraktion, ein Embedding-Modell für die semantische Suche oder eine Datenbank wie PostgreSQL für die Speicherung. Diese Abhängigkeiten haben direkte Auswirkungen auf Privatsphäre, Kosten und darauf, ob Ihr Memory-Stack vollständig selbst gehostet laufen kann. Hindsight, ByteRover und Mnemosyne bündeln die meisten Abhängigkeiten oder eliminieren sie; Honcho, Mem0 und Supermemory erfordern die meisten beweglichen Teile. Wo ein Provider Ollama oder jeden OpenAI-kompatiblen Endpoint unterstützt, können Sie LLM- und Embedding-Aufrufe an ein lokales Modell routen und die 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   # 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, mnemosyne, memori

Provider-Vergleich

Erfassungsstrategie 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 Self-Reinforcing Memory Loops in AI Agents um zu verstehen, warum diese Achse wichtig ist.

Diese sind architektonische Risikokategorien, keine Qualitätspunkte — ein sorgfältig konfigurierter fortschrittlicher Provider kann in der Praxis sicherer sein als ein schlecht konfigurierter einfacher.

Detaillierte Aufschlüsselung

Honcho

Am besten geeignet für: Multi-Agenten-Systeme, sitzungsübergreifender Kontext, Ausrichtung von Benutzer und Agent.

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

Externe Abhängigkeiten: Honcho erfordert ein LLM für Sitzungszusammenfassungen, Ableitung von Benutzervorstellungen und dialektisches Schlussfolgern; ein Embedding-Modell für die semantische Suche über Beobachtungen; PostgreSQL mit der pgvector-Erweiterung für Vektorspeicherung; und Redis für Caching. Die verwaltete Cloud unter api.honcho.dev übernimmt all dies für Sie. Für Self-Hosted-Deployments (Docker, K3s oder Fly.io) stellen Sie Ihre eigenen Anmeldedaten bereit. Der LLM-Slot akzeptiert jeden OpenAI-kompatiblen Endpoint, einschließlich Ollama und vLLM, sodass Inferenz vor Ort 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.

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

Wichtige Konfigurationsregler:

• 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()-Pässe pro Aufruf (auf 1-3 begrenzt)
• recallMode (Standard ‘hybrid’): hybrid (auto+tools), context (nur injizieren), tools (nur tools)
• writeFrequency (Standard ‘async’): Flush-Timing: async, turn, session oder ganze Zahl N
• observationMode (Standard ‘directional’): directional (alle an) oder unified (gemeinsamer Pool)

Beobachtungsmodi und Selbstmodellierung. directional, der Standard für neue Konfigurationen, lässt sowohl das Benutzer- als auch das KI-Peer sich selbst und einander beobachten — reichere dialektische Schlussfolgerungen, aber es bedeutet auch, dass KI-authentifizierte Nachrichten zum Modell von Honcho über die KI selbst beitragen. unified ist die konservativere Option: Die KI modelliert den Benutzer aus Benutzernachrichten, ohne die passende Selbstbeobachtungsschleife aus ihrer eigenen Ausgabe zu bauen. Wer sich speziell Sorgen macht, dass generierte Schlussfolgerungen in zukünftiges Schlussfolgern zurückfließen — siehe Self-Reinforcing Memory Loops in AI Agents — sollte unified als sichereren Standard behandeln.

Architektur: Zweischichtige Kontextinjektion — Basisschicht (Sitzungszusammenfassung + Darstellung + Peer-Karte) + dialektisches Supplement (LLM-Schlussfolgern). Wählt automatisch zwischen Kaltstart- und Warm-Up-Prompts.

Multi-Peer-Mapping: Workspace ist eine geteilte Umgebung über Profile hinweg. Peer des Benutzers (peerName) ist eine globale menschliche Identität. KI-Peer (aiPeer) gibt es ein pro Hermes-Profil (hermes als 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 KI-Peers für bestehende Profile nach

OpenViking

Am besten geeignet für: Self-Hosted-Wissensverwaltung mit strukturiertem Browsen.

OpenViking bietet eine Dateisystem-Hierarchie mit gestuften Ladevorgängen. Es ist kostenlos, selbst gehostet und gibt Ihnen die volle Kontrolle über Ihre Speicherspeicherung.

Externe Abhängigkeiten: OpenViking erfordert ein VLM (Vision-Language-Modell) für semantische Verarbeitung und Gedächtnisextraktion sowie ein Embedding-Modell für 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 ausgelieferte Embedding-Modell. Der interaktive Wizard 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, Zero-API-Key-Konfiguration konfigurieren. Eine externe Datenbank ist nicht erforderlich; OpenViking speichert das Gedächtnis im Dateisystem.

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

Benutzer-Gedächtnis versus Agent-Gedächtnis. Das Identitätsmodell von OpenViking kann den Speichernamensraum des Benutzers von einem optionalen Assistenten-Peer trennen. Diese Trennung ist wichtig für die Speicherhygiene: Fakten über den Benutzer und vom Agenten generierte Erfahrungen müssen nicht dieselbe Retention-Strategie teilen, was eine nützliche Eigenschaft ist, wenn Sie den vom Assistenten erstellten Zustand vom vom Benutzer erstellten Zustand isolieren möchten.

Einrichtung:

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

Mem0

Am besten geeignet für: Gedächtnisverwaltung ohne Eingriffe mit automatischer Extraktion.

Mem0 behandelt die Gedächtnisextraktion 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 alle Infrastrukturen. Die Open-Source-Bibliothek und der Self-Hosted-Server geben Ihnen die volle Kontrolle.

Externe Abhängigkeiten: Mem0 erfordert ein LLM für die Gedächtnisextraktion (Standard: OpenAI gpt-4.1-nano; 20 unterstützte Provider, einschließlich Ollama, vLLM und LM Studio für lokale Modelle) und ein Embedding-Modell für Abrufe (Standard: OpenAI text-embedding-3-small; 10 unterstützte Provider, einschließlich Ollama und HuggingFace für lokale Modelle). Die Speicherung verwendet Qdrant unter /tmp/qdrant im Bibliotheksmodus oder PostgreSQL mit pgvector im Self-Hosted-Servermodus — beide können lokal laufen. Ein vollständig lokaler, Zero-Cloud-Mem0-Stack ist machbar: Ollama für LLM, Ollama für Embeddings und eine lokale Qdrant-Instanz, alle konfiguriert über Memory.from_config.

Mem0 ist im Grunde ein Extraktionssystem: Ein LLM transformiert Konversationsmaterial in diskrete Erinnerungen und führt Deduplizierungs- und Aktualisierungslógica durch. Das ist bequem, aber es bedeutet, dass die Herkunft der Extraktion wichtig ist — ein generierter Assistenten-Schluss kann strukturell nicht unterscheidbar von einer vom Benutzer angegebenen Tatsache werden, es sei denn, der Erfassungspfad filtert ihn heraus, bevor die Extraktion ausgeführt wird.

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 geeignet für: Wissensgraph-basierte Abrufe mit Entity-Beziehungen.

Hindsight baut einen Wissensgraphen aus Ihrem Gedächtnis und extrahiert Entitäten und Beziehungen. Sein einzigartiges reflect-Tool führt eine Cross-Memory-Synthese durch — es kombiniert mehrere Erinnerungen zu neuen Erkenntnissen. Die Abrufe (Recall) führen vier Abrufstrategien parallel aus (semantisch, Schlüsselwort/BM25, Graphen-Traversierung, zeitlich) und fügen dann die Ergebnisse mit reziproker Rang-Fusion zusammen und sortieren sie neu.

Externe Abhängigkeiten: Hindsight erfordert ein LLM für Fakten- und Entity-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). Das Embedding-Modell und das Cross-Encoder-Reranking-Modell sind in Hindsight selbst eingebunden — sie laufen lokal innerhalb des hindsight-all-Pakets und erfordern keine externe API. PostgreSQL ist auch mit der eingebetteten Python-Installation über ein verwaltetes pg0-Datverzeichnis eingebunden; Sie können Hindsight alternativ an eine externe PostgreSQL-Instanz zeigen lassen. Für eine vollständig lokale, Zero-Cloud-Einrichtung setzen Sie HINDSIGHT_API_LLM_PROVIDER=ollama und zeigen Sie 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 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

Für konservative Speicherhygiene ist es zu überdenken, auto_retain=false zu setzen und auto_recall=true zu lassen — die semantische Abrufbarkeit bleibt verfügbar, aber abgeschlossene Runden fließen nicht mehr automatisch in das Langzeitgedächtnis. Behandeln Sie die Ausgabe von reflect als abgeleitetes Wissen, das über Speicher hinweg synthetisiert wird, und nicht als unabhängige Beobachtung mit demselben Beweiswert wie die Speicher, aus denen es gebaut wurde.

Holographic

Am besten geeignet für: privacidad-fokussierte Setups mit ausschließlich lokaler Speicherung.

Holographic verwendet HRR (Holographic Reduced Representation) Algebra für die Speicherung von Gedächtnis, mit Vertrauensbewertung für die Zuverlässigkeit des Gedächtnisses. 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 Speicher-Codierung erfolgt vollständig über die in-Process-laufende HRR-Algebra. Das macht es unter jedem Anbieter in diesem Vergleich einzigartig — es ist der einzige, der mit null externen Aufrufen arbeitet. Der Nachteil ist, dass die Abrufqualität niedriger ist als bei der Embedding-basierten semantischen Suche und es keine Cross-Memory-Synthese wie Hindights reflect gibt. Für Benutzer, für die Privatsphäre und Null-Abhängigkeits-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 Vertrauenspunkten funktionieren kann, anstatt als autonome Transkript-zu-Gedächtnis-Pipeline. Zusammen mit seinen Null-Abhängigkeiten macht es es zu einer der beiden einfachsten Optionen — neben Mnemosyne — für Leser, die bewusst keine automatische Erfassung wollen.

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

Einrichtung:

hermes memory setup  # „holographic" auswählen

RetainDB

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

RetainDB verwendet Delta-Kompression, um Speicher-Updates effizient zu speichern, und hybride Abrufe (Vektor + BM25 + Reranking), um relevanten Kontext an die Oberfläche zu bringen. Es ist Cloud-basiert mit einer Kosten von 20 $/Monat, wobei alle Speicher-Verarbeitungen serverseitig behandelt werden.

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 nur einen RETAINDB_KEY bereit. Die Gedächtnisextraktion verwendet Claude Sonnet serverseitig. Es gibt keine Self-Hosting-Option und keinen lokalen Modus. Alle Konversationsdaten werden an die RetainDB-Server zur Verarbeitung und Speicherung gesendet. Wenn Datensouveränität oder Offline-Betrieb für Ihren Anwendungsfall wichtig ist, 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).

Die Hermes-Integration von RetainDB ist über eine remote Gedächtnisdatenbank hinausgewachsen — sie enthält nun dialektische Synthese und ein Agent-Selbstmodell, was es architektonisch Honcho näher bringt als einem einfachen Vektorspeicher. Das ist nützlich für Kontinuität, erhöht aber auch die Bedeutung, Quellfakten von generierten Interpretationen zu trennen — dieselbe Sorge, die auf Honchos directional-Modus zutrifft.

Einrichtung:

hermes memory setup  # „retaindb" auswählen

Mnemosyne

Am besten geeignet für: Lokal-first-Gedächtnis mit granularer Retention-Kontrolle, inspizierbarer SQLite-Speicherung, strukturierten Fakten, zeitlichem Gedächtnis und konfigurierbarer Konsolidierung.

Mnemosyne ist nicht einer der ursprünglich gebündelten Memory-Provider von Hermes — es wird als separates Hermes-Provider-Plugin ausgeliefert, integriert sich aber über dieselbe MemoryProvider-Schnittstelle. Sein Hauptvorteil ist die Kontrolle: Das automatische Speichern von Konversationen kann nach Rolle eingeschränkt oder vollständig deaktiviert werden mit sync_roles: [], die Protokollierung von Tool-Ergebnissen ist standardmäßig aus, explizite remember/recall/forget-Operationen bleiben unabhängig davon verfügbar, und neuere Versionen enthalten optional Selbst-Echo-Unterdrückung an Kontext-Kompressions-Grenzen.

Externe Abhängigkeiten: Keine für die core-Installation; das embeddings-Extra fügt lokale Vektorsuche hinzu. Die Speicherung ist lokales SQLite mit FTS5 und optionaler Vektorsuche. Das System wartet auch Arbeitsgedächtnis, episodisches Gedächtnis, strukturierte Fakten, zeitliche Tripel, kanonische Fakten und Konsolidierung.

Mnemosyne implementiert auch provider-spezifische gestufte Schreibvorgänge für Hermes memory.write_approval, obwohl die Freigabe externer Provider in Hermes noch nicht standardisiert ist, sodass dieser Pfad gegen die exakten Versionen getestet werden sollte, die deployed werden. Die zusätzliche Raffinesse hat einen Preis: Abgeleitetes Gedächtnis erstellt mehr Lifecycle-Zustände, die inspiziert und bereinigt werden müssen. Kürzliche Mnemosyne-Releases haben spezifisch Validierung von Konflikten, Löschverhalten und Selbst-Echo-Behandlung verstärkt — siehe Self-Reinforcing Memory Loops in AI Agents für die Produktivitäts-Audit, das die Änderung der Konfliktvalidierung motiviert hat.

Einrichtung:

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

Für eine vollständige Installation und einen konservativen Konfigurations-Durchlauf siehe Mnemosyne for Hermes Agent: Local Memory Quickstart.

Memori

Am besten geeignet für: Agenten, bei denen Ausführungsverlauf genauso wichtig ist wie Konversationsverlauf.

Memori ist eine neuere Hermes-Integration, die sich auf tool-aware strukturiertes Gedächtnis konzentriert. Es erfasst abgeschlossene Runden zusammen mit verfügbarem Ausführungskontext — Tool-Nutzung, Workflow-Schritte, Entscheidungen, Ergebnisse und Einschränkungen — was hervorragend für das Erinnern operativer Arbeit ist, aber auch eine größere Feedback-Oberfläche schafft, da Aktionen, Modell-Entscheidungen und Tool-Ergebnisse alle zu dauerhaftem strukturiertem Gedächtnis werden können.

Im Gegensatz zu Providern, die primär einen großen Speicherblock vor jeder Runde injizieren, stellt Memori explizite recall und recall-summary-Tools bereit, die es dem Agenten ermöglichen, operativen Kontext abzurufen, wenn er ihn tatsächlich braucht, und nicht bei jedem Prompt. Das reduziert Prompt-Verschmutzung, beseitigt aber nicht allein das Feedback-Risiko auf der Schreibseite — abgeschlossene Runden und Ausführungsspuren können im Hintergrund weiterhin automatisch erfasst werden, daher eignet sich Memori besser für Benutzer, die einen Agenten wollen, der aus vorheriger Arbeit lernt, als für Installationen, die strikte nur-explizite Retention erfordern.

Einrichtung:

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

ByteRover

Am besten geeignet für: Lokal-first-Gedächtnis mit menschenlesbarer, auditierbarer Speicherung.

ByteRover speichert das Gedächtnis als strukturierten Markdown-Kontextbaum — eine Hierarchie von Domain-, Thema- und Unterthema-Dateien — anstatt Embedding-Vektoren oder eine Datenbank. Ein LLM liest den Quellinhalt, schlussfolgert darüber und platziert extrahiertes Wissen an der richtigen Stelle in der Hierarchie. Die Abrufung ist MiniSearch-Volltextsuche mit gestufter Fallback auf LLM-basierte Suche, ohne dass eine Vektordatenbank erforderlich ist.

Externe Abhängigkeiten: ByteRover erfordert ein LLM für Gedächtniskuratierung und Suche (18 unterstützte Provider, einschließlich Anthropic, OpenAI, Google, Ollama und jeder OpenAI-kompatible Endpoint über den openai-compatible-Provider-Slot). Es erfordert 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-Kollaboration verwendet; alles funktioniert standardmäßig vollständig offline. Für eine vollständig selbst-contained lokale Einrichtung verbinden Sie Ollama als Provider (brv providers connect openai-compatible --base-url http://localhost:11434/v1), und keine Daten verlassen Ihren Computer.

Hermes stellt auto_extract: false bereit, um automatische Kuratierungs-Hooks zu deaktivieren, was ByteRover in die Gruppe der Provider bringt, bei denen automatische Erfassung opt-in ist und nicht der Standard, nahe an Holographic und Mnemosyne.

Tools: 3 Tools für Speicheroperationen.

Einrichtung:

hermes memory setup  # „byterover" auswählen

Supermemory

Am besten geeignet für: Enterprise-Workflows mit Kontext-Zäunen und Session-Graph-Einfuhr.

Supermemory bietet Kontext-Zäune (Isolierung des Gedächtnisses nach Kontext) und Session-Graph-Einfuhr (Import ganzer Konversationsverläufe). Es extrahiert automatisch Erinnerungen, baut Benutzerprofile und führt hybride Abrufe aus, die semantische und Schlüsselwortsuche kombinieren. Die verwaltete Cloud-API ist das primäre Bereitziel.

Externe Abhängigkeiten: Der Cloud-Dienst von Supermemory behandelt alle LLM-Inferenz und Embedding serverseitig — Sie stellen nur einen Supermemory-API-Schlüssel bereit. Self-Hosting ist ausschließlich als Enterprise-Plan-Add-on verfügbar und wird zu 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 Self-Hosting-Pfad — die Architektur ist eng mit Cloudflare Workers Edge-Compute gekoppelt. Für Benutzer, die volle Datensouveränität ohne einen Enterprise-Vertrag benötigen, ist dieser Anbieter die richtige Wahl nicht.

Die aktuelle Hermes-Integration schreibt eine vollständige Session über Supermemorys Konversation-Endpoint als Einheit, puffert die Konversation und führt sie am Sitzungsende, bei Reset oder Kompression ein. Das erzeugt reicheren Entity- und Profile-Kontext als isolierte Fakten-Schreibvorgänge, bedeutet aber auch, dass generierter Assistententext Teil des Materials ist, das der Gedächtnisextraktionspipeline präsentiert wird, und nicht nur Benutzeräußerungen.

Tools: 4 Tools für Speicheroperationen.

Einrichtung:

hermes memory setup  # „supermemory" auswählen

Wie zu wählen

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

• Einfachstes lokales explizites Gedächtnis: Holographic — null Abhängigkeiten, auto_extract standardmäßig aus
• Lokales Gedächtnis mit reichlicheren Lifecycle-Kontrollen: Mnemosyne — SQLite, granulare Retention, Selbst-Echo-Unterdrückung
• Graph-schwere Synthese: Hindsight — Wissensgraph plus reflect
• Peer- oder Benutzermodellierung: Honcho — dialektische Schlussfolgerungen, unified-Modus für konservative Selbstmodellierung
• Dateisystem-Stil Wissen: OpenViking — gestufte viking://-Hierarchie
• Automatische Extraktion ohne Eingriffe: Mem0 — Zero-Config-LLM-basierte Faktenextraktion
• Operatives/Tool-aware Gedächtnis: Memori — Erfassung von Runden und Ausführungsspuren
• Menschenlesbar, auditierbar, keine Embedding-Pipeline: ByteRover — reiner Markdown-Kontextbaum
• Enterprise-Kontext-Zäune: Supermemory — Session-Graph-Einfuhr, Cloudflare-hosted
• Hochfrequenz-Updates, kein Self-Hosting erforderlich: RetainDB — Delta-Kompression, dialektisches Selbstmodell

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

Das breitere Drittanbieter-Hermes-Gedächtnis-Ökosystem

Hermes dokumentiert eine Paket/Plugin-Schnittstelle für externe Memory-Provider, einschließlich benutzerinstallierter Verzeichnisse und Python-Einstiegs punkte, sodass das Ökosystem jetzt über die Provider mit vollständigen Sektionen oben hinausgeht. Einige sind das Kennenwert, ohne für jedes eine vollständige Sektion hinzuzufügen:

• Scope Recall behandelt SQLite als dauerhafte Wahrheit, während es die rohe Konversations-Erfassung getrennt scoped hält, mit einem optionalen turn-closure-audit-Begleiter für konservative Nach-Runden-Prüfung — es trennt rohe Journal-Evidenz von dauerhaftem semantischem Gedächtnis, anstatt jede erfasste Runde als sofort gleichwertiges Langzeitwissen zu behandeln.
• Cognee ist eine Wissensgraph-/ECL-Ingest-Pipeline und kein Hermes-Konversationsgedächtnis-Plugin. Es excelliert bei strukturiertem Projekt- oder Institutionengedächtnis, ist aber automatischer als ein expliziter Faktenspeicher; siehe den Self-Hosting Cognee Quickstart und Choosing the right LLM for Cognee statt es als drop-in Hermes-Provider zu behandeln.
• AgentMemory betont Quellereignisse, Auditierbarkeit und Löschsemantik — relevant nach den isolierten abgeleiteten Datensatz-Problemen, die für Mnemosyne oben diskutiert wurden.
• XMemo liefert konservative Standards: Automatische Zeitlinien-Erfassung kann aus bleiben, und Löschung kann eingeschränkt werden. Die Adoption ist noch früh genug, dass sie noch keine vollständige Sektion rechtfertigt.

Verwandte Leitfäden

• AI Systems Memory hub — Umfang dieses Subclusters und Links zu Cognee-Leitfäden
• Self-Reinforcing Memory Loops in AI Agents — warum Erfassungsstrategie und Freigabe-Schleusen wichtig sind, im Detail
• Mnemosyne for Hermes Agent: Local Memory Quickstart — vollständige Installation und konservative Konfiguration für den oben behandelten Mnemosyne-Provider
• Hermes Agent Memory System — Kern-Zwei-Dateien-Gedächtnis vor Plugins
• Hermes Agent production setup — Profil-Anbindung für Provider in der Praxis