A vállalati AI-verembe egyre fontosabb komponensként kerül be a model routing: a beérkező kérések vagy promptok dinamikus továbbítása a feladathoz legmegfelelőbb modellhez a sebesség és költség optimalizálása érdekében. A jelenlegi megoldások többsége azonban statikus osztályozási feladatként kezeli az útválasztást, ami jelentősen korlátozza a lehetőségeket.
Egy új, nyílt forráskódú keretrendszer, az Agent-as-a-Router ezt a szűk keresztmetszetet oldja fel azzal, hogy a routert dinamikus, memóriát építő ágensként kezeli. A megközelítés alapja a Context-Action-Feedback (C-A-F) hurok: a rendszer nyomon követi a modellek sikereit és hibáit, majd a visszacsatolás alapján módosítja a router viselkedését.
A kutatók bemutatták az ACRouter nevű, a paradigmát konkretizáló megvalósítást is. Tesztekben az ACRouter jelentősen felülmúlta a statikus routereket és azt a drága stratégiát, hogy minden kérést alapból prémium modellekre küldenek — mindezt anélkül, hogy csapatoknak óriási modelleket kellene tanítaniuk vagy végtelen, kézi szabályrendszert kellene írniuk.
Miért fontos a routing gazdaságtana és az információhiány
Egyetlen modellre épülő rendszerek kísérletezéshez hasznosak lehetnek, de skálázáskor hátrányosak. A model routing célja, hogy egyszerűbb feladatoknál olcsóbb, gyorsabb nyílt modelleket használjon, miközben a bonyolultabb feladatokat a drágább határmodellnek (frontier model) tartogatja.
Ma két fő megközelítést használnak: (1) kézi, heurisztikus szabályok — például ha egy prompt bizonyos kulcsszavakat tartalmaz, küldd GPT-5.5-re, egyébként egy önhostolt nyílt modellre, mint Kimi K2.7; (2) statikusan betanított policy-k vagy osztályozók, amelyek a prompt beágyazásai alapján jósolják meg a múltbeli teljesítmény alapján legjobb modellt.
Mindkét megközelítés statikus. A kutatók valós kódolási és ügynöki (agentic) munkafolyamatokon végzett vizsgálatai szerint ezeknél erős korlát jelentkezik: a statikus routerek súlyos információhiánnyal küzdenek, mert csak a bemenetet nézik, és soha nem látják, hogy a választott modell valóban sikeresen végrehajtotta-e a feladatot.
Ez három hibapontot eredményez: a) befagyott információállapot — a rendszer nem tud új végrehajtási visszajelzéseket felhalmozni élesben; b) rossz out-of-distribution (OOD) generalizáció — amikor a felhasználói viselkedés vagy az adatok változnak, a tréningadatokra épülő szabályok érvényüket vesztik; c) érzékenység a modell-churnre — egy statikus osztályozó elavulhat, ha rövid időn belül új, jobb modellek jelennek meg.
Agent-as-a-Router: a saját magán fejlődő rendszer
Az Agent-as-a-Router alapfeltevése, hogy a hatékony routernek képesnek kell lennie végrehajtás-alapú információkat gyűjteni és felhalmozni éles üzem közben — vagyis "a feladaton tanulni".
A C-A-F hurok így működik: amikor beérkezik egy új prompt, a router megvizsgálja a promptot és a feladat metaadatait (például programozási nyelv, nehézség). Ezután a memóriában hasonló korábbi interakciók után keres, megnézve, mely modellek teljesítettek jól vagy rosszul. A kontextus alapján kiválasztja a célmodellt és végrehajtatja a feladatot. Végül megfigyeli a valós kimenetet, kivon egy siker/hiba jelzést, és ezt visszaírja a memóriába, hogy a jövőben jobb döntéseket tudjon hozni.
Például egy automatikus vállalati adat-analitikai csővezetékben a router egy SQL-generálási feladatot küldhet egy nyílt modellnek, például Kimi-nek. Ha a modell hallucinál egy oszlopnevet és a lekérdezés nem fordul le, a C-A-F hurok észleli a fordító/DB hibát, rögzíti a sikertelenséget, és a következő hasonló, szokatlan lekérdezésnél a router már egy fejlettebb modellhez, például Claude Opus 4.8-hoz irányítja a feladatot.
ACRouter felépítése
Az ACRouter három fő komponensből áll: Orchestrator, Verifier és Memory. Ezt egy eszközréteg (tool layer) támogatja, amely fizikailag végrehajtja a C-A-F hurkot.
- Memory: vektor-tárra épül, releváns korábbi interakciókat keres elő és frissíti a történelmi adatbázist új eredményekkel; ez szolgálja a kontextusfázist.
- Orchestrator: a cselekvési fázisért felel, a user promptot és a visszakeresett memóriát feldolgozva kiválasztja a legalkalmasabb modellt a rendelkezésre álló poolból.
- Verifier: a visszacsatolási fázist kezeli; értékeli a kiválasztott modell kimenetét és egyértelmű siker/hiba jelet generál.
Az eszközréteg összeköti a Verifiert a valós végrehajtási környezettel — például Python-kódértelmezővel, ügynöki sandboxszal vagy adatbázismotortól — így a rendszer képes lefuttatni a generált kódot vagy lekérdezést és megfigyelni a pontos kimenetet.
Érdemes megjegyezni, hogy az Orchestrator könnyű súlyú: a kutatók nem egy nagy nyelvi modellt használtak, hanem egy sub-billion paraméteres adaptert Qwen 3.5-re építve (kb. 0,8 milliárd paraméter), amit akár önhostolva is lehet futtatni.
Eredmények: ACRouter a költség-teljesítmény Pareto-élén
A keretrendszer próbája a CodeRouterBench volt, amely mintegy 10 000 feladatot tartalmazott, és ellenőrzött pontszámokat biztosított nyolc frontier modellel, köztük Claude Opus 4.6-tal, GPT-5.4-gyel, Qwen3-Max-szal és GLM-5-tel. A vizsgálat két részre oszlott: in-distribution (ID) tesztekre (kilenc egyszeri kérést lefedő kódolási dimenzió, például algoritmustervezés és tesztgenerálás) és out-of-distribution (OOD) agentic programozási tesztkörnyezetre, amely többlépéses tervezést, fájlkezelést és iteratív hibakeresést igényelt.
A bázisértékek rávilágítottak arra, miért sikertelen a single-model stratégia: nincs olyan egyetlen modell, amely minden kategóriában dominálna. Például bár Claude Opus 4.6 átlagosan a legjobb teljesítményt érte el, GLM-5 az algoritmustervezésben 86%-os relatív javulást mutatott vele szemben, és Qwen3-Max a tesztgenerálásban 111%-os javulást ért el — miközben Opus hozzávetőlegesen 12-szer drágább volt, mint kisebb modellek, például a Kimi-K2.5.
A benchmarkokban a statikus routerek rendre kudarcot vallottak: speciális, niche szintaxisú kódolási feladatokat küldtek olyan modelleknek, amelyek nem tudták azt végrehajtani, és a statikus router nem látta, hogy a kód futása meghiúsult. Ezzel szemben az ACRouter a végrehajtási környezetből érkező negatív visszajelzés után módosította az útválasztási döntést.
A kutatók szerint az ACRouter a költség és teljesítmény Pareto-élén helyezkedik el: mind az ID feladatok, mind a komplex OOD agentic tesztek esetén a legalacsonyabb kumulatív regret értéket érte el (a regret a nem optimális útválasztási döntések időbeni mérőszáma). Az in-distribution tesztsorozaton az ACRouter teljes futása 13,21 dollárba került, míg ha mindig Opus-ra küldték volna a kéréseket, az 34,02 dollár lett volna — ez nagyjából 2,6× költségmegtakarítást jelent.
Az ACRouter dinamikusan párosította a feladatokat a legalkalmasabb modellel az adott niche-re, ami arra utal, hogy a vállalatok frontvonalbeli pontosságot érhetnek el vagy haladhatnak meg változatos munkaterheléseknél anélkül, hogy minden lekérdezésnél prémium árat fizetnének.
Korlátok, alkalmazhatóság és kezdés
Az Agent-as-a-Router megoldja az információhiány problémáját, de nem univerzális megoldás minden AI-munkafolyamathoz.
A keretrendszer különösen hatékony olyan verifikálható feladatoknál, ahol a Verifier egyértelmű siker/hiba jelzést kap a környezettől — például kódolásnál vagy adatok lekérésénél. Hasznos, ha disztribúciós eltolódások vagy olyan domének vannak, ahol különböző modellek teljesítenek jól eltérő niche-ekben.
Viszont túlzó vagy indokolatlan lehet egyszerű, trivialitásokat igénylő feladatoknál, vagy alacsony volumenű alkalmazásoknál, ahol a fejlesztési ráfordítás nem térül meg. Szubjektív területeken, például kreatív írásnál sem ideális, mert nincs könnyen verifikálható "helyes" válasz, így a feedback jelek szabványosítása nehéz vagy lehetetlen.
A kutatók a kódot nyílt forráskódúként közzétették GitHubon, és az Orchestrator modell-súlyait a Hugging Face-en tették elérhetővé Apache 2.0 licenc alatt. A router kompatibilis többek között Claude Code-dal, Codex-szel és OpenCode-dal.
Összegzés
Az Agent-as-a-Router paradigma és annak ACRouter implementációja azt mutatja, hogy a dinamikus, végrehajtás-alapú visszacsatolást használó routerek jelentősen javíthatják a modellválasztást és csökkenthetik a költségeket. Különösen olyan verifikálható, többmodellű vállalati munkafolyamatokban lehet hasznos, ahol a rendszer képes valós visszajelzések alapján folyamatosan tanulni és alkalmazkodni.
