Gedächtnis in KI-Agenten: behalten, komprimieren, wegwerfen
In einem Sprachmodellaufruf gibt es kein Gedächtnis. Jeder Zug ist eine frische Anfrage, und das Modell weiß nur, was Sie diesmal zusammengestellt haben. Alles, was Menschen als Vergessen oder als Verschlechterung über einen langen Lauf beschreiben, ist eine Entscheidung Ihres Codes darüber, was mitgeführt wird.
Sobald man das akzeptiert, wird Gedächtnisdesign ein gewöhnliches Engineeringproblem: Was ist immer relevant, was kürzlich relevant, was lässt sich zusammenfassen und was sollte man lieber frisch holen als speichern.
Die vier Ebenen#
| Ebene | Inhalt | Gekürzt? | Typische Größe |
|---|---|---|---|
| Fixiert | Ziel, Vorgaben, Nutzeridentität, Richtlinie | Nie | 200–500 Tokens |
| Jüngst | Letzte Züge wörtlich, mit Werkzeugergebnissen | Rollierendes Fenster | 2–5 Züge |
| Komprimiert | Ältere Züge als kurze Faktennotizen | Wird beim Wachsen neu geschrieben | Unter 500 Tokens |
| Abgerufen | Dokumente und Daten für diesen Schritt | Nach Gebrauch verworfen | Pro Schritt |
Fakten komprimieren, nicht Prosa#
Der übliche Fehler ist, alte Züge erzählerisch zusammenzufassen — die Kundin fragte nach ihrer Bestellung und der Agent sah nach. Das liest sich gut und hilft nicht. Komprimieren Sie auf Fakten, die ein späterer Schritt braucht: Bestellung 4471, Status versandt, Rückerstattung gewünscht, Frist 30 Tage, noch nichts erstattet. Strukturiert, prüfbar und ein Zehntel so groß.
Komprimieren Sie an einer Schwelle, nicht in jedem Zug. Zusammenfassungen von Zusammenfassungen lassen Details still verschwinden.
Retrieval ist kein Gedächtnis#
Aus einer Wissensbasis geholte Dokumente gehören dem Schritt, der sie brauchte. Sie danach im laufenden Kontext zu behalten ist der schnellste Weg zu einem aufgeblähten, teuren, abgelenkten Lauf. Holen, nutzen, zitieren, verwerfen — und wenn ein späterer Schritt denselben Fakt braucht, erneut holen. Retrieval ist billig; ein Kontext voller alter Dokumente nicht.
Gedächtnis über Sitzungen hinweg#
Langlebige Agenten sammeln nützliche Fakten über Nutzer oder Konten: Präferenzen, frühere Entscheidungen, unveränderliche Vorgaben. Speichern Sie diese bewusst in einem kleinen strukturierten Datensatz mit explizitem Schreibschritt, statt Historie anwachsen zu lassen. Drei Regeln halten das gesund: nur Fakten schreiben, auf die ein späterer Lauf handeln würde; immer Herkunft festhalten; und jedem Fakt ein Ablauf- oder Prüfdatum geben.
- Bewusst schreiben — als Werkzeugaufruf, nicht als Nebeneffekt.
- Quelle und Datum neben jedem Fakt speichern.
- Größe deckeln und Ungenutztes ablaufen lassen.
- Nutzern zeigen und korrigieren lassen, was über sie gespeichert ist.
Symptome und Ursachen#
| Symptom | Übliche Ursache |
|---|---|
| Vergisst frühe Vorgabe | Vorgabe war nicht fixiert und wurde mitgekürzt |
| Qualität sinkt nach mehreren Schritten | Kontext mit altem Werkzeugoutput verdünnt |
| Wiederholt erledigten Schritt | Ergebnis ohne Abschlussmarker wegkomprimiert |
| Kosten steigen mit Lauflänge | Abgerufene Dokumente sammeln sich an |
| Behauptet Veraltetes selbstsicher | Persistentes Gedächtnis ohne Ablauf und Herkunft |
Häufige Fragen
Wie viel Historie wörtlich behalten?
Drei bis fünf Züge decken das meiste Denken ab, ohne den Kontext zu dominieren. Werkzeugergebnisse bleiben an ihrem Aufruf; Älteres wird zu strukturierten Fakten komprimiert statt still gelöscht.
Brauche ich eine Vektordatenbank fürs Agentengedächtnis?
Für Dokumentenabruf oft ja. Für den laufenden Zustand eines einzelnen Laufs nein — das ist ein kleines strukturiertes Objekt in Ihrem Speicher. Beides zu vermischen ergibt eine unscharfe Zustandsmaschine und einen unscharfen Index.
Wie verhindere ich veraltetes persistentes Gedächtnis?
Jeder gespeicherte Fakt bekommt Quelle, Datum und Ablauf; frisch Abgerufenes hat Vorrang. Und zeigen Sie den Datensatz den Nutzern, damit falsche Fakten korrigiert statt still wiederholt werden.
ki agenten gedächtniskontext managementgesprächszusammenfassungpersistentes gedächtnisllm kontextfenster
