In Ordnung, Freunde, hier ist Alex Petrov, gerade zurückgekommen von einem Kampf mit einem besonders sturen LLM-as-a-brain für ein neues Agentenprojekt. Und das, meine Freunde, führt uns zum Thema von heute. Wir sprechen nicht nur über Agenten; wir gehen in etwas, das ich selbst erfahrenen Teams Schwierigkeiten bereiten habe sehen: die Kunst und Wissenschaft der Verwaltung von Zuständen in komplexen KI-Agenten.
Das klingt banal, oder? Zustandsverwaltung. Wie sanitäre Anlagen. Aber genau wie ein Haus mit schlechter Sanitärinstallation irgendwann überflutet wird, wird ein Agent mit schlechter Zustandsverwaltung zu einem schrecklichen Chaos, das unmöglich zu debuggen ist und Halluzinationen oder, schlimmer noch, zu endlosen Schleifen neigt. Ich war dort, schaute mir Protokolle an, um zu verstehen, warum mein Agent beschlossen hatte, einen vollkommen guten Plan zum fünften Mal zu überdenken, bis ich schließlich bemerkte, dass er seine eigene Entscheidung von zwei Schritten zuvor vergessen hatte. Frustrierend ist dafür nicht einmal ein ausreichendes Wort.
Der aktuelle Hype um große Sprachmodelle (LLMs) konzentriert sich oft auf deren unglaubliche Fähigkeiten im Denken, ihre Fähigkeit, menschenähnlichen Text zu generieren, oder sogar ihre aufkeimende Planung. All das ist wahr, all das ist unglaublich. Aber was in der Aufregung oft übersehen wird, ist, dass diese Modelle grundsätzlich zustandslos sind. Jede Interaktion ist, für die meisten Fälle, ein Neuanfang. Und wenn Sie einen KI-Agenten entwickeln – etwas, das dafür konzipiert ist, Aufgaben über die Zeit hinweg auszuführen, mit einer Umgebung zu interagieren und ein Gefühl für einen Zweck aufrechtzuerhalten – stellt dieser Mangel an Zustand eine enorme architektonische Herausforderung dar.
Ich erinnere mich an ein Projekt im letzten Jahr, bei dem wir einen Agenten bauten, um einige Aufgaben der Datenanalyse zu automatisieren. Der ursprüngliche Prototyp war einfach: den LLM einladen, eine Antwort erhalten, ausführen. Spülen und wiederholen. Das funktionierte für triviale Fälle. Aber sobald wir mehrstufiges Denken, Aufrufe an externe Tools und Benutzerfeedback einführten, begann alles auseinanderzufallen. Der Agent verlor den Kontext, vergaß die Ausgaben vorheriger Tools oder fragte nach Informationen, die er bereits hatte. Es war wie mit jemandem zu sprechen, der unter kurzfristigem Gedächtnisverlust leidet. Das war der Moment, in dem ich wirklich anfing, die Feinheiten des Zustands zu schätzen.
Warum Zustandsverwaltung nicht einfach „Dinge in ein Wörterbuch packen“ ist
Wenn Sie denken „Einfach alles in ein Python-Wörterbuch packen und weitergeben“, haben Sie nicht Unrecht, aber Sie sind auch nicht bereit für Agenten, die mehr als nur eine einfache Runde machen. Das Problem mit einem naiven Ansatz ist, dass der „Zustand“ in einem KI-Agenten nicht nur eine Sammlung von Variablen ist. Er ist mehrschichtig, dynamisch und muss oft interpretiert, zusammengefasst oder sogar vergessen werden.
Betrachten Sie einen Agenten, der Ihnen helfen soll, eine Reise zu buchen. Sein Zustand könnte Folgendes umfassen:
- Benutzereingabe: „Ich möchte nächsten Monat von London nach New York fliegen.“
- Entdeckte Informationen: „Der Benutzer bevorzugt Direktflüge, Budget von etwa 800 $.“
- Ausgaben der Tools: „Verfügbare Flüge von British Airways, Flug BA175, Abflug am 22. März, 750 $.“
- Interne Gedanken/Überlegungen des Agenten: „Ich muss das Abflugdatum mit dem Benutzer bestätigen.“
- Umgebungszustand: „Das aktuelle Datum ist der 22. März 2026.“
Alle diese Informationen müssen zugänglich sein, aber nicht unbedingt alle gleichzeitig und nicht alle in Rohform, für den LLM zu verschiedenen Zeitpunkten. Das gesamte Gesprächshistorie und jede Ausgabe eines Tools für jede Anfrage zu füttern, erreicht schnell die Grenzen des Kontextfensters, ganz zu schweigen davon, dass es den LLM ineffektiv macht und ihn ablenkt.
Die Schichten des Zustands des Agenten
Ich finde es hilfreich, den Zustand des Agenten in mehrere distincte, aber miteinander verbundene Schichten zu denken.
1. Flüchtiger Kontext (Das Notizbuch)
Dies ist das Kurzzeitgedächtnis Ihres Agenten, oft spezifisch für einen einzigen Entscheidungszyklus oder eine sehr kleine Sequenz von Schritten. Denken Sie daran wie an das innere Monolog des LLM oder an ein Notizbuch, in dem er einen Gedanken ausarbeitet, bevor er sich auf einen Plan festlegt. Hier könnten Sie die unmittelbare Ausgabe eines Toolaufrufs, eine temporäre Variable für eine Berechnung oder den aktuellen Schritt in einer mehrstufigen Unteraufgabe speichern.
Warum es wichtig ist: Es hält die unmittelbare Anfrage fokussiert. Sie wollen nicht, dass der LLM die gesamte Gesprächshistorie jedes Mal erneut liest, wenn er entscheiden muss, was der nächste Schritt in einer engen Schleife ist. Meine Regel: Wenn es nur für die nächste Runde oder zwei relevant ist, gehört es hierher.
2. Gesprächshistorie (Die Transkription)
Dies ist der rohe oder leicht verarbeitete Hin- und Her zwischen dem Benutzer und dem Agenten, und manchmal sogar das innere Monolog des Agenten. Es ist entscheidend für den Fluss des Gesprächs und das Verständnis der Absicht des Benutzers im Laufe der Zeit.
Herausforderungen: Es wächst schnell. Das wiederholte Senden der gesamten rohen Historie an den LLM ist ein Rezept, um die Kontextgrenzen zu erreichen und die Token-Kosten zu erhöhen. Sie benötigen Strategien, um seine Größe zu verwalten.
3. Extrahiertes Wissen/Zusammengefasster Zustand (Das Gehirnnotizbuch)
Hier wird es interessant. Anstatt das rohe Gespräch zu senden, könnten Sie die Schlüsselpunkte zusammenfassen, Entitäten extrahieren oder bestätigte Fakten ableiten. Zum Beispiel könnten Sie aus einer langen Diskussion über die Flugbuchung „Ziel: New York, Abflugdatum: 22. März, Budget: 800 $“ extrahieren. Diese zusammengefasste Information ist viel prägnanter und liefert dem LLM die wesentlichen Fakten ohne die überflüssige Konversation.
Mein Ansatz: Ich benutze oft einen separaten LLM-Aufruf speziell für die Zusammenfassung oder die Entitätsextraktion zu strategischen Zeitpunkten. Nach einigen Gesprächsaustauschen sende ich die jüngste Historie an einen LLM mit einer Anfrage wie: „Auf Grundlage des folgenden Gesprächs, was sind die bestätigten Vorlieben des Benutzers für ihre Flugbuchung?“ Die Ausgabe wird ein Teil des persistenten Zustands des Agenten.
def summarize_conversation_segment(conversation_history):
prompt = f"""
Bitte fassen Sie die wichtigsten bestätigten Fakten und Präferenzen des Benutzers aus dem folgenden Gesprächssegment zusammen.
Konzentrieren Sie sich auf umsetzbare Informationen für einen Agenten, der versucht, einen Flug zu buchen.
Gespräch :
{conversation_history}
Zusammenfassung (z.B. "Der Benutzer möchte von London nach New York fliegen. Das Abflugdatum ist im März flexibel. Budget von etwa 800 $.") :
"""
# Angenommen, 'llm_client' ist ein initialisierter LLM-Client (z.B. OpenAI, Anthropic)
response = llm_client.chat.completions.create(
model="gpt-4o", # Oder welches Modell auch immer Sie verwenden
messages=[{"role": "user", "content": prompt}]
)
return response.choices[0].message.content.strip()
# Beispiel für die Nutzung :
# new_summary = summarize_conversation_segment(current_conversation_buffer)
# agent_state['facts'].append(new_summary) # Speichern Sie dies in den langfristigen Fakten Ihres Agenten
4. Umgebungszustand (Das Weltmodell)
Dies sind Informationen über die externe Welt, mit der der Agent interagiert. Das könnte die aktuelle Uhrzeit, die Ergebnisse einer Datenbankabfrage, der Status eines Aufrufs an eine externe API oder sogar die aktuellen Wetterbedingungen sein. Dieser Zustand wird oft über Tools abgerufen, muss aber vom Agenten gespeichert und referenziert werden.
Beispiel: Wenn Ihr Agent ein Meeting reserviert, würde der Umgebungszustand die verfügbaren Zeitfenster aus der Kalender-API umfassen. Wenn er ein Smart Home verwaltet, sind dies die aktuelle Temperatur, Lichteinstellungen usw.
5. Absichten/Ziel des Agenten (Der Nordstern)
Was versucht der Agent zu erreichen? Dieses übergeordnete Ziel oder die Absicht ist entscheidend. Es leitet die Entscheidungen des Agenten und hilft ihm, auf Kurs zu bleiben. Es stammt oft aus der ursprünglichen Anfrage des Benutzers, kann aber vom Agenten selbst verfeinert oder in Unterziele zerlegt werden.
Meine Erfahrung: Das explizite Angeben des aktuellen Ziels im LLM bei jeder Anfrage, selbst wenn es nur „Fahren Sie fort, den Flug für den Benutzer zu buchen“ ist, verbessert erheblich die Zielverwirklichung. Ohne dies können Agenten ziemlich leicht vom Kurs abkommen.
Praktische Strategien zur Verwaltung des Zustands
Also, wir wissen jetzt, mit welchem Typ von Zustand wir es zu tun haben. Wie verwalten wir ihn tatsächlich, ohne dass unser Agent ein Gedächtnisschacht oder ein chaotisches Durcheinander wird?
a. Verwaltung des Kontextfensters (Das Gleiten Fenster & Zusammenfassung)
Das ist wahrscheinlich die häufigste Herausforderung. LLMs haben begrenzte Kontextfenster. Man kann nicht einfach alles auf einmal auskippen. Ich verwende eine Kombination von Strategien:
- Gleitendes Fenster: Bewahre nur die letzten N Gespräche aus dem Rohverlauf der Unterhaltung auf. Das funktioniert für kurze und gezielte Interaktionen.
- Dynamische Zusammenfassung: Wie oben erwähnt, fasse regelmäßig die älteren Teile der Unterhaltung zusammen. Wenn der Verlauf der Konversation zu umfangreich wird, nehme ich den ältesten Abschnitt, fasse ihn zusammen und ersetze den Rohteil durch seine Zusammenfassung. So bleibt die wesentliche Information erhalten, während überflüssige Details eliminiert werden.
- Ereignisbasierte Zusammenfassung: Lasse eine Zusammenfassung nach Schlüsselereignissen auslösen, wie etwa einem wichtigen Entscheidungspunkt, einer Toolausführung oder einer signifikanten Änderung in der Benutzerabsicht.
b. Strukturierte Darstellung des Zustands (Basierend auf einem Schema)
Versuche, den Zustand nicht nur in freiem Text zu speichern, sondern strukturiert zu extrahieren und zu speichern. Dies erleichtert die Abfrage und Aktualisierung spezifischer Informationen durch den Agenten.
Zum Beispiel, anstatt ein Feld für “Notizen” im Freitext zu haben, habe spezifische Felder für “Zielort,” “Abreisedatum,” “Budget,” “bevorzugte_Fluggesellschaft.” Du kannst Pydantic-Modelle oder einfache Dictionaries dafür verwenden.
from pydantic import BaseModel, Field
from typing import Optional, List
from datetime import date
class FlightBookingState(BaseModel):
user_id: str
current_goal: str = "Flug buchen"
origin: Optional[str] = None
destination: Optional[str] = None
departure_date: Optional[date] = None
return_date: Optional[date] = None
num_passengers: int = 1
budget_usd: Optional[float] = None
preferred_airlines: List[str] = Field(default_factory=list)
confirmed_flights: List[dict] = Field(default_factory=list)
conversation_summary: List[str] = Field(default_factory=list) # Zusammengefasste Abschnitte
raw_history_buffer: List[dict] = Field(default_factory=list) # Letzte N Rohgespräche
# Dieses Objekt kann serialisiert und übertragen werden.
# Das LLM kann aufgefordert werden, spezifische Felder auszufüllen oder darauf zu verweisen.
Du kannst dein LLM sogar einladen, diesen strukturierten Zustand direkt zu aktualisieren. Zum Beispiel: “Angesichts der letzten Nachricht des Benutzers, aktualisiere das JSON-Objekt FlightBookingState mit allen neuen oder geänderten Informationen.”
c. Durch Abruf augmentierte Generierung (RAG für den Zustand)
Für sehr große oder komplexe Zustände (zum Beispiel, ein Agent, der viele laufende Projekte verwaltet, jedes mit umfangreicher Dokumentation), kannst du Teile deines Zustands als Wissensbasis behandeln. Integriere Zusammenfassungen, frühere Pläne oder Toolausgaben in eine Vektordatenbank. Wenn das LLM dann Kontext benötigt, frage die Vektordatenbank nach den relevantesten Informationsstücken basierend auf dem aktuellen Prompt oder Ziel.
Das ist besonders leistungsstark für Agenten, die über längere Zeiträume oder durch viele verschiedene Aufgaben operieren, wo es unmöglich ist, alles im direkten Kontext des LLM zu halten.
d. Explizite Gedächtnisverwaltung / Vergessen
Manchmal ist Vergessen ein Feature, kein Bug. Wenn eine Information nicht mehr relevant ist (zum Beispiel, der Benutzer hat seine Meinung offensichtlich geändert, oder eine Teilaufgabe ist abgeschlossen), entferne sie aus dem aktiven Zustand. Das verhindert, dass das LLM durch obsolet gewordene Informationen abgelenkt wird.
Das kann Entscheidungen des Agenten erfordern: “Ist diese Information noch relevant für das aktuelle Ziel?” oder “Wurde diese Tatsache durch eine neue Präferenz des Benutzers ersetzt?”
Eine kleine Anekdote über das Vergessen
Ich baute einen Agenten, der den Benutzern half, komplexe Software zu konfigurieren. Zu Beginn erinnerte er sich an jede Auswahl der Konfiguration, die der Benutzer getroffen hatte, selbst wenn dieser später sagte: “Lass uns tatsächlich Option B anstelle von A wählen.” Das LLM, überwältigt von widersprüchlichen Informationen in seinem Kontext, fiel manchmal zurück auf die alte Wahl oder war verwirrt. Erst als ich einen Mechanismus einrichtete, um alte Präferenzen explizit als “ersetzt” oder “nicht relevant” zu kennzeichnen, wurde der Agent zuverlässig. Es ging nicht darum, mehr Gedächtnis hinzuzufügen; es ging darum, es intelligent zu verwalten.
Praktische Tipps für dein nächstes Agentenprojekt
- Kategorisiere deinen Zustand: Kippe nicht alles in eine große “Gedächtnis”-Variable. Denke an die verschiedenen Schichten des Zustands, die ein Agent benötigt: flüchtig, dialogisch, zusammenfassend, umgebungsbezogen und zielorientiert.
- Priorisiere den Kontext: Verstehe, welche Informationen das LLM *wirklich* für seine aktuelle Entscheidung benötigt. Vermeide es, nicht relevante oder redundante Daten zu senden.
- Implementiere rechtzeitige Zusammenfassungen: Warte nicht, bis du die Grenzen des Kontextes erreichst. Plane Zusammenfassungen oder die Extraktion von Entitäten als wesentliche Komponente des Gedächtnissystems deines Agenten ein. Nutze LLMs für diese Aufgabe.
- Strukturierter Zustand ist dein Freund: Definiere Schemata (Pydantic-Modelle, JSON-Strukturen) für den kritischen Zustand deines Agenten. Das erleichtert Verwaltung, Aktualisierung und Interpretation.
- Ziehe RAG für das Langzeitgedächtnis in Betracht: Wenn dein Agent große Mengen an Informationen über längere Zeiträume speichern muss, erkunde die Nutzung von Vektordatenbanken und RAG-Techniken.
- Hab keine Angst vor dem Vergessen: Baue Mechanismen ein, um Informationen intelligent aus dem Zustand deines Agenten zu entfernen oder als nicht relevant zu kennzeichnen.
- Teste die Grenzfälle des Gedächtnisses: Teste absichtlich Szenarien, in denen der Agent sich an spezifische Details aus vielen Gesprächen erinnern muss oder in denen er widersprüchliche Informationen verwalten soll. Dort zeigt sich, was das Management des Zustands wirklich kann (oder versagt).
Das Management des Zustands in KI-Agenten ist nicht der auffälligste Teil der Arbeit. Es geht nicht darum, eine neue Architektur für neuronale Netze zu entwerfen oder den perfekten Prompt zu finden. Es geht um durchdengineering und gezielte Ingenieurkunst, die alles andere unterstützt. Aber ich verspreche dir, dass die Zeit, die du hier investierst, dir unzählige Stunden beim Debuggen sparen und dich zu viel fähigeren, zuverlässigeren und wirklich benutzerfreundlichen Agenten führen wird. Viel Spaß beim Bauen!
Verwandte Artikel
- Maßstäbe der NVIDIA-Grundlagen: Bewertung des Deep-Learning-Kurses erklärt
- Die Entlarvung von Vorurteilen in Convolutional Neural Networks
- Performance Engineer für Deep Learning: Master der KI-Optimierung
🕒 Published: