Wann man dazu greift
- Nutzerkontext über mehrere Turns hinweg gepflegt werden muss.
- Der Agent aus vergangenen Fällen lernen muss.
- Mehrstufige Aufgaben das Verfolgen von Zwischenzuständen erfordern.
Memory Architecture.
Kurzzeit, Langzeit, abgerufen.
Relevante Konversationshistorie, abgeschlossene Aufgabenepisoden und strukturiertes Langzeitwissen werden gespeichert und abgerufen, um Agenten über mehrere Turns und Läufe hinweg persistenten Kontext zu geben.
In der PraxisEin Reiseplanungs-Assistent ruft die langfristigen Sitzplatzpräferenzen des Nutzers und das unfertige Reiseprogramm der letzten Sitzung aus dem Gedächtnis ab und setzt die Aufgabe dort fort, ohne dass der Nutzer beides erneut nennen muss.
Wann es nach hinten losgeht
- Datenschutzvorschriften die Speicherung verbieten.
- Aufgaben strikt zustandslos sind.
- Eine statische semantische Wissensbasis ausreicht.
Die Abwägung
Verbesserter Kontext und Anpassungsfähigkeit werden auf Kosten höherer Token-Kosten, Datenschutzrisiken und Kontextfenstererschöpfung erreicht.
Was es tatsächlich tut.
Der Lauf schreibt jetzt Fakten und ruft sie in einem späteren Turn wieder ab.
Zwei Wege, wie dieses Pattern Probleme verursachen kann.
Gedächtnis leckt über Sitzungsgrenzen hinweg
Der private Kontext von Nutzer A fließt in die Konversation von Nutzer B ein, weil die Abrufschicht nicht nach Sitzungs-ID filtert.
Lösung · Jeden Gedächtniseintrag mit einer Sitzungs- oder Nutzerdimension versehen. Dimensionsbeschränkten Abruf auf der Speicherebene erzwingen.
Übereifiger Abruf bläht den Kontext auf
Der Retriever holt 20 relevante Erinnerungen und schreibt sie alle in den Prompt, was den Kontext des aktuellen Turns verdrängt.
Lösung · Abgerufene Chunks begrenzen und nach Aktualität + Relevanz ranken. Alte Erinnerungen zusammenfassen, statt sie wörtlich einzufügen.
Wo Memory Architecture nativ ist.
Microsoft Agent FrameworkThreads + MemoryNativ