Vergleich von Agent Memory Providern: Erfassungsrichtlinie und Self-Hosting

Die Erfassungspolitik ist nun genauso wichtig wie die Erinnerungsrate.

Inhaltsverzeichnis

Aktualisiert September 2026: Mnemosyne und Memori hinzugefügt, Konfiguration von Honcho und Hindsight erweitert und ein Vergleich der Erfassungsrichtlinien (Capture-Policy) neben der ursprünglichen Infrastruktur-Tabelle hinzugefügt.

Moderne Assistenten vergessen alles, wenn man den Tab schließt, es sei denn, etwas bleibt über das Kontextfenster hinaus erhalten. Speicheranbieter für Agenten sind Dienste oder Bibliotheken, die Fakten und Zusammenfassungen über mehrere Sitzungen hinweg speichern – oft als Plugins integriert, damit das Framework schlank bleibt, während der Speicher 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 breitere KI-Systeme-Stacks eingebunden werden. Dieselben Anbieter erscheinen in OpenClaw und anderen Agenten-Tools über Community- oder offizielle Integrationen. Das KI-Systeme Speicher-Hub listet diesen Artikel neben Cognee und verwandten Leitfäden.

Für Hermes-spezifischen begrenzten Kernspeicher (MEMORY.md und USER.md), Einfrierverhalten und Trigger siehe Hermes Agent Speicher-System. Die Anbindung von Anbietern ist eine Ebene einer breiteren Agenten-Wissenshierarchie – Identitätsdateien, residentespeicher, Fähigkeiten, Wikis und Speicherbanken, jeweils mit ihrem eigenen Injektionstrigger – kartiert in Stufenweiser Kontext: Eine Wissenshierarchie für KI-Agenten. Für Kontext dazu, wie die nativen Speicheranbieter von Hermes zu ihrem wachsenden Verbreitungs Vorteil gegenüber OpenClaw beitragen – einschließlich GitHub-Sterne, OpenRouter-Token-Rankings und Ökosystem-Größenvergleichen – siehe OpenClaw vs Hermes Agent: Sterne, Downloads & Nutzung 2026.

Es gibt eine weitere Achse, die genauso wichtig ist wie die Qualität der Abrufung: Speicherregulierung (Memory Governance). Anbieter unterscheiden sich drastisch darin, was sie automatisch erfassen, ob assistentenerzeugte Ausgaben zu dauerhaftem Speicher werden können, ob Reflexionen als Fakten gespeichert werden, wie Widersprüche aufgelöst werden und ob ein Mensch eine Schreibaktion vor ihrer Verwirklichung als zukünftigen Kontext überprüfen kann. Für Langlauf-Agenten können diese Unterschiede wichtiger sein als ein paar zusätzliche Punkte auf einem Abruf-Benchmark – siehe Selbstverstärkende Speicherschleifen in KI-Agenten für die Erklärung, 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 durchgearbeitete konservative Konfiguration.


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

Externe Abhängigkeiten. Jeder externe Anbieter außer Holographic erfordert mindestens einen externen Dienstruf – ein LLM für Speicheraufbereitung, 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 selbstgehostet 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 Anbieter Ollama oder einen OpenAI-kompatiblen Endpunkt unterstützt, können Sie LLM- und Embedding-Aufrufe an ein lokales Modell leiten und Daten vollständig von Drittanbieter-Servern fernhalten.

KI-Agenten-Speicher-System-Anbieter

Aktivierung mit Hermes Agent

Die folgenden Befehlszeilen-Schritte spiegeln die Tabellen in der Hermes Agent CLI-Spickzettel wider.

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

Anbieter-Vergleich

Anbieter Speicher Kosten Externe Abhängigkeiten Selbst hostbar Einziges Merkmal
Honcho Cloud/Selbst gehostet Bezahlt/Gratis LLM + Embedding-Modell + PostgreSQL/pgvector + Redis Ja – Docker / K3s / Fly.io Dialektische Benutzermodellierung + sitzungsbegrenzter Kontext
OpenViking Selbst gehostet Gratis LLM (VLM) + Embedding-Modell Ja – lokaler Server; Ollama-nativer Init-Assistent Dateisystem-Hierarchie + stufenweises Laden
Mem0 Cloud/Selbst gehostet Bezahlt/Gratis OSS LLM + Embedding-Modell + Vektor-Speicher (Qdrant oder pgvector) Ja – Docker Compose OSS; vollständig lokal möglich Serverseitige LLM-Aufbereitung
Hindsight Cloud/Lokal Gratis/Bezahlt LLM + gebündeltes PostgreSQL + eingebauter Embedder + eingebauter Reranker Ja – Docker oder eingebettetes Python; vollständig lokal mit Ollama Wissensgraph + reflect-Synthese
Holographic Lokal Gratis Keine Nativ – keine Infrastruktur erforderlich HRR-Algebra + Vertrauenswertung
RetainDB Cloud 20 USD/Monat Cloud-verwaltet (LLM + Retrieval auf RetainDB-Servern) Nein Delta-Kompression + dialektisches Selbstmodell
ByteRover Lokal/Cloud Gratis/Bezahlt Nur LLM – kein Embedding-Modell, keine DB Ja – standardmäßig lokal-zentriert; Ollama-Unterstützung Dateibasierter Kontextbaum; keine Embedding-Pipeline
Supermemory Cloud Bezahlt LLM + PostgreSQL/pgvector (Enterprise-Cloudflare-Deployment) Nur Enterprise-Plan Kontextzaun + Sitzungsgraph-Import
Mnemosyne Lokal (SQLite) Gratis Nur LLM für zusätzliche Embeddings; keine für core Ja – standardmäßig vollständig lokal Granulare Retentionskontrollen + lokaler FTS5/Vektor-Store
Memori Cloud/Selbst gehostet Bezahlt/Gratis LLM für Aufbereitung; Ausführungs-Trace-Erfassung Teilweise Rundengrab + Tool-/Workflow-Trace-Erfassung

Erfassungsrichtlinie und Regulierung

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

Anbieter Automatische Erfassung Abgeleitete Schlussfolgerung Nur-expliziter Modus Freigabestützung
Holographic Standardmäßig aus Gering Ja Keine Anbieter-Warteschlange
Mnemosyne Konfigurierbar (sync_roles) Fakten + Konsolidierung Ja Anbieterspezifisches Staging
ByteRover Konfigurierbar (auto_extract) Kuratierung Ja Nein
Hindsight Standardmäßig an (autoRetain) reflect-Synthese Ja (auto_retain: false) Nein
Mem0 Automatische Aufbereitung Fakten-Aufbereitung Begrenzt Nein
OpenViking Automatische Aufbereitung Stufenweise Zusammenfassungen Teilweise Nein
Supermemory Volle Sitzungserfassung Profil/Graph Teilweise Nein
Memori Runden- + Trace-Erfassung Strukturierte Abrufung Begrenzt Nein
Honcho Nachrichten-/Peer-Beobachtung (directional) Dialektische Modellierung Konfigurierbar (unified-Modus) Nein
RetainDB Reiche Erfassung Dialektik + Selbstmodell Begrenzt Nein

Dies sind architektonische Risikokategorien, keine Qualitätspunkte – ein sorgfältig konfigurierter, fortschrittlicher Anbieter kann in der Praxis sicherer sein als ein schlecht konfigurierter einfacher.

Detaillierte Aufschlüsselung

Honcho

Am besten 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 Kontextebene hinzu. Es modelliert Gespräche als Peers, die Nachrichten austauschen – ein Benutzer-Peer plus ein KI-Peer pro Hermes-Profil, alle teilen sich eine Arbeitsumgebung.

Externe Abhängigkeiten: Honcho erfordert ein LLM für Sitzungs-Zusammenfassung, Ableitung der Benutzerauftritte und dialektische Schlussfolgerung; ein Embedding-Modell für semantische Suche über Beobachtungen; PostgreSQL mit der pgvector-Erweiterung für Vektorspeicher; und Redis für Caching. Die verwaltete Cloud unter api.honcho.dev übernimmt all dies für Sie. Für selbstgehostete Deployments (Docker, K3s oder Fly.io) stellen Sie eigene Zugangsdaten bereit. Der LLM-Slot akzeptiert jeden OpenAI-kompatiblen Endpunkt, einschließlich Ollama und vLLM, sodass Inferenz vor Ort bleiben kann. Der Embedding-Slot standardmäßig 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.

Werkzeuge: honcho_profile (Peer-Karte lesen/aktualisieren), honcho_search (semantische Suche), honcho_context (Sitzungskontext – Zusammenfassung, Auftritte, Karte, Nachrichten), honcho_reasoning (LLM-synthese), honcho_conclude (Schlüsse erstellen/löschen).

Wichtige Konfigurationsknoobs:

  • contextCadence (Standard 1): Mindestanzahl an Runden zwischen Basis-Ebenen-Aktualisierung
  • dialecticCadence (Standard 2): Mindestanzahl an 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+Werkzeuge), context (nur Injektion), tools (nur Werkzeuge)
  • writeFrequency (Standard ‘async’): Flush-Timing: async, turn, session oder ganzzahliges N
  • observationMode (Standard ‘directional’): directional (alle an) oder unified (gemeinsamer Pool)

Beobachtungsmodi und Selbstmodellierung. directional, der Standard für frische Konfigurationen, lässt es sowohl den Benutzer- als auch den KI-Peers zu, sich selbst und gegenseitig zu beobachten – reichere dialektische Schlussfolgerung, aber es bedeutet auch, dass KI-autorensierte Nachrichten zum Honcho-Modell der KI selbst beitragen. unified ist die konservativere Option: Die KI modelliert den Benutzer aus Benutzernachrichten, ohne die entsprechende Selbstbeobachtungsschleife aus ihrer eigenen Ausgabe zu bauen. Jemand, der speziell besorgt ist über generierte Schlüsse, die in zukünftige Schlussfolgerungen zurückfließen – siehe Selbstverstärkende Speicherschleifen in KI-Agenten – sollte unified als den sichereren Standard behandeln.

Architektur: Zweischichtiger Kontexteinspritzung – Basisebene (Sitzungs-Zusammenfassung + Auftritte + Peer-Karte) + dialektische Ergänzung (LLM-Schlussfolgerung). Wählt automatisch Cold-Start- vs Warm-Start-Prompts.

Multi-Peer-Zuordnung: Die Arbeitsumgebung ist eine geteilte Umgebung über Profile hinweg. Das Benutzer-Peer (peerName) ist eine globale menschliche Identität. Das KI-Peer (aiPeer) ist pro Hermes-Profil eines (hermes standardmäßig, hermes.<profil> für andere).

Einrichtung:

hermes memory setup  # "honcho" auswählen
# 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 geteilter Arbeitsumgebung
hermes honcho sync                   # Befüllt KI-Peers für bestehende Profile

OpenViking

Am besten für: Selbst gehostetes Wissensmanagement mit strukturiertem Stöbern.

OpenViking bietet eine Dateisystem-Hierarchie mit stufenweisem Laden. Es ist gratis, selbstgehostet, und gibt Ihnen die volle Kontrolle über Ihren Speicherspeicher.

Externe Abhängigkeiten: OpenViking erfordert ein VLM (Visionssprachmodell) für semantische Verarbeitung und Speicheraufbereitung, und ein Embedding-Modell für Vektorsuche – beide sind Pflicht. Unterstützte VLM-Anbieter umfassen OpenAI, Anthropic, DeepSeek, Gemini, Moonshot und vLLM (für lokale Installation). Für Embeddings umfassen unterstützte 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 für eine vollständig lokale, API-key-freie Einrichtung konfigurieren. Keine externe Datenbank erforderlich; OpenViking speichert den Speicher im Dateisystem.

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

Benutzerspeicher gegenüber Agentenspeicher. Das Identitätsmodell von OpenViking kann den Speicher-Namespace des Benutzers von einem optionalen Assistenten-Peer trennen. Diese Trennung ist für die Speicherhygiene wichtig: Fakten über den Benutzer und vom Agenten generierte Erfahrungen müssen nicht dieselbe Retentionsrichtlinie teilen, was eine nützliche Eigenschaft ist, wenn Sie zustand von Assistenten und Benutzer trennen möchten.

Einrichtung:

pip install openviking
openviking-server init   # interaktiver Assistent (empfiehlt 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 für: Pflegeleichtes Speicher-Management mit automatische Aufbereitung.

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

Externe Abhängigkeiten: Mem0 erfordert ein LLM für Speicheraufbereitung (Standard: OpenAI gpt-4.1-nano; 20 unterstützte Anbieter, 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 unterstützte Anbieter, einschließlich Ollama und HuggingFace für lokale Modelle). Der Speicher 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, alle konfiguriert über Memory.from_config.

Mem0 ist grundsätzlich ein Aufbereitungssystem: Ein LLM verwandelt Gesprächsmaterial in diskrete Erinnerungen und führt Deduplizierung und Update-Logik durch. Das ist bequem, aber es bedeutet, dass der Ursprung der Aufbereitung wichtig ist – ein generierter Assistentenschluss kann strukturell von einer benutzergenannten Tatsache nicht zu unterscheiden sein, es sei denn, der Erfassungspfad filtert ihn heraus, bevor die Aufbereitung läuft.

Werkzeuge: mem0_profile, mem0_search, mem0_conclude.

Einrichtung:

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

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

Hindsight

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

Hindsight baut einen Wissensgraphen Ihres Speichers, indem es Entitäten und Beziehungen extrahiert. Sein einzigartiges reflect-Werkzeug führt Synthese über mehrere Erinnerungen hinweg durch – kombiniert multiple Erinnerungen zu neuen Erkenntnissen. Das Abrufen führt vier Suchstrategien parallel aus (semantisch, Schlüsselwort/BM25, Graph-Traversierung, zeitlich), kombiniert und sortiert dann Ergebnisse neu, umgekehrt-rang-fusion.

Externe Abhängigkeiten: Hindsight erfordert ein LLM für Fakten- und Entitätsaufbereitung bei retain-Aufrufen und für Synthese bei reflect-Aufrufen (Standard: OpenAI; unterstützte Anbieter umfassen Anthropic, Gemini, Groq, Ollama, LM Studio und jeden OpenAI-kompatiblen Endpunkt). Embeddings und Reranking standardmäßig auf In-Prozess-lokale Modelle (SentenceTransformers; das dicke Docker/hindsight-all-Image bündelt BGE + MiniLM), und Sie können diese gegen andere lokale Modelle oder einen externen OpenAI-kompatiblen / TEI-Endpunkt austauschen – zum Beispiel Qwen3-Embedding-0.6B und BGE-reranker-v2-m3 auf CPU. PostgreSQL ist über ein verwaltetes 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 Mehr-erinnerungen-Synthese).

Einrichtung:

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

Der Cloud-Modus akzeptiert weiterhin einen API-Schlüssel in ~/.hermes/.env. Die selbstgehostete Installation verwendet Docker Compose gegen eingebettetes oder bestehendes PostgreSQL – siehe den unten verlinkten Walk-Through. Erfordert ein aktuelles Hindsight-Client/API-Paar (Plug-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 selbstgehosteten Walk-Through – Docker Compose, lokale Embeddings und Reranking, Schreibpfad-Kontrolle (auto_retain) und Hermes local_external-Verdrahtung – siehe Hindsight für Hermes Agent: Selbst gehosteter Speicher mit lokalen LLMs. OpenCode, die Cursor-CLI und die anderen Codier-Harnesses verwenden ein anderes Paket, mit einer Bank pro Repository: Hindsight-Speicher für OpenCode, Cursor und andere Codier-Agenten.

Für konservative Speicherhygiene ist es lohnenswert, auto_retain=false zu setzen und auto_recall=true zu lassen – semantischer Abruf bleibt verfügbar, aber abgeschlossene Runden treten nicht mehr automatisch in den Langzeitspeicher ein. Behandeln Sie reflect-Ausgabe als abgeleitetes Wissen, das über Erinnerungen hinweg synthetisiert wird, nicht als unabhängige Beobachtung mit demselben Beweisgewicht wie die Erinnerungen, aus denen sie aufgebaut wurde.

Holographic

Am besten für: Datenschutz-betonte Setups mit nur lokalem Speicher.

Holographic verwendet HRR (Holographische Reduzierte Repräsentation) Algebra für Kodierung von Speicher, mit Vertrauenswertung für Speicherzuverlä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 im Prozess läuft. Dies macht es einzigartig unter jedem Anbieter in diesem Vergleich – es ist der einzige, der mit null externen Aufrufen funktioniert. Der Kompromiss ist, dass die Abrufqualität geringer ist als bei Embedding-basierter semantischer Suche, und es gibt keine Mehr-erinnerungen-Synthese wie Hindsight reflect. Für Benutzer, für die Datenschutz und null-Abhängigkeitsbetrieb verhandelungsunfähig sind, ist Holographic die einzige Option, die dies bedingungslos liefert.

auto_extract standardmäßig auf false, so dass Holographic primär als kleine explizite Fakten-Datenbank mit Vertrauenswerten funktionieren kann, anstelle einer autonomen Transkript-zu-Speicher-Pipeline. Kombiniert mit seinen null Abhängigkeiten macht es es eine der beiden einfachsten Optionen – neben Mnemosyne – für Leser, die absichtlich keine automatische Erfassung wollen.

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

Einrichtung:

hermes memory setup  # "holographic" auswählen

RetainDB

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

RetainDB verwendet Delta-Kompression, um Speicher-Updates effizient zu speichern, und Hybrid-Retrieval (Vektor + BM25 + Reranking), um relevanten Kontext sichtbar zu machen. Es ist Cloud-basiert mit einer Kosten von 20 USD/Monat, wobei die gesamte Speicherverarbeitung serverseitig durchgeführt wird.

Externe Abhängigkeiten: Die LLM-Aufrufe, die Embedding-Pipeline und das Reranking von RetainDB laufen alle auf RetainDBs eigener Cloud-Infrastruktur – Sie stellen nur einen RETAINDB_KEY bereit. Die Speicheraufbereitung verwendet Claude Sonnet serverseitig. Es gibt keine Selbsthosting-Option und keinen lokalen Modus. Alle Gesprächsdaten werden an RetainDB-Server für Verarbeitung und Speicherung gesendet. Wenn Daten-Souveränität oder Offline-Betrieb für Ihren Fall wichtig ist, ist dieser Anbieter nicht geeignet.

Werkzeuge: retaindb_profile (Benutzerprofil), retaindb_search (semantische Suche), retaindb_context (aufgabenrelevanter Kontext), retaindb_remember (speichern mit Typ + Wichtigkeit), retaindb_forget (Erinnerungen löschen).

Die Hermes-Integration von RetainDB ist über eine Fern-Speicher-Datenbank hinausgewachsen – sie enthält jetzt dialektische Synthese und ein Agenten-Selbstmodell, was es architektonisch Honcho näher als einem einfachen Vektor-Speicher bringt. Das ist nützlich für Kontinuität, erhöht aber auch die Wichtigkeit, Quell-Fakten von generierten Interpretationen zu trennen, dieselbe Bedenken, die sich auf Honchos directional-Modus beziehen.

Einrichtung:

hermes memory setup  # "retaindb" auswählen

Mnemosyne

Am besten für: Lokal-zentrierter Speicher mit granularer Retentionskontrolle, inspizierbarem SQLite-Speicher, strukturierten Fakten, zeitlichem Speicher und konfigurierbarer Konsolidierung.

Mnemosyne ist einer der ursprünglichen Hermes-gebündelten Speicheranbieter – es wird als separates Hermes-Anbieter-Plugin ausgeliefert, integriert sich aber über die gleiche MemoryProvider-Schnittstelle. Sein Hauptvorteil ist Kontrolle: Die Konversations-Auto-Speicherung kann nach Rolle eingeschränkt oder vollständig deaktiviert werden mit sync_roles: [], die Tool-Ergebnis-Logik ist standardmäßig aus, explizite remember/recall/forget-Operationen bleiben unabhängig davon verfügbar, und neuere Versionen umfassen optionale Selbst-Echo-Unterdrückung um Kontext-Kompressionsgrenzen.

Externe Abhängigkeiten: Keine für die core-Installation; das embeddings-Zusatzpaket fügt lokale Vektorsuche hinzu. Der Speicher ist lokaler SQLite mit FTS5 und optionaler Vektorsuche. Das System wartet auch Arbeitsspeicher, episodischer Speicher, strukturierte Fakten, zeitliche Tripel, kanonische Fakten und Konsolidierung.

Mnemosyne implementiert auch anbieterspezifische gestufte Schreibungen für Hermes memory.write_approval, obwohl Freigaben für externe Anbieter noch nicht standardisiert sind über Hermes, daher sollte dieser Pfad gegen die genauen Versionen getestet werden, die deployed werden. Die zusätzliche Raffinesse hat einen Preis: abgeleiteter Speicher erstellt mehr Lebenszyklus-Zustände, die inspiziert und aufgeräumt werden müssen. Jüngere Mnemosyne-Releases haben die Konfliktvalidierung, das Löschverhalten und die Selbst-Echo-Verarbeitung speziell verschärft – siehe Selbstverstärkende Speicherschleifen in KI-Agenten für die Produktions-Audit, die die Konfliktvalidierungsänderung motiviert hat.

Einrichtung:

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

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

Memori

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

Memori ist eine neuere Hermes-Integration, die sich auf tool-sensibles strukturiertes Speicher 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 von operativer Arbeit ist, aber auch eine größere Feedback-Oberfläche schafft, da Aktionen, Modell-Entscheidungen und Tool-Ergebnisse alle zu dauerhaftem strukturiertem Speicher werden können.

Im Gegensatz zu Anbietern, die primär einen großen Speicherblock vor jeder Runde einspritzen, stellt Memori explizite recall und recall-summary-Werkzeuge bereit, die es dem Agenten erlauben, operationellen Kontext abzurufen, wenn er ihn tatsächlich braucht, anstelle bei jedem Prompt. Das reduziert Prompt-Polymorphie, entfernt aber nicht allein das Schreiben-Feedback-Risiko – abgeschlossene Runden und Ausführungstraces können weiterhin automatisch im Hintergrund erfasst werden, daher passt Memori besser für Benutzer, die einen Agenten wollen, der aus vorheriger Arbeit lernt, als für Installationen, die strikte explizit-only-Retention erfordern.

Einrichtung:

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

ByteRover

Am besten für: Lokal-zentrierter Speicher mit menschenlesbarem, überprüfbarem Speicher.

ByteRover speichert den Speicher als strukturierten MarkDown-Kontextbaum – eine Hierarchie von Domain-, Themen- und Unterthemen-Dateien – anstelle von Embedding-Vektoren oder einer Datenbank. Ein LLM liest Quellinhalt, denkt darüber nach und platziert extrahiertes Wissen an den richtigen Ort in der Hierarchie. Das Abrufen ist MiniSearch-Volltextsuche mit stufenweiser Rückfall auf LLM-gestützte Suche, ohne Vektordatenbank erforderlich.

Externe Abhängigkeiten: ByteRover erfordert ein LLM für Speicherkuratie und Suche (18 unterstützte Anbieter, 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-Synchronisation ist optional und wird nur für Team-Kollaboration verwendet; alles funktioniert standardmäßig vollständig offline. Für eine vollständig eigenständige lokale Einrichtung, verbinden Sie Ollama als Anbieter (brv providers connect openai-compatible --base-url http://localhost:11434/v1) und keine Daten verlassen Ihre Maschine.

Hermes stellt auto_extract: false bereit, um automatische Kuratie-Hooks zu deaktivieren, was ByteRover in die Nähe von Holographic und Mnemosyne bringt in der Gruppe von Anbietern, bei denen automatische Erfassung optional ist und nicht Standard.

Werkzeuge: 3 Werkzeuge für Speicheroperationen.

Einrichtung:

hermes memory setup  # "byterover" auswählen

Supermemory

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

Supermemory bietet Kontextzaun (Trennung von Speicher nach Kontext) und Sitzungsgraph-Import (Import ganzer Gesprächshistorien). Es extrahiert automatisch Erinnerungen, baut Benutzerprofile auf und führt Hybrid-Retrieval durch, das semantische und Schlüsselwort-Suche kombiniert. Die verwaltete Cloud-API ist das primäre Deployment-Ziel.

Externe Abhängigkeiten: Der Cloud-Dienst von Supermemory ü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 deployed auf Cloudflare Workers; es erfordert, dass Sie PostgreSQL mit der pgvector-Erweiterung bereitstellen (für Vektorspeicher) und einen OpenAI-API-Schlüssel (Pflicht, mit Anthropic und Gemini als optionale Zusätze). Es gibt keinen Docker-basierten oder lokalen Selbsthosting-Pfad – die Architektur ist eng an Cloudflare-Workers-Edge-Compute gekoppelt. Für Benutzer, die volle Daten-Souveränität ohne Enterprise-Vertrag benötigen, ist dieser Anbieter nicht die richtige Wahl.

Die aktuelle Hermes-Integration schreibt eine volle Sitzung über Supermemorys Konversations-Endpunkt als Einheit, puffert das Gespräch und importiert es am Sitzungsende, Reset oder Komprimierung. Das erzeugt reicheren Entitäts- und Profil-Kontext als isolierte Fakten-Schreiben, aber es bedeutet auch, dass generierter Assistententext Teil des Materials ist, das an die Speicheraufbereitung-Pipeline übergeben wird, nicht nur Benutzeraussagen.

Werkzeuge: 4 Werkzeuge für Speicheroperationen.

Einrichtung:

hermes memory setup  # "supermemory" auswählen

Wie Sie wählen

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

  • Einfachster lokaler expliziter Speicher: Holographic – null Abhängigkeiten, auto_extract standardmäßig aus
  • Lokaler Speicher mit reicheren Lebenszyklus-Kontrollen: Mnemosyne – SQLite, granulare Retention, Selbst-Echo-Unterdrückung
  • Graph-lastige Synthese: Hindsight – Wissensgraph plus reflect
  • Peer- oder Benutzermodellierung: Honcho – dialektische Schlussfolgerung, unified-Modus für konservative Selbstmodellierung
  • Dateisystem-Stil-Wissen: OpenViking – stufenweiser viking://-Hierarchie
  • Pflegeleichte automatische Aufbereitung: Mem0 – Zero-Config-LLM-basierte Fakten-Aufbereitung
  • Operationelle/Tool-sensible Speicher: Memori – Runden- und Ausführungstrace-Erfassung
  • Menschenlesbar, überprüfbar, keine Embedding-Pipeline: ByteRover – einfacher MarkDown-Kontextbaum
  • Enterprise-Kontextzaun: Supermemory – Sitzungsgraph-Import, Cloudflare-gehostet
  • Hochfrequenz-Updates, kein Selbsthosting erforderlich: RetainDB – Delta-Kompression, dialektisches Selbstmodell

Für vollständige Profil-für-Profil-Anbieter-Konfigurationen und realitätsnahe Workflow-Muster, siehe Hermes Agent Produktions-Einrichtung.

Das breitere Drittanbieter-Hermes-Speicher-Ökosystem

Hermes dokumentiert eine Paket/Plugin-Schnittstelle für externe Speicheranbieter, einschließlich benutzerinstallierte Verzeichnisse und Python-Einstiegspunkte, sodass das Ökosystem nun über die Anbieter mit vollständigen Abschnitten oben hinausgeht. Einige sind es wert, ohne einen vollständigen Abschnitt für jeden hinzuzufügen:

  • Scope Recall behandelt SQLite als dauerhafte Wahrheit, während die rohe Gesprächserfassung separat begrenzt bleibt, mit einem optionalen turn-closure-audit-Begleiter für konservative Nach-Runden-Prüfung – es trennt rohe Journal-Beweise von dauerhaftem semantischen Speicher, anstatt jede erfasste Runde als unmittelbar äquivalente Langzeit-Wissens zu behandeln.
  • Cognee ist eine Wissensgraphen-/ECL-Erfassungspipeline anstelle eines Hermes-Konversationspeicher-Plugins. Es excellt bei strukturiertem Projekt- oder Institutionalspeicher, ist aber automatischer als ein expliziter Fakten-Store; siehe der Cognee-Selbsthosting-Quickstart und Das richtige LLM für Cognee wählen anstelle es als Drop-in-Hermes-Anbieter zu behandeln.
  • AgentMemory betont Quellereignisse, Überprüfbarkeit und Lösch-Semantik – relevant nach den isolierten abgeleiteten Datensatz-Problemen, die oben für Mnemosyne diskutiert wurden.
  • XMemo liefert konservative Standards: automatische Zeitlinien-Erfassung kann aus bleiben, und Löschung kann eingeschränkt werden. Die Verbreitung ist noch früh genug, dass es noch keinen vollständigen Abschnitt verdient.

Verwandte Leitfäden

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.