Hermes-Agent-Speichersystem: Wie persistentes KI-Speichern tatsächlich funktioniert

Sie kennen das Prinzip. Sie öffnen einen Chat mit einem KI-Agenten, erklären Ihr Projekt, teilen Ihre Präferenzen, lassen Arbeiten erledigen und schließen den Tab. Wenn Sie in der folgenden Woche zurückkehren, ist es, als würden Sie mit einem Fremden sprechen – der gesamte Kontext ist verschwunden, jede Präferenz vergessen, das Projekt muss von Grund auf neu erklärt werden.

Dies ist kein Fehler. So funktionieren Large Language Models (LLMs) absichtlich. Sie sind zustandslos: Jede Anfrage ist unabhängig, jede Antwort wird basierend auf dem Prompt generiert, den Sie gerade senden, ohne Gedächtnis, ohne Historie und ohne Kontinuität jenseits der Tokens im aktuellen Kontextfenster.

Für Einweg-Interaktionen ist das in Ordnung. Eine Frage stellen, eine Antwort erhalten, weiterziehen. Aber für Agenten – Systeme, die Dinge über Sitzungen hinweg tun, aus Fehlern lernen und sich mit Ihnen weiterentwickeln sollen – ist Zustandslosigkeit eine harte architektonische Grenze. Es ist eines der zentralen ungelösten Probleme in selbstgehosteten KI-Systemen.

Die Industrie hat versucht, dies zu lösen. LangChain fügte Speichermodule hinzu. OpenAI führte Assistenten mit Threads ein. Frameworks wie Letta, Zep und Cognee bauten gesamte Architekturen um persistierendes Gedächtnis auf. Databricks veröffentlichte Studien zur „Memory Scaling“ – der Idee, dass die Leistung von Agenten mit gesammelter Erfahrung verbessert. Seit 2024 sind dedizierte Benchmark-Papier, Episoden-Gedächtnis-Übersichten und ein schnell wachsendes Ökosystem von Tools entstanden, um das zu adressieren, was zunehmend als eines der zentralen ungelösten Probleme im agentic AI anerkannt wird.

Die meisten dieser Ansätze teilen ein gemeinsames Problem: Sie behandeln das Gedächtnis als nachträglichen Gedanken – eine Datenbank, die abgefragt wird, ein Kontextfenster, das gestopft wird, ein Abrufsystem, das Latenz und Rauschen hinzufügt, anstatt Klarheit zu schaffen.

Hermes Agent verfolgt einen grundlegend anderen Ansatz. Gedächtnis ist etwas, das der Agent nicht nur abrufen kann, wenn es benötigt wird. Es ist etwas, das der Agent zu jeder Zeit ist – in den System-Prompt integriert, kuratiert, begrenzt und immer aktiv. Es ist klein genug, um schnell zu sein, strukturiert genug, um nützlich zu sein, und diszipliniert genug, um zu wissen, was vergessen werden soll.

Dieser Artikel erklärt genau, wie das funktioniert.

Teil 1: Das KI-Agenten-Gedächtnisproblem

Warum „Einfach Kontext hinzufügen“ für Agenten nicht skaliert

Die offensichtliche Lösung für zustandslose KI ist das Hinzufügen von Kontext. Die vorherige Konversation anhängen. Die Projektdokumentation einschließen. Den gesamten Verlauf senden.

Eine Weile funktioniert das. Sie haben ein Kontextfenster von 128K. Da passt viel Text hinein.

Aber Kontext ist nicht Gedächtnis – es gibt einen echten und wichtigen Unterschied zwischen ihnen. Kontext ist alles, was Ihnen gerade gezeigt wird; Gedächtnis ist das, was Sie aktiv behalten und weitertragen.

Kontext hat keine Kuratierung. Es ist ein Dump: Je größer er wird, desto mehr Tokens irrelevanter Historie muss das Modell verarbeiten, um die eine Tatsache zu finden, die es benötigt. Das kostet Tokens und Geld, erhöht die Latenz und stößt schließlich an die Obergrenze.

Gedächtnis ist kuratiert. Es ist die Destillation von Erfahrung in etwas Kompaktes und Umsetzbares. Es wächst nicht unendlich – es konsolidiert, aktualisiert und vergisst.

Das menschliche Gedächtnis funktioniert auf die gleiche Weise. Sie erinnern sich nicht an jede Unterhaltung, die Sie je geführt haben. Sie erinnern sich an die Teile, die wichtig sind: Wessen Sie sprechen, worauf es ihnen ankommt, worauf Sie sich geeinigt haben, was Sie gelernt haben. Der Rest wird entweder vergessen oder ist bei Bedarf durchsuchbar.

Die Forschungslandschaft

Der Bereich der KI-Agenten-Gedächtnisse ist seit 2024 explodiert, mit dedizierten Benchmark-Suites, einer wachsenden Forschungsliteratur und einer messbaren Leistungslücke zwischen verschiedenen architektonischen Ansätzen. Hier ist der aktuelle Stand.

Letta (ehemals MemGPT) war eines der ersten Frameworks, das persistierendes Gedächtnis als Erstklass-Thema behandelte und 21.700 GitHub-Sterne erreichte. Es verwendet ein OS-inspiriertes Drei-Stufen-Modell: Kerngedächtnis (klein, immer im Kontext), Erinnerungs-Gedächtnis (durchsuchbare Konversationshistorie) und Archiv-Gedächtnis (langfristiger Kaltlagerung). Die Erkenntnis, dass nicht alles Gedächtnis gleich ist, war korrekt. Die Implementierung erfordert jedoch, dass Agenten vollständig innerhalb des Letta-Runtimes laufen – die Adoption bedeutet, die ganze Plattform zu übernehmen, nicht nur eine Speicher-Ebene.

Zep / Graphiti konzentriert sich auf Konversationsgedächtnis mit zeitlicher Entitätsverfolgung – Fakten haben Gültigkeitsfenster, damit der Graph weiß, wann etwas wahr war. Es ist stark für Chatbots, die Beziehungsgraphen benötigen, weniger geeignet für autonome Agenten, die Umweltfakten und Projekt-Konventionen verfolgen.

Cognee ist für die Wissensextraktion aus Dokumenten und strukturierten Daten gebaut, mit 30+ Ingestions-Connectoren und einem Knowledge-Graph-Backend. Es excelt bei institutionellem Wissen und RAG-Pipelines, ist aber weniger auf persönliches Agenten-Gedächtnis fokussiert. Siehe Cognee mit lokalen LLMs selbst hosten für eine praktische Einrichtung.

Hindsight bietet wissensgraphenbasierte Recall mit Entitätsbeziehungen und einem einzigartigen reflect-Synthesewerkzeug, das Cross-Memory-Synthese durchführt – das Kombinieren mehrerer Erinnerungen zu neuen Erkenntnissen. Es gehört zu den Top-Performern bei Agenten-Gedächtnis-Benchmarks und ist als Speicheranbieter für Hermes Agent verfügbar.

Mem0 handhabt die Gedächtnisextraktion serverseitig über LLM-Analyse und erfordert minimale Konfiguration. Das Mem0-Forschungspapier, veröffentlicht bei ECAI 2025 (arXiv:2504.19413), benchmarkte zehn verschiedene Ansätze zur KI-Gedächtnis und validierte den selektiven Extraktionsansatz – diskrete Fakten speichern, deduplizieren und nur das Abrufen, was relevant ist. Mem0 ist auf etwa 48.000 GitHub-Sterne gewachsen und unterstützt 21 Framework-Integrationen. Der Trade-off ist Cloud-Abhängigkeit und Kosten.

Databricks’ Memory-Scaling-Forschung führte das Konzept ein, dass die Agentenleistung mit gesammelter Erfahrung verbessert wird. Ihre Architektur hält System-Prompts, Unternehmensassets und episodische/semantische Erinnerungen, die auf Organisations- und Benutzerebene skaliert sind, und validiert die Idee, dass Gedächtnisqualität genauso wichtig ist wie Modellfähigkeit.

Der gemeinsame Nenner der meisten Frameworks ist, dass sie Gedächtnis als Abrufproblem behandeln: Es irgendwo speichern, bei Bedarf abfragen, in den Kontext injizieren. Hermes macht das Gegenteil – Gedächtnis wird nicht auf Abruf geholt, es wird bei Sitzungsstart injiziert und ist immer vorhanden. Immer aktiv, immer verfügbar, kuratiert genug, um nützlich zu bleiben.

Teil 2: Architektur – Zwei Dateien, Ein Gehirn

Das integrierte Gedächtnissystem von Hermes Agent lebt in zwei Dateien.

• ~/.hermes/memories/MEMORY.md – Persönliche Notizen des Agenten (2.200 Zeichen, ~800 Tokens)
• ~/.hermes/memories/USER.md – Benutzerprofil (1.375 Zeichen, ~500 Tokens)

Das ist die gesamte persistente Gedächtnisoberfläche: zwei Dateien, weniger als 3.600 Zeichen insgesamt, weniger als 1.300 Tokens. Es sieht bewusst klein aus, weil es ist – und genau das ist die Designabsicht.

MEMORY.md: Die Notizen des Agenten

Hier speichert der Agent alles, was er über seine Umgebung, das Projekt, Tools, Konventionen und gelernte Lektionen lernt. So sieht es aus:

Das Projekt des Benutzers ist ein Go-Mikroservice unter ~/code/gateway, der gRPC + PostgreSQL verwendet.
Diese Maschine läuft mit Ubuntu 22.04, hat Docker und kubectl installiert.
Der Benutzer bevorzugt snake_case für Variablennamen und vermeidet camelCase.

Das sind keine Logs. Das sind Fakten. Dicht, deklarativ, informationsreich. Keine Zeitstempel, kein Schnicksel, kein „Am 5. Januar hat der Benutzer mich gebeten, …“

USER.md: Das Benutzerprofil

Hier speichert der Agent alles, was er über Sie weiß.

Der Benutzer ist ein Full-Stack-Entwickler, der sich mit TypeScript, Go und Python auskennt.
Der Benutzer bevorzugt snake_case für Variablennamen und vermeidet camelCase.
Der Benutzer nutzt hauptsächlich Linux Ubuntu 22.04.
Der Benutzer deployt zu AWS mit Terraform.

Identität, Rolle, Präferenzen, technische Fähigkeiten, Kommunikationsstil, Ärgernisse. Das Zeug, das den Agenten anders auf Sie antworten lässt als auf jeden anderen.

Das Frozen Snapshot Pattern

Bei Sitzungsstart werden beide Dateien von der Festplatte geladen und als gefrorener Block in den System-Prompt injiziert. So sieht es aus:

══════════════════════════════════════════════
GEDÄCHTNIS (Ihre persönlichen Notizen) [7% — 166/2.200 Zeichen]
══════════════════════════════════════════════
Das Projekt des Benutzers ist ein Go-Mikroservice unter ~/code/gateway, der gRPC + PostgreSQL verwendet.
§
Diese Maschine läuft mit Ubuntu 22.04, hat Docker und kubectl installiert.
§
Der Benutzer bevorzugt snake_case für Variablennamen und vermeidet camelCase.
§

══════════════════════════════════════════════
BENUTZERPROFIL (wer der Benutzer ist) [8% — 110/1.375 Zeichen]
══════════════════════════════════════════════
Der Benutzer ist ein Full-Stack-Entwickler, der sich mit TypeScript, Go und Python auskennt.
§
Der Benutzer bevorzugt snake_case für Variablennamen und vermeidet camelCase.
§

Das Format verwendet Header, Nutzungssprozente, Zeichenzahlen und § (Paragraphenzeichen) als Trennzeichen. Einträge können mehrzeilig sein. Es ist so konzipiert, dass es vom Modell parsebar ist, aber trotzdem für Menschen lesbar bleibt.

Warum gefroren? Prefix-Caching. Der System-Prompt ist in jeder Runde einer Sitzung gleich. Indem das Gedächtnis nach Sitzungsstart statisch gehalten wird, kann das Modell die Prefix-Berechnung cachen und nur die variablen Teile – die Konversation – verarbeiten. Dies ist eine signifikante Performance-Optimierung. Sie berechnen die Attention nicht bei jeder Runde neu über die gleichen Gedächtnis-Tokens.

Änderungen, die während einer Sitzung vorgenommen werden, werden sofort auf die Festplatte persistiert, erscheinen aber erst beim nächsten Sitzungsstart im System-Prompt. Tool-Antworten zeigen immer den Live-Status, aber das „Gehirn“ des Modells ändert sich nicht während der Sitzung. Dies verhindert, dass das Modell seinem eigenen Schwanz hinterherjagt – also das Gedächtnis aktualisiert und dann auf seine eigene Aktualisierung in derselben Konversation reagiert.

Zeichengrenzen als Feature

2.200 Zeichen. 1.375 Zeichen. Das sind keine willkürlichen Grenzen. Sie sind Designbeschränkungen, die Kuratierung erzwingen.

Unbegrenztes Gedächtnis ist eine Belastung. Es ermutigt dazu, alles hineinzudumpen, nie zu konsolidieren und schließlich zu Rauschen zu werden. Begrenztes Gedächtnis zwingt den Agenten, selektiv zu sein. Was ist wirklich wichtig? Was werde ich wieder brauchen? Was kann komprimiert werden, ohne die Bedeutung zu verlieren?

Wenn das Gedächtnis voll ist, schlägt der Agent nicht einfach still. Er erhält einen Fehler mit aktuellen Einträgen und Nutzung, und folgt dann einem Workflow:

1. Aktuelle Einträge aus der Fehlerantwort lesen
2. Entfernbare oder konsolidierbare Einträge identifizieren
3. replace verwenden, um verwandte Einträge in kürzere Versionen zusammenzufassen
4. Den neuen Eintrag hinzufügen

So bleibt das Gedächtnis nützlich. Es ist keine Datenbank. Es ist eine kuratierte Sammlung von Fakten, die wichtig sind.

Sicherheit: Prompt-Injection-Scanning

Jeder Gedächtniseintrag wird vor der Akzeptanz gescannt. Das System blockiert Prompt-Injection-Versuche, Credential-Exfiltration, SSH-Backdoors und unsichtbare Unicode-Zeichen.

Das Gedächtnis wird auch dedupliziert. Exakte Duplikate werden automatisch abgelehnt. Dies verhindert, dass Angreifer versuchen, schädliche Inhalte durch wiederholte Übermittlungen zu injizieren.

Teil 3: Wenn das Gedächtnis aktiv wird – Trigger & Entscheidungen

Die häufigste Frage zum Gedächtnis von Hermes Agent ist, wann es tatsächlich etwas speichert.

Die Antwort lautet: ständig, aber selektiv. Der Agent verwaltet sein eigenes Gedächtnis über das memory-Tool, und die Entscheidung zu speichern wird durch eine Kombination aus expliziten Signalen und impliziten Mustern getrieben.

Schreib-Trigger: Wann entscheidet der Agent, zu speichern?

Der Agent speichert proaktiv. Er wartet nicht darauf, dass Sie fragen. Hier sind die Auslöser.

Benutzerkorrekturen. Wenn Sie den Agenten korrigieren, ist das ein Signal, sich zu erinnern. „Tu das nicht noch einmal.“ „Verwende stattdessen das.“ „Erinnere dich daran.“ Das sind explizite Anweisungen, das Gedächtnis zu aktualisieren.

Beispiel: Sie fragen den Agenten, eine Python-Umgebung zu konfigurieren. Er schlägt pip vor. Sie sagen: „Ich verwende poetry für alles.“ Der Agent speichert: Der Benutzer bevorzugt den Paketmanager 'poetry' für alle Python-Projekte.

Entdeckte Präferenzen. Der Agent beobachtet Muster und leitet Präferenzen ab. Wenn Sie konsistent ein bestimmtes Tool, Framework oder Workflow verwenden, wird es gespeichert.

Beispiel: Nach dem mehrmaligen Sehen der Verwendung von poetry über verschiedene Projekte hinweg, speichert der Agent es als Präferenz.

Umgebungsfakten. Dinge über die Maschine, das Projekt, die installierten Tools. Diese werden durch Exploration entdeckt und als Fakten gespeichert.

Beispiel: Der Agent prüft, was installiert ist, und speichert: Diese Maschine läuft mit Ubuntu 22.04, hat Docker und kubectl installiert.

Projekt-Konventionen. Wie das Projekt strukturiert ist, welche Tools es verwendet, welche Muster es folgt. Diese werden durch Code-Inspektion entdeckt und gespeichert.

Beispiel: Das Projekt des Benutzers ist ein Go-Mikroservice unter ~/code/gateway, der gRPC + PostgreSQL verwendet.

Abgeschlossene komplexe Workflows. Nach Abschluss einer Aufgabe, die 5+ Tool-Aufrufe erforderte, erwägt der Agent, den Ansatz als Fähigkeit zu speichern oder zumindest festzuhalten, was funktioniert hat.

Tool-Sonderfälle und Workarounds. Wenn der Agent etwas Nicht-Offensichtliches über ein Tool, eine API oder ein System entdeckt – eine Einschränkung, einen Workaround, eine Konvention – speichert er es.

Was übersprungen wird:

• Triviale oder offensichtliche Informationen
• Dinge, die leicht neu entdeckt werden können
• Rohdaten-Dumps
• Sitzungsspezifische Ephemera
• Informationen, die bereits in Kontextdateien enthalten sind (SOUL.md, AGENTS.md)

Lese-Trigger: Wann ruft der Agent ab?

Gedächtnis wird nicht abgerufen – es ist immer da. Aber es gibt verschiedene Zugriffsebenen.

Sitzungsstart (automatisch). MEMORY.md und USER.md werden in den System-Prompt injiziert. Der Agent hat sie vom ersten Token an. Keine Abfrage nötig, keine Latenz, kein Tool-Aufruf. Das ist das Kerngedächtnis – immer aktiv.

session_search (auf Abruf). Wenn der Agent etwas aus vergangenen Konversationen finden muss, das nicht im Kerngedächtnis ist, verwendet er das session_search-Tool. Dies queryt SQLite (~/.hermes/state.db) mit FTS5 Full-Text-Suche und Gemini Flash-Zusammenfassung.

Beispiel: Sie fragen: „Haben wir letzte Woche über Docker-Netzwerke gesprochen?“ Der Agent durchsucht die Sitzungshistorie und gibt eine Zusammenfassung der relevanten Konversation zurück.

Externe Provider-Tools (wenn konfiguriert). Wenn ein externer Speicheranbieter aktiv ist, hat der Agent zusätzliche Tools verfügbar: honcho_search, hindsight_recall, mem0_search usw. Diese werden verwendet, wenn der Agent bestimmt, dass externer Kontext benötigt wird.

Der Entscheidungsbaum

Hier ist, wie der Agent abwägt, „Ist das wert, erinnert zu werden?“:

Ist dies eine Korrektur oder eine explizite Anweisung?
  JA → Im Gedächtnis speichern
  NEIN → Ist dies eine Präferenz oder ein Muster?
    JA → Im Benutzerprofil speichern
    NEIN → Ist dies ein Umgebungsfakt oder eine Konvention?
      JA → Im Gedächtnis speichern
      NEIN → Ist dies leicht neu entdeckbar?
        JA → Überspringen
        NEIN → Ist dies sitzungsspezifisch?
          JA → Überspringen
          NEIN → Im Gedächtnis speichern

Der Agent denkt nicht zu sehr darüber nach. Er speichert proaktiv, konsolidiert bei Vollständigkeit und vertraut auf die Zeichengrenzen, um die Dinge straff zu halten.

Teil 4: Internes Gedächtnis vs. Externe Wissensdatenbanken

Hier entsteht oft Verwirrung. Hermes Agent hat internes Gedächtnis (MEMORY.md, USER.md, externe Provider) und externe Wissensdatenbanken (LLM Wiki, Obsidian, Notion, ArXiv, Dateisystem), und sie erfüllen völlig unterschiedliche Rollen. Dies ähnelt der Unterscheidung zwischen retrieval-augmented generation Pipelines und Agenten-Arbeitsspeicher – externer Abruf ist gut für tiefe Wissensabfragen, nicht für das Tragen von Identität und Präferenzen. Internes Gedächtnis ist das Gehirn des Agenten – immer aktiv, kuratiert, in jede Sitzung mitgenommen. Externe Wissensdatenbanken sind seine Bibliothek – vast Referenzressourcen, die auf Abruf konsultiert werden.

Die Unterscheidung

Internes Gedächtnis (das Gehirn):

• Klein, persistent, in den System-Prompt injiziert
• Enthält: Benutzerpräferenzen, Agenten-Konventionen, unmittelbare Lektionen
• Immer „im Kopf“ während der Konversation
• Kuratiert, begrenzt, aktiv verwaltet
• Beispiele: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Externe Wissensdatenbanken (die Bibliothek):

• Vast, nur zur Referenz, auf Abruf zugänglich
• Enthält: Dokumente, Papiere, Code, Notizen, Datenbanken
• Über Tools bei Bedarf zugänglich
• Nicht „erinnert“ – nachgeschlagen
• Beispiele: LLM Wiki, Obsidian, Notion, ArXiv, Dateisystem, GitHub

Wie sie zusammenhängen

Der Agent greift auf externe Datenbanken über Tools zu, wenn nötig. Er „erinnert“ sie sich nicht – er schlägt sie nach.

LLM Wiki (llm-wiki): Karpathys verlinkte Markdown-Wissensdatenbank zum Aufbau und Abfragen von Domänenwissen. Der Agent verwendet die llm-wiki-Fertigkeit, um sie zu lesen, zu durchsuchen und abzufragen. Es ist eine Referenzressource, kein Gedächtnis.

Obsidian: Persönliche Notizen-Schreibe mit bidirektionalen Links. Der Agent verwendet die obsidian-Fertigkeit, um Notizen zu lesen, zu durchsuchen und zu erstellen. Obsidian ist Teil des breiteren Personal Knowledge Management Ökosystems, das Hermes als Bibliotheksressource nutzen kann.

Notion/Airtable: Strukturierte Datenbanken und Wikis, die über API abgerufen werden. Der Agent queryt sie bei Bedarf.

ArXiv: Akademische Papier-Repositories. Der Agent durchsucht und extrahiert Papiere bei der Recherche eines Themas.

Dateisystem: Projektcode, Dokumentation, Konfigurationen. Der Agent liest Dateien bei der Arbeit an einem Projekt.

Das Destillationsmuster

Hier ist der Schlüsselausdruck: Kritische Erkenntnisse aus externen Datenbanken können in das interne Gedächtnis destilliert werden.

Beispiel: Der Agent liest ein Papier von ArXiv über Memory Scaling für KI-Agenten. Er speichert nicht das gesamte Papier im Gedächtnis. Er speichert die Kernaussage: Memory Scaling: Agentenleistung verbessert sich mit gesammelter Erfahrung durch Benutzerinteraktion und im Gedächtnis gespeicherten Geschäftskontext.

Die externe Ressource ist vast. Das interne Gedächtnis ist die Destillation.

Wann was verwenden

Internes Gedächtnis für:

• „Wem helfe ich?“
• „Was bevorzugt er/sie?“
• „Was haben wir gerade gelernt?“
• „Wie ist die Projekteinrichtung?“
• „Welche Tools sind verfügbar?“

Externe Wissensdatenbanken für:

• „Was ist die neueste Forschung zu X?“
• „Was steht in der Projektdokumentation?“
• „Worüber haben wir letzten Monat gesprochen?“
• „Was ist die API für diesen Dienst?“
• „Wie ist die Code-Struktur?“

Der Agent versteht den Unterschied und verwendet jedes angemessen – er verwechselt das Nachschlagen eines Dokuments nicht mit dem Erinnern an etwas, das er über Sie und Ihre Umgebung gelernt hat.

Teil 5: Wie es tatsächlich funktioniert

Schauen wir uns die Mechanik an.

Das memory-Tool

Der Agent verwaltet das Gedächtnis über ein einzelnes Tool mit drei Aktionen: add, replace, remove.

Es gibt keine read-Aktion – der Gedächtnisinhalt wird automatisch in den System-Prompt injiziert. Der Agent muss es nicht lesen, weil es immer da ist.

add – Fügt einen neuen Eintrag hinzu.

memory(action="add", target="memory",
       content="Der Benutzer läuft macOS 14 Sonoma, nutzt Homebrew, hat Docker Desktop installiert.")

replace – Ersetzt einen bestehenden Eintrag unter Verwendung von Substring-Matching.

memory(action="replace", target="memory",
       old_text="Dark Mode",
       content="Der Benutzer bevorzugt Light Mode in VS Code, Dark Mode im Terminal")

remove – Entfernt einen Eintrag unter Verwendung von Substring-Matching.

memory(action="remove", target="memory",
       old_text="temporärer Projekt-Fakt")

Substring-Matching

replace und remove verwenden kurze, eindeutige Substrings über old_text. Sie benötigen nicht den vollständigen Eintragstext. Das ermöglicht chirurgische Bearbeitungen, ohne den genauen Inhalt zu kennen.

Wenn ein Substring mehreren Einträgen entspricht, wird ein Fehler zurückgegeben, der eine spezifischere Übereinstimmung anfordert. Der Agent verfeinert dann seine Abfrage.

Ziel-Speicher: memory vs user

Der Parameter target bestimmt, welche Datei aktualisiert wird.

• memory – Persönliche Notizen des Agenten. Umgebungsfakten, Projekt-Konventionen, Tool-Sonderfälle, gelernte Lektionen.
• user – Benutzerprofil. Identität, Rolle, Zeitzone, Kommunikationspräferenzen, Ärgernisse, Workflow-Gewohnheiten.

Kapazitätsmanagement

Wenn das Gedächtnis zu >80% voll ist, konsolidiert der Agent. Er fusioniert verwandte Einträge, entfernt veraltete Fakten und komprimiert Informationen.

Gute Gedächtniseinträge sind kompakt und informationsdicht:

Der Benutzer läuft macOS 14 Sonoma, nutzt Homebrew, hat Docker Desktop installiert. Shell: zsh mit oh-my-zsh. Editor: Neovim mit Telescope-Plugin.

Schlechte Gedächtniseinträge sind vage oder wortreich:

Der Benutzer hat ein Projekt.
Am 5. Januar 2026 bat der Benutzer mich, sein Projekt unter ~/code/gateway anzusehen, das Go mit gRPC und PostgreSQL für die Datenschicht verwendet.

Das erste ist dicht und nützlich. Das zweite ist entweder zu vage oder zu wortreich.

Session Search vs. Persistentes Gedächtnis

session_search und persistentes Gedächtnis erfüllen unterschiedliche Zwecke.

Faustregel: Verwenden Sie Gedächtnis für kritische Fakten, die immer im Kontext sein sollten. Verwenden Sie Session Search für historische Nachschlage.

Teil 6: Externe Speicherprovider – Alle 8 Optionen im Vergleich

Jenseits der integrierten MEMORY.md und USER.md unterstützt Hermes Agent 8 externe Speicherprovider-Plugins für persistentes, cross-session Wissen.

Nur ein externer Provider kann gleichzeitig aktiv sein. Die integrierten Dateien sind immer aktiv neben dem externen Provider – additiv, nicht ersetzend.

Aktivierung

hermes memory setup   # Interaktiver Picker + 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

Provider-Vergleich

Detaillierte Aufschlüsselung

Honcho

Am besten für: Multi-Agenten-Systeme, Cross-Session-Kontext, Benutzer-Agenten-Ausrichtung.

Honcho läuft neben dem bestehenden Gedächtnis – USER.md bleibt wie es ist, und Honcho fügt eine zusätzliche Kontext-Ebene hinzu. Es modelliert Konversationen als Peers, die Nachrichten austauschen – ein Benutzer-Peer plus ein AI-Peer pro Hermes-Profil, alle teilen einen Workspace.

Tools: honcho_profile (Peer-Karte lesen/aktualisieren), honcho_search (semantische Suche), honcho_context (Session-Kontext – Zusammenfassung, Darstellung, Karte, Nachrichten), honcho_reasoning (LLM-synthetisiert), honcho_conclude (Schlüsse erstellen/löschen).

Wichtige Konfigurationsparameter:

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

Architektur: Zwei-Schichten-Kontext-Injektion – Basis-Schicht (Session-Zusammenfassung + Darstellung + Peer-Karte) + dialektisches Supplement (LLM-Reasoning). Wählt automatisch Cold-Start vs. Warm-Prompts.

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

Einrichtung:

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

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

Profilverwaltung:

hermes profile create coder --clone  # Erstellt hermes.coder mit geteiltem Workspace
hermes honcho sync                   # Backfillt AI-Peers für bestehende Profile

OpenViking

Am besten für: Selbstgehostetes Wissensmanagement mit strukturierter Durchsuchung.

OpenViking bietet eine Dateisystem-Hierarchie mit gestaffeltem Laden. Es ist kostenlos, selbstgehostet und gibt Ihnen volle Kontrolle über Ihre Speicherhaltung.

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

Einrichtung:

pip install openviking
openviking-server
hermes memory setup  # "openviking" auswählen
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Am besten für: Hands-off Gedächtnisverwaltung mit Auto-Extraktion.

Mem0 handhabt die Gedächtnisextraktion serverseitig. Sie konfigurieren nichts – es funktioniert einfach. Trade-off: Cloud-Abhängigkeit und Kosten.

Tools: mem0_profile, mem0_search, mem0_conclude.

Einrichtung:

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

Am besten für: Wissensgraph-basierten Recall mit Entitätsbeziehungen.

Hindsight baut einen Wissensgraphen Ihres Gedächtnisses auf, extrahiert Entitäten und Beziehungen. Sein einzigartiges reflect-Tool führt Cross-Memory-Synthese durch – das Kombinieren mehrerer Erinnerungen zu neuen Erkenntnissen.

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

Einrichtung:

hermes memory setup  # "hindsight" auswählen
echo "HINDSIGHT_API_KEY=ihr-schlüssel" >> ~/.hermes/.env

Installiert automatisch hindsight-client (Cloud) oder hindsight-all (lokal). Erfordert >= 0.4.22.

Konfiguration: $HERMES_HOME/hindsight/config.json

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

Lokale UI: hindsight-embed -p hermes ui start

Holographic

Am besten für: Privacy-fokussierte Setups mit nur lokalem Speicher.

Holographic verwendet HRR (Holographic Reduced Representation) Algebra für die Gedächtniskodierung, mit Vertrauensbewertung für die Gedächtniszverlässlichkeit. Keine Cloud-Abhängigkeit – alles läuft lokal auf Ihrer eigenen Hardware.

Tools: 2 Tools für Gedächtnisoperationen über HRR-Algebra.

Einrichtung:

hermes memory setup  # "holographic" auswählen

Keine Abhängigkeiten. Alles läuft lokal.

RetainDB

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

RetainDB verwendet Delta-Kompression, um Gedächtnis-Updates effizient zu speichern. Es ist cloud-basiert mit Kosten von $20/Monat, aber die Kompression bedeutet weniger Datentransfer und schnellere Updates.

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

Einrichtung:

hermes memory setup  # "retaindb" auswählen

ByteRover

Am besten für: Bandbreiten-eingeschränkte Umgebungen mit Pre-Kompression-Extraktion.

ByteRover komprimiert das Gedächtnis vor der Extraktion, reduziert die Bandbreitennutzung. Verfügbar in lokalen oder Cloud-Modi.

Tools: 3 Tools für Gedächtnisoperationen.

Einrichtung:

hermes memory setup  # "byterover" auswählen

Supermemory

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

Supermemory bietet Kontext-Fencing (Isolierung des Gedächtnisses nach Kontext) und Session-Graph-Ingest (Import ganzer Konversationsverläufe). Es ist cloud-basiert und bezahlt, aber für Enterprise-Scale-Gedächtnisverwaltung ausgelegt.

Tools: 4 Tools für Gedächtnisoperationen.

Einrichtung:

hermes memory setup  # "supermemory" auswählen

Wie man wählt

• Multi-Agenten-Support nötig? Honcho
• Selbstgehostet und kostenlos wollen? OpenViking oder Holographic
• Zero-Config wollen? Mem0
• Wissensgraphen wollen? Hindsight
• Delta-Kompression wollen? RetainDB
• Bandbreiteneffizienz wollen? ByteRover
• Enterprise-Features wollen? Supermemory
• Privatsphäre (nur lokal) wollen? Holographic

Für vollständige Profil-für-Profil-Provider-Konfigurationen und real-world Workflow-Muster, siehe Hermes Agent Production Setup.

Teil 7: Die Philosophie

Warum begrenztes Gedächtnis unbegrenztem Gedächtnis überlegen ist

Der Instinkt ist, das Gedächtnis so groß wie möglich zu machen. Alles speichern. Abrufen, was Sie brauchen.

Begrenztes Gedächtnis funktioniert besser. Hier ist warum.

Kuratierung erzwingt Qualität. Wenn Sie begrenzten Platz haben, speichern Sie nur das, was wichtig ist. Sie komprimieren, konsolidieren und priorisieren. Unbegrenztes Gedächtnis ermutigt dazu, alles hineinzudumpen und nie aufzuräumen.

Geschwindigkeit zählt. 1.300 Tokens im System-Prompt sind schnell. 100.000 Tokens, die aus einer Datenbank abgerufen werden, sind langsam. Gedächtnis sollte instant sein, keine Abfrage.

Rauschen degradiert die Leistung. Mehr Gedächtnis ist nicht besseres Gedächtnis. Es ist räuschenderes Gedächtnis. Das Modell muss Signal von Rauschen unterscheiden, und das kostet Attention – Attention, die für die eigentliche Aufgabe ausgegeben werden sollte.

Vergessen ist ein Feature. Das menschliche Gedächtnis vergisst. Das ist kein Bug – so priorisieren wir. Agenten sollten auch vergessen. Nicht alles verdient, erinnert zu werden.

Das „Vergessen“-Problem

Agenten müssen unlearnen. Nicht nur vergessen, sondern aktiv veraltete Informationen entfernen.

Hier ist, wie Hermes Agent das handhabt:

• remove-Aktion: Einträge löschen, die nicht mehr relevant sind.
• replace-Aktion: Einträge mit neuen Informationen aktualisieren.
• Kapazitätsdruck: Wenn das Gedächtnis voll ist, konsolidiert der Agent und entfernt alte Einträge.
• Security-Scanning: Blockiert schädliche oder korrupte Einträge.

Vergessen ist kein Versagen – es ist Wartung. Ein Agent, der nicht unlearnen kann, wird schließlich so viel Rauschen wie Signal tragen.

Memory Scaling

Databricks führte das Konzept der „Memory Scaling“ ein: Leistet ein Agent mit Tausenden von Benutzern besser als einer mit einem einzelnen Benutzer?

Ihre Forschung deutet darauf hin, ja, aber mit Vorbehalten. Memory Scaling erfordert:

1. Qualitative Extraktion: Nicht alle Interaktionen sind wert, erinnert zu werden. Der Agent muss Erkenntnisse extrahieren, nicht Logs.
2. Effektiver Abruf: Abgerufene Erinnerungen müssen relevant sein. Rauschen degradiert die Leistung.
3. Generalisierung: Erinnerungen sollten Muster sein, keine Spezifika. „Benutzer bevorzugt Python“ skaliert. „Benutzer führte Befehl X zu Zeitstempel Y aus“ skaliert nicht.

Das begrenzte Gedächtnis von Hermes Agent unterstützt Memory Scaling natürlich. Indem es Kuratierung erzwingt, stellt es sicher, dass Erinnerungen generalisierbar, kompakt und nützlich sind.

Was das für die Zukunft bedeutet

Gedächtnis wird zur wettbewerbsfähigen Moat im agentic AI – nicht das Modell selbst, sondern was das Modell zwischen Sitzungen trägt. Zwei Agenten mit identischen zugrunde liegenden Modellen können sehr unterschiedlich performen: einer erinnert sich an Ihre Präferenzen, Ihre Umgebung und Ihre vergangenen Fehler; der andere startet jedes Mal kalt.

Die Frage ist nicht mehr, ob Agenten persistierendes Gedächtnis haben sollten. Das ist geklärt: Sie müssen. Die offene Frage ist, wie man dieses Gedächtnis gut gestaltet – was zu behalten, was zu verwerfen, wie man es instant macht und wie man verhindert, dass es zu Rauschen wird.

Die Antwort von Hermes Agent ist, das Gedächtnis klein, kuratiert und immer aktiv zu halten – keine Datenbank, die abgefragt wird, sondern ein Arbeitsmodell des Benutzers, das der Agent in jede Konversation mitnimmt.

Fazit

Das Gedächtnissystem von Hermes Agent ist bewusst einfach: zwei Dateien, feste Zeichengrenzen, keine Abruf-Pipeline, keine Vektordatenbank und keine Latenz pro Abfrage. Was nach einer Einschränkung klingt, ist der ganze Punkt.

Es funktioniert, weil es das Gedächtnis behandelt, wie ein Gehirn funktioniert, nicht wie eine Datenbank – klein, kuratiert und immer aktiv. Der Agent ruft das Gedächtnis nicht ab, wenn er es braucht; das Gedächtnis ist einfach immer da, eingewoben in den System-Prompt vom ersten Token jeder Sitzung an.

Externe Speicherprovider erweitern dieses System für Benutzer, die mehr brauchen: Wissensgraphen, Multi-Agenten-Support, selbstgehosteten Speicher, Enterprise-Features. Aber der Kern bleibt der gleiche: begrenzt, kuratiert, immer verfügbar.

Und externe Wissensdatenbanken – LLM Wiki, Obsidian, Notion, ArXiv – erfüllen eine andere Rolle. Sie sind die Bibliothek, nicht das Gehirn. Der Agent schlägt sie nach, erinnert sie sich nicht. Kritische Erkenntnisse werden im internen Gedächtnis destilliert; der Rest bleibt in der Bibliothek.

So erinnert sich ein KI-Agent an Sie. Nicht indem er alles speichert, sondern indem er sich daran erinnert, was wichtig ist.

Hermes Agent wurde von Nous Research im Februar 2026 veröffentlicht und erreichte bis April 2026 über 64.000 GitHub-Sterne (v0.9.0), mit 242+ Mitwirkenden. Es ist Open-Source und verfügbar unter github.com/NousResearch/hermes-agent. Für Installation, Konfiguration und Workflow-Anleitungen, siehe die Hermes Agent Übersicht.