A kutatók bemutatják a Self-Harness-t, egy keretrendszert, amely lehetővé teszi az AI ügynökek számára, hogy saját szabályaikat átírják, így a teljesítményük akár 60%-kal is növekedhet.

Nem minden cégnek kell vagy szabad saját határvidéki AI nyelvi modellt építenie. Azonban a modell irányítása olyan dolog, amelyet a legtöbb vállalat testreszabhat és testreszabnia kell a konkrét céljaik érdekében. Persze, ez könnyebben hangzik, mint amit végrehajtani lehet. Az ügynök irányítások többsége még mindig nagyrészt manuális, ad hoc hibakeresésen keresztül van kalibrálva — egy olyan folyamat, amely nagymértékben támaszkodik az intuícióra, ahelyett, hogy rendszerszintű visszajelzési hurkokra támaszkodna, ami nehézzé teszi a gyorsan fejlődő LLM-ekhez való alkalmazkodást. E kihívás megoldására a Sanghaji Mesterséges Intelligencia Labor kutatói bemutatták az „Önirányítás” (Self-Harness) új paradigmáját, amelyben egy LLM-alapú ügynök rendszerszerűen fejleszti saját működési szabályait. Azáltal, hogy megvizsgálja a saját végrehajtási nyomvonalait javítások alkalmazására, a rendszer a manuális találgatás helyett empirikus bizonyítékokat használ. Az önfejlesztő irányítások lehetővé teszik a fejlesztőcsapatok számára, hogy robusztus, egyedi ügynököket indítsanak, amelyek folyamatosan adaptálják saját végrehajtási protokolljaikat a modell-specifikus gyengeségek leküzdésére. Az irányítás mérnöki kihívása Az LLM-alapú ügynök teljesítményét nemcsak az alapmodell határozza meg, hanem az irányítása is: a környező rendszer, amely kontextust biztosít és lehetővé teszi a modell számára, hogy interakcióba lépjen a környezettel. Az irányítás magában foglalja az olyan komponenseket, mint a rendszergyakorlatok, eszközök, memória, ellenőrzési szabályok, futási politikák, orchestrációs logika és hiba-helyreállítási eljárások. Ez a réteg kulcsfontosságú, mivel sok gyakori ügynöki hiba az irányítóból, nem pedig a modellből származik. Például egy ügynök sikeres eredményeket jelenthet anélkül, hogy ellenőrizné a modell válaszát (pl. lefuttatja a kódot, hogy megbizonyosodjon arról, hogy a teszteken átmegy), vagy folyamatosan megpróbálhatja megismételni egy sikertelen műveletet. Az irányítás felelős a kontextus elavulásának vagy túlterhelésének megakadályozásáért is, amikor az ügynök interakciós története nagyon naggyá válik. A népszerű irányítások példái közé tartozik a SWE-ügynök, a Claude Code, a Codex és az OpenHands. Az irányítás mérnöki munkája továbbra is jelentős kihívást jelent, de a szűk keresztmetszet nem feltétlenül az, hogy az emberek túl lassúak vagy képtelenek. Valójában Hangfan Zhang, az Önirányítás papír vezető szerzője elmondta a VentureBeatnek, hogy „sok esetben egy tapasztalt mérnök, aki mély szaktudással rendelkezik, még mindig jobb változtatásokat javasolhat, mint amit egy LLM ma tud.” Ehelyett a manuális mérnöki munka valódi szűk keresztmetszete az ad hoc hibakeresésre támaszkodó munka. „A mélyebb probléma az, hogy a jelenlegi irányítási mérnöki paradigma gyakran hiányolja a rendszerszintű visszajelzési hurkot,” magyarázta Zhang. „Sok javítást az intuíció, néhány megfigyelt hiba vagy ad hoc hibakeresés alapján végeznek.” Mivel új modellek jelennek meg gyors ütemben, a modell-specifikus irányítás manuális kalibrálására való támaszkodás egyre költségesebbé és tarthatatlanná válik. Míg egyes megközelítések erősebb modelleket használnak a gyengébb célügynökök irányításának javítására, ez a külső irányítástól való függőség önálló kihívásokat is hordoz, mivel ezek a modellek költségesek, nem elérhetők a határmodellekhez, vagy nem illeszkednek a célmodell hibás működési módjaihoz. Az Önirányítás működése Az Önirányítás paradigmája lehetővé teszi az LLM-alapú ügynök számára, hogy javítsa saját irányítását emberi mérnökök vagy erősebb külső modellek segítsége nélkül. Ez a folyamatos önfejlesztés egy háromfázisú iteratív hurkot hajt végre, amely a viselkedési bizonyítékokat irányítási frissítésekké alakítja: Gyengeségfeltárás: A kiindulási irányítástól kezdve az ügynök egy feladatsort végez, amely ellenőrizhető kimenetekkel rendelkező végrehajtási nyomvonalakat állít elő. Az ügynök kategorizálja a sikertelen nyomvonalakat, és megpróbálja észlelni a modell-specifikus hibás mintákat. Irányítási javaslat: Ezekre a hibás mintákra alapozva az ügynök egy „javasló” szerepet játszik, hogy generáljon egy változatos, mégis minimalista irányítási módosítást, amelyek mindegyike egy specifikus hibamechanizmushoz kapcsolódik, hogy elkerülje a túlzottan általános javításokat. Javaslatvalidálás: A rendszer az regressziós tesztekkel értékeli a lehetséges módosításokat. Egy módosítást csak akkor emelnek előtérbe, ha az javítja a teljesítményt anélkül, hogy mérhető romlást okozna a fenntartott feladatokon. Ha több jelölt módosítás átmegy a regressziós teszteken, azokat összevonják a következő verzióba, amely ezután a következő iteráció kiindulási pontjaként szolgál. Annak szemléltetésére, hogy egy vállalat miért van szüksége erre, képzelje el, hogy van egy automatizált problémakijavító ügynök, amely belső dokumentációkat olvas, javításokat ír, és pull kéréseket nyit. Ha a cég frissíti a dokumentációs stílusát, az ügynök hirtelen meghiúsulhat, rossz kontextust hívva le vagy rossz javításokat írva. A felszínen az ügynök egyszerűen töröttnek tűnik. De az Önirányítás ezt az ambiguális hibát megoldható problémává alakítja. „A hibás nyomvonalak megmutatják, hogy az ügynök hol használja rosszul az új dokumentációs formát; a javasló célzott irányítási javítást generálhat... és az értékelő el tudja dönteni, hogy ez a javítás javítja-e a hibás eseteket anélkül, hogy más esetekben romlást okozna,” mondta Zhang. Az Önirányítás működés közben A kutatók az Önirányítást a Terminal-Bench-2.0-n értékelték, egy benchmarkon, amely a általános eszközalapú végrehajtást teszteli, beleértve az artefaktumkezelést, a parancsok használatát, az ellenőrzési viselkedést és a végrehajtási hibákból való helyreállítást. Az Önirányítást a MiniMax M2.5-tel, Qwen3.5-35B-A3B-val és GLM-5-tel alkalmazták. Az önfejlődő irányítás hatásának izolálásához egy minimális irányítást építettek a DeepAgent SDK-ra, amely csak a benchmarkkal szembeni rendszergyakorlatot és az alapértelmezett fájlrendszert és shell eszközöket tartalmazta. A modell backendje, az eszközkészlet, a benchmark környezet és az értékelő változatlanul maradt, míg csak az irányítás változhatott. A mennyiségi eredmények azt mutatják, hogy az ügynökök automatikus irányítási módosítások révén javították teljesítményüket. A fenntartott feladatokon a teljesítmény jelentősen javult, 33-tól 60 százalékig terjedő relatív javulásokkal a különböző modellek esetében. Fontos, hogy egy explicit elfogadási szabály csak azokat a módosításokat támogatja, amelyek javítják a teljesítményt anélkül, hogy elfogadhatatlan romlást okoznának. Ami az Önirányítást hatékonnyá teszi az üzleti alkalmazásokhoz, az az, hogy nem csupán a promptot hosszabbítja meg, vagy általános utasításokat ad hozzá. Ehelyett célzott változásokat vezet be, amelyek a végrehajtás során felmerülő ismétlődő problémákat tükrözik. Például a alapértelmezett irányítás alatt a MiniMax M2.5 végtelenül beakadhatott az adathalmazon belüli konfigurációk felfedezésébe, amíg a végrehajtási környezet ki nem fagyott, így nem tudott semmilyen teljesítményt előállítani. Az Önirányításon keresztül a rendszer azonosította ezt a konkrét hibát, és írt egy "hurokmegszakítót" a futási politikájába, amely arra kényszerítette az ügynököt, hogy 50 eszközhívás után megálljon és átváltoztassa megközelítését. Ezenkívül egy szabályt is hozzáadott, hogy a szükséges artefaktumok kezdeti változatát a lehető leghamarabb elkészítse. Másrészről a Qwen-3.5-nek volt egy szokása, hogy fájl felülírási hibát okozott, majd vakon próbálta megismételni ugyanazt a parancsot, végül szükséges fájlokat törölve a zűrzavar miatt, mielőtt megállt volna. Az önirányítás ezt orvosolta azáltal, hogy bevezetett egy szigorú parancsmegismétlési diszciplínát (megtiltva a pontosan azonos parancsokat) és egy mechanizmust, amely arra kényszerítette az ügynököt, hogy azonnal újra létrehozza az összes hiányzó artefaktumot, ha fájlhiba történt. A GLM-5 váltogatta a környezeti változások megőrzését különböző parancsok között, és gyakran időt pazarolt hatalmas letöltésekre, vagy befejezte a feladatokat, még akkor is, ha a sanity ellenőrzések sikertelenek voltak. Az általa önállóan generált irányítás szabályokat vezetett be, amelyek utasították az ügynököt, hogy megőrizzék a PATH változókat a shell munkamenetek között, korlátozzák a külső számítást, és javítsák a megszakadt sanity ellenőrzéseket, mielőtt befejezték a futásukat. Az automatizált irányítások rejtett költségei Míg az Önirányítás automatizálja az idioszinkratikus modellhibák felderítésének fárasztó munkáját, a döntéshozóknak reálisnak kell lenniük a kompromisszumokkal kapcsolatban. Az emberi mérnöki munka automatizált próbálgatással való helyettesítése jelentős számítási többletterhet igényel. „Az Önirányítás a humán mérnöki terhek egy részét helyettesíti ismételt javaslatgenerálással, párhuzamos jelöltértékeléssel és regressziós teszteléssel,” mondta Zhang. „Ez jelentheti, hogy több API token, hosszabb latencia az optimalizálás során, és több infrastruktúra szükséges az értékelési feladatok futtatásához.” Ezenkívül ez a rendszer támaszkodik az értékelési csővezeték pontosságára. A Terminal-Bench-2.0 kísérleteik során a kutatók szigorú, determinisztikus ellenőrzőkre támaszkodtak, hogy biztosítsák, hogy az ügynök javításai valóban hasznosak voltak. Enélkül a szigorú alap igazság nélkül egy automatizált rendszer kockázatot jelent a rossz frissítések előmozdítására. „[Az] értékelési rendszer nem választható alkotóelem; ez az, ami lehetővé teszi, hogy az emberi intuíciót empirikus bizonyítékokra cseréljük,” mondta Zhang. Ez a szigorú ellenőrökre való támaszkodás azt is megszabja, hogy az Önirányítást hol kell telepíteni. „A legjobb telepítési célok azok a környezetek, ahol a hibák mérhetők, és ahol a próbálgatás viszonylag biztonságos,” mondta Zhang, utalva a kódolásra, belső munkafolyamat-automatizálásra és DevOps adatcsövekre, mint ideális felhasználási esetekre. Ezzel szemben a vállalatoknak kerülnie kell az irányítások teljes körű automatizálását magas tétű vagy szubjektív területeken. „A legnyilvánvalóbb figyelmeztető jelek azok a területek, ahol az értékelés szubjektív, késlekedő, nem determinisztikus vagy költséges, ha hibásan kezelik, mint például az orvosi döntéshozatal, biztonságkritikus infrastruktúrák vagy jogi döntések.” A prompt módosítókból visszajelzési építészekké Az önfejlődő ügynökök bevezetése nem jelenti azt, hogy a kódolás vagy az üzleti munkafolyamatok hirtelen embermentessé válnak. Az emberi mérnök és az AI közötti együttműködés minősége továbbra is kulcsfontosságú és nehezen rögzíthető automatizált benchmarkokkal. Ehelyett az mérnöki szakma a magasabb absztrakciós rétegre lép. „Az üzleti mérnökök szerepe elmozdul a mérsékelten egyedi promptok vagy eszközök javításáról a visszajelzési rendszerek tervezésére, amelyek lehetővé teszik az ügynök fejlődését,” jósolta Zhang. Előrehaladva, „az engineer kevésbé lesz prompt-módosító és inkább visszajelzés-építész.” Ahogy az alapvető modellek egyre képesebbé válnak, természetes módon magukhoz vonják azokat a képességeket, amelyek jelenleg manuális irányítást igényelnek. „De amikor ez megtörténik, az irányítás nem fog eltűnni; a hatóköre kibővül, hogy összekapcsolja a modellt gazdagabb külső környezetekkel,” mondta Zhang. „Amíg ez a határviszony nem lép túl azon, amit az emberek meg tudnak ítélni, az emberek továbbra is fontos visszajelzés-ként fognak működni.”