Zum Inhalt springen

Wissensbasis

Persistentes Agenten-Memory

Persistentes Agenten-Memory ist Zustand, den ein Agent außerhalb seines Kontextfensters schreibt und in einer späteren Sitzung zurückliest, als Notizen, Memory-Dateien oder Knowledge Graphs. Schwierig ist das Vergessen: Memory, das nur wächst, enthält am Ende nichts Nützliches mehr.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Wir halten Zustand aus der Unterhaltung heraus. Pläne, Fortschritt und Recherche liegen in Dateien, und der externe Plan ist die Quelle der Wahrheit (öffnet in einem neuen Tab). Ein Fix geht mit dem Update seiner Regel im selben Commit raus. Denn ein Incident ist der günstigste Moment (öffnet in einem neuen Tab), ins Memory der Factory zu schreiben.

Reichere Formen gehen über eine Notizdatei hinaus. Sie ergänzen temporale Knowledge Graphs, gespeicherte Reasoning-Traces und eine menschliche Freigabe, bevor etwas die Memory-Datei erreicht.

Wie erinnert sich ein Agent über eine Sitzung hinaus?

Agenten sind von Haus aus zustandslos, Memory muss man gezielt einbauen. Die übliche Taxonomie trennt Kurzzeit- von Langzeit-Memory. Das Kurzzeit-Memory ist das Kontextfenster selbst und wird bei jedem Aufruf neu aufgebaut. Das Langzeit-Memory liegt in externen Speichern und teilt sich in drei Arten. Semantisches Memory hält Fakten (“user prefers Python”). Episodisches Memory hält vergangene Ereignisse, praktisch echte Few-Shot-Beispiele. Prozedurales Memory hält gelernte Regeln dafür, wie Aufgaben auszuführen sind. Geschrieben wird entweder explizit im Ablauf der Interaktion oder implizit durch Hintergrundprozesse. Explizit wirkt sofort, kostet aber Latenz und vermischt Memory-Logik mit Agenten-Logik. Implizit spüren die Nutzer:innen keine Latenz, dafür ist der Stand kurz veraltet. Die schweren Probleme sind die Relevanz beim Abruf, aufgeblähtes Memory und das Vergessen. Ein Agent, der sich an alles erinnert, erinnert sich irgendwann an nichts Nützliches mehr. Vergessen heißt, Verdrängungsregeln zu entwerfen, die Rauschen verwerfen, ohne entscheidenden Kontext zu löschen. All das erschwert die verzögerte Rückkopplung: Eine fehlerhafte Memory-Strategie zeigt sich erst mit der Zeit (Memory in Agents, Make LLMs remember (öffnet in einem neuen Tab)).

Was als episodisches Memory gespeichert wird, wirkt nicht symmetrisch. Vergangene Fehlschläge helfen einem Agenten, aus lokalen Minima auszubrechen. Vergangene Erfolge machen ihn eher faul: Er gleicht das Muster der früheren Antwort ab und plappert sie nach, statt neu zu denken (Chroma - Context Engineering for Engineers (öffnet in einem neuen Tab)). Dieselbe Logik spricht dafür, fehlgeschlagene Aktionen im laufenden Kontext zu lassen, statt sie zu tilgen.

Das einfachste robuste Muster sind strukturierte Notizen. Der Agent schreibt regelmäßig Notizen außerhalb des Kontextfensters und holt sie später zurück, als To-do-Liste oder als NOTES.md. So hält er Fortschritt und Abhängigkeiten über Dutzende Tool Calls fest und übersteht Resets des Kontexts. Anthropic liefert das als dateibasiertes Memory-Tool aus. Sein Pokémon spielender Agent bleibt über mehrere Stunden kohärent, allein durch selbst geschriebene Notizen (Anthropic - Effective Context Engineering for AI Agents (öffnet in einem neuen Tab)). Hook-basierte Context Bundles erweitern das zum Nachspielen einer Sitzung. Ein Protokoll der Tool Calls, an das nur angehängt wird, ist auf die wesentlichen Lese- und Schreibvorgänge gekürzt. In einem frischen Fenster stellt es grob 60-70 % des Verständnisses des vorigen Agenten wieder her (Elite Context Engineering with Claude Code (öffnet in einem neuen Tab), 8. September 2025).

Viel kopierte Harness-Prompts schreiben das Muster fest. Sie sichern Präferenzen der Nutzer:innen in einer festen Memory-Datei, die der Agent anlegt und bei jeder Aufgabe neu liest (Beast Mode (öffnet in einem neuen Tab)). Prozedurales Memory lässt sich auch nach Ergebnis gewichten. Ein Review-Agent erhöht das Gewicht von Vorschlägen, die Menschen annehmen, und senkt es bei ignorierten. So taucht ein zehnmal abgelehnter Fix nicht mehr auf (Qodo - Why More Context Makes Your Agent Dumber (öffnet in einem neuen Tab)).

Wer reicheren Zustand als Notizen braucht, landet an der Front bei strukturiertem und temporalem Memory. Zep argumentiert aus Produktiveinsätzen. “Agent memory” als Fakten aus dem Chatverlauf deckt nur einen Bruchteil dessen ab, was eine Organisation über alle Kontaktpunkte hinweg über eine Person weiß. Deshalb modelliert Zep Memory als temporale Knowledge Graphs. Sie halten fest, was wahr ist, und dazu, was wann wahr war und wie es sich geändert hat. Die Engineering-Kosten sind real. Die Auflösung von Entitäten in unsauberen Daten verlangte Reflexionsmechanismen und viel Arbeit an der Pipeline, bis sie im Produktivbetrieb verlässlich lief. Beispiele sind “Netflix” und “netflix” als getrennte Entitäten oder zwei Verweise auf ein Elternteil, die auf verschiedene Personen zeigen (Zep - What is Context Engineering, Anyway? (öffnet in einem neuen Tab)). Zep warnt außerdem, dass Subagents mit zerstückeltem Kontext inkohärente Ergebnisse liefern. Ein Beispiel ist Cognitions Flappy Bird, bei dem getrennt gebriefte Agenten unpassende Teile bauten. Der Kontext muss also geteilt werden, sonst sollte man die Aufgabe gar nicht aufteilen (Zep - What is Context Engineering, Anyway? (öffnet in einem neuen Tab)).

Consumer-Memory im Produktivbetrieb muss keine Vektordatenbank bedeuten. Ein Reverse Engineering von ChatGPTs Memory, aus dem Verhalten erschlossen und nicht offiziell, beschreibt gar kein RAG über den Gesprächsverlauf. Es beschreibt geschichtete Speicher. Dauerhafte Fakten über Nutzer:innen werden nur geschrieben, wenn jemand “remember this” sagt oder das Modell einen passenden Fakt erkennt. Kontinuität über Chats hinweg liefern vorab berechnete, schlanke Digests der eigenen Nachrichten der Nutzer:innen statt Retrieval. Dazu kommt eine flüchtige Metadaten-Schicht pro Sitzung (Gerät, Zeitzone, Tarif), die nie bestehen bleibt. Das laufende Fenster rollt nach Token-Zahl ab, nicht nach Zahl der Nachrichten (I Reverse Engineered ChatGPT’s Memory System (öffnet in einem neuen Tab)). Wer den Graphen will, bekommt das Muster bei Zep und Cognee als Dienst: Daten aufnehmen, in einen Graphen überführen, abfragen. Teams übernehmen das, ohne die Pipeline selbst zu bauen. Cognee beschreibt seinen Speicher als automatisch extrahierte Ontologie oder Weltmodell über den Daten einer Organisation (Wizard of Graph – Graph RAG talk (öffnet in einem neuen Tab); Cognee (öffnet in einem neuen Tab), Anbieter).

Zwei Richtungen führen Memory über Notizen und Fakten hinaus. Coding-Agents wechseln schnell, deshalb halten manche Praktiker:innen Instruktionen in einem portablen Speicher statt in der Konfiguration eines Tools. Dieser Speicher ist ein MCP-Knowledge-Graph, und beim Wechsel des Agenten geht kein gelerntes Verhalten verloren. Ein einzelner Satz wie “we are done” entfaltet sich zu einer gemerkten, mehrstufigen Release-Kette, die zu Beginn jeder Sitzung nachgespielt wird (DevOps Toolkit - agent memory MCP workflow (öffnet in einem neuen Tab)). Wo Memory bisher nur Fakten hielt, erweitern Context Graphs es außerdem um das Reasoning. Sie halten Policies, Regeln und frühere Entscheidungen mit ihrer Begründung, aufgeteilt auf Kurzzeit, Langzeit und eine eigene Reasoning-Ebene. So kann ein Agent eine Wahl gegen Präzedenzfälle und gegen die Kosten eines Irrtums abwägen. Ein Agent schlägt Optionen mit Vor- und Nachteilen vor. Ein zweiter entscheidet, ob er handeln darf oder eskalieren muss, und schreibt das Ergebnis als Präzedenzfall zurück (Neo4j - Context Graphs for Agentic Decision-Making (öffnet in einem neuen Tab)).

Der Talk ordnet diese Entscheidung in fünf Stufen unter menschlicher Aufsicht. Framing benennt das Ziel, das kausale Bild und was in der Umgebung auf dem Spiel steht. Guidance holt Präzedenzfälle und Regeln. Assessment wägt das Risiko gegen Wert, Umkehrbarkeit und die Kosten eines Fehlers ab und erzeugt den Vorschlag. In Action prüft der zweite Agent seine Befugnis und handelt dann oder eskaliert. Outcome hält fest, was erwogen wurde und was nicht, damit der Eintrag als Präzedenzfall für die nächste Entscheidung dient (Neo4j - Context Graphs for Agentic Decision-Making (öffnet in einem neuen Tab)). Neo4j Labs veröffentlicht die drei Ebenen als Bibliothek unter Apache-2.0, neo4j-agent-memory. Das Kurzzeit-Memory hält Unterhaltungen als geordnete, durchsuchbare Nachrichten pro Sitzung. Das Langzeit-Memory hält typisierte Entitäten, Fakten und Präferenzen als Graph, der über Sitzungen hinweg wächst. Das Reasoning-Memory hält Traces von Gedanken, Tool Calls mit Argumenten und Ergebnissen und ob jeder Weg Erfolg hatte. So kann der Agent nach einem ähnlichen früheren Problem suchen, bevor er ein neues löst (Neo4j Labs - Understanding the three memory types (öffnet in einem neuen Tab), Stand September 2026). Das Langzeit-Memory wird per Graph-Traversierung und semantischer Suche abgefragt. Ein einziger Aufruf, get_context(), setzt das gespeicherte Memory zu kombiniertem Kontext für einen Prompt zusammen (neo4j-labs - agent-memory (öffnet in einem neuen Tab), Stand September 2026).

Ein Open-Source-Agentenprodukt setzt eine menschliche Freigabe zwischen das Modell und die Memory-Datei. In exxperts, gebaut auf einem Fork von pi, wächst das Memory eines Raums in drei Schritten. Remember schlägt am Ende einer Unterhaltung eine Zusammenfassung vor. Memorize arbeitet die wartenden Unterhaltungen in Notizen ein, und Review räumt die Notizen Thema für Thema auf. Hinter jedem Schritt stehen Modellprozesse ohne Tools, die nur eine kurze Liste von Änderungen vorschlagen können. Die Person gibt den Vorschlag frei, und nur der Freigabe-Endpoint schreibt die Memory-Datei (EXXETA - exxperts memory documentation (öffnet in einem neuen Tab), Version 0.14.1, Oktober 2026). Das erklärte Ziel ist Memory, das dichter wird statt bloß größer. Ein neuer Punkt aktualisiert oder ersetzt die Notiz, die ihn schon enthält. Eine Review-Änderung, deren Text länger wird als das Ersetzte, wird abgelehnt. Memorize und Review löschen nie eine Notiz. Verlässt eine Notiz das Memory, wandert sie mit dem Grund dafür in ein Archiv (EXXETA - How exxperts works (öffnet in einem neuen Tab), Version 0.14.1). Ein Budget pro Raum, standardmäßig 20.000 geschätzte Tokens, entscheidet, welche Notizen dorthin wandern. Angeheftete Notizen und offene Punkte bleiben (EXXETA - exxperts memory documentation (öffnet in einem neuen Tab)).

Den Abruf erledigt in diesem Produkt eine Stichwortsuche über die Notizen, das Archiv und die Transkripte gemerkter Unterhaltungen, gerankt mit BM25. Die Wörter werden vor dem Indexieren vereinheitlicht, damit deutsche und englische Schreibweisen zusammenfinden. “Überweisung” findet “Ueberweisung”, “1.6.2026” findet “2026-06-01” und “55.000” findet “55,000” (EXXETA - exxperts memory search index (öffnet in einem neuen Tab)). Eine Suche nach Bedeutung lässt das Projekt bewusst weg. Embeddings bräuchten ein zweites Modell oder einen heruntergeladenen Index und kosteten bei jedem Speichern Tokens oder Plattenplatz. Wo sie nichts finden, ist das zudem schwerer zu erklären als ein Wort, das nicht dastand. Der Raum ist angewiesen, mit anderen Worten erneut zu suchen, bevor er sagt, dass er etwas nicht weiß (EXXETA - exxperts memory documentation (öffnet in einem neuen Tab)).

Das Projekt hat das Design auf LongMemEval-S gemessen, einem öffentlichen Benchmark mit langen Chatverläufen. Es nutzte eine feste Stichprobe von 50 Fragen. Zu jeder Frage gehören etwa 48 Unterhaltungen und 115.000 Tokens Verlauf. Das Raum-Memory beantwortete 43 richtig, dasselbe Modell mit dem ganzen Verlauf im Prompt 41. Das Raum-Memory brauchte etwa 33.000 Tokens pro Frage gegenüber etwa 168.000. Dazu kam ein einmaliger Aufbau von etwa 1,15 Millionen Tokens pro Verlauf. Claude Sonnet 5 antwortete, legte das Memory an und bewertete. Die Grenzen nennt das Projekt selbst: Bei 50 Fragen ist 43 gegen 41 ein Unentschieden, und die Stichprobe diente auch in der Entwicklung. Dasselbe Modell antwortet und bewertet. Zudem misst der Benchmark private Chats mit einem geskripteten Nutzer, keine Projektarbeit (EXXETA - exxperts memory documentation (öffnet in einem neuen Tab), Selbstauskunft des Projekts, Stand Oktober 2026).

Memory-Dateien verfallen, und der Agent räumt sie nicht auf. Ein Katalog aus der Praxis listet die Formen. Derselbe Fakt steht mehrmals in anderen Worten da, zwei Einträge widersprechen sich, Einträge bleiben vage. Andere Regeln betreffen eine Bibliothek, die vor Monaten entfernt wurde. Regel- und Memory-Dateien überschneiden sich, derselbe Fakt kann also in beiden stehen, und der Katalog pflegt beide gemeinsam. Die Routine führt Duplikate zusammen, entscheidet jeden Widerspruch und löscht den unterlegenen Eintrag. Ein veralteter Eintrag wird ohne Archiv gelöscht, sobald die Git-Historie oder ein ADR die Entscheidung festhält. Denn ein Archiv, das niemand pflegt, landet später wieder im Kontext. Ein Widerspruch zwischen zwei Dateien ist in Ordnung, wo jede Datei ihren Geltungsbereich nennt, etwa bei Testing-Notizen für Frontend und Backend (Augmented Coding Patterns - Memory Grooming (öffnet in einem neuen Tab)). Auch das Erfassen hat sein eigenes Ritual. Am Ende einer Sitzung listet der Agent auf, was die Sitzung gelehrt hat, und schlägt für jeden Punkt ein Ziel vor. Eine Verhaltensregel kommt in die immer geladenen Regeln, ein Projektfakt in ein Referenzdokument. Eine wiederkehrende Qualitätskorrektur wird zum Hook, ein wiederholter Prozess zum Skill. Die Person gibt die Zuordnung frei (Augmented Coding Patterns - Learning Loop (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Memory mit Freigabe

Memory-Bibliotheken