Vom Prompt-Engineering zur Kontexttechnik: Schreiben, Auswählen, Komprimieren, Isolieren
Ein Kurs zur Kontexttechnik für KI-Agenten: Warum Prompt-Engineering nicht ausreicht, wie sich das Kontextfenster füllt, vier Strategien, RAG für Tools, Claude Code.
Jeder, der bereits einen Agenten entwickelt hat, hat vermutlich dieses Muster beobachtet. In den ersten Schritten funktioniert er gut: Er wählt sinnvolle Werkzeuge, argumentiert klar und konzentriert sich auf die Aufgabe. Gegen Schritt 15 oder 20 wird er nachlässig – er vergisst, was gefordert wurde, ruft Werkzeuge auf, die für die Aufgabe unpassend sind, oder liefert schwache Ergebnisse.
Der übliche erste Verdacht fällt auf das Modell. Häufig ist jedoch der eigentliche Grund das, was dem Modell gezeigt wird. Die Entscheidung darüber, was dem Modell in welcher Form und zu welchem Zeitpunkt präsentiert wird, nennt man Kontextengineering – und für Entwickler von Agenten ist dies zu einer der wertvollsten Fähigkeiten geworden.
Die folgenden Abschnitte behandeln, was Context Engineering ist und warum Agenten es benötigen, die vier Strategien, die nahezu jede Technik strukturieren, die vier Möglichkeiten, wie der Kontext fehlschlagen kann, konkrete Ratschläge für Systemanfragen und Tool-Definitionen, einen schrittweisen Arbeitsablauf, der die Strategien miteinander verbindet, sowie die Art und Weise, wie Claude Code, Manus, ChatGPT Agent und Googles Agent Development Kit damit umgehen.
Von Prompt Engineering zu Context Engineering im Kontextfenster
Prompt Engineering ist die Kunst, gute Anweisungen für ein Sprachmodell zu verfassen: Dinge klar zu formulieren, Beispiele bereitzustellen und eine Rolle zuzuweisen. Für ein Gespräch mit einer einzigen Frage und Antwort reicht das oft aus.
Agenten verändern das Bild. Ein Agent antwortet nicht sofort. Er durchsucht, ruft APIs auf, schreibt Code und führt Befehle Schritt für Schritt aus – manchmal sogar Dutzende von Schritten lang – ohne dass ein Mensch eingreift. Jeder Schritt erzeugt eine Ausgabe, und all das gelangt in den Kontext des Modells, der eine feste Größe hat.
Kontextengineering bedeutet daher die Gestaltung des gesamten Informationssystems um das Modell herum. Dazu gehören der Systemprompt, die Definitionen der Tools, die Ergebnisse früherer Toolaufrufe, die Konversationshistorie und vieles mehr – bei jedem einzelnen Schritt. Anthropics Engineering-Team beschreibt den Kontext als die Menge an Token, die bei der Stichprobenziehung aus einem Modell berücksichtigt werden, und das Kontextengineering als die Optimierung dessen, wie nützlich diese Token sind, um das gewünschte Ergebnis zu erzielen. Einfach ausgedrückt: Der Agent sollte zur richtigen Zeit die richtigen Informationen im richtigen Format erhalten.
Anthropic betrachtet dies ebenfalls als die natürliche nächste Stufe nach der Prompt-Engineering-Technik. Alles, was bereits beim Erstellen von Prompts gilt – klare Anweisungen, gute Beispiele, strukturierte Formatierung – bleibt weiterhin relevant, dazu kommt noch eine weitere Ebene: Tools, externe Daten, Nachrichtenverlauf, Speicher und dynamischer Zustand. Das Prompt-Engineering wird somit zu einem Teilaspekt.
Der Zeitpunkt ist entscheidend. Gartner prognostiziert, dass bis Ende 2026 40 Prozent der Unternehmensanwendungen task-spezifische KI-Agenten enthalten werden, gegenüber weniger als 5 Prozent im Jahr 2025. Diese Agenten ersetzen statische Prompts und feste Abrufprozesse durch ein dynamisches System, in dem jeder Tool-Aufruf, jedes abgerufene Dokument und jede Entscheidung in ein Fenster eingebettet werden, das sich mit Material füllt, nach dem der Benutzer nie direkt gefragt hat. Teams, die lernen, dieses System zu verwalten, entwickeln in der Regel zuverlässige Agenten, weil sie aufhören, das Modell für Probleme verantwortlich zu machen, die in seinen Eingaben liegen.
Das Kontextfenster als Arbeitsgedächtnis
LangChain bietet eine nützliche Analogie. Betrachten Sie das LLM als eine neue Art Betriebssystem: Das Modell ist die CPU, die denken kann, und das Kontextfenster ist die RAM, das Arbeitsspeicher, der alles enthält, was das Modell derzeit sehen kann. Genau wie ein Computer langsamer wird, wenn die RAM voll ist, verschlechtert sich das Denken eines Agenten, je voller sein Kontextfenster wird.
Dieser Effekt hat einen Namen: Kontextverfall. Chroma testete achtzehn führende Modelle, darunter GPT-4.1, Claude 4, Gemini 2.5 und Qwen3, und stellte fest, dass jedes von ihnen bei zunehmender Eingabellänge schlechter abschneidet – selbst weit unter der angegebenen Grenze. Ein Modell mit einem 200K-Token-Kontextfenster kann bereits bei 50K Token eine echte Leistungsabnahme aufweisen. Es gibt keinen plötzlichen Abfall, nur einen stetigen Anstieg. Auch die technischen Dokumente von Anthropic kommen zu demselben Schluss und betrachten die Leistungsabnahme als einen Gradienten.
Der Grund liegt darin, wie Transformer funktionieren. Jedes Token achtet auf jedes andere Token, was n² Paarbeziehungen ergibt. Wenn das Fenster größer wird, wird die Fähigkeit des Modells, all diese Beziehungen zu verfolgen, schwächer – ähnlich wie wenn man jemanden bitten würde, eine immer größer werdende Anzahl von Gegenständen im Kopf zu behalten. Irgendwann werden einige Gegenstände übersehen.
Ein weiterer gut erforschter Effekt ist das Phänomen des „Verlorengehens in der Mitte“. Eine von Liu geleitete Forschungsgruppe stellte fest, dass die Aufmerksamkeit einen U-förmigen Verlauf nimmt: Material am Anfang des Kontexts wird gut abgerufen, Material am Ende ebenso, während Material in der Mitte übersehen wird. Die Genauigkeit sinkt um mehr als dreißig Prozentpunkte, wenn der relevante Abschnitt vom Anfang in die Mitte verschiebt. Stellen Sie sich einen Agenten vor, dessen ursprüngliche Anweisungen unter fünfzigtausend Tokens an Tool-Ausgaben liegen – diese Anweisungen sind praktisch verschwunden.
Praktiker haben Faustregeln entwickelt. Nutzer von Claude Code berichten, dass die Ausgabequalität bereits bei etwa 40 bis 60 Prozent der Zeitfensterleistung nachlässt – lange bevor ein fester Grenzwert erreicht wird.
Was um Platz konkurriert
Sieben Arten von Informationen kämpfen um Platz im Kontext eines Agents:
- Der Systemprompt, der die Identität des Agents darstellt: Verhaltensregeln, Steuerfluss sowie Anleitungen für verschiedene Aufgabentypen. Bei einem Agent ist er weitaus mehr als nur eine „hilfreiche Assistenten“-Zeile und kann bestimmen, wie das Ganze funktioniert.
- Tooldefinitionen. Jedes Tool, das der Agent aufrufen könnte, benötigt ein Schema, das beschreibt, was es tut, welche Parameter es entgegennimmt und wann es verwendet werden soll.
- Toolergebnisse. Jeder Aufruf fügt seine Ausgabe hinzu. Eine heruntergeladene Webseite kann fünf bis zehntausend Tokens umfassen, und das gilt auch für gelesene Dateien.
Die vier Kernstrategien – mit Beispielen aus RAG und Claude Code
Bei einem begrenzten, schrumpfenden Zeitrahmen stellt sich die Frage, was hineinkommt, was draußen bleibt und was weggelassen werden muss. LangChains weit verbreitetes Framework einteilt jede Technik der Kontextgestaltung in vier Kategorien: Schreiben, Auswählen, Komprimieren und Isolieren. Sobald man sich damit vertraut gemacht hat, fällt fast jede Technik, auf die man stößt, in eine dieser Kategorien.
Schreiben
Agenten vergessen. Wenn ein vollständiger Kontext komprimiert wird, verschwindet Informationen – und wenn der Agent sie nicht anderswo gespeichert hat, ist sie verloren. Durch Schreiben erhält der Agent Möglichkeiten, Informationen außerhalb des Zeitrahmens zu speichern. Dies geschieht in drei gängigen Formen.
Scratchpads sind ein Notizwerkzeug, das der Agent während einer Aufgabe nutzen kann, um vorläufige Erkenntnisse, Entscheidungen sowie Dinge, die später benötigt werden, aufzuschreiben. Anthropic hat ein „Think“-Werkzeug entwickelt, das Claude einen speziellen Ort bietet, um ein Problem zu durchdenken, und im tau-bench-Benchmark verbesserte es die Leistung bei bestimmten Aufgaben um bis zu 54 %.
Rules-Dateien fungieren als dauerhafte prozedurale Erinnerung. Claude Code-Nutzer kennen CLAUDE.md. Diese Dateien werden zu Beginn jeder Sitzung als Standardanweisungen geladen und umfassen die Architektur des Projekts, gängige Vorgehensweisen, Anleitungen zum Ausführen von Tests sowie Hinweise darauf, worauf geachtet werden muss, sodass die Grundlagen niemals vergessen werden.
Gedächtnisextraktion ermöglicht es dem Agenten, Fakten, Präferenzen sowie gelernte Muster in einem dateibasierten System zu speichern und diese in späteren Sitzungen – völlig außerhalb des aktiven Fensters – abzurufen.
Selektieren
Notizen sind nur nützlich, wenn die richtigen zu dem richtigen Zeitpunkt zur Verfügung stehen. Die Auswahl bedeutet, dem Agenten das zu geben, was er für diesen Schritt benötigt, und nicht alles, was er möglicherweise verwenden könnte. Ein Agent mit Dutzenden von Werkzeugen, einer umfangreichen Wissensbasis sowie mehreren Historie-Sitzungen kann nicht alles auf einmal verarbeiten, daher muss etwas entscheiden, was relevant ist – und die eigentliche Frage ist, was genau diese Entscheidung trifft.
In klassischem RAG entscheidet das System. Eine Frage wird eingegeben, Dokumente werden abgerufen und in den Prompt eingefügt, wobei das Modell keine Mitsprache hat. Bei agilerem RAG wählt der Agent selbst aus, was gesucht werden soll, welche Werkzeuge verwendet werden, wie Anfragen verfeinert werden und wann genug Informationen vorliegen. Die Informationsbeschaffung wird zu einem iterativen Prozess, was sinnvoll ist, da die Relevanz bei jedem Schritt einer langen Aufgabe sich ändert und nur der Agent weiß, was er als Nächstes benötigt.
Sowohl LangChain als auch Pinecone unterscheiden drei Arten von Speicher, auf die zugegriffen werden kann. Episodisches Gedächtnis umfasst im Wesentlichen Beispiele für ähnliche Situationen, wie sie zuvor bewältigt wurden. Semantisches Gedächtnis ist eine Sammlung von Fakten, die das Agent gelernt hat oder ihm mitgeteilt wurden. Prozedurales Gedächtnis sind die dauerhaften Verhaltensanweisungen, wie beispielsweise die oben genannten Regeldateien. Ein gut konstruiertes Agent zieht je nach Schritt von allen drei Arten des Speichers Nutzen.
Tools verursachen die größten Probleme bei der Auswahl. Mit etwas mehr als vierzig Tools können bereits vor Beginn der Arbeit rund zehntausend Token an Definitionen im Kontext vorhanden sein. Wie der untenstehende Abschnitt zu Fehlern zeigt, führt zu viele Tools nicht nur zum Verbrauch von Speicher, sondern verwirrt das Modell auch aktiv.
Die Lösung besteht darin, RAG direkt auf die Toolbeschreibungen anzuwenden und eine semantische Suche durchzuführen, die nur die wenigen Tools ausweist, die in dem aktuellen Schritt verwendet werden können. Ein Paper mit dem Titel RAG-MCP hat dies getestet und festgestellt, dass die Genauigkeit bei der Toolauswahl von etwa 14 % auf 43 % stieg – mehr als das Dreifache – während die Anzahl der Prompt-Tokens um etwa die Hälfte abnahm.
Anthropics allgemeiner Rat ist ein Hybridansatz: Man lädt im Vorfeld eine kleine Menge an essentiellen Materialien zur Geschwindigkeitssteigerung hoch, wie beispielsweise die CLAUDE.md-Datei, und lässt den Agenten den Rest erst rechtzeitig abrufen. In der Praxis bedeutet das, dass der Agent leichte Referenzen wie Dateipfade, Abfragen und Links speichert und den umfangreichen Inhalt erst dann öffnet, wenn ein Schritt dies erfordert. Das Vorladen der Grundlagen und das Abrufen des Rests nach Bedarf hält die Systemlast gering, ohne den Agenten im Unklaren zu lassen.
Komprimieren
Auch bei einer guten Auswahl füllt sich das Fenster weiter. Stellen Sie sich einen Agenten vor, der zwanzig Tool-Aufrufe durchführt. Er trägt achtzigtausend Tokens an Ausgaben, Historie und Schlussfolgerungsspuren mit sich, von denen er den größten Teil bereits verarbeitet hat. Dieses alte Material nimmt weiterhin Platz ein, lenkt die Aufmerksamkeit ab und erhöht Kosten sowie Latenz. Es handelt sich dabei wieder um das Problem des Kontextverfalls, das durch Kompression gelöst werden kann, indem Tokens entfernt werden, während die wichtigen Informationen erhalten bleiben. Dies kann an drei Stellen erfolgen.
Vor dem Eintreten der Informationen in den Kontext. Durch Chunking werden große Dokumente in kleinere, kohärente Teile aufgeteilt, und durch Neubewertung gelangen nur die besten Teile ins Fenster. Die Ausgaben der Tools können außerdem direkt vor dem Hinzufügen zum Hauptkontext zusammengefasst werden.
Während der Agent arbeitet. Die gängige Methode besteht darin, das Gespräch zusammenzufassen: Eine laufende Zusammenfassung, die nach jedem Austausch aktualisiert wird, bewahrt eine kompakte Aufzeichnung von allem, was bisher gesagt wurde. Eine beliebte Mischlösung speichert die letzten zehn Nachrichten wortwörtlich, da genaue Details möglicherweise noch benötigt werden, und fasst alles Ältere zusammen. Eine weitere Option ist das einfache Kürzen mit fest programmierten Regeln, bei denen alte Nachrichten ab einem bestimmten Größenlimit entfernt werden. Claude Code verfügt über eine automatische Komprimierung, die den gesamten Verlauf zusammenfasst, sobald das Fenster zu 95 Prozent gefüllt ist. Das dient als Sicherheitsnetz. Idealerweise findet die Kompression im Voraus statt und nicht erst bei einem Notfall.
Nachdem der Agent etwas verwendet hat. Der einfachste Weg ist das Löschen der Ergebnisse der Tools. Wenn ein Tool fünfzehn Schritte rückwärts ausgeführt wurde und der Agent bereits auf das Ergebnis reagiert hat, kann der Rohtext entfernt werden. Eine vor langer Zeit heruntergeladene vollständige Webseite kann durch eine einzeilige Zusammenfassung ersetzt oder ganz entfernt werden.
Isolieren
Die Isolierung ist es, die mehrere Agentensysteme nutzbar macht. Angenommen, ein Agent kümmert sich in einem einzigen langen Gespräch um Forschung, Planung, Programmierung, Testing und Debugging. Sein Kontext füllt sich dabei, doch das größere Problem ist die Kontamination. Dateisuchen aus der Forschungsphase liegen weiterhin vor, wenn mit der Implementierung begonnen wird, und dieses alte Material stellt nun Störungen dar, die das Modell ablenken, gerade wenn es sauberen Code schreiben muss.
Die Lösung besteht darin, verschiedenen Arbeitsteilen separate Kontextfenster zuzuweisen.
Der offensichtliche Ansatz sind Unteragenten. Ein Elagent überträgt eine spezifische Aufgabe – beispielsweise die Suche nach allen Dateien im Zusammenhang mit der Authentifizierung – an einen Unteragenten, der in einem eigenen Fenster arbeitet. Nach Abschluss liefert dieser nur eine zusammengefasste Zusammenfassung zurück, während die aufwendige Suche innerhalb des Unteragenten bleibt und den Elagenten nicht belastet.
Eine weitere Variante ist die Isolation des Zustandschemas, wie sie in LangGraph umgesetzt ist. Der Zustand des Agenten ist so gestaltet, dass verschiedene Felder unterschiedliche Arten von Kontexten enthalten, wodurch das Modell nur die für den aktuellen Schritt relevanten Felder sieht. Ergebnisse von Tools können in einem hintergründigen Feld gespeichert werden, das das Modell erst dann sieht, wenn etwas sie absichtlich nach vorne bringt. Dadurch wird eine feine Steuerung ohne das Starten zusätzlicher Agenten ermöglicht.
Kurz gesagt, die Strategien lauten schreiben, auswählen, komprimieren und isolieren – alles Weitere wendet eine oder mehrere davon an.
Wie Agenten versagen
Fehlermuster zeigen, was man vermeiden sollte. Mitte 2025 schrieb Drew Breunig eine einflussreiche zweiteilige Serie, in der er vier verschiedene Arten aufzeigte, wie Agenten bei zunehmendem Kontext versagen können.
Kontextvergiftung. Eine Halluzination oder ein Fehler gelangt in den Kontext und wird anschließend immer wieder herangezogen. Vielleicht hat ein Tool fehlerhafte Daten zurückgegeben oder der Agent vor fünf Schritten zu einer falschen Schlussfolgerung gelangt. Der Fehler bleibt nun im Kontext bestehen, und der Agent baut darauf weiter auf. Da Agenten ihre eigenen Ausgaben wiederholen, verschärft sich jeder fehlerhafte Schritt. Die Lösung besteht darin, überflüssige oder widersprüchliche Informationen aktiv zu entfernen, sobald neue Details vorliegen, die Ausgaben von Tools – insbesondere solcher externer Quellen – vor deren Aufnahme in den Kontext zu überprüfen und nachdem der Agent von einem Fehler wieder genesen ist, die fehlgeschlagenen Versuche zu komprimieren, sodass zehn Sitzungen des Sackgassendekodierens nicht weiter bestehen bleiben, wenn nur die Lösung zählt. Wenn diese aufgegebenen Versuche unverändert bleiben, locken sie das Modell weiterhin zu Ansätzen, die bereits gescheitert sind.
Kontextstörung. Bei einem sehr langen Kontext neigt das Modell dazu, sich zu stark auf die jüngste Vergangenheit zu stützen und zu wenig auf das, was es während des Trainings gelernt hat. Es hört auf, etwas Neues zu synthetisieren, und wiederholt Muster, die es kürzlich gesehen hat, wodurch es vergangene Handlungen erneut durchgeht, anstatt einen neuen Plan zu entwickeln. Die Lösung ist derselbe allgemeine Rat: Ziehen Sie konsequent Zusammenfassungen und entfernen Sie unnötige Elemente – auch dann, wenn der Kontextumfang sehr groß ist.
Kontextverwirrung. Überflüssiger Inhalt wird vom Modell erfasst und senkt die Qualität der Antwort. Ein klassisches Beispiel ist die Verwechslung von Werkzeugen. In einer Vergleichsstudie wurde ein quantisiertes Llama 3.1 8B-Modell am GeoEngine-Benchmark getestet. Bei allen vierundvierzig verfügbaren Werkzeugen versagte es, obwohl der Kontext deutlich innerhalb seiner Grenzen lag. Bei nur neunzehn Werkzeugen funktionierte es hingegen. Die Werkzeuge passten zwar in den Rahmen, waren aber zu zahlreich, sodass das Modell nicht klar reasoningen konnte. Die Lösung besteht in einer dynamischen Werkzeugverwaltung: Man reduziert die verfügbaren Werkzeuge auf jene, die zur aktuellen Phase des Agents passen, wobei ein RAG-MCP-ähnlicher Suchmechanismus für jeden Schritt die relevanten Werkzeuge auswählt.
Konflikt im Kontext. Neue während einer Aufgabe gesammelte Informationen stehen im Widerspruch zu bereits vorhandenen Informationen im Kontext. Die Systemanweisung kann eine Sache besagen, während ein heruntergeladenes Dokument etwas anderes angibt. Der Agent kann diese Informationen nicht miteinander in Einklang bringen und verhält sich inkonsistent – mal folgt er einer Quelle, mal einer anderen, und manchmal tut er etwas, das keiner der Quellen entspricht. Die Lösung besteht in einer klaren Hierarchie der Autoritäten: Systemanweisungen haben Vorrang vor heruntergeladenen Fakten, diese wiederum vor dem Gesprächsverlauf. Neue Informationen sollten vor ihrer Einbeziehung mit dem bereits vorhandenen Inhalt abgeglichen werden, und es sollten strukturierte Abschnitte wie XML-Tags oder klare Überschriften verwendet werden, damit das Modell erkennen kann, woher jede Information stammt und inwieweit man ihr vertrauen kann.
Die gute Nachricht ist, dass die Benennung eines Fehlers in der Regel auf eine Strategie hinweist. Vergiftung wird durch Kompression und Reduzierung bewältigt, Ablenkung durch Kompression, Verwirrung durch Auswahl und Konflikte durch strukturiertes Schreiben sowie Auswahl. Im Grunde kommt es immer auf Schreiben, Auswahl, Komprimieren und Isolieren an.
Systemanfragen für Agenten
Das Anfordern von Antworten bei einem Agenten unterscheidet sich stark vom Anfordern bei einem Chatbot. Eine Chatbot-Anfrage legt meist nur einen Ton fest – freundlich und kurz. Eine Agenten-Anfrage definiert hingegen die Architektur. Sie beschreibt den Ablauf der Steuerung, also wie mit verschiedenen Aufgaben umgegangen wird, welche Tools zu welchen Situationen passen, was nach einem Fehler zu tun ist und welche Sicherheitsgrenzen gelten. Sie liest sich eher wie eine Stellenbeschreibung für einen autonomen Mitarbeiter.
Anthropic spricht über das Schreiben auf der richtigen „Höhe“ – es gibt dabei eine Art Goldilocks-Zone. Zu starre Vorgaben sind anfällig für Fehler. Stellen Sie sich eine Regel vor, die vorschreibt, das Tool X zu verwenden, sobald der Nutzer auf Rechnungsstellung oder Rückerstattung anspielt und der Betrag über hundert Dollar liegt. Solche Regeln versagen bei jedem bisher unvorhergesehenen Fall. Zu vage Formulierungen sind genauso problematisch. Der Satz „Seien hilfreich und verwenden die geeigneten Tools“ gibt dem Agenten keine konkreten Anhaltspunkte, da er nicht weiß, welche Tools für welche Aufgaben geeignet sind, und ohne klare Signale keine Entscheidungen treffen kann. Der ideale Ausgleich liegt darin, genug Spezifität zu haben, um autonomes Verhalten zu steuern, aber gleichzeitig genug Freiraum zu lassen, damit das Modell in neuen Situationen eigenständig urteilen kann. Man sollte starke Heuristiken statt starrer Regeln verwenden.
Einige praktische Gewohnheiten helfen:
- Geben Sie der Anfrage eine Struktur mit XML-Taggen oder Markdown-Überschriften, die Hintergrundinformationen, Anweisungen und Anleitungen zu den Tools voneinander trennen.
- Beginnen Sie mit dem Minimum und arbeiten Sie an den Fehlern weiter. Führen Sie den Agenten mit echten Aufgaben aus, um herauszufinden, wo er versagt, und fügen Sie Anweisungen hinzu, die speziell auf diese Fehler zugeschnitten sind, anstatt zu versuchen, alle möglichen Randfälle im Voraus vorherzusagen.
- Minimal bedeutet nicht kurz. Eine Anweisung für einen komplexen Arbeitsablauf kann aus Tausenden von Tokens bestehen – das ist in Ordnung, solange jedes Token seinen Platz verdient.
- Verwenden Sie Few-Shot-Beispiele. Die Darstellung vielfältiger, typischer Beispiele für die richtige Werkzeugwahl, logisches Denken und ordnungsgemäße mehrstufige Ausführung ist effektiver als die Beschreibung jeder Regel mit Worten.
Werkzeugdefinitionen
Jedes aufrufbare Werkzeug benötigt ein Schema, das seinen Zweck, seine Parameter sowie den Einsatzzeitpunkt beschreibt. Eine gute Definition ist selbstständig, fehlerverzeihend und klar in ihren Anweisungen – der Preis dafür ist Speicherplatz im Kontext.
In der Produktion werden Tools zunehmend über MCP, das Model Context Protocol, miteinander verbunden – ein standardisierter Weg dafür, dass Agenten auf externe Tools und Daten zugreifen können. Ein MCP-Server für GitHub, ein anderer für die Datenbank, ein dritter für das Dateisystem – alle stellen Tools über eine einheitliche Schnittstelle bereit. Das Problem ist, dass das Anschließen von Tools so einfach wird, dass man damit übertrieben vorgeht. Bei vier oder fünf verbundenen Servern können die Definitionen bereits vor dem ersten Schritt Tausende von Tokens verbrauchen.
Die übliche Empfehlung lautet, eine minimale, funktionsfähige Auswahl zu verwenden. Wenn ein Agent tatsächlich viele Tools benötigt, eignen sich zwei Ansätze zur Skalierung.
Die erste Quelle stammt von Manus, einer Plattform für Produktionsagenten. Sie raten davon ab, mitten in einem Gespräch Werkzeuge hinzuzufügen oder zu entfernen – aus einem Grund, den viele Entwickler nicht kennen: dem KV-Cache. Wenn Tokens an ein LLM gesendet werden, berechnet das Modell für jeden von ihnen Schlüssel-Wert-Repräsentationen, was aufwändig ist; deshalb speichern die Anbieter diese in einem Cache. Wenn der Anfang des Kontexts (das Präfix) bei verschiedenen Aufrufen identisch ist, verwendet der Anbieter die bereits gespeicherten Daten und verarbeitet nur die neuen Tokens am Ende – was schneller und günstiger ist.
Wenn man den Anfang des Kontexts zwischen den Aufrufen umordnet oder bearbeitet, wird der Cache ungültig, sodass alles erneut berechnet werden muss. Bei Claude Sonnet kosten gespeicherte Eingabetokens 30 Cent pro Million, während ungecachete Tokens 3 Dollar pro Million kosten – das ist ein Zehnfachunterschied. Ein Agent, der pro Aufgabe dreißig oder vierzig Aufrufe durchführt, spürt das schnell.
Deshalb bevorzugt Manus das Maskieren von Werkzeugen gegenüber deren Entfernung. Jede Definition bleibt im gespeicherten Präfix erhalten, doch bestimmte Werkzeuge werden als für die aktuelle Phase nicht verfügbar markiert. Die Definitionen bleiben zur Stabilität des Caches bestehen, während der Agent weiß, sie nicht verwenden zu sollen, und konsistente Namenspräfixe helfen ihm dabei, über Kategorien von Werkzeugen nachzudenken.
Der zweite Ansatz ist die zuvor erläuterte, auf RAG basierende Auswahl: Es werden nur die Werkzeuge abgerufen, die für den aktuellen Schritt relevant sind, wodurch laut der RAG-MCP-Studie die Genauigkeit um mehr als das Dreifache gesteigert und gleichzeitig die Tokenverwendung halbiert werden konnte. Die beiden Methoden ergänzen sich gegenseitig. Das Maskieren eignet sich für eine mittlere Anzahl an Werkzeugen, während die Abrufmethode für eine sehr große Anzahl geeignet ist.
Unter beidem liegt ein grundlegendes Prinzip: Stabile Inhalte kommen an die Spitze des Kontexts – der Systemanweisung, die Tool-Definitionen sowie alles, was zwischen den Schritten nicht ändert sich. Dynamische Inhalte (Historie, aktueller Schritt, Zustand des Agenten) befinden sich unten.
Ein schrittweiser Arbeitsablauf, der alles kombiniert
Diese Prinzipien gelten sowohl für fertige Programmierhilfen als auch für selbst entwickelte Agenten. Der einzige Unterschied besteht darin, ob man den Arbeitsablauf selbst strukturiert oder einen Agenten dafür baut.
Dex Horthy, CEO von HumanLayer, hielt auf dem AI Engineer Code Summit einen Vortrag, in dem er eine Methode beschrieb, die all das übersichtlich veranschaulicht. Sein Team soll sie genutzt haben, um in einer einzigen siebenstündigen Sitzung etwa dreißigfünftausend Zeilen Code in eine große Rust-Codebasis einzubringen. Er nennt diese Methode „Frequent Intentional Compaction“. Die Arbeit ist absichtlich in Phasen unterteilt. Jede Phase erzeugt ein kompaktes Ergebnis, wie beispielsweise eine strukturierte Markdown-Zusammenfassung, und jede neue Phase beginnt in einem neuen Fenster, das nur dieses Ergebnis enthält. Dadurch wird absichtlich darauf geachtet, dass der Platzbedarf bei etwa 40 bis 60 Prozent des Fensters bleibt.
Erste Phase: Forschung. Bevor Code geschrieben wird, durchforstet der Agent die Codebasis: Er liest Dateien, verfolgt Datenflüsse und kartiert die für die Aufgabe relevante Architektur. Unteragenten übernehmen die eigentliche Suche und Analyse, sodass alle grep-Ergebnisse sowie Datein Inhalte in ihren eigenen Fenstern bleiben und niemals das Fenster des übergeordneten Agenten betreffen. Das ist Isolation. Das Ergebnis dieser Phase ist eine Forschungsdatei – ein kompaktes Markdown-Dokument mit Dateipfaden, Funktionssignaturen, vorhandenen Mustern sowie potenziellen Problemen. Damit handelt es sich um Schreiben, da die Erkenntnisse außerhalb des Fensters gespeichert werden. Anschließend wird der Kontext zurückgesetzt. Die ursprüngliche Forschung könnte 60 bis 80 Prozent des Fensters in Anspruch genommen haben, während das Ergebnis diesen Wert auf vielleicht 15 bis 20 Prozent verringert. Das ist Kompression.
Zweite Phase: Planung. Es öffnet sich ein völlig neues Fenster, das nur die Forschungsdatei sowie die Problembeschreibung enthält, und der Agent nutzt diese saubere Ausgangslage, um einen detaillierten Umsetzungsplan zu entwerfen. Dies ist auch der beste Ort für eine menschliche Überprüfung. Ein hier entdeckter Logikfehler ist kostengünstig zu beheben, weshalb jeder, der seinen eigenen Agenten entwickelt, an dieser Stelle einen Kontrollpunkt mit menschlicher Beteiligung einbauen sollte.
Dritte Phase: Umsetzung. Ein weiteres neues Fenster zeigt nur den Plan an, und der Agent arbeitet sich Schritt für Schritt daran vor. Bei Aufgaben, die mehrere Komprimierungszyklen erfordern, protokolliert eine Datei mit dem Namen progress.md, was bereits erledigt wurde und was noch aussteht – was erneut eine Schreiboperation bedeutet.
Eine Variante davon kommt in den meisten Produktionsystemen vor.
Wie echte Produkte mit Kontext umgehen
Claude Code. Der Kommandozeilen-Programmieragent von Anthropic gehört zu den am besten dokumentierten Beispielen. Er verwendet eine hybride Suchmethode: CLAUDE.md-Dateien werden zu Beginn jeder Sitzung geladen, um einen grundlegenden Kontext bereitzustellen, während Werkzeuge wie glob und grep eine just-in-time-Erkundung der Codebasis ermöglichen. Er indiziert nicht alles im Voraus, sondern erkundet den Code nach Bedarf. Die automatische Komprimierung tritt bei 95 Prozent Auslastung ein und bewahrt architektonische Entscheidungen sowie die fünf kürzlichsten zugriffenen Dateien auf. Er kann Sub-Agenten mit sauberen Arbeitsumgebungen für komplexe Unteraufgaben erstellen, und ein Speicherwerkzeug bewahrt Informationen über Sitzungen hinweg. Die Leitphilosophie besteht darin, das einfachste funktionierende Verfahren anzuwenden, dem Modell zu vertrauen, dass es weiß, was es benötigt, und es mit den nötigen Werkzeugen auszustatten, um es zu finden.
Manus. Dies ist der anspruchsvollere Ansatz, der viel Infrastruktur erfordert, aber sinnvoll ist, wenn es um einen Allzweck-Agenten geht, der Hunderttausende von Nutzern bedient und bei dem Skaleneffizienz entscheidend ist. Sein charakteristisches Merkmal ist die cachebewusste Sortierung, bei der das Präfix über mehrere Schritte hinweg stabil bleibt, um eine maximale Wiederverwendung des Caches zu gewährleisten, sowie das Maskieren von Werkzeugen anstelle ihres Entfernens. Ein Kompressionspipeline für Beobachtungen verarbeitet jede Werkzeugausgabe, bevor sie den Kontext des Agents erreicht. Eine persistente To-Do-Liste überwacht den Zustand, und das Dateisystem dient als Puffer für aus dem Kontext entfernte Daten.
ChatGPT Agent. Der Agent von OpenAI, der aus Operator hervorgegangen ist, weist in seiner Architektur Unterschiede zu beiden auf. Angetrieben durch ein Computer-Using Agent-Modell verfolgt er einen auf die grafische Benutzeroberfläche ausgerichteten Ansatz. Anstelle von textbasierten Toolaufrufen wird ein visueller Browser genutzt, wobei Screenshots als Schnappschüsse in den Kontext aufgenommen werden, über die das Modell zusammen mit seiner Historie früherer Screenshots und Aktionen nachdenkt. Dadurch ändert sich auch die Herausforderung. Visuelle Token sind aufwändig in der Verarbeitung, weshalb der Agent sorgfältig entscheiden muss, wie viele Screenshots er speichert. OpenAI verwendet Verstärkungslernen, um gute Strategien für den Toolgebrauch zu finden, indem es auf Tausenden von virtuellen Maschinen trainiert, anstatt fest vorzuschreiben, wann welches Tool verwendet werden soll. Deep Research und Operator teilen den Zustand, was reibungslose Übergänge zwischen Surfen, Textanalyse und Codeausführung ermöglicht. Im Vergleich zum auf Code ausgerichteten, textbasierten Claude Code mit großem Fenster ist dieses Tool visuell und vielseitig einsetzbar. Beide erfordern eine Kontextgestaltung, wobei unterschiedliche Probleme und Lösungsansätze vorliegen.
Google’s Agent Development Kit. ADK verfolgt den prinzipientreuesten architektonischen Ansatz und legt drei Designprinzipien für den Agentenkontext fest. Speicherung und Darstellung sollten getrennt werden, da ein dauerhafter Zustand nicht identisch ist mit dem, was in einer bestimmten API-Aufrufung angezeigt wird. Es sollten explizite Transformationen verwendet werden, d.h. benannte, geordnete Verarbeitungsschritte, die den Kontext in testbaren, kombinierbaren Schritten umformen, anstatt ad hoc Zeichenketten zusammenzufügen. Der Kontext sollte standardmäßig eingeschränkt werden, sodass jeder Modellaufruf nur das Minimum an Informationen erhält und nichts im Kontext landet, es sei denn, es wird ausdrücklich hinzugefügt. Dadurch wird die Kontextzusammenstellung als Pipeline mit klaren Phasen betrachtet und nicht als Prompt, den man ständig erweitert.
Die gemeinsame Kontextpipeline
Wenn man sich diese Plattformen ansieht, zeigt sich bei jedem Schritt des Agents immer derselbe Ablauf:
- Kandidaten sammeln: Benutzereingaben, Historie, Ergebnisse von Tools, abgerufte Dokumente sowie der Zustand des Agents.
- Innerhalb des verbleibenden Token-Budgets das für diesen Schritt Relevanteste auswählen.
- Durch Zusammenfassen, Kürzen oder Umstrukturieren der Auswahl komprimieren, um den Rahmen einzuhalten.
- Alles so anordnen, dass es für die Wiederverwendung im KV-Cache geeignet ist – mit stabilem Inhalt zuerst und dynamischem Inhalt zuletzt.
- Den endgültigen Kontext zusammenstellen und den Aufruf durchführen.
Das Feld entwickelt sich rasant und es gibt noch viel zu lernen, daher ist der beste Weg zur Verbesserung das Experimentieren: Etwas bauen, beobachten, wo es versagt, und anpassen.
Verwandte Literatur
- Context Engineering für LLM-Anwendungen: Strukturierte Ausgaben, Tools und Grenzen von Agenten: Wie man gezielt Eingaben für Modelle erstellt: Kontextauswahl, Prompt-Vorlagen, JSON-Schemata, eingeschränkte Dekodierung, Toolaufrufe, Agentenschleifen und begrenzte Autonomie.
- Strategien zum Chunking für Produktionsumgebungen von RAG: Festes Format, semantisches Chunking und Eltern-Kind-Struktur: Eine praktische Übersicht zum Chunking in RAG-Systemen – von festem Format und rekursivem Aufteilen über Eltern-Kind-Strukturen, Propositionen, spätes Chunking, RAPTOR, Tabellen, Code bis hin zu Benchmarking.