Context Engineering ist die Praxis, alles festzulegen, was ein Sprachmodell beim Antworten sieht: nicht nur die Frage, die du tippst, sondern auch die Anweisungen drumherum, die eingefügten Dokumente und Tool-Ergebnisse, das gespeicherte Gedächtnis über den User und das bisherige Gespräch. All das teilt sich ein Kontextfenster, und das Modell antwortet aus diesem Text und aus nichts anderem. Der Begriff verbreitete sich 2025, als immer mehr KI-Produkte zu Agenten wurden, die den Großteil ihres Kontexts automatisch zusammenstellen.
Beim Prompt Engineering geht es vor allem darum, wie du eine Anfrage formulierst. Beim Context Engineering geht es darum, was das Modell bei jedem Aufruf vor sich haben soll, und in welcher Reihenfolge.
Vom Prompt zum Kontext
In einer Chat-App schreibst du den Großteil des Kontexts selbst: Die App fügt einen System-Prompt und den Verlauf hinzu, und du lieferst den Rest. In einer Anwendung kippt das Verhältnis. Ein User tippt einen Satz, und der Code um das Modell herum fügt Anweisungen, ein Nutzerprofil, drei per Suche gefundene Hilfeartikel, die Liste verfügbarer Tools und die Ausgabe des letzten Tool-Aufrufs hinzu. Der Satz des Users ist dann vielleicht nur ein kleiner Bruchteil dessen, was das Modell liest.
Wenn ein solches System schlecht antwortet, liegt die Lösung selten in der Formulierung. Meist hatte das Modell das falsche Material: ein fehlender Fakt, ein veraltetes Tool-Ergebnis, ein irrelevantes Dokument, das für die Suche relevant aussah.
Was ins Kontextfenster kommt
Ein typischer Aufruf in einer KI-Anwendung enthält einige oder alle dieser Teile, ungefähr in dieser Reihenfolge:
- Systemanweisungen: Rolle, Regeln und Ausgabeformat, meist fest für die ganze App. Siehe System-Prompt.
- Tool-Definitionen: Namen, Beschreibungen und Parameter der Tools, die das Modell aufrufen darf.
- Beispiele: ein paar Beispiel-Inputs und Ausgaben, die das erwartete Verhalten zeigen.
- Gedächtnis: Fakten aus früheren Sitzungen, etwa Tarif, Sprache oder Vorlieben des Users.
- Abgerufene Dokumente: Passagen, die für diese Frage in einer Wissensdatenbank gesucht wurden (Retrieval-Augmented Generation, kurz RAG).
- Gesprächsverlauf: frühere Nachrichten, wörtlich oder zusammengefasst.
- Tool-Ergebnisse: Ausgaben von Suchen, Codeläufen oder API-Aufrufen während dieser Aufgabe, wie in einer ReAct-Schleife.
- Die aktuelle Nachricht: das, was der User gerade gefragt hat.
Der Block unten ist ein zusammengestellter Kontext für einen Support-Assistenten. Schalte die Bausteine nacheinander aus. Ohne den Kontext-Baustein kann das Modell den Tarif der Kundin nicht kennen; ohne den Input-Baustein hat es keine Produktfakten, und seine Vorgaben sagen ihm, das zuzugeben, statt zu raten.
Hallo Dana, der Offline-Modus gehört zum Pro-Tarif, und dein Konto läuft gerade im Free-Tarif, deshalb steht er dir im Moment nicht zur Verfügung. Mit Pro werden Notizen, die du während des Flugs erstellst, automatisch synchronisiert, sobald dein Handy wieder verbunden ist. Eine Grenze solltest du kennen: Anhänge über 20 MB sind offline nicht verfügbar.
Beachte, dass die richtige Antwort davon abhängt, zwei Quellen zusammenzuführen: das Gedächtnis (Free-Tarif) und ein Dokument (Offline-Modus nur mit Pro). Keine der beiden reicht allein, und das ist typisch. Ein großer Teil des Context Engineering besteht darin, dafür zu sorgen, dass Teile, die einander brauchen, gemeinsam ankommen.
Vier Arten, wie ein Kontext schiefgeht
- Fehlende Information. Das Modell füllt Lücken mit plausiblen Vermutungen, und daher kommen viele Halluzinationen. Ergänze den Fakt oder sag dem Modell, was es tun soll, wenn ein Fakt fehlt.
- Zu viel Material. Jeder irrelevante Absatz kostet Tokens und konkurriert um Aufmerksamkeit. Liu et al. 2023, "Lost in the Middle: How Language Models Use Long Contexts", fanden heraus, dass die getesteten Modelle Informationen am Anfang oder Ende eines langen Inputs zuverlässiger nutzten als Informationen in der Mitte. Neuere Modelle kommen mit langen Inputs besser zurecht, aber die paar Passagen zu schicken, die die Frage beantworten, ist trotzdem billiger und für das Modell leichter zu nutzen, als das ganze Handbuch einzufügen.
- Veraltete Information. Ein Tool-Ergebnis von vor zehn Schritten kann eine Datei oder einen Kontostand beschreiben, der sich seitdem geändert hat. Wenn das Modell beide Versionen sieht, nimmt es vielleicht die alte.
- Widersprüche. Zwei Dokumente widersprechen sich, oder das Gedächtnis sagt das eine und der User das andere. Sag dem Modell, welche Quelle gewinnt, zum Beispiel "die neueste Nachricht des Users hat Vorrang vor dem gespeicherten Gedächtnis".
Den Kontext ordnen
Die Reihenfolge ändert sowohl die Ergebnisse als auch die Kosten.
- Stabile Teile zuerst. Systemanweisungen, Tool-Definitionen und festes Referenzmaterial ändern sich zwischen Aufrufen selten. Mehrere API-Anbieter bieten Prompt Caching an, das die Verarbeitung eines identischen Input-Anfangs wiederverwendet, also macht ein unveränderter Anfang wiederholte Aufrufe billiger und schneller.
- Langes Material vor die Frage. Bei einem langen Dokument oder vielen Passagen setz das Material an den Anfang und die Frage und die letzten Anweisungen danach. Anthropics Prompting-Leitfaden zum Beispiel empfiehlt diese Reihenfolge für lange Inputs, mit der Frage direkt vor der Stelle, an der das Modell zu schreiben beginnt.
- Beschrifte jedes Stück. Pack jede Quelle in Tags wie
<document>,<memory>oder<tool_result>, mit einem Quellennamen. Beschriftungen lassen das Modell Daten von Anweisungen unterscheiden, und du kannst es bitten zu nennen, woher eine Antwort stammt. Trennzeichen und XML-Tags zeigt die Formate.
Einen langen Kontext kürzen
Jede Nachricht in einem Chat schickt den ganzen Verlauf erneut, also wachsen lange Sitzungen, bis etwas weichen muss. Je nach App werden ältere Nachrichten zusammengefasst oder weggelassen, oder du wirst gebeten, einen neuen Chat zu beginnen. Bessere Ergebnisse bekommst du, wenn du gezielt kürzt.
- Behalte die letzten paar Nachrichten wörtlich und ersetz ältere durch eine Zusammenfassung.
- Wenn ein Tool-Ergebnis verwendet wurde, ersetz es durch eine einzeilige Notiz dazu, was es gezeigt hat.
- Behalte in jeder Zusammenfassung exakte Bezeichner: Dateinamen, Funktionsnamen, IDs, Fehlermeldungen und Zahlen. Eine Zusammenfassung, die "die Konfigurationsdatei" sagt, wo im Verlauf
settings.prod.yamlstand, verliert genau das eine Detail, auf das es ankam. - Wenn das Gespräch in einer Chat-App abdriftet, beginne einen neuen Chat mit einer Übergabenotiz. Der Prompt unten schreibt eine.
Ziel: die handgeschriebenen Prüfungen des Anmeldeformulars durch ein gemeinsames Validierungsschema ersetzen, das Browser und Server beide nutzen.
Entscheidungen
- Eine Schemadatei,
signupSchema.ts, importiert vonSignupForm.tsxundapi/signup.ts, damit die beiden Regelsätze nicht auseinanderlaufen können. - Die Fehlermeldungen bleiben wortgleich, weil das Hilfecenter sie zitiert.
Aktueller Stand
- Die Validierung im Browser nutzt das Schema, und
SignupForm.test.tsxläuft durch. - Der Server ruft noch das alte
validateSignup()inapi/signup.tsauf.
Exakte Details: Passwörter brauchen mindestens 8 Zeichen und eine Ziffer. Fehlertext für E-Mail: "Bitte gib eine gültige E-Mail-Adresse ein."
Nächster Schritt: validateSignup() durch das Schema ersetzen und die API-Tests laufen lassen.
Offene Frage: Soll eine bereits registrierte E-Mail 409 oder 400 zurückgeben?
Gedächtnis über Sitzungen hinweg
Gedächtnis ist Kontext, der ein Gespräch überdauert: Fakten, die am Ende einer Sitzung gespeichert und in die nächste geladen werden. Chat-Apps bieten Varianten davon, etwa gespeicherte Erinnerungen oder Projektanweisungen, die jedem Chat in einem Projekt hinzugefügt werden. In deiner eigenen Anwendung ist Gedächtnis eine Tabelle oder eine Notizdatei, die dein Code liest und einfügt. Zwei Regeln halten es nützlich: Speicher Fakten, die wahr bleiben (Tarif, Sprache, bevorzugter Tech-Stack), keine Protokolle; und lade nur, was für die aktuelle Aufgabe relevant ist, denn Gedächtnis konkurriert um denselben Platz wie alles andere.
Kontext im Code zusammenstellen
In einer Anwendung ist Context Engineering ganz normaler Code. Diese Skizze mit dem Anthropic Python SDK setzt die festen Regeln und das Gedächtnis in den System-Prompt, behält nur den jüngsten Verlauf und stellt beschriftete Dokumente vor die Frage.
import anthropic
client = anthropic.Anthropic()
MODEL = "your-model-id" # e.g. from your provider's model list
def build_context(question, docs, history, memory, max_messages=6):
documents = "\n".join(
f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
)
system = (
"You are the support assistant for Acme Notes. Answer only from the documents. "
"If they do not cover the question, say so.\n"
f"<memory>\n{memory}\n</memory>"
)
# history holds complete user/assistant pairs, so an even slice starts with a user turn
recent = history[-max_messages:]
user = f"<documents>\n{documents}\n</documents>\n\n{question}"
return system, recent + [{"role": "user", "content": user}]
# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)
Jede Entscheidung in dieser Funktion (welche Dokumente, wie viele Nachrichten, wohin das Gedächtnis kommt) ist eine Entscheidung im Context Engineering, und jede lohnt es, an echten Fragen getestet zu werden, genauso wie du eine Änderung an der Formulierung testen würdest.
Häufig gestellte Fragen
Was ist Context Engineering?
Context Engineering ist die Arbeit, alles auszuwählen, zu ordnen und zu kürzen, was ein Sprachmodell bei einem Aufruf bekommt: die Systemanweisungen, Beispiele, abgerufene Dokumente, Tool-Definitionen und Tool-Ergebnisse, gespeichertes Gedächtnis, den Gesprächsverlauf und die Nachricht des Users. Das Modell antwortet nur aus diesem Text, also entscheidet das, was darin steht und was fehlt, über die Qualität der Antwort.
Was ist der Unterschied zwischen Context Engineering und Prompt Engineering?
Beim Prompt Engineering geht es vor allem um die Formulierung der Anweisungen. Context Engineering umfasst den gesamten Input, von dem ein Großteil von Code zusammengestellt statt von einem Menschen getippt wird: welche Dokumente abgerufen werden, welche Tool-Ergebnisse bleiben, wie viel Verlauf dazukommt und in welcher Reihenfolge. In einem Chat schreibst du den Großteil des Kontexts selbst; in einer App oder einem Agenten wählt ihn großteils das System um das Modell herum aus.
Ist mehr Kontext immer besser?
Nein. Irrelevantes oder veraltetes Material konkurriert mit den wichtigen Teilen, kostet Tokens und kann dem aktuellen Stand widersprechen. Forschung zu langen Inputs hat gezeigt, dass Modelle Informationen in der Mitte eines langen Kontexts übersehen können. Nimm auf, was die Aufgabe braucht, beschrifte es und entferne, was sie nicht mehr braucht.
Warum wird ein langer Chat mit der Zeit schlechter?
Das ganze Gespräch wird bei jeder Nachricht erneut geschickt, also bleiben alte Fehler, verworfene Ideen und überholter Code im Kontext und beeinflussen weiter die Antworten. Wenn der Chat über das Kontextfenster hinauswächst, muss die App ältere Nachrichten weglassen oder zusammenfassen. Einen neuen Chat mit einer kurzen Zusammenfassung der Entscheidungen und des aktuellen Stands zu beginnen, funktioniert oft besser als weiterzumachen.
Was ist RAG im Context Engineering?
RAG (Retrieval-Augmented Generation) heißt, deine eigenen Dokumente nach Passagen zu durchsuchen, die zur Frage passen, und sie in den Kontext einzufügen, bevor das Modell antwortet. Es ist eines der wichtigsten Werkzeuge im Context Engineering: Das Modell bekommt aktuelle, konkrete Fakten, die es aus dem Training nicht kennen kann, und du kannst ihm sagen, dass es nur aus diesen Passagen antworten soll.
