Context Engineering
operative Disziplin zur Gestaltung und Validierung von Kontextinformationen für Menschen und KI-Systeme
From Wikipedia, the free encyclopedia
Context Engineering (deutsch etwa Kontextgestaltung) bezeichnet in der Informatik die systematische Gestaltung der Informationsumgebung, in der ein großes Sprachmodell (LLM) arbeitet. Im Unterschied zum Prompt Engineering, das einzelne Eingaben optimiert, umfasst Context Engineering die Architektur persistenter Kontextsysteme — einschließlich Systemanweisungen, Dateistrukturen, Konventionen und Abhängigkeitssysteme.[1]
Der Begriff wurde im Juni 2025 von Tobi Luetke, CEO von Shopify, geprägt und in der Folge von Entwicklern und Forschern aufgegriffen.[2]
Begriffsgeschichte
Tobi Luetke schlug den Begriff am 18. Juni 2025 als Ablösung von Prompt Engineering vor. Seine Definition: Context Engineering sei „die Kunst, sämtlichen Kontext bereitzustellen, damit eine Aufgabe vom LLM plausibel lösbar wird".[2] Simon Willison, Mitschöpfer des Django-Webframeworks und Blogger zu KI-Themen, erklärte am 27. Juni 2025, der Begriff werde sich durchsetzen, da Prompt Engineering falsche Assoziationen wecke — nämlich die Annahme, es genüge, Eingaben in ein Chatfenster zu tippen.[3]
Philipp Schmid (Senior AI Developer Relations bei Google DeepMind) formalisierte den Begriff: Context Engineering sei „die Disziplin, dynamische Systeme zu entwerfen und zu bauen, die die richtige Information mit den richtigen Werkzeugen im richtigen Format zum richtigen Zeitpunkt bereitstellen".[1] Schmids zentrale These: Die Mehrheit der Fehler in KI-Agentensystemen seien keine Modellfehler mehr, sondern Kontextfehler.[1]
Andrej Karpathy, ehemaliger KI-Leiter bei Tesla und Mitgründer von OpenAI, ordnete Context Engineering in sein Konzept von Software 3.0 ein: Natürliche Sprache werde zur Programmiersprache für LLMs, und die Gestaltung des Kontexts sei die zentrale Ingenieursaufgabe.[4]
Abgrenzung zu Prompt Engineering
| Merkmal | Prompt Engineering | Context Engineering |
|---|---|---|
| Gegenstand | Einzelne Eingabe (Prompt) | Gesamte Informationsumgebung |
| Zeithorizont | Pro Interaktion | Session- und projektüberdauernd |
| Persistenz | Keine (flüchtig) | Versioniert, strukturiert |
| Komplexität | Textoptimierung | Systemarchitektur |
| Analogie | Einen Brief formulieren | Ein Büro einrichten |
Während Prompt Engineering eine gute Antwort auf eine einzelne Frage anstrebt, zielt Context Engineering auf konsistent gute Antworten über Sessions, Aufgaben und Domänen hinweg.[3]
Technische Grundlagen
Kontextfenster
LLMs verarbeiten Eingaben innerhalb eines begrenzten Kontextfensters (gemessen in Token). Alles, was das Modell bei einer Antwort berücksichtigen soll — Systemanweisungen, Gesprächsverlauf, Referenzdokumente — muss in dieses Fenster passen. Context Engineering adressiert die Frage, wie dieses begrenzte Fenster optimal befüllt wird.[1]
Instruktionsdateien
Mehrere LLM-Werkzeuge verwenden projektbezogene Instruktionsdateien im Markdown-Format, die beim Start einer Sitzung automatisch in den Kontext geladen werden:
- CLAUDE.md — verwendet von Claude Code (Anthropic). Hierarchisch: global (Benutzerebene), Projekt (Repository-Ebene), lokal (Verzeichnisebene).[5]
- AGENTS.md — verwendet von Cursor und anderen Coding-Assistenten
- GEMINI.md — verwendet von Google Gemini Code Assist
- copilot-instructions.md — verwendet von GitHub Copilot
Alle folgen demselben Prinzip: Eine Markdown-Datei fungiert als persistenter Systemprompt für ein Repository oder Projekt.[6]
Geschichteter Kontext (Layered Context)
Ein wiederkehrendes Architekturmuster in der Praxis ist die Schichtung von Kontext in mehrere Ebenen mit abnehmender Allgemeinheit:[7]
| Ebene | Inhalt | Lebensdauer | Beispiel |
|---|---|---|---|
| Global | Identität, Konventionen, Arbeitsstil | Dauerhaft | CLAUDE.md, Systemdateien |
| Projekt | Domänenkontext, Projektstatus | Projektdauer | README.md, Statusdateien |
| Aufgabe | Spezifische Dateien, Werkzeuge | Sitzungsdauer | Einzelne Dokumente, Skills |
Dieses Muster wurde unabhängig von mehreren Praktikern beschrieben,[8][9] darunter Teresa Torres (Autorin von Continuous Discovery Habits), die ein vergleichbares dreischichtiges System aus Obsidian, Markdown-Dateien und Claude Code beschrieb.[10][11]
Es weist strukturelle Parallelen zum Drei-Speicher-Modell der Kognitionspsychologie auf (Arbeitsgedächtnis, episodisches Gedächtnis, semantisches Gedächtnis nach Tulving).[12]
Anwendung: Knowledge Operating System
Als Knowledge Operating System (kurz Knowledge OS) wird ein strukturiertes, versioniertes Wissens-Repository bezeichnet, das sowohl menschliches Denken als auch LLM-Kontext bedient. Der Begriff entstand ab 2025 in der Praxis von Wissensarbeitern, die bestehende Konzepte des Personal Knowledge Management (PKM) mit LLM-Kontextarchitektur verbanden.[13]
Ein Knowledge OS unterscheidet sich von klassischen PKM-Systemen (wie Zettelkasten, Getting Things Done oder Tiago Fortes Second Brain) durch zwei Merkmale:[14]
- Duale Leserschaft — Die Inhalte sind sowohl für den Menschen als auch für maschinelle Verarbeitung durch LLMs optimiert.
- Kontextarchitektur — Die Struktur folgt nicht nur einer Ordnungslogik (wie PARA), sondern einer Ladestrategie: Welcher Kontext wird wann in welcher Granularität dem LLM bereitgestellt.
Typische Implementierungen verwenden Markdown-Dateien in einem Git-versionierten Repository, verwaltet über Werkzeuge wie Obsidian oder Visual Studio Code, und angebunden an LLM-Clients wie Claude Code, Cursor oder GitHub Copilot.[10][5]
Verwandte Konzepte
| Konzept | Urheber | Jahr | Beziehung zu Knowledge OS |
|---|---|---|---|
| Memex | Vannevar Bush | 1945 | Hypothetisches Gerät zum Speichern und Verknüpfen persönlichen Wissens |
| Zettelkasten | Niklas Luhmann | ab 1951 | Verzettelungssystem mit atomaren, verlinkten Notizen |
| Getting Things Done | David Allen | 2001 | Aufgabenverwaltung durch externalisierte Systeme |
| Second Brain / PARA | Tiago Forte | 2017 | Digitale Notizorganisation nach Handlungsrelevanz |
| Evergreen Notes | Andy Matuschak | ca. 2019 | Konzeptorientierte, evolvierende Notizen |
| Digital Garden | diverse (u. a. Maggie Appleton) | ca. 2020 | öffentliche, wachsende Wissenssammlungen |
Herausforderungen
Philipp Schmid und Praktiker benennen wiederkehrende Probleme:[1]
- Kontextüberlastung — Mehr Kontext verbessert die Ergebnisse nicht linear; ab einem Schwellenwert sinkt die Qualität.
- Wartungsschulden — Veralteter Kontext kann das LLM aktiv in die Irre führen. Lebendige Systeme erfordern kontinuierliche Pflege.
- Automatisierungsparadox — Der Aufbau eines zeitsparenden Systems erfordert zunächst erheblichen Zeitaufwand.
- Transfergrenzen — Kontextsysteme, die für eine Person funktionieren, sind nicht ohne Weiteres auf andere oder auf Teams übertragbar.
Forschung
Die akademische Forschung an der Schnittstelle von Wissensmanagement und LLMs befindet sich im Frühstadium. Erste systematische Übersichten erschienen ab 2025:
- Kirchner (2025) untersuchte den Einsatz generativer KI im Wissensmanagement von Softwareentwicklungsteams.[15]
- Eine systematische Literaturuebersicht von 63 Studien analysierte den Einsatz von RAG und LLMs im Unternehmens-Wissensmanagement.[16]
Ein frühes Beispiel für den Begriff Knowledge Operating System in der Informatik ist das KnowOS-Projekt von Travers, Massar und Shrager (2005), ein Common-Lisp-Framework für Bioinformatik, das auf Arbeiten für die NASA zurückging.[17]