Mi a számítógép-használat, és miért fontos? A számítógép-használat egyszerű ötlet, mégis messzemenő következményekkel jár: ahelyett, hogy válaszokat kérnénk a modellektől, szoftvereket működtetünk velük – webhelyeken navigálnak, űrlapokat töltenek ki, végighaladnak munkafolyamatokon, és önállóan, az elejétől a végéig elvégzik a feladatokat.
Ez valós feladatok széles körét teszi megoldhatóvá, amelyek jelenleg különböző felületek között töredeznek szét: például teljes foglalási és webáruházi fizetési folyamatokat, többlépéses utazástervezést, valamint olyan háttérirodai munkafolyamatokat, amelyeknek nincs letisztult API-megfelelőjük. Ezek nem új problémák. Az az újdonság, hogy immár általános célú modellekkel is megoldhatók.
Az Anthropic és az OpenAI legújabb rendszerei olyan ügynököket mutattak be, amelyek nemcsak cselekszenek, hanem értelmezik is az állapotot, helyreállnak a hibákból, és menet közben feladatspecifikus megoldásokat alkotnak. Ezzel a böngésző az ügynökök általános végrehajtási környezetévé válik, de rögtön felmerül egy tervezési kérdés: mennyit tárjunk fel ebből a környezetből a modell előtt?
A korai rendszerek válasza az volt, hogy a böngészőt biztonságos, előre meghatározott műveletek rögzített készletébe burkolták. Amint ebben a bejegyzésben bemutatjuk, ez a megközelítés elérte a határait.
Böngészőügynökök fejlesztésekor ismerős ösztön, hogy ne bízzunk túlságosan a modellben.
Ezért burkolóval vesszük körül a böngészőt. Olyan előre meghatározott eszközöket teszünk elérhetővé, mint a click, a type, a scroll, a select és a read_text. Leegyszerűsítjük a dokumentumobjektum-modellt (DOM). Leszűkítjük a műveleti teret. Az általunk tervezett absztrakciókkal igyekszünk átláthatóvá és irányíthatóvá tenni a viselkedést.
Ez észszerű kiindulópont. Ugyanakkor hosszú távon egyre inkább ez a helytelen architektúra.
Az élvonalbeli modellek fejlődésével már nem pusztán az jelenti a korlátot, hogy a modellnek nincsenek megfelelő eszközei. Hanem az, hogy olyan absztrakciókon keresztül kényszerítjük működésre, amelyek túl sokat elfednek az alapul szolgáló rendszerből. Egy rendezetlen, dinamikus környezetet rögzített műveleti felületté tömörítünk, majd azt várjuk a modelltől, hogy az így elvesző információk ellenére is jól teljesítsen.
Ez a kompromisszum egyre kevésbé vonzó.
Az általunk vizsgált váltás könnyen leírható, de jelentős következményekkel jár. Az ügynököt nem előre meghatározott műveletek kiválasztójaként, hanem korlátozott futtatókörnyezetben működő programszintetizálóként kezeljük.
A modellek rendkívül jók lettek, ezért már nincs szükségük az absztrahált védőkorlátainkra. A teljes műveleti térre van szükségük ahhoz, hogy megtervezzék és végrehajtsák a feladatot, majd addig finomítsák a megoldást, amíg el nem érik a céljukat.
Ez a bejegyzés erről a váltásról szól: az absztrakciókra épülő böngészőautomatizálástól a korlátozott számítógép-használatig, valamint arról, mi változik az így megtervezett rendszerekben.
Nem az a probléma, hogy a rögzített műveleti felületek elvben helytelenek. Hanem az, hogy a web nem alkalmazkodik hozzájuk.
A modern felületek Reactre, Vue-ra és Angularra épülnek, aszinkron állapotfrissítésekkel, szintetikus eseményrendszerekkel és olyan beágyazott külső modulokkal, amelyek eltérő eredetű iframe-ekben, saját életciklussal működnek. Az „írj ebbe a beviteli mezőbe” műveletet kínáló burkoló csak akkor működik helyesen, ha az oldal is ugyanazt érti gépelés alatt. Sok oldal nem így működik. Egy érték közvetlen beállítása gyakran teljesen megkerüli a keretrendszer változásérzékelését. A mező kitöltöttnek látszik. Az ellenőrzés nem indul el. Az űrlap továbbra sem működik.
Ezt ki lehet javítani. Különleges eseteket adhatunk hozzá a React beviteli mezőihez, a fókuszálás után blur eseményeket küldhetünk, az állapot beolvasása előtt pedig megvárhatjuk, amíg megszűnik a hálózati forgalom. Minden egyes javítás helyben helyes. Együtt azonban egy egyre nehezebben karbantartható rendszerré állnak össze, amely mindinkább a már ismert webhelyekre specializálódik.
A mélyebb probléma az, hogy az absztrakciós rétegbe kódoljuk az interakciók működésére vonatkozó feltételezéseinket, majd rájövünk, hogy a web más feltételezések szerint működik.
Vegyünk egy Stripe vagy Adyen segítségével, eltérő eredetű iframe-be ágyazott fizetési űrlapot. A burkoló nem fér hozzá közvetlenül, mert külön eredetről származik. A read_text eszköz nem látja a belső állapotát. A type eszköz nem tudja megcímezni a beviteli mezőit. A burkolókra épülő ügynök itt falba ütközik. Az absztrakciót a fő dokumentumhoz tervezték. A tényleges feladat azonban olyan helyen található, amelyet az absztrakció nem lát.
Hasonló eltérés kevésbé nyilvánvaló folyamatokban is előfordul. Előfordulhat, hogy egy keretrendszer által vezérelt legördülő menü egyáltalán nem reagál a közvetlen kattintásra, mert a látható elem nem a tényleges vezérlő. A háttérben zajló állapotváltás kiváltásához billentyűzetesemények sorozatára lehet szükség. Kívülről úgy tűnik, hogy a felületen lehet kattintani. Az absztrakció azt mondja: „kattints”. Semmi sem történik.
Vagy vegyünk egy többlépéses modális folyamatot, amelyben a látható DOM frissítései elmaradnak a belső állapotváltozások mögött. A helyes következő művelet olyan állapotváltástól függ, amely még nem jelenik meg a burkoló által látható elemekben. A burkolókra épülő ügynök végül túl korán cselekszik vagy elavult állapotot olvas, mert csak hiányos képe van a rendszerről.
Az absztrakció minden ilyen esetben elrejti az ügynök számára ténylegesen szükséges jeleket.
Egy alacsonyabb szinten működő modell képes eligazodni ezekben a helyzetekben: megvizsgálja az aktuális DOM-ot, értelmezi a keretek határait, és az adott felülethez igazodó interakciós sorrendet állít elő. Nem arról van szó, hogy a modell eleve intelligensebb. Hanem arról, hogy hozzáfér a korábban eltávolított információkhoz.
Az általunk megcélzott változás egyszerűen leírható: ahelyett, hogy előre meghatározott műveletek közötti választást kérnénk a modelltől, alacsonyabb szintű végrehajtási felületet adunk neki, amelyet nem absztrakciókkal, hanem futásidejű szabályzattal korlátozunk.
Ez a tervezési döntés egy szélesebb iparági átalakulásból ered, amely egyre inkább az alacsonyabb szintű primitív eszközöknek kedvez. Ezek kiaknázzák az ügynök eredendő képességét a futásidejű korrekcióra és a kiváló minőségű kód előállítására, szemben a stabil, de mereven kódolt, speciális eszközökkel, amelyek megfosztják a modellt a különböző környezetekhez való alkalmazkodás lehetőségétől.
Gondoljunk arra, hogy a Claude Code sok fejlesztő eszköztárának elsődleges elemévé vált, valamint arra, hogy az iparág egyre inkább a terminálalapú ügynökök felé fordul. A Claude Code legnagyobb előnye nem maga a modell, hanem az alacsonyabb szintű végrehajtási környezet. Ha kevesebb, modulárisabb és alacsonyabb szintű eszközt adunk a modellnek – vagyis a terminált –, az jobb eszközhívási teljesítményt eredményez. Ennek fő oka, hogy az ügynök képes érvelni és egyedi szkripteket létrehozni az adott feladathoz, ahelyett, hogy a kontextusablakot terhelő általános eszközökkel próbálkozna.
A böngészőautomatizálás gyakorlatában ez azt jelenti, hogy a modell közvetlenül megvizsgálhatja az oldal aktuális állapotát, bejárhatja a kereteket, és az adott felülethez egyedi interakciós kódot készíthet, ahelyett, hogy mindent előre elkészített műveletek rögzített készletére képezne le.
A modell kevésbé viselkedik választóként, inkább futásidejű programalkotóként. Megvizsgálja az aktuális állapotot, értelmezi a felületet, és előállítja az adott helyzethez szükséges interakciós logikát. Többlépéses folyamatokat állíthat össze, alkalmazkodhat a szokatlan munkamenetekhez, és a folytatás előtt ellenőrizheti az eredményeket. Ha egy művelet sikertelen, a modell látja az alapul szolgáló hibát, és önállóan korrigál. Ez hatékonyabb és kockázatosabb is, ugyanakkor sokkal jobban megfelel a probléma valódi természetének.
Fontos, hogy az absztrakciós réteg eltávolításától a rendszer nem válik kevésbé fegyelmezetté. Csupán máshová kerül a fegyelem.
A korábban a burkolók tervezéséhez és a szélsőséges esetek kezeléséhez tartozó munka három helyre kerül át: az utasításba, amely az operatív betanítás egyik formájává válik; a futtatókörnyezetbe, amely olyan határokat érvényesít, mint a navigáció hatóköre, az érzékeny műveletek és az újrapróbálkozási viselkedés; valamint az értékelési rétegbe, amely nemcsak a feladat sikerét, hanem a köztes lépések helyességét is vizsgálja. Kevesebb törékeny absztrakció. Erősebb környező rendszerek.
E változás egyik eredménye, hogy a termékkód gyakran egyszerűbbé válik, miközben a teljes rendszer képességei bővülnek. Az interakciós minták újrafelhasználható burkolókba kódolása helyett az ügynök futásidőben állítja elő a viselkedést. A speciális eszközök és a szélsőséges eseteket kezelő logika egyre bővülő készlete helyett néhány hatékony primitívet és egy korlátozott végrehajtási környezetet tartunk fenn.
Ez azt is megváltoztatja, hogyan általánosít a rendszer. A burkolókra épülő ügynök jól általánosít azokra a feladatokra, amelyek hasonlítanak a már elkészített burkolókhoz. A korlátozott futtatókörnyezetben működő ügynök azokra a feladatokra is képes általánosítani, amelyek közös végrehajtási alapra épülnek, még ha a látható felületük eltérő is.
Egy keresési űrlap, egy foglalási folyamat és egy beállítási oldal használata például a felhasználói felület szintjén teljesen eltérőnek tűnhet. A háttérben azonban közös mintákat követnek: állapotolvasást, eseményindítást, eredmény-ellenőrzést és aszinkron frissítések kezelését. Az ezen a szinten működő rendszer természetesebben alkalmazkodik a különböző feladatokhoz.
Az újrafelhasználható összetevő nem a műveletek listája, hanem a modell azon képessége, hogy megvizsgálja az állapotot, biztonságosan cselekedjen és ellenőrizze az eredményeket.
E munka legfontosabb tanulsága, hogy a megbízhatóságot nem az teremti meg, ha több segédfüggvényt adunk a modellnek. Gyakran éppen az segít, ha kevesebb, de hatékonyabb primitívet adunk neki, és ezeket megfelelően korlátozzuk. A túlzott segítségnyújtás kódba égeti a feladat végrehajtásának módjára vonatkozó feltételezéseket. A korlátozások biztonságos működési határokat szabnak, és lehetővé teszik, hogy a modell jobb helyi megoldásokat találjon.
A nagyobb képességű végrehajtási felülethez szigorúbb biztonsági modell is szükséges. Amint az ügynök már nem csupán néhány előre meghatározott műveletet végezhet, gyakorlatilag közvetlenül valódi szoftvereken dolgozik. Ez azonnal megváltoztatja a kockázati profilt.
A tervezés során négy szempontot kell figyelembe venni:
Adatkitettség. Ha az ügynök valódi felületeket használ, gyakran találkozik bizalmas adatokkal. Ez fegyelmezett maszkolást és hozzáférés-szabályozást igényel. Az adatokat csak akkor szabad felfedni, ha a végrehajtáshoz szükségesek, a naplókat és nyomkövetési adatokat pedig körültekintően kell kezelni, nehogy a megfigyelhetőségi réteg váljon a rendszer legérzékenyebb részévé.
Végrehajtási hatókör. Egy nagy képességű ügynök nem működhet tetszőleges módon. A gyakorlatban korlátozni kell, hogy hová navigálhat, mely tartományokhoz férhet hozzá, és mely rendszerekkel léphet kapcsolatba. Ezeket a korlátokat futásidőben kell érvényesíteni, nem pedig az utasításokban szereplő konvenciókra bízni.
A környezet megbízhatósága. A modern felületek félrevezető vagy kifejezetten ellenséges utasításokat, tartalmakat és folyamatokat is tartalmazhatnak. Az oldalak tartalmán keresztüli utasítás injekció valós támadási felület. Egyértelmű utasításhierarchiára, ellenőrzésekre és leállítási feltételekre van szükség, hogy az ügynök ne kövessen nem kívánt útmutatást.
Az autonómia spektruma. Nem minden művelet lehet teljesen önálló. Számos éles környezetben fontos spektrumként kezelni az autonómiát. A rendszer nagymértékben önállóan kutathat és hajthat végre feladatokat, miközben bizonyos művelettípusokhoz továbbra is jóváhagyást kér.
Az alapelv egyszerű: ha nagyobb hatalmat adunk a modellnek, a környező rendszert is meg kell erősítenünk. Szabályzat nélküli autonómia nem áll készen az éles használatra.
Már nem azt kérdeztük: mely böngészőműveleteket érdemes elérhetővé tenni?
Ehelyett azt kérdeztük: hogyan adhatunk teljes műveleti teret a modellnek, és milyen futásidejű szabályzatokkal tarthatjuk ezt mégis biztonságos keretek között?
Ez a szemléletváltás a prioritásokat is átrendezi. A műveleti taxonómiák és a burkolók teljessége kevésbé fontos. A futásidejű szabályzat, a megfigyelhetőség és a lépésszintű értékelés fontosabbá válik. A modell képességei és a rendszertervezés nem helyettesítik egymást. A modellek fejlődésével a rendszer szerepe nem csökken, hanem egyre fontosabbá válik.
A bemutatókon működő böngészőügynökök gyakran azért sikeresek, mert a feladat szűk körű, a környezet pedig együttműködő. Az éles rendszerekhez más kell: korlátozott végrehajtás, műszerezett viselkedés és olyan értékelés, amely meg tudja különböztetni a helyes eredményt a szerencsés véletlentől.
Kevesebb burkolótervezés. Több rendszertervezés.
Bár a böngészőügynökökre összpontosítottunk, mindez egy tágabb szemlélet felé mutat, amely a számítógép-használatot rendszermérnöki szakterületként kezeli.