Doc2Harness prüft, wie zuverlässig KI-Modelle Coding-Agent-Harnesses bauen

Zwei Phasen trennen Bau und Prüfung

Doc2Harness ist als zweistufiger Ablauf angelegt. In der ersten Phase erhält jedes Build-Modell dieselben Eingaben innerhalb derselben Builder-Umgebung: ein Entwicklungsdokument, das Verhaltensweisen aus der Dokumentation von zwölf Harnesses zusammenführt, und ein Gerüst mit Schnittstellen. Dieses Gerüst umfasst laut Projektbeschreibung fünf Python-Dateien und drei unveränderliche Schnittstellen, enthält aber noch keine Implementierung. Als Builder-Harness wird OpenCode verwendet. [5]

Das Modell soll daraus einen vollständigen, ausführbaren Coding-Agent-Harness erstellen. Nach der Abgabe prüft die erste Phase die Form der Einreichung, führt aber noch keine der späteren Tests aus. Der Kandidat wird anschließend eingefroren. In der zweiten Phase wird er in eine separate, isolierte Umgebung verschoben und dort von einem Skript mit einem simulierten Modell durch die Tests geführt. [5]

Diese Trennung ist für die Aussagekraft wichtig: Bewertet wird nicht, ob das Modell in einer einzelnen Unterhaltung einen Programmierauftrag löst, sondern ob es ein System baut, das in vorgegebenen Abläufen die erwarteten Funktionen ausführt. Weil Builder und Treiber festgelegt sind, sollen die Unterschiede zwischen den Kandidaten vor allem auf die Modelle zurückgehen, die den Harness geschrieben haben. Das ist eine Analyse des Versuchsaufbaus, keine Aussage darüber, wie sich die Systeme in jeder realen Entwicklungsumgebung verhalten. [5]

Vier beobachtbare Kanäle statt Selbstbewertung

Die Testauswertung stützt sich auf vier Signale: Anfragen, die der Harness an das Modell sendet, den Zustand der Dateien auf dem Datenträger, den Exit-Code des Prozesses und die Ausgabe von Kommandos. Der Benchmark verlässt sich damit nicht allein auf die Behauptung des zu prüfenden Harnesses, eine Funktion sei erfolgreich ausgeführt worden. [5]

Zusätzlich setzt Doc2Harness positive Kontrollen ein. Sie sollen prüfen, ob die Voraussetzungen einer Testaussage tatsächlich erfüllt sind. Bei einem Test zum Schutz vor Zugriffen außerhalb des Arbeitsbereichs wäre beispielsweise das bloße Fehlen verbotener Dateiinhalte kein hinreichender Erfolgsnachweis: Auch ein grundsätzlich defektes Lese-Werkzeug könnte dazu führen. Kontrollen prüfen deshalb unter anderem, ob der Leseweg grundsätzlich funktioniert und ob ein Zugriff auf einen erlaubten Pfad gelingt. Nur wenn der Test und seine relevanten Kontrollen bestehen, zählt der Fall als bestanden. [5]

Positive Kontrollen fließen laut Beschreibung nicht in den Nenner der Passrate ein. Sie dienen dazu, triviale oder irreführende Erfolge zu vermeiden, bei denen zwar das erwartete Ergebnis sichtbar ist, aber nicht aus dem geprüften Sicherheitsmechanismus folgt. Für Unternehmen ist das ein relevanter methodischer Punkt: Ein Benchmark für Berechtigungen muss nicht nur das gewünschte Resultat, sondern auch die Funktionsfähigkeit des Prüfpfads absichern. [5]

Die Rangfolge hängt auch von der Art des Tests ab

Über alle 328 Testfälle hinweg erzielt GPT-6 Astra mit 53,05 Prozent den höchsten Wert. Daraus folgt rechnerisch, dass auch dieses Modell in 46,95 Prozent der Fälle nicht als bestanden gewertet wurde. Hy3 kommt auf 27,44 Prozent; der Abstand zwischen beiden beträgt rund 25,6 Prozentpunkte. Die Resultate sind jeweils Mittelwerte aus drei Builds pro Modell. [5]

Die Projektseite zeigt außerdem, dass eine Gesamtwertung Unterschiede zwischen Aufgabentypen verdecken kann. In gewöhnlichen Szenarien liegt Opus 5 bei 80,68 Prozent vor GPT-6 Astra mit 72,46 Prozent. Bei den als Grenzfälle ausgewiesenen Szenarien kehrt sich die Reihenfolge um: GPT-6 Astra erreicht 48,97 Prozent, Opus 5 37,02 Prozent. [5]

Auch in sechs größeren Kategorien, die jeweils mindestens 20 Fälle enthalten, verschieben sich die Modellränge laut Auswertung um bis zu 16 Plätze. Die 15 paarweisen Korrelationen zwischen diesen Kategorien seien zwar positiv, die Rangabweichungen zeigten aber dennoch, dass ein Spitzenplatz in einer Teilaufgabe keine einheitliche Stärke in allen Bereichen garantiert. [5]

Was die Tests abdecken – und was nicht

Die Testsuite umfasst neun Kategorien. Die Projektbeschreibung nennt unter anderem Dateizugriffe und Berechtigungen, ein interaktives Terminal sowie Prüfungen von Artefakten, dem Programmstart und der Erkennung von Erweiterungen. Die Aufgaben prüfen damit verschiedene Funktionen eines Harness, nicht nur, ob er grundsätzlich startet oder eine einzelne Anfrage weiterleitet. [5]

Für die Bewertung von Sicherheitsfunktionen ist die Trennung zwischen einem funktionierenden und einem fehlerhaften Kontrollpfad besonders wichtig. Die beschriebene Symlink-Prüfung etwa soll sicherstellen, dass Inhalte außerhalb des Arbeitsbereichs nicht an das Modell gelangen, während ein erlaubter Lesezugriff innerhalb des Arbeitsbereichs weiterhin möglich sein muss. Solche Fälle prüfen zugleich Schutzgrenzen und deren praktische Funktionsfähigkeit. [5]

Die Ergebnisse sind dennoch nicht gleichbedeutend mit einer Messung der Produktionsreife. Das Benchmarkdesign prüft Kandidaten in einer kontrollierten Umgebung anhand einer festgelegten Spezifikation und skriptgesteuerter Szenarien. Daraus lässt sich nicht direkt ableiten, wie ein Harness mit den unterschiedlichen Werkzeugen, Richtlinien und Arbeitsabläufen eines konkreten Unternehmens zurechtkommt. Diese Grenze ergibt sich aus dem beschriebenen Testaufbau. [5]

Architektur: Mehr Module sind nicht automatisch besser

Neben den Passraten untersuchten die Autoren den Quellcode von 57 Builds – drei für jedes der 19 Modelle. Ein Ergebnis betrifft die Aufteilung der Implementierung: Bei vergleichbarem Umfang sei eine höhere Modulzahl mit niedrigeren Erfolgsraten verbunden. Die Projektseite nennt für diesen Zusammenhang eine partielle Korrelation von minus 0,423. [5]

Die Autoren weisen ausdrücklich darauf hin, dass daraus keine Kausalität folgt. Die Beobachtung zeigt also nicht, dass eine stärkere Modularisierung an sich die Qualität verschlechtert. Denkbar ist vielmehr, dass die Art der Aufteilung mit anderen Entscheidungen in der Implementierung zusammenhängt. Die Projektseite berichtet zudem, dass der Zusammenhang bei einer Prüfung unter Ausschluss jeweils eines Modells bestehen blieb; das ist ein Robustheitshinweis innerhalb dieser Stichprobe, aber kein Beleg für einen allgemeinen Architekturgrundsatz. [5]

Für Entwicklungsverantwortliche ist deshalb nicht die bloße Zahl von Dateien oder Modulen entscheidend. Aussagekräftiger ist, ob eine Architektur die geforderten Abläufe, Berechtigungsgrenzen und Fehlerbehandlungen tatsächlich zuverlässig umsetzt. Das ist eine aus den Benchmarkbefunden abgeleitete Einordnung, keine vom Benchmark direkt gemessene Kennzahl. [5]

Bedeutung für die Beschaffung und interne Evaluation

Doc2Harness legt eine Lücke zwischen Modellvergleich und Systemvergleich offen: Übliche Tests können die Leistung eines Agenten unter einem festgelegten Harness bewerten; dieser Benchmark nimmt stattdessen den Bau der umgebenden Steuerungssoftware selbst in den Blick. Für Unternehmen, die Coding-Agenten einsetzen oder intern anpassen, kann das die Evaluierung ergänzen. Ein Modell, das bei einer Programmieraufgabe gut abschneidet, ist nicht automatisch auch darin stark, robuste Sitzungsverwaltung, Werkzeugsteuerung oder Berechtigungslogik zu implementieren. [5]

Die niedrige Spitzenquote spricht dafür, Ergebnisse nicht nur als Gesamtwert zu betrachten. Für einen Einsatz mit erhöhten Anforderungen an Dateizugriffe können Berechtigungsfälle wichtiger sein als ein Durchschnitt über alle Kategorien; für Entwicklungsarbeit mit langen Sitzungen können dagegen Wiederaufnahme und Zustandsverwaltung stärker ins Gewicht fallen. Welche Gewichtung angemessen ist, hängt vom jeweiligen Einsatz ab. Die Benchmarkseite weist unterschiedliche Kategorien und Rangverschiebungen aus, gibt aber keine unternehmensspezifische Gewichtung vor. [5]

Praktisch folgt daraus: Ein Vergleich sollte neben der Gesamtpassrate die relevanten Tests, die Kontrollen hinter einem erfolgreichen Ergebnis und die konkrete Implementierung berücksichtigen. Außerdem sollten Sie berücksichtigen, dass drei Builds je Modell zwar wiederholte Beobachtungen ermöglichen, aber keine Garantie dafür liefern, dass ein System unter allen Produktionsbedingungen gleich abschneidet. Die Projektseite nennt für diesen Vergleich drei unabhängige Builds pro Modell. [5]

Ein nützlicher Messpunkt, aber kein Produktionsnachweis

Doc2Harness macht Harness-Engineering messbarer, indem es den Bau eines Coding-Agent-Systems von dessen anschließender Ausführung trennt und beobachtbare Kriterien für die Bewertung festlegt. Die Ergebnisse zeigen zugleich, dass selbst der bestplatzierte Kandidat in diesem Versuchsaufbau fast die Hälfte der Fälle nicht besteht und dass die Rangfolge je nach Szenariotyp wechseln kann. [5]

Für B2B-Teams ist das vor allem als Hinweis auf die Notwendigkeit eigener, einsatznaher Prüfungen relevant. Der Benchmark liefert einen vergleichbaren Ausgangspunkt für die Fähigkeiten von Modellen beim Aufbau eines Harness; er ersetzt jedoch weder Sicherheitsprüfungen noch die Validierung mit den eigenen Werkzeugen, Berechtigungen und Arbeitsabläufen. Diese Schlussfolgerung folgt aus dem Abstand zwischen dem kontrollierten Benchmarkaufbau und einer konkreten Unternehmensumgebung. [5]

Quellen

1. [1] RT by @_akhaliq: Doc2Harness: The first benchmark for long-horizon harness engineering of coding agents 19 frontier models, 328 test cases, best pass rate only 53% — even the strongest fails half. From ICT-CAS. — https://x.com/HuggingPapers/status/2110765616101540224 (abgerufen am 2026-10-15)
2. [5] Doc2Harness: Benchmarking LLMs on Long-Horizon Harness Engineering of Coding Agents | YuyaoGe's Website — https://geyuyao.com/publication/ge2026doc2harness (abgerufen am 2026-10-15)