Sieben stillschweigende Wege, auf denen Kontextverschmutzung LangGraph-Agenten beeinträchtigt.

Stellen Sie sich einen LangGraph-Agenten vor, der einem Benutzer mitteilt, dass sein Projekt „auf Kurs für eine Lieferung im Juli“ sei. Der Kalender zeigt jedoch August an. Die Protokolle weisen weder Ausnahmen noch fehlgeschlagene Tool-Aufrufe auf, und überall ist nichts in Rot markiert. Nach allen von dem Team verfolgten Metriken ist der Agent funktionsfähig – doch drei Tage lang täuscht er die Leute heimlich, bevor jemand etwas bemerkt.

Solche Vorfälle haben eine gemeinsame, unsichtbare Ursache: die Kontextverschmutzung. Alle sieben unten aufgeführten Fälle lassen sich darauf zurückführen. Jeder von ihnen verursachte keine Fehler. Die Szenarien sind künstlich zusammengestellt und dienen zur Veranschaulichung; Firmennamen sowie Zahlen sind erfunden, doch die zugrundeliegenden Mechanismen sind solche, mit denen Agentenentwickler regelmäßig konfrontiert werden.

Kontextverschmutzung in zwei Minuten

Wenn ein Agent reasoning durchführt, sieht er Ihre Anwendung nicht. Er sieht nur einen langen Textblock, das Kontextfenster, und nichts anderes. Stellen Sie es sich wie einen Schreibtisch vor: Alles, was auf dem Schreibtisch liegt, ist nutzbar, während alles, was darauf nicht liegt, für den Agenten nicht existiert – auch dann nicht, wenn es sich nur wenige Meter entfernt in Ihrer Datenbank befindet.

Jeder Zug legt mehrere Elemente auf diesen Schreibtisch:

• die Systemanweisung, also die Richtlinien
• Die Definitionen der Tools, also welche Funktionen der Agent aufrufen kann
• Die Konversationshistorie, also alles, was bisher gesagt wurde
• Die Ausgaben der Tools, also alles, was Ihre APIs zurückgegeben haben
• Den Zustand, also die Informationen, die Ihre LangGraph-Node speichern und weitergeben
• Die abgerufenen Dokumente, falls Sie RAG verwenden

Anfänger hören das selten: Der Schreibtisch hat eine Größenbegrenzung, und die Aufmerksamkeit wird nicht gleichmäßig darauf verteilt. Inhalte können technisch vorhanden sein, aber in der Praxis ignoriert werden. Sie können auch veraltet, doppelt vorhanden oder widersprüchlich sein, und das Modell wird keine Einwände erheben. Es verarbeitet den Unsinn kommentarlos.

Kontextverschmutzung bedeutet fehlerhaftes, veraltetes, überdimensioniertes oder widersprüchliches Material, das im System vorhanden ist und das Verhalten verschlechtert, ohne dass ein einziger Fehler auftritt. Das ist die Gefahr. Ein Absturz weckt einen mitten in der Nacht um 2 Uhr, während die Kontextverschmutzung dazu führt, dass der Agent dauerhaft zu 20 Prozent falsch arbeitet.

Jeder der unten aufgeführten Fälle wird mit einem Symptom, einer Ursache, einer Lösung sowie einer Methode zur Erkennung im eigenen System beschrieben – denn ein Fehler, den man nicht erkennen kann, wird immer wieder auftreten.

Fall 1: Der Agent steckt im Juli fest

Symptom. Nehmen wir einen Berichtsagenten für eine fiktive Dienstleistung – nennen wir sie Meridian Energy. Er wies ständig auf „diese Monats“-Zahlen hin, die eigentlich vom Vormonat stammten. Die Nutzer machten den Datenfluss dafür verantwortlich, was in Ordnung war.

Ursache. Zu Beginn einer Sitzung hatte ein Entwickler den aktiven Berichtszeitraum genau einmal im LangGraph-Zustand gespeichert (eine Schlüssel mit dem Namen current_period, der den Wert 2026-07 enthielt), und der Checkpointer speicherte dies ab. Später nahmen die Nutzer alte Sitzungen wieder auf – eine beliebte Funktion – und der gespeicherte Checkpointer brachte somit den Juli mit. Der Agent war nicht verwirrt; er folgte seinem Kontext, und sein Kontext besagte Juli.

Lösung. Führen Sie eine Regel ein, die das State-Design verändert: Speichern Sie niemals etwas, was man kostengünstig neu berechnen kann. Das aktuelle Datum, der aktuelle Zeitraum sowie alles, was als „heute“ bezeichnet ist, sollte zu Beginn jeder Ausführung neu berechnet werden und nicht gespeichert bleiben. Wenn current_period aus dem gesicherten State in einen kleinen Node verlegt wird, der ihn bei jedem Aufruf neu berechnet, kostet das nur eine Zeile Code und beseitigt die gesamte Klasse von Fehlern.

Erkennung. Im Entwicklungsmodus geben Sie zu Beginn jeder Ausführung das State-Dictionary aus und prüfen Sie für jeden Schlüssel, ob er veraltet sein könnte und ob Sie das bemerken würden. Jeder Schlüssel, der ein Datum, einen Status oder das Wort „aktuell“ enthält, ist verdächtig.

Fall 2: Ein Tool-Dump mit 8.000 Tokens, der die Anweisungen überschwemmte

Symptom. Der Agent begann, die Formatierungsregeln zu ignorieren. Die Systemanweisung besagte, jede Antwort mit einer Zusammenfassungstabelle zu beginnen. Das tat er zunächst, bis er manchmal nicht mehr darauf achtete. Zufällig – was die schlimmste Art von Fehler ist.

Ursache. Ein Tool rief eine API auf und fügte die rohe JSON-Antwort in den Kontext ein. Bei kleinen Abfragen betrug dies 400 Token. Bei großen Abfragen stieg die Menge auf über 8.000 Token an – voller verschachtelter JSON-Daten mit IDs, Metadaten, leeren Feldern und Paginierungsinformationen, die niemand benötigte. Durch das Einfügen mitten in den Kontext verwandelten sich die sorgfältig formulierten Anweisungen in eine leise Stimme im Hintergrund eines lauten Raumes. Die Aufmerksamkeit richtete sich auf die Flut an JSON-Daten, wodurch die Formatierungsregeln praktisch verschwanden.

Das unangenehme Detail ist, dass dies nur bei großen Antworten auftrat. Kleine Abfragen funktionierten weiterhin einwandfrei, weshalb es Wochen dauerte, einen Zusammenhang zwischen „Fehlerverhalten des Agents“ und „der Benutzer stellte eine große Frage“ herzustellen.

Lösung. Die Tools sollten Fakten zurückgeben, nicht ganze Datensätze. Fügen Sie in jedes Tool eine einfache Transformationsschicht ein, die die wenigen Felder extrahiert, die der Agent benötigt, sie kompakt formatiert und den Rest weglässt. Ein solches Tool reduzierte seine Tokenanzahl von etwa 8.000 auf etwa 300.

# Before: return response.json()          # 8,000 tokens of noise
# After:
def summarize_response(data: dict) -> dict:
    return {
        "project": data["name"],
        "status": data["status"],
        "owner": data["owner"]["displayName"],
        "due": data["dueDate"],
        "open_risks": len(data.get("risks", [])),
    }                                       # ~300 tokens of signal

Erkennung. Protokollieren Sie die Anzahl der Tokens jeder Tool-Ausgabe. Ein Tool, das mehr Tokens zurückgeben kann als Ihr gesamter Systemprompt, ist eine Quelle von Störungen, die auf eine lange Antwort wartet.

Fall 3: Eine Korrektur, die den ursprünglichen Auftrag nie ersetzt hat

Symptom. Ein Benutzer bittet um Informationen zur Nordostregion, korrigiert sich anschließend sofort und fragt nach der Nordwestregion. Der Agent antwortet korrekt zur Nordwestregion. Nach vier Gesprächsrunden weicht er ohne weitere Anfrage wieder auf die Nordostregion aus.

Ursache. Die Gesprächshistorie ist standardmäßig nur für das Hinzufügen neuer Einträge geeignet, sodass sowohl die fehlerhafte Anweisung als auch die Korrektur dauerhaft im Kontext bleiben. Normalerweise gewichtet das Modell die neueren Nachrichten korrekt, was aber nicht immer der Fall ist. Mit zunehmender Länge des Chats verschwimmen die beiden Versionen zu gleichermaßen plausiblen Fakten. Der Agent erinnerte sich nicht falsch – er erinnerte sich einfach zu viel.

Lösung. Es gibt zwei Optionen.

1. Lösen, nicht anhäufen. Wenn eine Korrektur festgestellt wird, fügt man sie nicht einfach hinzu. Schreiben Sie den neuen Wert in einen strukturierten Faktenblock im Zustand (Region auf Northwest gesetzt), den der Agent als autoritativ betrachtet, sodass das unübersichtliche Transkript nicht bei jedem Schritt erneut diskutiert werden muss.
2. Die Historie bearbeiten. LangGraph ermöglicht es, Nachrichten vor deren erneutem Eintrag in den Kontext zu kürzen oder umzuschreiben, sodass überholte Anweisungen einfach entfernt werden können.

Die wichtigere Erkenntnis ist, dass eine Konversationshistorie ein Protokoll und keine Wissensdatenbank ist. Lassen Sie den Agenten nicht bei jedem Schritt die Wahrheit aus einem Transkript ableiten.

Erkennung. Fügen Sie einen Fall der Selbstkorrektur zu Ihren Tests hinzu: Der Benutzer sagt X, korrigiert sich dann auf Y und stellt anschließend fünf weitere Fragen. Wenn der Agent wieder zu X zurückkehrt, haben Sie diesen Fehler.

Fall 4: RAG gab eine Antwort fünfmal aus und versteckte die echte

Symptom. Die Nutzer stellten eine Frage, auf die in der Dokumentation ausdrücklich geantwortet wurde, doch das System lieferte nur eine vage, unvollständige Antwort. Die Abrufprotokolle zeigten sechs heruntergeladene Abschnitte, sodass es den Anschein hatte, als würde die Informationsabrufung ihre Aufgabe erfüllen.

Ursache. Im Korpus befanden sich nahezu identische Inhalte: Ein Absatz aus einer Richtlinie war in fünf verschiedene Dokumente eingefügt worden, wie es reale Unternehmen oft tun. Die Ähnlichkeitssuche funktionierte einwandfrei und lieferte fünf fast identische Abschnitte, die den einzigen anderen Abschnitt mit der echten Antwort verdrängten. Fünf Plätze am Tisch wurden demselben „Gast“ zugewiesen.

Lösung. Entfernen Sie Duplikate beim Abrufen. Selbst eine einfache Methode funktioniert gut: Laden Sie 20 Kandidaten herunter, entfernen Sie alle Teile, die zu ähnlich zu einem bereits ausgewählten sind, und behalten Sie den vielfältigsten Satzzyklus. Wenn Ihr Vektorlager maximale marginale Relevanz unterstützt, ist diese Idee bereits integriert. Die Qualität der Antworten auf Richtlinienfragen verbesserte sich sofort, ohne dass das Modell oder die Anfrage geändert werden mussten.

Erkennung. Protokollieren Sie die abgerufenen Teile und prüfen Sie diese wöchentlich. Wenn ein Satz in einer Batch-Gruppe regelmäßig zweimal auftaucht, zahlen Sie für Redundanzen mit Relevanz.

Fall 5: Die Zusammenfassung, die die wichtige Regel ignorierte

Symptom. Um lange Sitzungen kostengünstig zu halten, führte ein Team eine schrittweise Zusammenfassung ein: Alle N Schritte werden ältere Nachrichten komprimiert. Standardmäßig und weithin empfohlen. Später begann ein Mitarbeiter, Entwurfsaufzeichnungen in offizielle Berichte aufzunehmen, obwohl der Benutzer bereits elf Schritte zuvor „Entwürfe ausschließen“ gesagt hatte.

Ursache. Der Zusammenfassungsalgorithmus verhielt sich wie vorgesehen. Er behielt die wichtigsten Informationen bei (der Benutzer wollte regionale Berichte und sprach über das Layout) und ignorierte das, was er als unbedeutend einstufte. Doch „Entwürfe ausschließen“ war keineswegs unbedeutend – es handelte sich dabei um eine Einschränkung, und Einschränkungen können nicht paraphrasiert werden: Entweder bleiben sie unverändert bestehen oder verschwinden ganz. Von allen sieben Fehlern ist dieser am besorgniserregendsten, da die Zusammenfassung in Demos wie ein unumstrittener Vorteil erscheint.

Lösung. Teilen Sie den Speicher in zwei Bereiche auf, bevor eine Kompression stattfindet.

• Narrative kann aggressiv zusammengefasst werden.
• Beschränkungen, Entscheidungen und Präferenzen werden in eine strukturierte Liste aufgenommen, die niemals zusammengefasst wird. Einträge werden nur hinzugefügt oder ausdrücklich entfernt, und die gesamte Liste wird bei jedem Schritt in den Kontext eingefügt.

Die Zusammenfassungsanweisung kann das direkt festlegen: Bevor zusammengefasst wird, sollen alle Anweisungen, Beschränkungen und Entscheidungen wortwörtlich in die Beschränkungsliste kopiert werden.

Erkennung. Während der Entwicklung sollte die Beschränkungsliste vor und nach jedem Zusammenfassungsvorgang verglichen werden. Eine Beschränkung, die nur innerhalb eines Zusammenfassungsparagrafen vorhanden ist, deutet darauf hin, dass der Kompressor Ihre Regeln zerstört.

Fall 6: Ein Stack-Trace, der den Agenten dazu brachte, ein funktionierendes Werkzeug zu misstrauen

Symptom. Ein Tool hatte einmal kurzzeitig einen Zeitüberschreitungsfehler, funktionierte aber bereits beim nächsten Aufruf wieder einwandfrei. Dennoch teilte der Agent den Nutzern den Rest der Sitzung über mit, dass er das Berichtssystem nicht erreichen könne, obwohl er tatsächlich erfolgreich darauf zugreifen konnte. Die Nutzer vertrauten natürlich eher dieser Aussage als den tatsächlichen Daten.

Ursache. Der vollständige Fehlerverlauf, ein TimeoutError nach 30 Sekunden, wurde der Historie hinzugefügt und blieb dort. Für das Modell wurde „das Berichtssystem ist unzuverlässig“ zu einer feststehenden Tatsache, wodurch jede spätere Antwort davon beeinflusst wurde. Ein vorübergehender Fehler verwandelte sich so in eine dauerhafte Störung.

Lösung. Behandeln Sie Fehler als Ereignisse und nicht als Fakten. Nach einem erfolgreichen Neversuch ersetzen Sie den Fehler in der Historie durch eine einzeilige Notiz wie „(vorübergehender Fehler, nach Neversuch behoben)“. Wenn ein Tool endgültig versagt, geben Sie dem Agenten einen sauberen, strukturierten Status – nicht eine Stack-Trace-Anzeige. Stack-Traces gehören in die Logs, niemals in den Kontext.

Erkennung. Suchen Sie in den laufenden Kontexten nach den Zeichenfolgen Error, Traceback und Exception. Jeder Treffer stellt entweder ein andauerndes Problem oder einen verbleibenden Fehler dar, der spätere Prozesse beeinträchtigt – beides sollte beseitigt werden.

Fall 7: fünfundzwanzig Tools im selben Fenster

Symptom. Im Laufe mehrerer Monate wurde die Anwendung immer langsamer und teurer, was vorhersehbar war, da ständig neue Funktionen hinzukamen. Zudem wählte sie zunehmend das falsche Werkzeug für einfache Anfragen – beispielsweise eine Konformitätsauswertung, obwohl jemand lediglich einen Projektüberblick haben wollte. Nichts war kaputt; alles wurde einfach nur unübersichtlicher.

Ursache. Das Werkzeugset umfasste bereits 25 Tools, von denen jedes eine ausführliche Beschreibung sowie ein JSON-Schema hatte. Bevor der Benutzer ein Wort eintippen konnte, wurden bereits etwa 12.000 Tokens verbraucht. Bei jeder Anfrage bewertete das Modell 25 Optionen, von denen viele ähnliche Beschreibungen wie „Projektdaten abrufen“, „Projektdetails holen“ oder „Projektinformationen sichern“ enthielten. Die Auswahl eines Tools erfordert logisches Denken, doch das Team verwandelte dies in eine Multiple-Choice-Frage mit 25 ähnlichen Antworten.

Lösung. In zwei Teilen.

1. Prüfen Sie aggressiv. Führen Sie überschneidende Tools zusammen – hier von 25 auf 11 – und formulieren Sie jede Beschreibung um eine Frage herum: Wann sollte das Modell dieses Tool gegenüber seinen Nachbarn wählen?
2. Laden Sie Tools je nach Kontext. Nicht jeder Knoten benötigt jedes Tool. In LangGraph ist es einfach, jedem Knoten nur den relevanten Teilmenge zuzuweisen; so sieht ein Knoten für Berichtserstellung vielleicht vier Tools statt 25.

Die Tokenkosten pro Runde sanken um etwa ein Drittel, und falsche Tool-Wahlmöglichkeiten verschwanden fast vollständig.

Erkennung. Zählen Sie allein die Tokens in Ihren Tool-Definitionen. Wenn diese die Länge Ihres Systemprompt sowie eines durchschnittlichen Gesprächs zusammen überschreiten, befindet sich Ihr Agent in einer Prüfung mit offenen Büchern, bei der die meisten Seiten falsch sind.

Was die sieben gemeinsam haben

Wenn man den Text siebenmal durchliest, zeigt sich ein klares Muster. Kein Bestandteil war beschädigt und nichts fehlte. Die „Verschmutzung“ bestand konsequent aus überschüssigem, veraltetem oder wiederholtem Inhalt.

Deshalb versagt hier die herkömmliche Fehlersuche. Ingenieure werden darin ausgebildet, nach Fehlern zu suchen: dem fehlenden Null-Check, der unverarbeiteten Ausnahme. Bei Kontextverschmutzung ist hingegen das Gegenteil erforderlich – man muss lernen, nach dem zu suchen, was dort nicht sein sollte.

Falls Sie sich nur eine Gewohnheit aneignen wollen, dann die, den rohen Kontext Ihres Agenten zu lesen. Überspringen Sie die Protokolle und das Überwachungsdashboard und lesen Sie den tatsächlich zusammengesetzten Text, den das Modell bei einer echten Produktionsnutzung erhält. Das ist die wertvollste Stunde für alle, die Agenten entwickeln – und fast niemand nutzt sie.

Eine Sechzig-Sekunden-Checkliste vor dem Deployen

1. Ist ein Zustandswert ein Datum, ein Status oder etwas, das als „aktuell“ bezeichnet wird? (Fall 1)

Kann ein Tool mehr Token zurückgeben als der Systemprompt selbst? (Fall 2)

Kann die alte Version jemals gewinnen, wenn ein Benutzer sich selbst korrigiert? (Fall 3)

Wiederholen sich die abgerufenen Teile jemals? (Fall 4)

Kann eine Einschränkung Wort für Wort dem Zusammenfassungsprogramm standhalten? (Fall 5)

Bleiben Fehlerspuren nach der Wiederherstellung im Historischen verfügbar? (Fall 6)

Wie viele Token verwenden die Tool-Definitionen, bevor der Benutzer etwas eintippt? (Fall 7)

Sieben Fragen. Jede Antwort wie „wahrscheinlich, aber ungewiss“ ist ein Vorfall, der auf einen Zeitpunkt wartet.