Die zugrundeliegende Logik von Agent Harness hinter dem Claude Code-Hype: Eine tiefgehende Analyse von UIUC, Meta und der Stanford University

Wenn Agenten in Umgebungen mit langfristigen Aufgaben eingesetzt werden, was ist das eigentliche Operationsobjekt, das Schlussfolgern, Handeln, Feedback, Validierung und Zusammenarbeit miteinander verbindet?

In den letzten zwei Jahren ist es nicht mehr neu, dass große Modelle Code schreiben. Von der Code-Vervollständigung bis zur Behebung von GitHub-Issues, von Wettbewerbsprogrammierung bis hin zu Softwareentwicklung auf Repository-Ebene gewöhnen sich die Menschen an, ein einfaches Kriterium zur Bewertung von Coding-Agenten anzuwenden: Kann der Code korrekt geschrieben werden? Können die Tests bestanden werden?

Aber die Entstehung von Systemen wie Claude Code und Codex treibt die Frage auf eine noch tiefere Ebene. Ein wirklich starker Coding-Agent kann nicht nur "Code schreiben". Er muss auch in der Lage sein, über einen längeren Zeitraum das Repository zu lesen, Pläne zu erstellen, Dateien zu ändern, Befehle auszuführen, Fehler zu prüfen, fehlgeschlagene Aktionen zu beheben, den Kontext zu pflegen und in mehrfachen Feedback-Schleifen kontinuierlich Aufgaben voranzutreiben.

Dieses Ausführungssystem, das es ermöglicht, dass das Modell langfristig zuverlässig "läuft", ist der Agent Harness. Viele Diskussionen über Harness befassen sich damit, was um das Modell herum gepackt werden sollte: Werkzeuge, APIs, Sandboxes, Gedächtnis, Zugriffsbereiche, Validatoren, Feedback-Schleifen. Sie beantworten die Frage, "Welche Systemkomponenten ein nutzbarer Agent benötigt".

Eine 102-seitige Übersichtsarbeit namens "Code as Agent Harness" von der University of Illinois at Urbana-Champaign (UIUC), Meta und der Stanford University geht noch einen Schritt weiter und fragt: Was sind die eigentlichen Objekte, die die Schritte von Inferenz, Handlung, Feedback, Validierung und Zusammenarbeit miteinander verbinden, wenn ein Agent in eine langfristige Aufgabenumgebung eingesetzt wird?

Die Antwort ist: Code.

Titel der Studie: Code as Agent Harness
Studie: https://arxiv.org/pdf/2605.18747
GitHub-Repository: https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers

Hierbei ist der Code nicht nur ein Programm, das das Modell am Ende erzeugt, noch bedeutet es, dass der Agent-Frameworks selbst aus Code besteht. Es bezieht sich auf eine Reihe von kodierten Zwischenprodukten, die der Agent im Harness ständig erzeugt, ausführt, ändert, speichert und teilt: Plan.md, Testskripte, Shell-Befehle, Patches, Ausführungslogs, Workflows, Skill-Bibliotheken, Simulatoren, Validatoren und sogar den Zustand des geteilten Repositories.

In der traditionellen Codegenerierung ist der Code normalerweise das Endprodukt des Modells; aber im Agent Harness tritt der Code in den gesamten Ausführungszyklus ein, trägt Planung, Ausführung, Feedback, Validierung und Zustandsverwaltung und wird zum zentralen Medium für die Organisation des langfristigen Ausführungsprozesses im Harness.

Code as Agent Harness betrachtet den Code als ausführbares, prüfbares und zustandsbehaftetes Medium im Agent-System und behandelt es auf drei Ebenen: Schnittstelle, Mechanismus und Erweiterung für mehrere Agenten.

Warum benötigt der Harness Code als zentrales Trägermedium?

Ein reines großes Sprachmodell ist im Wesentlichen zustandslos. Es kann zwar basierend auf dem Kontext den nächsten Text generieren, aber es speichert nicht automatisch den Fortschritt einer Aufgabe und pflegt auch nicht die Zustandsänderungen der Außenwelt. Die Aufgabe des Harness besteht darin, das Modell in eine reale Ausführungsumgebung einzubinden.

Code eignet sich als zentrales Trägermedium für den Harness, weil er drei Eigenschaften hat, die natürliche Sprache nicht besitzt: ausführbar, prüfbar und zustandsbehaftet.

Ausführbar bedeutet, dass die Absicht des Modells in reale Aktionen umgesetzt werden kann. Ein Plan ist nicht nur "Ich werde die Datei ändern", sondern kann in Shell-Befehle, Patches oder Testskripte umgesetzt werden.

Prüfbar bedeutet, dass der Ausführungsprozess objektive Rückmeldungen liefert. Kompilierungsfehler, Laufzeitfehler, Testergebnisse, Logs und Traces können dem System mitteilen, was gerade passiert, anstatt sich nur auf die Selbstbeschreibung des Modells zu verlassen.

Zustandsbehaftet bedeutet, dass der Fortschritt einer Aufgabe dauerhaft gespeichert werden kann. Repositories, Dateisysteme, Konfigurationen, Tests, Commit-Historie, Skill-Bibliotheken können alle aufzeichnen, was der Agent bereits getan hat, wo er fehlgeschlagen ist und wo er als nächstes weitermachen sollte.

Der größte Unterschied zwischen dieser Übersichtsarbeit und anderen Harness-Übersichten besteht also nicht darin, noch einmal Werkzeuge, Gedächtnis und Sandboxes aufzulisten, sondern darin, dass der Code in den Mittelpunkt gestellt wird: Der Code ist der stabilste und am besten handhabbare Zustandsträger im Harness.

Wie verbindet der Code die Schnittstellen des Harness?

Die erste Ebene dieser Übersichtsarbeit ist die Harness-Schnittstelle: Wie wird der Code zur Schnittstelle zwischen dem Modell und der Außenwelt?

Zunächst macht der Code die Inferenz ausführbar. In der Vergangenheit hat das Modell auf natürliche Sprache basierende Chain-of-Thought-Methoden zur Inferenz verwendet, aber die Textinferenz war schwer zu validieren. Methoden wie PoT und PAL wandeln die Zwischeninferenz in Programme um, sodass der Interpreter die Berechnungen durchführt; Arbeiten im Zusammenhang mit Lean/Coq machen die Inferenz sogar zu einem maschinenprüfbaren Beweisprozess. Der Schwerpunkt liegt nicht darin, dass "das Modell Programme schreiben kann", sondern darin, dass die Inferenz selbst in ein ausführbares Objekt externalisiert wird.

Zweitens macht der Code die Handlungen umsetzbar. Bei Claude Code oder Codex ist die Handlung nicht nur der Satz "Ich werde den Bug beheben", sondern es handelt sich um die tatsächliche Änderung von Dateien, das Ausführen von Tests, das Prüfen von Fehlern und das Generieren von Patches. Bei Robotern zeigen Arbeiten wie SayCan, Code as Policies und Voyager eine andere Form: Sprachziele werden in Skill-Aufrufe, Steuerungsskripte oder wiederverwendbare Funktionen umgewandelt.

Drittens macht der Code die Umwelt modellierbar. Damit ein Agent langfristig laufen kann, muss er den Zustand der Umwelt kennen. Software-Repositories, Testergebnisse, Ausführungslogs, DOM-Bäume, Simulatoren, Datenanalyse-Skripte können alle als strukturierte Repräsentationen dienen, mit denen der Agent die Welt versteht. Ausführbare Bewertungsumgebungen wie SWE-bench und AgentBench basieren genau auf diesem Prinzip: Aufgaben werden nicht mehr nur als statische Fragen und Antworten behandelt, sondern werden in einer ausführbaren Umgebung durchgeführt.

Nachdem der Code in die Harness-Schnittstelle eingetreten ist, ist die Inferenz nicht mehr nur Text, die Handlungen sind nicht mehr nur Versprechen, und die Umwelt ist nicht mehr nur eine Beschreibung. Sie alle werden zu Zuständen, die ausgeführt, geprüft und aktualisiert werden können.

Der Code verbindet auf der Schnittstellenebene Inferenz, Handlung und Umweltmodellierung und bringt die Inferenz, Handlungen und den Umweltzustand des Agenten in einen ausführbaren geschlossenen Kreis.

Der Entwicklungspfad des Codes auf der Schnittstellenebene.

Wie verwaltet der Harness Zustand und Feedback mithilfe von Code?

Wahre Aufgaben werden selten in einem Schritt abgeschlossen. Um einen Bug zu beheben, muss man möglicherweise mehrmals lokalisieren, ändern, testen und rückgängig machen; bei der Bedienung eines Web-Systems muss man möglicherweise über mehrere Seiten und Werkzeuge hinweg arbeiten; bei einem wissenschaftlichen Experiment muss man möglicherweise Hypothesen aufstellen, Simulationen ausführen, Daten analysieren und dann die nächsten Schritte entsprechend anpassen.

Hierbei ist es nicht nur wichtig, dass das Modell stärker wird, sondern auch, dass jeder Schritt des Agenten in einen kontrollierbaren Ausführungszyklus eingebunden werden kann.

Planning ist nicht mehr nur ein Plan im Kopf des Modells, sondern kann in Plan.md, Workflows oder ausführbare Aufgaben-Graphen umgewandelt werden. Memory ist nicht nur ein "größeres Kontextfenster", sondern es geht darum, welche Repository-Evidenzen, Ausführungslogs, fehlgeschlagene Erfahrungen, historische Patches in den externen Zustand gespeichert, komprimiert oder gelöscht werden sollten. Tool use ist nicht nur der API-Aufruf, sondern es handelt sich um die Veränderung der Außenwelt mithilfe von Terminalen, Sandboxes, Test-Frameworks, statischen Analyse-Tools und anderen Werkzeugen.

Der Kern ist der Plan-Execute-Verify-Zyklus. Der Plan definiert den Bereich der Aktionen, die Ausführung findet in einer Sandbox oder einer eingeschränkten Umgebung statt, und die Validierung basiert auf Tests, Lintern, statischer Analyse und Ausführungslogs. Systeme wie SWE-agent und OpenHands sind wichtig, nicht nur weil sie Werkzeuge aufrufen, sondern weil sie den Prozess von "Code schreiben - ausführen - fehlschlagen - beheben" in einen wiederholbaren Zustandsübergangsprozess organisieren.

Ein reifer Agent sollte keine Angst vor Fehlern haben. Fehlermeldungen, fehlgeschlagene Tests und Ausführungslogs sind genau die Feedback-Sensoren, mit denen der Code-Harness das Verhalten des Agenten steuert und ihn schrittweise konvergieren lässt.

Planung, Gedächtnis, Werkzeuggebrauch und Ausführungsfeedback bilden zusammen die codezentrierte Harness-Architektur und unterstützen den langfristigen Betrieb des Agenten.

Beim Zusammenspiel mehrerer Agenten ist der Code die gemeinsame Grundlage

Wenn eine Aufgabe zu komplex ist, um von einem einzelnen Agenten bewältigt zu werden, ist die Zusammenarbeit mehrerer Agenten eine natürliche Lösung. Ein Agent fungiert als Manager, ein anderer als Planer, ein weiterer schreibt Code, einer schreibt Tests und einer ist der Reviewer.

Das eigentliche Problem bei der Zusammenarbeit mehrerer Agenten liegt nicht darin, "mehrere Modelle zu einem Gespräch einzuladen", sondern darin, wie sie denselben Weltzustand teilen können.

Wenn mehrere Agenten nur über Chat-Nachrichten zusammenarbeiten, kann es leicht zu einem Zustandsdivergenz kommen: Jeder Agent denkt, er verstehe den aktuellen Fortschritt, aber sie haben möglicherweise keine gemeinsame Vorstellung davon, wie der Code tatsächlich geändert wurde, wo die Tests fehlgeschlagen sind und welche Änderungen bereits wirksam geworden sind.

Der Code bietet hier eine stabilere gemeinsame Grundlage. Repositories, Tests, Pull Requests, Issues, CI-Logs, Review-Kommentare, Ausführungs-Traces können alle von mehreren Agenten gemeinsam gelesen, geschrieben und validiert werden. Echte Zusammenarbeit bedeutet nicht "sich gegenseitig zu überzeugen", sondern es geht darum, sich um den geteilten Programmzustand herum ständig zu konvergieren.

Die gemeinsame Sprache eines Mehr-Agenten-Systems sollte nicht nur die natürliche Sprache sein, sondern ein ausführbarer, geteilter Codezustand.

Im Mehr-Agenten-System bilden geteilte Repositories, Tests, Ausführungszustände und Workflows die Grundlage für die Zusammenarbeit.

Von Claude Code bis hin zu Robotern:

Der Code wird zur Agent-Betriebssystem

Es ist nicht überraschend, dass die Idee von "Code as Agent Harness" zuerst in Coding-Agenten sichtbar wurde. Die Softwarewelt ist von Natur aus ausführbar, testbar, rückgängig machbar und aufzeichnbar und eignet sich daher am besten als Musterbeispiel für die Implementierung von Agenten.

Aber dieser Trend endet nicht bei der Code-Schreibung. Bei GUI/OS-Agenten werden Webseiten und Betriebssysteme in programmierbare Umgebungen umgewandelt. DOM-Bäume, Barrierefreiheits-Bäume, Playwright-Skripte machen die Bedienung von Benutzeroberflächen zu ausführbaren Zustandsübergängen. Bei Robotern müssen sprachliche Absichten in Skill-Bibliotheken, Steuerungsskripte und Simulationsrückmeldungen umgewandelt werden. Abstrakte Ziele können nur dann von physikalischen Beschränkungen geprüft werden, wenn sie in ausführbaren Code umgesetzt werden. Bei der wissenschaftlichen Entdeckung können Hypothesen, Experimente, Simulationen, Datenanalyse und Experimentprotokolle in eine Code-Pipeline organisiert werden. Der Agent erzeugt nicht nur Ideen, sondern treibt den Entdeckungsprozess mithilfe einer ausführbaren Pipeline voran.

Deshalb werden viele zukünftige Agenten möglicherweise nicht alle "Coding-Agenten" genannt werden, aber es ist wahrscheinlich, dass sie alle auf einem codezentrierten Harness laufen werden.