Agent Harness Engineering

Ein Coding-Agent ist das Modell plus alles, was darum herum gebaut ist. Harness Engineering betrachtet dieses Gerüst als ein lebendiges Artefakt, das bei jedem Fehler des Agenten verfeinert wird.

Einfach ausgedrückt: Immer wenn ein Agent versagt, entwickeln Sie eine dauerhafte Lösung, damit genau dieser Fehler nie wieder auftritt.

In den letzten zwei Jahren hat die Branche über Modelle debattiert: Welches ist das intelligenteste, welches schreibt den saubersten React-Code oder welches halluziniert am wenigsten. So wichtig diese Diskussion auch ist, sie übersieht die andere Hälfte des Systems.

Das Modell ist nur eine Eingabe in einen laufenden Agenten. Der Rest ist das Harness: die Prompts, Tools, Kontextrichtlinien, Hooks, Sandboxen, Subagenten, Feedbackschleifen und Wiederherstellungspfade, die um das Modell herum gebaut sind, damit es tatsächlich Aufgaben erledigen kann.

Ein anständiges Modell mit einem großartigen Harness schlägt durchweg ein großartiges Modell mit einem schlechten Harness. Zunehmend liegt die interessanteste Ingenieursarbeit nicht in der Auswahl des Modells, sondern im Design des Gerüsts darum herum.

Diese Disziplin hat jetzt einen Namen. @Vtrivedy10 prägte den Begriff Harness Engineering und lieferte eine klare Aufschlüsselung, was ein Harness eigentlich ist und warum jedes Teil existiert. Andere Stimmen der Branche wie @dexhorthy, die aufkommende Muster verfolgen, HumanLayer, das Agentenfehler als konfigurationsbedingte "Skill Issues" einordnet, das Ingenieursteam von Anthropic, das Leitfäden für das Design langlebiger Anwendungen veröffentlicht, und Birgitta Böckeler, die die Benutzerseite erforscht – alle kommen ungefähr auf die gleiche Idee.

Dieser Beitrag führt diese Fäden zusammen.

Was ist ein Harness eigentlich?

Trivedys Kerndefinition leistet die meiste Arbeit:

Agent = Modell + Harness. Wenn du nicht das Modell bist, bist du das Harness.

Ein Harness umfasst jeden Teil des Codes, der Konfiguration und der Ausführungslogik, der nicht das Modell selbst ist. Ein rohes Modell ist kein Agent. Es wird erst dann zu einem, wenn ein Harness ihm Zustand, Tool-Ausführung, Feedbackschleifen und durchsetzbare Einschränkungen bereitstellt.

Konkret umfasst ein Harness:

• System-Prompts, CLAUDE.md, AGENTS.md, Skill-Dateien und Subagenten-Anweisungen.
• Tools, Skills, MCP-Server und deren technische Beschreibungen.
• Gebündelte Infrastruktur wie das Dateisystem, Sandboxen und Headless-Browser.
• Orchestrierungslogik zum Erzeugen von Subagenten, zur Handhabung von Übergaben und zum Routing von Modellen.
• Hooks und Middleware für deterministische Ausführung, wie Lint-Prüfungen oder Kontextkomprimierung.
• Observability-Tools für Logs, Traces, Kosten- und Latenzmessung.

Im Kern ist ein Agent ein System, das Tools in einer Schleife ausführt, um ein Ziel zu erreichen. Die wahre Fähigkeit liegt im Design sowohl der Tools als auch dieser Schleife.

Obwohl dies eine riesige Angriffsfläche darstellt, ist es Ihre Angriffsfläche, nicht die des Modellanbieters. Claude Code, Cursor, Codex, Aider und Cline sind alles Harnesses. Das zugrundeliegende Modell mag plattformübergreifend identisch sein, aber das Verhalten, das Sie erleben, wird vom Harness dominiert.

Lassen Sie uns das "Skill Issue" neu formulieren

Es ist üblich, dass Ingenieure dem Modell die Schuld geben, wenn ein Agent etwas Sinnloses tut, und das Problem oft als etwas abtun, auf das man "auf die nächste Version warten" müsse.

Die Denkweise des Harness Engineering lehnt diese Voreinstellung ab. Fehlschläge sind normalerweise einigermaßen nachvollziehbar. Wenn der Agent eine Konvention ignoriert hat, fügen Sie sie zu AGENTS.md hinzu. Wenn er einen destruktiven Befehl ausgeführt hat, schreiben Sie einen Hook, um ihn zu blockieren. Wenn er sich bei einer 40-Schritte-Aufgabe verlaufen hat, teilen Sie die Architektur in einen Planer und einen Ausführer auf. Wenn er konsequent mit kaputtem Code endet, schalten Sie ein Typprüfungs-Backpressure-Signal in die Schleife.

Wie HumanLayer es formuliert: "Es ist kein Modellproblem. Es ist ein Konfigurationsproblem." Betrachten Sie Leistungsbenchmarks: Ein führendes Modell, das innerhalb eines Standard-Frameworks läuft, erzielt oft drastisch niedrigere Werte als das exakt gleiche Modell, das in einem benutzerdefinierten, hochoptimierten Harness läuft. Ein Modell in eine Umgebung mit besseren Codebase-Tools, präziseren Prompts und schärferem Backpressure zu versetzen, kann Fähigkeiten freisetzen, die das ursprüngliche Setup ungenutzt ließ.

Die Lücke zwischen dem, was heutige Modelle theoretisch können, und dem, was Sie sie tatsächlich tun sehen, ist größtenteils eine Harness-Lücke.

Die Ratsche: Jeder Fehler wird zur Regel

Die wichtigste Gewohnheit im Harness Engineering ist, Agentenfehler als dauerhafte Signale zu behandeln – nicht als einmalige Ausrutscher, die man wiederholt und vergisst.

Wenn ein Agent einen PR mit einem auskommentierten Test ausliefert, der versehentlich gemergt wird, ist das ein Input. Die nächste Iteration von AGENTS.md muss festhalten: "Kommentiere Tests niemals aus; lösche oder repariere sie." Der nächste Pre-Commit-Hook sollte automatisch .skip( im Diff markieren. Der Reviewer-Subagent muss aktualisiert werden, um auskommentierte Tests zu blockieren.

Einschränkungen sollten nur hinzugefügt werden, wenn Sie einen tatsächlichen Fehler beobachten, und nur entfernt werden, wenn ein fähiges Modell sie überflüssig macht. Jede Zeile in einem guten System-Prompt sollte auf einen bestimmten, historischen Fehler zurückzuführen sein.

Aus diesem Grund ist Harness Engineering eine Disziplin und kein Einheits-Framework. Das richtige Harness für eine bestimmte Codebase wird vollständig durch ihre einzigartige Fehlergeschichte geprägt.

Rückwärtsarbeiten vom Verhalten

Der effektivste Weg, ein Harness zu entwerfen, ist, mit dem gewünschten Verhalten zu beginnen und die Komponente zu bauen, die es liefert: Gewünschtes Verhalten → Harness-Design, um es zu erreichen.

Jedes Teil des Harnesses muss eine bestimmte Aufgabe haben. Wenn Sie nicht benennen können, welches spezifische Verhalten eine Komponente liefern soll, sollte sie entfernt werden.

Dateisystem und Git – dauerhafter Zustand

Das Dateisystem ist grundlegend. Modelle können nur mit dem arbeiten, was in ihren Kontextfenster passt. Ein Dateisystem bietet einen Arbeitsbereich zum Lesen von Daten, einen Ort zum Auslagern von Zwischenarbeit und eine Oberfläche für die Koordination mehrerer Agenten.

Das Hinzufügen von Git bietet kostenlose Versionierung, sodass der Agent Fortschritte verfolgen, Experimente abzweigen und Fehler rückgängig machen kann.

Bash und Code-Ausführung: Allzweck-Tooling

Die meisten Agenten arbeiten in einer ReAct-Schleife: denken, handeln über einen Tool-Aufruf, beobachten, wiederholen. Anstatt für jede erdenkliche Aktion ein Tool vorzubauen, ermöglicht der Bash-Zugriff dem Agenten, das zu bauen, was er braucht, spontan.

Agenten sind im Allgemeinen hervorragend mit Shell-Befehlen, was Bash und Code-Ausführung zur Standardstrategie für autonome Problemlösung macht.

Sandboxen und Standard-Tooling

Bash ist nur nützlich, wenn es sicher läuft. Sandboxen bieten Agenten eine isolierte Umgebung, um Code auszuführen, Dateien zu inspizieren und Arbeit zu verifizieren, ohne das Host-System zu gefährden.

Eine gute Sandbox kommt mit starken Standardeinstellungen: vorinstallierte Laufzeitumgebungen, Test-CLIs und Headless-Browser, die es dem Agenten ermöglichen, seine eigene Arbeit zu beobachten und die Selbstverifikationsschleife zu schließen.

Speicher und Suche: Kontinuierliches Lernen

Modelle haben kein Wissen über ihre Trainingsgewichte und den aktuellen Kontext hinaus. Harnesses überbrücken diese Lücke mit Speicherdateien (wie AGENTS.md), die Wissen in jede Sitzung einbringen.

Für Echtzeitinformationen wie neue Bibliotheksversionen oder Live-Daten sind Websuche und MCP-Tools direkt in das Harness eingebaut.

Bekämpfung von Kontextverfall

Modelle lassen in ihrer Argumentationsfähigkeit nach, wenn ihre Kontextfenster voll werden. Harnesses verwalten diese Knappheit mit drei primären Techniken:

• Komprimierung: Intelligentes Zusammenfassen und Auslagern von älterem Kontext, um API-Fehler zu vermeiden.
• Tool-Aufruf-Auslagerung: Speichern massiver Tool-Ausgaben (wie 2.000-zeilige Logs) im Dateisystem, während nur die wesentlichen Kopf- und Fußzeilen im Kontext bleiben.
• Progressive Offenlegung: Anweisungen und Tools nur dann preisgeben, wenn eine Aufgabe sie explizit erfordert, anstatt alles beim Start zu laden.

Langfristige Ausführung

Autonome, langlaufende Arbeiten leiden unter vorzeitigem Abbruch und schlechter Problemzerlegung. Harnesses begegnen dem durch strukturelles Design:

• Schleifen: Abfangen des Versuchs eines Modells, zu beenden, und es zwingen, in einem frischen Kontextfenster gegen ein Fertigstellungsziel fortzufahren.
• Planung: Das Modell zwingen, Ziele in eine schrittweise Planungsdatei zu zerlegen und seine Arbeit nach jedem Schritt durch Selbstverifikations-Hooks zu überprüfen.
• Aufteilungen: Trennen von Generierung und Bewertung in verschiedene Agenten, um die inhärente positive Verzerrung zu verhindern, die Modelle bei der Bewertung ihrer eigenen Arbeit haben.

Hooks sind Ihre Durchsetzungsebene

Hooks überbrücken die Lücke zwischen dem Anfordern einer Aktion und deren Durchsetzung. Sie laufen in bestimmten Lebenszyklen: vor einem Tool-Aufruf, nach einer Dateibearbeitung oder vor einem Commit. Hooks blockieren destruktive Befehle, erzwingen automatische Formatierung, um Tokens zu sparen, und führen Testsuiten aus.

Idealerweise ist Erfolg leise und Fehlschlag ausführlich. Wenn eine Typprüfung bestanden wird, hört der Agent nichts; wenn sie fehlschlägt, wird der Fehler direkt zurück in die Schleife zur Selbstkorrektur eingespeist.

Hier sind das Regelwerk und die Tool-Auswahl

Eine flache Markdown-Datei im Stammverzeichnis eines Repositorys ist immer noch der Konfigurationspunkt mit der höchsten Hebelwirkung. Sie muss jedoch wie die Checkliste eines Piloten behandelt werden, nicht wie ein Styleguide. Halten Sie sie kurz und stellen Sie sicher, dass jede Regel durch einen vergangenen Fehler verdient wurde.

Die gleiche Disziplin gilt für Tools. Zehn hochfokussierte Tools werden immer fünfzig überlappende übertreffen.

Da Tool-Beschreibungen außerdem den Prompt füllen, können bösartige oder schlampige externe Integrationen (wie unverifizierte MCP-Server) schlechte Prompts in den Agenten einschleusen, bevor er überhaupt mit der Arbeit beginnt.

Wie das in der Produktion aussieht

Das klarste öffentliche Bild eines ausgereiften Harnesses, das ich gesehen habe, ist Fareed Khans (geschätzte) Aufschlüsselung der Architektur von Claude Code.

Fast jedes Konzept aus dem vorherigen Abschnitt taucht in diesem Diagramm als benannte Komponente auf. Kontextinjektion ist die Wissensebene. Schleifenzustand lebt im Speicher und im Worktree-Isolator. Hooks für destruktive Aktionen sitzen hinter dem Berechtigungs-Gate. Subagenten-Kontext-Firewalls sind die gesamte Multi-Agenten-Ebene. Das Tool-Dispatch-Registry ist der Ort, an dem sowohl MCP-Server als auch Bash eingesteckt werden. Die Entwicklung von Claude Code dreht sich mindestens so sehr um das Harness wie um das darunterliegende Modell.

Harnesses Schrumpfen Nicht, Sie Verschieben Sich

Wenn Modelle besser werden, verschwindet die Notwendigkeit eines Harnesses nicht – sie verlagert sich.

Es ist verlockend anzunehmen, dass bessere Modelle das Gerüst überflüssig machen. Jüngste Modell-Upgrades haben beispielsweise den Bedarf an "Kontextangst"-Minderungen drastisch reduziert. Aber wenn die untere Grenze steigt, steigt auch die obere Grenze. Aufgaben, die zuvor unerreichbar waren, sind jetzt im Spiel und bringen völlig neue Fehlermodi mit sich.

Jede Komponente in einem Harness kodiert eine Annahme darüber, was das Modell nicht alleine kann. Wenn sich das Modell verbessert, sollte veraltetes Gerüst entfernt werden, und neues Gerüst muss gebaut werden, um den nächsten Horizont zu erreichen.

Was ist mit der Trainingsschleife?

Es gibt eine aktive Feedbackschleife zwischen Harness-Design und Modelltraining.

Heutige Modelle werden oft mit bestimmten Harnesses in der Schleife nachtrainiert, was zu einem gewissen Grad an Überanpassung führt. Das Modell wird außergewöhnlich gut in den spezifischen Aktionen, die die Harness-Designer priorisiert haben (z. B. Dateisystemoperationen, Bash, Subagenten-Dispatch).

Dies macht das Harness zu einem lebendigen System, nicht zu einer statischen Konfigurationsdatei, und beweist, dass das "beste" Harness dasjenige ist, das speziell für Ihre spezifischen Aufgaben und Arbeitsabläufe optimiert ist.

Harness-as-a-Service (HaaS)

Die Branche verlagert sich vom Bauen auf LLM-APIs (die Vervollständigungen liefern) hin zum Bauen auf Harness-APIs (die eine Laufzeitumgebung bereitstellen). SDKs bieten jetzt die Schleife, Tools, Kontextverwaltung, Hooks und Sandboxen direkt aus der Box.

Anstatt Orchestrierung von Grund auf neu zu bauen, ist der moderne Standard, ein Harness-Framework auszuwählen, seine Kernpfeiler zu konfigurieren und sich ausschließlich auf das domänenspezifische Prompt- und Tool-Design zu konzentrieren.

Das macht die Fehlerbehebung skalierbar: Sie stimmen eine gut strukturierte Konfigurationsoberfläche ab, anstatt die gesamte Agentenarchitektur neu zu erfinden.

Wohin Das Führt

Wenn Sie sich die besten Coding-Agenten von heute ansehen, ähneln sie sich mehr als ihren zugrundeliegenden Modellen. Die Modelle unterscheiden sich, aber die Harness-Muster konvergieren. Die Branche identifiziert schnell das tragende Gerüst, das erforderlich ist, um generativen Text in auslieferbare Software zu verwandeln.

Die spannendsten offenen Probleme bewegen sich über einzelne Agenten hinaus: die Orchestrierung mehrerer Agenten parallel, die Befähigung von Agenten, ihre eigenen Spuren zu analysieren, um Harness-Ebene-Fehler zu beheben, und der Bau von Umgebungen, die Tools dynamisch und just-in-time zusammenstellen.

Letztendlich ist dies die Phase, in der Harnesses aufhören, statische Konfigurationsdateien zu sein, und anfangen, sich viel mehr wie Compiler zu verhalten.

Wenn Sie nach einem großartigen Agent-Harness-Framework suchen, @FredKSchott hat Flue geschrieben. Es ist solide und wurde anscheinend von einer früheren Version dieses Beitrags inspiriert!