A Microsoft Research csapat kutatói azt a gyakorlati problémát vették célba, hogy a modern mesterséges intelligencia alapú ügynökök hibáit sokszor nehéz gyorsan és pontosan megtalálni. Ezek az ügynökök már nem csak válaszokat adnak, hanem hosszabb folyamatokat visznek végig, eszközöket hívnak meg, állapotot módosítanak, és több szereplő között is koordinálnak, így egyetlen rossz lépés könnyen boríthatja a teljes folyamatot.
Miért különösen nehéz a hibakeresés
Az ügynökök működése gyakran valószínűségi, a futások hosszúak, az eszközök kimenetei zajosak lehetnek, és a hibák mellékhatásokon keresztül is felhalmozódhatnak, mielőtt a végső eredményen egyáltalán látszanának. Emiatt a fejlesztő számára nem az a legnagyobb kérdés, hogy rossz lett-e a végeredmény, hanem az, hogy hol történt az a döntés, amely után a rendszer már nem tudott visszatérni a helyes útra.
A kritikus hiba fogalma
A tanulmány a kritikus hibát úgy definiálja, mint egy végrehajtási nyomvonal legelső olyan hibáját, amelyet az ügynökök már nem tudnak helyrehozni, és amely végül megakadályozza a feladat sikeres befejezését. Ez a megközelítés szándékosan elkülönül attól, hogy menet közben korábban történt-e kisebb botlás. Lehetnek ugyanis olyan hibák, amelyek később még korrigálhatók, de a kritikus lépés az, amely után a futás érdemben már nem menthető.
Egy új mérce a sikertelen futások megértéséhez
A szerzők 115 sikertelen ügynökfutásból álló, nyílt adathalmazt tettek közzé, amely három különböző ügynökös területet fed le, és minden nyomvonalnál lépés szinten jelöli a kritikus hibát, valamint annak kategóriáját. A cél kifejezetten az, hogy a hibák okát és helyét ne utólagos benyomásokból, hanem a futás tényleges eseményeiből lehessen visszafejteni.
Kilenc visszatérő gyökérok a hibák mögött
A kézi elemzés eredménye egy kilenc kategóriából álló, több területre általánosítható hibatipológia, amely megmutatja, milyen jellegű hibák tesznek egy futást visszafordíthatatlanná. A kategóriák között hangsúlyos az eszközkimenet félreértelmezése, amikor az ügynök rosszul következtet egy válaszból, és emiatt hibás állítást vagy rossz lépést épít rá. Szintén gyakori, amikor a terv vagy az instrukciók követése sérül, vagy amikor a rendszer új, nem alátámasztott információt vezet be. A tipológia azért fontos, mert egységes nyelvet ad a hibák leírásához, így a diagnózis és a javítás is összehasonlíthatóvá válik különböző rendszerek között.
Az AGENTRX keretrendszer lényege
A tanulmány központi technikai hozzájárulása az AGENTRX nevű, területtől független diagnosztikai keret, amely a különböző formátumú ügynöknaplókat egységes futási reprezentációvá alakítja, majd a rendelkezésre álló eszközleírásokból, szabályokból és a nyomvonal addigi részéből ellenőrizhető kötelezettségeket állít elő. Ezeket a kötelezettségeket lépésről lépésre ellenőrzi, és egy olyan naplót készít, amely konkrét szabálysértéseket és a hozzájuk tartozó bizonyítékot rögzíti.
Miért számít az auditható bizonyíték
A megközelítés gyakorlati előnye, hogy a diagnózis nem csak egy vélemény arról, mi romlott el, hanem nyomvonalrészletekkel alátámasztott állítás. A tanulmány példája szerint az AGENTRX képes olyan ellenőrzéseket felépíteni, amelyek újraszámolják vagy újraértékelik egy eszközhívás kimenetét, majd jelzik, ha az ügynök következtetése nem egyezik a tényleges adattal. Ez a fajta bizonyítékalapú jelzés különösen értékes ott, ahol a hibák nem azonnal állítják meg a futást, hanem csendben rontják a további döntések minőségét.
A korlátok és a felelős használat
A tanulmány világosan jelzi, hogy a módszer nem tévedhetetlen. Gyengébb vagy zajos validációs jeleknél a rendszer félrevezethető, és előfordulhatnak téves riasztások, ezért a diagnózist továbbra is érdemes mérnöki józan ésszel ellenőrizni. Ugyanakkor a szerzők azt is hangsúlyozzák, hogy az automatizált diagnózis csökkentheti a kézi elemzés költségét, és skálázhatóbb irányba tolhatja az ügynökök megbízhatóságának javítását.
Forrás: Barke, Shraddha et al. “AgentRx: Diagnosing AI Agent Failures from Execution Trajectories.” (2026).
Címlapkép: Depostipohots
