Context Engineering

Vom Prompt zum Kontext

Mit den Agenten hat sich gezeigt: Die Qualität der Ergebnisse hängt weniger von der cleveren Formulierung einzelner Prompts ab als davon, welche Informationen dem Modell insgesamt vorliegen — deutsch sinngemäß „Kontextgestaltung". Ein Modell braucht keine Tricks, sondern dasselbe Wissen, das auch ein fähiger neuer Mitarbeiter bräuchte: die Konventionen des Projekts, die Architektur, die harten Regeln, passende Beispiele. Context Engineering ist die Praxis, dieses Wissen in eine Form zu bringen, die das Modell nutzen kann.

Bestandteile des Kontexts

Zum Kontext eines Agenten zählen üblicherweise sechs Arten von Information: Anweisungen (Rolle und Regeln), Wissen (Dokumente, Fachdaten), Gedächtnis (Sitzungsverlauf und dauerhaft Gespeichertes, siehe Agent-Memory), Beispiele, Werkzeugbeschreibungen (Tool-Use) und Guardrails (Schutzregeln).

Statischer und dynamischer Kontext

Die zentrale Entwurfsentscheidung ist die Aufteilung: Statischer Kontext ist immer geladen — etwa Regel-Dateien und der System-Prompt. Er kostet in jeder Interaktion Platz im Kontextfenster; zu viel davon verwässert das Signal. Dynamischer Kontext wird erst bei Bedarf nachgeladen — etwa abgerufene Dokumente (RAG), Werkzeug-Ergebnisse oder aufgabenspezifische Anleitungen (sogenannte Skills). Gute Systeme behandeln die Grenze zwischen beiden als bewusste Architektur-Entscheidung, die versioniert und überprüft wird.

Abgrenzung

Prompt-Engineering gestaltet die einzelne Anfrage; Context Engineering gestaltet die gesamte Informationsumgebung, in der ein Modell über viele Schritte arbeitet. Das eine löst das andere nicht ab — bei Agenten, die über lange Läufe hinweg Werkzeuge nutzen und Zwischenergebnisse verarbeiten, verschiebt sich das Gewicht aber deutlich zum Kontext.