Wir haben die letzten zwei Jahre darüber diskutiert, welches Modell das klügste ist, welches das sauberste React schreibt, welches am wenigsten halluziniert. Das ist eine legitime Diskussion — aber sie ignoriert die Hälfte des Systems. Das Modell ist ein Input in einen laufenden Agenten. Der Rest ist das Harness: die Prompts, Tools, Kontext-Richtlinien, Hooks, Sandboxes, Subagents, Feedback-Schleifen und Recovery-Pfade, die um das Modell gewickelt werden, damit es überhaupt etwas fertigstellen kann.
Ein brauchbares Modell mit einem exzellenten Harness schlägt ein exzellentes Modell mit einem schlechten Harness. Ich habe das in meiner eigenen Arbeit immer wieder beobachtet. Und zunehmend liegt die interessante Entwicklung nicht in der Modellauswahl, sondern im Design des Gerüsts drumherum.
Was ist ein Harness — wirklich?
Viv Trivedy hat es auf den Punkt gebracht: "Agent = Model + Harness. Wenn Sie nicht das Modell sind, sind Sie das Harness." Ein Harness ist jedes Stück Code, Konfiguration und Ausführungslogik, das nicht das Modell selbst ist. Ein rohes Modell ist kein Agent. Es wird erst zu einem, wenn ein Harness ihm Zustand, Tool-Ausführung, Feedback-Schleifen und erzwingbare Constraints gibt.
Konkret umfasst ein Harness:
- System-Prompts, CLAUDE.md, AGENTS.md, Skill-Dateien und Subagent-Prompts
- Tools, Skills, MCP-Server und deren Beschreibungen
- Gebündelte Infrastruktur (Dateisystem, Sandbox, Browser)
- Orchestrierungslogik (Subagent-Spawning, Handoffs, Modell-Routing)
- Hooks und Middleware für deterministische Ausführung (Compaction, Continuation, Lint-Checks)
- Observability (Logs, Traces, Kosten- und Latenz-Messung)
Simon Willison reduziert den Schleifen-Teil auf seine Essenz: Ein Agent ist ein System, das "Tools in einer Schleife ausführt, um ein Ziel zu erreichen." Die Kunst liegt im Design sowohl der Tools als auch der Schleife.
Claude Code, Cursor, Codex, Aider, Cline — das sind alles Harnesses. Das Modell darunter ist manchmal dasselbe, aber das Verhalten, das Sie erleben, wird dominiert von dem, was das Harness tut.
Das "Skill-Issue"-Reframing
Es gibt ein Muster, in das ich Entwickler immer wieder fallen sehe: Der Agent tut etwas Dummes, der Entwickler gibt dem Modell die Schuld, und die Schuld wird unter 'warten wir auf die nächste Version' abgelegt.
Die Harness-Engineering-Denke lehnt diesen Default ab. Der Fehler ist meist lesbar. Der Agent wusste nichts von einer Konvention — also fügen Sie sie zur AGENTS.md hinzu. Der Agent hat einen destruktiven Befehl ausgeführt — also fügen Sie einen Hook hinzu, der ihn blockiert. Der Agent hat sich in einer 40-Schritt-Aufgabe verloren — also teilen Sie ihn in Planer und Executor auf. Der Agent hat ständig kaputten Code als 'fertig' markiert — also verdrahten Sie einen Typecheck-Backpressure-Signal in die Schleife.
HumanLayer sagt: "Es ist kein Modell-Problem. Es ist ein Konfigurations-Problem." Harness Engineering ist das, was passiert, wenn man das ernst nimmt.
Es gibt einen beeindruckenden Datenpunkt: Auf Terminal Bench 2.0 schneidet Claude Opus 4.6 innerhalb von Claude Code deutlich schlechter ab als dasselbe Modell in einem maßgeschneiderten Harness. Vivs Team hat einen Coding-Agenten von Top 30 auf Top 5 gebracht — nur durch Änderung des Harness. Modelle werden post-training an den Harness gekoppelt, gegen den sie trainiert wurden. Wenn Sie sie in einen anderen Harness mit besseren Tools, einem engeren Prompt und schärferem Backpressure versetzen, können Sie Fähigkeiten freischalten, die der ursprüngliche Harness auf dem Tisch hat liegen lassen.
Das ist das Gegenteil der 'warten wir auf GPT-6'-Erzählung. Die Lücke zwischen dem, was heutige Modelle können, und dem, was Sie sie tun sehen, ist weitgehend eine Harness-Lücke.
Die Ratsche: Jeder Fehler wird zur Regel
Die wichtigste Gewohnheit im Harness Engineering ist die Behandlung von Agenten-Fehlern als permanente Signale. Nicht als einmalige Anekdoten zum Lachen, nicht als 'schlechte Runs' zum Wiederholen. Sondern als Signale.
Wenn der Agent einen PR mit auskommentierten Tests shippt und ich es versehentlich merge, ist das ein Input. Die nächste Version meiner AGENTS.md sagt: 'Kommentiere niemals Tests aus; lösche sie oder repariere sie.' Die nächste Version meines Pre-Commit-Hooks grept nach .skip( und xit( im Diff. Die nächste Version meines Reviewer-Subagents markiert auskommentierte Tests als Blocker.
Sie fügen nur dann Constraints hinzu, wenn Sie einen echten Fehler gesehen haben. Sie entfernen sie nur, wenn ein fähiges Modell sie überflüssig gemacht hat. Jede Zeile in einer guten AGENTS.md sollte auf ein spezifisches Problem zurückführbar sein, das schiefgelaufen ist.
Das ist auch der Grund, warum Harness Engineering eine Disziplin und kein Framework ist. Der richtige Harness für Ihre Codebase wird durch Ihre Fehlerhistorie geformt. Sie können ihn nicht herunterladen.
Rückwärts vom Verhalten her arbeiten
Der nützlichste Ansatz beim Harness-Design ist, beim gewünschten Verhalten zu starten und das Harness-Stück abzuleiten, das es liefert. Das Muster: Verhalten, das wir wollen (oder reparieren wollen) → Harness-Design, das dem Modell hilft, es zu erreichen.
Das Nützliche daran: Jede Harness-Komponente hat einen spezifischen Job. Wenn Sie das Verhalten nicht benennen können, das eine Komponente liefern soll, sollte sie wahrscheinlich nicht da sein.
Dateisystem und Git: Dauerhafter Zustand
Das Dateisystem ist das grundlegendste Primitiv — und es wird oft unterschätzt, weil es langweilig ist. Modelle können nur direkt operieren, was in den Kontext passt. Ohne Dateisystem kopieren Sie in ein Chat-Fenster, und das ist kein Workflow.
Mit einem Dateisystem bekommt der Agent einen Workspace zum Lesen von Daten, Code und Docs; einen Ort, um Zwischenergebnisse abzuladen, statt sie im Kontext zu halten; und eine Oberfläche, auf der mehrere Agenten und Menschen über gemeinsame Dateien koordinieren können. Git darauf gibt Versionierung kostenlos dazu — der Agent kann Fortschritt tracken, Fehler zurückrollen und experimente branchen.
Bash und Code-Ausführung: Das Universal-Werkzeug
Die Hauptschleife eines Agenten ist heute eine ReAct-Schleife: Das Modell denkt nach, führt eine Aktion über einen Tool-Call aus, beobachtet das Ergebnis und wiederholt. Ein Harness kann aber nur die Tools ausführen, für die es Logik hat. Sie können versuchen, für jede mögliche Aktion ein eigenes Tool zu bauen — oder Sie geben dem Agenten Bash und lassen ihn die Tools bauen, die er braucht.
Willisons Take: Agenten sind bereits hervorragend in Shell-Kommandos; die meisten Aufgaben kollabieren auf ein paar gut gewählte CLI-Aufrufe. Bash plus Code-Ausführung ist zur Standard-Strategie für autonomes Problemlösen geworden. Es ist der Unterschied zwischen jemandem, der ein einzelnes Küchengerät bedienen kann, und jemandem, dem man eine ganze Küche übergibt.
Sandboxes und Standard-Tooling
Bash ist nur nützlich, wenn sie irgendwo sicher läuft. Agenten-generierten Code auf dem Laptop auszuführen ist riskant, und eine einzelne lokale Umgebung skaliert nicht auf viele parallele Agenten.
Sandboxes geben Agenten eine isolierte Betriebsumgebung. Statt lokal auszuführen, verbindet sich das Harness mit einer Sandbox, um Code zu starten, Dateien zu inspizieren, Dependencies zu installieren und Arbeit zu verifizieren. Sie können Befehle allow-listen, Netzwerk-Isolation erzwingen, neue Umgebungen on-demand hochfahren und sie herunterreißen, wenn die Aufgabe erledigt ist.
Eine gute Sandbox kommt mit guten Defaults: vorinstallierte Sprach-Runtimes und Packages, Git- und Test-CLIs, ein Headless-Browser für Web-Interaktion. Browser, Logs, Screenshots und Test-Runner sind es, die dem Agenten erlauben, seine eigene Arbeit zu beobachten und die Selbstverifikations-Schleife zu schließen.
Memory und Suche: Kontinuierliches Lernen
Modelle haben kein zusätzliches Wissen über ihre Gewichte und das, was gerade im Kontext ist, hinaus. Ohne die Fähigkeit, Gewichte zu bearbeiten, ist der einzige Weg, Wissen hinzuzufügen, die Kontext-Injektion.
Das Dateisystem ist wieder das Primitiv. Harnesses unterstützen Memory-Datei-Standards wie AGENTS.md, die bei jedem Start injiziert werden. Wenn der Agent diese Datei bearbeitet, lädt das Harness sie neu — Wissen aus einer Session trägt in die nächste. Das ist eine grobe, aber effektive Form des kontinuierlichen Lernens.
Für Wissen, das zum Trainingszeitpunkt nicht existierte — neue Library-Versionen, aktuelle Docs, heutige Daten — überbrücken Web-Suche und MCP-Tools wie Context7 den Cutoff. Das sind nützliche Primitive, die man ins Harness backen sollte, statt sie dem Nutzer zu überlassen.
Kontext-Fäulnis bekämpfen
Kontext-Fäulnis ist die Beobachtung, dass Modelle schlechter darin werden zu argumentieren und Aufgaben abzuschließen, je voller das Kontextfenster wird. Kontext ist knapp, und Harnesses sind im Wesentlichen Zustellungsmechanismen für gutes Kontext-Engineering.
Drei Techniken tauchen wiederholt auf:
- Compaction. Wenn das Fenster voll wird, muss etwas weichen. Das Harness fasst älteren Kontext intelligent zusammen und lagert ihn aus, damit der Agent weiterarbeiten kann.
- Tool-Call-Offloading. Große Tool-Outputs (denken Sie an 2.000-Zeilen-Logdateien) überladen den Kontext ohne viel Signal. Das Harness behält Head- und Tail-Tokens und lagert den vollständigen Output ins Dateisystem aus.
- Skills mit progressiver Offenlegung. Alle Tools und MCPs beim Start in den Kontext zu laden, verschlechtert die Leistung, bevor der Agent eine einzige Aktion ausgeführt hat. Skills lassen das Harness Anweisungen und Tools nur dann enthüllen, wenn die Aufgabe sie tatsächlich verlangt.
Anthropics Harness-Post fügt eine weitere Technik für wirklich lange Jobs hinzu: vollständige Kontext-Resets, bei denen das Harness die Session abreißen und aus einer kompakten Handoff-Datei neu aufbaut. Sie sind explizit: Compaction allein war nicht ausreichend für lange Aufgaben; manchmal muss man frisch starten mit einem strukturierten Briefing.
Langstrecken-Ausführung: Planung und Verifikation
Autonome Langstrecken-Arbeit ist der Heilige Gral und das Schwerste, richtig hinzubekommen. Heutige Modelle leiden unter vorzeitigem Abbruch, schlechter Dekomposition komplexer Probleme und Inkohärenz, wenn sich Arbeit über mehrere Kontextfenster erstreckt.
Planung bedeutet, dass das Modell ein Ziel in eine Sequenz von Schritten zerlegt, üblicherweise in eine Plan-Datei auf der Festplatte. Nach jedem Schritt verifiziert der Agent seine Arbeit: Hooks führen eine vordefinierte Test-Suite aus und schleifen Fehler mit dem Fehlertext zurück zum Modell, oder das Modell reviewt seinen eigenen Output gegen explizite Kriterien.
Anthropics Langstrecken-Arbeit ist explizit darin, dass die Trennung von Generierung und Evaluation in distinct Agents die Selbst-Evaluation outperformt — weil Agenten zuverlässig positiv verzerren, wenn sie die eigene Arbeit bewerten. Das verwandte Muster ist der Sprint-Contract: Generator und Evaluator verhandeln, was 'fertig' eigentlich bedeutet, bevor Code geschrieben wird. In meinen eigenen Workflows hat das Aufschreiben der Done-Bedingung vor dem Start mehr Scope-Drift aufgefangen als jede Prompt-Änderung, die ich je gemacht habe.
Hooks: Die Durchsetzungsebene
Hooks sind das, was 'ich habe dem Agenten gesagt, er soll X tun' von "das System erzwingt X" trennt.
Ein Hook ist ein Skript, das an einem spezifischen Lifecycle-Punkt läuft: vor einem Tool-Call, nach einem File-Edit, vor dem Commit, beim Session-Start. Sie sind der richtige Ort für Dinge, die der Agent niemals vergessen sollte, aber oft vergisst: Typecheck und Lint und Tests nach jedem Edit ausführen und Fehler sichtbar machen. Destruktive Bash-Befehle blockieren. Zustimmung erzwingen, bevor ein PR geöffnet oder auf main gepusht wird. Auto-Formatierung beim Schreiben.
Das Prinzip, das HumanLayer hervorhebt und dem ich zustimme: Erfolg ist lautlos, Fehler sind verbose. Wenn der Typecheck durchläuft, hört der Agent nichts. Wenn er fehlschlägt, wird der Fehlertext in die Schleife injiziert und der Agent korrigiert sich selbst. Das macht die Feedback-Schleife im Normalfall fast kostenlos und bei Fehlern direkt umsetzbar.
AGENTS.md und Tool-Auswahl
Das flache Markdown-Regelwerk im Root Ihres Repos ist immer noch der einzelne Konfigurationspunkt mit dem höchsten Hebel, weil es bei jedem Turn im System-Prompt landet. Konventionen kommen hier rein: Package-Manager, Test-Framework, Formatierung, 'never touch /legacy', 'immer unseren Logger verwenden'.
Zwei hart verdiente Lektionen:
- Kurz halten. HumanLayer hält seines unter 60 Zeilen. Jede Zeile konkurriert um Aufmerksamkeit, und mehr Regeln machen jede einzelne weniger wichtig. Piloten-Checkliste, nicht Style-Guide.
- Jede Zeile verdienen. Regeln sollten auf einen spezifischen vergangenen Fehler oder eine harte externe Constraint zurückführbar sein. Wenn nicht, sind sie Rauschen. Ratschen, nicht Brainstormen.
Dasselbe gilt für Tools. Jedes Tool-Name, jede Description und jedes Schema wird bei jedem Request in den Prompt gestempelt. Zehn fokussierte Tools outperformen fünfzig überlappende, weil das Modell das Menü im Kopf behalten kann.
Harnesses schrumpfen nicht — sie bewegen sich
Eine der besseren Beobachtungen im Anthropic-Beitrag ist, dass mit besseren Modellen der Raum interessanter Harness-Kombinationen nicht schrumpft. Er bewegt sich.
Die naive Geschichte ist: bessere Modelle machen Harnesses obsolet. Wenn das Modell planen kann, kein Planer. Wenn das Modell über lange Horizonte kohärent ist, keine Kontext-Resets. Und ja — Opus 4.6 hat die Context-Anxiety-Failure-Mode weitgehend getötet. Aber die Decke hat sich mit dem Modell bewegt. Aufgaben, die unerreichbar waren, sind jetzt machbar — und sie haben ihre eigenen Failure-Modes.
Anthropic formuliert es klar: "Jede Komponente in einem Harness kodiert eine Annahme darüber, was das Modell allein nicht kann." Wenn das Modell in etwas besser wird, wird diese Komponente tragend für nichts und sollte raus. Wenn das Modell etwas Neues freischaltet, wird neues Gerüst benötigt, um die neue Decke zu erreichen.
Der Modell-Harness-Trainings-Loop
Was zusätzlich passiert — und was Viv explizit benennt — ist ein Feedback-Loop zwischen Harness-Design und Modell-Training.
Heutige Agenten-Produkte werden post-trained mit Harnesses in der Schleife. Das Modell wird spezifisch besser in den Aktionen, die Harness-Designer für wichtig halten: Dateisystem-Operationen, Bash, Planung, Subagent-Dispatch. Deshalb fühlt sich Opus 4.6 innerhalb von Claude Code anders an als in jemandes anderem Harness. Das ist auch der Grund, warum das Ändern einer Tool-Logik manchmal seltsame Regressionen verursacht.
Die praktische Implikation ist zweifach: Ein Harness ist ein lebendes System, keine Konfigurationsdatei, die man einmal einrichtet. Und der 'beste' Harness ist nicht notwendigerweise der, in dem das Modell trainiert wurde — es ist der, der für Ihre Aufgabe designt ist.
Harness-as-a-Service
Vivs anderer Beitrag ist das HaaS-Framing: Harness-as-a-Service. Die Beobachtung: Wir bewegen uns vom Bauen auf LLM-APIs (die Ihnen ein Completion geben) zum Bauen auf Harness-APIs (die Ihnen eine Runtime geben). Der Claude Agent SDK, der Codex SDK und der OpenAI Agents SDK — sie alle zeigen in dieselbe Richtung.
Sie bekommen die Schleife, die Tools, das Kontext-Management, die Hooks und die Sandbox-Primitive out-of-the-box und passen sie an. Der Default-Pfad war früher: eigene Schleife bauen, eigenes Tool-Calling verdrahten, eigenen Conversation State handhaben. Jetzt ist der Default-Pfad: ein Harness-Framework wählen, entlang der vier Säulen konfigurieren (System-Prompt, Tools, Kontext, Subagents) und den Rest der Energie in domänenspezifisches Prompt- und Tool-Design stecken.
Wo das hingeht
Schaut man sich die Top-Coding-Agenten Seite an Seite an — Claude Code, Cursor, Codex, Aider, Cline — sie sehen mehr einander ähnlich als ihre zugrundeliegenden Modelle. Die Modelle sind verschieden. Die Harness-Patterns konvergieren. Ich glaube nicht, dass das ein Zufall ist. Es ist die Industrie, die langsam die tragenden Stücke des Gerüsts findet, die ein generatives Modell in etwas verwandeln, das shippen kann.
Vivs Framing der offenen Probleme ist das, das ich am spannendsten finde: die Orchestrierung vieler Agenten, die parallel an einer gemeinsamen Codebase arbeiten; Agenten, die ihre eigenen Traces analysieren, um Harness-Level-Failure-Modes zu identifizieren und zu beheben; Harnesses, die dynamisch die richtigen Tools und den richtigen Kontext just-in-time für eine gegebene Aufgabe assemblieren, statt beim Start vorkonfiguriert zu sein.
Dieses letzte Thema fühlt sich an wie der Punkt, an dem Harnesses aufhören, statische Konfiguration zu sein, und anfangen, eher ein Compiler zu werden.
Ein decentes Modell mit einem großartigen Harness schlägt ein großartiges Modell mit einem schlechten Harness. Die interessantere Frage ist nicht, welches Modell Sie wählen — sondern welches Gerüst Sie darum herum bauen.