Hermes-Agent-Speichersystem: So funktioniert persistentes KI-Speicher

Sie kennen das Prinzip. Sie öffnen einen Chat mit einem KI-Agenten, erläutern Ihr Projekt, teilen Ihre Präferenzen, lassen Aufgaben 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 verloren, jede Präferenz vergessen, das Projekt muss von Grund auf neu erklärt werden.

Dies ist kein Fehler. So funktionieren Large Language Models (LLMs) per Design. 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 Interaktionen mit nur einem Austausch ist das in Ordnung. Stellen Sie eine Frage, erhalten Sie eine Antwort, und gehen Sie weiter. Für Agenten – Systeme, die im Laufe mehrerer Sitzungen Aktionen ausführen, aus Fehlern lernen und sich mit Ihnen entwickeln sollen – ist Zustandslosigkeit jedoch eine harte architektonische Grenze. Es ist eines der zentralen ungelösten Probleme in selbst gehosteten KI-Systemen.

Die Industrie hat versucht, dies zu lösen. LangChain fügte Gedächtnismodulen hinzu. OpenAI führte Assistenten mit Threads ein. Frameworks wie Letta, Zep und Cognee bauten ganze Architekturen um ein persistierendes Gedächtnis herum. Databricks veröffentlichte Studien zum “Memory Scaling” – der Idee, dass die Leistung von Agenten mit gesammelter Erfahrung verbessert wird. Seit 2024 sind dedizierte Benchmark-Papiere, Übersichten zur episodischen Erinnerung und ein schnell wachsendes Ökosystem von Tools entstanden, um das zu adressieren, was zunehmend als eines der zentralen ungelösten Probleme in der 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 aufgefüllt wird, ein Abrufsystem, das Latenz und Rauschen hinzufügt, statt Klarheit zu schaffen.

Hermes Agent verfolgt einen grundlegend anderen Ansatz. Gedächtnis ist etwas, das der Agent nicht abrufen muss, wenn es benötigt wird. Es ist etwas, das der Agent zu jeder Zeit ist – in den System-Prompt eingebaut, 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 darf.

Dieser Artikel erklärt genau, wie das funktioniert – die Hermes-spezifische Schicht im cross-framework-Modell in Gedächtnissysteme in KI-Assistenten und die breitere Stack-Struktur in Architektur von KI-Assistenten. Für Aktivierungs- und Inspektionsbefehle (hermes memory, hermes dump, Log-Tailing) kombinieren Sie dies mit der Hermes Agent CLI Cheat Sheet. Für die komplementäre Seite von Hermess “langfristigem Wissen” – wiederverwendbare Verfahren in SKILL.md statt kuratierter Gedächtnisdateien – siehe Hermes Agent Skill Authoring — SKILL.md Struktur und Best Practices.

Teil 1: Das Problem des KI-Agent-Gedächtnisses

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

Die offensichtliche Lösung für zustandslose KI ist das Hinzufügen von Kontext. Binden Sie das vorherige Gespräch an. Schließen Sie die Projektdokumentation ein. Senden Sie die gesamte Historie.

Eine Weile funktioniert das. Sie haben ein Kontextfenster von 128K. Sie können viel Text hineinpaketen.

Aber Kontext ist kein 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 muss das Modell Tausende von Tokens irrelevanten Historie verarbeiten, um die eine Tatsache zu finden, die es benötigt. Das kostet Tokens und Geld, verstärkt die Latenz und stößt schließlich an die Grenzen.

Gedächtnis ist kuratiert. Es ist die Destillation von Erfahrung zu etwas Kompaktem und Actionable. Es wächst nicht unendlich – es konsolidiert, aktualisiert und vergisst.

Das menschliche Gedächtnis funktioniert auf die gleiche Weise. Sie erinnern sich nicht an jedes Gespräch, das Sie je geführt haben. Sie erinnern sich an die Teile, die wichtig sind: Mit wem Sie sprechen, was sie interessiert, worauf Sie sich geeinigt haben, was Sie gelernt haben. Der Rest wird entweder vergessen oder ist bei Bedarf durchsuchbar.

Die Forschungslandschaft

Der Bereich des KI-Agent-Gedächtnisses ist seit 2024 explodiert, mit dedizierten Benchmark-Suiten, einer wachsenden Forschungslandschaft 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 First-Class-Problem behandelte und 21.700 GitHub-Sterne erreichte. Es verwendet ein OS-inspiriertes Drei-Stufen-Modell: Core Memory (klein, immer im Kontext), Recall Memory (durchsuchbare Gesprächshistorie) und Archival Memory (langfristige Cold-Storage). Die Erkenntnis, dass nicht alles Gedächtnis gleich ist, war korrekt. Die Implementierung erfordert jedoch, dass Agenten vollständig innerhalb der Letta-Laufzeit laufen – die Adoption bedeutet, die gesamte Plattform zu übernehmen, nicht nur eine Gedächtnisschicht.

Zep / Graphiti konzentriert sich auf konversationales Gedächtnis mit zeitlicher Entity-Tracking – Fakten haben Gültigkeitsfenster, sodass 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 über 30 Ingestion-Connectoren und einem Knowledge-Graph-Backend. Es excelt in institutionellem Wissen und RAG-Pipelines, ist aber weniger auf persönliches Agent-Gedächtnis fokussiert. Siehe Selbsthosting von Cognee mit lokalen LLMs für eine praktische Setup-Anleitung.

Hindsight bietet knowledge-graph-basiertes Recall mit Entity-Beziehungen und einem einzigartigen reflect-Synthese-Tool, das Cross-Memory-Synthese durchführt – das Kombinieren mehrerer Erinnerungen zu neuen Erkenntnissen. Es gehört zu den Top-Performern in Agent-Gedächtnis-Benchmarks und ist als Memory-Provider für Hermes Agent verfügbar.

Mem0 verarbeitet die Gedächtnisextraktion serverseitig über LLM-Analyse und erfordert minimale Konfiguration. Das Mem0-Forschungspapier, veröffentlicht auf ECAI 2025 (arXiv:2504.19413), benchmarkte zehn verschiedene Ansätze zum KI-Gedächtnis und validierte den Ansatz der selektiven Extraktion – Speicherung diskreter Fakten, Deduplizierung und Abruf nur dessen, was relevant ist. Mem0 ist auf etwa 48.000 GitHub-Sterne angewachsen 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 auf Organisations- und Benutzerebene und validiert die Idee, dass Gedächtnisqualität genauso wichtig ist wie Modellfähigkeit.

Der gemeinsame Nenner in den 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 abgerufen, es wird beim Sitzungsstart injiziert und immer vorhanden. Immer aktiv, immer verfügbar, kuratiert genug, um nützlich zu bleiben.

Teil 2: Architektur

Lesen Sie diesen Teil von oben nach unten – Schichten und per-turn recall/store zuerst, dann was in MEMORY.md und USER.md lebt, dann wie man einen externen Anbieter anbindet.

Zwei Schichten

Hermes stapelt Gedächtnis in zwei Schichten:

1. Eingebaut — MEMORY.md und USER.md, dateibasiert, immer aktiv. Harte Limits von 2.200 Zeichen (Agent-Notizen) und 1.375 Zeichen (Benutzerprofil).
2. Ein externer Anbieter (optional) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory und Peers, die Sie über die Konfiguration aktivieren. Nur ein externes Backend läuft gleichzeitig. Es fügt Abruf und Retention neben den Dateien hinzu; es ersetzt sie nicht.

Das mentale Modell ist additiv – eingefrorene Kerndateien plus höchstens ein Plugin. Prefetch- und Sync-Hooks orchestrieren die externe Schicht; die beiden Dateien bleiben als Teil des eingefrorenen System-Prompts separat injiziert.

Runtime-Flow (Prefetch und Sync)

Recall geschieht bevor das Modell antwortet; Persistenz geschieht nach der Assistant-Nachricht. In Hermes Agent’s Memory-Manager映射 dies auf prefetch beim Hineingehen und sync beim Hinausgehen. Die Namen unten entsprechen der Implementierungs-Oberfläche (MemoryManager, per-provider prefetch / sync_turn / queue_prefetch).

Benutzernachricht
    |
    v
MemoryManager.prefetch_all(query)        <-- Recall-Phase
    |
    +-- provider.prefetch(query)        <-- jeder externe Anbieter durchsucht seinen Speicher
    |
    v
Kontext in LLM-Turn injiziert
    |
    v
LLM antwortet (Assistant-Nachricht)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- Store-Phase
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- Hintergrundsuche für den nächsten Turn

Die eingebauten MEMORY.md und USER.md werden nicht über prefetch_all abgerufen – sie sind bereits Teil des eingefrorenen System-Prompts. Externe Backends hängen in prefetch_all / sync_all ein; queue_prefetch ermöglicht es einem Anbieter, den Abruf für den folgenden Turn vorzuwärmen, ohne die aktuelle Antwort zu blockieren.

Drei Wege in das Langzeitgedächtnis

1. Eingebautes memory-Tool. Das Modell ruft memory mit add, replace oder remove auf, wenn Anweisungen sagen, dass etwas persistieren soll – dauerhafte Fakten, Präferenzen, Korrekturen, Umgebungsnotizen. target='user' pflegt USER.md; target='memory' pflegt MEMORY.md. Beispiel-Form: memory(action='add', target='user', content='…').

2. Passive Retention bei externen Anbietern. Jeden Turn ruft das Framework den Sync-Pfad des Anbieters auf, sodass Konversationen chunked, zusammengefasst oder extrahiert werden können, ohne dass das Modell jede Tatsache benennt. Das Verhalten unterscheidet sich je nach Backend – zum Beispiel batcht Hindsight Turns und führt strukturierte Retention mit Entities und Beziehungen durch; Honcho sendet Dialoge durch seine dialektische Pipeline; Mem0- und Supermemory-Stacks extrahieren Fakten passiv aus Turns.

3. Anbieterspezifische Tools. Wenn das Plugin sie verfügbar macht, speichern explizite Schreibvorgänge wie honcho_conclude, hindsight_retain oder honcho_profile dauerhafte Scheiben auf Abruf.

Automatisches Recall versus Provider-Tools

Core Memory benötigt kein Lese-Tool – es ist bereits im Prompt. Externe Backends fügen entweder automatische Injektion aus Prefetch hinzu (kein separates Recall-Tool-Call für diesen Teil des Kontexts) oder explizite Abruf-Tools (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect und Peers), wenn das Modell eine schärfere Abfrage benötigt als Prefetch allein.

Recall-Modi (externe Anbieter)

Plugins unterstützen einen konfigurierbaren Recall-Modus (typischerweise recall_mode neben memory.provider in der Konfiguration), der Tokens gegen Kontrolle austauscht.

Wenn kein externer Anbieter gesetzt ist (memory.provider leer oder nicht gesetzt), gelten nur die eingebauten Dateien und die Session-Suche – kein Prefetch/Sync von einem Plugin.

Pfade auf der Festplatte und Budgets

Das eingebaute Gedächtnis 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 Oberfläche des persistenten Gedächtnisses: zwei Dateien, unter 3.600 Zeichen insgesamt, weniger als 1.300 Tokens. Es sieht absichtlich klein aus, weil es ist – und genau das ist die Design-Intention.

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-Microservice 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 Schnickschnack, 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 mit TypeScript, Go und Python vertraut ist.
Der Benutzer bevorzugt snake_case für Variablennamen und vermeidet camelCase.
Der Benutzer verwendet hauptsächlich Linux Ubuntu 22.04.
Der Benutzer deployt mit Terraform auf AWS.

Identität, Rolle, Präferenzen, technische Fähigkeiten, Kommunikationsstil, persönliche Dornen im Auge. Das Zeug, das den Agenten anders auf Sie antworten lässt als auf jeden anderen.

Das Frozen-Snapshot-Muster

Zum Sitzungsstart werden beide Dateien von der Festplatte geladen und als eingefroener 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-Microservice 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 mit TypeScript, Go und Python vertraut ist.
§
Der Benutzer bevorzugt snake_case für Variablennamen und vermeidet camelCase.
§

Das Format verwendet Header, Nutzungsprozentsätze, Zeichenzahlen und § (Section-Zeichen) als Trennzeichen. Einträge können mehrzeilig sein. Es ist so ausgelegt, dass es vom Modell parsbar bleibt, während es für Menschen lesbar bleibt.

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

Änderungen, die während einer Sitzung vorgenommen werden, werden sofort auf die Festplatte geschrieben, erscheinen aber erst beim nächsten Sitzungsstart im System-Prompt. Tool-Antworten zeigen immer den Live-Status, aber der “Geist” des Modells ändert sich nicht während der Sitzung. Dies verhindert, dass das Modell seinen eigenen Schwanz jagt – 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 Limits. Das sind Design-Einschränkungen, die Kuratierung erzwingen.

Unbegrenztes Gedächtnis ist eine Last. 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, folgt dann einem Workflow:

1. Lese aktuelle Einträge aus der Fehlerantwort
2. Identifiziere entfernbare oder konsolidierbare Einträge
3. Verwende replace, um verwandte Einträge in kürzere Versionen zusammenzuführen
4. Füge den neuen Eintrag hinzu

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 doppelte Einträge werden automatisch abgelehnt. Dies verhindert, dass Gegner versuchen, bösartige Inhalte durch wiederholte Einreichungen einzuspritzen.

Externe Gedächtnisanbieter (Aktivierung und Links)

Jenseits der eingebauten MEMORY.md und USER.md kann Hermes Agent einen externen Gedächtnis-Plugin zur gleichen Zeit anbinden – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover oder Supermemory – für persistierendes, cross-session-Wissen. Nur ein externer Anbieter ist gleichzeitig aktiv; die zwei Kerndateien bleiben daneben geladen (additiv, nicht ersetzend).

Aktivieren und inspizieren Sie Anbieter mit hermes memory setup, hermes memory status und hermes memory off, oder setzen Sie memory.provider und recall_mode in ~/.hermes/config.yaml. Credential-Muster variieren (zum Beispiel HINDSIGHT_API_KEY, Honcho-Schlüssel unter $HERMES_HOME/honcho.json); verwenden Sie hermes memory setup für interaktive Verdrahtung.

Minimale YAML-Struktur nur für eingebautes Gedächtnis:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Beispielaktivierung für ein Backend (tauschen Sie hindsight gegen honcho, mem0, supermemory oder andere aus, die Ihre Installation unterstützt):

memory:
  provider: "hindsight"

Für die vollständige Vergleichstabelle, LLM- und Embedding-Abhängigkeitsnotizen, Aufschlüsselungen pro Anbieter und wie diese Backends zu OpenClaw und anderen Stacks stehen, siehe Vergleich der Agent-Gedächtnisanbieter.

Für profil-spezifische Verdrahtung und Produktionsworkflows siehe Hermes Agent Produktions-Setup. Die KI-Systeme Gedächtnis-Hub listet diesen Leitfaden sowie verwandte Cognee- und Knowledge-Layer-Artikel auf.

Teil 3: Wenn Gedächtnis zündet – 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 von einer Kombination aus expliziten Signalen und impliziten Mustern angetrieben.

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

Der Agent speichert Gedächtnis proaktiv. Er wartet nicht darauf, dass Sie fragen. Hier sind die Trigger.

Benutzerkorrekturen. Wenn Sie den Agenten korrigieren, ist das ein Signal zum Erinnern. “Mach das nicht nochmal.” “Verwende stattdessen dies.” “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 inferiert Präferenzen. Wenn Sie konsistent ein bestimmtes Tool, Framework oder Workflow verwenden, wird es gespeichert.

Beispiel: Nachdem der Agent gesehen hat, dass Sie poetry mehrmals in verschiedenen Projekten verwenden, speichert er 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-Microservice 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 Skill zu speichern oder zumindest festzuhalten, was funktioniert hat.

Tool-Idiosynkrasien 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 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 Zugangsebenen.

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-Call. Das ist das Core Memory – immer aktiv.

session_search (auf Abruf). Wenn der Agent etwas aus vergangenen Konversationen finden muss, das nicht im Core Memory ist, verwendet er das session_search-Tool. Dies queryt SQLite (~/.hermes/state.db) mit FTS5 Full-Text-Suche und Gemini Flash-Zusammenfassung. Verwenden Sie dies, wenn die Frage klingt wie “haben wir das vorher besprochen” statt “erinnere dich an diese Tatsache für immer.”

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 externes Gedächtnis-Provider aktiv ist, führt das Framework auch einen automatischen Prefetch-Schritt vor jeder Antwort aus (siehe Teil 2). Zusätzliche Tools wie honcho_search, hindsight_recall oder mem0_search sind für gezielte Lookups, wenn der Agent expliziten Abruf wählt – je nach recall_mode können automatische Injektion, Tools oder beide aktiv sein.

Die Entscheidungsbaum

So wägt der Agent ab, “ist das wert, erinnert zu werden?”:

Ist das eine Korrektur oder explizite Anweisung?
  JA → Speichere im Gedächtnis
  NEIN → Ist das eine Präferenz oder ein Muster?
    JA → Speichere im Benutzerprofil
    NEIN → Ist das ein Umgebungsfakt oder eine Konvention?
      JA → Speichere im Gedächtnis
      NEIN → Ist das leicht neu entdeckbar?
        JA → Überspringe
        NEIN → Ist das sitzungsspezifisch?
          JA → Überspringe
          NEIN → Speichere im Gedächtnis

Der Agent denkt nicht zu viel darüber nach. Er speichert proaktiv, konsolidiert, wenn voll, und vertraut den Zeichengrenzen, die Dinge straff zu halten.

Teil 4: Internes Gedächtnis versus Externe Wissensdatenbanken

Hier entsteht oft Verwirrung. Hermes Agent hat internes Gedächtnis (MEMORY.md, USER.md, externe Anbieter) 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 Agent-Arbeitsgedächtnis – externer Abruf ist gut für tiefe Wissenslookups, 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 getragen. Externe Wissensdatenbanken sind seine Bibliothek – umfangreiche Referenzressourcen, die auf Abruf konsultiert werden.

Die Unterscheidung

Internes Gedächtnis (das Gehirn):

• Klein, persistent, in den System-Prompt injiziert
• Enthält: Benutzerpräferenzen, Agent-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):

• Umfangreich, nur referenziell, auf Abruf zugreifbar
• Enthält: Dokumente, Papiere, Code, Notizen, Datenbanken
• Zugreifbar via Tools, wenn benötigt
• Nicht “erinnert” – nachgeschlagen
• Beispiele: LLM Wiki, Obsidian, Notion, ArXiv, Dateisystem, GitHub

Wie sie zusammenhängen

Der Agent greift auf externe Datenbanken via Tools zu, wenn benötigt. Er “erinnert” sie sich nicht – er schaut sie nach.

LLM Wiki (llm-wiki): Karpathys verknüpftes Markdown-Wissensdatenbank zum Aufbau und Abfragen von Domänenwissen. Der Agent verwendet den llm-wiki-Skill, um es zu lesen, zu durchsuchen und abzufragen. Es ist eine Referenzressource, kein Gedächtnis.

Obsidian: Persönliche Notizen-Vaults mit bidirektionalen Links. Der Agent verwendet den obsidian-Skill, 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 via API abgerufen werden. Der Agent queryt sie, wenn benötigt.

ArXiv: Akademische Papier-Repositories. Der Agent sucht und extrahiert Papiere, wenn er ein Thema recherchiert.

Dateisystem: Projektcode, Dokumentation, Konfigurationen. Der Agent liest Dateien, wenn er an einem Projekt arbeitet.

Das Destillationsmuster

Hier ist der Schlüsselinsight: 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 Geschäftskontext, der im Gedächtnis gespeichert ist.

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

Wann man was verwendet

Internes Gedächtnis für:

• “Wem helfe ich?”
• “Was bevorzugt er?”
• “Was haben wir gerade gelernt?”
• “Wie ist das Projekt-Setup?”
• “Welche Tools sind verfügbar?”

Externe Wissensdatenbanken für:

• “Was ist die neueste Forschung zu X?”
• “Was steht in der Projektdokumentation?”
• “Was haben wir letzten Monat diskutiert?”
• “Wie ist die API für diesen Service?”
• “Wie ist die Code-Struktur?”

Der Agent versteht den Unterschied und verwendet jedes entsprechend – 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, verwendet Homebrew, hat Docker Desktop installiert.")

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

memory(action="replace", target="memory",
       old_text="dunkler Modus",
       content="Der Benutzer bevorzugt hellen Modus in VS Code, dunklen Modus 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, einzigartige Substrings via old_text. Sie benötigen nicht den vollständigen Eintragstext. Dies ermöglicht chirurgische Bearbeitungen, ohne den genauen Inhalt zu kennen.

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

Ziel-Speicher: memory versus user

Der target-Parameter bestimmt, welche Datei aktualisiert wird.

• memory — Persönliche Notizen des Agenten. Umgebungsfakten, Projekt-Konventionen, Tool-Idiosynkrasien, gelernte Lektionen.
• user — Benutzerprofil. Identität, Rolle, Zeitzone, Kommunikationspräferenzen, persönliche Dornen im Auge, Workflow-Gewohnheiten.

Kapazitätsmanagement

Wenn das Gedächtnis >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, verwendet 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 Datenbankebene verwendet.

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

Session Search versus 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 Lookups.

Teil 6: Die Philosophie

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

Der Instinkt ist, Gedächtnis so groß wie möglich zu machen. Speichere alles. Rufe das ab, was du brauchst.

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 sofortig sein, keine Abfrage.

Rauschen verschlechtert die Leistung. Mehr Gedächtnis ist kein besseres Gedächtnis. Es ist lauter 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 Fehler – so priorisieren wir. Agenten sollten auch vergessen. Nicht alles verdient es, erinnert zu werden.

Das “Vergessen”-Problem

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

So geht Hermes Agent damit um:

• remove-Aktion: Lösche Einträge, die nicht mehr relevant sind.
• replace-Aktion: Aktualisiere Einträge mit neuen Informationen.
• Kapazitätsdruck: Wenn das Gedächtnis voll ist, konsolidiert der Agent und entfernt alte Einträge.
• Sicherheits-Scanning: Blockiert bösartige oder beschädigte Einträge.

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

Memory Scaling

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

Ihre Forschung deutet auf Ja hin, aber mit Vorbehalten. Memory Scaling erfordert:

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

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

Was das für die Zukunft bedeutet

Gedächtnis wird zur Wettbewerbsmauer in der 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: Der eine 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 entwirft – was zu behalten, was zu verwerfen, wie man es sofortig macht und wie man verhindert, dass es zu Rauschen wird.

Hermes Agent’s Antwort 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 mit sich trägt.

Fazit

Das Gedächtnissystem von Hermes Agent ist absichtlich einfach: zwei Dateien, harte Zeichengrenzen, keine Abruf-Pipeline, keine Vektordatenbank, und keine Latenz pro Abfrage. Was wie eine Einschränkung klingt, ist der ganze Punkt.

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

Externe Gedächtnisanbieter erweitern dieses System für Benutzer, die mehr brauchen: Knowledge Graphs, Multi-Agent-Support, selbst gehostete Speicherung, 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 schaut sie nach, erinnert sie sich nicht. Kritische Erkenntnisse werden in das interne Gedächtnis destilliert; der Rest bleibt in der Bibliothek.

So erinnert sich ein KI-Agent an Sie. Indem er nicht alles speichert, sondern das, was wichtig ist, erinnert.

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 über 242 Mitwirkenden. Es ist Open-Source und verfügbar unter github.com/NousResearch/hermes-agent. Für Installations-, Konfigurations- und Workflow-Leitfäden siehe die Hermes Agent Übersicht.