# Hogyan építsünk modell-routert a harnessbe (LangChain, 2026-10-01) > **Szerzők:** Sydney Runkle és Eugene Yurtsev (LangChain) > **Megjelenés:** 2026-10-01 > **Eredeti cím:** „How to Build a Model Router in the Harness” > **Forrás:** > **Archív példány:** > **Kód:** (`agent/middleware/model_selection.py`) > **Típus:** technikai blog-bejegyzés, nem peer-reviewed tanulmány > **Terjedelem:** 2 297 szó --- ## Bevezetés és a központi állítás A frontier modellek drágák, és ez agent-méretben már nem fenntartható. A cikk állítása szerint viszont **a legtöbb feladat nem igényel frontier-szintű intelligenciát**. A szerzők a LangChain belső kódoló agentjén, az **Open SWE**-n mérték meg, mennyit ér az, ha a modellválasztás nem globális, hanem feladatonkénti: **a medián költség 64 százalékkal csökkent, mérhető minőségromlás nélkül**. A második, elvi állítás ennél is fontosabb: a **routing döntés helye a harness, nem egy általános gateway**. Az érvelés egyszerű. A jó modellválasztáshoz ugyanaz a domain- és feladatkontextus kell, amit a harness már úgyis összeállít (a prompt, az eszközök, a szakterületi tudás). Egy generic gateway ezzel nem rendelkezik, ezért ott a döntés szükségképpen vak. **A legfontosabb pontok:** - **Modell-harness-feladat illeszkedés**: a jó agent nem a legerősebb modellt használja mindenhol, hanem feladatonként a megfelelőt. A szerzők ezt nevezik *model-harness-task fit*-nek - **A medián költség 64 százalékkal csökkent** (0,94 dollár a 2,61 dollárral szemben), a minőség mérhetően nem változott - **Az átlag 42 százalékkal, a p90 37 százalékkal esett**, tehát a megtakarítás nem néhány olcsó kiugró eset eredménye - **A kérések 90 százaléka nem igényelte a legerősebb modellt**: 56 százalék a középső, 34 százalék a gyors, és csak 10 százalék a csúcs-szintre ment - **A szintek között 30-szoros költségszórás van**: a medián szál 0,097 dollár a gyors, 1,50 dollár a középső és 2,88 dollár a csúcs-szinten - **A router a szál első emberi üzenetén fut, egyszer dönt**, és a modellt az egész szálra rögzíti - **A klasszifikátor a Jev nevű döntési modellre került át**, amitől a besorolás közel **50-szer gyorsabb** lett - **Az ellenkező irányú kontroll megbukott**: amikor a felét kizárólag a gyors modellre irányították, a mérnökök egy nap alatt jelezték a minőségromlást, és a tesztet leállították ## Összegzés A cikk egy négylépéses recept, és a sorrend a lényeg része. Először **meg kell érteni a feladatokat** a saját trace-ekből, mert enélkül a szintek találomra születnek. Másodszor **meg kell érteni a modelleket** a költség-intelligencia görbén, hogy a szintek valós alternatívák legyenek. Harmadszor **a routert a harnessbe kell építeni**, mert a döntéshez szükséges kontextus ott van. Negyedszer **mérni kell a kimenetet**, mert a router értéke csak akkor valódi, ha a minőség nem romlik. A cikk legerősebb része nem a megtakarítás, hanem a **kudarc dokumentálása**. A szerzők lefuttatták az ellenkező irányú kísérletet is (mi történik, ha minden a gyors modellre megy), és **egy nap alatt leállították**, mert a mérnökök azonnal jelezték, hogy a kimenet minősége tönkreteszi a munkájukat. Ez a kontroll nélkül hiányzott volna, és a „64 százalék olcsóbb” eredmény félrevezető lenne. A harmadik tanulság a **mérés kétarcúsága**. Az offline eval a biztonságos út, de a kódoló agentnél nem működik jól: a PR minőségét és review-elhetőségét nehéz offline pontozni. Az élő A/B teszt valósághű, de a felhasználókat egy esetleg nem optimális routernek teszi ki. A szerzők ezért mindkettőt használták, és két jelzést követtek: a **mergelt PR-ok arányát** (erős jel) és a **felhasználói visszajelzést** (ritka, de ott derültek ki a routing-hibák). A negyedik tanulság, hogy **a router a feladathalmazhoz van kötve**, nem általános. A szerzők kimondják: a kritériumok az Open SWE feladataira íródtak, ezért a router „mélyen csatolt” ehhez a feladathalmazhoz. Egy másik agent más kritériumokat igényel. Ez nem hiba, hanem a design következménye: pontosan ezért nem jó helye egy generic gateway. ## 1. lépés: a feladatok megértése A kiindulás nem a modellek, hanem a **saját forgalom**. A szerzők az Open SWE thread-szintű adatait húzták ki a LangSmith trace-ekből, és egy hét interaktív szálát címkézték fel LLM-klasszifikátorral. A megoszlás tanulságos: **az új funkciók 22 százalékot, a hibajavítások 17 százalékot, a teszt- és no-op futások 16 százalékot** tettek ki. Vagyis a kódváltoztatás dominált, de mellette jelentős volt az olyan forgalom, ami egyáltalán nem igényel komoly modellt. A komplexitás mérésére két jelzést használtak, és mindkettő hiányos önmagában. A **költség** viszonylag közvetlenül követi a komplexitást, mert a nagyobb feladat több tokent eszik. Az **invokációk száma** árnyaltabb: magas érték jelenthet nehezebb feladatot, de jelentheti azt is, hogy a modellnek utólagos körökre volt szüksége. A feature-felderítéssel kapcsolatos szálak hosszabbak és drágábbak voltak, a tesztelési és kiadási folyamatok rövidek és olcsók. A fontos megfigyelés: **abban az időben minden szál a legdrágább frontier modellen futott**, miközben a komplexitás eloszlása széles volt. Ez adta a tesztelhető hipotézist: a router a kezdeti kérésből meg tudja becsülni a feladat típusát és nehézségét, és elküldheti a megfelelő szintre. ## 2. lépés: a modellek megértése A második lépés a modellválasztás megalapozása. A szerzők az **Artificial Analysis Intelligence Index**-et használták, ami a modelleket közös feladathalmazon pontozza, és megadja a feladatonkénti költséget, így egyetlen görbére lehet tenni az intelligenciát a költség függvényében. A **Pareto-front** azoknak a modelleknek a halmaza, amelyek egyszerre a legolcsóbbak és a legokosabbak. Három szintet választottak, mindegyiket más egyensúllyal: - **Gyors:** GLM-5.3-Flash (xhigh) - **Kiegyensúlyozott:** GPT-5.6 Sol (medium) - **Teljesítmény:** GPT-6 Astra (low) Két megjegyzésük érdemes figyelemre. A három modell **különböző szolgáltatóktól** érkezik, és a gyors szint **nyílt modell**. A GLM-5.3-Flash a Pareto-fronton ül, zárt modellek mellett, amit a szerzők úgy olvasnak: **a nyílt modellek átléptek egy küszöböt**. A másik, hogy a LangChain modell-agnosztikus, ezért egy jobb modell bevezetése **egyetlen sor** cseréje a routerben. ## 3. lépés: a router a harnessben A router maga három részből áll: - **Alapprompt:** megmondja a klasszifikátornak a feladatát, azt, hogy a legkevésbé drága modellt válassza, ami valószínűleg elvégzi a munkát - **Szintenkénti kritériumok:** rövid, hétköznapi nyelvű leírás arról, milyen munka tartozik az adott szinthez - **Klasszifikátor modell:** elolvassa a kérést, és a kritériumok szerint szintet választ A kritériumok megírásához két forrást kell összevezetni, és ezt a szerzők külön kiemelik: **a saját feladat-elemzésedet és a szolgáltatók saját útmutatóit** arról, mire jók a modelljeik. Egy általános benchmark csak kiindulópont. A döntés a szál első emberi üzenetén születik meg, és **a modell az egész szálra rögzül**. Ez a legegyszerűbb változat, és a cikk nyíltan elismeri a korlátját: ha egy szál menet közben témát vagy komplexitást vált, ez a design nem kezeli. A megoldást a „mi következik” szekcióba sorolják. A klasszifikátor technikai evolúciója önmagában is tanulságos. Az első verzió egy strukturált kimenetű LLM volt, a kéréssel promptolva. A mostani verzió a **Jev** nevű döntési modellen fut, amitől a besorolás **közel 50-szer gyorsabb** lett. A cikk megjegyzi azt is, hogy ez a döntés azért illik természetesen a harness middleware-rétegébe, mert ott a modellcsere az agent többi részének változtatása nélkül megy. A szerzők a routingot **kontextus-mérnökségnek** nevezik, a klasszikus feature engineering analógiájára: el kell dönteni, milyen információt lásson a router, hogy a döntése jó legyen az adott domainben. ## 4. lépés: az eredmények követése A router értéke az alacsonyabb költség, de **csak akkor, ha a minőség nem esik**. Ehhez két dolgot kell eltalálni egyszerre: a választott modellnek el kell tudnia végezni a feladatot, és a lehető legolcsóbbnak kell lennie, ami még képes rá. Két mérési út létezik, és mindkettőnek megvan a maga ára: - **Offline eval**: a routert fix adathalmazon futtatod, így a verziók biztonságosan és ismételhetően összehasonlíthatók. A buktató az adathalmaz: hasonlítania kell a valós forgalomra, és arra kell pontozni, ami a felhasználóknak fontos. - **Élő A/B teszt**: a szálakat a router és egy egymodelles alapvonal között osztod szét, és egy minden szálon mérhető sikerességi mutatón hasonlítod össze. Az élő forgalom természeténél fogva reprezentatív, cserébe a felhasználók egy esetleg nem optimális routert kapnak. A szerzők két kimeneti jelzést vezettek be. Az **Open SWE mostantól rögzíti minden megnyitott PR-t és azt is, hogy mergelték vagy lezárták**, és a szálankénti mergelt PR lett a fő sikerességi metrika. Emellett **fel-le hüvelykujj értékelést** is bevezettek, hogy a PR-t nem eredményező szálakat is pontozni lehessen; minden értékelés a thread LangSmith trace-ére kerül. A tapasztalatuk szerint a **mergelt PR-ok erősebb jel**, a visszajelzés ritka, mert a szálaknak csak kis része kap értékelést. Viszont pontosan a visszajelzés volt az, ahol a routing-hibák felszínre kerültek. ## Az A/B teszt eredményei Az első teszt 973 szálon futott: a fele a routeren ment, a fele mindig a legerősebb modellen. **A minőség nem változott mérhetően.** A routerezett szálak 29,2 százaléka végződött mergelt PR-ban, a kontrollnál 27,3 százalék (p = 0,49). A PR-nyitási arány is lapos volt (38,9 a 39,6 százalékkal szemben, p = 0,82). **A költség viszont nagyot esett.** A medián routerezett szál 0,94 dollárba került a kontroll 2,61 dollárjával szemben, ez 64 százalék csökkenés. Az átlag 42, a p90 37 százalékkal esett. **A legtöbb kérés nem igényelte a legerősebb modellt.** A routerezett szálak 56 százaléka a kiegyensúlyozott, 34 százaléka a gyors, és csak 10 százaléka a teljesítmény-szintre ment. A szintek közötti költség-létra meredek: a medián szál 0,097 dollár a gyors, 1,50 dollár a kiegyensúlyozott és 2,88 dollár a teljesítmény-szinten, ez **30-szoros szórás**. A felhasználói visszajelzés ugyanabba az irányba mutatott. Amikor egy egyszerű kérés a GPT-6 Astrán futott, a mérnökök közvetlenül jelezték a túlköltekezést: „elég drága ezért a kérdésért”, illetve „ezt a kérést nem a teljesítmény-modellre kellett volna irányítani”. A szerzők maguk is hozzáteszik a helyes önkorrekciót: az eredmény nem meglepő, hiszen a kontroll a legdrágább modelljük volt. A tanulság viszont általános, mert **sok agent túlrotálja a minőséget, és közben túlköltekezik**, különösen ha a feladathalmaza sokszínű. A második teszt az ellenkező kontroll volt: a szálak fele a routeren, fele mindig a gyors modellen. **Ezt a tesztet egy napon belül leállították**, még mielőtt statisztikailag értelmes eredmény születhetett volna. A mérnökök azonnal jelezték a problémát, és a kimenet alacsony minősége zavarta a munkájukat. ## Mi következik A szerzők ezt a routert proof of conceptnek nevezik, amely alapot ad egy optimálisabb routerhez: - **Benchmarkolás DeepSWE-n** vagy más kódolási benchmarkon, hogy a routing döntéseket kontrollált alapvonalon lehessen értékelni, ne csak éles A/B teszten - **Subagentek modellválasztása.** Jelenleg a subagentek a routertől függetlenül választanak modellt; a routing kiterjesztése rájuk, különösen a hosszan futó feladatokon, tovább csökkentheti a költséget - **Menet közbeni újrairányítás.** Ha egy új üzenet eléggé különbözik a korábbiaktól (mondjuk egy kérdés hibajavítássá alakul), a modellcsere megérheti. Az ára a prompt cache: a modellváltás eldobja, és az új modell teljes áron olvassa újra a szálat. Aszinkron agenteknél ez gyakran elhanyagolható, mert a cache a humán körök között úgyis lejár, ha rövid a TTL - **A kritériumok finomítása** több jelzéssel, például a trace-ekből kinyert felhasználói hangulattal: azok a szálak, ahol a felhasználó frusztrált, jelezhetik, hogy erősebb modell kellett volna ## A szerzők kezdő receptje A cikk záró receptje négy pontban, a szerzők megfogalmazása szerint: 1. **A feladatok megértése.** A trace-ek tartalmazzák a valódi rekordot arról, mit kérnek az agenttől; a LangSmith Insights segít megtalálni a mintázatokat, hogy a szintek kiválasztása előtt látható legyen a feladat-mix 2. **A modellek megértése.** Néhány modell kiválasztása a költség-intelligencia görbén, modern benchmarkok alapján 3. **A router beépítése a harnessbe.** A routing kezelése kontextus-mérnökségként: annak eldöntése, milyen információt lásson a router, hogy a döntés jó legyen a saját domainben 4. **A feladat kimenetének követése.** A sikeresség mérése a routing bevezetése **előtt**: evalek, online értékelők vagy felhasználói visszajelzés a trace-eken. Ha az eval-adathalmaz építése túl drága, élő A/B teszt is működik A szerzők hozzáteszik: a feladathoz illő modell folyamatosan változik, ahogy új modellek, köztük nyílt súlyúak is, a frontra kerülnek. Mivel a LangChain modell-agnosztikus, ezeknek a nyereségeknek a begyűjtése egy szint cseréje, nem az agent újraépítése. A gyakorlati fogódzó, amit kínálnak: egy újonnan kiadott **model routing middleware**, aminek megadod az alappromptot, a modell-szinteket és a kritériumokat, ő pedig minden szál elején választ modellt. ## Forrás - Eredeti cikk: (2026-10-01) - Archív példány a Code Newsletter archívumában (X article formátum): - A cikk a LangChain blog posztjának X-en publikált változata; az archívum a teljes szöveget tartalmazza ## Kapcsolódó külső források - **Open SWE**, a nyílt forráskódú kódoló agent, a mérés tárgya: - **A router implementációja**: `agent/middleware/model_selection.py` az Open SWE repóban - **LangSmith**, trace-logolás és observability (nem követeli meg a LangChain-t) - **LangSmith Custom Apps**, a saját trace-elemző felület, amit a feladat-felméréshez és az eredmény-követéshez használtak - **LangSmith Insights**, LLM-alapú csoportosítás a trace-eken - **Artificial Analysis Intelligence Index**, a költség-intelligencia görbe adatforrása - **Jev** (TypeSafe AI), a klasszifikátort futtató döntési modell; a LangChain külön posztot szentelt neki („Building a Harness with Jev”) - **GPT-5.6 Sol**, **GPT-6 Astra**, **GLM-5.3-Flash**, a három választott modell - **DeepSWE**, a tervezett következő benchmark - **Anthropic modellválasztási útmutatója**, amit a cikk a „kevesebb is elég lehet” állítás alátámasztására idéz ## Kapcsolódó belső források - **Laya és a Jev-vita (2026-09-18)**: ugyanaz a Jev, a másik oldalról. A Laya szerzője szerint a TypeSafe a 2025-ös munkáját vezette be újként, és a Jev-számok harmadik féltől származnak. Itt a Jev **pozitív szerepben** jelenik meg: a klasszifikátor futtatója, közel 50-szeres gyorsítással. A két cikk együtt adja a Jev teljes képét - **Hamel Husain: Your AI Product Needs Evals (2026-07-14)**: a háromszintű eval-rendszer, az offline eval és az élő A/B teszt trade-offja, valamint a trace-ek mint a valóság rekordja. A LangChain cikk ugyanezt a metodológiát alkalmazza egy konkrét döntésre - **5 design pattern for long-horizon agent harness (Google Cloud Tech, 2026-08-20)**: a harness-réteg mint beavatkozási pont; a stable prefix és a cache-tudatos tervezés közvetlenül kapcsolódik a menet közbeni újrairányítás cache-költségéhez - **SoL-Pi (arXiv:2609.20519, 2026-09-17)**: a harness-réteg optimalizálása 44,7-49 százalékos token-csökkentéssel és körülbelül 33 százalékos költségmegtakarítással. Ugyanaz a cél (alacsonyabb költség azonos minőség mellett), más mechanizmus (kontextus-tömörítés és tool-fúzió, nem modellválasztás) - **Claude Code context engineering**: a kontextus-összeállítás mint a harness feladata, ami a routing döntés alapját adja ## Hogyan kapcsolódik a saját rendszerünkhöz? 1. **A cikk a saját modell-routing gyakorlatunk elméleti megalapozása.** A `model-routing` skill jelenleg kézi szabályokat sorol fel (vision feladatra MiniMax-M3, bizalmas adatra lokális modell, alapértelmezett DeepSeek-v4.1-flash). A cikk ugyanazt a logikát formalizálja, és hozzáadja, ami hiányzik: **a szintek kritériumait a saját feladat-elemzésből és a szolgáltatói útmutatókból kell megírni**, nem általános benchmarkból 2. **A „routing a harnessben, nem gatewayben” elv közvetlenül érvényes ránk.** A Hermes harness, ezért a modellválasztás a harness kontextusára épülhet (a skill-tár, a memória, a feladat domainje). Ez megerősíti, hogy a modell-pinninget a cron jobokban és a skill-szintű routingot nem érdemes egy külső proxyra bízni 3. **A kritériumok feladathalmaz-specifikusak, nem általánosak.** Ez a figyelmeztetés a saját rendszerünkre is áll: a podcast-feldolgozás (hosszú szöveg, egyetlen nagy írás) és a kódolási feladat (iteratív, eszközhasználat) más-más szint-térképet igényel. Egyetlen globális routing-szabály nem lesz jó mindkettőre 4. **A prompt cache költsége a menet közbeni modellváltásnál.** Ez a mi kontextusunkban is él: a hosszú session-ök prefix-cache-e érték, ezért a modellváltás nem ingyenes. A cikk megoldása (csak akkor váltani, ha a cache úgyis lejárna) közvetlenül átvehető 5. **Az A/B teszt két jelzése adaptálható.** A „mergelt PR” analógja nálunk a **feldolgozott summary minőségi kapuja** (auto-review score, output-integrity gate), a „felhasználói hüvelykujj” analógja pedig a Henky-visszajelzés. A cikk tanulsága szerint az utóbbi ritka, de pont az hozza felszínre a routing-hibákat, ezért érdemes megtartani 6. **A subagentek modellválasztása nálunk is nyitott kérdés.** A cikk ezt a jövő munkájaként jelöli; nálunk a `delegate_task` jelenleg a szülő modelljét örökli, hacsak nincs pinnelve. A cikk érve (a hosszan futó subagenteknél nagy a megtakarítás) közvetlenül vizsgálandó 7. **A benchmark-infláció óvatossága.** A cikk a Pareto-frontot az Artificial Analysis Intelligence Indexből veszi, miközben a korábbi FTF-epizódok (Seth) figyelmeztetnek, hogy a nyilvános benchmarkokra mindenki optimalizál. A helyes olvasat: a benchmark **kiindulópont a szintek kiválasztásához**, a döntés viszont a saját forgalmon mért eredmény legyen