Context Rot bei langlaufenden Agenten: Leeren, Compaction, Memory und Sub-Agenten

Context Rot bezeichnet den Genauigkeitsverlust eines LLM bei wachsender Eingabelänge, lange bevor das Kontextfenster voll ist. Ein Fenster von 1M Tokens heißt nicht, dass das Modell das millionste Token so gut nutzt wie das hundertste. Für einen Chat spielt das kaum eine Rolle. Für einen Agenten, der stundenlang läuft und jede gelesene Datei und jeden ausgeführten Befehl anhängt, ist es der Hauptgrund, warum die Qualität spät in einer Aufgabe nachlässt.

Dieser Artikel sammelt die Belege, erklärt, warum Agenten am stärksten betroffen sind, und geht die vier Hebel durch, die in der Praxis funktionieren: alte Tool-Ergebnisse entfernen, Compaction, Notizen und Memory außerhalb des Fensters sowie Sub-Agenten mit eigenem Kontext. Für jeden Hebel zeigt er die aktuellen Mechanismen der Claude- und OpenAI-API und die Harness-Muster, die einen langen Lauf kohärent halten.

Was die Forschung zeigt

Drei Forschungslinien zeigen in dieselbe Richtung. Keine davon nutzt Agenten-Workloads, was eher darauf hindeutet, dass echte Agenten schlechter abschneiden:

Chromas Bericht fügt zwei für Agenten wichtige Details hinzu. Distraktoren, also Inhalte, die relevant aussehen, es aber nicht sind, schaden mit wachsendem Kontext stärker, und die Claude-Modelle in der Studie enthielten sich bei solcher Mehrdeutigkeit eher, statt zu raten. Und entgegen der Intuition schnitten die Modelle bei einem durchmischten Heuhaufen besser ab als bei einem zusammenhängenden. Das Fazit des Berichts ist das nützliche: Ob die relevante Information im Kontext steht, zählt weniger als die Art, wie sie präsentiert wird.

Warum Agenten am stärksten betroffen sind

Die Agentenschleife hängt jeden Tool-Aufruf und jedes Tool-Ergebnis an die Historie und schickt alles beim nächsten Turn wieder mit. Nach zwei Stunden Arbeit besteht der Kontext überwiegend aus veralteten Dateilesungen, alter Testausgabe und überholten Plänen: genau die distraktorlastige Eingabe mit wenig Signal, die die Studien oben bestrafen. Anthropics Leitfaden zum Context Engineering beschreibt es als "Aufmerksamkeitsbudget": Ein Transformer setzt jedes Token zu jedem anderen in Beziehung, n² Paare bei n Tokens, also verdünnt jedes zusätzliche Token die Aufmerksamkeit für die wichtigen. Die Arbeitsregel des Leitfadens lautet, "die kleinstmögliche Menge an Tokens mit hohem Signal" für den nächsten Schritt zu finden.

Das zweite Problem sind die Kosten. Jedes Token in der Historie wird bei jedem Turn erneut abgerechnet; Caching mildert das (siehe Prompt Caching und Routing), aber ein Kontext, der nur wächst, macht jeden späteren Schritt langsamer und teurer und dazu ungenauer.

Vier Hebel: leeren, verdichten, auslagern, isolieren

Alte Tool-Ergebnisse entfernen

Anthropic nennt das Entfernen von Tool-Ergebnissen "eine der sichersten und schonendsten Formen der Compaction": Hat der Agent eine Datei gelesen und darauf reagiert, muss der volle Dateiinhalt selten bleiben. In der Claude-API heißt das Context Editing (Beta-Header context-management-2025-06-27). Die Strategie clear_tool_uses_20250919 greift oberhalb einer Schwelle (standardmäßig 100.000 Eingabe-Tokens), behält die neuesten Tool-Nutzungen (standardmäßig 3) und ersetzt ältere Ergebnisse durch einen Platzhalter:

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    betas=["context-management-2025-06-27"],
    tools=tools,
    messages=messages,
    context_management={"edits": [{
        "type": "clear_tool_uses_20250919",
        "trigger": {"type": "input_tokens", "value": 30000},
        "keep": {"type": "tool_uses", "value": 3},
        "clear_at_least": {"type": "input_tokens", "value": 5000},
        "exclude_tools": ["web_search"],   # results you never want dropped
    }]},
)

Zwei Einstellungen verdienen Aufmerksamkeit. exclude_tools schützt Ergebnisse, die der Agent nicht günstig wiederherstellen kann. clear_at_least gibt es, weil das Leeren den gecachten Prompt-Präfix ab der Änderungsstelle invalidiert; wenn ein Durchgang nur ein paar hundert Tokens frei macht, kostet das Neuschreiben des Caches mehr, als es spart. Eine eigene Strategie clear_thinking_20251015 macht dasselbe für alte Thinking-Blöcke.

Dasselbe geht auch im eigenen Harness ohne Beta: die letzten paar Tool-Ergebnisse wörtlich behalten und ältere durch einen einzeiligen Platzhalter ersetzen, etwa "src/order.ts gelesen (412 Zeilen), siehe Notizen". Der Platzhalter hält die Trajektorie lesbar und wirft den Ballast ab.

Compaction: zusammenfassen und weitermachen

Compaction ersetzt ältere Turns durch eine Zusammenfassung und macht von dort aus weiter. Anthropic beschreibt, wie Claude Code das macht: Das Modell fasst die Historie zusammen, behält Architekturentscheidungen, ungelöste Bugs und Implementierungsdetails und verwirft redundante Tool-Ausgaben. Beide großen APIs bieten das inzwischen serverseitig an:

• Claude, ab einer Token-Schwelle (Beta compact-2026-01-12): compact_20260112 zu context_management.edits hinzufügen. Die Standardschwelle liegt bei 150.000 Eingabe-Tokens, das Minimum bei 50.000. instructions ersetzt den Standard-Zusammenfassungsprompt vollständig, und pause_after_compaction hält nach der Zusammenfassung an, damit du die letzten Turns wörtlich wieder einfügen kannst.
• Claude, auf Abruf (Beta compact-2026-09-04): die Konversation mit "compaction": {"type": "summarize"} schicken; die Antwort ist ein einzelner signierter compaction-Block mit stop_reason "compaction", der in der nächsten Anfrage anstelle der zusammengefassten Nachrichten an erster Stelle steht. Den Zeitpunkt bestimmt deine Anwendung.
• OpenAI Responses API: context_management mit compact_threshold bei responses.create setzen oder den eigenständigen Compact-Endpunkt aufrufen. Das zurückgegebene Compaction-Item ist verschlüsselt und "nicht dafür gedacht, von Menschen interpretiert zu werden"; mit store=false ist der Ablauf ZDR-freundlich.

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    betas=["compact-2026-01-12"],
    tools=tools,
    messages=messages,
    context_management={"edits": [{
        "type": "compact_20260112",
        "trigger": {"type": "input_tokens", "value": 120000},
        "instructions": (
            "Summarise for continuing this task in a new context window. Keep: the goal, "
            "constraints the user stated, decisions made and why, files changed, failing "
            "tests and their errors, open questions, the next step. Drop raw tool output."
        ),
    }]},
)
messages.append({"role": "assistant", "content": response.content})   # keep the compaction block

Eine Zusammenfassung ist absichtlich verlustbehaftet. Was der Standardprompt weglässt, rächt sich meist später: die Vorgabe des Nutzers aus Turn drei, der Grund, warum ein Ansatz verworfen wurde. Schreib eigene Anweisungen für deine Domäne, behalte die letzten Turns wörtlich und teste es: Lass Tasks laufen, die eine Information von vor der Compaction brauchen, und prüfe, ob der Agent sie noch hat.

Notizen und Memory außerhalb des Fensters

Anthropics Harness-Artikel vom November 2025 ist deutlich: "Compaction reicht nicht". Selbst ein Frontier-Modell, das über mehrere Kontextfenster lief, versuchte gern, eine App in einem Rutsch zu bauen, oder erklärte das Projekt zu früh für fertig. Gelöst hat das Zustand auf der Festplatte. Eine Initialisierungs-Session schreibt eine init.sh, ein Log claude-progress.txt und einen ersten git-Commit; für ihre Beispiel-App schrieb sie zudem eine Feature-Liste mit über 200 Anforderungen, alle als fehlschlagend markiert. Jede spätere Session liest Fortschrittsdatei und git-Historie, macht inkrementell Fortschritt an einem Feature und hinterlässt strukturierte Updates.

Das ist der Auslagerungs-Hebel, und auf ihn verlasse ich mich bei Coding-Agenten am meisten: eine Plan-Datei, ein Fortschrittslog und kleine Commits sind billig, überstehen jede Compaction und jeden Absturz und sind für den Menschen lesbar, der die Arbeit prüft. Für Agenten, die nicht dateibasiert arbeiten, bietet Claudes Memory-Tool (memory_20250818) dasselbe Muster als Tool: Das Modell liest und schreibt Dateien unter /memories, und deine Anwendung führt diese Operationen gegen einen Speicher aus, den du kontrollierst. Weil es dein Speicher ist, muss der Handler Pfade außerhalb von /memories ablehnen. Was gespeichert werden sollte und wie man Vergiftung verhindert, beschreibt Memory für KI-Agenten entwerfen.

Sub-Agenten: Isolation mit Preis

Ein Sub-Agent bekommt eine Aufgabe, ein eigenes sauberes Kontextfenster und eigene Tools. Er verbraucht beim Erkunden womöglich zehntausende Tokens, liefert aber laut Anthropic "eine verdichtete, destillierte Zusammenfassung seiner Arbeit (oft 1.000 bis 2.000 Tokens)". Das Fenster des Hauptagenten sieht nur diese Zusammenfassung. Für suchlastige Arbeit ist das der stärkste Hebel gegen Rot, etwa "finde jede Stelle, die Mehrwertsteuer berechnet" in einer großen Codebasis.

Der Preis ist Koordination. Cognitions "Don't Build Multi-Agents" plädiert dafür, vollständige Agenten-Traces zu teilen statt einzelner Nachrichten, weil Aktionen implizite Entscheidungen tragen und Sub-Agenten, die die Entscheidungen der anderen nicht sehen, widersprüchliche Ergebnisse liefern. Meine Regel: Sub-Agenten für lesende Erkundung und Recherche, die Fakten zurückliefert; ein Agent mit vollem Kontext für alles, was schreibt. Wann sich Multi-Agenten-Systeme lohnen geht tiefer.

Von vornherein weniger laden

Das günstigste Token ist das, das nie hinzugefügt wird. Anthropic beschreibt "Just-in-time"-Kontext: Der Agent hält leichte Bezeichner (Dateipfade, gespeicherte Abfragen, Links) und lädt Daten erst bei Bedarf, mit Tools wie head, tail und gezielten Abfragen statt ganze Objekte zu lesen. Das Tool-Design erledigt den Rest:

• Tool-Ausgaben standardmäßig paginieren und kürzen, mit einem klaren Hinweis, wie man mehr bekommt.
• Zusammenfassungen plus Handles zurückgeben, keine Rohdumps: "143 passende Bestellungen, die ersten 10 unten, Abfrage-ID q_17".
• Stabile Anweisungen kurz und vorne halten und das aktuelle Ziel samt Vorgaben ans Ende des Kontexts setzen, wo Modelle laut den Ergebnissen von Lost in the Middle am besten hinschauen.
• Retrieval statt Vollstopfen. Die Abwägung zwischen langem Kontext und Suche beschreibt RAG im Jahr 2026; für Coding-Agenten ordnet Tools zum Token-Sparen die Optionen nach Beleglage.

Es im eigenen Agenten messen

Context Rot ist eine Eigenschaft deines Workloads, also miss sie dort. Drei günstige Signale:

1. Eingabe-Tokens pro Turn loggen und den Task-Erfolg gegen die Kontextgröße auftragen, bei der jeder Task endete. Fällt der Erfolg in den oberen Bereichen ab, ist deine Schwelle zu hoch.
2. Früh eine Vorgabe setzen und spät prüfen. Ein Eval-Task, der in Turn eins eine Regel nennt ("fass das Zahlungsmodul nie an") und sie nach einer Compaction braucht, zeigt dir, ob deine Zusammenfassung das Wichtige behält.
3. Mit einer frischen Session vergleichen. Gescheiterte späte Schritte in einer neuen Session wiederholen, die nur Notizen und Fortschrittsdatei bekommt. Gelingt es dort, lag das Problem am Kontext, nicht am Modell.

Diese Prüfungen passen direkt in die Trajektorien-Evals und Traces, die du schon hast; Agent-Observability mit OpenTelemetry zeigt, wie du Token-Zahlen pro Span erfasst.

Checkliste

1. Das Kontextfenster als Genauigkeitsbudget behandeln, nicht als Speichergrenze.
2. Tool-Ausgaben paginieren und kürzen; Handles und Zusammenfassungen zurückgeben.
3. Zuerst alte Tool-Ergebnisse entfernen, mit Ausnahmen für teuer wiederherstellbare Ergebnisse.
4. Mit domänenspezifischen Anweisungen verdichten, die letzten Turns wörtlich behalten und die ganze Antwort anhängen, damit der Compaction-Block erhalten bleibt.
5. Pläne, Fortschritt und Entscheidungen auf der Festplatte oder in einem Memory-Store halten, den der Agent zu Beginn jeder Session liest.
6. Sub-Agenten für lesende Erkundung mit kurzen Zusammenfassungen nutzen; Schreibvorgänge in einem Agenten mit vollem Kontext belassen.
7. Aktuelles Ziel und Vorgaben ans Ende des Kontexts setzen.
8. Erfolg gegen Kontextgröße messen und prüfen, ob frühe Vorgaben die Compaction überstehen.

Wenn deine Agenten bei langen Aufgaben nachlassen und du eine zweite Meinung zum Harness willst, siehe AI Engineering.

Quellen

1. Chroma: Context Rot: How Increasing Input Tokens Impacts LLM Performance (Jul 2025)
2. Liu et al.: Lost in the Middle: How Language Models Use Long Contexts (2023)
3. Modarressi et al.: NoLiMa: Long-Context Evaluation Beyond Literal Matching (2025)
4. Anthropic: Effective context engineering for AI agents (Sep 2025)
5. Anthropic: Effective harnesses for long-running agents (Nov 2025)
6. Claude API docs: Compaction at a token threshold
7. Claude API docs: Compaction on demand
8. Claude API docs: Context editing
9. Claude API docs: Memory tool
10. OpenAI API docs: Compaction
11. Cognition: Don't Build Multi-Agents