Das Harness: das Gerüst, das den Agenten zuverlässig macht

In vielen Posts hier taucht das Wort «Harness» auf, meist als das, worein man die eigentliche Arbeit steckt, statt in den einzelnen Fix. Es lohnt sich, den Begriff einmal sauber zu kompilieren, statt ihn bei jeder Erwähnung neu zu umschreiben. Kurz gesagt: Das Harness ist das Gesamtgerüst um den Agenten herum, das sein Verhalten zuverlässig und wiederholbar macht, statt es vom Tagesform-Prompt abhängen zu lassen.

1. 🧩 Was ein Harness ist

Ein Sprachmodell ist von sich aus unbeständig. Dieselbe Frage, anders formuliert, an einem anderen Tag, kann ein anderes Ergebnis liefern. Wer Agenten ernsthaft einsetzt, will aber nicht jedes Mal hoffen, dass der Prompt heute gut sitzt. Er will, dass die Arbeit zuverlässig in derselben Qualität herauskommt, egal wer den Lauf startet und wie der Tag läuft.

Genau das leistet das Harness. Es ist nicht der Agent selbst und nicht der einzelne Prompt, sondern alles drumherum: die Regeln, Vorlagen, Rollen und Checks, die den Agenten in eine verlässliche Form zwingen. Das Verhalten wandert damit vom flüchtigen Prompt in ein dauerhaftes, versioniertes Gerüst im Repo.

Wichtig ist die Denkweise dahinter: Eine schlechte Agenten-Ausgabe ist nicht «ein misslungener Lauf», sondern ein Hinweis auf eine Lücke im Harness. Man bessert nicht das einzelne Artefakt nach, man verbessert das Gerüst, das es erzeugt hat. Diese Schwungrad-Logik ist im agentischen Flywheel ausführlich beschrieben.

2. 🏗️ Die Schichten desselben Systems

Ein häufiges Missverständnis: Man hält Instruktionsdatei, Rollen, Evals und Flywheel für vier getrennte Werkzeuge. Sie sind aber Schichten eines Systems. Jede beschreibt eine andere Ebene desselben Harness:

  • Globale Ebene: die Instruktionsdatei. Die Instruktionsdatei (Konvention AGENTS.md oder CLAUDE.md) hält fest, was immer gilt: Konventionen, Build-Schritte, wiederkehrende Regeln. Sie ist das Langzeitgedächtnis, das dem Modell von Natur aus fehlt.
  • Spezialisierte Ebene: Rollen und Subagenten. Statt einen Allzweck-Agenten alles machen zu lassen, übernehmen spezialisierte Rollen mit eigenem, frischem Kontext einzelne Aufgaben. Das agentische Rollen-Setup zeigt so eine Aufteilung (Use-Case, Test-Spec, Implementierung, Architektur, Security, Betrieb).
  • Prüf-Ebene: die Evals. Automatische Checks sagen dem Agenten, ob seine Arbeit taugt, ohne dass ein Mensch jede Zeile liest. Eval-driven Development macht diese Prüfschicht zum festen Artefakt, so routinemässig wie Unit-Tests.
  • Die Schleife: das Flywheel. Was die Prüf-Ebene aufdeckt, wird in die anderen Schichten zurückgespielt. Diese Rückkopplung ist das agentische Flywheel, das aus einem statischen Gerüst ein mit jedem Lauf besseres macht.

Die Schichten greifen ineinander: Die globale Ebene legt die Grundregeln, die spezialisierte Ebene teilt die Arbeit auf, die Prüf-Ebene verifiziert, und die Schleife sorgt dafür, dass jede Korrektur dauerhaft wird.

3. 🪶 Ein Harness muss knapp bleiben

Es liegt nahe, das Harness immer weiter aufzublähen: noch eine Regel, noch ein Hinweis, noch eine Vorlage. Das ist gefährlich. Jede Zeile in der Instruktionsdatei und jeder mitgeschleppte Kontext kostet Platz im Kontextfenster des Modells. Wird das Gerüst zu fett, frisst es genau den Raum, den der Agent für die eigentliche Aufgabe braucht, und das Modell beginnt, Regeln zu überlesen.

Deshalb gehört zum Harness eine zweite Disziplin: es schlank zu halten. Das ist die Aufgabe von Context-Engineering. Die Leitfrage pro Regel lautet: Würde ihr Wegfall wirklich Fehler verursachen? Wenn nicht, raus damit. Wenige wirksame Regeln plus automatische Checks schlagen eine lange Prosa-Liste, die niemand mehr liest.

4. 🔧 Konkret: die Werkstatt statt des einzelnen Mechanikers

Stell dir eine Auto-Werkstatt vor, in der ständig wechselnde Mechaniker arbeiten. Würde die Qualität allein vom einzelnen Mechaniker abhängen, käme an einem guten Tag ein sauberer Service heraus und an einem schlechten ein vergessener Ölwechsel. Eine gute Werkstatt verlässt sich nicht auf die Tagesform. Sie hat eine Hebebühne, Diagnosegeräte, Drehmoment-Vorgaben und eine Service-Checkliste, die jeder abarbeitet. Dieses eingerichtete Drumherum ist das Harness: Es macht das Ergebnis verlässlich, egal wer gerade schraubt.

Übertragen auf ein Software-Beispiel, einen Webshop: Der Agent soll eine Bestell-Funktion bauen. Ohne Harness hängt das Ergebnis am Prompt des Tages. Mit Harness ist die Sache eingerahmt: Die Instruktionsdatei sagt «Lagerbestand-Edge-Cases sind Pflicht» (globale Ebene), eine QA-Rolle leitet daraus eine Test-Spec ab (spezialisierte Ebene), ein automatischer Test wird bei fehlender Behandlung rot (Prüf-Ebene), und wenn doch ein Fall durchrutscht, wird die Lücke als neue Regel zurückgespielt (die Schleife). Das Ergebnis hängt nicht mehr am Glück des Prompts, sondern am Gerüst.

5. 🧠 Bezug zum Brain

Das Konzept ist nicht auf Coding-Agenten beschränkt. Auch dieses Second Brain läuft über ein Harness: AGENTS.md und die Blog-Guidelines sind die globale Ebene, der Ingest- und der Lint-Lauf sind spezialisierte Rollen, und die Pflege-Regeln sorgen dafür, dass jeder Lauf reproduzierbar bleibt statt vom Tagesprompt abzuhängen. Warum so ein kompiliertes, eigenes System mehr ist als eine Notiz-App, steht unter LLM-Wiki trifft OKF.

📚 Weiterführende Links & Quellen

Intern:

Extern: