Kontextfenster eines LLM-Agenten: Was hineinpasst und warum der Agent Regeln vergisst

Was das Kontextfenster eines LLM ist

Das Kontextfenster eines LLM ist der gesamte Text, den das Modell als Eingabe erhält, wenn es die nächste Antwort erzeugt. Das Modell hat kein Gedächtnis im menschlichen Sinn: Alles, was es in diesem Moment über Ihre Aufgabe »weiß«, steht in diesem Fenster. Was nicht im Fenster steht, existiert für das Modell nicht.

Die Größe des Fensters wird in Token gemessen — Wortstücken. Deutscher Text zerfällt in mehr Token als englischer, weil Zusammensetzungen wie »Datenbankverbindungsfehler« in mehrere Teile zerlegt werden. Dieselbe Anweisung kostet also je nach Sprache unterschiedlich viel. Moderne Modelle haben Fenster mit Hunderttausenden Token, da scheint der Platz für alles zu reichen. In der Praxis ist der Platz für einen Agenten schneller aufgebraucht, als man erwartet, und die Qualität sinkt noch früher.

Was im Kontextfenster eines Agenten landet

Ein Agent für die Programmierung hat genau drei Informationsquellen: den Systemprompt mit der Beschreibung der Aufgabe, den Inhalt der Dateien, die er gelesen hat, und die Ausgaben der Werkzeuge, die er aufgerufen hat. Alle drei leben im selben Fenster und konkurrieren um den Platz.

Entscheidend ist: Nichts davon verschwindet von selbst. Das Protokoll fehlgeschlagener Tests, das vor zwanzig Schritten nötig war, liegt weiterhin im Fenster und nimmt dem aktuellen Schritt Aufmerksamkeit weg. Eine lange Sitzung ist ein immer größer werdender Haufen, in dem es immer schwerer wird, die richtige Nadel zu finden.

Warum der Agent in langen Sitzungen Regeln vergisst

Eine häufige Klage: Zu Beginn der Sitzung hält sich der Agent sorgfältig an die Regeln aus der CLAUDE.md, nach einer Stunde Arbeit beginnt er, sie zu verletzen. Er hat sie im wörtlichen Sinn nicht vergessen — der Text der Regeln steht noch im Fenster. Das Problem liegt darin, wie das Modell seine Aufmerksamkeit über einen langen Text verteilt.

Lost in the middle

Eine Untersuchung von Liu et al. aus dem Jahr 2023 zeigte: Sprachmodelle nutzen Informationen am Anfang und am Ende eines langen Kontexts deutlich besser als solche aus der Mitte. Die Anweisungsdatei wird zu Beginn der Sitzung geladen, doch mit fortschreitendem Gespräch wächst oben und unten immer mehr Text. Eine Regel, die anfangs gut sichtbar war, gerät allmählich in den Bereich, den das Modell am schlechtesten erfasst.

Der Anteil der Regeln im Fenster sinkt

In einer frischen Sitzung sind die Anweisungen ein spürbarer Teil des Kontexts. Nach hundert Werkzeugaufrufen werden sie zu einem kleinen Fragment zwischen Logs, Diffs und gelesenem Code. Das Signal bleibt gleich, der Lärm drumherum wird dutzendfach größer.

Frische Beispiele wiegen schwerer als alte Regeln

Das Modell stützt sich stark auf das, was im Gespräch kürzlich passiert ist. Hat der Agent mehrfach eine Regel umgangen und ist damit durchgekommen, wiegt dieses Muster im Verlauf mehr als die Zeile mit der Anweisung irgendwo am Anfang.

Context Rot: Qualitätsverlust lange vor der Grenze

Context Rot (»Verrottung des Kontexts«) nennt man den Effekt, bei dem die Qualität der Antworten sinkt, je voller das Fenster wird, obwohl die technische Grenze noch weit entfernt ist. Das Modell akzeptiert formal 200.000 Token, arbeitet bei 150.000 aber schlechter als bei 20.000: Es verwechselt Details häufiger, schlägt bereits verworfene Lösungen erneut vor und verliert Anweisungen.

Anzeichen, dass eine Sitzung »verrottet« ist:

• Der Agent schlägt einen Ansatz vor, den Sie vor einer halben Stunde zusammen verworfen haben.
• Er verwechselt Namen von Dateien und Funktionen, die schon besprochen wurden.
• Er hört auf, Prüfungen zu starten, die er zu Beginn selbst gestartet hat.
• Die Antworten werden länger und verschwommener, es tauchen unnötige »habe nebenbei noch korrigiert«-Passagen auf.

Eine weitere Regel hinzuzufügen hilft dagegen nicht: Die neue Regel geht im selben Rauschen unter. Man muss das Rauschen verringern.

Kompaktierung des Kontexts

Kompaktierung ist die Verdichtung des Sitzungsverlaufs: Das Modell schreibt eine kurze Zusammenfassung dessen, was passiert ist, und das Gespräch läuft dann mit dieser Zusammenfassung statt mit dem vollständigen Verlauf weiter. Das Fenster wird frei, und der Kern der Arbeit bleibt — so scheint es zumindest.

In Claude Code gibt es dafür den Befehl /compact, dem Sie einen Hinweis mitgeben können, worauf bei der Verdichtung zu achten ist. Nähert sich das Fenster der Grenze, führt Claude Code die Kompaktierung auch automatisch aus. Der Befehl /clear löscht den Verlauf vollständig und beginnt mit einem leeren Blatt, und /context zeigt, wie das Fenster gerade belegt ist.

/context
/compact behalte: Ziel der Aufgabe, getroffene Entscheidungen mit Begründung, Liste der geänderten Dateien, was noch zu prüfen ist
/clear

Was an der Kompaktierung gefährlich ist

Eine Nacherzählung verliert immer Details. In der verdichteten Zusammenfassung fehlen womöglich die verworfene Variante und der Grund der Ablehnung, die genaue Formulierung einer Anforderung oder eine Nebenbemerkung, auf die Sie sich beiläufig geeinigt haben. Danach arbeitet der Agent mit einem fremden Konspekt der eigenen Sitzung. Deshalb sollten Sie wichtige Dinge nicht im Gesprächsverlauf halten, sondern in Dateien, die jede Kompaktierung überstehen.

Kompaktierung oder neue Sitzung

Wie Sie das Kontextfenster sparsam nutzen

Den Kontext zu sparen hat nichts mit dem Preis der Token zu tun, sondern mit der Qualität der Arbeit. Je weniger Rauschen im Fenster liegt, desto mehr Aufmerksamkeit bekommen die Aufgabe und die Regeln.

1. Eine kurze Anweisungsdatei als Wegweiser

Die Einstiegsdatei CLAUDE.md oder AGENTS.md wird in jeder Sitzung vollständig gelesen. Eine Datei mit 600 Zeilen kostet etwa 10.000 bis 20.000 Token dauerhaft. Halten Sie darin die Prüfbefehle, die harten Vorgaben und eine Übersicht über das Projekt, die Details zu einzelnen Themen legen Sie in eigene Dokumente, die der Agent nur bei Bedarf öffnet.

2. Wissen, das bei Bedarf geladen wird

Die Skills in Claude Code sind so aufgebaut, dass zuerst nur ihre kurze Beschreibung in den Kontext gelangt und der vollständige Text erst geladen wird, wenn der Skill für die Aufgabe nötig ist. So halten Sie seltene Abläufe — Deployment, Migrationen, Release — griffbereit, ohne in jeder Sitzung dafür zu bezahlen.

3. Subagenten für laute Arbeit

Ein Subagent arbeitet in seinem eigenen Kontextfenster und gibt der Hauptsitzung nur das Ergebnis zurück. Die Suche in großem Code, die Analyse eines langen Logs, das Einarbeiten in ein unbekanntes Modul — all das lässt sich an einen Subagenten geben, und als Antwort kommen einige Absätze mit Schlussfolgerungen statt Tausender Zeilen Rohausgabe.

4. Leise Werkzeugausgaben

Die Ausgabe von Befehlen ist der größte Fresser des Fensters. Richten Sie die Prüfbefehle so ein, dass sie bei Erfolg eine einzige Zeile ausgeben und bei Fehlern nur das Wesentliche: den fehlgeschlagenen Test und seine Meldung, nicht das komplette Build-Protokoll.

# laut: Tausende Zeilen pro Lauf im Fenster
pytest -v

# leise: bei Erfolg eine Zeile, bei Fehler nur die fehlgeschlagenen Tests
pytest -q --tb=short

# Logs nicht komplett, sondern nur das Ende und die Fehler
tail -n 50 app.log | grep -i error

5. Eine Aufgabe — eine Sitzung

Ziehen Sie eine Sitzung nicht durch drei unzusammenhängende Aufgaben. Der Verlauf der ersten Aufgabe ist für die dritte nutzlos, belegt aber Platz und verwirrt den Agenten. Ist eine Aufgabe erledigt, halten Sie das Ergebnis fest und öffnen eine neue Sitzung.

6. Der Stand gehört in Dateien, nicht in den Verlauf

Alles, was eine Kompaktierung und eine neue Sitzung überstehen soll, schreiben Sie ins Repository: das Ziel, die Entscheidungen mit Begründung, die verworfenen Varianten, was erledigt und wie es geprüft wurde, den nächsten Schritt. Zum Beispiel in PLAN.md und PROGRESS.md. Dann beginnt eine neue Sitzung nicht mit einer Nacherzählung, sondern mit einem präzisen Dokument, und Sie können den Verlauf ohne Sorge löschen.

# PROGRESS.md
## Ziel
Berechnung der Rabatte auf ganze Cent umstellen

## Erledigt (geprüft)
- app/payments/discount.py: float → int, make test grün
- Migration 041 hinzugefügt, lokal angewendet

## Entscheidungen
- Rundung — kaufmännisch, wie beim Zahlungsanbieter

## Verworfen
- Decimal im Modell: bricht die Serialisierung der Webhooks

## Nächster Schritt
End-to-End-Szenario der Bestellung aktualisieren und make e2e ausführen

Kritische Regeln gehören nicht nur ins Fenster

Auch ein perfekt aufgebauter Kontext garantiert nicht, dass Regeln eingehalten werden: Text im Fenster beeinflusst das Modell, ist aber kein ausführbares Verbot. Ist ein Verstoß nicht hinnehmbar, muss die Regel mechanisch geprüft werden. In Claude Code dafür gibt es Hooks — Befehle, die bei Ereignissen des Agenten laufen und eine Aktion blockieren können — und Berechtigungseinstellungen, die bestimmte Werkzeuge oder Befehle untersagen. Linter, Tests und CI arbeiten unabhängig davon, was gerade im Fenster des Agenten passiert.

Eine gute Regel für das Harness: Alles, was sich automatisch prüfen lässt, wird automatisch geprüft, und im Kontext bleibt nur, was ein Urteil verlangt.

Fazit

Das Kontextfenster eines LLM ist der einzige Ort, an dem der Agent Ihre Aufgabe sieht, und es füllt sich schneller, als man denkt: Anweisungen, Verlauf, gelesene Dateien und Befehlsausgaben sammeln sich bis zum Ende der Sitzung. Die Qualität sinkt lange vor der technischen Grenze, Regeln aus der Mitte eines langen Kontexts gehen verloren, und die Kompaktierung rettet Platz auf Kosten der Details. Halten Sie Anweisungen kurz, laden Sie seltenes Wissen bei Bedarf nach, lagern Sie laute Arbeit an Subagenten aus, bewahren Sie den Stand in Dateien auf und sichern Sie kritische Regeln durch Hooks und Prüfungen ab. Den Umgang mit dem Kontext des Agenten behandeln wir im Kurs zum Harness Engineering praktisch.