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 etwas erledigen und schließen den Tab. Kommen Sie die folgende Woche zurück, ist es so, 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 einzelne Interaktionen ist das in Ordnung. Stellen Sie eine Frage, erhalten Sie eine Antwort, und gehen Sie weiter. Aber für Agenten – Systeme, die Dinge über Sitzungen hinweg tun, aus Fehlern lernen und sich mit Ihnen entwickeln sollen – ist Zustandslosigkeit eine harte architektonische Grenze. Es ist eines der zentralen ungelösten Probleme in selbst gehosteten KI-Systemen.

Die Branche hat versucht, dies zu lösen. LangChain fügte Gedächtnismodule hinzu. OpenAI führte Assistenten mit Threads ein. Frameworks wie Letta, Zep und Cognee bauten ganze Architekturen um persistierendes Gedächtnis auf. 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, Übersichtsarbeiten zum episodischen Gedächtnis und ein schnell wachsendes Ökosystem von Tools entstanden, um das zu adressieren, was zunehmend als eines der zentralen ungelösten Probleme der agentischen KI 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 Retrieval-System, das Latenz und Rauschen hinzufügt, statt Klarheit zu schaffen.

Hermes Agent verfolgt einen grundlegend anderen Ansatz. Das Gedächtnis ist etwas, das der Agent nicht abrufen muss, wenn es benötigt wird. Es ist etwas, das der Agent ist – jederzeit 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 zu vergessen ist.

Dieser Artikel erklärt genau, wie das funktioniert.

Teil 1: Das KI-Agenten-Gedächtnisproblem

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

Die offensichtliche Lösung für zustandslose KI ist das Hinzufügen von Kontext. Hängen Sie das vorherige Gespräch an. Nehmen Sie die Projektdokumentation auf. Senden Sie die gesamte Historie.

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

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 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 zu etwas Kompaktem und Handlungsfähigem. 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 Konversation, die Sie je geführt haben. Sie erinnern sich an die Teile, die wichtig sind: Wem Sie gegenüberstehen, was ihnen wichtig ist, worauf Sie sich geeinigt haben, was Sie gelernt haben. Der Rest wird entweder vergessen oder ist bei Bedarf durchsuchbar.

Die Forschungslandschaft

Der Raum für KI-Agenten-Gedächtnis ist seit 2024 explodiert, mit dedizierten Benchmark-Suiten, 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 erste Priorität behandelte und 21.700 GitHub-Sterne erreichte. Es verwendet ein vom Betriebssystem inspiriertes Drei-Stufen-Modell: Kerndaten (klein, immer im Kontext), abrufbares Gedächtnis (durchsuchbare Gesprächshistorie) und Archivgedächtnis (langfristiger kalter Speicher). Die Erkenntnis, dass nicht alles Gedächtnis gleich ist, war korrekt. Die Implementierung erfordert jedoch, dass Agenten vollständig innerhalb der Letta-Laufzeitumgebung laufen – die Adoption bedeutet, die gesamte Plattform zu übernehmen, nicht nur eine Speicher-Ebene.

Zep / Graphiti konzentriert sich auf Konversationsgedächtnis mit zeitlicher Entitätsverfolgung – 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 Umgebungsdaten und Projektstandards verfolgen.

Cognee ist für die Wissensextraktion aus Dokumenten und strukturierten Daten aufgebaut, mit über 30 Ingestions-Connectoren und einem Knowledge-Graph-Backend. Es glänzt 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 erinnerungsbasierter Abruf über Knowledge Graphs 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 in Agenten-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. Die Mem0-Forschungsarbeit, veröffentlicht auf ECAI 2025 (arXiv:2504.19413), benchmarkte zehn verschiedene Ansätze zum KI-Gedächtnis und validierte den selektiven Extraktionsansatz – Speichern diskreter Fakten, Deduplizieren und Abrufen nur dessen, 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, Unternehmensressourcen und episodische/semantische Erinnerungen auf Organisations- und Benutzerebene vor, was die Idee validiert, dass die Qualität des Gedächtnisses genauso wichtig ist wie die Modellkapazität.

Der gemeinsame Nenner der meisten Frameworks ist, dass sie das Gedächtnis als Retrieval-Problem behandeln: Speichern Sie es irgendwo, fragen Sie es bei Bedarf ab, injizieren Sie es in den Kontext. Hermes macht das Gegenteil – das Gedächtnis wird nicht auf Abruf abgerufen, es wird beim 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 besteht aus 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 persistierenden Gedächtnisses: zwei Dateien, unter 3.600 Zeichen insgesamt, weniger als 1.300 Tokens. Es sieht bewusst klein aus, weil es das 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 unter 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 Ballast, kein „Am 5. Januar bat der Benutzer mich um…"

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 verwendet hauptsächlich Linux Ubuntu 22.04.
Der Benutzer deployt auf 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-Muster (Eingefrorener Schnappschuss)

Zu Beginn der Sitzung werden beide Dateien von der Festplatte geladen und als eingefrorener 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 unter 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 Überschriften, Nutzungszentusätze, Zeichenanzahlen und `§` (Punktum-Zeichen) als Trennzeichen. Einträge können mehrzeilig sein. Es ist so konzipiert, dass es vom Modell parsed werden kann, während es für Menschen lesbar bleibt.

Warum eingefroren? [Prefix-Caching](https://www.glukhov.org/de/llm-performance/). 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 Aufmerksamkeit nicht bei jeder Runde erneut über die gleichen Gedächtnis-Tokens.

Während einer Sitzung vorgenommene Änderungen 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 sich selbst im Kreis dreht – das Gedächtnis aktualisiert und dann auf seine eigene Aktualisierung in derselben Konversation reagiert.

### Zeichenlimits als Feature

2.200 Zeichen. 1.375 Zeichen. Das sind keine willkürlichen Limits. 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 der Nutzung und folgt dann einem Workflow:

1. Aktuelle Einträge aus der Fehlerantwort lesen
2. Entfern- oder konsolidierbare Einträge identifizieren
3. `replace` verwenden, um ähnliche Einträge zu kürzeren Versionen zusammenzuführen
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 Versuche von Prompt-Injektionen, Credential-Exfiltration, SSH-Backdoors und unsichtbaren Unicode-Zeichen.

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

---

## Teil 3: Wenn das Gedächtnis aktiviert wird — Trigger & Entscheidungen

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

Die Antwort ist: ständig, aber selektiv. Der Agent verwaltet sein eigenes Gedächtnis über das `memory`-Tool, und die Entscheidung zum Speichern wird durch eine Kombination aus expliziten Signalen und impliziten Mustern gelenkt.

### Schreib-Trigger: Wann entscheidet sich der Agent zum Speichern?

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

**Benutzerkorrekturen.** Wenn Sie den Agenten korrigieren, ist das ein Signal zum Erinnern. „Tu das nicht nochmal." „Nutze stattdessen dies." „Merke dir das." Dies sind explizite Anweisungen, das Gedächtnis zu aktualisieren.

Beispiel: Sie bitten den Agenten, eine Python-Umgebung zu konfigurieren. Er schlägt `pip` vor. Sie sagen: „Ich nutze `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: Nachdem Sie `poetry` in verschiedenen Projekten mehrmals verwendet haben, speichert der Agent es als Präferenz.

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

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

**Projekt-Konventionen.** Wie das Projekt strukturiert ist, welche Tools es nutzt, 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, überlegt der Agent, den Ansatz als Fähigkeit zu speichern oder zumindest zu notieren, was funktioniert hat.

**Tool-Sonderheiten 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
- Session-spezifisches Ephemera
- Informationen, die bereits in Kontextdateien sind (SOUL.md, AGENTS.md)

### Lese-Trigger: Wann erinnert sich der Agent?

Das Gedächtnis wird nicht abgerufen – es ist immer da. Aber es gibt unterschiedliche Zugriffsstufen.

**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. Dies ist das Kerndaten-Gedächtnis – immer aktiv.

**`session_search` (on-demand).** Wenn der Agent etwas aus vergangenen Konversationen finden muss, das nicht im Kerndaten-Gedächtnis ist, verwendet er das `session_search`-Tool. Dies fragt SQLite (`~/.hermes/state.db`) mit FTS5 Volltextsuche und Gemini Flash-Zusammenfassung ab.

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, 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

So wiegt der Agent „Ist das wert, erinnert zu werden?":

Ist dies eine Korrektur oder explizite Anweisung? JA → Speichern im Gedächtnis NEIN → Ist dies eine Präferenz oder ein Muster? JA → Speichern im Benutzerprofil NEIN → Ist dies ein Umgebungsfakt oder eine Konvention? JA → Speichern im Gedächtnis NEIN → Ist dies leicht neu zu entdecken? JA → Überspringen NEIN → Ist dies sitzungsspezifisch? JA → Überspringen NEIN → Speichern im Gedächtnis

Der Agent denkt nicht zu sehr darüber nach. Er speichert proaktiv, konsolidiert bei Volllast und vertraut darauf, dass die Zeichenlimits die Dinge kompakt 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](https://www.glukhov.org/de/rag/)-Pipelines und dem Arbeitsgedächtnis des Agenten – externes Retrieval 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 getragen. Externe Wissensdatenbanken sind seine Bibliothek – umfangreiche Referenzressourcen, die bei Bedarf 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):**

- Umfangreich, nur zur Referenz, on-demand 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 bei Bedarf zu. Er „erinnert" sie sich nicht – er schlägt sie nach.

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

**[Obsidian](https://www.glukhov.org/de/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Persönliche Notiz-Schreibe mit bidirektionalen Links. Der Agent verwendet die `obsidian`-Fähigkeit, um Notizen zu lesen, zu durchsuchen und zu erstellen. Obsidian ist Teil des breiteren [Personal Knowledge Management](https://www.glukhov.org/de/knowledge-management/)-Ökosystems, das Hermes als Bibliotheksressource nutzen kann.

**Notion/Airtable:** Strukturierte Datenbanken und Wikis, zugänglich über API. Der Agent fragt sie bei Bedarf ab.

**ArXiv:** Akademische Papier-Repositories. Der Agent durchsucht 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üssel: Kritische Erkenntnisse aus externen Datenbanken können *destilliert* werden in das interne Gedächtnis.

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äftlichen Kontext, der im Gedächtnis gespeichert ist.`

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

### Wann was verwendet wird

**Internes Gedächtnis für:**

- „Wem helfe ich?"
- „Was bevorzugt er/sie?"
- „Was haben wir gerade gelernt?"
- „Wie ist die Projektkonfiguration?"
- „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 nutzt 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` (hinzufügen), `replace` (ersetzen), `remove` (entfernen).

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

**`add`** — Fügt einen neuen Eintrag hinzu.

```python
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 Teilzeichenketten-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 Teilzeichenketten-Matching.

memory(action="remove", target="memory",
       old_text="vorübergehende Projektfakt")

Teilzeichenketten-Matching

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

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

Ziel-Speicher: memory vs user

Der target-Parameter bestimmt, welche Datei aktualisiert wird.

• memory — Persönliche Notizen des Agenten. Umgebungsfakten, Projekt-Konventionen, Tool-Sonderheiten, 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 ähnliche 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 Datenschicht verwendet.

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

Session Search vs. Persistentes Gedächtnis

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

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

Teil 6: Externe Gedächtnis-Provider — Alle 8 Optionen im Vergleich

Jenseits der integrierten Dateien MEMORY.md und USER.md unterstützt Hermes Agent 8 externe Gedächtnis-Provider-Plugins für persistentes, sitzungübergreifendes 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   # Interaktive Auswahl + Konfiguration
hermes memory status  # Prüfen, was aktiv ist
hermes memory off     # Externen Provider deaktivieren

Oder manuell in ~/.hermes/config.yaml:

memory:
  provider: openviking  # oder honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Provider-Vergleich

Detaillierte Aufschlüsselung

Honcho

Am besten für: Multi-Agenten-Systeme, sitzungübergreifenden 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 Kontextschicht hinzu. Es modelliert Konversationen als Peers, die Nachrichten austauschen – ein Benutzer-Peer plus ein KI-Peer pro Hermes-Profil, alle teilen einen Workspace.

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

Wichtige Konfigurationsparameter:

• contextCadence (Standard 1): Minimale Runden zwischen Aktualisierung der Basisebene
• dialecticCadence (Standard 2): Minimale Runden zwischen peer.chat() LLM-Aufrufen (1-5 empfohlen)
• dialecticDepth (Standard 1): .chat()-Durchläufe pro Aufruf (begrenzt 1-3)
• recallMode (Standard ‘hybrid’): hybrid (auto+tools), context (nur Injektion), tools (nur Tools)
• writeFrequency (Standard ‘async’): Flush-Timing: async, turn, session oder Integer N
• observationMode (Standard ‘directional’): directional (alle an) oder unified (gemeinsamer Pool)

Architektur: Zwei-Schichten-Kontextinjektion – Basisebene (Sitzungszusammenfassung + Darstellung + Peer-Karte) + dialektisches Supplement (LLM-Reasoning). Automatische Auswahl von Cold-Start vs. Warm-Prompts.

Multi-Peer-Mapping: Workspace ist eine gemeinsame Umgebung über Profile hinweg. Benutzer-Peer (peerName) ist eine globale menschliche Identität. KI-Peer (aiPeer) ist eins 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 gemeinsamem Workspace
hermes honcho sync                   # Backfillt KI-Peers für bestehende Profile

OpenViking

Am besten für: Selbst-gehostetes Wissensmanagement mit strukturierter Durchsuchung.

OpenViking bietet eine Dateisystemhierarchie mit gestaffeltem Laden. Es ist kostenlos, selbst-gehostet und gibt Ihnen volle Kontrolle über Ihre Gedächtnisspeicherung.

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 automatischer Extraktion.

Mem0 verarbeitet 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: Knowledge-Graph-basierten Abruf mit Entitätsbeziehungen.

Hindsight baut einen Knowledge Graph 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-fokusierte Setups mit ausschließlich lokaler Speicherung.

Holographic verwendet HRR (Holographic Reduced Representation) Algebra für die Gedächtniskodierung, mit Vertrauensbewertung für Gedächtniszverlässigkeit. 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 $20/Monat Kosten, 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: Bandbreitenbeschränkte Umgebungen mit Pre-Kompressions-Extraktion.

ByteRover komprimiert das Gedächtnis vor der Extraktion, reduziert den Bandbreitenverbrauch. 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-Zäunung und Sitzungsgraph-Ingest.

Supermemory bietet Kontext-Zäunung (Isolierung von Gedächtnis nach Kontext) und Sitzungsgraph-Ingest (Import ganzer Konversationshistorien). Es ist cloud-basiert und bezahlt, aber für Enterprise-Skalierung im Gedächtnismanagement ausgelegt.

Tools: 4 Tools für Gedächtnisoperationen.

Einrichtung:

hermes memory setup  # "supermemory" auswählen

Wie man wählt

• Brauchen Sie Multi-Agenten-Unterstützung? Honcho
• Wollen Sie selbst-gehostet und kostenlos? OpenViking oder Holographic
• Wollen Sie Zero-Config? Mem0
• Wollen Sie Knowledge Graphs? Hindsight
• Wollen Sie Delta-Kompression? RetainDB
• Wollen Sie Bandbreiteneffizienz? ByteRover
• Wollen Sie Enterprise-Features? Supermemory
• Wollen Sie Privacy (nur lokal)? Holographic

Für vollständige Profil-für-Profil-Provider-Konfigurationen und reale 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 benötigen.

Begrenztes Gedächtnis funktioniert besser. Hier ist der Grund.

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

Geschwindigkeit ist wichtig. 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 nicht besseres Gedächtnis. Es ist lauter Gedächtnis. Das Modell muss Signal von Rauschen unterscheiden, und das kostet Aufmerksamkeit – Aufmerksamkeit, die für die tatsächliche Aufgabe verwendet werden sollte.

Vergessen ist ein Feature. Menschliches 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 entlernen. Nicht nur vergessen, sondern aktiv veraltete Informationen entfernen.

So geht Hermes Agent damit um:

• 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.
• Sicherheitsscanning: Blockiert schädliche oder korrupte Einträge.

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

Memory Scaling

Databricks führte das Konzept von „Memory Scaling" ein: Performt 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 wert, erinnert zu werden. Der Agent muss Erkenntnisse extrahieren, nicht Logs.
2. Effektives Retrieval: Abrufene Erinnerungen müssen relevant sein. Rauschen verschlechtert die Leistung.
3. Generalisierung: Erinnerungen sollten Muster sein, keine Spezifika. „Benutzer bevorzugt Python" skaliert. „Benutzer führte Befehl X zum 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 zum wettbewerbsfähigen Graben in der agentischen KI – 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 behalten, was verwerfen, wie man es sofortig 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 mit sich trägt.

Fazit

Das Gedächtnissystem von Hermes Agent ist bewusst simpel: zwei Dateien, feste Zeichenlimits, keine Retrieval-Pipeline, keine Vektordatenbank und keine Latenz pro Abfrage. Was wie eine Einschränkung klingt, ist der ganze Punkt.

Es funktioniert, weil es das Gedächtnis so 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, in den System-Prompt gewebt vom ersten Token jeder Sitzung an.

Externe Gedächtnis-Provider erweitern dieses System für Benutzer, die mehr brauchen: Knowledge Graphs, Multi-Agenten-Unterstützung, selbst-gehostete Speicherung, Enterprise-Features. Aber der Kern bleibt derselbe: 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 in das interne 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 an das erinnert, was wichtig ist.

Hermes Agent wurde von Nous Research im Februar 2026 veröffentlicht und erreichte bis April 2026 (v0.9.0) über 64.000 GitHub-Sterne, 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.