A jobb ügynökteljesítményre törekvő AI-csapatok többsége ugyanazokhoz az eszközökhöz nyúl: nagyobb kontextusablakokhoz, több dokumentumhoz és okosabb utasításokhoz. A cikk szerint ez az ösztönös megközelítés teljesen téves. A hiányzó összetevő nem a több információ. Hanem az irányítás. A jól megtervezett irányítási réteg választja el a bemutatóban működő ügynököt az élesben is helytállótól.
A nagyobb memória, több dokumentum vagy hosszabb kontextusablak nem teszi okosabbá az AI-ügynököt, csak lassabbá és drágábbá. Az igazi előrelépést az hozza, ha az ügynök megtanulja kiválasztani, mire és mikor van szüksége, ahelyett, hogy egyszerre mindent feldolgozna.
A megbízhatóság a ciklusból ered, nem a modellből. A bemutatón lenyűgöző és az élesben is helytálló ügynök közötti különbséget nem az AI minősége adja, hanem az, hogy a rendszer ellenőrzi-e a saját munkáját. A minden lépésben tervező, cselekvő, megfigyelő és ellenőrző ügynökök észreveszik saját hibáikat, ahelyett, hogy magabiztosan tévednének.
A legtöbb mai AI-ügynök lényegében néhány extra lépéssel kiegészített chatbot: nincs mechanizmusuk annak felismerésére, hogy jó úton járnak-e, mikor álljanak le, vagy mikor váltsanak megközelítést. A megfelelő irányítási réteg – világos sikerkritériumok, strukturált állapot és validációs ellenőrzések – alakítja az ügynökszerű tárgyat valóban megbízható rendszerré.
Mit ebédelt tegnap?
Valószínűleg nem játszotta le minden emlékét, amíg el nem jutott a „tegnap + ebéd” találathoz. Egyből tapasztalatai azon részéhez ugrott, ahol ezek a fogalmak találhatók. Ez hasznos mentális modell az ügynökök építéséhez:
Az óriási kontextusablak nem memória.
A lekért dokumentumok halmaza nem jelent megértést.
A hosszú gondolatmenet nem jelent megbízhatóságot.
Ezek csak összetevők. Az ügynököt ugyanaz teszi valóban ügynökszerűvé, ami miatt az agyunk sem nyers erővel kutatja át teljes élettörténetünket: az irányítás.
Egy friss felmérés – Ügynöki érvelés nagy nyelvi modellekkel – kiválóan összefoglalta és elnevezte azt a változást, amelyet sokan érzékeltünk fejlesztés közben: a modellen belüli érveléstől az interakción keresztüli érvelés felé tartunk. Ez a bejegyzés nem a tanulmány összefoglalása. Arra tesz kísérletet, hogy a változást gyakorlati rendszertervezési elvekre fordítsa le:
Ha az ügynököket eszközökkel kiegészített chatbotként építjük fel, ugyanazokat a chatbothibákat kapjuk – csak költségesebb következményekkel.
Egy ideig a „tegyük okosabbá a modellt” alapértelmezett receptje lényegében jobb utasításokból, gondolatmenetből, önkonzisztenciából vagy mintavételezésen alapuló fejlesztésekből és esetleg keresésből állt.
A ReAct fordulópontot jelentett, mert természetessé tette a „gondolat → cselekvés → megfigyelés” folyamatát. Vegyük azonban észre a hallgatólagos korlátot: ennek nagy része továbbra is „egylövéses következtetés, csak több tokennel”. A felmérés pontosabban fogalmaz: az ügynöki érvelés a teszteléskori interakció skálázását hangsúlyozza, vagyis a következtetést iteratív folyamattá alakítja, amelyben a modell, a memória és a környezet is végig a ciklus része marad.
Ha épített vagy használt már olyan ügynököt, amely a bemutatókon lenyűgöző, de a valódi munkafolyamatokban törékeny, ez Önnek szól.
Hadd mutassak be egy gyakran látott mintát, amelynek különböző változatait magam is megépítettem:
Vegyünk egy jó chatmodellt
Adjunk hozzá néhány eszközt (keresést, adatbázis-lekérdezést, esetleg kódfuttatást)
Adjunk hozzá RAG-ot
Adjunk hozzá egy „you are an autonomous agent” rendszerutasítást
Tegyük az egészet egy while ciklusba, amíg le nem áll vagy túl nem lépi az időkorlátot
Gratulálunk, elkészült egy ügynökszerű tárgy. Csakhogy kiszámítható módokon hajlamos hibázni:
Kontextusfelduzzadás: minden megfigyelés hozzáadódik; az utasítások régészeti rétegekké válnak.
Vaktában használt eszközök: az alapértelmezett hibamód a „rossz eszköz, de magabiztosan” lesz.
Nincsenek leállási feltételek: azért folytatja, mert képes rá, nem azért, mert kellene.
Nincs fegyelmezett lehorgonyzás: nem veszi észre, hogy téved, hacsak rá nem kényszerítjük.
Memória = csevegési előzmény: ami lényegében naplóírás, tanulásnak nevezve.
Ezért tűnnek az „ügynökök” gyakran varázslatosnak a bemutatókon, de kaotikusnak élesben. Az ügynöki rendszerek éles üzembe állításával szerzett tapasztalataink is ezt igazolják: amint már nem egy modellt, hanem egy rendszert értékelünk, a hibamódok közé tartozik a navigáció, a fegyelmezett eszközhasználat, a kontextus metszése és az értékelés megtervezése is – nem csupán az, hogy „helyesen válaszolt-e a modell”.
A kérdés tehát az: milyen a tudatosan kialakított ügynök?
Hogy mindez kevésbé legyen elvont, íme egy egyszerű, könnyen elképzelhető munkafolyamat: „Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Egy tipikus, „ügynökszerű” megvalósítás így néz ki:
Azonnal lekér egy rakás légitársasági és utazási szabályzatot, még ha egyikre sincs szükség.
Meghív egy keresőeszközt, az eredmények hosszú listáját beilleszti az utasításba, majd „kiválaszt egyet”.
Idő előtt foglal, a feltételek (érkezési idő, poggyász, ülés, szabályzat) ellenőrzése nélkül.
Ha hibázik, kissé másképp próbálkozik újra, de nem világos, mi változott, vagy mit tanult belőle.
A hibát nem az okozza, hogy a modell képtelen az érvelésre, hanem az, hogy a rendszer nem irányítja a munkafolyamatot.
Egy valóban ügynöki változat explicit állapottal és ellenőrzésekkel rendelkező, interaktív folyamatként kezeli a feladatot:
TERVEZÉS: a feltételek megismétlése és a hiányzó információk felsorolása (például „which airport preference?” / „is 1 stop ok?”).
CSELEKVÉS: repülőjárat-keresés indítása strukturált lekérdezéssel (dátumtartomány, érkezési korlát, költségkeret).
MEGFIGYELÉS: az eredmények tárolása egy tömör állapotobjektumban (az 5 legjobb jelölt árral, érkezéssel és átszállásokkal), nem pedig egy óriási beillesztett szövegtömbben.
FRISSÍTÉS: ha nem teljesülnek a feltételek, a lekérdezés finomítása (például „arrival before 6pm is too strict—widen time window or raise budget?”).
ELLENŐRZÉS: validátorok futtatása („érkezés < 18:00”, „ár ≤ £900”, „megfelel a szabályzatnak”, „választható ülés”).
LEÁLLÁS: csak akkor, ha a foglalási API visszaigazolást ad, és minden validátor sikeres.
A változás árnyalatnyi, mégis döntő. A lekérés feltételes, nem reflexszerű; a kontextus kezelt, vagyis az állapot strukturált, nem felhalmozott; az ellenőrzés pedig a ciklus része, nem a felhasználó feladata. A „repülőjegy-foglalást” cseréljük le „beszerzési rendelés létrehozására”, „visszatérítés kiadására”, „éles konfiguráció módosítására” vagy „PR leszállítására”, és ugyanoda jutunk: amint az ügynök képes cselekedni, a ciklus fontosabbá válik az utasításnál.
A fent említett felmérés három rétegbe rendezi az ügynöki érvelést: alapvető (tervezés, eszközhasználat, keresés), önfejlesztő (visszacsatolás és memória) és kollektív (több ügynök koordinációja).
A mélyebb gondolat azonban az, hogy az érvelés a tervezés, a döntéshozatal és az ellenőrzés rendezőelvévé válik, nem csupán egy hihető gondolatmenet generálását szolgálja. Ez egészen addig elvontnak hangzik, amíg hozzá nem rendeljük az architektúra változásaihoz. Három alapvető dolgot érdemes megjegyezni:
Egy jó ügynök nem kezelheti a lekérést úgy, hogy „mindig végre kell hajtani”. A lekérés döntés, nem reflex.
Íme egy gyakorlati ökölszabály:
Ha a rendszer minden fordulóban lekér adatokat, akkor nem lekérési rendszert, hanem kontextusadót építettünk.
Ez a valódi munka során folyton előkerül. Éles üzemzavar hibakeresésekor sem öntjük az összes naplót a kontextusba; az aktuális hipotézis alapján döntjük el, mely mérőszámokat és naplókat kérjük le legközelebb. Ez az „ügynöki lekérés”. Egy konkrétabb minta:
Döntsük el, szükség van-e lekérésre
Ha igen: fogalmazzuk meg a lekérdezést, kérjük le, tekintsük át és emeljük ki a lényeget
Ha a bizonyítékok ellentmondanak egymásnak: kérjünk le újra
Csak ezután szintetizáljunk
Itt kezd eltérni az „ügynöki RAG” is a hagyományos RAG-tól: a lekérés tudatos érvelési lépéssé válik, nem pedig alapértelmezett folyamatszakasz marad.
Amint már nem „egy modellt”, hanem „egy rendszert” értékelünk, fontossá válik az állapot követése és a nyomkövetés.
Az iparág mára egyértelműbben kezeli az ügynöki munkafolyamatok megfigyelhetőségét. Az OpenAI Agents SDK például beépített nyomkövetést és Traces irányítópultot kínál, amely rögzíti az ügynök futásait (generálásokat, eszközhívásokat, átadásokat, védőkorlátokat és egyéni eseményeket), hogy lépésről lépésre hibakeresést és auditot lehessen végezni.
Ez nem pusztán „jó, ha van”. Ez választja el a hibakereshető rendszert attól, amelyet csak megérzés alapján lehet ellenőrizni.
A felmérés leginkább gyakorlatba ültethető része szerintem az, ahogy kertelés nélkül beszél a visszacsatolásról. A visszacsatolást három működésmódra bontja: reflektív visszacsatolásra (generálás → kritika → átdolgozás), parametrikus alkalmazkodásra (tanulás finomhangolással/RL-lel) és validátorvezérelt visszacsatolásra (újrapróbálkozás a validátor sikeréig).
A legtöbb csapatnak a validátorvezérelt visszacsatolással érdemes kezdenie, mert unalmas, de hatékony. Ha tudunk írni bármilyen validátort, amely egységtesztet futtat, sémát ellenőriz, üzleti szabályokat vagy korlátozásokat érvényesít („X felett nincs visszatérítés eszkaláció nélkül”), illetve tényszerűséget követel meg („hivatkozások szükségesek”), akkor a modell nem determinisztikus kimenete valóban megbízhatóvá tehető.
Az egyik egyszerű, korábban nem is sejtett felismerés: az ügynökök világában a megbízhatóság gyakran inkább a ciklusból ered, mint a modellből.
Ez a legegyszerűbb ciklikus módszer, amely tapasztalataim szerint tanítás nélkül is megbízhatóan javítja a működést:
Haladjunk lépésekben: Tervezés → Cselekvés → Megfigyelés → Frissítés,
minden cselekvés után 1–3 pontban foglaljuk össze a megfigyelést,
álljunk le, ha teljesülnek a sikerkritériumok vagy elfogy a keret; adjuk vissza a legjobb ismert eredményt és a fennmaradó bizonytalanságokat.
Nem az a cél, hogy a modell terjengős legyen. Hanem az, hogy a rendszer működése érthető legyen, és minden lépésben szembesüljön a valósággal. A mérnökök számára ismerős példa a CI-szerű, zárt hurkú lehorgonyzás:
Tervezés: módosítási lista javaslata
Cselekvés: tesztek/linter futtatása
Megfigyelés: hibák elemzése
Frissítés: javítás és újrapróbálkozás
Néhány kérdés, amely gyakran leleplezi a véletlenül ügynökszerűvé vált kialakítást:
„Az ügynököm dönti el, mit kérjen le, vagy mindig automatikusan lekérek mindent?”
Ha a lekérés feltétel nélküli, annak nagyobb késleltetés, költség, kontextushígulás és a „szemét be, szemét ki” jelenség fokozott kockázata az ára.
„Észre tudja venni az ügynököm, ha téved?”
Ha az ügynök egyetlen visszacsatolási jele az, hogy „a felhasználó bosszankodik”, akkor emberi szenvedéssel végzünk megerősítéses tanulást. A validátorvezérelt újrapróbálkozási ciklus a legtisztább módja annak, hogy szembesítsük a valósággal.
„Írható a memória, és idővel javul?”
Ha a „memória” csak a csevegési előzményeket bővíti, lényegében naplókat írunk. Fontos, ahogyan a felmérés a memóriát keretezi: dinamikusan bővülő kontextussá válik, amelyet az ügynökök idővel finomítanak – nem csupán átirat marad.
A naplók elmondják, mi történt; a memória azt, hogy legközelebb mit tegyünk. A csevegési előzmény egy átirat. A memória folyamatosan fejlődő szabályrendszer arról, mit érdemes továbbvinni.
Jó kiindulópont egy apró „tanulságok” tábla, amelyben a kulcs a feladattípus, az eszköz és a hibamód, az érték pedig az, hogy mi vált be, és mit kell kerülni. Nem egy tökéletes tudásgráf felépítése a cél. A cél az egymásra épülő fejlődés: a memória és a visszacsatolás az „állapot nélküli segítőkből” idővel javuló rendszereket alkot.
Csábító több ügynököt ráereszteni a problémára, ez azonban gyakran megsokszorozza a koordinációs terheket. Egy jó „minimálisan életképes csapat” mintája:
Koordinátor: felbontja és kiosztja a feladatokat
Végrehajtó: eszközöket hív meg és módosításokat végez
Kritikus/értékelő: ellenőrzi a helyességet és a kockázatot
Memóriagondozó: rögzíti és válogatja a tanulságokat
Ha nem tudjuk elmagyarázni, miért felel az egyes ügynökök, valószínűleg még nincs szükségünk többre.
Ha valóban elfogadjuk a paradigmaváltást, valószínűleg felhagyunk azzal, hogy mindent utasításokba zsúfoljunk, a hibákat végleges kimenetként kezeljük, és az ügynököket chatbotként értékeljük. Ehelyett annak kezeljük az ügynököket, amik valójában: olyan szoftverrendszereknek, amelyekben a nyelv az irányítási sík, a megbízhatóság pedig a ciklusból ered.
Mielőtt hozzáadnánk egy újabb modellt, adjunk hozzá még egy értékelési ciklust. Mielőtt mindent lekérnénk, tegyük feltételessé a lekérést. Előbb szállítsunk le egy validátort, mint tízet. A memóriát szabályzati döntésekként kezeljük, ne adatbázisként. Többügynökös működésre váltva pedig kettővel kezdjünk, ne hússzal. Ezek nem szabályok, hanem olyan minták, amelyek kiállták az éles használat próbáját.