Context Engineering: Was Es Ist und Wie Ich Es Nutze, um Bessere KI-Agenten zu Bauen

Inhaltsverzeichnis

Veroeffentlicht im Juli 2026.

TL;DR: Prompt Engineering betrifft die Wortwahl; Context Engineering betrifft die Informationsarchitektur. Du hast ein endliches Kontextfenster und jedes Token ist ein Kompromiss. Ich strukturiere den Agenten-Kontext in vier Schichten: System-Prompt, Konversationsverlauf, abgerufene Inhalte und Tool-Ausgaben. Das Fenster als Budget zu behandeln, nicht als leere Leinwand, hat die Zuverlaessigkeit mehr verbessert als ein Modellwechsel.

[Betreiber-Hinweis] Ich betreibe mehr als 30 Agenten in der Produktion. Die Verbesserung, die im letzten Jahr den groessten Unterschied gemacht hat, ist weder ein besseres Modell noch ein ausgefeilteres Framework — es ist bewusster zu sein, was in das Kontextfenster einfliesst und was draussen bleibt. Context Engineering ist jetzt die Kernkompetenz, nach der ich bei der Bewertung von Agenten-Arbeit suche.

Die meisten Menschen sprechen noch immer vom “Prompt Engineering” als der entscheidenden Faehigkeit fuer die Arbeit mit KI. Prompt Engineering ist real und wichtig. Aber es ist eine Teilmenge einer groesseren Disziplin — und es als die gesamte Arbeit zu betrachten, erklaert, warum viele Agenten, die in Demos gut aussehen, in der Produktion scheitern.

Warum “Prompt Engineering” zum falschen Rahmen wurde

“Prompt Engineering” impliziert, dass der zentrale Hebel der Text ist, den du in den System-Prompt oder die Benutzernachricht schreibst. Verbringe genuegend Zeit damit, die richtigen Anweisungen, die richtige Formulierung, das richtige Format zu entwickeln, und das Modell wird tun, was du brauchst.

Das stimmt bis zu einem gewissen Punkt. Ein gut geschriebener System-Prompt ist notwendig. Aber das Verhalten des Modells wird durch alles bestimmt, was sich im Kontextfenster befindet — nicht nur durch deinen System-Prompt. Es wird beeinflusst durch:

• Den Konversationsverlauf (was in vorherigen Zuegen passiert ist)
• Die Dokumente oder Daten, die du abgerufen und injiziert hast
• Die Tool-Aufruf-Ergebnisse, die das Modell bisher gesehen hat
• Die Token-Anzahl und Position jedes Informationsstuecks

Wenn du nur an die Prompt-Formulierung denkst und den Rest dessen ignorierst, was das Kontextfenster fuellt, optimierst du einen Input, waehrend du die anderen ungesteuert laesst. Deshalb ist “Context Engineering” der praezisere Rahmen fuer ernsthaftes Agenten-Werk.

Was Context Engineering wirklich ist

Context Engineering ist die Disziplin zu entscheiden, welche Informationen in das Kontextfenster des Modells eingehen, in welcher Reihenfolge, zu welchem Zeitpunkt im Gespraech.

Das Kontextfenster ist das Arbeitsgedaechtnis des Modells. Es ist endlich. Jedes Token, das du hineinsteckst, verdraengt etwas anderes — oder erhoht die Kosten. Und anders als menschliches Arbeitsgedaechtnis hat das Modell keine Moeglichkeit, etwas ausserhalb des Fensters “nachzuschlagen” (es sei denn, du gibst ihm Werkzeuge dafuer). Was es sieht, ist alles, was es hat.

Context Engineering ist die Praxis, dieses Fenster als Ressource zu behandeln, die bewusst gesteuert wird:

• Was muss das Modell wissen, um diesen Schritt abzuschliessen?
• Was musste es in einem vorherigen Schritt wissen, braucht es aber nicht mehr?
• Was ist stabil ueber Laeufe hinweg vs. was ist dynamisch pro Anfrage?
• Wo im Fenster sollte jedes Informationsstueck erscheinen?

Das sind keine Fragen zur Prompt-Formulierung. Das sind Fragen der Informationsarchitektur. Und die Antworten treiben die Agenten-Zuverlaessigkeit genauso an wie die Modellauswahl.

Die vier Schichten, die ich entwerfe

Jeder Agent, den ich baue, hat vier unterschiedliche Kontextschichten. Ich denke an jede von ihnen separat.

Schicht 1: Der System-Prompt

Das ist die stabile, zugrunabhaengige Grundlage. Sie definiert, wer der Agent ist, was er tun kann, was er nicht tun kann und wie er Randfaelle behandeln soll.

Der Fehler, den die meisten Menschen hier machen, ist, den System-Prompt einmal zu schreiben und ihn als fertig zu betrachten. In der Praxis muss der System-Prompt explizit drei Fragen beantworten:

1. Wofuer ist dieser Agent? (Das Modell braucht einen engen Anwendungsbereich, keine vage Mission.)
2. Was soll er tun, wenn die Eingabe mehrdeutig oder unvollstaendig ist?
3. Was soll er niemals tun? (Negative Einschraenkungen sind wichtig.)

Halte den System-Prompt minimal. Jeder unnoetige Satz ist Overhead, der mit dem dynamischen Inhalt konkurriert, wo das eigentliche Denken stattfindet.

Ein praktischer Tipp: Wenn du Claude mit der API verwendest, nutze cache_control fuer deinen System-Prompt. Ein grosser, stabiler System-Prompt im Cache kostet etwa 10% von dem, was ein nicht gecacheter kosten wuerde.

Schicht 2: Konversationsverlauf

In einem Multi-Turn-Agenten ist der Konversationsverlauf dynamisch und waechst mit jedem Zug. Ohne Verwaltung wird er zum groessten Treiber von Kontext-Inflation.

Das Problem: Fruehe Zuege enthalten Informationen, die das Modell nicht mehr benoetigt. Alles zu behalten, verschwendet Token und kann das Modell verwirren, indem es ihm veralteten Kontext zum Denken gibt.

Was ich tue:

• Alte Zuege kuerzen oder zusammenfassen, wenn der Verlauf einen Schwellenwert ueberschreitet.
• Nur noch relevante Tool-Aufruf-Ergebnisse behalten.
• Den Verlauf in einem langfristigen Agenten nie unbegrenzt wachsen lassen.

Schicht 3: Abgerufene Inhalte

Das ist die Schicht, die mittelmassige Agenten von guten trennt. Die meisten Agenten muessen zur Laufzeit externe Daten abrufen.

Zwei Prinzipien, die ich anwende:

Nur das Relevante fuer den aktuellen Schritt abrufen. Injiziere kein 50-seitiges Dokument, wenn der aktuelle Schritt nur einen Abschnitt davon benoetigt.

Position ist wichtig. Informationen am Anfang und am Ende des Kontexts werden staerker gewichtet als Informationen in der Mitte. Wenn es einen abgerufenen Abschnitt gibt, den das Modell unbedingt verwenden muss, begrabe ihn nicht in der Mitte einer langen Injektion.

Schicht 4: Tool-Ausgaben

In einer agentischen Schleife ruft das Modell Tools auf und erhaelt Ergebnisse. Diese Ergebnisse haeufen sich an. Und anders als der Konversationsverlauf denken die Menschen selten daran, sie zu verwalten.

Die Loesung ist dieselbe: Nachdem ein Tool-Ergebnis seinen Zweck erfuellt hat, musst du es nicht im Fenster behalten. In einem Multi-Schritt-Agenten fuehre ich eine strukturierte Zusammenfassung von “was wir bisher festgestellt haben” weiter, anstatt die rohe Ausgabe jedes vorherigen Schritts.

Das Kontext-Budget: Was einzuschliessen und was zu kuerzen ist

Ich verwende ein einfaches mentales Modell: Das Kontextfenster ist ein Budget und jedes Token ist eine Ausgabe. Vor jedem Agenten-Zug frage ich:

• Was muss das Modell jetzt wissen, um diesen Schritt zu machen?
• Was kann ich weglassen oder zusammenfassen, ohne etwas Wichtiges zu verlieren?
• Was ist ueber Schichten hinweg dupliziert?

Das Ziel ist, das Fenster mit den hochwertigsten Informationen pro Schritt zu fuellen, nicht umfassend zu sein.

Drei Context Engineering-Fehler, die ich in der Produktion gemacht habe

1. Fliegende Zeitstempel im stabilen Praefix. Ich hatte Aktuelles Datum: {{datum}} oben in meinem System-Prompt. Diese Zeichenkette aendert sich taeglich, was meinen Prompt-Cache lautlos alle 24 Stunden ungueltig machte. Verschiebe volatile Informationen — Zeitstempel, Benutzer-IDs — ans Ende des Kontexts, nach dem stabilen Praefix.

2. Tool-Ausgaben als nur-anhaegendes Behandeln. Ich fuehrte agentische Schleifen durch, bei denen jedes Tool-Aufruf-Ergebnis im Kontext verblieb. Im Zug 8 dachte das Modell aus einem Kontext heraus, der zu 80% aus veralteten Tool-Ausgaben bestand.

3. Die Evaluierung bei Kontextaenderungen ueberspringen. Kontextaenderungen sind Modellaenderungen. Ich fuehre jetzt dasselbe Evaluierungsgeschirr bei Kontextaenderungen aus wie bei Prompt-Aenderungen.

Mein Context Engineering-Workflow in der Praxis

Bevor ich eine einzige Zeile Agenten-Code schreibe, skizziere ich die Kontextschichten:

System-Prompt:        ~500 Token, stabil, gecacht
Verlaufs-Budget:      ~2000 Token max, nach jedem Schritt zusammengefasst
Abgerufener Kontext:  ~1000-3000 Token pro Schritt, nur relevante Abschnitte
Ausgaben-Budget:      nur aktueller Schritt, zusammengefasst weitergefuehrt

Die Modellauswahl-Frage kommt danach. Sobald ich weiss, welches Context Engineering ich tun muss, waehle ich das guenstigste Modell, das den Zuverlaessigkeitsstandard unter der richtigen Kontextkonfiguration haelt.

FAQ

Was ist der Unterschied zwischen Prompt Engineering und Context Engineering?

Prompt Engineering konzentriert sich auf die Formulierung deines System-Prompts und der Benutzernachrichten. Context Engineering ist die umfassendere Disziplin: Entscheiden, welche Informationen in das gesamte Kontextfenster eingehen — einschliesslich Konversationsverlauf, abgerufene Daten und Tool-Ausgaben — in welcher Reihenfolge und zu welchen Token-Kosten.

Wie gross sollte mein System-Prompt sein?

So klein wie moeglich, waehrend er spezifisch ist. Ich zielte auf unter 800 Token fuer die meisten Agenten ab. Ein System-Prompt, der versucht, jedes Szenario zu antizipieren, wird am Ende zu lang, um vom Modell zuverlaessig gelesen zu werden.

Ist Context Engineering wichtiger fuer bestimmte Modelle als fuer andere?

Es ist fuer alle wichtig, aber die Einsaetze sind mit kleineren Modellen hoeher. Ein grosses Frontier-Modell kann sich manchmal von einem schlecht strukturierten Kontext erholen; ein kleineres Modell mit einem engerem Budget nicht.

Wie weiss ich, ob mein Context Engineering funktioniert?

Verfolge dieselben Metriken, die du fuer jede Zuverlaessigkeitsaenderung verfolgen wuerdest: Erfolgsrate in deinem Evaluierungssatz, Kosten pro erfolgreichem Ergebnis und Fehlerverteilung nach Schritt.

Sollte ich den Verlauf immer komprimieren oder zusammenfassen?

Fuer kurze transaktionale Agenten: nein. Fuer Multi-Turn-Agenten, die mehr als 5-6 Austausche durchfuehren: ja, immer. Die Faustregel, die ich verwende: Sobald das Verlaufs-Budget 30% meines gesamten Kontext-Budgets ueberschreitet, fange ich an, zusammenzufassen.