Prompt Engineering vs. Context Engineering: kein Rebranding, ein Wechsel dessen, was Sie optimieren

Prompt Engineering ist, eine Anweisung gut zu formulieren. Context Engineering ist, zu entscheiden, was das Modell überhaupt sieht. Der Begriff wurde im Juni 2025 von Shopifys Tobi Lutke populär gemacht und von Andrej Karpathy verstärkt, der ihn als die Kunst beschrieb, das Kontextfenster mit genau der richtigen Information für den nächsten Schritt zu füllen. Die sauberste Unterscheidung kommt von Philipp Schmid: Kontext ist alles, was das Modell sieht, bevor es eine Antwort erzeugt, und das ist ein System, keine Zeichenkette.

Die beiden sind keine Rivalen; Prompt Engineering ist eine Teilmenge. Wenn Sie einen guten System-Prompt schreiben, ist das Prompt Engineering. Wenn Sie entscheiden, welche drei Dokumente abgerufen werden, welche Werkzeuge Sie freigeben, wie viel Verlauf Sie behalten, was wegzufassen ist und welches Ausgabeschema Sie verlangen, alles unter einem Token-Budget, ist das Context Engineering. Anthropics eigene Leitlinie rahmt es als das Verwalten des gesamten Kontextzustands über Züge hinweg, und ihr schärfster Satz ist der, den es zu behalten lohnt: Kontext ist eine endliche Ressource mit abnehmendem Grenzertrag.

Der Grund, warum Context Engineering zu einer benannten Disziplin wurde, ist, dass die bequeme Annahme unter Messung zerbrach. Die Annahme war, dass Modelle mit langem Kontext einen das Fenster vollstopfen und aufhören zu denken lassen. Chromas Context-Rot-Studie testete im Juli 2025 18 Frontier-Modelle und fand, dass jedes degradiert, je mehr Eingabe wächst, oft auf uneinheitliche Weise: das Modell behandelt das zehntausendste Token nicht so verlässlich wie das hundertste. Der ältere Lost-in-the-Middle-Befund zeigte in dieselbe Richtung.

Zwei Kräfte machten die Nutzlast, nicht den Prompt, zum Ding, das zu engineeren ist. Erstens: Agenten, Werkzeugnutzung, Retrieval und Speicher bedeuten, dass der Kontext über viele Züge von einem System zusammengesetzt wird, nicht einmal von Hand geschrieben. Zweitens die Ökonomie: in Produktion bei Manus liegt das Verhältnis von Eingabe- zu Ausgabe-Token bei rund 100 zu 1, und die Wiederverwendung des Key-Value-Caches treibt einen großen Kostenunterschied, was ins Fenster kommt, ist also ebenso eine Kostenentscheidung wie eine Qualitätsentscheidung. Mehr Kontext ist nicht besser; budgetierter, relevanter Kontext ist es. Das ist das empirische Rückgrat unter unserem früheren Durchgang durch Context Engineering und warum es zählt.

Vom Etikett befreit, ist Context Engineering ein Satz testbarer Praktiken, kein Prompt-Flüstern. Die benannten Techniken kehren bei Anthropic, LangChain und dem Manus-Produktionsbericht wieder:

• Retrieval. Ziehen Sie die wenigen relevanten Dokumente im Moment, in dem sie gebraucht werden, statt alles hineinzukopieren. Das ist die Disziplin hinter Retrieval-Augmented Generation.
• Verdichtung und Zusammenfassung. Komprimieren Sie alte Züge in eine laufende Zusammenfassung, damit das Budget für das Lebendige ausgegeben wird, nicht fürs Transkript.
• Speicher und Notizen. Lagern Sie Zustand in externe Notizen oder Dateien aus, die der Agent zurücklesen kann, statt ihn im Fenster mitzutragen.
• Werkzeug-Kuratierung. Halten Sie drei bis fünf Kernwerkzeuge geladen und ziehen Sie den Rest gerade rechtzeitig. Jedes Werkzeug zu laden verdünnt das Signal und bricht den Cache.
• Strukturierte Ausgaben. Verlangen Sie ein Schema, damit das Modell Token für die Antwort ausgibt, nicht für formatierende Prosa.
• Isolation. Teilen Sie Arbeit über Subagenten auf, damit jeder nur den Kontext sieht, den er braucht.

LangChain rahmt denselben Satz als schreiben, auswählen, komprimieren und isolieren. Der Punkt ist, dass jedes davon messbar ist: Sie können einen Retriever, eine Verdichtungsschwelle oder eine Werkzeugausstattung A/B-testen, was genau das ist, was dies zu Engineering statt zu Formulierung macht.

Teilweise, und das ist in Ordnung. Ja, gute Ingenieure kuratierten bereits, was das Modell sieht; der Wert des Namens ist, dass er die Optimierung auf die Nutzlast und das System richtet, nicht auf den Satz, wo Verlässlichkeit und Kosten tatsächlich leben. Die laufende Debatte ist nützlicher als der Terminologie-Streit. Im Juni 2025 argumentierte Cognition gegen Multi-Agenten-Systeme, mit der Begründung, dass es schwer ist, Kontext sauber zwischen Agenten zu teilen, und empfahl, Arbeit einzeln zu halten und volle Traces zu teilen. In derselben Woche beschrieb Anthropic ein Multi-Agenten-Recherchesystem, das von disziplinierter Kontextisolation abhängt. Dieselbe Disziplin, entgegengesetzte architektonische Schlussfolgerung.

Für ein Team, das mit LLMs baut, sind die Lehren schlicht. Budgetieren Sie Token, wie Sie Rechenleistung budgetieren, denn mehr ist nicht kostenlos und nicht immer besser. Behandeln Sie die Arbeit als Verrohrung (Retrieval-Qualität, Verdichtung, Speicher, Werkzeug-Kuratierung, strukturierte Ausgaben), nicht als Formulierung. Und wählen Sie Ihre Architektur danach, wie verlässlich Sie Kontext teilen können, nicht danach, welcher Ansatz fortschrittlicher klingt. Der Name wird weiter mutieren, manche nennen die nächste Schicht schon Harness Engineering, aber das Objekt ist stabil: das System, das entscheidet, was das Modell zu sehen bekommt.