Grundlagen · Arbeitsweise
Prompt, Kontext, Harness, Loop:
vier Ebenen, ein System.
Seit einem Jahr kommen im Monatstakt neue Begriffe dazu: erst Context Engineering, dann Harness Engineering, inzwischen Loop Engineering. Der Verdacht liegt nahe, dass jemand alten Wein in neue Schläuche füllt. Er stimmt nicht ganz. Die vier Begriffe beschreiben vier verschiedene Stellschrauben, und in Projekten entscheidet die Frage, an welcher man gerade drehen muss.
Woher die Begriffsflut kommt
2022 war ein LLM-Projekt ein Textfeld und eine Antwort. Alles, was man beeinflussen konnte, stand im Prompt, also hieß die Disziplin Prompt Engineering. Heute läuft ein Agent zwanzig Minuten, ruft dabei vierzig Werkzeuge auf, schreibt Dateien, liest sie wieder ein und entscheidet selbst, wann er fertig ist. Der Prompt ist davon ein Bestandteil unter vielen.
Die neuen Begriffe benennen die Stellen, die dazugekommen sind. Sie liegen ineinander: Jede Ebene setzt die darunter voraus und bestimmt deren Spielraum.
Ebene 1: Prompt Engineering
Formulierung
Wie die Aufgabe gestellt wird
Stellschraube: Wortlaut, Rolle, Beispiele, Format · Wirkung: innerhalb eines Aufrufs
Rollenangabe, Aufgabenbeschreibung, Ausgabeformat, ein paar Beispiele, gegebenenfalls die Aufforderung, den Rechenweg auszuschreiben. Das ist die älteste und am besten verstandene Ebene, und sie ist keineswegs erledigt: Ein präzise gestellter Auftrag schlägt einen vagen auch bei den stärksten Modellen.
Ihre Grenze ist die Reichweite. Ein Prompt beeinflusst einen Aufruf. Sobald das System zehn Aufrufe hintereinander macht und der zehnte auf dem Ergebnis des dritten aufsetzt, ist die Formulierung des ersten nur noch ein kleiner Teil der Erklärung dafür, was am Ende herauskommt.
Das ist auch der Grund, warum Prompt-Sammlungen selten übertragbar sind. Sie beschreiben eine Ebene, deren Wirkung von den drei darüberliegenden abhängt.
Ebene 2: Context Engineering
Auswahl
Was im Kontextfenster steht, wenn das Modell antwortet
Stellschraube: Retrieval, Kompaktierung, Notizen, Werkzeugausgaben, Subagenten · Wirkung: über einen Lauf
Anthropic beschreibt das Ziel als „die kleinste Menge hochwertiger Token, die das gewünschte Ergebnis wahrscheinlich macht“. Der Kontext ist ein knappes Gut, und zwar nicht nur wegen der Kosten. Mit wachsender Füllung sinkt die Trefferquote im gefüllten Fenster, ein Effekt, der als Context Rot beschrieben wird. Effective context engineering for AI agents.
Die Werkzeuge dieser Ebene sind inzwischen gut beschrieben:
- Kompaktierung. Beim Anlaufen an die Grenze wird der Verlauf zusammengefasst, wobei Architekturentscheidungen, offene Fehler und Implementierungsdetails erhalten bleiben und redundante Werkzeugausgaben herausfallen.
- Notizen außerhalb des Fensters. Der Agent schreibt in eine Datei, statt alles im Kontext zu halten. In Anthropics Pokémon-Beispiel trägt das über tausende Spielzüge.
- Subagenten. Ein eigener Agent mit sauberem Kontextfenster erledigt eine Teilaufgabe und liefert eine Zusammenfassung von typischerweise 1.000 bis 2.000 Token zurück. Die Detailarbeit belastet den Hauptkontext nicht.
- Nachladen statt Vorladen. Der Agent hält Dateipfade und Suchanfragen statt Inhalte und lädt zur Laufzeit gezielt nach.
Diese Ebene ist in RAG-Projekten der Ort, an dem die meiste Zeit hängen bleibt. Chunking, Ranking und die Frage, wie viele Treffer man tatsächlich mitgibt, sind Context Engineering, auch wenn im Projekt niemand das Wort benutzt.
Ebene 3: Harness Engineering
Umgebung
Was das Modell anfassen kann und was mit seiner Ausgabe passiert
Stellschraube: Werkzeuge, Rechte, Sandbox, Dateisystem, Verifikationsskripte · Wirkung: über alle Läufe
Das Harness ist der Apparat um das Modell herum. Welche Werkzeuge es gibt und wie sie geschnitten sind, was ausgeführt werden darf und was erst nach Rückfrage, wo der Lauf stattfindet, was protokolliert wird und woran ein schlechtes Ergebnis auffällt. Claude Code, Cursor und jeder selbstgebaute Agent sind Harnesses, ob man sie so nennt oder nicht.
Anthropic hat für lange Läufe einen Aufbau beschrieben, der die Wirkung dieser Ebene gut zeigt: Ein Initialisierungsagent legt einmalig eine Merkmalsliste mit über 200 Einträgen an, jeder mit Testschritten und einem Erledigt-Kennzeichen. Ein zweiter Agent arbeitet danach in jeder Sitzung mit frischem Kontext ein einzelnes Merkmal ab, liest zu Beginn Git-Log und Fortschrittsdatei und prüft am Ende über Browserautomatisierung nach, ob es tatsächlich funktioniert. Effective harnesses for long-running agents.
Kein Wort davon betrifft die Formulierung des Prompts. Es geht um Dateien, Skripte, einen Startbefehl und die Frage, woran das System merkt, dass es sich irrt.
Der Werkzeugschnitt gehört ebenfalls hierher und wird oft unterschätzt. Wenn ein Mensch beim Blick auf die Werkzeugliste nicht sicher sagen kann, welches Werkzeug für einen bestimmten Fall zuständig ist, wird das Modell es auch nicht können. Zwei überlappende Werkzeuge sind schlechter als eines mit einem Parameter.
Ebene 4: Loop Engineering
Regelkreis
Wann das Modell erneut aufgerufen wird und wann Schluss ist
Stellschraube: Abbruchbedingung, Prüfsignal, Wiederholung, Eskalation an den Menschen · Wirkung: über den Betrieb
Die äußerste Ebene. Sie entscheidet, was als erledigt gilt, wie oft nachgebessert wird, was bei einem Fehlschlag passiert und an welcher Stelle ein Mensch gefragt wird. Das ist die Ebene, auf der ein Agent von einer Demo zu etwas wird, das man laufen lassen kann.
Die entscheidende Größe hier ist die Qualität des Prüfsignals. Ein Agent, der seine Arbeit gegen eine Testsuite prüfen kann, verbessert sich über Iterationen. Ein Agent, dessen einziges Prüfsignal seine eigene Einschätzung ist, iteriert sich in die Zuversicht hinein. Genau deshalb steht in Anthropics Aufbau die Anweisung, dass es unzulässig ist, Tests zu löschen oder zu ändern: Der Weg des geringsten Widerstands zum Grün ist sonst der Test, nicht der Code.
In meinem Weltmodell-Projekt ist mir derselbe Mechanismus in kleinerem Maßstab begegnet. Der Planer bewertete Handlungsfolgen mit einem gelernten Modell, und das Modell erfand Belohnungen, wo keine waren. Das Ergebnis sah besser aus als die Wirklichkeit, weil das Prüfsignal aus derselben Quelle stammte wie die Handlung. Der Beitrag dazu.
Die vier Ebenen nebeneinander
| Ebene | Was verändert wird | Leitfrage | Reichweite |
|---|---|---|---|
| Prompt | Wortlaut, Beispiele, Format | Versteht das Modell die Aufgabe? | ein Aufruf |
| Kontext | Auswahl und Verdichtung der Token | Sieht das Modell das Richtige? | ein Lauf |
| Harness | Werkzeuge, Rechte, Umgebung | Kann das Modell handeln, und fällt Unsinn auf? | alle Läufe |
| Loop | Iteration, Abbruch, Prüfsignal | Woran merkt das System, dass es fertig ist? | der Betrieb |
Die Ebenen konkurrieren nicht. Man kann auf keiner von ihnen ausgleichen, was auf einer anderen fehlt. Ein hervorragender Prompt rettet kein Harness ohne Prüfmöglichkeit, und ein sauber gebauter Loop bringt nichts, wenn im Kontext die falschen Dokumente stehen.
Vier Ebenen, ineinander
Die Ebenen liegen nicht nebeneinander, sondern ineinander. Jede äußere umschließt die inneren und setzt ihnen den Rahmen: Der Loop bestimmt, wie oft das Harness überhaupt anläuft, das Harness bestimmt, welcher Kontext zusammenkommt, und der Kontext bestimmt, worauf ein Prompt sich beziehen kann.
Daraus folgt die Reihenfolge beim Suchen: Ein Fehlerbild, das sich innen zeigt, hat seine Ursache oft weiter außen. Wenn das Modell nach zwanzig Minuten schlechter wird, ist selten der Prompt schuld, sondern der Kontext. Wenn ein Fehler erst dem Menschen auffällt, der das Ergebnis liest, fehlt im Harness eine Prüfmöglichkeit. Und wenn der Agent für erledigt erklärt, was nicht erledigt ist, liegt es am Loop.
Der häufigste Fall liegt allerdings außerhalb aller vier Kreise. Ohne einen Satz fester Testfälle, gegen den man vorher und nachher misst, ist jede Arbeit auf allen vier Ebenen Meinungssache. Zwanzig echte Aufgaben aus dem eigenen Betrieb mit bekannten Antworten reichen für den Anfang, und sie sind an einem Nachmittag geschrieben.
Wo die Aufteilung ausfranst
Die Grenze zwischen Harness und Loop ist die unschärfste. Ob ein Wiederholungsversuch nach einem fehlgeschlagenen Werkzeugaufruf zum Harness gehört oder zum Loop, lässt sich in beide Richtungen begründen, und verschiedene Autoren tun genau das. Wer Graph Engineering dazuzählt, für fest verdrahtete Abläufe zwischen mehreren Agenten, hat eine fünfte Ebene, die sich mit Loop überschneidet.
Für den Sprachgebrauch heißt das: Die Begriffe taugen als Landkarte, nicht als Katalog. Wer sie in einer Ausschreibung liest, sollte nachfragen, was gemeint ist. Wer sie im eigenen Team benutzt, sollte einmal festlegen, wo die Grenzen liegen sollen, und danach dabei bleiben.
Was das praktisch heißt
Drei Beobachtungen aus Projekten, in denen alle vier Ebenen vorkamen.
Erstens wird auf Ebene 1 zu viel Zeit verbraucht. Prompts sind das Einzige, woran alle im Team ohne Vorbereitung mitarbeiten können, also wird dort gearbeitet, auch wenn das Problem woanders sitzt. Ein halber Tag am Werkzeugschnitt bringt in solchen Fällen mehr als eine Woche am Systemprompt.
Zweitens kauft man mit einem fertigen Werkzeug immer die Ebenen 3 und 4 mit ein. Wer Claude Code einsetzt, übernimmt dessen Werkzeugsatz, dessen Berechtigungsmodell und dessen Vorstellung davon, wann ein Auftrag erledigt ist. Das ist bequem und der Grund, warum ein Wechsel des Werkzeugs mehr verändert als ein Wechsel des Modells.
Drittens liegt der Hebel für Verlässlichkeit fast immer auf Ebene 3 und 4. Ein Agent wird nicht dadurch zuverlässig, dass er bessere Sätze liest, sondern dadurch, dass sein Irrtum auffällt, bevor er Wirkung entfaltet. Das ist Infrastrukturarbeit und sieht in keiner Demo gut aus.
Zum Nachlesen
- Anthropic: Effective context engineering for AI agents, 29. September 2025
- Anthropic: Effective harnesses for long-running agents
- codecentric: Loop, Harness, Context Engineering: The Terms Explained
Die vier Ebenen am eigenen System durchgehen
In meinen Schulungen zeige ich die Ebenen an laufenden Systemen statt an Folien, und wir klären für Ihren Fall, welche davon gerade begrenzt. 30 Minuten Erstgespräch, kostenlos.