Das Gedächtnis von KI-Agenten ist keine Datenbank: Was gespeichert, abgerufen und vergessen werden sollte.
Warum das Gedächtnis von KI-Agenten ein Relevanzproblem darstellt: Wie Kontext, Gedächtnis, Zustand und RAG voneinander unterscheiden, was gespeichert werden sollte, wie der Umfang definiert wird, wie das Gedächtnis zeitlich begrenzt und überprüft wird – und warum Vergessen eine Eigenschaft ist.
Quellen: AI Agent Memory Is Not a Database
Das Gedächtnis von KI-Agenten wird in der Regel als Funktion dargestellt, die sie intelligenter macht: Sie sollen vergangene Gespräche, Benutzerpräferenzen, frühere Arbeitsabläufe, das, was zuletzt funktioniert hat, sowie Fakten aus Dokumenten behalten können. Der Traum ist ein Agent, der alles kennt, was er je gesehen hat. Genau da beginnt die Verwirrung, denn ein Agent muss nicht alles behalten, und Gedächtnis ist nicht dasselbe wie Datenspeicherung.
Eine Datenbank kann Millionen von Einträgen speichern, ohne dass einer davon im Gedächtnis eines Agenten landet. Die ingenieurtechnischen Fragen lauten anders: Was sollte gespeichert werden – und für wie lange? Wo befindet es sich, wann wird es abgerufen, wann gelöscht? Und handelt es sich überhaupt um Gedächtnis? Aus dieser Perspektive ist das Gedächtnis weniger ein Speicherproblem als vielmehr ein Relevanzproblem.
Warum das Konzept „Alles speichern“ nicht funktioniert
Stellen Sie sich einen Agenten vor, der eine lang andauernde Aufgabe ausführt. In der ersten Phase lernt er das Ziel des Benutzers, das ausgewählte Dokument, einige extrahierte Werte, das Ergebnis eines Tools, eine vorläufige Entscheidung sowie das Ergebnis der Validierung. Danach folgt eine weitere Phase, und wieder eine – so wächst die Menge an Informationen stetig an.
Die einfachste Umsetzung besteht darin, alles zu speichern: Jene Nachrichten werden hinzugefügt, jedes Tool-Ergebnis abgelegt, und beim nächsten Aufruf wird alles erneut gesendet. Das funktioniert eine Weile. Doch dann wächst der Kontextumfang, die Reaktionszeiten verlangsamen sich, die Kosten steigen, veraltete Informationen beeinflussen neue Entscheidungen, und Informationen, die bereits nicht mehr relevant sind, befinden sich weiterhin im Prompt. Im Grunde wird das Modell gefragt, welche von fünfzig Informationen gerade wichtig sind. Zu diesem Zeitpunkt ist die Speicherkapazität zu Lärm geworden.
Vier Begriffe, die oft verwechselt werden
Diese Konzepte lösen unterschiedliche Probleme, und die Konzeption von Agenten verbessert sich, sobald sie voneinander getrennt werden.
Kontext ist das, was das Modell in diesem Moment wissen muss: die aktuelle Anfrage, die ausgewählten Belege, einige frühere Entscheidungen sowie die Ausgabe relevanter Tools. Er ist vorübergehend und dient dem aktuellen Denkprozess.
Gedächtnis sind Informationen, die das System später wieder benötigen könnte, wie z. B. eine Benutzerpräferenz, eine von jemandem bestätigte Entscheidung, eine nützliche Zusammenfassung oder das Ergebnis einer vorherigen Aufgabe. Es kann länger bestehen als eine einzelne Modellaufruf.
Zustand gibt an, wo sich der Arbeitsablauf befindet. Es kann ein Status wie QUEUED, RUNNING, WAITING_FOR_TOOL, RETRYING oder COMPLETED sein, oder feinere Flags wie document_extracted = true, analysis_completed = true und report_generated = false. Der Zustand ermöglicht es dem System, fortzufahren. Er ist keine Erkenntnis.
RAG bedeutet, Wissen aus einer externen Quelle abzurufen, wenn es benötigt wird: Dokumente, Datenbanken, Richtlinien, Berichte, interne Wikis, Vektorlagern. Diese Informationen befinden sich bereits anderswo. Der Agent muss sie nicht dauerhaft merken, sondern lediglich bei Bedarf finden – was ein anderes Problem darstellt.
Kurzzeitgedächtnis
Das Kurzzeitgedächtnis ist das Arbeitsset. Menschen, die ein Problem lösen, behalten bestimmte Fakten im Kopf und werfen den größten Teil davon nach Abschluss weg; Agenten haben denselben Bedarf. Während eines Workflows kann ein Agent die aktuelle Anfrage, das ausgewählte Dokument, jüngste Tool-Ausgaben, Zwischenergebnisse, frühere Entscheidungen sowie den Fortschritt der Aufgabe nutzen. All das ist im Moment wichtig, kann aber morgen fast wertlos sein. Eine gute Definition ist der kleinste Satz an Informationen, der zur Fortsetzung der aktuellen Aufgabe erforderlich ist – und nicht alles, was seit ihrem Beginn geschehen ist.
Das Langzeitgedächtnis muss sich seinen Platz verdienen
Das Langzeitgedächtnis umfasst das, was man absichtlich aufbewahrt, weil es möglicherweise wieder nützlich sein kann. Beispiele hierfür sind eine ausgesprochene Präferenz wie „Kurze Berichte bevorzugen“, eine festgelegte Geschäftsentscheidung wie „Dieses Berichtsformat für zukünftige Analysen verwenden“ oder eine bestätigte Tatsache wie „In diesem Projekt gilt System A als Quelle der Wahrheit“.
Der Standard sollte hier höher liegen. Bevor etwas gespeichert wird, sollte man prüfen, ob es dazu beitragen kann, zukünftige Entscheidungen zu verbessern. Falls nicht, sollte es weggelassen werden – schließlich hat das Langzeitgedächtnis neben der Speicherung noch weitere Kosten: Jeder Eintrag ist etwas, das das System später abrufen, vertrauen, pflegen und falsch interpretieren könnte.
RAG ist kein Langzeitgedächtnis
Nehmen wir an, es gibt 20.000 interne Dokumente in einem Vektorindex, die vom Agenten durchsucht werden können. Das ist keine Agentenerinnerung. Die Dokumente stellen das Wissen dar, und RAG ist die Methode, um darauf zuzugreifen. Der Agent sollte nicht jedes Dokument im Gedächtnis speichern, sondern nur wissen, wie er das richtige findet. Der gesunde Ablauf ist folgender: Der Agent benötigt Informationen, durchsucht die Wissensquelle, holt relevante Belege ab und verwendet sie. Der ungesunde Ablauf besteht darin, das gesamte Wissen in das Gedächtnis zu kopieren. Das Wissen kann enorm sein, während das Arbeitsgedächtnis klein bleiben muss.
Zustand ist oft wichtiger als Gedächtnis
Viel von dem, was als Agentenmemorie bezeichnet wird, ist in Wirklichkeit der Zustand des Arbeitsablaufs. Angenommen, ein Agent hat die Extraktion eines Dokuments abgeschlossen, Beweise abgerufen und diese analysiert, wobei der Bericht noch erstellt werden muss. Wenn der Prozess vor Fertigstellung des Berichts abstürzt, muss das System wissen, wo es fortsetzen soll. Das ist der Zustand. Das Modell sollte nicht daran erinnert werden müssen, dass die Analyse abgeschlossen ist, da die Anwendung es bereits weiß.
Aufgabenstatus, Anzahl der Wiederholungsversuche, Kontrollpunkte, Job-IDs, abgeschlossene Schritte sowie ausstehende Aktionen gehören im Allgemeinen zum deterministischen Anwendungsstatus und nicht in ein LLM-Gespräch. Eine gute Regel: Wenn Software etwas genau wissen kann, soll sie es auch genau speichern. Das Modell sollte nicht für das Merken der Wahrheiten des Arbeitsablaufs verantwortlich sein.
Nicht alles, was passiert ist, verdient einen Platz
Stellen Sie sich vor, ein Tool gibt einen 500 Zeilen umfassenden JSON-Datenstrom zurück. Braucht der nächste Schritt wirklich alle 500 Zeilen? Wahrscheinlich reichen bereits ein oder zwei Felder aus, wie account_status = ACTIVE, total_balance = 120000 oder document_found = true. Die Rohdaten können in Protokollen oder der Speicherung bleiben, während im Arbeitsspeicher nur die relevanten Teile gespeichert werden müssen.
Auch Gespräche funktionieren auf dieselbe Weise. Wenn ein Benutzer und ein Agent zehn Nachrichten benötigen, um eine Anforderung zu klären, ist eine kurze Notiz wie „Der Benutzer möchte den Bericht nach Kategorie gruppieren und nach Schweregrad sortiert haben“ nützlicher als jedes Mal den gesamten Austausch erneut abzuspielen.
Was sollte man sich merken
Es gibt keine universelle Lösung für jedes System, aber einige Kategorien eignen sich in der Regel gut:
- Stabile Präferenzen: Ausgabeformat, Sprache, Berichtsstil.
Vor was man beim Speichern vorsichtig sein sollte
- Jede Modellantwort. Die meisten Zwischenschritte sind später nicht nützlich.
- Jeder Tool-Ausgabe, die groß sein kann, veraltet ist oder nur für einen bestimmten Moment relevant ist.
- Vorübergehende Fehler. Gestriges Timeout sollte nicht zum Kontext von morgen werden.
- Nicht überprüfte Modellannahmen – das Risikohöchste von allen. Wenn ein Modell angibt, dass ein Dokument „scheinbar auf Unternehmen A verweist“ und niemand das überprüft, kann dessen Speicherung eine schwache Vermutung in eine dauerhafte Tatsache verwandeln, auf der später weitergebaut wird.
- Sensible Daten ohne klaren Grund für die Aufbewahrung. Der Speicher sollte einen Zweck haben.
Der Speicher kann falsch liegen
Dies gehört zu den größten Problemen des Langzeitgedächtnisses. Ein System speichert beispielsweise, dass die Berichtswährung eines Kunden USD ist, und sechs Monate später ändert sich diese Präferenz, während der alte Eintrag weiterhin vorhanden bleibt. Was hat Vorrang? Der Speicher benötigt ein Konzept der Aktualität. Einige Fakten bleiben jahrelang gültig, andere nur Minuten lang – ein gutes System unterscheidet zwischen ihnen.
Ein Lebenszyklus, nicht Speichern und Vergessen
Das Speichern von Informationen sollte nicht ewig auf dem Weg des Speicherns und Behalten bestehen bleiben. Ein realistischerer Zyklus umfasst die Erfassung, Überprüfung, Speicherung, Abrufung, Nutzung sowie anschließend die Aktualisierung, Fälligkeit oder Löschung. Um dies zu unterstützen, benötigt jeder Eintrag möglicherweise ein Erstellungsdatum, eine Herkunft, einen bestätigten oder unbestätigten Status, ein Datum der letzten Nutzung, eine Fälligkeitsregel sowie einen Link zu einem neueren Wert, der ihn ersetzt hat. Das Schreiben ist nur die eine Hälfte der Arbeit – die Wartung ist die andere.
Die Quelle ist wichtig
Nehmen wir an, es gibt zwei Erinnerungen. Die eine besagt, dass das bevorzugte Format PDF ist, und der Benutzer hat dies gestern ausdrücklich bestätigt. Die andere besagt, dass das bevorzugte Format Excel sein könnte, was ein LLM vor sechs Monaten geschlossen hat. Sie sollten nicht denselben Gewichtungsfaktor haben, weshalb Erinnerungen idealerweise die Herkunft festhalten sollten: Wurde sie vom Benutzer bereitgestellt, vom System erzeugt, von einem Modell geschlossen, aus einem Dokument abgerufen, von einer Tool zurückgegeben oder von elsewhere kopiert? Dieser Kontext gibt dem System an, inwieweit es dieser Erinnerung vertrauen kann.
Auch das Vertrauensniveau ist wichtig
"Der Vertrag scheint im Juni zu enden" ist eine andere Art von Aussage als "Vertragsende: 30. Juni 2027", die aus einem strukturierten Feld abgerufen wird. Die eine kann als hochgradig zuverlässig angesehen werden, während die andere Überprüfung erfordert; dadurch verwandeln sich vage Schlussfolgerungen nicht stillschweigend in Fakten. Eine nützliche Langzeitdatenaufzeichnung enthält oft mehr als nur einen Wert – sie kann außerdem Quelle, Zuverlässigkeitsgrad, Zeitstempel, Bereich und Status enthalten, was eine spätere Abrufung deutlich sicherer macht.
Zusammenfassungen sind Interpretationen
Zusammenfassungen gehören zu den besten Methoden, um das Arbeitsgedächtnis klein zu halten. Speichern Sie beispielsweise „Der Benutzer wünscht eine prägnante technische Erklärung mit Beispielen“ anstelle eines gesamten Gesprächs oder „Drei Erkenntnisse bestätigt, eines ungelöst“ anstelle jeder Analyseebene. Der Haken ist, dass eine Zusammenfassung eine Interpretation darstellt und wichtige Details weglassen kann. Bei wichtigen Arbeitsabläufen sollten Sie die Zusammenfassung mit einem Verweis auf die ursprünglichen Belege kombinieren. Die Zusammenfassung sorgt dafür, dass der Agent effizient arbeitet, während die ursprünglichen Unterlagen zur Verfügung stehen, falls etwas überprüft werden muss.
Erstellen Sie keine zweite Quelle der Wahrheit
Falls die Kundendaten bereits in der Hauptkundendatenbank gespeichert sind, ist es in der Regel ein Fehler, sie in das Langzeitgedächtnis des Agenten zu kopieren. Bald stimmen die beiden Kopien nicht mehr überein, und niemand weiß, welche richtig ist. Besser ist es, das autoritative System als Quelle zu nutzen, wenn es benötigt wird, und das Ergebnis in den Kontext des Agenten einzuspeisen. Duplizieren Sie ein Datensystem nur aus einem sehr klaren Grund. Die Prüfung besteht darin, ob die Informationen zuverlässig aus ihrer Quelle abgerufen werden können anstatt im Gedächtnis behalten zu werden. Wenn dem so ist, kann das Abrufen besser sein als das Merken.
Bereich
Wenn mehrere Benutzer, Organisationen oder Arbeitsabläufe dieselbe Agent-Infrastruktur teilen, sind Grenzen für den Speicherverbrauch notwendig. Der Speicher eines Benutzers darf nicht im Kontext eines anderen erscheinen, eine Organisation sollte keine Daten einer anderen abrufen, und ein Arbeitsablauf benötigt möglicherweise nicht die Zwischenergebnisse eines anderen. Im Allgemeinen erfordert der Speicher eine explizite Gültigkeitsbereichsangabe, wie z. B. global, Organisation, Benutzer, Konversation, Arbeitsablauf oder Aufgabe. Je enger der Gültigkeitsbereich ist, desto geringer ist die Wahrscheinlichkeit, dass irrelevante Informationen in eine unzusammenhängende Entscheidung eindringen.
Das Abrufen von Speicherinhalten ist ein Suchproblem
Mit 500 gespeicherten Erinnerungen sollte niemand alle davon in jeden Prompt aufnehmen. Wir kehren damit zum Kontextproblem zurück – daher benötigt die Abrufung von Erinnerungen einen eigenen Ablauf: Man betrachtet die aktuelle Aufgabe, bestimmt, welche Art von Erinnerung relevant ist, filtert nach Benutzer, Arbeitsablauf und Organisation, sucht, bewertet, wählt aus und fügt die relevanten Erinnerungen zum arbeitenden Kontext hinzu. Deshalb sind Memory-Engineering und Kontextengineering so eng miteinander verbunden: Die Erinnerungen bestimmen, was später verfügbar sein könnte, während das Kontextengineering entscheidet, was im Moment genutzt wird.
Schreiben Sie weniger, holen Sie bessere Informationen ab
Anstatt zu fragen, was noch gespeichert werden kann, sollte man sich fragen, welche Informationen genug zukünftigen Wert haben, um ihr Speichern zu rechtfertigen. Anstatt zu fragen, wie viel Speicherplatz im Prompt vorhanden ist, sollte man prüfen, welche Erinnerung für diese Entscheidung relevant ist. Eine gute Erinnerungsarchitektur sollte in der Regel dafür sorgen, dass das System weniger sieht – schließlich sind irrelevante Erinnerungen einfach nur irrelevanter Kontext.
Beobachtbarkeit
Nehmen wir an, ein Agent gibt eine seltsame Antwort. Das heruntergeladene Dokument scheint in Ordnung zu sein und der Tool-Aufruf war erfolgreich, doch die Antwort ist falsch, und schließlich stellt jemand fest, dass eine alte Erinnerung die Entscheidung beeinflusst hat. Ohne Sichtbarkeit bezüglich des Abrufs von Erinnerungen ist es sehr schwierig, Fehler zu beheben. Für jeden Lauf ist es hilfreich, zu protokollieren, welche Erinnerungen abgerufen wurden und warum, ihre Herkunft und ihr Alter, der bestätigte Status, ob sie in den endgültigen Kontext aufgenommen wurden und ob sie die Ausgabe verändert haben. Dadurch wird aus dem versteckten Verhalten der Erinnerungen etwas, das überprüft werden kann.
Eine realistischere Architektur
Anstatt dass alles in die Erinnerungen fließt und anschließend zum Agenten gelangt, stellen Sie sich Folgendes vor: Ein Benutzer oder eine Aufgabe tritt ein, der Workflow-Zustand wird abgefragt, und das System entscheidet, welche Informationen benötigt werden. Anschließend zieht es die Informationen aus verschiedenen Quellen ab:
- Arbeitskontext für das, was gerade benötigt wird, wie die aktuelle Anfrage, das neueste Tool-Ergebnis und die aktuelle Entscheidung.
- Kurzfristiges Gedächtnis für das, was im Rahmen dieses Workflows benötigt wird, wie eine Aufgabenübersicht, vorläufige Erkenntnisse und kürzliche Entscheidungen.
- Langfristiges Gedächtnis für das, was zukünftigen Workflows helfen könnte, wie eine stabile Präferenz, ein bestätigter Fakt oder ein historisches Ergebnis.
- Wissen und RAG für Informationen, die an anderer Stelle vorhanden sind, wie Dokumente, Richtlinien, Berichte und Datenbanken.
- Anwendungsstatus für deterministische Informationen wie Status, Kontrollpunkte, Anzahl der Wiederholungsversuche und abgeschlossene Schritte.
Danach wird der aktuelle Kontext gefiltert, gerankt und zusammengestellt, damit der Agent schlussfolgern kann. Die einfache Bezeichnung all dessen als „Gedächtnis“ verdeckt die Struktur.
Fragen, die vor dem Hinzufügen einer Gedächtnisfunktion gestellt werden sollten
- Wird dies einer zukünftigen Aufgabe helfen? Wenn nicht, sollte es nicht gespeichert werden.
Die Antworten auf diese Fragen sind in der Regel wichtiger als die Wahl der Speicheldatenbank.
Vergessen ist eine Eigenschaft
Gute Erinnerungsfähigkeit bedeutet nicht, sich an alles zu erinnern. Ein nützlicher Agent sollte viel vergessen: vorübergehende Details, alte Ergebnisse von Werkzeugen, unoverprüfte Annahmen, veraltete Fakten sowie Schlussfolgerungen, die nicht mehr relevant sind. Mehr Speicherkapazität macht ein System nicht automatisch intelligenter – manchmal gibt sie dem Modell nur mehr Möglichkeiten, falsche Zusammenhänge herzustellen. In der Praxis bedeutet das: Nur das speichern, was später von Nutzen ist, den Workflow-Zustand in einfachem, deterministischem Code speichern, Wissen von dort abrufen, wo es sich befindet, nur die relevanten Erinnerungen in den Prompt aufnehmen, die Herkunft jeder Erinnerung notieren und Einträge aktualisieren oder löschen, sobald sich die Fakten ändern.
Datenbanken dienen dazu, Daten zu speichern. Die Erinnerung eines Agents hat ein anderes Ziel: Die richtigen Fakten dem Modell zur Verfügung zu stellen, wenn sie benötigt werden, während altes Unordnungsmaterial nicht zu späterer Gewissheit wird.