Context Engineering löst Prompt Engineering als entscheidende KI-Fähigkeit ab

Prompt Engineering ging nie wirklich darum, magische Worte zu finden. Es ging darum, dem Modell genug relevante Informationen in einem nutzbaren Format zu geben, um eine gute Antwort zu produzieren. Dieser Unterschied spielte weniger Rolle, als die Aufgabe ein einfacher Frage-Antwort-Austausch war. Er spielt heute enorm große Rolle, da die meisten produktiven KI-Systeme Agenten sind: Schleifen, die Tools aufrufen, Ergebnisse lesen, Dokumente abrufen und über Dutzende Schritte Zustand behalten.

Die Fähigkeit, die entscheidet, ob solche Systeme funktionieren, ist nicht mehr die Formulierung des Prompts. Es ist Context Engineering — die Disziplin, zu entscheiden, was bei jedem Schritt in das Context Window des Modells gelangt, wie es strukturiert ist und wann es entfernt wird. Teams, die dies als Nebensache behandeln, bauen Agenten, die teuer, langsam und auf schwer zu debuggende Weise falsch sind.

Warum Prompt Engineering nicht mehr ausreicht

Ein einzelner gut formulierter Prompt setzt voraus, dass das Modell bereits alles hat, was es für eine Antwort braucht. Agentische Workflows funktionieren nicht so. Ein Agent, der einen Produktionsvorfall analysiert, sammelt vielleicht Log-Auszüge, ein Runbook, drei verwandte Slack-Threads und die Ausgabe zweier Tool-Aufrufe — alles bevor er auch nur ein Wort seiner eigentlichen Antwort schreibt. Nichts davon ist “der Prompt” im Sinne von 2023. Es ist ein Context-Budget, und jedes Token darin ist eine Entscheidung.

Größere Context Windows haben die Sache zunächst verschlimmert, bevor sie sie verbesserten. Als Modelle der GPT-4-Ära bei rund 32.000 Token deckelten, waren Teams gezwungen, aus Notwendigkeit selektiv zu sein. Context Windows mit einer Million Token entfernten diese Einschränkung, und die naive Antwort — alles Relevante hineinwerfen und das Modell sortieren lassen — erwies sich als leistungsmindernd. Forschung zu Long-Context-Retrieval zeigt durchgängig, dass Modelle ihre Aufmerksamkeit in einem großen Kontext ungleich verteilen, oft Informationen nahe dem Anfang oder Ende bevorzugen und bei Fakten in der Mitte an Genauigkeit verlieren. Mehr Token bedeutet nicht mehr Signal. Es bedeutet oft mehr Rauschen mit einer höheren API-Rechnung.

Die vier Aufgaben von Context Engineering

In der Praxis zerfällt Context Engineering in vier trennbare Probleme, und die meisten Agentenfehler lassen sich darauf zurückführen, eines davon falsch zu lösen.

Retrieval-Auswahl

Entscheiden, was überhaupt in den Kontext gelangt. Dies ist die Aufgabe, für die RAG-Pipelines gebaut wurden, aber Auswahlqualität zählt mehr als Retrieval-Recall. Die 20 semantisch ähnlichsten Abschnitte zurückzugeben ist nicht dasselbe wie die 5, die die Frage tatsächlich beantworten. Teams, die auf Recall statt Präzision optimieren, landen wieder in der Alles-hineinwerfen-Falle, nur dass jetzt ein Embedding-Modell statt eines Menschen das Hineinwerfen übernimmt.

Kompression

Rohe Tool-Ausgaben, Log-Dateien und Dokumentauszüge sind selten in einer Form, die es wert ist, wörtlich gesendet zu werden. Ein 400-zeiliger Stack Trace lässt sich meist auf drei relevante Zeilen und eine Zusammenfassung komprimieren, ohne etwas zu verlieren, das das Modell braucht. Kompression ist die Quelle der meisten Token-Kosteneinsparungen in produktiven Agentensystemen, und genau hier kann naive Zusammenfassung auch leise das eine Detail löschen, das wichtig war.

Struktur und Reihenfolge

Wo Information im Kontext sitzt, beeinflusst, ob das Modell sie korrekt nutzt. Einschränkungen und Anweisungen direkt vor dem Generierungsschritt zu platzieren, statt sie oben in einem langen System-Prompt zu vergraben, verbessert messbar die Befolgung von Anweisungen in Long-Context-Szenarien. Reihenfolge ist nicht kosmetisch — sie ist tragend.

Memory-Rückschreibung

Agenten, die über mehr als eine Runde laufen, brauchen eine Richtlinie, was ins persistente Memory geschrieben wird und was flüchtig im aktuellen Kontext bleibt. Alles zu schreiben macht Memory zu einer zweiten Müllhalde mit demselben Rauschproblem. Nichts zu schreiben lässt den Agenten dieselben Fakten in jeder Sitzung neu herleiten, was Token und Latenz für Wiederentdeckung verbrennt.

Wo Teams es falsch machen

Der häufigste Fehler ist, Kontext als kostenlos zu behandeln. Das ist er nicht. Jedes zusätzliche Dokument im Fenster erhöht Latenz, Kosten und — ab einer gewissen Dichte — einen messbaren Qualitätsabfall der Antworten, manchmal “Context Rot” genannt. Der zweithäufigste Fehler ist statische Kontext-Zusammenstellung: eine einzige Pipeline zur Kontexterstellung zu bauen und sie für jede Anfrage zu nutzen, unabhängig davon, ob die Aufgabe drei oder dreißig Dokumente braucht. Der dritte ist, die Eviction-Richtlinie komplett zu überspringen, sodass eine lang laufende Agenten-Sitzung Tool-Ausgaben anhäuft, bis der Großteil des Context Windows nur noch Gerüst aus Schritten ist, die der Agent nicht mehr braucht.

Wie sich das in einem funktionierenden System zeigt

Teams, die das richtig machen, haben meist ein explizites Context-Budget pro Schritt: eine Token-Obergrenze für abgerufene Dokumente, eine separate Obergrenze für Tool-Ausgaben und eine reservierte Zuweisung für Anweisungen und jüngste Konversationsrunden, die nie verdrängt wird. Sie protokollieren, was im Kontext war, als ein Agent eine schlechte Antwort produzierte, genau wie sie einen Stack Trace protokollieren würden, denn Kontext-Zusammensetzung ist jetzt eine primäre Debugging-Fläche, kein Implementierungsdetail.

Praktische Erkenntnisse

• Hören Sie auf, Prompt-Formulierung isoliert zu optimieren. Prüfen Sie, was tatsächlich bei jedem Schritt der Agenten-Ausführung in das Context Window gelangt, und messen Sie, wie viel davon das Modell tatsächlich nutzt.
• Behandeln Sie Retrieval-Präzision als wichtiger als Retrieval-Recall. Weniger, relevantere Ergebnisse zurückzugeben ist besser als mehr Ergebnisse zurückzugeben und zu hoffen, dass das Modell sie filtert.
• Bauen Sie einen Kompressionsschritt für Tool-Ausgaben und Logs, bevor sie das Context Window erreichen — nicht erst, nachdem eine Kostenprüfung die Token-Ausgaben anmahnt.
• Platzieren Sie Aufgabenanweisung und Einschränkungen nahe am Generierungspunkt, nicht oben in einem langen System-Prompt vergraben, besonders sobald Ihr Kontext einige Tausend Token übersteigt.
• Definieren Sie eine explizite Memory-Rückschreibrichtlinie, statt standardmäßig zwischen Runden alles zu horten oder alles zu verwerfen.