A Xiaomi HarnessX közvetlenül a feladat közben írja át saját AI keretrendszerét — és a kisebb modellek használnak a legnagyobbat.

Ahogy a vállalati AI ügynökök egyre összetettebb, hosszú távú feladatokat vállalnak, teljesítményüket gyakran korlátozza a "harness", az a szoftveres keretrendszer, amely összekapcsolja a háttérben működő LLM-et a környezetével. Jelenleg a harness-ek nagyrészt statikusak és kézműves módon készülnek. Fejlesztésük túlnyomórészt manuális folyamat, és nem javulnak automatikusan az általuk gyűjtött végrehajtási adatok alapján. Az emiatt fellépő mérnöki szűkület kezelése érdekében a Xiaomi kutatói bemutatták a HarnessX-et, egy olyan keretrendszert, amely az AI harness-t összetevőként kezeli, és önállóan alkalmaz javításokat a kódjára. A valós vállalati alkalmazásokban ez az automatizált alkalmazkodás lehetővé teszi az AI rendszerek számára, hogy dinamikusan igazodjanak az alkalmazás-specifikus követelményekhez. A gyakorlati tesztek azt mutatták, hogy a HarnessX jelentős teljesítménynövekedést eredményezett olyan területeken, mint a szoftvermérnökség és a webes interakció. Az eredmények azt bizonyítják, hogy az alapmodellt nemcsak skálázni lehet a képesebb AI érdekében - és kisebb modellek esetén ez talán nem is a legjobb megoldás. A HarnessX harness fejlesztése átlagosan +14,5%-os teljesítménynövekedést eredményezett 15 modell-benchmark kombinációban; az open-weight Qwen3.5-9B esetében a nyereség +44% volt a megvalósított tervezési feladatok során. A harness mérnöki kihívásai Az AI alkalmazásokban az alapmodell képessége nagymértékben függ a környező harness-től. A harness működési rétegként funkcionál, amely a nyers modellkimeneteket strukturált, végrehajtható ügynöki viselkedésekké alakítja. Tartalmazza a promptokat, külső eszközintegrációkat, memória kezelést és vezérlési folyamatokat, amelyek meghatározzák, hogyan figyeli az AI rendszer a környezetét, hogyan gondolkodik egy problémán, és miként cselekszik. Ahogy a vállalati ügynökök egyre összetettebb, hosszú távú munkafolyamatokat vállalnak, a harness mérnöki munka a mesterséges intelligencia fejlesztésének alapvető részévé vált. Annak ellenére, hogy a harness fejlesztésének fontossága vitathatatlan, a terület messze van az érett mérnöki diszciplínától, és három fő kihívással néz szembe. Először is, a harness-ek statikusak és kézműves módon készülnek. Bármilyen változás az alapmodellben, új eszközök bevezetése vagy egy másik működési területre való áttérés egyedi, manuális kód újraírásokat igényel. A hagyományos harness-ek nem rendelkeznek olyan mechanizmusokkal, amelyek lehetővé tennék számukra, hogy automatikusan tanuljanak és fejlődjenek a korábbi végrehajtási tapasztalatokból. Másodszor, a meglévő harness-ek többsége architekturális összefonódással küzd. Szorosan összekapcsolják a prompt sablonokat, az eszközöket, az újrapróbálási politikákat és a memória kezelést ugyanabban a kódúton. Ez az összefonódás azt jelenti, hogy egy komponens módosítása csendben másokat is megszakíthat. Különböző vállalati területeken a harness újbóli felhasználása gyakran nyers kód másolásába torkollik ahelyett, hogy tiszta, moduláris összetételt hozna létre. Harmadszor, a harness és az alapmodell izoláltan van optimalizálva. Amikor a mérnökök teszteket futtatnak a harness javítására, a keletkező végrehajtási nyomokat jellemzően eldobják, ahelyett, hogy training adatként felhasználnák a modell javítására. Következésképpen a modellfrissítések nem vezetnek a harness javulásához, ami szűk keresztmetszetet eredményez, ahol a csapatok nem képesek maximálisan kihasználni az ügynök működési adatait. HarnessX: autonóm üzem a mesterséges intelligencia ügynökök számára A HarnessX megoldja a manuális harness fejlesztés mérnöki szűk keresztmetszeteit azzal, amit a kutatók "egységes harness üzemnek" neveznek. A HarnessX alapvető újítása, hogy a harness-t "első osztályú objektumként" kezeli. Szoftvermérnöki értelemben ez azt jelenti, hogy a harness egy függetlenül sorozatba állítható, moduláris és helyettesíthető entitás. A modell konfigurálását (azaz, hogy melyik AI modell működik) elválasztva a harness konfigurálásától a mérnökök zökkenőmentesen cserélhetik, alakíthatják és fejleszthetik a vázszerkezetet anélkül, hogy megérintenék az alapmodellt. A HarnessX az ügynöki viselkedést különböző komponensekre bontja, mint például a kontextus összeszerelés, memória kezelés, eszközöket ölelbe vevő ökoszisztémák, vezérlési folyamatok és megfigyelhetőség. Minden egyes konkrét viselkedést "feldolgozóként" valósítanak meg, amelyek a harness életciklusának precíz horgaira csatlakoznak. Ez a moduláris struktúra lehetővé teszi a rendszer számára, hogy ezeket a feldolgozókat cserélje, hozzáadja vagy eltávolítsa anélkül, hogy megszakítaná a környező folyamatot. Az automatizált optimalizálás érdekében a HarnessX bevezeti az AEGIS-t, egy nyomkövetésen alapuló fejlődési motort. Az AEGIS úgy keretezi a harness alkalmazkodást, mint egy megerősített tanulási (RL) problémát, amely a harness különböző szimbolikus komponenseire vonatkozik. A harness optimalizálását megerősített tanulási problémának keretezni három patológiát vezetett be, amelyekkel a kutatóknak expliciten mérnökeikkel kellett dolgozniuk: Jutalom manipulálás: A rendszer kihasználhatja a megoldás rövidítéseit, ahelyett, hogy valóban megoldaná a feladatot. Katasztrofális elfelejtés: Egy szerkesztés, amely kijavít egy hibás mintázatot egy területen, csendben megszakíthat egy korábban megoldott munkafolyamatot egy másikon. Alulfedezés: A rendszer kisebb prompt módosításokon iterálhat, ahelyett, hogy új, szerkezetileg fejlettebb eszközkonfigurációkat fedezne fel. E problémák elkerülése érdekében az AEGIS teljes nyomkövetési láthatóságra és egy négyfokozatú folyamatra támaszkodik: Emésztő: Összenyomja a végrehajtási nyomokat strukturált összefoglalókká, hogy azonosítsa, hol akad el az ügynök. Tervező: Elemzi ezeket az összefoglalókat, hogy lehetővé tegye a rendszer számára a strukturális változások feltérképezését, nem csupán helyi prompt módosításokat. Fejlesztő: Kód szintű szerkesztéseket generál a harnessben, valamint teszteket, hogy biztosítsa, hogy helyesen fussanak a telepítés előtt. Kritikus és kapu: A Kritikus értékeli a szerkesztéseket, hogy észlelje a jutalom manipulálást, míg egy determinisztikus kapu elutasít minden frissítést, amely visszaesik egy korábban megoldott feladathoz, hogy megakadályozza a katasztrofális elfelejtést. A HarnessX belépett az önjavító harness-kutatás növekvő területére — de ami megkülönbözteti, az a harness-model közös fejlődése. A kutatók hangsúlyozzák, hogy bármelyik komponens optimalizálása izoláltan végül falba ütközik. Csak a harness fejlődése vázszerkezeti plafont ütközik, ha az alapmodell nem rendelkezik a szükséges észlelési képességekkel az új eszközök használatához. Csak a modell képzése eléri a képzési jel plafonát, ha a harness soha nem kéri a modellt, hogy használja fejlett képességeit. A HarnessX összekapcsolja a harness fejlődését a modellképzéssel. A végrehajtási nyomok, amelyeket a harness generál, miközben alkalmazkodik a feladatokhoz, megerősített tanulási jelekké alakulnak az alapmodell számára. Minden alkalommal, amikor a harness javítja stratégiáját, a modell egyidőben tanulja meg, hogy jobban kihasználja ezt az új stratégiát, megszakítva a hagyományos AI ügynök fejlesztésének képesség plafonjait. A HarnessX ezt a közös fejlődést lehetővé teszi a kereszt-harness GRPO (Csoport Relatív Politika Optimalizálás) által. A GRPO az a népszerű RL algoritmus, amelyet olyan észlelési modellek képzésére használnak, mint a DeepSeek-R1. A modell finomítése során a kereszt-harness GRPO egy ügynök végrehajtási pályáit gyűjti össze ugyanarra a feladatra, teljesen különböző verziójú harness-ek között. Ez lehetővé teszi az alapmodell számára, hogy belsővé tegye a magas szintű stratégiai elmozdulásokat, mint például egy új API végpont használata vagy egy végrehajtási költségkeret kezelése, ahelyett, hogy csupán kisebb prompt-formulázási változásokat tanulna. A HarnessX a gyakorlati benchmark-okon A HarnessX gyakorlati hasznosságának érvényesítése érdekében a kutatók öt benchmarkon tesztelték, amelyek a szoftvermérnökséget, a többkörös ügyfélszolgálati párbeszédet, a webes navigációt, az nyitott végű több lépcsős észlelés fenntartását és a megvalósított tervezést ölelték fel. Az AI-t két szerepre osztották. A “meta-ügynök”, amelyet a Claude Opus 4.6 hajtott, elemezte a naplókat és megírta a kódot a harness-ek fejlesztéséhez. A “feladatügyfelek” futották a tényleges munkafolyamatokat. Annak bizonyítására, hogy a keretrendszer modellfüggetlen, három különböző munkamodellel tesztelték: Claude Sonnet 4.6, GPT-5.4, és az open-weight Qwen3.5-9B. A HarnessX-et két alapvizsgálat ellen hasonlították össze. Az első egy statikus harness volt, amely a legtöbb vállalkozás ma használja, olyan kézműves, rögzített beállításokkal, amelyek benchmark-specifikus promptokat és eszközöket használnak. A második a Claude Code SDK volt, amely egy alapként szolgáló, egyetlen ügynököt fejlődtető referenciát képviselt, hogy teszteljék, vajon a komplex, négyfokozatú AEGIS folyamat meghaladja-e annyira, hogy csak egy nyelvi modellt kérjünk arra, hogy iteráljon a kódon. A harness dinamikus fejlődése jelentős nyereségeket hoz ugyanazon alapmodell esetében. A HarnessX 14-ből 15 modell-benchmark kombinációban javította a teljesítményt. Az összes teszt során a harness fejlődése átlagosan 14,5%-os abszolút teljesítménynövekedést eredményezett. A leggyengébb modellek a dinamikus harness javításából profitáltak a legjobban. Az open-weight Qwen3.5-9B a +44,0%-os teljesítménynövelést látta az ALFWorld megvalósított tervezési benchmarkon, és +18,2%-os ugrást a SWE-bench ellenőrzött szoftvermérnökségben. A közös fejlődés szintén rendkívül hatékonynak bizonyult. Amikor a kutatók a foundation modelt tanították a harness fejlesztése során keletkezett adatok felhasználásával, további +4,7%-os átlagos teljesítménynövekedést tapasztaltak. A harness és a modell egyidejű fejlesztése hozza a legmagasabb plafont. A közös fejlődési nyereség csak az open-weight modellekre vonatkozik. Az kísérletekből származó anekdotikus bizonyítékok megmutatják, hogyan oldja meg a HarnessX a bosszantó problémákat, amikor ügynöki harness-okat hoz létre a valós feladatokhoz. Például a GAIA több lépcsős észlelési benchmarkban a feladatügynök folyamatosan kudarcot vallott, mert a használatával lévő fej nélküli böngésző eszköz, amit a Wikipédiáról való adatgyűjtésre használt, időkorlát miatt leállt a weboldal JavaScriptet sűrűn használó frontendjén. A HarnessX elemezte a végrehajtási nyomokat, diagnosztizálta a hibát, és írt egy új eszközt, amely teljesen megkerülte a böngészőt, és közvetlenül a MediaWiki API-t hívta meg sima szövegért. Ezt az eszközt behelyezte a harness-be, azonnal feloldva a meghibásodott feladatokat. A WebShop e-kereskedelmi tesztek során az AI ügynök sokszor beragadt a lapozási hurkokba, végtelenszor kattintva a "következő oldal" gombra és újraformálva kereséseit anélkül, hogy valaha is döntést hozott volna egy termék megvásárlásáról. Ahelyett, hogy csupán módosította volna a promptot, a HarnessX épített egy tanácsadó feldolgozót, amely észlelte, amikor az ügynök ismétlődő navigációs műveleteket hajtott végre. Figyelmeztetést iktatott be a kontextusba, hogy kényszerítse a döntést, gyógyítva a hurkoló viselkedést és növelve a teljesítményt. Az automatizált harness mérnöki munka korlátai Fontos megjegyezni, hogy a rendszer jelenleg erős modellekre támaszkodik, hogy meta-ügynökként újraírja a harness kódot. Kísérleteik során a kutatók zárt határellen lévő modellekre, mint például Claude Opus-ra támaszkodtak. Az open-weight modellek gyorsan fejlődnek, de képességük, hogy meta-ügynökként szolgáljanak, még nem lett tesztelve. Egy másik figyelembe veendő korlátozás a használt modellek belső képességei. Ha az alap feladatomodell alapvetően túl gyenge a komplex munkafolyamatok végrehajtásához, amelyet az új harness javasol, a HarnessX nem lesz képes javítani az ügynök általános képességeit (a kutatók ezt megfigyelték a Qwen3.5-9B modellel a SWE-bench kódolási teszteknél). Ezek ellenére a HarnessX egyértelmű esetet mutat be, hogy a harness mérnökség - nem csak a modell skálázása - az a hatály, amelyet a gyakorlati szakemberek most kihasználhatnak. Azoknak a csapatoknak, akik kisebb open-weight modelleket futtatnak komplex munkafolyamatokban, a nyereségek elég jelentősek ahhoz, hogy érdemes legyen a harness fejlődését első lépésként mérlegelni, mielőtt egy drágább határellen lévő modellhez nyúlnának. A kutatók tervezik a kód kiadását a jövőbeli frissítésekben.