Welche Teile eines Coding-Agent-Harness wirklich helfen

Was die Arbeit untersucht

Ein Coding-Agent besteht nicht nur aus einem Sprachmodell. Das Modell läuft in einem „Harness“ (einer Ausführungsumgebung): einer Softwareschicht mit einer Steuerschleife, einer Werkzeugschnittstelle und Regeln, die festlegen, welche Teile des bisherigen Verlaufs das Modell behält. Die Arbeit „An Empirical Study of Harness Design for Coding Agents“ (arXiv 2609.20804, eingereicht am 17. September 2026) fragt, welche Teile dieser Schicht wirklich etwas bewirken. Neun Autoren der UMass Amherst, der Emory University und der UNC Charlotte haben sie verfasst. Die Arbeit vermerkt, dass ein Teil der Arbeit während Praktika bei Zoom Video Communications entstand.

Die Autoren sagen, frühere Studien verglichen meist vollständige Harnesses. Sie führen eine Harness-übergreifende Bewertung an, in der Claude-Opus-4.5 mit OpenHands am besten abschnitt, Claude-Sonnet-4.5 dagegen mit SWE-Agent. Ein solches Ergebnis zeigt nicht, ob der Gewinn aus der Planung, dem Werkzeugdesign, dem Kontextmanagement oder dem Zusammenspiel mit dem Modell kommt. Deshalb bauten die Autoren einen schlanken Harness von Grund auf. Seine ReAct-Schleife bleibt fest. Sie variieren nur drei Komponenten: die Planung (Planning), den Aktionsraum (Action Space) und das Kontextmanagement (Context Management). Rechteverwaltung, Diagnosen nach Änderungen und Erkennung von Festhängern bleiben in allen Läufen unverändert.

Der Aufbau in Kürze

Der Harness basiert auf LangGraph, und die Benchmarks laufen über Harbor. Jede Aufgabe erhält höchstens 300 Schritte. Die Arbeit testet vier Modelle: drei Größen von Nemotron-3 (30B, 120B und 550B) und Mistral-Medium-3.5-128B. Sie nutzt zwei Benchmarks. SWE-Bench Verified enthält 500 von Menschen geprüfte GitHub-Issues. Terminal-Bench 2.1 enthält 89 Kommandozeilenaufgaben. Die Arbeit berichtet die Erfolgsquote und die mittleren Kosten je Aufgabe, berechnet mit den Preisen von OpenRouter.

Das Kontextmanagement hat fünf Stufen. T0 tut nichts und endet mit einem Fehler, wenn das Fenster überläuft. T1 ersetzt veraltete Werkzeugausgaben durch kurze Platzhalter (Elision, also Auslassung). T2 fügt einen externen Speicher und ein Werkzeug recall_event hinzu, sodass ausgelassene Inhalte wieder gelesen werden können. T3 nutzt nur die Zusammenfassung durch ein LLM. T4 verbindet alle drei in Stufen: zuerst Auslassung, und nur wenn der Verlauf noch zu lang ist, eine Zusammenfassung. Die weiche und die harte Schwelle liegen bei 0,6 und 0,85 des nutzbaren Fensters. Die Autoren führen alle fünf Stufen mit Fenstern von 32k, 64k, 96k und 128k Tokens aus. Planung und Aktionsraum (vordefinierte Werkzeuge gegen nur bash) werden nur mit T4 und einem 128k-Fenster einzeln untersucht. Insgesamt ergibt das 176 zugeordnete Einstellungen. Die Autoren vergleichen Erfolgsquoten mit zweiseitigen exakten McNemar-Tests und kontrollieren die False Discovery Rate bei 0,05.

Vier Befunde mit den Zahlen der Arbeit

1. Kontextmanagement zählt am meisten, wenn das Fenster knapp ist. Im Mittel über die Modelle sinkt die Lücke zwischen den verwalteten Stufen (T1 bis T4) und T0 auf SWE-Bench von 35,7 auf 15,9, dann 5,5 und 2,7 Prozentpunkte, wenn das Fenster von 32k auf 128k wächst. Auf Terminal-Bench sinkt sie von 9,5 auf 7,5, 4,8 und 2,8. Die Überlauf-Ausfallrate von T0 fällt auf SWE-Bench von 78,7 % auf 8,7 % und auf Terminal-Bench von 61,0 % auf 12,1 %. Alle verwalteten Stufen haben bei jedem Budget null Überlaufausfälle. Ein Beispiel aus Tabelle 3: Bei 32k erreicht Nemotron-3 550B auf SWE-Bench mit T0 6,40 % und mit T4 55,60 %. Die Arbeit folgert, dass der größte Teil des Nutzens daher kommt, ein vorzeitiges Abschneiden zu verhindern. 2. Gestufte Auslassung mit Zusammenfassung (T4) ist am effizientesten; der Abruf bringt wenig. T4 erreicht ähnliche Erfolgsquoten wie T1 bis T3. Es hat in sieben von acht Modell-Benchmark-Feldern die niedrigsten Kosten und bei jedem Fensterbudget die niedrigsten mittleren Kosten je Aufgabe. Auch das Verhältnis des Spitzenkontexts ist bei allen vier Budgets am niedrigsten. Bei 32k erreichen T1 und T2 noch fast das ganze Fenster. Der Abrufmechanismus ist eine andere Geschichte. In 32 zugeordneten Vergleichen schlug T2 die Stufe T1 in 15 Einstellungen, verlor in 14 und lag in drei gleichauf. Die mittlere Differenz beträgt minus 0,36 Punkte. In 36 von 64 Einstellungen (56,3 %) rief das Modell recall_event nie auf. Die mittlere Zahl der Abrufe je Aufgabe sank von 0,540 bei 32k auf 0,007 bei 128k.

3. Planung wandelt sich vom Genauigkeitsgerüst zum Kostensparer. Bei Nemotron-3 30B erhöhte die Planung die Erfolgsquote um 11,6 Punkte auf SWE-Bench und um 4,5 Punkte auf Terminal-Bench, bei höheren Kosten. Beim 120B-Modell gab es keinen einheitlichen Gewinn. Bei Nemotron-3 550B und Mistral-Medium-3.5-128B senkte die Planung die Kosten auf SWE-Bench um etwa 30 % und 32 %, während der Erfolg um 2,0 und 0,4 Punkte fiel. 4. Der beste Aktionsraum hängt vom Modell ab. Bei Nemotron-3 30B erhöhte der vordefinierte Werkzeugsatz den Erfolg um 15,0 Punkte auf SWE-Bench und um 10,1 Punkte auf Terminal-Bench. Bei Nemotron-3 550B erhöhte „nur bash“ den Erfolg um 3,6 und 5,6 Punkte und senkte die Kosten um 53 % und 30 %. Mistral ist gemischt: Der volle Werkzeugsatz ist auf SWE-Bench besser (23,2 Punkte mehr), aber „nur bash“ bringt auf Terminal-Bench 6,7 Punkte dazu.

Was die Verläufe zeigen

Die Autoren haben außerdem jeden Zug der Agentenläufe mit einer Arbeitsphase gekennzeichnet, mithilfe eines LLM-Bewerters. Ihre Deutung erklärt die vier Befunde. Kontextmanagement macht die Läufe vor allem länger. Bei 32k ohne Verwaltung dauern die mittleren SWE-Bench-Verläufe 20 bis 30 Züge, und die meisten Läufe enden noch während der Lokalisierung des Fehlers. Mit Verwaltung steigen die mittleren Längen auf etwa 50 bis 180 Züge, und die Läufe erreichen die Überprüfung.

Planung wirkt bei schwachen und starken Modellen anders. Bei Nemotron-3 30B auf SWE-Bench senkte das Abschalten der Planung den mittleren Verlauf von 40 auf 5 Züge. Ohne Planung endeten 68,6 % der Läufe ohne jede Änderung, mit Planung 27,8 %. Bei den beiden stärksten Modellen verkürzte die Planung den mittleren Lauf von 108 auf 74 Züge (550B) und von 68 auf 53 Züge (Mistral). Die Autoren führen den größten Teil davon auf weniger Überprüfung nach der Änderung zurück. Der Aktionsraum verändert, wie Code geschrieben wird. Bei Nemotron-3 30B auf Terminal-Bench endeten 66 % der Läufe mit „nur bash“, nachdem das Modell Aufrufe von Werkzeugen ausgegeben hatte, die im Register für „nur bash“ nicht vorhanden sind. Der mittlere Lauf schrumpfte von 71 auf 15 Züge. Beim 550B-Modell auf Terminal-Bench senkte „nur bash“ den mittleren Verlauf von 47 auf 31 Aktionen und hob den Anteil der Code-Schreib-Aktionen von 16 % auf 27 %. Wiederholte Korrekturen an bereits geänderten Dateien nahmen bei allen vier Modellen ab, zum Beispiel beim 30B von 3,3 auf 0,4.

Unsere Analyse

Nach unserer Lesart geht es der Arbeit vor allem um Bedingungen, nicht um Sieger. Jeder Befund enthält ein „Wenn“: wenn das Fenster knapp ist, wenn das Modell schwach ist, wenn das Modell gut mit bash umgeht. Ein einziger Standard-Harness kann nicht zu allen diesen Fällen passen. Wer berichtet, „Harness A schlägt Harness B“, sollte auch das Modell, das Budget und die Aufgabenart nennen.

Ein zweites Thema ist, dass zusätzliche Technik nicht umsonst ist. Das Abrufwerkzeug fügte Technik hinzu, und die Modelle nutzten es selten. Vordefinierte Werkzeuge halfen einem schwachen Modell, schienen einem starken aber Aufwand zu bringen, in den Worten der Autoren „Aufwand bei Aktionsauswahl und Interaktion“. Zugleich sagen die Ergebnisse nicht, „einfacher sei immer besser“. „Nur bash“ halbierte beim 550B-Modell fast die Kosten, schadete aber dem 30B-Modell stark und schadete Mistral auf SWE-Bench.

Ein dritter Punkt betrifft die Kosten. Die Dollarbeträge hängen von den OpenRouter-Preisen vom August 2026 für genau diese Modelle ab. Die Richtung eines Effekts, etwa weniger Züge nach der Planung, lässt sich besser übertragen als die Dollarwerte.

Grenzen und offene Fragen

Die Autoren nennen mehrere Grenzen. Die Ergebnisse gelten für die konkreten Komponenten, die sie gebaut haben, nicht für einen universell besten Harness. Planung und Aktionsraum werden nur mit T4 und einem 128k-Fenster einzeln untersucht; für andere Kombinationen wäre eine vollständige faktorielle Studie nötig. Jede Einstellung läuft pro Aufgabe nur einmal. Terminal-Bench hat nur 89 Aufgaben, daher sind viele Kontraste dort im McNemar-Test nicht signifikant, und die Autoren stützen sich auf gleichgerichtete Tendenzen über Modelle und Budgets hinweg. SWE-Bench Verified enthält nur Python. Die Modellgröße ist ein unvollkommener Stellvertreter für die Fähigkeit, und die Autoren sagen, die Kreuzungspunkte sollten geprüft werden, bevor man sie auf andere Modellfamilien, Harnesses oder Aufgaben überträgt. Sie merken auch an, dass die Änderung des Aktionsraums mehrere Dinge bündelt: die Verfügbarkeit der Werkzeuge, die Prompts, die Verfolgung des Dateizustands und automatische Diagnosen.

Wir fügen zwei Grenzen hinzu, die daraus folgen, dass wir nur den Text der Arbeit gelesen haben. Wir haben den Code nicht ausgeführt und die Tabellen nicht neu geprüft. Und die Studie nutzt eine Familie mit offenen Gewichten plus ein weiteres Modell. Über die geschlossenen Spitzenmodelle, die viele kommerzielle Coding-Werkzeuge verwenden, sagt sie nichts.

Praktische Hinweise

Für Teams, die Coding-Agenten bauen, legt die Arbeit einige Gewohnheiten nahe. Messen Sie, wie oft lange Läufe an die Kontextgrenze stoßen, bevor Sie raffinierte Gedächtnisfunktionen hinzufügen, denn die Arbeit findet, dass der größte Nutzen darin liegt, Überläufe zu vermeiden. Probieren Sie die günstige, regelbasierte Auslassung, bevor Sie für die Zusammenfassung durch ein LLM zahlen.

Nehmen Sie nicht an, dass ein Abrufwerkzeug genutzt wird: Prüfen Sie die Aufrufprotokolle. Testen Sie die Planung für jedes Modell einzeln, denn sie kann bei einem schwachen Modell die Kosten erhöhen und bei einem starken senken. Testen Sie für starke Modelle eine Schnittstelle mit „nur bash“, behalten Sie aber strukturierte Werkzeuge für Modelle mit schwachen Shell-Fähigkeiten. Wiederholen Sie schließlich diese Prüfungen, wenn Sie das Modell oder das Kontextbudget ändern.