Meta AI és a University of Illinois Urbana–Champaign kutatói bemutatták az EvoHarness-RL nevű keretrendszert, amely arra tanítja a nagy nyelvi modelleket, hogy mikor és hogyan használják a futtatási rétegükhöz (harness) kapcsolódó információkat. A cél különösen hosszú, több lépéses vállalati munkafolyamatoknál fontos: például nagy mennyiségű ügyféladat áttöltése egy régi CRM-ből egy felhőalapú adatbázisba, ahol a feladat órákon át tart, és az ügynök nem támaszkodhat kizárólag a belső kontextusablakra.
Mi a probléma a jelenlegi megközelítésekkel?
A hagyományos megközelítésekben a fejlesztők kézzel írnak szabály- és utasításkészleteket, amelyek lépésről lépésre megmondják az ügynöknek, mit tegyen. Ez azonban merev, és az ügynök nem tanulja meg önállóan mérlegelni a cselekvések költségét és hasznát. Emellett az append-only emlékrendszerek — amelyek csak hozzáadnak korábbi tapasztalatokat — idővel felhalmozhatnak elavult vagy hibás információkat, ami rontja a következtetéseket és növeli a mérnöki ráfordítást.
Xuying Ning, az EvoHarness-RL társszerzője a VentureBeatnek elmondta, hogy a kézi logika és a merev memóriafelépítések gyakran nagy mérnöki költségeket okoznak. Más modellek frissítésekor újra és újra hangolni kell a promptokat, a memória dizájnt és a jogosultságokat, ami lassítja az iterációt.
A BPE: egy egységesített munkatér
Az EvoHarness-RL a harness komponenseit egyetlen, strukturált felületbe foglalja össze, amelyet a Belief, Progress és Experience (BPE) három funkcionális területére osztanak:
- Belief: a környezet aktuális állapotának pontos nyomon követése;
- Progress: a teljesített és függőben lévő részfeladatok kezelése;
- Experience: a korábbi tapasztalatok újrahasznosítása.
Az AI ahelyett, hogy komplex, doménspecifikus API-kkal operálna, négy kompakt meta-akcióval érintkezik a BPE-vel: track (követés), commit (rögzítés/frissítés), recall (visszahívás) és note (feljegyzés). Így az ügynök például lekérdezheti a live környezet állapotát, rögzíthet workflow-frissítéseket, előhívhat korábbi megoldásokat vagy lejegyezhet új felismeréseket.
A BPE koncepció jól kapcsolódik vállalati vertikumokhoz: szoftvermérnökségben a Belief a repozitórium aktuális állapotát reprezentálhatja, a Progress a kész és hátralévő lépéseket, az Experience pedig a korábbi hibajegyekből leszűrt tanulságokat foglalja.
Kétlépcsős tanítás: finomhangolás és költségtudatos megerősítéses tanulás
A módszer két fő fázisból áll:
- Felügyelt harness-finomhangolás: a bázismodell megtanulja, hogyan vonjon ki és strukturáljon hasznos tényeket a zajos végrehajtási logokból a BPE-formátumba.
- Költségtudatos (cost-aware) megerősítéses tanulás: mivel a memórialekérdezések token- és időköltséggel járnak, az ügynök megtanulja felmérni, mikor érdemes eszközöket hívni, és mikor jobb spórolni az erőforrásokkal. Ennek célja, hogy a korábbi, keménykódolt utasítások helyett a futásidőben megtanult viselkedés szülessen.
Eredmények az ALFWorldben
A rendszert az ALFWorld benchmarkon tesztelték, amely szöveges, többlépéses feladatokra fókuszál, és a sorozati logika illetve állapotkövetés kihívásait méri. A kísérletben a kutatók a Qwen3-8B modellt használták bázismodellként. Összehasonlították a tanított 8 milliárd paraméteres modellt több nagy, zárt modelllel (Claude Opus 4.5, GPT-4.1, GPT-5), fagyasztott agent-keretrendszerekkel (például ReAct, ExpeL, ReasoningBank), valamint fejlettebb, tanítható módszerekkel (például GRPO, SkillOS, SkillRL).
A fő eredmények:
- A Qwen3-8B az EvoHarness-RL használatával 96,9% átlagos sikerességet ért el, ami 49,0 százalékponttal jobb a saját ReAct alapú kiinduló pontjához képest.
- A tanított modell felülmúlta a fejlettebb tanítható keretrendszereket: SkillRL 89,9% és SkillOS 80,2%.
- Az 8B modell teljesítménye lényegében megegyezett a drágább, zárt modellek csúcsával: Claude Opus 4.5 kifutás nélkül 96,4%-ot ért el.
A BPE előnyei nem korlátozódtak csak a tanítható modellekre: amikor a kutatók a BPE prompt-time harness-sel szerelték fel a fagyasztott, out-of-the-box frontier modelleket, azok is nagy javulást mutattak. GPT-4.1 sikeressége 22,1 százalékponttal, GPT-5-é pedig 25,7 ponttal nőtt.
Dinamika: harness annealing és harness evolution
A kísérletek során a kutatók két jelenséget figyeltek meg. A „harness annealing” során a modell korai szakaszban gyakran hívta a Progress és Experience trackereket minden lépéshez, de ahogy rutint szerzett, fokozatosan beépítette ezeket a sikeres mintákat a saját paramétereibe, és csökkentette az eszközhasználatot — ami alacsonyabb késleltetést és kisebb token-költséget jelent a gyakorlatban.
A „harness evolution” alatt azt értették, hogy az ügynök dinamikusan változtatta stratégiáját: egyszerű, ismert feladatoknál minimalizálta az eszközhasználatot, míg ismeretlen hibáknál vagy bonyolult helyzetekben intenzívebben használta a Belief és Experience modulokat (például szerverlogok felhívása vagy korábbi jegyek lekérdezése egy rejtett API-hiba megoldásához).
Integráció és gyakorlati megfontolások vállalatok számára
A keretrendszer bevezetésekor a kutatók szerint nem feltétlenül kell lecserélni a meglévő belső eszközöket: EvoHarness-RL egy adaptert használ, amely lehetővé teszi, hogy a doménspecifikus implementációk megmaradjanak, miközben megosztják a tanítható réteget. Ning szerint a BPE jól beilleszthető meglévő orchestration rendszerekbe mint további állapotkezelő réteg.
A költségek minimalizálása érdekében a cikk javasol egy hibrid, aszinkron architektúrát: a konszolidációhoz magas minőségű példákat generálhat egy frontier modell, majd egy nyílt súlyú, olcsóbb modellt lehet finomhangolni a rutin állapotkezelésre. Mivel a konszolidáció aszinkron is történhet, nem feltétlenül lassítja az ügynök fő végrehajtási ciklusát.
Ning megjegyezte, hogy nem minden feladathoz szükséges a teljesen tanítható BPE: rövid, stabil feladatoknál a ReAct vagy a hagyományos RAG megoldások elegendőek lehetnek. A BPE különösen akkor válik értékessé, ha az ügynök órákon, napokon vagy heteken át dolgozik, és kompresszióra, iteratív hibajavításra, illetve az Experience használatára van szükség.
Összegzés
Az EvoHarness-RL egy lépést jelent a workflow engineering paradigmarendszerében: nem a teljes automatizált helyettesítést ígéri, hanem azt, hogy a korábban kézzel megírt, merev futtatási logikát olyan tanítható viselkedéssé alakítja, amely hatékonyabban kezeli a külső állapotot, csökkenti az ismétlődő hibákat és optimalizálja a költségeket. A bemutatott kísérletek alapján a megközelítés különösen ígéretes a költséghatékony, közepes méretű (8B) modellek számára, amelyek versenyképes teljesítményt érhetnek el a legjobb zárt modellekkel szemben.
