🤖 AI

Agent-as-a-Router: Agentic Model Routing for Coding Tasks

Dieses Paper führt Agent-as-a-Router ein, ein Framework, das Modell-Routing als dynamischen Kontext-Aktion-Feedback-Zyklus behandelt, um ausführungsgrundierte Erfahrung zu akkumulieren, wodurch der Informationsdefizit statischer Router überwunden und eine überlegene Performance sowie Kosteneffizienz bei Programmieraufgaben erreicht wird.

Ursprüngliche Autoren: Pengfei Zhou, Zhiwei Tang, Yixing Ma, Jiasheng Tang, Yizeng Han, Zhenglin Wan, Fanqing Meng, Wei Wang, Bohan Zhuang, Wangbo Zhao, Yang You

Veröffentlicht 2026-06-23

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Pengfei Zhou, Zhiwei Tang, Yixing Ma, Jiasheng Tang, Yizeng Han, Zhenglin Wan, Fanqing Meng, Wei Wang, Bohan Zhuang, Wangbo Zhao, Yang You

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 sind ein Manager, der eine geschäftige Coding-Agentur leitet. Sie haben ein Team von acht verschiedenen Experten-Entwicklern, jeder mit seinen eigenen einzigartigen Superkräften und Preisschildern.

Entwickler A ist ein Genie darin, Bugs zu beheben, kostet aber ein Vermögen.
Entwickler B ist günstig und großartig im Schreiben von Datenskripten, aber schlecht in komplexer Mathematik.
Entwickler C ist fantastisch im Schreiben von Testfällen, aber langsam bei allem anderen.

In der Vergangenheit haben die meisten Unternehmen einfach Entwickler A (den teuersten, „besten“) für jeden Job engagiert, um auf der sicheren Seite zu sein. Das ist jedoch verschwenderisch. Wenn man ein einfaches Datenskript benötigt, ist es so, als würde man einen Formel-1-Fahrer engagieren, um einen zum Supermarkt zu fahren.

Dieses Paper mit dem Titel „Agent-as-a-Router“ stellt eine neue Art und Weise vor, dieses Team zu managen. Anstatt blind den „besten“ Entwickler auszuwählen, haben die Autoren einen smarten Verkehrsleiter (einen „Router“) entwickelt, der entscheidet, welcher spezifische Entwickler welche spezifische Aufgabe übernehmen soll.

Hier ist die Aufschlüsselung ihrer Entdeckung und Lösung:

1. Das Problem: Die „Informationslücke“

Die Forscher fragten zuerst: Warum arbeiten aktuelle smarte Router nicht besser?
Sie testeten einen Standard-KI-Router (einen „Vanilla“-Router) und stellten fest, dass dieser Fehler machte. Sie fragten sich: Ist der Router einfach nicht schlau genug, um das Problem zu durchdenken?

Um dies zu testen, gaben sie dem Router ein Spickzettel, der Leistungsstatistiken enthielt (z. B. „Entwickler B ist zu 90 % gut bei Datenaufgaben“).

Ergebnis: Die Leistung des Routers sprang sofort um 15,3 % nach oben.
Die Lehre: Der Router scheiterte nicht, weil er „dumm“ war; er scheiterte, weil er blind war. Er verfügte nicht über genügend Informationen darüber, wie die verschiedenen Entwickler bei spezifischen Aufgaben tatsächlich abschnitten. Das Problem war ein Informationsdefizit, kein Mangel an Intelligenz.

2. Die Lösung: Der „Lernende Verkehrsleiter“

Die Autoren schlagen ein neues System namens ACRouter vor. Anstatt ein statisches Regelwerk zu sein, haben sie es als eine lebendige, lernende Schleife konzipiert. Sie nennen dies die C-A-F-Schleife:

Context (Die Einweisung/Briefing): Der Router betrachtet die neue Coding-Aufgabe und erinnert sich an das, was er von ähnlichen Aufgaben zuvor gelernt hat.
Action (Die Zuweisung): Er wählt den besten Entwickler für den Job aus.
Feedback (Das Zeugnis/Report Card): Der Entwickler erledigt die Arbeit, und ein „Verifier“ (eine isolierte Testumgebung) prüft, ob der Code tatsächlich funktioniert und wie viel er gekostet hat.
Update (Das Gedächtnis): Der Router nimmt dieses Zeugnis und speichert es in seinem Gedächtnis.

Die Analogie:
Betrachten Sie einen traditionellen Router als eine statische Karte. Sie zeigt jedes Mal dieselbe Route an, selbst wenn die Straße gesperrt ist.
Der ACROuter ist wie ein Fahrer eines Ride-Sharing-Dienstes mit Live-GPS.

Er nimmt einen Fahrgast (die Aufgabe) mit.
Er setzt ihn ab.
Er prüft, ob der Fahrgast zufrieden war und wie viel Benzin verbraucht wurde.
Er merkt sich: „Route X war großartig für diese Art von Fahrgast, aber Route Y war zu teuer.“
Das nächste Mal, wenn ein ähnlicher Fahrgast kommt, trifft der Fahrer eine bessere Wahl, weil er Erfahrung hat.

3. Das „Gedächtnis“ ist der Schlüssel

Der wichtigste Teil ihres Systems ist das Memory-Modul.

Alte Router waren wie Schüler, die für einen Test lernten, ihn absolvierten und dann alles wieder vergaßen. Sie konnten nicht aus ihren Fehlern lernen.
ACRouter führt ein „Tagebuch“ über jede geroutete Aufgabe. Er erinnert sich: „Letztes Mal, als ich eine ‚Data Science‘-Aufgabe an Entwickler B delegiert habe, hat es perfekt funktioniert und war günstig. Letztes Mal, als ich sie an Entwickler A delegiert habe, war es teuer und ist fehlgeschlagen.“

Dies ermöglicht es dem Router, mit jedem Arbeitsschritt klüger zu werden und sich an neue Arten von Coding-Herausforderungen anzupassen, die er zuvor noch nie gesehen hat.

4. Die Ergebnisse: Smarter und Günstiger

Das Team testete ihr System auf einem massiven Benchmark namens CodeRouterBench (etwa 10.000 Coding-Aufgaben).

Bei bekannten Aufgaben: ACRouter war am genauesten darin, den richtigen Entwickler auszuwählen, und übertraf sogar die „perfekten“ statischen Regeln.
Bei neuen, ungewöhnlichen Aufgaben (Out-of-Distribution): Hier geschah die Magie. Als sie dem Router eine völlig neue Art von Coding-Herausforderung (Agentic Programming) gaben, die er noch nie zuvor gesehen hatte:
- Die alten „statischen“ Router (die nur Regeln auswendig kannten) scheiterten kläglich.
- Der „lernende“ Router (ACRouter) passte sich schnell an, indem er sein Gedächtnis über ähnliche Muster nutzte, um erfolgreich zu sein.
- Er übertraf sogar die Strategie, einfach für jeden Job den teuersten, „besten“ Entwickler einzustellen, wodurch er Geld sparte und gleichzeitig bessere Ergebnisse erzielte.

Zusammenfassung

Das Paper argumentiert, dass man, um das Beste aus mehreren KI-Coding-Modellen herauszuholen, nicht einfach nur das „stärkste“ Modell auswählen sollte. Stattdessen benötigt man einen smarten, lernenden Manager, der:

Die spezifischen Stärken jedes Modells kennt.
Aus seinen eigenen Fehlern lernt (in Echtzeit).
Ein Gedächtnis aufbaut, was funktioniert und was nicht.

Indem sie die „Informationslücke“ durch diese Feedback-Schleife schließen, wird das System zu einer hocheffizienten, selbstverbessernden Routing-Engine, die Geld spart und die Codequalität verbessert.

Technisches Resümee: Agent-as-a-Router

1. Problemstellung

Reale Nutzer haben oft Zugriff auf mehrere Large Language Models (LLMs) verschiedener Anbieter, von denen jedes in unterschiedlichen Domänen (z. B. Algorithmenentwurf, Data Science oder Code-Vervollständigung) herausragt, aber keines alle Aufgaben dominiert. Aktuelle Coding-Agenten verlassen sich typischerweise auf ein einzelnes, festes LLM für alle Aufgaben – ein Design, das die Vorhersehbarkeit auf Anbieterseite gegenüber der nutzerzentrierten Kosteneffizienz und Aufgabenqualität priorisiert.

Das Kernproblem ist das automatische Modell-Routing: zu bestimmen, welches Modell welche eingehende Coding-Aufgabe bearbeiten sollte, um die Leistung zu maximieren und gleichzeitig die Kosten zu minimieren. Bestehende Routing-Methoden behandeln dies als statisches, einmaliges Klassifizierungsproblem und verwenden häufig Sprachmodelle als Routing-Policies. Vorläufige Experimente zeigen jedoch eine signifikante Leistungslücke zwischen diesen statischen Routern und einem „Pro-Task-Oracle“ (das das beste Modell für jede spezifische Aufgabe kennt). Das Papier identifiziert, dass der Engpass für bestehende Router nicht ein Mangel an Denkvermögen ist, sondern ein Informationsdefizit: Statische Router versäumen es, während des Einsatzes erfahrungen auf Basis der Ausführung zu akkumulieren.

2. Methodik

2.1. Diagnose: Informationsdefizit

Die Autoren führten eine Ablationsstudie mit einem Zero-Shot-LLM-Router (betrieben durch Claude Sonnet 4.6) durch.

Vanilla Router: Erzielte 41,41 % AvgPerf.
+Perf Stats: Als statistische Leistungsdaten aus einem gehaltenen Probing-Set bereitgestellt wurden, stieg der Wert auf 47,74 % (+15,3 % relativer Gewinn) und übertraf damit sogar den besten heuristischen Router (47,50 %), der dieselben statischen Priors kodierte.
Schlussfolgerung: Die primäre Einschränkung ist der Mangel an dynamischen, auf der Ausführung basierenden Informationen, nicht die Denkfähigkeit des Router-Modells selbst.

2.2. Das Agent-as-a-Router-Framework

Um das Informationsdefizit zu adressen, schlagen die Autoren Agent-as-a-Router vor, ein Framework, das das Routing als Context-Action-Feedback (C-A-F)-Schleife formalisiert. Im Gegensatz zu statischen Routern entwickelt sich dieses Framework über einen Strom von Aufgaben:

Kontext ( $c_i$ ): Der Router beobachtet den Task-Prompt, Metadaten und die akkumulierte Historie (Memory) aus vorherigen Schleifen.
Aktion ( $a_i$ ): Der Router wählt ein Modell aus dem Kandidatenpool aus.
Feedback ( $f_i$ ): Die Ausgabe des ausgewählten Modells wird in einer Sandbox ausgeführt, und ein Verifizierer generiert einen Score sowie die Kosten.
Update: Das Feedback wird im Gedächtnis gespeichert und in den Kontext für die nächste Aufgabe ( $c_{i+1}$ ) integriert.

Diese Formulierung bezieht sich auf ein kontextuelles Multi-Armed-Bandit-Problem, bei dem die natürliche Metrik für die Evaluierung der kumulative Regret (die akkumulierte Differenz zwischen der Leistung des Routers und dem Pro-Task-Oracle) ist.

2.3. ACRouter-Instanziierung

Das Framework wird als ACRouter instanziiert, bestehend aus drei Kernmodulen:

Orchestrator: Trifft Routing-Entscheidungen durch Integration des DimensionBest-Priors, der Top-10 historischen Nachbarn (abgerufen via Cosine kNN aus dem Memory) und Task-Metadaten. Er verwendet ein leichtgewichtiges, fein abgestimmtes Qwen3.5-0.8B-Modell kombiniert mit heuristischen Regeln via gewichteter Abstimmung.
Verifier: Bewertet Modell-Outputs in einer Sandbox-Umgebung. Er aggregiert Signale (AST-Parsing, Ausführungsergebnisse, LLM-as-Judge) zu einem einheitlichen Performance-Score ( $u_i \in [0, 1]$ ).
Memory: Ein Online-Vektorstore, der durch Task-Embeddings geschlüsselt ist. Er protokolliert das gewählte Modell, die Performance, die Kosten und die Verifizierungs-Traces. Er nutzt einen FIFO-gebundenen Store (20K Einträge), um eine feingliedrige, kontextsensitive Abfrage vergangener Erfolge und Misserfolge zu ermöglichen.

2.4. CodeRouterBench

Zur Evaluierung des Routings auf Task-Streams führen die Autoren CodeRouterBench ein, ein Benchmark, der Folgendes umfasst:

~10.000 Aufgaben über 10 Coding-Dimensionen (9 In-Distribution Single-Turn-Aufgaben und 1 Out-of-Distribution Agentic-Programming-Dimension).
8 Frontier LLMs (darunter Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5, etc.).
Execution-Verified Scores: Aufgaben werden über Sandboxed-Ausführung oder LLM-as-Judge bewertet, was eine Ground-Truth-Beobachtungsmatrix für den Regret-basierten Vergleich liefert.

3. Kernbeiträge

Framework: Der Vorschlag von Agent-as-a-Router, der das Modell-Routing als C-A-F-Schleife formalisiert, wodurch Router in der Lage sind, die Informationslücke durch ausführungsorientiertes Feedback aktiv zu schließen.
Artefakte:
- ACRouter: Eine konkrete Instanziierung des Frameworks mit Orchestrator, Verifier und Memory-Modulen.
- CodeRouterBench: Eine standardisierte Evaluierungsumgebung (~10K Aufgaben, 8 LLMs), die speziell für den Regret-basierten Vergleich von Routern auf Task-Streams inklusive eines OOD Agentic-Programming-Testbeds entwickelt wurde.
Erkenntnisse:
- Informationsdefizit: Der Routing-Engpass ist der Informationszugriff, nicht das Denkvermögen. Die Bereitstellung von Performance-Statistiken liefert einen 15,3 % relativen Gewinn.
- Leistung: ACRouter erreicht den niedrigsten kumulativen Regret bei In-Distribution-Aufgaben und generalisiert effektiv auf Out-of-Distribution (OOD) Agentic-Programming-Aufgaben.
- Statische Limitationen: Leichtgewichtige statische Router (trainierte Klassifikatoren, Heuristiken) schneiden bei In-Distribution-Aufgaben akzeptabel ab, scheitern aber signifikant bei OOD-Aufgaben, wohingegen ACRouter eine starke Leistung beibehält.

4. Experimentelle Ergebnisse

Die Experimente wurden sowohl auf In-Distribution (ID) als auch auf Out-of-Distribution (OOD) Task-Streams durchgeführt.

In-Distribution Performance:
- ACRouter erreichte die höchste durchschnittliche Performance (49,98 %) und den niedrigsten kumulativen Regret (205,5), womit es die statische „DimensionBest“-Heuristik (47,50 %) und alle trainierten Policy-Baselines übertraf.
- Es demonstrierte zudem eine überlegene Kosteneffizienz (Perf/$ Verhältnis von 3,79) im Vergleich zur Nutzung des stärksten Einzelmodells (Always-Opus 4.6, welches ein Verhältnis von 1,29 aufwies).
Out-of-Distribution (OOD) Generalisierung:
- Auf dem Agentic-Programming-Testbed (176 Aufgaben) erreichte ACRouter 62,50 % AvgPerf und übertraf damit signifikant die Always-Opus-Baseline (57,14 %) und alle anderen Router.
- Statische Klassifikatoren (z. B. LogReg, RouteLLM-BERT) brachen bei OOD-Aufgaben zusammen, mit Leistungen, die auf 8,93 %–21,43 % fielen – sogar niedriger als eine Zufallsauswahl.
- Die Fähigkeit von ACRouter, während des Streams verifizierte Erfahrungen zu sammeln, ermöglichte es ihm, sich an die neue Aufgabenverteilung anzupassen, während statische Methoden, die auf eingefrorenen Priors basieren, versagten.
Kostenanalyse:
- Obwohl ACRouter Overhead für die Memory- und Verifier-Module verursacht, bleibt es kosteneffizienter als die Wahl des teuersten Modells (Opus 4.6), während es gleichzeitig eine höhere Qualität liefert.
- Die Strategie „Always-Kimi-K2.5“ bot die höchste Kosteneffizienz (Perf/$ 12,62), jedoch um den Preis einer erheblichen Reduktion der absoluten Performance (36,66 % AvgPerf).

5. Bedeutung und Ansprüche

Das Paper behauptet, dass das aktive Schließen der Informationslücke durch ausführungsorientiertes Feedback ein allgemeines Prinzip für den Aufbau agentischer Systeme ist, die zwischen heterogenen Tools oder Modellen routen müssen.

Paradigmenwechsel: Die Arbeit verschiebt das Routing von einem statischen Klassifizierungsproblem hin zu einem dynamischen, selbstadaptiven Prozess (C-A-F-Schleife).
Praktischer Nutzen: Es zeigt auf, dass Nutzer durch dynamisches Routing eine nahezu Oracle-Performance und Kosteneffizienz erreichen können, anstatt sich auf ein einziges „bestes“ Modell zu verlassen.
Generalisierbarkeit: Die C-A-F-Schleife wird nicht nur als Routing-Mechanismus, sondern als breiteres Entscheidungs-Paradigma präsentiert, das auf Tool-Selektion, API-Endpunkt-Selektion und Aufwandallokation anwendbar ist.
Bescheidenheit: Die Autoren räumen Einschränkungen ein, wie etwa die Unfähigkeit, die Cache-Hit-Raten auf Anbieterseite zu beobachten (was die Kostenschätzungen relativ statt absolut macht), sowie die Verwendung eines reduzierten Schrittlimits für OOD-Aufgaben zur Wahrung der Budget-Beherrschbarkeit. Sie merken an, dass ihre aktuelle Instanziierung zwar ein LLM-Policy mit kNN-Memory nutzt, alternative Techniken auf Parameterebene jedoch noch erforscht werden müssen.

Zusammenfassend argumentiert das Paper, dass die Zukunft für agentische Coding-Systeme nicht darin liegt, ein einziges dominantes Modell zu finden, sondern adaptive Router zu bauen, die aus der Ausführungs-Feedback lernen, um das richtige Werkzeug für die richtige Aufgabe zu wählen.