🤖 AI

Steer, Don't Solve: Training Small Critic Models for Large Code Agents

Dieses Paper schlägt das Training kleiner, supervised fine-tuned Critic-Modelle vor, um Intra-Trajektorien-Steuerung für große Code-Agenten bereitzustellen, und zeigt auf, dass dieser Ansatz die Leistung auf Benchmarks wie SWE-bench Verified signifikant verbessert, während er gleichzeitig sowohl die Rechenkosten als auch die Trajektorienlängen im Vergleich zu End-to-End-Training oder Post-hoc-Scoring reduziert.

Ursprüngliche Autoren: Shubham Gandhi, Yiqing Xie, Atharva Naik, Ruichen Zhu, Carolyn Rose

Veröffentlicht 2026-06-23

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Shubham Gandhi, Yiqing Xie, Atharva Naik, Ruichen Zhu, Carolyn Rose

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

Die große Idee: Das GPS vs. der Fahrer

Stellen Sie sich vor, Sie versuchen, mit einem Auto von New York nach Los Angeles zu fahren. Sie haben einen sehr geschickten Fahrer (den Code-Agenten), der genau weiß, wie man das Lenkrad dreht, Gas gibt und die Gänge wechselt. Dieser Fahrer wird jedoch manchmal beim Großen Ganzen verwirrt. Er fährt vielleicht im Kreis, biegt falsch ab, weil er ein Schild falsch gelesen hat, oder versucht immer wieder, durch eine Wand zu fahren, weil er sie für eine Tür hält.

Normalerweise versucht man dies zu beheben, indem man den Fahrer von Grund auf neu trainiert. Aber das ist teuer, dauert lange und der Fahrer könnte trotzdem immer noch auf denselben verwirrenden Straßen stecken bleiben.

Dieses Paper schlägt eine andere Lösung vor: Anstatt den Fahrer neu zu trainieren, stellen wir einen kleinen, klugen GPS-Navigator ein (das Critic-Modell).

Der Fahrer (Agent): Er erledigt die eigentliche Arbeit (Code schreiben, Befehle ausführen). Er bleibt exakt gleich; wir ändern nicht sein Gehirn.
Das GPS (Critic): Es berührt nicht das Lenkrad. Stattdessen beobachtet es den Fahrer alle paar Minuten. Wenn der Fahrer im Kreis fährt oder auf eine Klippe zusteuert, sagt das GPS: „Hey, du fährst in einer Schleife! Du versuchst die falsche Datei zu reparieren. Halte inne und überdenke deine Strategie.“

Das Paper zeigt, dass dieser kleine GPS viel günstiger zu engagieren ist als ein super-intelligenter menschlicher Navigator, und dass er dem Fahrer hilft, das Ziel viel schneller und häufiger zu erreichen.

Das Problem: Warum reines „Training“ nicht ausreicht

Die Autoren stellten fest, dass große KI-Coding-Agenten, wenn man sie darauf trainiert, Software-Bugs zu lösen, zwar sehr gut in der Mechanik werden (Code tippen, Tools ausführen). Aber sie scheitern oft an der Strategie (herauszufinden, was der richtige Plan ist).

Es ist wie das Lehren eines Schülers beim Schreiben von Aufsätzen. Man kann ihm perfekte Grammatik und Rechtschreibung beibringen (die Mechanik), aber wenn er nicht weiß, wie er seine Gedanken ordnet oder beim Thema bleibt (die Strategie), wird der Aufsatz trotzdem ein Chaos sein.

Wenn man versucht, die KI gleichzeitig beides lehren zu wollen, stößt sie an eine „Obergrenze“. Sie bleibt stecken. Die Autoren fanden heraus, dass etwa 65 % der Fehler nicht darauf zurückzuführen waren, dass die KI schlechten Code schrieb, sondern dass sie eine fehlerhafte Argumentation hatte.

Die Lösung: Ein „Kleiner Kritiker“

Das Team entwickelte ein System, bei dem ein kleines KI-Modell (der Critic) neben dem großen Coding-Agenten sitzt.

Der Aufbau: Der große Agent versucht, ein Problem zu lösen. Alle 5 oder 10 Schritte hält er inne.
Der Check-in: Der kleine Critic betrachtet das, was der Agent bisher getan hat.
Der Rat: Der Critic gibt einen kurzen, hochgradig abstrakten Tipp.
- Schlechter Rat: „Lösche Zeile 42 und schreibe hier eine Schleife.“ (Dies ist „Beifahrer-Fahren“ [Backseat Driving], und das Paper sagt, dass dies schlecht ist, weil das kleine Modell nicht klug genug ist, um den Code besser zu kennen als das große Modell).
- Guter Rat: „Du wiederholst denselben Befehl dreimal. Du steckst in einer Schleife fest. Versuche einen anderen Ansatz.“ (Dies ist „Steuern“ [Steering]).
Die Fortsetzung: Der große Agent liest den Rat und arbeitet weiter.

Wie sie das GPS trainierten

Um den kleinen Critic zu lehren, wie man guten Rat gibt, haben sie nicht einfach geraten. Sie nutzten einen „Lehrer“ (eine massive, sehr teure KI namens Claude-Opus-4.6), um zuerst den Rat zu generieren.

Der Lehrer: Die teure KI beobachtete den Agenten bei der Arbeit und schrieb den perfekten, hochgradig abstrakten Rat auf.
Der Schüler: Die kleine, günstige KI (Qwen3-8B) studierte diese Notizen. Sie lernte, den Stil des Rats zu imitieren (fokussiert auf Strategie, nicht auf spezifische Codezeilen), ohne so klug sein zu müssen wie der Lehrer.

Entscheidende Entdeckung: Das Paper fand heraus, dass die Art des Rats am wichtigsten ist.

Wenn der Lehrer spezifische Code-Instruktionen gab, konnte der kleine Schüler diese nicht gut lernen.
Wenn der Lehrer hochgradig abstrakte Strategien lieferte (z. B. „Du steckst fest“, „Überprüfe deine Annahmen“), lernte der kleine Schüler dies perfekt.

Die Ergebnisse: Schneller, billiger und klüger

Das Team testete dies auf einem berühmten Benchmark namens SWE-bench, was wie ein Test mit 500 echten Software-Bugs ist.

Es funktioniert bei verschiedenen Fahrern: Sie trainierten den Critic mit einer Art von Coding-Agent (CWM-32B). Dann nutzten sie denselben Critic, um zwei andere Coding-Agenten (Qwen-Modelle) zu helfen, die er noch nie gesehen hatte.
- Ergebnis: Die neuen Agenten wurden signifikant besser darin, Bugs zu lösen, indem sie einfach dem Critic zuhörten.
Es spart Geld: Der „Lehrer“ (Claude-Opus) ist sehr teuer im Betrieb. Der „Schüler“ (Qwen3-8B) ist winzig und günstig.
- Ergebnis: Das System mit dem kleinen Critic war 30- bis 92-mal günstiger als die Verwendung des teuren Lehrers.
Es spart tatsächlich Zeit: Bei einem der großen Agenten sorgte der Critic nicht nur dafür, dass der Agent klüger wurde, sondern auch, dass der Agent aufhörte, Zeit zu verschwenden. Der Agent erledigte Aufgaben schneller, was noch mehr Geld sparte. Tatsächlich war das gesamte System (Agent + Critic) günstiger, als wenn der Agent alleine gearbeitet hätte.

Das „Geheimrezept“

Das Paper hebt zwei Hauptgründe hervor, warum dies funktionierte:

Trennung der Zuständigkeiten (Separation of Concerns): Der Agent konzentriert sich auf das Tun (Codieren), und der Critic konzentriert sich auf das Denken (Strategie). Sie kämpfen nicht darum, wer das Sagen hat.
Kein Beifahrer-Fahren (No Backseat Driving): Dem Critic ist es streng untersagt zu sagen: „Schreibe diese spezifische Zeile Code.“ Er sagt nur: „Du gehst in die falsche Richtung.“ Dies verhindert, dass das kleine Modell schlechte, spezifische Anweisungen gibt, die das große Modell verwirren könnten.

Zusammenfassung

Betrachten Sie dieses Paper als Blaupause für den Aufbau eines Teams statt eines Superhelden. Anstatt zu versuchen, eine einzige riesige, perfekte KI zu erschaffen, die alles kann (was schwer und teuer ist), haben sie ein System gebaut, in dem ein kleiner, spezialisierter Coach einen mächtigen Arbeiter leitet.

Der Coach erledigt die Arbeit nicht selbst, aber indem er die richtigen, strategischen Anstöße gibt, löst der Arbeiter Probleme, die er allein nicht bewältigen könnte – und das gesamte Team erledigt den Job schneller und für weniger Geld.

Technisches Resümee: Steuern statt Lösen

Problemstellung

Das End-to-End-Training von Code-Agenten ist ressourcenintensiv und stößt oft hinsichtlich des für die Lösung komplexer Code-Probleme erforderlichen Strategie-Level-Reasoning an seine Grenzen. Empirische Belege deuten darauf hin, dass Agenten zwar Low-Level-Implementierungsfähigkeiten erlernen können (Ausführen von Tool-Aufrufen, Editieren von Code), ihr High-Level-Reasoning (Fehlerbehebung, Planung, Suche) jedoch unterentwickelt bleibt, wenn es gemeinsam mit der Ausführung optimiert wird. Ungefähr 65 % der Fehler von Code-Agenten resultieren aus fehlerhaftem Reasoning statt aus falschen Aktionen. Aktuelle Post-Training-Methoden, die Strategie-Level-Reasoning mit Implementierungsverhalten koppeln, sättigen schnell ab, wodurch der Agent nicht in der Lage ist, Muster effektiv zu generalisieren. Darüber hinaus sind bestehende Critic-Modelle typischerweise post-hoc orientiert, das heißt, sie bewerten abgeschlossene Trajektorien, anstatt während der Ausführung eine Intra-Trajektorien-Steuerung bereitzustellen, um den Agenten vor einem Fehlschlag zu bewahren.

Methodik

Die Autoren schlagen ein „Steer, Don't Solve“-Paradigma vor: Den Code-Agenten einzufrieren und ein separates, kleines Critic-Modell zu trainieren, das während der Ausführung des Agenten High-Level-, Strategie-Level-Feedback liefert.

Kernarchitektur

Gefrorener Agent ( $\pi_A$ ): Der Code-Agent (z. B. CWM-32B, Qwen3-Varianten) bleibt während des gesamten Prozesses eingefroren. Er ist für alle konkreten Aktionen, Tool-Aufrufe und Code-Edits verantwortlich.
Critic-Intervention: Alle $k$ Schritte (z. B. $k=5$ oder $10$) inspiziert ein Critic-Modell $C$ die Teil-Trajektorie $\tau_{1:t}$ und die Historie des Agenten.
Feedback-Schleife: Der Critic generiert eine kurze textliche Kritik $f_t$ , die vor dem nächsten Schritt des Agenten an dessen Kontext angehängt wird. Der Critic interagiert nicht direkt mit der Umgebung.

Critic-Design & Training

Teacher-Distillation: Ein Frontier-Modell (Claude-Opopus-4.6) fungiert als Teacher-Critic ( $C_T$ ), um Trainingsdaten zu generieren. Das Student-Critic-Modell ( $C_\theta$ ) ist ein kleineres Modell (Qwen3-8B), das mittels Supervised Fine-Tuning (SFT) auf diesen Kritiken trainiert wurde.
Konzise vs. detaillierte Prompts: Die Arbeit identifiziert eine kritische Designentscheidung bezüglich des Feedback-Formats.
- Detaillierter Prompt: Ermöglicht es dem Teacher, spezifische Anweisungen auf Aktionsebene zu geben (z. B. „führe diesen Befehl aus“, „ändere diese Datei“). Dies ist zwar für den starken Teacher effektiv, führt aber zu „Backseat Driving“, bei dem der Agent einfach die Lösung des Teachers kopiert, anstatt selbst zu reasonen.
- Konziser Prompt: Beschränkt den Teacher auf High-Level-Feedback. Er verbietet spezifische Code-Änderungen oder technische Ansätze und konzentriert sich stattdessen auf eine Fehler-Taxonomie (z. B. „Schritt-Wiederholung“, „Aufgaben-Abweichung“) und strategische Neuausrichtung. Das trainierte Student-Critic-Modell wird aus diesem konzisen Prompt destilliert, um sicherzustellen, dass es lernt zu steuern statt zu diktieren.
Budget-Bewusstsein: Während der Inferenz werden, sobald der Agent sich seinem Schritt-Limit nähert (z. B. Schritt 100 von 150), budget-bewusste Instruktionen an den Input des Critics angehängt, die ihn dazu anhalten, eine Einreichung (Submission) zu empfehlen, falls der Agent feststeckt oder eine Lösung gefunden hat.
Trainingsdaten: Trajektorien werden gesammelt, indem der gefrorene Agent mit dem Teacher-Critic interveniert wird. Der Trainingskorpus verwendet ein „konzises“ Supervisionssignal. Um die Übertragbarkeit zu gewährleisten, sammeln die Autoren Daten von einem Agenten (CWM-32B) und testen auf anderen, oder mischen Trajektorien der Ziel-Agenten in den Korpus.

Evaluierungs-Setup

Benchmark: SWE-bench Verified (500 von Menschen verifizierte GitHub-Issues).
Getestete Agenten: CWM-32B (dense), Qwen3-32B (dense) und Qwen3-Next-80B-A3B (MoE).
Metriken: Resolve Rate (Bestehen der versteckten Tests), Localized Rate, Non-Empty Rate und Kosten (USD pro Instanz).
Fallback-Mechanismus: Falls ein durch den Critic gesteuerter Durchlauf innerhalb des Budgets keine Einreichung schafft, wird ein Basis-Durchlauf (ohne Critic) als Fallback ausgeführt, um einen fairen Kostenvergleich zu gewährleisten.

Kernergebnisse

Leistungssteigerungen: Der trainierte Critic verbessert die Resolve Rate der eingefrorenen Agenten signifikant.
- Bei CWM-32B verbesserte ein auf CWM-32B-Trajektorien trainierter Critic die Resolve Rate um +3,8 Punkte (29,2 % $\to$ 33,0 %).
- Bei Qwen3-32B verbesserte derselbe Critic (trainiert nur auf CWM-32B-Daten) die Resolve Rate um +3,4 Punkte (9,6 % $\to$ 13,0 %).
- Bei Qwen3-Next-80B-A3B betrug der Gewinn +3,0 Punkte (20,8 % $\to$ 23,8 %).
- Das Hinzufügen von Trajektorien des Ziel-Agenten zum Trainingskorpus steigerte die Gewinne weiter auf +5,2 Punkte bei Qwen3-32B und +4,4 Punkte bei Qwen3-Next-80B-A3B.
Übertragbarkeit: Ein auf die Trajektorien eines einzelnen Agenten trainierter Critic überträgt sich effektiv auf ungesehene Agenten mit unterschiedlichen Architekturen (dense vs. MoE) und Größen, was darauf hindeutet, dass das gelernte Steering-Signal agenten-agnostisch ist.
Kosteneffizienz:
- Der trainierte 8B-Critic kostet 30- bis 92-mal weniger als der Claude-Opus-4.6-Teacher.
- Entscheidend ist, dass das durch den Critic gesteuerte System beim Qwen3-Next-80B-A3B Agent insgesamt günstiger ist (0,04 $ vs. 0,11 $) als der ungesteuerte Agent. Dies liegt daran, dass der Critic die Trajektorien des Agenten verkürzt (was die Agent-Compute reduziert) und dadurch die Kosten der Critic-Aufrufe kompensiert.
Ablations-Ergebnisse:
- Training ist essenziell: Ein ungetrainierter (Off-the-shelf) 8B-Critic lieferte keinen Leistungsgewinn gegenüber der Baseline.
- Das Prompt-Format ist entscheidend: Während der Teacher mit detaillierten Prompts besser performte, war der trainierte Student mit konzisen Prompts erfolgreicher. Der detaillierte Prompt führte dazu, dass der Teacher „Backseat Driving“ betrieb – ein Verhalten, das der 8B-Student nicht originalgetreu replizieren oder generalisieren konnte, was zu einer geringeren Performance bei der Distillation führte.

Bedeutung und Ansprüche

Die Autoren behaupten, die erste Studie zu sein, die Critic-Modelle speziell für Code-Agenten trainiert, als Alternative zur Skalierung des Agenten selbst mittels „Separation of Concerns“.

Praktische Ergänzung: Die Ergebnisse zeigen, dass ein kleiner, gut trainierter Critic eine praktische und kosteneffiziente Ergänzung zur Skalierung des Agenten-Trainings darstellt. Er stellt die Strategie-Level-Reasoning-Fähigkeiten wieder her, die beim End-to-End-Training unterentwickelt bleiben.
Trennung der Zuständigkeiten (Separation of Concerns): Durch die Entkopplung von Strategie (Critic) und Ausführung (Agent) lernt das System einfachere, generalisierbarere Muster. Der Critic übernimmt die High-Level-Diagnose und Umleitung, während der Agent die Implementierung handhabt.
Effizienz: Der Ansatz erreicht Pareto-optimale Verbesserungen und bietet eine höhere Genauigkeit zu geringeren Kosten im Vergleich zu sowohl ungesteuerten Agenten als auch Systemen, die teure Frontier-Modelle als Critics nutzen.

Die Autoren kommen zu dem Schluss, dass das Trainieren von Critic-Modellen ein gangbarer Weg ist, um Code-Agenten zu verbessern, ohne die prohibitiven Kosten eines Retrainings der Agenten selbst oder die Abhängigkeit von teuren, Black-Box-Teachern zur Inferenzzeit in Kauf nehmen zu müssen.