A böngésző automatizálás, a Playwright és a build kontra buy

Mi a Playwright

A Playwright egy nyílt forrású böngésző-automatizálási eszköz, amelyet a Microsoft fejleszt. A lényege, hogy egy igazi böngészőt vezérel programozottan, nem egy leegyszerűsített szimulációt. Ugyanaz a három motor áll mögötte, amit a valódi felhasználók is használnak, a Chromium, a Firefox és a WebKit. A Playwright ezeket a böngészőket irányítja kódból. Betölt egy oldalt, rákattint egy gombra, kitölt egy űrlapot, kiolvassa az oldal tartalmát, és képernyőképet készít arról, amit lát. Minden művelet, amit egy ember egy böngészőablakban elvégezne, leírható a Playwright-tal is. Fontos különbség, hogy ez nem egy külső, felszíni kattintgatás, hanem a böngésző belső állapotára épülő vezérlés, amely megvárja, amíg egy elem tényleg megjelenik, mielőtt cselekedne. Ez teszi elég stabillá ahhoz, hogy valós, éles folyamatokban is használható legyen, ne csak bemutatókban.

Ez a réteg, amin keresztül az ügynök hat

Az eddigi leckékben a stack olyan rétegeivel foglalkoztunk, amelyek gondolkodnak, emlékeznek és tudást hívnak elő. A Playwright ehhez képest más szerepet tölt be. Ez az a réteg, amin keresztül egy cselekvő AI ügynök ténylegesen hat a külvilágra. Amit egy ember egy böngészőben megtenne, azt az ügynök a Playwright-on keresztül teszi meg. Beír egy keresést, végignéz egy találati listát, megnyit egy oldalt, kimásol belőle egy adatot, majd elküld egy űrlapot. A modell eldönti, mi legyen a következő lépés, a Playwright pedig végrehajtja azt a böngészőben. Enélkül a réteg nélkül az ügynök csak beszélni tudna a világról, cselekedni nem.

Miért van erre szükség

Kézenfekvő lenne azt gondolni, hogy mindenhez van API. A valóságban sok feladatnak nincs. Rengeteg rendszernek csak weboldala van, hivatalos programozói felület nélkül, vagy a funkciók egy része csak a böngészőből érhető el. Ilyenkor a böngésző-automatizálás az egyetlen mód arra, hogy az ügynök ott is dolgozni tudjon. A Playwright így azoknál a feladatoknál nélkülözhetetlen, ahol nincs tiszta gépi belépő, csak egy weboldal, amit egyébként egy ember kezelne. Ez teszi az ügynököt igazán általánossá, mert nem korlátozódik azokra a szolgáltatásokra, amelyek külön API-t kínálnak. Ahol az ember elboldogul egy böngészővel, ott elvben az ügynök is. Gondoljunk egy régi belső rendszerre, amelyhez soha nem készült integráció, csak egy webes felület. Egy ilyen felületről adatot kiolvasni vagy oda adatot bevinni programozottan sokáig csak kézi munkával ment. A böngésző-automatizálás pontosan ezt a szakadékot hidalja át, és a modell döntési képességét összeköti azzal, hogy a lépéseket egy valódi felületen végre is lehessen hajtani.

Mire kell figyelni

A böngésző-automatizálásnak két visszatérő buktatója van. Az első a megbízhatóság. Egy weboldal bármikor változhat. Átalakul az elrendezés, elmozdul egy gomb, átnevezik a mezőket, és ami tegnap még hibátlanul futott, ma elakad. Egy jól megírt automatizálás ezért nem a pontos képernyőhelyzetre, hanem stabilabb kapaszkodókra épít, és számol azzal, hogy időnként újra kell igazítani. Ez nem hiba a rendszerben, hanem a webes környezet természetes velejárója, amivel érdemes előre tervezni.

A második buktató a visszafordíthatatlan műveletek kezelése. Egy böngészőben az ügynök nemcsak olvasni tud, hanem véglegesíteni is. Elküldhet egy űrlapot, leadhat egy megrendelést, vagy törölhet valamit, és ezek a lépések nem vonhatók vissza egy kattintással. A felelős megközelítés az, hogy a kockázatos, nem visszafordítható műveletek elé emberi jóváhagyás kerül. Az ügynök előkészíti a lépést, de a végső megerősítést ember adja meg. Ez visszautal arra a felelős AI szemléletre, amit egy éles rendszernél soha nem érdemes kihagyni.

Vissza az egész stackhez

Ezzel a réteggel körbeértünk. A kurzus során végigvettük, mi fut valójában egy modern AI alkalmazás alatt. Volt szó az API rétegről és a FastAPI-ról, a vektoradatbázisról, ahol a PostgreSQL és a pgvector dolgozik, a RAG csővezetékről és a LlamaIndex-ről, az orkesztrációról és a LangChain-ről, az ügynök memóriájáról és a Redis-ről, az inferencia motorról és a vLLM-ről, és most a böngésző automatizálásról és a Playwright-ról. Ezeknek közös jellemzőjük, hogy mind nyílt forrásúak, és bárki ingyen eléri őket. Nagyon sok AI-native termék pontosan ezekre az összetevőkre épül a felszín alatt.

Miért fontos ezt tudni vezetőként

Ennek egy nagyon gyakorlati következménye van. Ha tudjuk, mi van a felszín alatt, akkor jobban látjuk, mennyit ér valójában egy termék, mielőtt túlfizetnénk érte. Amikor egy szállító egy AI megoldásért kér egy árat, érdemes tudni, hogy a megoldás alatt gyakran ugyanezek a nyílt forrású összetevők dolgoznak. Ez nem azt jelenti, hogy minden terméket magunknak kellene összeraknunk. Azt jelenti, hogy tájékozott vevőként tudunk dönteni, és a beszélgetés nem az ismeretlenről, hanem a tényleges hozzáadott értékről szól. A stack ismerete tárgyalási pozíció, nem öncélú technikai tudás.

A build kontra buy döntés

A saját építés kontra kész termék vásárlása régi vezetői döntés, de az AI-nál különösen élesen jelenik meg, mert az alapelemek szabadon elérhetők. A kérdés ritkán az, hogy melyik modellt válasszuk, sokkal inkább az, hogy mit veszünk készen és mit építünk magunknak. Öt szempont segít eldönteni, melyik irányba induljunk.

Egy fiktív céges példa

Vegyünk egy fiktív példát. Egy közepes méretű magyar biztosítási cég szeretné az ügyfélszolgálatát AI-val támogatni. Az első kérdés nem az, hogy melyik modellt válasszák, hanem az, hogy építsenek vagy vegyenek. Ha a cél egy általános chatbot a honlapra, amely a leggyakoribb kérdéseket kezeli, akkor egy kész termék valószínűleg gyorsabb és olcsóbb, és semmi okuk nincs magukat építéssel terhelni. Ha viszont a rendszernek mélyen hozzá kell férnie a belső, érzékeny ügyféladatokhoz, össze kell kötni a saját szerződéskezelővel, és éppen ez a képesség a cég valódi megkülönböztető ereje, akkor a saját stack, ugyanezekből a nyílt forrású elemekből felépítve, jobb döntés lehet. A kettő között nincs egyetlen helyes válasz, csak a cég helyzetéhez illő döntés, amit sokkal magabiztosabban lehet meghozni, ha tudjuk, mi van a felszín alatt. Az is gyakori, hogy a helyes válasz vegyes, a standard részt készen veszik, a megkülönböztető, érzékeny részt pedig saját kézben építik. A saját építésnél érdemes arra is gondolni, hogy a rendszer nem a bevezetéskor, hanem évekig kerül igazi pénzbe, mert karbantartás, frissítés és üzemeltetés jár vele. Ezt a rejtett költséget a build kontra buy döntésnél a kezdeti árajánlat mellett mindig érdemes a mérlegbe tenni.

A zárás fő üzenete

Ha egyetlen gondolatot kell hazavinni ebből a kurzusból, akkor ez az. A modell a legkisebb munka. A modellt lecserélni néhány sor, a nehézség a körülötte lévő stackben van, abban, ahogyan az adat beérkezik, tárolódik és előkerül, ahogyan az ügynök emlékszik, dönt, majd a Playwright-on keresztül cselekszik. Aki érti ezt a stacket, jobb beszerzési és fejlesztési döntéseket hoz. Tudja, mit érdemes megvenni, mit érdemes megépíteni, és mennyit ér valójában az, amit kínálnak neki. Nem a legmélyebb technikai tudás a cél, hanem az a tisztánlátás, amivel egy vezető magabiztosan tud dönteni az AI beruházásairól. Ezzel a kurzus végére értünk, a záróteszt tíz kérdésével pedig ellenőrizheted, mennyit vittél magaddal.