Memory und State: Kurzzeit-Kontext und Langzeit-Recall

Sie sagen einem Support-Agent: „Mein Name ist Priya und meine Bestellnummer ist #4471.“ Drei Nachrichten später fragt ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen →: „Darf ich Ihren Namen erfahren?“ Das ist ein Agent ohne Memory, und es wirkt kaputt. Der umgekehrte Fehler ist genauso schlimm: ein Agent, der jede vergangene Konversation in jede Antwort packt, durcheinanderkommt, langsam wird und ein Vermögen kostet. Gute Agenten merken sich die *richtigen* Dinge zum *richtigen* Zeitpunkt. Darum geht es in dieser Lektion.

Zwei Arten von Memory

Das menschliche Gehirn hat ein Arbeitsgedächtnis (woran Sie gerade denken) und ein Langzeitgedächtnis (was Sie bei Bedarf abrufen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen). KI-Agenten funktionieren genauso, und diese Unterscheidung ist für den Aufbau entscheidend.

Kurzzeit-Memory: das Context WindowContext WindowDas Context Window ist die maximale Textmenge (gemessen in Tokens), die ein Sprachmodell auf einmal verarbeiten kann, einschließlich Input-Prompt und generiertem Output.Vollständige Definition ansehen →

Das Context Window ist der Textblock, den das Modell in einer einzelnen Anfrage „sehen“ kann. Es enthält die System-Instruktionen, die bisherige Konversation und alle Daten, die Sie hineinkopieren. Stellen Sie es sich als Schreibtisch des Agenten vor: Alles auf dem Tisch ist gleichzeitig sichtbar, aber der Tisch hat eine feste Größe.

Diese Größe wird in TokensTokensEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen → gemessen (jeweils grob ¾ eines Wortes). Moderne Modelle haben 2026 große Windows, oft 200.000 Tokens oder mehr, aber „groß“ ist nicht „unendlich“, und ein volles Window ist langsam und teuer.

Hier die zentrale Tatsache, die viele überrascht: Das Modell hat zwischen den Aufrufen kein Gedächtnis. Jedes Mal, wenn Sie eine Nachricht senden, wird die gesamte Konversation erneut mitgeschickt. Der Agent „erinnert“ sich nur an Ihren Namen, weil Ihre Anwendung das Transkript behält und es in jeder Runde wieder einfügt.

# Short-term memory is just a list you resend every turn.
messages = [
    {"role": "system", "content": "You are a support agent."},
]

def chat(user_text):
    messages.append({"role": "user", "content": user_text})
    reply = model.generate(messages)          # whole list sent every time
    messages.append({"role": "assistant", "content": reply})
    return reply

chat("My name is Priya, order #4471.")
chat("When does it ship?")   # 'Priya' and '#4471' are still in the list

Das ist der gesamte Trick hinter konversationellem Memory. Keine Magie, nur eine wachsende Liste.

Langzeit-Memory: ein durchsuchbarer Speicher

Der Schreibtisch füllt sich. Alte Tickets, frühere Chats und Kontohistorie können nicht alle für immer im Context Window liegen. Also verschieben wir sie ins Langzeit-Memory: einen externen Speicher, den der Agent durchsuchen kann, wenn ein Thema aufkommt.

Das übliche Werkzeug dafür ist ein Vector StoreVector StoreEine Vector Database speichert Daten als hochdimensionale numerische Vektoren (Embeddings) und findet Inhalte über Ähnlichkeit statt über exakte Treffer. Sie ist die Grundlage für semantische Suche und KI-Anwendungen.Vollständige Definition ansehen → (auch Vektordatenbank genannt). Er speichert Text als Embeddings: numerische Fingerabdrücke, die Bedeutung erfassen. Wenn Priya sich erneut meldet, wandelt der Agent ihre neue Nachricht in ein EmbeddingEmbeddingEin Embedding ist ein numerischer Vektor, der Daten (Text, Bilder oder Objekte) so darstellt, dass ihre Bedeutung erfasst wird: Ähnliche Elemente liegen im Raum dicht beieinander.Vollständige Definition ansehen → um und fragt den Speicher: „Welche vergangenen Tickets sind diesem am ähnlichsten?“ Er holt nur die wenigen relevanten zurück und legt sie auf den Schreibtisch.

Das nennt man Retrieval: die Handvoll Erinnerungen holen, die zählen, und die Tausenden ignorieren, die es nicht tun. Wenn Sie tiefer in die Mechanik einsteigen wollen, erklärt dieses kostenlose Primer zu Embeddings und Vektorsuche es verständlich, ohne Programmierkenntnisse vorauszusetzen.

Ein konkreter Support-Agent

Machen wir es greifbar. Priya hat den Support in zwei Jahren viermal kontaktiert. Heute schreibt sie: „Mein Mixer raucht schon wieder.“

So verhält sich ein gut gebauter Agent:

1. Kurzzeit: Er behält das heutige Gespräch im Context Window, damit er mitten im Chat nicht erneut nach ihrem Namen fragt.
2. Langzeit-Retrieval: Er durchsucht den Vector Store nach Priyas früheren Tickets. Er findet Ticket #4471 vom letzten Jahr: „Mixer überhitzt, im Rahmen der Garantie ersetzt.“ Das ist hochrelevant, also lädt er es.
3. Er ignoriert ihr unzusammenhängendes Ticket über eine verspätete Rechnung. Nicht ähnlich, nicht geladen.
4. Er antwortet mit Kontext: „Ich sehe, dass wir diesen Mixer im März wegen Überhitzung ersetzt haben. Prüfen wir, ob noch Garantie besteht.“

Das fühlt sich an wie ein Mensch, der sich tatsächlich an Sie erinnert. Beachten Sie: Der Agent hat nicht alle vier Tickets ins Window gekippt. Er hat eines abgerufen.

# Long-term recall: search, then inject only what's relevant.
def build_context(user_text, user_id):
    past = vector_store.search(
        query=user_text,
        filter={"user_id": user_id},
        top_k=3            # only the 3 most relevant memories
    )
    memory_block = "\n".join(m.text for m in past)
    return [
        {"role": "system",
         "content": f"You are a support agent.\nRelevant history:\n{memory_block}"},
        {"role": "user", "content": user_text},
    ]

Das top_k=3 leistet viel Arbeit. Es sagt: „Gib mir die drei besten Treffer, nicht alles.“ Diese eine Zahl macht oft den Unterschied zwischen einem präzisen Agenten und einem, der in Historie ertrinkt.

Was behalten, zusammenfassen oder vergessen

Memory heißt nicht „alles speichern“. Es ist eine Reihe von Entscheidungen. Hier praktische Regeln.

Behalten (wörtlich, im Window)

• Die aktuelle Aufgabe und die letzten paar Gesprächsrunden.
• Fakten, die der Agent nicht falsch wiedergeben darf: Bestellnummern, das genannte Ziel des Nutzers, eine bestätigte Lieferadresse.
• Alles, wozu der Nutzer gerade gesagt hat „merk dir das“.

Zusammenfassen (komprimieren, dann die Zusammenfassung behalten)

Wenn ein Gespräch lang wird, schleppen Sie nicht alle fünfzig Nachrichten mit. Fassen Sie die älteren in einer kurzen Notiz zusammen und behalten Sie nur diese. Das nennt man oft „Rolling Summary“.

Beispiel: Vierzig Nachrichten Hin und Her beim Debugging werden zu einer Zeile: *„Nutzerin behebt Problem mit rauchendem Mixer; Modell X200 bestätigt; Garantiestatus unbekannt.“* Sie haben gerade den Großteil des Schreibtischs freigeräumt und das Wesentliche behalten.

# When the transcript gets long, compress the old part.
if token_count(messages) > 6000:
    old = messages[1:-6]                      # keep system + last 6 turns
    summary = model.generate([
        {"role": "user",
         "content": f"Summarize these support messages in 3 sentences:\n{old}"}
    ])
    messages[1:-6] = [{"role": "system", "content": f"Summary so far: {summary}"}]

Vergessen (komplett verwerfen)

• Smalltalk und Höflichkeiten. „Vielen Dank!“ muss nicht erinnert werden.
• Sensible Daten, die Sie nicht aufbewahren sollten (siehe unten).
• Fehlgeschlagene Versuche, sobald die Aufgabe gelöst ist. Der Agent braucht keine drei falschen Antworten, die seine Erinnerung an ein gelöstes Ticket zumüllen.

Ein nützliches Denkmodell: Fakten behalten, Verläufe zusammenfassen, Rauschen vergessen.

Die richtige Balance finden

Zwei Fehlermodi liegen links und rechts von gutem Memory.

Zu wenig Memory: Der Agent fragt Dinge erneut, verliert den Faden und wirkt roboterhaft. Meist verursacht dadurch, dass das Transkript nicht persistiert wird oder top_k zu niedrig gesetzt ist.

Zu viel Memory: Der Agent wird von veralteter oder irrelevanter Historie verwirrt, widerspricht sich, läuft langsam und kostet pro Nachricht mehr. Meist verursacht dadurch, dass die volle Historie hineingekippt statt abgerufen wird, oder nie zusammengefasst wird.

Die Lösung für beides ist dieselbe Disziplin: Entscheiden Sie bewusst, was ins Window kommt. Relevante Langzeit-Erinnerungen abrufen, lange Gespräche zusammenfassen, Rauschen vergessen. Das Context Window ist erstklassige Lage. Behandeln Sie jedes Token so, als würde es Sie etwas kosten, denn das tut es.

Noch ein praktischer Punkt: Schreiben Sie Memory zurück. Nach Abschluss eines Tickets speichern Sie eine kurze strukturierte Notiz im Vector Store: *„2026-03-11: Priya, Mixer X200, Überhitzung, im Rahmen der Garantie ersetzt.“* Genau das wird der Agent von morgen abrufen. Ein Agent, der nie neue Erinnerungen schreibt, kann immer nur das abrufen, womit er gestartet ist.

Eine Anmerkung zu Datenschutz und Frameworks

Langzeit-Memory bedeutet, dass Sie Nutzerdaten speichern, manchmal sensible Daten. Zwei Regeln halten Sie aus Schwierigkeiten heraus:

• Speichern Sie nicht, was Sie nicht brauchen. Schwärzen Sie Kartennummern, Passwörter und Gesundheitsdaten, bevor sie in den Vector Store gelangen.
• Lassen Sie Nutzer ihre Erinnerungen einsehen und löschen. „Vergiss alles über mich“ sollte tatsächlich funktionieren. Planen Sie das ab Tag eins ein.

Sie müssen diese ganze Infrastruktur nicht selbst bauen. Jeder große Anbieter liefert inzwischen ein Agent-Framework, das Transkripte, Retrieval und Summarization für Sie übernimmt: das OpenAI Agents SDK, das Claude Agent SDK und Googles Agent Development Kit (ADK). Sie unterscheiden sich in den Details, teilen aber dieselbe Struktur, die Sie hier gelernt haben: Kurzzeit-Kontext plus Langzeit-Retrieval. Die Provider-Deep-Dive-Blöcke in diesem Kurs behandeln die Besonderheiten der einzelnen Anbieter. Die Konzepte lassen sich direkt übertragen, wählen Sie also den Anbieter, den Sie ohnehin nutzen.

Wichtigste Erkenntnisse

• Kurzzeit-Memory ist nur das Transkript, das Sie in jeder Runde erneut senden. Das Modell hat zwischen den Aufrufen kein Gedächtnis; Ihre Anwendung liefert es, indem sie die Konversation wieder einfügt.
• Langzeit-Memory ist ein durchsuchbarer Vector Store. Rufen Sie die wenigen relevanten früheren Einträge ab (ein niedriges top_k), nicht die gesamte Historie.
• Fakten behalten, Verläufe zusammenfassen, Rauschen vergessen. Bestellnummern wörtlich mitführen, lange Gespräche in eine Rolling Summary komprimieren, Höflichkeiten verwerfen.
• Schreiben Sie Memory nach jeder Aufgabe zurück, damit künftige Sessions darauf zugreifen können, und planen Sie Löschung aus Datenschutzgründen von Anfang an ein.
• Das Context Window ist erstklassige Lage. Sowohl zu wenig als auch zu viel Memory macht Agenten kaputt; die Kur ist, bei jedem Token bewusst zu entscheiden, ob es ins Window gehört.