Context Engineering erklaert

Was das Context Window tatsächlich hält

Das Context Window ist alles, was das Modell sehen kann, wenn es seine nächste Antwort generiert, gemessen in Tokens (Text-Stücke, grob vier Zeichen je Token). Für einen Coding Agent füllt es sich mit mehr als deiner letzten Nachricht: dem System Prompt, der den Agenten definiert, deinen CLAUDE.md- oder AGENTS.md-Regeln, den Definitionen jedes verbundenen Tools und MCP-Servers, jeder Datei, die der Agent gelesen hat, jedem Befehls-Output, den er gesehen hat, und der gesamten bisherigen Konversation. All das konkurriert um dasselbe endliche Budget. Das Mental Model, das zählt: Kontext ist eine knappe Ressource, die du ausgibst, und alles, was du lädst (ein gesprächiger MCP-Server, eine riesige Datei, ein langes Hin und Her), ist Budget, das die eigentliche Aufgabe nicht mehr hat. Siehe das Glossar zum Context Window für die formale Definition.

• Der System Prompt und deine CLAUDE.md- / AGENTS.md-Regeln, jede Runde neu geladen.
• Tool- und MCP-Server-Definitionen, weshalb das Verbinden vieler Server teuer ist.
• Jede gelesene Datei und jeder Befehls-Output, was sich während einer Aufgabe schnell aufsummiert.
• Die gesamte Konversations-Historie; lange Sessions tragen ihre ganze Vergangenheit mit.

Warum ein volles Window schadet: die Performance-Klippe

Es ist verlockend zu denken, ein grösseres Context Window heisse, du müsstest dir keine Sorgen mehr machen, aber das Gegenteil stimmt: Die Modellqualität sinkt deutlich, bevor das Window technisch voll ist, und sie sinkt scharf. Während das Window sich mit Dateien, Historie und Rauschen füllt, hat das Modell mehr zu beachten und verliert eher den Faden, widerspricht einer früheren Anweisung oder vergisst eine Constraint vom Anfang der Konversation. Das ist die "Performance-Klippe", und sie ist der Grund, warum ein 1M-Token-Window nicht heisst, dass du 1M Tokens hineinschütten solltest. Die praktische Erkenntnis ist kontraintuitiv, aber verlässlich: Ein kleinerer, gut kuratierter Kontext übertrifft meist einen grösseren, vollgestopften. Context Engineering existiert genau, um dich auf der guten Seite dieser Klippe zu halten.

• Die Qualität fällt, bevor das Window voll ist, und der Fall ist eine Klippe, kein sanftes Gefälle.
• Ein vollgestopftes Window lässt das Modell Fäden verlieren, sich widersprechen und Constraints fallen lassen.
• Ein grosser Maximalkontext ist eine Decke, kein Ziel; füll ihn nicht, weil du kannst.
• Ein kuratierter kleiner Kontext schlägt einen aufgeblähten grossen, die zentrale Regel des Context Engineering.

Lost in the Middle

"Lost in the Middle" ist ein gut dokumentiertes Verhalten von Sprachmodellen: Sie beachten Information am Anfang und am Ende ihres Kontexts am verlässlichsten und am wenigsten verlässlich Information, die in der Mitte vergraben ist. Eine entscheidende Anweisung oder die eine relevante Tatsache, in die Mitte eines langen Prompts oder einer langen Konversation fallen gelassen, ist das, was am ehesten ignoriert wird. Die praktische Konsequenz prägt, wie du Kontext anordnest. Setz die wichtigsten Anweisungen und das relevanteste Material dorthin, wo das Modell hinschaut: nahe dem Anfang (deine stehenden Regeln) und nahe dem Ende (die unmittelbare Aufgabe und die Schlüssel-Datei). Nimm nicht an, dass das Modell etwas nutzt, nur weil es irgendwo im Window steht. Position ist Hebel.

• Modelle beachten Anfang und Ende des Kontexts am besten, die Mitte am schlechtesten.
• Eine Schlüssel-Anweisung mitten im Prompt vergraben wird am ehesten ignoriert.
• Setz stehende Regeln nahe an den Anfang und die unmittelbare Aufgabe und Schlüssel-Datei nahe ans Ende.
• Im Window zu sein heisst nicht, genutzt zu werden; Position bestimmt Aufmerksamkeit.

Compaction, Handovers und Resets

Wenn eine Session lang läuft, brauchst du Wege, Gewicht abzuwerfen, ohne den Faden zu verlieren. Drei Techniken erledigen das meiste. Compaction fasst die bisherige Konversation in kompakter Form zusammen und macht weiter, befreit das Window; der Haken ist, dass automatische Compaction still Details fallen lässt, die dir wichtig waren, also steuere sie, indem du dem Agenten sagst, was er vor der Compaction bewahren soll. Ein Handover beendet eine Session und startet eine frische mit einer sauberen, bewussten Zusammenfassung, die du schreibst, was dir einen weit aufgeräumteren Kontext gibt, als eine Session stundenlang ausufern zu lassen. Ein Reset wirft einen Kontext weg, der verwirrt ist, und startet neu mit einem engen Prompt, was oft schneller ist, als einen entgleisten Agenten zurück auf Kurs zu argumentieren. Zu wissen, wann man zu welchem greift, ist der praktische Kern der Fähigkeit.

• Compaction: zusammenfassen und weitermachen, um das Window zu befreien; steuere sie, damit sie behält, was zählt.
• Handover: die Session beenden und frisch starten mit einer sauberen Zusammenfassung, die du kontrollierst.
• Reset: einen verwirrten Kontext verwerfen und mit einem engen Prompt neu starten statt zu argumentieren.
• Subagents helfen auch: Delegiere laute Arbeit, sodass ihr Output nie in deinem Haupt-Window landet.

Retrieval: nur reinbringen, was gebraucht wird

Der gegenteilige Fehlermodus zum vollgestopften Window ist, dass die richtige Information nie ankommt. Retrieval ist, wie du genau das relevante Stück bei Bedarf hereinholst, statt alles vorzuladen. Für einen Coding Agent ist das meist konkret und unglamourös: Lass den Agenten die Codebasis durchsuchen und nur die Dateien lesen, die eine Aufgabe berührt, statt das ganze Repo einzufügen; zeig ihm die eine Doku-Seite, die er braucht; lass ihn nach der Funktion greppen statt das Verzeichnis zu laden. Das Prinzip hinter Retrieval-Augmented-Patterns ist dasselbe, ob es eine Vektordatenbank oder ein Agent ist, der grep ausführt: Hol genau das, was die Aufgabe braucht, wenn sie es braucht, damit das Window Signal hält statt einen hoffnungsvollen Haufen vielleicht-relevanten Materials.

• Hol die spezifische Datei, Doku oder den Datensatz, den die Aufgabe braucht, nicht alles potenziell Relevante.
• Lass einen Coding Agent bei Bedarf suchen und lesen, statt das ganze Repo vorzuladen.
• Retrieval hält das Window voll Signal, was das Modell auf der guten Seite der Klippe hält.
• Dieselbe Idee skaliert hoch zur Vektorsuche; das Ziel ist immer relevant-bei-Bedarf, nicht alles-auf-Verdacht.

Prompt Caching: die Kosten eines grossen Kontexts kontrollieren

Ein grosser, stabiler Kontext ist teuer, weil das Modell jeden seiner Tokens bei jeder Anfrage neu verarbeitet, und du zahlst diese Input-Tokens jedes Mal. Prompt Caching löst die Kostenseite: Du markierst ein stabiles Präfix (deinen System Prompt, Regeln, Tool-Definitionen, ein grosses Referenzdokument) als cachebar, und nachfolgende Anfragen, die mit denselben exakten Bytes beginnen, lesen es aus dem Cache statt es neu zu berechnen. Auf der Claude API ist die Ökonomie im Juni 2026 klar: Ein Cache-Write kostet etwa das 1,25-Fache eines normalen Input-Tokens für die Standard-Lebensdauer von fünf Minuten (oder das 2-Fache für die Ein-Stunden-Option), und ein Cache-Read kostet nur etwa das 0,1-Fache, ein Zehntel des Preises. Ein gecachtes Präfix amortisiert sich also innerhalb von ein paar Wiederverwendungen. Der Cache ist ein Präfix-Cache, also zählt die Reihenfolge: Setz deinen stabilen Inhalt zuerst und deinen wechselnden Inhalt zuletzt, und ein einziges geändertes Token vor dem Breakpoint erzwingt einen vollen Re-Write. Caching reduziert nicht, wie viel Kontext das Modell beachtet, nur was du zahlst, um ihn zu senden, also ergänzt es Kuratierung, statt sie zu ersetzen.

• Caching verwendet den enkodierten Zustand eines stabilen Präfix wieder, sodass es nicht jede Anfrage neu berechnet wird.
• Auf der Claude API (Juni 2026): Cache-Writes etwa 1,25x Input (5-Minuten-Standard, 2x für 1 Stunde), Cache-Reads etwa 0,1x.
• Es ist ein Präfix-Cache: Halte stabilen Inhalt zuerst und wechselnden Inhalt zuletzt, sonst erzwingst du einen Re-Write.
• Caching senkt Kosten, nicht Aufmerksamkeit; du kuratierst das Window weiterhin. Siehe das Glossar zu Prompt Caching.

Eine praktische Context-Engineering-Checkliste

Setz die Ideen zu Gewohnheiten zusammen, die du ohne Nachdenken ausführst. Nichts davon braucht spezielles Tooling; es ist Disziplin darüber, was du lädst und wann du aufräumst. Ein künftiger Begleiter ist das Token- und Context-Estimator-Tool auf diesem Campus, mit dem du Text einfügen und sehen wirst, wie viel eines Modell-Windows er füllt, bevor du ihn sendest; vorerst tragen dich die Regeln unten.

• Halte stehende Regeln in CLAUDE.md oder AGENTS.md, und halte diese Datei knapp; sie lädt jede Runde.
• Lad die Dateien, die die Aufgabe braucht, nicht das ganze Repo; lass den Agenten bei Bedarf retrieven.
• Setz die wichtigste Anweisung nahe an den Anfang und die unmittelbare Aufgabe nahe ans Ende.
• Compacte, übergib oder resette, wenn eine Session lang oder verwirrt wird; lass sie nicht ausufern.
• Cache grosse stabile Präfixe zur Kostenkontrolle, mit stabilem Inhalt zuerst.
• Delegiere laute Nebenarbeit an einen Subagent, sodass sein Output aus deinem Haupt-Window bleibt.

Häufige Fragen

Weiterlernen