Harness vs Context Engineering: worin sich Harness Engineering von Prompt- und Context-Engineering unterscheidet

Kurz gesagt: drei Ebenen einer Aufgabe

Prompt-Engineering beantwortet die Frage „Wie frage ich?“, Context-Engineering die Frage „Was muss das Modell jetzt wissen?“, Harness-Engineering die Frage „In welcher Umgebung arbeitet der Agent, und wie erfährt er, dass er einen Fehler gemacht hat?“. Das sind keine konkurrierenden Ansätze, sondern verschachtelte Ebenen: Ein guter Prompt ist Teil eines guten Kontexts, und ein durchdachter Kontext ist eines der Teilsysteme des Harness.

Verwirrung entsteht, weil alle drei das Verhalten des Modells beeinflussen, aber mit unterschiedlichen Hebeln. Kann der Agent die Tests nicht starten, behebt keine Formulierung des Prompts dieses Problem. Vergisst der Agent die Entscheidungen von gestern, liegt das Problem nicht im Wortlaut der Anfrage, sondern darin, wo der Zustand gespeichert wird. Wer den Unterschied zwischen Harness und Context Engineering versteht, spart Wochen: Sie hören auf, Anweisungen umzuschreiben, wo die Umgebung kaputt ist.

Prompt-Engineering: die Formulierung einer einzelnen Anfrage

Prompt-Engineering ist die Arbeit am Text der Anfrage: Rolle, Aufgabe, Ausgabeformat, Beispiele (Few-Shot), Einschränkungen, Reihenfolge der Schritte. Die Arbeitseinheit ist ein Modellaufruf. Das Ergebnis wird an der Antwort gemessen: Ist sie korrekt, im richtigen Format, ist das Modell beim Thema geblieben?

Typische Techniken:

• das Ausgabeformat ausdrücklich beschreiben (JSON-Schema, Tabelle, Liste);
• 2 bis 3 Beispiele „Eingabe → richtige Ausgabe“ geben;
• um schrittweises Schlussfolgern vor der Antwort bitten;
• Anweisung und Daten durch klare Trennzeichen voneinander trennen;
• aufzählen, was nicht getan werden darf.

Prompt-Engineering funktioniert gut für Aufgaben „eine Eingabe — eine Ausgabe“: Klassifikation, Datenextraktion, Übersetzung, Textgenerierung nach einer Vorlage. Seine Grenze zeigt sich, wenn das Modell zu handeln beginnt: Werkzeuge aufruft, Dateien ändert, Dutzende Schritte hintereinander ausführt. Dort hängt die Qualität nicht mehr an einem einzelnen Satz, sondern an allem, was das Modell umgibt.

Context-Engineering: was in das Fenster des Modells gelangt

Context-Engineering bedeutet, den Inhalt des Kontextfensters bei jedem Schritt zu steuern. Das Fenster ist begrenzt, und der Agent sammelt bei einer langen Sitzung Befehlsausgaben, Dateiinhalte und den Gesprächsverlauf. Die Aufgabe ist, dass in jedem Moment das Nötige darin steht und nichts Überflüssiges.

Dazu gehören:

• Auswahl: welche Dateien, Dokumente und Codeausschnitte für die Aufgabe geladen werden (Suche, RAG, Lesen bei Bedarf);
• Verdichtung: Zusammenfassen einer langen Historie, Kürzen von Befehlsausgaben, Verdichten der Sitzung;
• Struktur: eine Einstiegsdatei mit Anweisungen als Inhaltsverzeichnis, die Details in eigenen Dokumenten, die der Agent bei Bedarf öffnet;
• Isolation: eine Teilaufgabe an einen Sub-Agenten mit eigenem sauberem Kontext abgeben, damit der Hauptstrang nicht verstopft.

Die Metrik des Context-Engineering ist, ob der Agent im richtigen Moment die richtige Regel oder Information gefunden hat und nicht im Rauschen untergegangen ist. Ein typisches Symptom: Eine Regel steht in der CLAUDE.md, doch der Agent verletzt sie, weil die Datei fünf Seiten umfasst und die Regel zwischen Tonfall und Lieblingsmustern des Teamleads verloren geht.

Harness-Engineering: alles um das Modell herum

Das Harness („das Zaumzeug“) ist die Umgebung, in der der Agent arbeitet. Das Modell ist darin nur eine Komponente, die einmal in den Kreislauf eintritt. Alles Übrige — Anweisungen, Werkzeuge, Umgebung, Zustand und Rückmeldung — entwirft ein Ingenieur. Harness-Engineering sorgt dafür, dass der Agent nicht nur Code schreiben, sondern ihn auch ausführen, prüfen, von einem Fehler erfahren und in der nächsten Sitzung an derselben Stelle weitermachen kann.

Praktisch ist es, das Harness in fünf Teilsysteme zu gliedern:

Im Schema lebt das Context-Engineering innerhalb der ersten beiden Teilsysteme: Es entscheidet, wie Anweisungen und Werkzeugausgaben in das Fenster gelangen. Das Harness ergänzt, was sich nicht in den Kontext legen lässt: einen funktionierenden Prüfbefehl, eine reproduzierbare Umgebung, eine Zustandsdatei, die einen Neustart übersteht.

Vergleichstabelle

Warum ein Prompt und Kontext allein nicht reichen

Eine klassische Geschichte: Das Team sieht, dass der Agent Fehler macht, und schreibt eine Woche lang eine fünfseitige AGENTS.md. Der Agent führt den Linter trotzdem nicht vor dem Commit aus. Der Grund liegt nicht im Text: Dem Agenten fehlt schlicht der Shell-Zugriff mit den richtigen Rechten, und der Linter ist im Image nicht installiert. Das ist ein Problem von Werkzeugen und Umgebung, und man hat es mit Anweisungen behandelt.

Zweite Geschichte: Der Agent behebt zum dritten Mal in Folge denselben Fehler, weil er sich nach einem Neustart nicht erinnert, was er schon versucht hat. Context-Engineering innerhalb der Sitzung hilft hier nicht: Das Fenster wird geleert. Nötig ist das Teilsystem Zustand — eine Datei, in die der Agent Versuche und Entscheidungen einträgt, und eine Regel, sie zu Beginn der Arbeit zu lesen.

Die dritte Geschichte ist die teuerste: Der Agent schreibt „fertig“, die Unit-Tests sind grün, aber das Feature funktioniert nicht. Weder der Prompt „prüfe sorgfältig“ noch zusätzliche Dokumente im Kontext verschaffen dem Agenten eine unabhängige Prüfung. Die liefert nur eine Rückmeldung von einer Maschine: ein Ende-zu-Ende-Test, ein Prüfskript, ein eigener Prüfer ohne Zugriff auf die Überlegungen des Ausführenden.

Das allgemeine Fazit: Prompt und Kontext beeinflussen, was das Modell denkt. Das Harness beeinflusst, was das Modell tun kann und was es nach einer Handlung erfährt.

Warum der Modellwechsel nicht hilft

Eine verbreitete Reaktion auf einen unzuverlässigen Agenten ist, ein stärkeres Modell zu nehmen. Das heilt meist nichts: Dasselbe Modell arbeitet in einem gut organisierten Repository wie ein selbstsicherer Senior, verliert sich aber in einem Repository ohne Prüfbefehle und ohne Beschreibung des Stacks. Ein stärkeres Modell errät nicht die Konventionen Ihres Teams, erhält keinen Zugriff auf eine Datenbank, zu der ihm die Berechtigung fehlt, und erfährt nichts von einer defekten Migration, wenn niemand sie ausgeführt hat.

Zugleich veraltet das Harness nicht mit neuen Modellen. Anweisungen, eine reproduzierbare Umgebung und Prüfungen braucht jedes Modell. Verändert wird nur, wie viel manuelle Mikrosteuerung wegfallen kann: Einem starken Modell genügen Invarianten („Daten werden an der Grenze der Domäne validiert“), keine Schritt-für-Schritt-Anleitung.

Wie man erkennt, welche Ebene zu reparieren ist

Die Diagnose anhand von Symptomen ist schneller als jedes Experiment:

Womit man das Harness beginnt

Beim Aufbau von Grund auf empfiehlt sich diese Reihenfolge: Rückmeldung → Anweisungen → Zustand → Umgebung → Werkzeuge. Die Rückmeldung kommt zuerst, weil man ohne sie die Wirkung der übrigen Änderungen nicht messen kann. Solange es keinen Befehl gibt, der ehrlich antwortet „funktioniert oder nicht“, wird jede Verbesserung der Anweisungen nach Gefühl beurteilt.

Ein minimaler Start sieht so aus:

# AGENTS.md (Auszug)
## So wird geprüft
- make check   # Lint, Typen, Unit-Tests
- make e2e     # Ende-zu-Ende-Szenarien
Ein Feature ist nur dann fertig, wenn beide Befehle mit Exit-Code 0 enden.

## Regeln
- MUST: Alle SQL-Abfragen sind parametrisiert
- MUST: Vor dem Commit make check ausführen
- Details zu Zahlungen: docs/payments.md (lesen, wenn die Aufgabe Zahlungen betrifft)

Achten Sie auf die letzte Zeile: Das ist Context-Engineering innerhalb des Harness. Die Einstiegsdatei ist eine Karte, kein Lehrbuch; Details werden unter der Bedingung „wenn“ geladen.

Wie man den Beitrag jedes Teils misst

Das Harness hat eine Metrik, die ein Prompt nicht hat: den Anteil der Aufgaben, die der Agent als fertig gemeldet hat, die aber eine unabhängige Prüfung nicht bestätigt hat. Man nennt das die Verifikationslücke (verification gap). Nehmen Sie 10 Aufgaben hintereinander und vermerken Sie bei jeder, ob der Agent „fertig“ gesagt hat und ob die Prüfung bestanden wurde — so erhalten Sie eine Zahl, an der sich Änderungen messen lassen.

Um zu sehen, welches Teilsystem wirkt, verwendet man die Ablation: Modell und Aufgabenmenge bleiben fest, dann schaltet man jeweils einen Teil des Harness ab und beobachtet den Einbruch. Dabei sind zwei Dinge wichtig. Besser beginnt man nicht mit der Ablation, sondern mit einem Fehlerprotokoll: Die Kennzeichnung, auf welcher Ebene etwas gebrochen ist, zeigt den Engpass schneller. Und ein Einbruch von null beweist nicht, dass eine Komponente nutzlos ist: Vielleicht hat die gewählte Aufgabenmenge sie einfach nicht beansprucht.

Häufige Fehler

• Eine Prompt-Datei für das Harness halten. Die Anweisungen sind eines von fünf Teilsystemen. Ein Regal voller Rezepte ist noch keine Küche.
• Fehlende Werkzeuge mit Text beheben. „Führe immer die Tests aus“ nützt nichts, wenn die Tests in der Umgebung des Agenten nicht laufen.
• Die Anweisungen aufblähen. Je länger die Einstiegsdatei, desto eher wird eine wichtige Regel übersehen. Wichtige Regeln macht man besser zu ausführbaren Prüfungen.
• Der Selbstauskunft des Agenten vertrauen. Ein Modell, das die eigene Arbeit bewertet, neigt zur Überschätzung. Geprüft werden muss durch ein Skript oder einen eigenen Agenten mit sauberem Kontext.
• Das Harness einmal einrichten und fertig. Es veraltet wie Code: Regeln weichen von der Realität ab, Befehle ändern sich. Es muss regelmäßig überarbeitet werden.

Fazit

Prompt-Engineering verbessert die Formulierung, Context-Engineering wählt aus, was ins Fenster des Modells gelangt, Harness-Engineering gestaltet die gesamte Umgebung des Agenten, einschließlich Werkzeugen, Umgebung, Zustand und Prüfungen. Arbeitet ein Agent lange und ändert er selbst Code, wird das Harness zur Hauptsache: Es macht aus „der Agent sagt fertig“ ein „das System hat geprüft, dass es funktioniert“. Die Wahl zwischen Harness und Context Engineering ist daher kein Entweder-oder: Der Kontext ist Teil des Harness, und repariert wird das Teilsystem, auf das die Symptome zeigen. Dieses Thema wird im Kurs zum Harness Engineering an einem durchgängigen Projekt eines Zahlungs-Backends praktisch behandelt.