Agent Lightning v1.0: könnyű Harnessed Agentic RL keretrendszer valós ügynökhámokhoz

A Microsoft Research Asia kutatói újraértelmezték azt a módot, ahogyan ügynököket (agents) lehet megerősítéses tanulással (reinforcement learning, RL) képezni: bevezették a Harnessed Agentic RL paradigma fogalmát, és nyílt forráskódúra tették Agent Lightning v1.0 keretrendszerüket. A lényege, hogy a képzés során ugyanaz a „harness” — a ténylegesen éles környezetben használt ügynökhám — vesz részt a tréningben, így nem kell újraimplementálni az ügynököt a tanító rendszerben.

Fő jellemzők és célok

• Könnyű és átlátható: az Agent Lightning v1.0 teljes kódalapja nagyjából 3,500 sor kód, így a rendszer egyszerűen érthető, módosítható és bővíthető.
• Képzés a valós ügynökhámokon: a keretrendszer egy LLM-proxyt helyez el az ügynök és a modell között, így a meglévő harness kód változtatása nélkül a deployed ügynök közvetlenül vesz részt a rolloutekben és a tanításban.
• Natív Kubernetes-támogatás: az ügynökök standard Kubernetes jobokként futnak önálló clusterben, felhőben vagy helyi infrastruktúrán, így nincs szükség fizetős, zárt sandbox-szolgáltatásokra.
• Teljes, reprodukálható kódolóügynök-pipeline: egy end-to-end példában Qwen3.5-9B modell Pass@1 értéke a SWE-bench Verified készletén 41.8%-ról 56.4%-ra nőtt — azaz 14.6 százalékponttal javult — mintegy 6,000 nyílt forrású mintával.

Miért jelent ez változást a hagyományos agentic RL-hez képest?

A korábbi agentic RL megközelítések azt feltételezték, hogy a képző keretrendszer birtokolja az interakciós hurkot az ügynökkel és a környezettel. Ebben a modellben a teljes rollout egy folyamatos tokenpályára vetül, és ezért a legtöbb korai rendszer (például verl, AReaL, slime) újra kellett építse az ügynök ciklusát a trénerben. Sok modern ügynökhám — például mini-SWE-agent, OpenHands, OpenCode, Claude Code, Codex és mások — azonban saját kontextuskezeléssel, tool-protokollokkal és végrehajtási logikával rendelkezik, amelyeket költséges újraimplementálni, és az újraépített ügynök már nem garantáltan azonosan viselkedik az élessel.

Agent Lightning erre válaszként az LLM-proxy megoldást alkalmazza: az ügynök a megszokott módon fut tovább, csak annyit kell tenni, hogy a modell API hívásait az Agent Lightning proxyjára irányítják. Az új v1.0 keretrendszer ezt a megközelítést formalizálja Harnessed Agentic RL néven: a telepített harness maga vesz részt a tanulási rolloutekben.

Négy fő kihívás a valós harnessokkal történő RL-képzésben

Mivel az interakciós hurkot most a harness kezeli, a tréner csak LLM kérések és válaszok sorozatát látja. Ennek következtében egy rollout több, változó számú mintára (sample) bontható — ez négy konkrét problémát okoz:

1. Retokenizáció és minták összefésülése: a harness a kontextust szövegként tartja, de a RL-képzésnek a rollout alatt mintált token ID-k kellenek. A chat-sablon és tokenizátor újrafuttatása eltérő tokenhatárokat eredményezhet, így szomszédos hívások nem mindig egyesíthetők egy mintává.
2. Előny (advantage) számítás: mivel egy rolloutot töredezhetnek al-minták, ha az előnyöket mintaszinten számolják, a sok mintát adó rolloutok túlreprezentálttá válnak, torzítva az eredeti rollout-szintű statisztikákat.
3. Loss normalizáció: egyszerű átlagolás mintaszámmal több súlyt ad a többlet mintát előállító rolloutoknak — mivel a mintaszám gyakran a harness viselkedésének következménye, a normalizációnak ezt is figyelembe kell vennie.
4. Tréning backend ütemezés: a mintaszám és mintahossz csak a harness befejezése után ismert, miközben GPU-szám és a párhuzamos konfigurációk előre fixek; a backendnek változó munkaerőt kell leképeznie rögzített erőforrásokra.

Architektúra: három fő komponens, 3,500 sor kódban

Agent Lightning v1.0 három alapeleme:

• API Gateway: OpenAI-kompatibilis LLM-proxy, tárolja a rolloutekat, a modelleket és az eseményeket; minden harnessből érkező modellhívást összekapcsol a rollouttal, és rögzíti a promptokat, válaszokat és log-probokat.
• Rollout Controller: elindítja és kezeli az ügynök végrehajtást, legyen az helyi folyamat vagy standard Kubernetes job; az ügynök végrehajtását külön tartja a tréner folyamatától.
• Customized Trainer: verl-re épülve létrehozza a rolloutekat, megvárja azok befejezését, begyűjti a mintákat és egy sample adapteren keresztül állítja össze a végső tréningmintákat.

Ezzel a felépítéssel egy meglévő ügynökhám esetén általában elegendő, ha a modell endpointját az Agent Lightning proxyjára irányítják, és a harness gyorsan csatlakozik az RL képzéshez.

Collocated Async RL: jobb GPU-kihasználtság kevesebb erőforrással

Mivel a rollout-idők ügynökönként nagyon eltérőek lehetnek, a szinkron RL a leglassabb ügynök miatt hagyja tétlenül a GPU-kat, míg a teljesen aszinkron RL jobb kihasználtságot ad, de külön GPU-poolokat igényel rolloutokhoz és tréninghez. Agent Lightning v1.0 a Collocated Async RL-t vezeti be: rolloutok és modelfrissítések ugyanazokat a GPU-kat osztoztatják.

A rendszer az update megkezdésekor megállítja új kérések fogadását az API Gatewayen, megvárja a folyamatban lévő hívásokat, lefuttatja az update-et, majd folytatja a rolloutokat. Ez az átmenet transzparens az ügynök harness számára. A kutatók mérései szerint ez közel kétszeres (kb. 2x) végponttól-végpontig sebességnövekedést adott a szinkron RL-hez képest, miközben kevesebb GPU-t használt, mint a hagyományos aszinkron megoldás.

Kubernetes-alapú rolloutok: skálázhatóság költséghatékonyan

Nagy mennyiségű rollout gyűjtése sok CPU-t, memóriát és végrehajtó erőforrást igényel. Más rendszerek gyakran kereskedelmi sandbox szolgáltatásokon futtatják az ügynököket, ami skálázásnál gyorsan költségessé válik. Agent Lightning v1.0 ehelyett a meglévő Kubernetes-clustereket használja: az ügynökök standard Kubernetes jobokként futnak önmenedzselt clusterben, felhői Kubernetesen vagy lokális infrastruktúrán, ami olcsóbb és reprodukálható megoldást ad.

Példa: kódolóügynök-pipeline és kísérleti eredmények

A csapat egy teljes pipeline-t épített SWE-smith, mini-SWE-agent és Qwen3.5-9B használatával: adat-tisztítás, környezetépítés, reward-hacking ellenőrzések és RL-képzés. A tréningkészlet körülbelül 6,000 mintát tartalmazott, és nem igényelt nagy mennyiségű számítási erőt. Csak az RL-képzés eredményeként Qwen3.5-9B Pass@1 értéke a SWE-bench Verified készletén 41.8%-ról 56.4%-ra emelkedett, ami 14.6 százalékpontos abszolút javulás.

A kísérletek továbbá alátámasztották a korábban említett két fontos technikai kérdést: az előnyszámítás (advantage calculation) és a loss normalizáció. A rollout-szintű előnyszámítás és rollout-szintű normalizáció jobb validációs rewardot és stabilabb policy-entrópia-menetet eredményezett a mintaszintű megközelítéshez képest.

Összegzés

Agent Lightning v1.0 és a Harnessed Agentic RL paradigmája a gyakorlati agentek képzésére fókuszál: megtartja az éles környezetben használt harness működését a tréningben, miközben egyszerű, kis kódalapú és Kubernetes-barát megoldást kínál. A bemutatott pipeline és mérések — különösen a 6,000 mintás kísérlet és a 14.6 százalékpontos javulás Qwen3.5-9B esetében — azt mutatják, hogy ez a megközelítés hatékony és költséghatékony alternatívát ad a hagyományos agentic RL megoldásokhoz képest.

Hivatkozások és további anyagok

A kutatás technikai beszámolója és az Agent Lightning v1.0 GitHub-projekt nyílt forrásúként elérhető a Microsoft Research bejelentésében.