Context Engineering für KI-Agenten mit langem Zeithorizont

Zusammengenommen deuten Arizes Analyse, das arXiv-Paper zu Context Window Overflow, Redis’ Production-Erklärung und Atlans Vergleich zum Harness Engineering auf einen praktischen Wandel im Agentendesign hin. Lang laufende Agenten werden weniger nach der Größe des Kontextfensters des Modells bewertet und stärker nach der Kontrollschicht darum herum. Arize macht diesen Wandel konkret. Die Analyse nennt ausgelieferte Agent-Tools und Speicher-/Harness-Systeme, darunter Pi, OpenClaw, Claude Code und Letta, als Beispiele für Context Engineering auf Harness-Ebene und beschreibt einen interaktiven Simulator, der zeigt, wie sich ein Fenster mit 200K token füllt.

Die öffentlichen Details in den zitierten Quellen sind unterschiedlich ausführlich. Arize liefert konkrete Implementierungszahlen für Pi, OpenClaw, Claude Code und Letta. Ein Forschungspaper zum Lösen von Context Window Overflow in KI-Agenten beschreibt einen allgemeineren Mechanismus für den Umgang mit Tool-Ausgaben, die jedes praktikable Fenster überschreiten können. Redis’ Erklärung zu Context Window Overflow fasst die Produktionssymptome zusammen: harte API-Fehler, stille Qualitätsverschlechterung, Ansammlung von Tool-Ausgaben und längere Latenz, wenn Prompts wachsen. Atlans Vergleich von Prompt, Context und Harness Engineering liefert die nützliche Stack-Metapher: Prompt Engineering formt die Nachricht, Context Engineering formt, was das Modell sieht, und Harness Engineering formt die gesamte Agentenumgebung.

Die wichtige Nachricht ist nicht, dass Kontextfenster zu klein sind. Das wissen Builder bereits. Der nützlichere Punkt ist, dass die zitierten Agentensysteme auf vier Harness-Mechanismen zulaufen, die Arbeit am Leben halten, nachdem das Protokoll keine sichere Quelle der Wahrheit mehr ist.

Ein oberflächlicher Agent liest Dateien, ruft Tools auf, hängt das Ergebnis an und hofft, dass das Modell damit umgehen kann. Ein Harness-first-Agent blockiert oder formt große Eingaben um, bevor sie das Modell erreichen.

Die erste Gruppe von Limits lässt sich sauberer so lesen:

• Pi: Dateilesevorgänge stoppen bei 2.000 Zeilen oder 50KB, je nachdem, was zuerst erreicht ist. Der zurückgegebene Inhalt enthält einen Fortsetzungshinweis, der dem Modell sagt, welcher Zeilenbereich gezeigt wurde und wie es mit offset und limit weitermachen kann. OpenClaw übernimmt dieses Verhalten und ergänzt separate Obergrenzen: Bootstrap-Dateien sind auf 12.000 Zeichen pro Datei und 60.000 Zeichen insgesamt begrenzt. Tool-Ergebnisse bekommen ein weiteres Budget von 16.000 Zeichen oder 30% des Kontextfensters, je nachdem, was kleiner ist.

Claude Code nutzt ein Zwei-Gate-Design. Laut Arize prüft es vor dem Öffnen einer Datei eine Byte-Obergrenze von 256KB und zählt das Ergebnis nach dem Lesen anschließend gegen ein Budget von 25.000 token. Selbst bei Dateien unterhalb der Obergrenze gibt es standardmäßig 2.000 Zeilen ab dem Anfang zurück und kürzt Zeilen, die länger als 2.000 Zeichen sind. Wenn das Modell denselben Dateibereich erneut liest und sich die Datei nicht geändert hat, kann Claude Code statt des vollständigen Inhalts einen Stub zurückgeben.

Das ist nicht nur Optimierung. Es verändert den Fehlermodus. Statt zuzulassen, dass ein großer Lesevorgang die Aufgabe verdrängt, macht der Harness aus „alles lesen“ ein „kontrollierten Ausschnitt lesen“. Wenn das Modell mehr braucht, kann es danach fragen. Für Builder, die Agent-Harnesses von Grund auf entwerfen, ist das die erste Verteidigungslinie: Lass rohe externe Daten nie standardmäßig zum Protokoll werden.

Das nächste Muster besteht darin, Kontext wie einen Viewport zu behandeln, nicht wie Speicher.

Pi und Claude Code machen Paginierung über offset und limit verfügbar. OpenClaw ergänzt an manchen Stellen Head-/Tail-Trunkierung und behält Anfang und Ende, wenn die Mitte wahrscheinlich weniger wichtig ist. Arize sagt, OpenClaw nutze für übergroße Bootstrap-Dateien eine Aufteilung von 75% Head / 25% Tail und könne bei Tool-Ergebnissen sowohl Head als auch Tail behalten, wenn der Tail wichtig wirkt, etwa bei Fehlern, schließenden JSON-Klammern oder summary-ähnlichen Keywords.

Letta geht weiter, indem Dateien außerhalb des Prompts leben. Hochgeladene Dateien werden geparst, in Chunks aufgeteilt und in einen Vektorspeicher eingebettet, wodurch der Agent direkte Ansicht, exakte Suche und semantische Suche erhält. Wenn eine Datei im Kontext geöffnet ist, zeigt Letta eine verwaltete Ansicht, deren Größe mit dem Modellkontext skaliert: 5.000 Zeichen für 8K-Kontext, 15.000 für 32K, 25.000 für 128K und 40.000 für 200K+. Auch die Anzahl gleichzeitig geöffneter Dateien skaliert, von 3 bei kleinen Modellen bis zu 15 bei sehr großen, wobei eine LRU-Policy die am längsten nicht aufgerufenen Dateien verdrängt.

Das ist dieselbe Designidee wie hinter Production-RAG: Stopfe nicht den gesamten Korpus in den Prompt; rufe den relevanten Teil ab. Der Unterschied ist, dass Agent-Harnesses das kontinuierlich tun müssen, über Dateien, Tool-Ausgaben, Speicher und Zwischenpläne hinweg. Dieselbe Einschränkung gilt für RAG-Systeme: Bei Retrieval geht es nicht nur um Relevanz, sondern auch darum, genug Kontextbudget für den eigentlichen Reasoning-Schritt zu erhalten.

Redis macht einen verwandten Punkt: Größere Kontextfenster nehmen einem das Kontextmanagement nicht ab. System-Prompts, abgerufene Dokumente, Gesprächshistorie und Tool-Ausgaben konkurrieren alle um denselben Platz. Schon bevor ein hartes Limit erreicht ist, kann die Modellqualität sinken, wenn relevante Informationen in langen Eingaben vergraben werden.

Überlauf ist der offensichtliche Fehler. Zielverlust ist leiser. Der Agent hat noch Platz zum Antworten, vergisst aber das ursprüngliche Ziel, übersieht eine Einschränkung oder beginnt, eine lokale Teilaufgabe zu optimieren.

Genau hier zählt Kompaktierung. Schlecht gemacht ersetzt Zusammenfassung eine unordentliche, aber treue Historie durch eine saubere, aber verlustbehaftete Geschichte. Gut gemacht erhält sie Aufgabenstatus, aktuelle Arbeit, offene Punkte und die Integrität von Tool-Aufrufen.

Arize berichtet, dass Pi Kompaktierung auslöst, wenn die geschätzten Kontext-token das Kontextfenster minus Reserve-token überschreiten, mit einer Standardreserve von 16.384 token. Es behält die neuesten rund 20.000 token und fasst ältere Inhalte in einer synthetischen User-Nachricht zusammen, die dem behaltenen Tail vorangestellt wird. Außerdem vermeidet es, Tool-Call-/Tool-Result-Paare zu durchschneiden.

OpenClaw ergänzt eine aggressivere History-Policy. Wenn die Historie 50% des Kontextfensters überschreitet, teilt es Nachrichten in Token-Chunks mit gleicher Masse auf, verwirft den ältesten Chunk, fasst die verworfenen Inhalte über gestufte Multi-Pass-Zusammenfassung zusammen und repariert Tool-Call-/Result-Paarungen. Außerdem führt es vor der Kompaktierung einen Flush aus: Ein stiller agentischer Turn gibt dem Agenten die Chance, Zustand in Speicherdateien zu persistieren, bevor Historie verschwindet. Separat beschneidet es Tool-Ergebnisse im Speicher mit Soft-Trim- und Hard-Clear-Verhalten bei einer Cache-TTL von 5 Minuten.

Claude Code kompaktiert nahe am Ende des Fensters. Arize sagt, der Trigger sei das effektive Kontextfenster minus einen Puffer von 13.000 token, was die Kompaktierung bei einem Modell mit 200K-Kontext auf etwa 167K token legt. Sein Zusammenfassungs-Prompt fordert strukturierte Abschnitte zur Hauptanfrage, zu technischen Konzepten, Dateien und Code, Fehlern und Fixes, Problemlösung, User-Nachrichten, offenen Aufgaben, aktueller Arbeit und nächstem Schritt. Nach der Kompaktierung kann es bis zu 5 kürzlich gelesene Dateien innerhalb eines Token-Budgets wieder anhängen.

Das Muster ist klar: Kompaktierung bedeutet nicht „den Chat zusammenfassen“. Sie ist Checkpointing. Ein lang laufender Agent braucht das Äquivalent einer Speicherdatei: Ziel, Einschränkungen, Entscheidungen, offene Handles, aktuelle Evidenz und nächste Aktion.

Manche Ausgaben sollten überhaupt nie im Kontextfenster landen.

Das arXiv-Paper macht das mit einem Workflow aus der Materialwissenschaft konkret. Ein Tool erzeugt eine elektronische Gitterstruktur für ein Molekül: eine 3D-Matrix mit den Dimensionen 128 × 128 × 128, insgesamt 2.097.152 float32-Elemente. Diese Ausgabe übersteigt das Kontextfenster weit verbreiteter LLMs bei Weitem. Das nächste Tool braucht das Gitter aber als Eingabe.

Die vorgeschlagene Lösung ist, große Werte außerhalb des Modellkontexts zu speichern und kurze Identifikatoren oder Pointer zurückzugeben. Tool-Wrapper prüfen Eingaben darauf, ob es sich um Rohwerte oder Speicherpfade handelt. Zu große Ausgaben werden im Runtime-Speicher unter einem Pfad abgelegt, und spätere Tools können den Pointer erhalten und intern auflösen. Das Modell manipuliert Referenzen, während der Harness die vollständigen Daten erhält. In einem Vergleichsexperiment, in dem beide Methoden erfolgreich waren, nutzte der pointerbasierte Ansatz laut Paper ungefähr siebenmal weniger token als der traditionelle Workflow.

Das ist die sauberste Trennung zwischen Reasoning und Datentransport. Das Modell muss eine Matrix mit 2 Millionen Elementen nicht „sehen“, um sie an ein anderes Tool weiterzugeben. Es muss wissen, dass die Matrix existiert, wofür sie steht und welche Operation sie als Nächstes verarbeiten soll.

Dieselbe Logik gilt über wissenschaftliche Arrays hinaus. Große JSON-Antworten, PDFs, Logs, Embeddings, Mediendateien und Datenbankexporte gehören oft in den Speicher, nicht in den Prompt. Für Systeme rund um MCP-Tools oder eigene API-Connectors sollte Pointer Passing eine Designentscheidung erster Klasse sein, kein Patch nach dem ersten Überlauf.

Ein Kontextfenster mit 200K token wirkt groß, bis ein Agent anfängt zu handeln. Ein System-Prompt, Tool-Definitionen, ein paar abgerufene Dokumente, Dateilesevorgänge, Logs, Fehlertraces und Zusammenfassungen können es schneller verbrauchen als erwartet. Der praktische Rahmen ist nicht, wie groß das Fenster auf dem Papier aussieht, sondern wie schnell Agenten es zur Laufzeit ausgeben. Redis’ Leitfaden zu Agent Memory weist in Richtung externen, dauerhaften Speichers für Zustand, der über Aufrufe hinweg bestehen soll, während Atlans Context-Engineering-Framing bessere Prompts von besserem Kontextaufbau trennt. Zusammengenommen behandeln sie das Kontextfenster weniger wie ein Lagerhaus und mehr wie ein begrenztes Working Set.

Die tiefere Lektion ist, dass ein Kontextfenster eine knappe Runtime-Ressource ist. Es als „Speicher“ zu behandeln, ist hilfreich, aber nur, wenn sich der Harness wie ein Betriebssystem verhält: zuweisen, verdrängen, auslagern, kompaktieren, deduplizieren und persistieren. Atlans Ebenenunterscheidung ist hier nützlich. Prompt Engineering kann keinen Dateileser reparieren, der 80.000 irrelevante token in den nächsten Aufruf kippt. Context Engineering kann das Working Set verbessern. Harness Engineering entscheidet, ob dieses Working Set überhaupt geschützt wird.

Das verändert auch, wie Teams Agenten evaluieren sollten. Ein Demo-Prompt reicht nicht. Evaluation mit langem Zeithorizont sollte wachsende Protokolle, wiederholte Dateilesevorgänge, große Tool-Ausgaben, fehlgeschlagene Tool-Aufrufe, Wiederaufnahmen nach Kompaktierung und Aufgaben enthalten, bei denen der korrekte nächste Schritt von einer frühen Einschränkung abhängt. Unser Leitfaden zu Context Engineering für Agenten behandelt die modellseitige Version dieses Problems; auf der Harness-Ebene wird es operativ.

Erstens: Lege Budgets für jede Kontextquelle fest. Dateien, Tool-Ausgaben, abgerufene Chunks, Speichereinfügungen und Gesprächshistorie sollten jeweils explizite Limits haben. Eine einzige globale maximale Token-Zahl ist zu grob.

Zweitens: Mache Trunkierung handlungsorientiert. Wenn der Harness Inhalte kürzt, sollte das Modell wissen, welchen Bereich es gesehen hat und wie es mehr anfordern kann. Stille Trunkierung ist schlimmer als Ablehnung, weil sie selbstsicheres Arbeiten auf Basis fehlender Daten erzeugt.

Drittens: Kompaktiere um Zustand herum, nicht um Prosa. Zusammenfassungen sollten das Ziel des Users, Einschränkungen, Entscheidungen, offene Aufgaben, berührte Dateien, relevante Tool-Ergebnisse und den unmittelbaren nächsten Schritt erhalten. Tool-Call-Paare sollten intakt bleiben.

Viertens: Verschiebe große Werte aus dem Prompt heraus. Speichere sie, benenne sie und reiche Pointer durch Tools weiter. Das ist besonders wichtig für Agenten, die APIs aufrufen, Dokumente verarbeiten oder Multi-Agent-Systeme koordinieren.

Teste schließlich Zielverlust getrennt von Überlauf. Ein Agent kann unter dem harten Fenster bleiben und trotzdem abdriften. Die richtige Frage lautet nicht nur: „Hat die API den Prompt akzeptiert?“ Sondern: „Dient die nächste Aktion noch der ursprünglichen Aufgabe?“

Die folgende Zusammenfassung macht aus diesen Mustern eine kurze Checkliste vor dem FAQ.

• Agenten mit langem Zeithorizont scheitern sowohl durch Kontextüberlauf als auch durch Zielverlust, deshalb muss der Harness mehr verwalten als nur die Prompt-Länge.
• Production-Agentensysteme nutzen harte Budgets für Dateien, Tool-Ausgaben und Historie, bevor Rohdaten das Modell erreichen.
• Paginierung, Suche und verwaltete Ansichten behandeln Kontext als begrenzten Viewport statt als dauerhaften Speicher.
• Kompaktierung funktioniert am besten als Checkpointing: Sie erhält Ziele, Einschränkungen, Entscheidungen, offene Arbeit und die Integrität von Tool-Aufrufen.
• Große Tool-Ausgaben gehören oft in externen Speicher, wobei kurze Pointer zwischen Tools weitergereicht werden, statt vollständige Werte in den Prompt zu legen.

Dieser Abschnitt beantwortet die praktischen Fragen hinter Context Engineering für Agenten mit langem Zeithorizont: was überläuft, wie Ziele verloren gehen und welche Harness-Muster Arbeit auf Kurs halten.

Kontextüberlauf entsteht, wenn der angesammelte Prompt, die Historie, abgerufene Daten, Dateien und Tool-Ausgaben eines Agenten das nutzbare Kontextfenster des Modells überschreiten oder die Qualität verschlechtern, bevor das harte Limit erreicht ist.

Zielverlust entsteht, wenn die ursprüngliche Aufgabe irgendwo im Protokoll noch vorhanden ist, aber die nächste Aktion des Agenten nicht mehr steuert, oft nach langen Historien oder schlechter Zusammenfassung.

Sie setzen Budgets pro Quelle, paginieren Dateilesevorgänge, rufen nur relevante Ansichten ab, kompaktieren Historie um Zustand herum, deduplizieren wiederholte Lesevorgänge und speichern große Ausgaben außerhalb des Prompts.

Pointer lassen das Modell auf große Werte im Runtime-Speicher verweisen, etwa Matrizen, Logs oder PDFs, während nachgelagerte Tools die vollständigen Daten auflösen, ohne sie ins Kontextfenster zu legen.

Nein. Größere Fenster helfen, aber System-Prompts, Tool-Definitionen, abgerufene Dokumente, Logs und Historie konkurrieren weiterhin um Platz, und relevante Informationen können vergraben werden, bevor ein hartes Limit erreicht ist.