🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

Diese Arbeit zeigt, dass die Beschränkung von Coding-Agenten auf ein einziges `execute_code`-Tool oft ebenso effektiv und häufig kostengünstiger ist als die Verwendung tool-reicher Umgebungen, was offenlegt, dass die optimale Tool-Oberfläche gemeinsam durch das Zusammenspiel zwischen Aufgabenregimen und spezifischen Agenten-Designs bestimmt wird, anstatt durch einen dieser Faktoren allein.

Ursprüngliche Autoren: Hong Yang, Qi Yu, Travis Desell

Veröffentlicht 2026-07-14

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Hong Yang, Qi Yu, Travis Desell

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen superintelligenten Roboter-Assistenten, dessen Aufgabe es ist, kaputten Code zu reparieren oder mathematische Rätsel zu lösen. Im Moment gibt es in der Tech-Welt eine riesige Debatte darüber, wie dieser Roboter mit dem Computer kommunizieren sollte, um seine Arbeit zu erledigen.

Einige sagen: „Gib ihm einen vollständigen Werkzeugkasten mit Spezialknöpfen für jede Aufgabe!“ (Wie eine schicke IDE).
Andere sagen: „Gib ihm einfach eine Kommandozeile und lass ihn Shell-Befehle eintippen!“ (Wie ein Hacker in einem Film).
Eine dritte Gruppe sagt: „Nee! Lass den Roboter einfach ein Python-Skript schreiben und es alles auf einmal ausführen!“ (Der execute_code-Ansatz).

Dieses Paper ist wie ein riesiger, fairer Schiedsrichter, der ein Rennen organisiert, um zu sehen, welche Methode tatsächlich Geld spart und die Arbeit erledigt. Sie haben nicht nur geraten; sie haben exakt denselben Roboter (zwei verschiedene Modelle: Claude und Codex) auf exakt densamen Aufgaben laufen lassen, aber dabei nur die Werkzeuge geändert, die ihm zur Verfügung standen.

Hier ist das, was sie herausgefunden haben, aufgeschlüsselt in einfachen Geschichten.

Die Hauptentdeckung: Es kommt auf den Roboter und den Job an

Die größte Überraschung? Es gibt nicht das eine „beste“ Werkzeug. Der Gewinner ändert sich, je nachdem, wer der Roboter ist und was er tut.

Denken Sie an Folgendes:

Der „Mathematik-Rätsel“-Job (Artifact-Aufgaben): Wenn der Roboter Berechnungen oder Datenverarbeitung durchführt, ist die Methode „ein Skript schreiben und ausführen“ (code_only) der klare Gewinner. Es ist, als würde man einen Koch engagieren, der einfach ein perfektes Rezept schreibt und die ganze Mahlzeit in einem Rutsch kocht.
- Für den Claude-Roboter sparte diese Methode 24,6 % an Kosten.
- Für den Codex-Roboter sparte er etwa 6,7 % (obwohl das Paper anmerkt, dass dieses Ergebnis etwas unsicher ist, wie ein Münzwurf).
- Urteil: Für Mathe und Daten ist die Skript-Methode günstiger und genauso gut darin, das Problem zu lösen.
Der „Aufräumen eines unordentlichen Codebases“-Job (SWE-bench-Aufgaben): Hier wird es knifflig. Diese Aufgaben beinhalten das Bearbeiten vieler Dateien in einem komplexen Projekt.
- Wenn Sie den Codex-Roboter verwenden: Die Skript-Methode ist immer noch der Champion! Sie sparte 19,9 % an Kosten. Warum? Weil die Skript-Methode es dem Roboter ermöglicht, viele kleine Anfragen in ein großes Paket zu schnüren, wie ein Lieferwagen, der 50 Pakete transportiert, anstatt eine Person, die 50 Mal zu Fuß geht.
- Wenn Sie den Claude-Roboter verwenden: Oh weh. Die Skript-Methode wurde tatsächlich teurer (um 14,4 %), obwohl das Paper anmerkt, dass dies kein statistisch „bewiesener“ Unterschied war, sondern nur ein starker Trend. Warum? Weil es für Claude, eine Datei per Skript zu bearbeiten, so ist, als würde man versuchen, einen Reifen zu wechseln, indem man zuerst ein neues Auto baut. Es braucht viel zu viele Wörter (Tokens), um die Änderung im Code zu erklären, was „Edit-Friction“ (Bearbeitungsreibung) erzeugt.

Was das Paper ausschließt

Das Paper argumentiert explizit dagegen, dass eine Werkzeugoberfläche immer besser für alle ist.

Es schließt aus: „Spezielle IDE-Buttons sind immer erforderlich.“ (Weil die Skript-Methode bei Codex gewann).
Es schließt aus: „Bash-Befehle sind immer ausreichend.“ (Weil die Skert-Methode bei Claude für Matheaufgaben günstiger war).
Es schließt aus: „Code-Ausführung ist immer am günstigsten.“ (Weil sie für Claude bei komplexen Code-Fixes teurer war).

Die Autoren sind sich sehr sicher: Man kann ein Werkzeug nicht einfach basierend auf dem Werkzeug selbst auswählen. Man muss die Kombination aus dem Gehirn des Roboters und der Art der Arbeit betrachten.

Die Überraschung bei der „Pass Rate“ (Erfolgsquote)

Hier ist der wichtigste Teil: Die Kosten änderten sich, aber die Erfolgsquote blieb gleich.

Stellen Sie sich zwei Läufer vor. Einer läuft in schweren Stiefeln (teure Werkzeuge) und der andere in Sneakern (günstige Werkzeuge). Das Paper fand heraus, dass beide Läufer das Rennen exakt mit der gleichen Geschwindigkeit beendet haben.

Unabhängig davon, ob der Roboter das schicke Werkzeugset, die Bash-Befehle oder die Skript-Methode verwendete, die prozentuale Anzahl der korrekt gelösten Aufgaben war fast identisch (innerhalb von 3 Prozentpunkten).
Die „Skript“-Methode hat den Roboter weder klüger noch dümmer gemacht; sie hat nur verändert, wie er die Ziellinie erreichte. Manchmal war dieser Weg ein Sprint (billig) und manchmal ein Stolpern (teuer).

Warum änderten sich die Kosten?

Das Paper geht der Frage nach, warum die Skript-Methode günstiger oder teurer war.

Die „Edit-Friction“-Steuer (Für Claude): Wenn Claude eine Datei mittels der Skript-Methode ändern musste, musste es ein langes Python-Skript schreiben, nur um zu sagen: „Ändere Zeile 5“. Dies verbrauchte viele „Output-Tokens“ (Wörter, die der Roboter tippen musste). Es war, als müsste man jedes Mal eine Gebühr bezahlen, wenn man eine Seite umblättern wollte. Dies geschah meist bei Aufgaben, bei denen der Roboter scheiterte oder Schwierigkeiten hatte, was diese spezifischen Durchläufe sehr teuer machte.
Der „Batching“-Bonus (Für Codex): Wenn Codex die Skript-Methode verwendete, konnte es viele kleine Befehle in ein Skript packen. Anstatt den Computer zu fragen: „Lies Datei A“, dann „Lies Datei B“, dann „Lies Datei C“ (drei separate Wege), fragte es: „Lies A, B und C“ in einem Rutsch. Das sparte eine Menge „Input-Tokens“ (Wörter, die der Roboter lesen musste).
Der „Doomed Run“-Effekt (Der gescheiterte Versuch): Die zusätzlichen Kosten für Claude bei den Code-Fix-Aufgaben traten hauptsächlich auf, wenn der Roboter ohnehin gerade dabei war zu scheitern. Es war wie ein Auto, dem mitten im Kreisfahren der Sprit ausgeht. Die Skript-Methode hat das Scheitern nicht verursacht; sie hat nur den gescheiterten Versuch teurer gemacht.

Wie sicher sind wir?

Die Autoren sind sehr sicher bei den Mathematik-Aufgaben und den Codex-Roboter-Ergebnissen. Sie führten diese Tests an 93 Mathematik-Aufgaben und 100 Code-Fix-Aufgaben durch, wobei sie für jede drei verschiedene „Seeds“ (zufällige Startpunkte) verwendeten, um sicherzustellen, dass die Ergebnisse nicht nur Glück waren. Die Einsparungen für Codex bei den Code-Fix-Aufgaben waren statistisch signifikant (ein Rückgang von 19,9 % mit einem p-Wert von 2,0 × 10⁻⁹, was praktisch null Chance auf Zufall bedeutet).

Für den Claude-Roboter bei den Code-Fix-Aufgaben ist das Ergebnis jedoch etwas unklarer. Die Kosten stiegen um 14,4 %, aber der statistische Test ergab, dass dies kein „Slam Dunk“-Beweis war (p-Wert von 0,12). Die Autoren bezeichnen dies als „direktional“, was bedeutet, dass der Trend zwar da ist, man aber die Tests öfter durchführen müsste, um zu 100 % sicher zu sein, dass es kein Zufall ist.

Das Fazit

Wenn Sie einen Coding-Agenten bauen:

Raten Sie nicht. Das „beste“ Werkzeug hängt von Ihrem spezifischen Roboter und Ihrer spezifischen Aufgabe ab.
Für Mathe/Daten: Probieren Sie die „Schreibe ein Skript“-Methode aus. Sie ist günstiger und funktioniert genauso gut.
Für Code-Fixes: Es kommt darauf an. Wenn Sie Codex verwenden, ist die Skript-Methode großartig. Wenn Sie Claude verwenden, sollten Sie vielleicht die Standard-Editier-Werkzeuge behalten, besonders bei schwierigen Problemen, da die Skript-Methode in der „Edit-Friction“ stecken bleiben könnte.
Machen Sie sich keine Sorgen um die Intelligenz: Die Werkzeuge zu ändern, wird Ihren Roboter weder klüger noch dümmer machen; es ändert nur den Preisschild des Weges.

Das Paper kommt zu dem Schluss, dass der „billigste“ Weg, einen Agenten zu betreiben, keine universelle Regel ist; es ist ein Puzzle, bei dem man das Werkzeug auf den Roboter und die Aufgabe abstimmen muss.

Technisches Resümee: Wann hilft die Beschränkung eines Coding-Agenten auf `execute_code`?

Problemstellung

Das Feld der Coding-Agenten operiert derzeit unter drei sich gegenseitig ausschließenden Behauptungen hinsichtlich der optimalen „Tool-Oberfläche“ (der Menge der dem Agenten exponierten Schnittstellen):

Spezialisierte IDE-Primitive sind erforderlich: Strukturierte Schnittstellen (z. B. Agent-Computer Interface oder ACI) schneiden signifikant besser ab als roher Shell-Zugriff, wie von SWE-agent argumentiert wird.
Bash ist ausreichend: Minimale, rein auf Bash basierende Gerüste können auf Software-Engineering-Benchmarks ohne IDE-Primitive wettbewerbsfähige Leistungen erzielen.
Code-Ausführung ist optimal: Das Routing von Agenten-Aktionen durch ein einzelnes execute_code-Tool (via Model Context Protocol, MCP) reduziert den Token-Verbrauch drastisch im Vergleich zum direkten Aufruf nativer Tools.

Vorherige Arbeiten haben diese Widersprüche nicht aufgelöst, da bestehende Studien eine einzelne Variable fixieren (z. B. den Vergleich von ACI vs. Shell bei einem spezifischen Modell), ohne das Task-Regime (Berechnung vs. Code-Modifikation) und das Agenten-Design (unterschiedliche Modellfamilien) zu kreuzen. Folglich fehlt dem Feld ein einheitliches Verständnis darüber, unter welchen Bedingungen welche Tool-Oberfläche bevorzugt wird.

Methodik

Die Autoren führen einen „fehlenden gekreuzten Vergleich“ mittels einer Integritäts-bereinigten, Drei-Arm-Ablationsstudie durch. Das experimentelle Design folgt einer $3 \times 2 \times 2$ Faktorialstruktur:

Drei Tool-Oberflächen:
- Baseline: Die Standard-Tool-Oberfläche des Agenten (z. B. Read, Grep, Edit, Write, Bash).
- Bash_Only: Beschränkt auf natives Bash plus Read-Only-Browsing (Read, Glob, Grep); alle Datei-Editier-Primitive (Edit, Write) werden entfernt.
- Code_Only: Die gesamte native Oberfläche wird durch ein einziges MCP-Tool (mcp__codebox__execute_code) ersetzt, das eine persistente Python+Bash-REPL ausführt. Alle nativen Built-ins sind untersagt.
Zwei Agenten: Claude Code (Modell claude-sonnet-4-6) und OpenAI Codex CLI (Modell gpt-5.5).
Zwei Task-Regime:
- Computation (Berechnung): Eine neue „Artifact“-Suite ( $n=93$ ), bestehend aus in sich geschlossenen Aufgaben, definiert durch einen Workspace, einen versteckten Grader und eine Referenzausgabe.
- Modification (Modifikation): SWE-bench Mini ( $n=100$ ), eine kuratierte Teilmenge von Repository-Modifikationsaufgaben.

Experimentelle Kontrollen:

Integrität: Das Harness erzwingt ein striktes SWE-bench-Protokoll, bei dem Test-Patches erst nach Beendigung des Agenten angewendet werden. Die Dateisystem-Zustände sind zwischen den Armen mittels fuse-overlayfs isoliert, um Kreuzkontamination zu verhindern.
Kostenrechnung: Um die Variabilität des Server-seitigen Prompt-Caching zu adressieren, verwenden die Autoren eine Metrik namens „cache-adjustierte Kosten“. Diese wendet eine Median-Floor-Anpassung auf die Input-Token des ersten Turns an, um das „Warm/Kalt“-Cache-Lotterie-Problem zu normalisieren, ohne eine vollständige Cache-Isolation zu beanspruchen.
Statistische Rigorosität: Die Einheit der Inferenz ist der Task, nicht der Seed. Die Ergebnisse werden mittels gepaarter Wilcoxon-Signed-Rank-Tests auf per-Task-Differenzen über drei unabhängige Seeds hinweg analysiert.

Zentrale Beiträge

1. Eine vierzellige, agenten-bedingte Kostenstruktur

Die Studie zeigt, dass die Kosteneffizienz der Beschränkung eines Agenten auf execute_code nicht universell ist, sondern gemeinsam durch das Task-Regime und das Agenten-Design bestimmt wird.

Drei von vier Zellen begünstigen code_only:
- Artifact/Claude: Signifikante Kostenreduktion ( $-24,6\,\%$ , $p=7,4 \times 10^{-14}$ ).
- Artifact/Codex: Richtungsweisende Kostenreduktion ( $-6,7\,\%$ , nicht signifikant).
- SWE-bench/Codex: Signifikante Kostenreduktion ( $-19,9\,\%$ , $p=2,0 \times 10^{-9}$ ).
Eine Zelle kehrt den Trend um:
- SWE-bench/Claude: code_only ist richtungsweisend kostspieliger ( $+14,4\,\%$ , nicht signifikant).

Dieses Ergebnis zeigt, dass die drei bisherigen Behauptungen in der Literatur nicht widersprüchlich sind, sondern nur unter spezifischen (Regime, Agent)-Kombinationen zutreffen.

2. Kausale Dekomposition über drei Mechanismen

Die Autoren zerlegen die beobachteten Kostenvarianzen in drei distinkte Mechanismen:

Path-Cost (Edit-Friction): Bei Claude für SWE-bench zwingt code_only dazu, jede Dateieditierung als Python-Skript auszudrücken. Dies skaliert die Output-Token mit dem Edit-Volumen (Spearman $\rho=0,488$ ) und erzeugt eine „Steuer“ auf Aufgaben mit hohem Edit-Aufwand.
Failure-Cost (Fehlerskosten): Der Kostenüberschuss für Claude bei SWE-bench lokalisiert sich auf „doomed-run“-Trajektorien (Instanzen, in denen alle Arme scheitern). Auf der Teilmenge der einstimmig bestandenen Instanzen kollabiert der Kostenunterschied von $+14,4\,\%$ auf $+4,1\,\%$ (nicht signifikant).
Pricing Asymmetry (Batching): Bei Codex für SWE-bench erzielt code_only signifikante Einsparungen ( $-19,9\,\%$ ) primär durch die Reduktion der Input-Token ( $-24,8\,\%$ ). Dies wird durch Tool-Call-Batching (ein Python-Skript ersetzt mehrere native Tool-Aufrufe) und programmatische Output-Unterdrückung (der Agent begrenzt das Output-Volumen und vermeidet so die harten Output-Caps der nativen Tools) getrieben.

3. Kapazitäts-Invarianz

Über alle vier Zellen und drei Tool-Oberflächen hinweg sind die Pass-Raten statistisch gleichwertig (Differenzen $<3$ Prozentpunkte, alle nicht signifikant).

Die Agreement-Matrix zeigt, dass für die Mehrheit der Instanzen ( $\ge 91\,\%$ unter Mehrheitsentscheidung) alle Arme entweder gemeinsam bestehen oder gemeinsam scheitern.
Dies bestätigt, dass die Wahl der Tool-Oberfläche den Pfad und die Kosten zur Lösung einer Aufgabe verändert, aber nicht die Fähigkeit (Capability), die Aufgabe zu lösen, was konsistent mit dem „Capability Overlap Principle“ ist.

Zusammenfassung der Ergebnisse

Das Paper liefert eine „Auf-einen-Blick“-Karte darüber, wann code_only vorteilhaft ist:

Computation Tasks (Artifact): Die Beschränkung auf execute_code ist für beide Agenten günstiger, mit einem signifikanten Sieg für Claude.
Modification Tasks (SWE-bench) mit Codex: Die Beschränkung auf execute_code ist signifikant günstiger aufgrund von Input-Token-Batching und Output-Kontrolle.
Modification Tasks (SWE-bench) mit Claude: Die Beschränkung auf execute_code ist richtungsweisend teurer. Dies wird durch „Edit Friction“ (höhere Output-Token für Edits) und „Failure Costs“ (teure fehlgeschlagene Trajektorien) getrieben, nicht durch eine Strafe auf erfolgreiche Edits.

Bedeutung und Ansprüche

Das Paper behauptet, den „dreifachen widersprüchlichen Anspruch“ des Feldes dadurch aufzulösen, dass es zeigt, dass keine einzelne Tool-Oberfläche unter allen Bedingungen optimal ist.

Kosten vs. Kapazität: Das Hauptsignal der Wahl der Tool-Oberfläche ist die Kostenstruktur, nicht die Pass-Rate. Da die Pass-Raten invariant sind, ist die Wahl der Oberfläche eine Entscheidung des Kosten-Engineerings und keine Entscheidung zur Kapazitätssteigerung.
Gemeinsame Bestimmung: Die optimale Oberfläche wird durch die Schnittmenge des Task-Regimes (Berechnung vs. Modifikation) und der spezifischen Implementierung des Agenten (wie dieser Batching, Output-Caps und Edit-Primitive handhabt) bestimmt.
Empirischer Beleg: Die Studie liefert den ersten empirischen Beleg für die Ungleichheit der „Tool-Use Tax“ bei Coding-Agenten: Eine Tool-Oberfläche liefert nur dann einen Nettovorteil, wenn ihr task-spezifischer Kapazitätsgewinn den pro Aufruf entstehenden Definition-Kosten übersteigt.

Die Autoren betonen explizit, dass es sich bei ihren Befunden um Kosten-Engineering-Behauptungen handelt, nicht um Kapazitäts-Behauptungen. Sie behaupten weder, dass code_only universell überlegen ist, noch dass ihre Ergebnisse ohne weitere Validierung auf alle Modelle oder externe MCP-Tools verallgemeinerbar sind. Die Bedeutung liegt im methodischen Rahmen, der die Unterscheidung zwischen Agenten-Design und Regime-Effekten ermöglicht und das Feld von anekdotischen Branchenberichten hin zu kontrollierten, gekreuzten Ablationsstudien führt.