Browser és computer use agentek: mire jók valójában?

Két különböző dolog, egy néven

Amikor „böngészőagentről" beszélünk, valójában két, egymástól nagyon eltérő megoldásról van szó:

• Pixelalapú: az agent képernyőképet kap, és koordinátákra kattint. Úgy dolgozik, ahogy egy ember — látja a felületet, és megnyomja a gombot.
• Kódalapú: az agent nem kattint, hanem automatizáló kódot ír (böngészővezérlő szkriptet, HTTP-hívásokat), és azt futtatja.

Sokáig úgy tűnt, hogy az első a „rendes" computer use , a második pedig egy kerülőút. Egy 2026 májusi kutatási eredmény ezt megfordította. Ugyanazon a 300 feladatos, 136 valódi weboldalt használó teszten a kódalapú megoldás 86,7%-ot ért el ugyanazzal a modellel, míg a képernyőkép-alapú alapvonal „minden nehézségi kategóriában lényegesen gyengébben" teljesített.

A hosszabb, több weboldalon átívelő feladatokon a különbség még látványosabb: a kódalapú megoldás 60,1%-ot ért el, miközben ugyanannak a modellnek a puszta alapvonala 33,5% volt. Ez majdnem 80%-os relatív javulás pusztán attól, hogy másképp vezéreljük a böngészőt — a modell ugyanaz maradt.

A kutatók magyarázata jól megfogható: a kódalapú keret „teret ad az agentnek, hogy megválassza a saját útját a feladattérben". A kattintgatás lineáris: egy lépés, egy kép, egy döntés. A kód elágazhat, ciklusba szervezhet, és ötven sorban elintézheti azt, ami kattintásban ötven lépés.

A gyakorlati következtetés, amit érdemes megjegyezni: ha nincs API , az még nem jelenti, hogy pixelagent kell. A sorrend: API → kódalapú böngészővezérlés → és csak legvégül képernyőkép-kattintgatás.

Mit tudnak ma, mérve?

A számítógép-használat mércéje egy 369 feladatos, valódi operációs rendszereken futó teszt. Az idővonala az elmúlt két év legmeredekebb görbéje:

(Önbevallott eredmények nyilvános ranglistán; harmadik fél nem hitelesítette őket. A benchmarkok olvasásáról külön írás szól: hogyan olvass AI-benchmarkot — érdemes elolvasni, mielőtt bármelyik számot komolyan veszed.)

Két dolgot fontos látni e mögött. Az egyik, hogy a legjobb eredmények egy része nem modell, hanem agent-keretrendszer: több próbálkozás, szavazás a kimenetek között, specializált vezérlés. A másik, hogy ezek a számok maximális lépéskerettel születnek.

A lépéskeret csapdája

Ez a cikk legfontosabb táblázata, mert közvetlenül a pénztárcáról szól. Ugyanaz a modell, ugyanaz a feladatsor, csak a megengedett lépésszám változik:

A 15-ről 50-re emelés +12,7 pontot hoz. Az 50-ről 100-ra emelés mínusz 2,5 pontot. Nem elírás: a több lépés egy ponton túl nem segít, csak fogyaszt — az agent hosszabban téved el, több zajt halmoz a kontextusába, és nehezebben talál vissza.

Ugyanebbe az irányba mutat egy másik mérés is, ami szerint az első ötven lépés adja a pontosság 82%-át, a következő ötven pedig mindössze 3–4 további pontot — ott tehát nem romlott az eredmény, csak gyakorlatilag megállt a javulás.

Gyakorlati szabály ebből: állíts lépéskorlátot, és ne a legnagyobbat. Ötven körül van az az érték, ahol a legtöbb feladatnál a görbe ellaposodik.

Élő weben: a számok, és a fenntartás

A valódi, élő weboldalakon mért eredmények szintén látványosan javultak:

De ezt a táblázatot óvatosan kell olvasni. A 2026-os, 90% fölötti eredményeket külön cégek küldték be, és nem ugyanaz a szervezet validálta őket, mint a korábbiakat. Nem ugyanaz a mérési rezsim — a sorok tehát egymással csak korlátozottan összevethetők. A trend valós; a legfelső szám nem ígéret.

A költség: négyzetesen nő

Itt van az a rész, amit a bemutatókban soha nem mondanak el.

A computer use eszközkészlet önmagában nagyjából 4 500 bemeneti tokent ad minden egyes kéréshez — ez a puszta belépő, mielőtt bármi történne. Ehhez jön képernyőképenként 1 000–1 800 token. És mivel az agent minden lépésnél újraküldi a teljes eddigi beszélgetést, a kontextus lépésről lépésre nő.

[Saját számítás] Egy élvonalbeli modell mai árán (5 dollár millió bemeneti, 25 dollár millió kimeneti tokenért), gyorsítótárazás nélkül, lépésenként egy képernyőképpel:

A 15-ről 100 lépésre ugrás 6,7-szeres lépésszám — és 34-szeres költség. Ez a görbe alakja, nem egy konkrét szolgáltató árazása.

A prompt caching ezt nagyjából tizedére viszi, és érdemes is használni — de a görbe alakját nem változtatja meg. A négyzetes növekedés a rendszer tulajdonsága: minden lépésben az összes korábbi képernyőkép ott van a kontextusban.

Két olcsó fogás, ami sokat számít: kisebb felbontás (asztali feladatokra 1024×768 vagy 1280×720 az ajánlott; 1920×1080 fölé ne menj), és kevesebb kép — ha egy lépéshez nem kell friss képernyőkép, ne kérj. Az árazás logikájáról általában az AI-árazás című írás szól bővebben.

És mennyibe kerül egy pontosságpont?

Van egy ranglista, ami futásonként közli a tokent, a dollárt és az időt is — ez ritka, és nagyon tanulságos. Két megállapítás jön belőle, mindkettő pénzben mérhető:

1. A legmagasabb gondolkodási szint nem éri meg. Ugyanaz a modell „magas" és „maximális" beállításon 57,9% és 58,2% — a különbség a hibahatáron belül van, miközben a maximális beállítás 43%-kal drágább és 32%-kal lassabb.

2. A rossz modellválasztás nem néhány százalék, hanem nagyságrend. A mezőny egyik modellje futásonként 29 dollárt költött 12,4%-os eredményért; a legjobb ár-érték arányú beállítás 7 dollárt 57,9%-ért. Pontonként ez tizenkilencszeres különbség.

A tanulság nem az, hogy melyik modellt válaszd — az havonta változik —, hanem hogy ezt a két számot méred-e egyáltalán: dollár per futás és dollár per sikeres futás.

Az idő, amit senki nem kalkulál

Ez nem hiba, hanem a működés természete. A gyártó saját dokumentációja is ezt írja: a mai computer use késleltetés „túl lassú lehet" az emberi interakcióhoz képest, ezért olyan felhasználásra érdemes, ahol a sebesség nem kritikus — háttérben futó információgyűjtésre, automatizált szoftvertesztelésre, megbízható környezetben.

Ez a mondat a legjobb iránytű a technológiához. Ha valaki élő ügyfél előtt akar computer use agentet futtatni, rossz feladatot választott.

Hol bukik el?

Itt van a cikk legmeglepőbb adata. A 369 feladatos mérés karbantartói nyilvánosságra hozták a beérkezett hibabejelentéseket: 360 bejelentés, 217 különböző feladatra — vagyis a feladatok több mint felére érkezett panasz.

[Saját számítás] A bejelentések kategorizálva:

(A 360 bejelentésből 153 besorolatlan maradt, és egy bejelentés több kategóriába is eshet — ezért nem adja ki a táblázat a 360-at. A lista konstrukció szerint a mérés hibái felé torzít: azt jelentik be, ami hibásnak látszik. A tanulság ettől még áll.)

A legtanulságosabb konkrét eset a listából: az agent helyesen elvégezte a feladatot, de a kiértékelő egy beállítófájlt nézett, amit a program még nem írt ki a lemezre — így ugyanaz a futás hol sikeresnek, hol sikertelennek számított.

És itt van az igazi üzleti tanulság. Ha a mérésen dolgozó, célra épített kiértékelők 148 esetben tévedtek a sikerről, akkor a te folyamatodban is a legnehezebb kérdés nem az, hogy az agent meg tudja-e csinálni — hanem hogy meg tudod-e mondani, megcsinálta-e. Ezért nem lehet felügyelet nélkül futtatni; erről szól részletesen az ember a folyamatban című írás.

A többi kategória pedig pontosan azt írja le, amitől egy produkciós böngészőagent instabil: a weboldal változik, a bejelentkezés lejár, a botvédelem beugrik, és a felugró ablak elrontja a kattintást. Ezek nem modellhibák, és nem is javulnak modellváltással.

A biztonsági rész, amit nem lehet kihagyni

A böngészőagent definíció szerint nem megbízható tartalmat olvas, és közben hozzáfér a bejelentkezett fiókjaidhoz. Ez a legrosszabb kombináció, ami létezik.

Mért számok egy gyártó saját, 123 teszteseten és 29 támadási forgatókönyvön végzett vizsgálatából:

A böngésző-specifikus támadások közt: a DOM-ba rejtett, láthatatlan űrlapmezők, az URL szövegébe és a fülcímbe rejtett utasítások.

És egy dokumentált, valós eset 2025 nyaráról. A rosszindulatú utasítás egy közösségi oldal kommentjében volt, spoiler-jelölés mögé rejtve — fehér szöveg fehér háttéren, HTML-megjegyzés, láthatatlan elemek. Amikor a felhasználó rákattintott az „összefoglalom" gombra, az asszisztens kiolvasta a fiókjához tartozó e-mail-címet, bejelentkezést kísérelt egy megtévesztően hasonló domainnévvel, kiolvasta az egyszeri belépőkódot a levelezésből, és visszaírta a támadó kommentjébe. A javítás két hullámban készült el, és az első nem volt teljes.

A kutatók konklúziója idézhető: a hagyományos webbiztonsági feltevések nem állnak az agentes AI-ra.

Ezt maguk a gyártók is elismerik. Az egyik dokumentációja szerint „bizonyos körülmények között a modell követi a tartalomban talált utasításokat akkor is, ha azok ellentmondanak a tiédnek". A másik fejlesztői útmutatója pedig kimondja a helyes alapállást: a képernyő tartalmát nem megbízhatóként kell kezelni — a weboldalon, dokumentumban vagy eszközválaszban lévő szöveg nem ad jogosultságot.

Van egy nyugtalanító mellékszál is: a legismertebb nyilvános, akadémiai prompt injection mérőeszköz eredményoldalán a legfrissebb bejegyzés 2025 februári. Vagyis a nyilvános, független biztonsági mérés lemaradt a modellektől — miközben a képességek másfél év alatt megháromszorozódtak.

A védekezés alapelveiről a legkevesebb jogot kapó agent című írás szól, a támadás mechanikájáról pedig a prompt injection alapjai című bevezető.

A jogi rész: új, és fontos

2026 szeptemberében vált véglegessé egy amerikai döntés, ami az első komoly precedens arról, ki felel egy böngészőagent cselekedeteiért. Egy nagy kereskedelmi platform perelte be egy AI-böngésző fejlesztőjét, mert az agentje a felhasználó nevében belépett a fiókjába és vásárolt.

A fellebbviteli bíróság elutasította a keresetet, és az indoklás néhány mondata megjegyzendő:

„Bármilyen fejlett is ma az asszisztens, eszköz, nem személy a törvény alkalmazásában."

„A felhasználó az, aki hozzáfér a rendszerhez, az asszisztens segítségével."

A bíróság szándékosan szűken fogalmazott: kijelentette, hogy nem hoz létre új jogi rendszert az agentes AI-ra, és nem dönt arról, hogy más típusú igényeknél (például kártérítésnél) mi lenne a helyzet.

Két gyakorlati következménye van, és mindkettő fontos, ha vállalkozásként gondolkodsz erről:

1. A felhasználási feltételek továbbra is élnek. A bíróság külön lábjegyzetben rögzítette: a döntés nem érinti a platform jogát, hogy a saját szerződési feltételeivel szabályozza a hozzáférést. Csak azt mondta ki, hogy a számítógépes bűncselekményekről szóló törvényekre ez nem alapozható.

2. A vita magva nem az volt, hogy az agent belépett — hanem hogy elrejtette, hogy agent. A technikai kérdés a perben egy azonosító karakterlánc volt, ami jelezte volna, hogy a felhasználó AI-agentet aktivált, és amivel a platform blokkolhatta volna. Ennek elhagyása volt a vita középpontja.

Ha tehát üzletileg építesz böngészőagentre, a kockázat nem elsősorban büntetőjogi, hanem szerződéses: a fiókod felfüggeszthető, ha a szolgáltató feltételei tiltják az automatizált hozzáférést. Európában ehhez jön az AI Act átláthatósági követelményrendszere, aminek első megfelelési határideje 2026. december 2.

Mikor érdemes?

IGEN, HA
- nincs API, és nem is lesz;
- a feladat háttérben futhat, nem ember vár rá;
- a lépésszám 50 alatt tartható;
- a hiba olcsó és visszafordítható;
- van saját fiók, amit korlátozhatsz.

NEM, HA
- van API - akkor azt használd;
- ügyfél vagy kolléga vár a válaszra;
- pénzügyi művelet vagy visszavonhatatlan lépés;
- a szolgáltató feltételei tiltják az automatizálást;
- nem tudod megmondani a futásról, hogy sikerült-e.

És egy sorrend, ami a mérésekből következik, nem véleményből:

1. API, ha van. Olcsóbb, gyorsabb, megbízhatóbb.
2. Ha nincs: KÓD, ami vezérli a böngészőt.
   Mérés szerint pontosabb ÉS olcsóbb.
3. Csak legvégül: képernyőkép és kattintás.
4. Mindháromnál: lépéskorlát, külön fiók,
   szűk jogosultság, naplózás.

Tipikus félreértések

• „Ha nincs API, akkor pixelagent kell." Nem. Előbb jön a kódalapú böngészővezérlés, ami a mérés szerint egyszerre pontosabb és olcsóbb.
• „Több lépést engedek neki, és megoldja." Ötven lépés fölött a mérésben romlott az eredmény. A hosszabb keret nem kitartás, hanem több lehetőség eltévedni.
• „A 85%-os benchmark azt jelenti, hogy tízből nyolcat megcsinál nekem." Nem. Az a szám gondosan definiált feladatokon, maximális kerettel, ismételt próbálkozással született. A te folyamatod nem ilyen.
• „A költség a futásidővel arányos." A tokenköltség a lépésszám négyzetével nő. Ezért lesz egy „csak még pár lépés" tipikusan sokszoros számla.
• „A saját gépemen fut, tehát biztonságos." Pont fordítva: ott vannak a bejelentkezett fiókjaid. A böngészőagent kockázata nem a futtatás helyéből jön, hanem abból, hogy nem megbízható tartalmat olvas jogosultsággal a kezében.
• „Bírósági döntés kimondta, hogy szabad." Egy amerikai döntés kimondta, hogy erre bizonyos büntetőjogi tényállások nem alkalmazhatók. A szolgáltatók szerződési feltételei érintetlenül maradtak.

Amit érdemes elvinni

A computer use az elmúlt két évben 12%-ról 86%-ra jutott, és 2025 decemberében átlépte az emberi alapvonalat. A képesség tehát valós — a gazdaságosság a szűk keresztmetszet.

Három szám, amit érdemes fejben tartani: a lépésszám négyzetesen drágít, ötven lépés fölött romlik az eredmény, és a legdrágább beállítás nem a legjobb — egy mérésben a maximális gondolkodási szint 43%-kal többe került a hibahatáron belüli különbségért.

És a legfontosabb: a böngészőagent akkor jó választás, ha nincs API, a feladat háttérben futhat, és a hiba olcsó. Ha bármelyik nem teljesül, valószínűleg nem ezt az eszközt keresed. Arról, hogy mi a különbség egy eszközhívó agent és egy kattintgató agent között, a tool use és a function calling című írás szól, a szabványosított eszközkapcsolatról pedig az MCP témájú bevezető.