Was ist Context Engineering? Was das Modell erhält, bevor es antwortet

Context Engineering ist die Gestaltung dessen, welche Informationen ein Sprachmodell zur Inferenzzeit erhält, in welcher Form, in welcher Reihenfolge und für wie lange. Es ist umfassender als Prompt Engineering, weil der Modellkontext Systemanweisungen, Benutzernachrichten, abgerufene Dokumente, Tool-Ergebnisse, Speicher, aktuellen Anwendungszustand, Beispiele, strukturierte Daten und Zwischenartefakte umfassen kann. Das Ziel ist nicht, die Anzahl der Tokens zu maximieren, sondern den kleinsten nützlichen Kontext zu konstruieren, der die für die aktuelle Aufgabe erforderlichen Informationen, Einschränkungen und Belege bewahrt.

Was Context Engineering wirklich bedeutet

Jeder Modellaufruf erfolgt in einer temporären Arbeitsumgebung: die aktuellen Anweisungen, Nachrichten, abgerufenen Belege, Tool-Ausgaben und Zustände, die in das aktive Kontextfenster passen. Context Engineering ist die Disziplin, diese Umgebung bewusst zu konstruieren.

Das Schlüsselwort ist bewusst. Ein naives System verkettet einfach alles, was es hat: vollständigen Verlauf, alle abgerufenen Dokumente, jede Tool-Antwort und große System-Prompts. Ein context-engineered System entscheidet, welche Informationen für die aktuelle Entscheidung erforderlich sind und welche Informationen außerhalb des Fensters bleiben sollten, bis sie benötigt werden.

Dadurch ist Context Engineering teilweise ein Informationsarchitekturproblem, teilweise ein Laufzeitproblem und teilweise ein Evaluierungsproblem. Das Design muss entscheiden, was in den Kontext gelangen kann, woher es kommt, welche Version aktuell ist, wie Konflikte aufgelöst werden, wie viel Detail beibehalten wird und wie das Ergebnis getestet wird.

Das einfachste Beispiel

Stellen Sie sich einen internen Support-Assistenten vor. Ein Benutzer fragt: „Kann dieser Kunde ohne Gebühr kündigen?“

Das Modell benötigt möglicherweise fünf Dinge: die aktuelle Kündigungsrichtlinie, den aktuellen Vertragstyp des Kunden, das effektive Vertragsdatum, die relevanten Ausnahmeregeln und den Autorisierungsumfang des Benutzers.

Es benötigt nicht unbedingt die gesamte Kundendatenbank, das vollständige Richtlinienarchiv, jede vorherige Konversation oder jedes Support-Ticket. Context Engineering ist der Prozess, der die fünf nützlichen Teile auswählt und zusammenstellt, während irrelevante Informationen ausgeschlossen werden.

Wo das einfache Beispiel endet

Reale Systeme sind schwieriger, weil die für einen Schritt benötigten Informationen möglicherweise nicht bekannt sind, bevor die Ausführung beginnt. Ein Agent kann durch Tools neue Fakten entdecken, Zwischendateien erstellen, sich ändernden externen Zustand empfangen oder eine Aufgabe über mehr als ein Kontextfenster erstrecken.

Context Engineering wird daher dynamisch. Der Kontext für Schritt 12 sollte nicht einfach der Kontext von Schritt 1 plus elf Schichten akkumulierter Ausgabe sein. Er sollte den aktuellen Aufgabenstatus, die noch relevanten Entscheidungen und die für die nächste Aktion erforderlichen Belege widerspiegeln.

Was kann in einen Modellkontext gelangen?

Context Engineering vs. Prompt Engineering

Anthropic beschreibt Context Engineering ausdrücklich als die natürliche Weiterentwicklung des Prompt Engineering für Systeme, in denen das Modell mit Tools, externen Daten, Nachrichtenhistorie und lang laufendem Agentenzustand arbeiten muss. Die praktische Unterscheidung ist nützlich, weil ein perfekt geschriebener Prompt fehlende autoritative Daten oder einen durch widersprüchlichen Zustand verunreinigten Kontext nicht ausgleichen kann.

Context Engineering vs. Retrieval

Retrieval wählt Kandidateninformationen aus einem externen Korpus oder einer Quelle aus. Context Engineering entscheidet, was danach und darum herum mit diesem Retrieval geschieht.

Der Retriever kann 30 Passagen zurückgeben. Ein Reranker kann sie auf 10 reduzieren. Die Kontextschicht kann vier Passagen auswählen, Duplikate entfernen, Quell-/Versionsmetadaten anhängen, sie mit dem aktuellen Anwendungszustand kombinieren und sie nach den Systemanweisungen platzieren.

Deshalb kann ein RAG-System die richtige Passage abrufen und trotzdem schlecht antworten: Das Scheitern kann während der Kontextzusammenstellung statt beim Retrieval auftreten.

Context Engineering vs. Gedächtnis

Gedächtnis sind Informationen, die außerhalb des unmittelbaren Modellaufrufs bewahrt werden, damit sie später erneut verwendet werden können. Kontext sind die Informationen, die tatsächlich in den aktuellen Aufruf geladen werden.

Ein Gedächtnissystem kann Tausende Fakten, Notizen oder frühere Entscheidungen enthalten. Context Engineering wählt aus, welche davon für die aktuelle Aufgabe wieder eingeführt werden sollen. Jedes Gedächtnis bei jedem Turn zu laden, untergräbt den Zweck einer externen Gedächtnisschicht.

Die Unterscheidung wird entscheidend für volatilen Zustand. Ein erinnerter Projektstatus oder eine Benutzerpräferenz kann nützlich sein, aber der aktuelle autoritative Zustand muss möglicherweise vor einer folgenreichen Entscheidung neu gelesen werden.

Context Engineering vs. Anwendungszustand

Anwendungszustand ist der aktuelle Zustand des äußeren Systems: Kontostand, Ticketstatus, Dateiversion, Workflow-Phase, Deployment-Zustand oder Aufgabenfortschritt.

Zustand kann in den Kontext zusammengefasst werden, aber die Zusammenfassung ist nicht der Zustand selbst. Für folgenreiche Operationen muss die Laufzeit möglicherweise das autoritative System unmittelbar vor der Aktion neu lesen, anstatt einem früheren modellsichtbaren Snapshot zu vertrauen.

Werkzeugdesign ist Teil des Kontext-Engineerings

Werkzeuge geben Agenten nicht nur Fähigkeiten. Werkzeugnamen, Beschreibungen, Schemas und Ergebnisse werden zu modell-sichtbaren Informationen, die Entscheidungen prägen.

Die aktuelle Kontext-Engineering-Richtlinie von Anthropic betont token-effiziente Werkzeuge und warnt vor aufgeblähten Werkzeugsätzen mit überlappender Funktionalität. Ein Werkzeugkatalog, der für einen Menschen schwer zu unterscheiden ist, ist auch für ein Modell schwer zuverlässig zu routen.

Auch Werkzeugausgaben brauchen Kontextdisziplin. Ein vollständiges Protokoll mit 20.000 Zeilen zurückzugeben, wenn der Agent eine einzelne Fehlerbedingung angefordert hat, verbraucht Aufmerksamkeit und kann die entscheidenden Beweise verschütten.

Just-in-Time-Kontext vs. vorgeladener Kontext

Anthropic beschreibt ein hybrides Muster, bei dem ein Teil des stabilen Kontexts vorgeladen wird, während Agenten zur Laufzeit zusätzliche Informationen abrufen. Dies ist ein nützliches Architekturmuster, weil nicht jede wichtige Tatsache eine dauerhafte Residenz im Kontextfenster verdient.

Kontext ist ein Budget, kein Speichersystem

Ein Kontextfenster definiert Kapazität. Es garantiert nicht, dass jedes Token gleich gut genutzt wird. Das Modell muss Aufmerksamkeit über Anweisungen, Verlauf, Beweise, Werkzeuge und Zwischenzustand verteilen.

Das praktische Ziel ist daher nicht, das Fenster zu füllen. Es ist, den Nutzen des begrenzten Aufmerksamkeitsbudgets zu maximieren.

Anthropic formuliert ein ähnliches Prinzip als das Finden der kleinsten hochsignaligen Token-Menge, die die Wahrscheinlichkeit des gewünschten Verhaltens maximiert. Die Kontextmanagement-Richtlinie von OpenAI warnt ebenfalls, dass unkuratierter Verlauf, redundante Werkzeugergebnisse und verrauschtes Retrieval selbst große Fenster überwältigen können.

Warum mehr Kontext schlechter sein kann

Zusätzlicher Kontext kann irrelevante Informationen, veralteten Zustand, doppelte Beweise, widersprüchliche Anweisungen oder Positionskonkurrenz einführen. Er kann auch dazu führen, dass Kompaktierungssysteme Details verwerfen, die später wichtig werden.

Die klassische Lost-in-the-Middle-Studie zeigte, dass Langkontextmodelle Informationen unterschiedlich nutzen können, je nachdem, wo relevanter Inhalt erscheint, wobei die Leistung oft abnimmt, wenn entscheidende Informationen in die Mitte langer Eingaben gesetzt werden.

Das bedeutet nicht, dass langer Kontext von Natur aus schlecht ist. Es bedeutet, dass Verfügbarkeit innerhalb des Fensters nicht dasselbe ist wie zuverlässige Nutzung.

Die Kontextreihenfolge sollte bewusst gewählt werden

Kontextkonstruktion ist auch ein Reihenfolgeproblem. Kritische Anweisungen, aktueller Zustand, entscheidende Beweise und aufgabenspezifische Einschränkungen sollten nicht willkürlich aneinandergereiht werden.

Es gibt keine universell perfekte Reihenfolge für jedes Modell und jede Aufgabe. Die Architektur sollte daher testen, ob eine Neuordnung der Beweise die Korrektheit verändert und ob wichtige Informationen über realistische Kontextvariationen hinweg robust bleiben.

Eine stabile Antwort, die sich dramatisch ändert, wenn zwei gleichermaßen gültige Passagen ihre Positionen tauschen, deutet auf eine Kontextsensitivität hin, die gemessen und nicht ignoriert werden sollte.

Konfliktbehafteter Kontext erfordert explizite Vorrangregeln

Ein Modell kann eine alte Richtlinie und eine neue Richtlinie erhalten, eine erinnerte Präferenz und eine aktuelle explizite Anweisung oder einen zwischengespeicherten Status und ein Live-API-Ergebnis. Das System sollte nicht erwarten, dass das Modell den Vorrang aus dem Prosastil ableitet.

Context Engineering sollte Vorrang durch Quellenauswahl, Metadaten, Reihenfolge oder explizite Anweisungen kodieren: der aktuelle autoritative Zustand überschreibt veraltete Kopien; eine explizite aktuelle Nutzeranweisung überschreibt eine ältere abgeleitete Präferenz; eine genehmigte Richtlinie ersetzt veraltete Entwürfe.

Kompaktierung ist Kontexttransformation, keine verlustfreie Speicherung

Langlebige Systeme müssen irgendwann den Verlauf kürzen, zusammenfassen oder kompaktieren. Kompaktierung erzeugt eine neue Repräsentation des vorherigen Kontexts, damit der Agent fortfahren kann, ohne jedes Token erneut abzuspielen.

OpenAIs Beispiele für Kontextmanagement verwenden Kürzung und Kompression für langlebige Sitzungen. Anthropic beschreibt Kompaktierung als eine primäre Technik, um die Kohärenz aufrechtzuerhalten, wenn eine Interaktion sich dem Kontextlimit nähert.

Der schwierige Teil ist zu entscheiden, was nicht sicher entfernt werden kann: ungelöste Aufgaben, Identifikatoren, Nutzereinschränkungen, Sicherheitsgrenzen, Architekturentscheidungen, Ausnahmen, Quellenherkunft und die Bedingungen, unter denen eine frühere Schlussfolgerung gültig ist.

Gültigkeitsgrenzen bewahren

Wichtige Schlussfolgerungen sollten die Bedingungen mitführen, unter denen sie weiterhin gestützt werden: Version, Datum, Geltungsbereich, Annahmen, Quellenautorität und ungelöste Meinungsverschiedenheiten.

Context Engineering ist daher mit der Answer Validity Boundary verbunden. Der Kontextassembler sollte nicht die Metadaten entfernen, die bestimmen, ob Belege noch anwendbar sind.

Context Engineering ist auch eine Sicherheitsgrenze

Daten, die das Modell erreichen, haben eine wichtige Systemgrenze überschritten. Die Kontextassemblierung muss daher Autorisierung, Mandantentrennung, Vertraulichkeit und Datenminimierungsregeln respektieren.

Ein Retriever kann technisch eine Passage finden, auf die der aktuelle Nutzer keinen Zugriff hat. Das korrekte Design besteht darin, zu verhindern, dass diese Passage in den Modellkontext gelangt, anstatt sich darauf zu verlassen, dass das Modell sie ignoriert.

Werkzeugausgaben können auch nicht vertrauenswürdige Anweisungen oder adversarialen Inhalt enthalten. Context Engineering sollte die Unterscheidung zwischen Anwendungsanweisungen und externen Daten bewahren, damit abgerufener Text nicht stillschweigend Anweisungsautorität erlangen kann.

Eine praktische Architektur für Context Engineering

Der Kontext-Assembler ist konzeptionell wichtig, auch wenn kein Modul genau diesen Namen trägt. In einer kleinen Anwendung kann er gewöhnlicher Anwendungscode sein. In einer großen Agentenplattform kann er Sitzungsverwaltung, Retrieval, Speicher, Tool-Middleware, Kompaktierung und Richtliniendurchsetzung kombinieren.

Eine praktische Richtlinie zum Kontextaufbau

Wie man Context Engineering evaluiert

Kontextassemblierung ist eine eigenständige RAG-Fehlerschicht

Eine RAG-Pipeline kann beim Retrieval erfolgreich sein und dennoch nachgelagert fehlschlagen. Die relevante Quelle kann auf Rang 2 erscheinen, doch der Kontext-Assembler kann sie verwerfen, abschneiden, mit veraltetem widersprüchlichem Material kombinieren oder das Token-Budget überschreiten.

Deshalb sollten Retrieval-Traces mit dem tatsächlichen, an das Modell gesendeten Kontext verglichen werden. Ohne diesen Vergleich werden Kontextfehler leicht als Embedding- oder Modellfehler fehldiagnostiziert.

Belege aus der ursprünglichen Implementierung

Source of Truth Research Engine: begrenzte Recherche statt unbegrenztem Kontext

Die Source of Truth Research Engine trennt Entdeckung, Beschaffung, Extraktion, Verifikation, Widerspruchsanalyse und Synthese in begrenzte Recherchephasen, statt eine einzige riesige Rechercheaufgabe und alles angesammelte Material in einen einzigen Modellaufruf zu senden.

Ihr Evidenzmodell speichert Sources, Artifacts, Claims, Relations, Contradictions und Herkunft außerhalb des Modellkontexts. Das Modell kann die für den aktuellen Rechercheschritt benötigte Teilmenge erhalten, während dauerhafte Belege im externen Speicher verbleiben.

Das ist ein konkretes Context-Engineering-Muster: dauerhafter Recherchezustand lebt außerhalb des Modellfensters; der aktive Modellkontext wird für die aktuelle Phase rekonstruiert.

Aaasaasa AI Client: Runtime, Berechtigungen und Kontext sind getrennte Anliegen

Der Aaasaasa AI Client trennt Anbieter-/Modellauswahl, Laufzeitort, Workspace-Berechtigungen, lokale Ressourcen und Tool-Zugriff. Dadurch wird verhindert, dass der Modellkontext zum Eigentümer von Autorisierung oder Anwendungszustand wird.

Direct Chat und agentische Laufzeitumgebungen können unterschiedliche Tool-Fähigkeiten haben. Workspace-Berechtigungsprofile werden von der Laufzeitumgebung durchgesetzt und nicht nur im natürlichsprachlichen Kontext beschrieben. Diese Unterscheidung ist wichtig: Der Kontext kann einem Modell sagen, was es tun soll, während die Laufzeitumgebung weiterhin durchsetzen muss, was tatsächlich erlaubt ist.

Die Implementierungsbelege hier sind architektonische Trennung, nicht die Behauptung, dass jede in diesem Artikel beschriebene fortgeschrittene Kontextmanagement-Technik bereits implementiert ist.

Häufige Fehlermuster im Context Engineering

Häufige Missverständnisse

Eine praktische Abfolge für Context Engineering

Checkliste für Context Engineering

Randfälle und Einschränkungen

Manche Aufgaben sind so einfach, dass Context Engineering auf einen kurzen System-Prompt und eine Benutzernachricht reduziert wird. Das Hinzufügen von Retrieval, Speicher und Verdichtung würde nur unnötige Architektur einführen.

Manche Aufgaben erfordern hohe Recall und können absichtlich mehr Kontext einbeziehen, bevor später synthetisiert wird. Recherche, Entdeckung und juristische Prüfung können es vorziehen, Auslassungen zu vermeiden, statt die Token-Anzahl zu minimieren.

Manche Informationen sollten niemals vor der Verwendung zusammengefasst werden. Exakte Verträge, Code, kryptografisches Material, numerische Aufzeichnungen und regulatorische Texte können einen wörtlichen oder strukturierten Abruf erfordern, wenn eine Komprimierung die Bedeutung verändern könnte.

Das Verhalten bei langem Kontext variiert erheblich zwischen Modellen. Eine Strategie, die an einem Modell, einer Kontextlänge oder einem Tool-Harness validiert wurde, sollte nicht automatisch auf ein anderes übertragen werden.

Das Modell kann hervorragenden Kontext dennoch ignorieren oder falsch interpretieren. Context Engineering verbessert die Informationsumgebung; es garantiert jedoch nicht die Korrektheit des Schlussfolgerns.

Was würde diese Antwort ändern?

Zukünftige Modelle könnten robuster gegenüber langem Kontext, Positionseffekten und widersprüchlichen Informationen werden. Das könnte den Umfang manueller Kuratierung reduzieren.

Die architektonische Unterscheidung bliebe dennoch nützlich, weil Berechtigungen, Aktualität, Speicherpersistenz, Quellenautorität und externer Anwendungszustand unabhängig von der Kontextfenstergröße außerhalb des Modells existieren.

Das empfohlene Gleichgewicht zwischen vorab geladenem und Just-in-Time-Kontext ändert sich ebenfalls mit Latenzanforderungen, Zuverlässigkeit der Tools, Korpusgröße, Modellkosten und der Dynamik der zugrunde liegenden Informationen.

Verwandtes kanonisches Wissen

Context Engineering liegt zwischen Retrieval und Generierung. RAG erklärt, wie externes Wissen abgerufen wird; R01 trennt Embeddings, Vektorsuche und Reranking; Context Engineering erklärt, was letztendlich das Modell erreicht.

Die Source-of-Truth-Architektur beantwortet eine andere Frage: nicht welche Informationen im Kontext vorhanden sind, sondern welche Quelle autorisiert ist, eine Aussage zu belegen.

Der bestehende Artikel Warum mehr Kontext KI-Antworten verschlechtern kann ist der diagnostische Begleiter zu dieser kanonischen Definition. Er konzentriert sich auf Kontextverschmutzung, Positionseffekte, Top-k-Wachstum, Kompaktierungsverlust und Antwortverschlechterung, anstatt Context Engineering selbst neu zu definieren.

Häufig gestellte Fragen

Glossar

Fazit

Context Engineering ist die Schicht, die entscheidet, was das Modell sieht, bevor es antwortet. Dadurch ist es umfassender als Prompting und dem Retrieval nachgelagert, während es sich zugleich von dauerhaftem Speicher und autoritativem Anwendungszustand unterscheidet.

Eine starke Kontextarchitektur behandelt das Kontextfenster nicht als Datenbank. Sie hält dauerhaften Zustand und dauerhaftes Wissen außerhalb des Modells, lädt, was für die aktuelle Entscheidung erforderlich ist, bewahrt Autorität und Herkunft, entfernt unnötiges Rauschen und aktualisiert volatile Informationen bei Bedarf.

Das praktische Ziel ist daher nicht maximaler Kontext. Es ist minimal ausreichender, signalstarker, korrekt autorisierter und gültigkeitsbewahrender Kontext für die nächste Modellentscheidung.

Primärquellen und aktuelle Leitlinien

Die folgenden Quellen stützen die aktuelle Terminologie des Context Engineering, das Verhalten bei langem Kontext und operative Muster des Kontextmanagements. Projektabschnitte sind ausdrücklich Umsetzungsbelege und keine allgemeingültigen Aussagen.