Prompt-, Kontext-, Harness- und Loop-Engineering: Die vier Schichten eines KI-Agenten
Prompt Engineering und Context Engineering umfassen zwei der vier Ebenen. Was Harness- und Loop-Engineering steuern, ein Beispiel für Triage bei GitHub sowie die Build-Reihenfolge.
Quellen: Prompt, context, harness, loop: the four layers of engineering an AI agent
Mitte 2025 schrieb Shopify-CEO Tobi Lütke, dass die eigentliche Fähigkeit bei der Arbeit mit KI-Modellen keineswegs im Prompt-Engineering lag, sondern darin, ausreichend Kontext bereitzustellen, damit die Aufgabe plausibel gelöst werden konnte. Andrej Karpathy stimmte zu und bezeichnete dies als eine Kunst, bei der genau die richtigen Informationen in das Kontextfenster eingefügt werden müssen, je nachdem, was das Modell als Nächstes tun soll. Kurz darauf hatte sich „Kontext-Engineering“ in den meisten ernsthaften Diskussionen über die Nutzung von KI-Modellen anstelle von „Prompt-Engineering“ durchgesetzt.
Ein Jahr später stoßen die Teams, die autonome Programmieragenten, Problemanalyse-Bots sowie selbstheilende Bereitstellungs pipelines entwickeln, weiterhin auf dieselben Hindernisse. Es stellte sich heraus, dass der Kontextaufbau nur ein Teil eines vielschichtigen Problems ist. Von der engsten bis zur breitesten Schicht sind das der Prompt, der Kontext, die Infrastruktur und der Schleifenmechanismus – wobei jede Schicht die darunterliegende umfasst. Die beiden äußeren Schichten, die Infrastruktur- und der Schleifenmechanismus, erhalten am wenigsten Aufmerksamkeit, was seltsam ist, denn genau dort liegt heute der größte Nutzen.
Betrachten Sie es als vier Fragen: Wie ist die Anfrage formuliert? Das ist der Prompt. Was weiß das Modell bereits zu Beginn? Das ist der Kontext. Was kann es tatsächlich nach dem Start tun? Das ist die Infrastruktur. Und wann sowie wie oft wird es aufgerufen? Das ist der Schleifenmechanismus. Heute liegt der größte tatsächliche Nutzen in der Schleifenmechanismus-Schicht – einer Schicht, die vor einem Jahr kaum einen Namen hatte.
Was folgt, ist ein funktionsfähiges Rahmenwerk zur Unterscheidung der Schichten sowie eine Reihenfolge für den Aufbau. Es setzt voraus, dass Sie bereits Tools oder Funktionen über eine LLM-API aufgerufen haben. Falls nicht, beginnen Sie dort.
In der Praxis zeigt sich ein Muster, das erklärt, warum dieses Rahmenwerk nützlich ist. Wenn die Ausgabe eines Agents enttäuschend ist, liegt die Lösung fast nie im Prompt – sie befindet sich fast immer in einer höheren Schicht.
Schicht 1: der Prompt, also das, was Sie sagen
Die Prompt-Entwicklung ist die engste Schicht und befasst sich mit einer einzigen Sache: der Formulierung einer Anweisung an das Modell.
Beispiele: Wie ein Systemprompt formuliert wird, wie ein Few-Shot-Beispiel dargestellt wird, ob Sie schrittweises Denken oder sorgfältige Abwägung verlangen, sowie ob die Antwort als JSON oder als freier Text zurückgegeben werden soll. Es handelt sich dabei um die Kunst, eine Nachricht zu verfassen, die das Modell dazu bringt, in seinem nächsten Schritt das zu tun, was Sie wollen.
Die Arbeit ist real. Die Genauigkeit bei derselben Aufgabe kann zwischen einer vagen Anweisung und einer präzisen erheblich unterschiedlich sein. Nehmen wir als laufendes Beispiel einen Triage-Agenten für ein GitHub-Projekt. Ein schwacher Prompt sieht so aus:
Look at this GitHub issue and label it.
Und eine präzise:
You are a triage agent for project X. For each issue, output JSON with:
component (one of the values in the taxonomy provided in context)
severity (critical | high | medium | low)
team (the owning team from the on-call table provided in context)
Base severity only on user-facing impact stated in the issue, not on your
own guess about difficulty. If the component is ambiguous, set
"component": "unknown" rather than guessing.
Das Modell, die Tools und alles andere sind identisch, doch der zweite Prompt liefert strukturierte, nachvollziehbare Ergebnisse. Man sollte jedoch bedenken, was hier als selbstverständlich angesehen wird: Die Verarbeitung findet innerhalb einer einzigen Anfrage und eines einzigen Schritts statt. Dabei wird vorausgesetzt, dass die Taxonomie sowie die Tabelle der verfügbaren Tools bereits geladen sind und dass eine andere Komponente entscheidet, wann das Modell aufgerufen wird.
Die meisten Tutorials enden an diesem Punkt. Die meisten produktiven Agentensysteme haben hier gerade erst begonnen.
Schicht 2: Der Kontext – oder was das Modell weiß
Der Kontextaufbau umfasst alles, was vor der Verarbeitung des Prompts in den Blickfeld des Modells gelangt. Er steht oberhalb der eigentlichen Prompt-Verarbeitung. Selbst ein perfekter Prompt erzeugt unsinnige Ergebnisse, wenn der Kontext falsch ist.
Dazu gehören welche Dokumente, Code-Dateien oder Datenbankdaten abgerufen und eingespeist werden, welche Tool-Schemata geladen werden und welche zurückgehalten werden, um Tokens zu sparen, wie viel des Gesprächsverlaufs erhalten bleibt im Vergleich dazu, dass er zusammengefasst oder weggelassen wird, sowie was die Systemanweisungen über die Rolle und Grenzen des Modells sagen.
Drew Breunig hat im Jahr 2025 die Ursachen für Fehlfunktionen des Kontexts aufgelistet. Kontextvergiftung tritt auf, wenn eine Halluzination in den Kontext eindringt und ständig darauf Bezug genommen wird. Kontextstörung entsteht, wenn ein zu langer Kontextbereich dazu führt, dass das Modell sich darauf verlässt und das Vergessene aus der Trainingsphase ignoriert. Kontextverwirrung entsteht, wenn irrelevante Materialien die Qualität der Ausgabe verschlechtern. Kontextkonflikte entstehen, wenn neu hinzugefügte Tools oder Fakten mit bestehenden Anweisungen im Widerspruch stehen.
Der Kontext kostet ebenfalls Geld, und seine Kodierung beeinflusst die Rechnung. Laut Angaben verwendet TOON, eine kompakte Kodierung des JSON-Datenschemas, bis Mitte 2026 in seinem eigenen Benchmark-Set etwa 42,6 Prozent weniger Token als JSON, wobei die Abrufgenauigkeit auf einem ähnlichen Niveau liegt (72,2 Prozent gegenüber 71,4 Prozent). Die Einsparung hängt von der Struktur der Daten ab: Bei flachen tabellarischen Daten liegt der Anteil der Einsparung bei fast 59 Prozent, bei gemischten, verschachtelten Daten bei etwa 33 Prozent, und reines CSV kann beide Formate übertreffen, wenn die Daten rein flach sind. Das sind die eigenen Angaben des Projekts – überprüfen Sie sie daher anhand Ihrer Daten. Fazit: Dasselbe Datensatz, in drei verschiedenen Formaten dargestellt, unterscheidet sich in Bezug auf Kosten sowie bei der Zuverlässigkeit der Wiederauslesung. Kontextengineering bedeutet also, nicht nur zu entscheiden, was einbezogen werden soll, sondern auch, wie es kodiert werden soll.
Eine kurze Illustration zeigt, wie das schiefgehen kann. Stellen Sie sich einen Artikelgenerierungs-Agenten vor, der ständig generische Ergebnisse liefert. Zwei Tage werden damit verbracht, den Prompt umzuschreiben, Beispiele und Einschränkungen hinzuzufügen sowie die Rolle des Agenten genauer zu definieren – doch es passiert nichts. Der Prompt war nie das Problem. Dreißig Tool-Schemata werden im Voraus in den Kontext geladen und übertönen die relevanten Anweisungen. Durch den Wechsel zum „lazy loading“, bei dem eine Definition erst dann angezeigt wird, wenn der Agent danach fragt, verbessert sich die Qualität, ohne dass ein Wort des Prompts geändert werden muss. Zwei Tage wurden an der falschen Ebene verschwendet.
Während das Prompt-Engineering dazu dient, die richtigen Worte auszuwählen, sorgt das Context-Engineering dafür, dass das Modell bereits vor dem Aussprechen von Worten etwas sehen kann.
Ebene 3: das Umfeld, oder was das Modell tun kann
Das Umfeld ist die ausführbare Umgebung um das Modell herum: alles, worauf es zugreifen kann, und alles, was auf es zugegriffen werden kann.
Anthropics bekannte Leitlinien zur Erstellung effektiver Agenten führten die Idee einer Agent-Computer-Schnittstelle ein, die bewusst der Mensch-Computer-Schnittstelle parallel ist. Die Begründung dahinter ist, dass man genauso viel Aufwand in die Gestaltung der Weise investieren sollte, wie ein Agent mit Werkzeugen arbeitet, wie die Branche in die Gestaltung der Weise, wie Menschen mit Software arbeiten.
Hier ist eine vereinfachte Definition eines Werkzeugs aus dem Triage-Beispiel:
{
"name": "apply_label",
"description": "Apply a label to a GitHub issue. Only use after reading the issue body and checking the component taxonomy.",
"parameters": {
"type": "object",
"properties": {
"issue_number": { "type": "integer" },
"labels": { "type": "array", "items": { "type": "string" } }
},
"required": ["issue_number", "labels"]
}
}
Das Feld description übernimmt Aufgaben im Kontext. Es bestimmt, wann das Modell auf das Tool zugreift, und nicht nur, welche Argumente es übermittelt. Doch das Schema ist nur die Hälfte des „Harnesses“.
Die andere Hälfte befindet sich im Orchestrator, der das Tool in Elemente hüllt, die das Modell niemals sieht. Eine Genehmigungsstufe entscheidet, ob apply_label automatisch ausgeführt wird oder in eine Warteschlange für einen Menschen kommt. Eine Geschwindigkeitsbeschränkung, beispielsweise 60 Etiketten-Einträge pro Stunde, verhindert, dass ein unkontrollierter Kreislauf das Repository überflutet. Eine Sandbox-Grenze begrenzt, was das Tool erreichen kann. Solche Wrapper formen das Verhalten, ohne dass der Systemprompt geändert werden muss.
Ein „Harness“ umfasst außerdem:
- Dateisystem. Welche Dateien das Modell öffnen, bearbeiten, erstellen oder löschen darf.
- Speicher. Wie Informationen über verschiedene Schritte hinweg gespeichert und abgerufen werden, beispielsweise Korrekturlisten, frühere Entscheidungen und Projektkonventionen.
Bieten Sie einem durchschnittlichen Prompt gute Werkzeuge, dann wird er in der Regel besser abschneiden als ein brillanter Prompt ohne Werkzeuge. Ein Agent, der die benötigte Datei nicht öffnen kann, profitiert nicht von besseren Formulierungen. Zuerst die Werkzeuge bereitstellen.
Layer 4: der Loop – oder was einen Agenten ausmacht
Die Loop-Engineerung ist das Mechanismus, der einen Agenten autonom macht. Er handelt, beobachtet das Ergebnis, entscheidet, was als Nächstes zu tun ist, und setzt dies fort, bis ein Ziel erreicht oder eine Stoppsbedingung ausgelöst wird – ohne dass bei jedem Schritt eine menschliche Anweisung erforderlich ist. Diese Schicht verwandelt einen chatbasierten Tool-Nutzer in etwas, das Probleme eigenständig lösen kann.
Hier ist dieselbe Idee in Pseudocode dargestellt. Es handelt sich dabei um eine Veranschaulichung, die nicht ausführbar ist: Hilfsfunktionen wie model.decide und execute werden weggelassen.
def agent_loop(goal, max_iterations=10):
context = gather_initial_context(goal)
consecutive_errors = 0
for i in range(max_iterations):
action = model.decide(context, goal)
if action.type == "done":
return action.result
result = execute(action)
if result.error:
consecutive_errors += 1
if consecutive_errors >= 3:
# stuck: same approach keeps failing, decompose differently
context.add("Previous approach failed 3 times. Try a different strategy.")
consecutive_errors = 0
else:
consecutive_errors = 0
context.add(result)
return escalate_to_human(context)
Nur wenige Zeilen enthalten die entscheidenden Anweisungen: Wann man aufhören soll, wann man die Strategie ändern muss und wann man aufgeben sollte. OpenAI integrierte dieses Muster in ein Produkt, als es im April 2026 den Befehl /goal zur Codex CLI hinzufügte. Man legt ein Ziel fest, und das System wiederholt die Schritte, bis es das Ziel für erfüllt hält oder das Tokenbudget aufgebraucht ist.
Eine naive Schleife versucht es immer wieder, bis etwas funktioniert. Eine gut konzipierte Schleife erkennt, dass sie feststeckt, zerlegt das Problem auf andere Weise, wendet sich an einen Menschen oder gibt einen fehlerhaften Ansatz auf. Der Designer Matt Webb bemerkte im März 2026, dass ein Agent, dem ein Problem und eine while-Schleife gegeben werden, es letztendlich lösen wird. Der Zusatz „letztendlich“ zeigt, wo die Ingenieurskunst liegt: Versuchszahlen, Verzögerungen nach wiederholten Fehlern sowie Strategien zur Aufteilung des Problems, falls eine einzige Durchführung ins Stocken gerät.
Deshalb stellt diese Schicht den größten Machtwechsel dar. Bei der Prompt-Engineering-Methodik schreibt eine Person jede Anweisung. Bei der Context-Engineering-Methodik entscheidet eine Person, was das Modell bei jedem Aufruf sieht. Bei der Harness-Engineering-Methodik baut eine Person die Tools einmal und das Modell nutzt sie unbegrenzt wieder. Das Loop-Engineering unterscheidet sich in seiner Art: Eine Person entwirft ein System, das das Modell anleitet, das Ergebnis bewertet und es erneut aufruft – ohne dass jemand im Raum ist. Die Kontrolle wechselt von der Person, die den Agenten anleitet, zur Person, die das System zur Anleitung entwickelt hat.
Jon Udell schlug Mitte 2026 eine Formulierung vor, die man beibehalten sollte: Er missfällt der Ausdruck „Mensch im Kreislauf“, weil er die Autorität den Maschinen überlässt, obwohl es eigentlich immer noch unser Kreislauf ist und wir nun Agenten rekrutieren, um dem Team beizutreten.
Alle vier Schichten in einem Agenten: GitHub-Issue-Triage
Stellen Sie sich einen Agenten vor, der sich mit neuen GitHub-Beschwerden für ein mittelgroßes Open-Source-Projekt befasst: Er kennzeichnet die Komponente, bewertet die Schweregrad und leitet jede Beschwerde an das richtige Team weiter.
- Aufforderung. Die Systemaufforderung weist ihn an, die betroffene Komponente zu finden, den Schweregrad von kritisch bis gering einzustufen, das richtige Team zuzuweisen und mit strukturiertem JSON zu antworten.
- Kontext. Für jede Entscheidung liefert das System den Titel und den Inhalt, die fünf neuesten Kommentare, die Taxonomie der Komponenten (eine quartalsweise überarbeitete YAML-Datei), frühere ähnliche Probleme mit ihren Labels (als Beispiele über Vektorabfragen abgerufen) sowie den diensthabenden Mitarbeiter.
Jede 100 Ausgaben vergleicht das System seine Genauigkeit mit menschlichen Korrekturen und passt seine Schwellenwerte an. In einem vergleichbaren System musste der Vertrauensschwellenwert angeblich bei 0,85 beginnen und nicht bei dem angenommenen 0,7, weil falsche Etiketten mehr menschliche Arbeit verursachten als fehlende. Diese Art der Kalibrierung ist Loop-Engineering: Man findet sie nur, indem man das System laufen lässt und seine Fehler im Laufe der Zeit beobachtet.
Nehmt man eine Schicht weg, versagt es auf andere Weise. Ohne Anweisung ist das Ausgabeformat nur eine Schätzung. Ohne Kontext werden Komponentennamen erfunden. Ohne Hilfsmittel kann es herausfinden, was zu tun ist, aber nicht etikettieren oder suchen. Ohne Schleife bleibt ein Assistent übrig, der nur dann handelt, wenn jemand nacheinander „Diese Angelegenheit priorisieren“ in ein Chat-Fenster eingibt.
Woher das Vokabular stammt
Der Begriff „Prompt Engineering“ stammt aus dem Jahr 2022. Riley Goodside schlug bereits 2023 vor, ihn in „Context Engineering“ und „Prompt Programming“ aufzuteilen, doch das Vokabular setzte sich erst durch, nachdem Lütke und Karpathy im Juni 2025 „Context Engineering“ verwendeten und Simon Willison erklärte, warum es besser passte.
„Harness“ und „Scaffolding“ wurden durch die Arbeiten von Anthropic zu effektiven Agenten standardmäßig verwendet, wodurch die Agent-Computer-Schnittstelle formalisiert und die Tool-Entwicklung als erstklassige Ingenieurtechnik betrachtet wurde.
Loop-Engineering ist das jüngste der vier Ansätze, und niemand hat diesen Begriff geprägt. Es entstand aus der Konvergenz mehrerer Entwicklungen: OpenAI’s zielorientierte Schleifen in Codex, Anthropics Unterscheidung zwischen Arbeitsabläufen (festgelegte Pfade) und Agenten (von dem Modell gesteuerte Schleifen), LangChain’s Ausbau von Routern über Zustandsmaschinen bis hin zu autonomen Agenten sowie die zunehmende Praxis, dass der Mensch die Schleife entwirft und sich aus ihren einzelnen Schritten heraushält.
Die hier dargestellte Vier-Ebenen-Einteilung ist eine Synthese dieser konvergierenden Anwendungen und kein Branchenstandard. Dennoch beschleunigt die Benennung der Ebenen die Diagnose. Die Frage, ob ein Problem auf den Prompt, den Kontext, das Harness oder die Schleife zurückzuführen ist, eingrenzt die Suche sofort.
Wo man zuerst investieren sollte
Die Ebenen wurden von der engsten zur breitesten aufgelistet, doch man baut sie eigentlich von der breitesten aus – genauer gesagt zuerst das Harness. Für einen ersten autonomen Programmieragenten ist die Reihenfolge wie folgt.
- Umgebung.** Es müssen Funktionen für das Lesen und Schreiben von Dateien, Zugriff auf die Shell, Möglichkeiten zum Ausführen von Tests sowie Git-Befehlen bereitgestellt werden. Ein nicht programmierender Agent erhält stattdessen API-Aufrufe, Datenbankabfragen oder Messaging-Funktionen – die Idee bleibt dieselbe.
- Schleife.** Schon eine einfache Schleife hilft: Ausführen, prüfen, ob die Tests bestehen, bei Fehlern einen Fehler zurückgeben und nach drei Versuchen oder bei Erfolg beenden. Allein das bringt bereits den größten Teil des Vorteils der Autonomie.
- Kontext.** Nachdem man beobachtet hat, wie der Agent in seiner Schleife arbeitet, erkennt man, was ihm fehlt – sei es Code, frühere Fehler oder Projektkonventionen. Im Voraus zu raten, kostet meist nur Zeit.
- Aufforderungen.** Mit einer funktionierenden Umgebung und Schleife sind die benötigten Aufforderungen in der Regel kurz und einfach. Die schwierigen ingenieurtechnischen Aspekte wurden zu diesem Zeitpunkt bereits erledigt.
Es gibt eine Ausnahme. Wenn der Agent eine präzise formatierte Ausgabe liefern muss, wie beispielsweise strukturierte JSON-Daten für eine API oder bestimmte Markdown-Konventionen, ist die Gestaltung der Anweisungen bereits früh entscheidend, da eine Formatkonformität im Laufe des Prozesses schwer zu korrigieren ist. Das ist ein Sonderfall, nicht die Norm.
Neulinge wechseln in der Regel die Reihenfolge. Wochenlang werden aufwendige Systemanweisungen entwickelt, während der Agent noch keine Werkzeuge, keinen Schleifenmechanismus und falsche Dateien in seinem Kontext hat.
Der Übergang von der Anweisungsformulierung zur Kontextgestaltung bedeutet, anzuerkennen, dass das dem Modell bereitgestellte Material wichtiger ist als die Formulierung der Anfrage. Der weitere Schritt zur Nutzung von Schleifenmechanismen bedeutet noch mehr: Wer das System um das Modell herum entwickelt, hat mehr Macht als wer mit ihm kommuniziert.
Verwandte Artikel
- Agentic Context Engineering: Ein Schritt-für-Schritt-Leitfaden für ML-Entwickler: Wie man festlegt, was ein LLM-Agent bei jedem Schritt sieht – Recherche, strukturierter Kontext, Speicherung, Kompression und Bewertung – anhand eines Beispiels mit einem ML-Debugging-Agenten.
- Von Zero-Shot zu Selbstkonsistenz: Eine praktische Leiter an Prompting-Techniken: Wie man zwischen Zero-Shot-, Few-Shot-, Dekompositions-, Kritikschleifen- und Reasoning-Prompts wählt, anhand eines Beispiels mit einem Support-Bot, sowie wann man die Aufgabe lieber an reine Code-Lösungen abgibt.