Hogyan dolgozik az AI-ügynök a bejelentkezett böngésződben: bővítmény, CDP-relé vagy felhős böngésző

A böngészőben végzett üzleti munka jelentős részéhez nincs használható API: a hirdetéskezelő tömeges szerkesztője, a CMS adminfelülete, a beszállítói portál, a bank. Ha egy ügynök ezt a munkát el akarja végezni, olyan böngésző kell neki, amelyben a te fiókoddal vagy bejelentkezve. Háromféleképp lehet ilyet szerezni. Nem egyenértékűek.

1. Felhős böngésző

Fej nélküli (headless) Chrome valaki más szerverén. A Browserbase, a Firecrawl, a Manus és a legtöbb „computer use” demó így fut.

Elérés: minden, ami nyilvános. A fiókjaidba kezdetben nincs bejelentkezve, így vagy beilleszted a hitelesítő adataidat egy szolgáltató gépére, vagy szinkronizálod oda a sütiket, vagy minden alkalommal lefuttatsz egy bejelentkezést 2FA-val. Egyes szolgáltatók az első belépés után megőrzik a munkamenetet.

Szivárog: a munkameneted az ő infrastruktúrájukon él. Bármit mond az adatmegőrzési szabályzatuk, a süti náluk van.

Megáll: ha egy oldal felismeri az adatközponti IP-címet, ha kell az eszközöd (passkey, hardveres 2FA), és minden olyan oldalnál, amelynek feltételei tiltják az automatizálást ismeretlen gépről.

Jó webes adatkinyerésre, kutatásra és párhuzamos munkákra, ahol nincs személyes bejelentkezés. Arra, hogy „válaszolj a három ügyfélszolgálati jegyre a Zendeskemben”, csak akkor jó, ha a Zendesk-munkameneted már az ő szerverükön él.

2. CDP-relé a helyi Chrome-hoz

A Chrome DevTools Protocol az a protokoll/interfész, amelyet a Chrome hibakereséshez biztosít. Indítsd a Chrome-ot --remote-debugging-port kapcsolóval, továbbítsd azt a socketet egy szerverre, és egy távoli ügynök vezérelheti a Chrome-odat. Így működik a Playwright, a Puppeteer és a legtöbb „csatlakozz a böngésződhöz” eszköz.

Egy buktató, amibe sokan belefutnak: a Chrome 136 óta a hibakeresési kapcsolókat figyelmen kívül hagyja az alapértelmezett profilkönyvtárnál, így a --remote-debugging-port a mindennapi Chrome-odon egyáltalán nem nyit portot. Külön --user-data-dir-t kell megadni, az pedig a bejelentkezéseid nélkül indul; a valódi munkameneteidhez vagy át kell oda másolni a profilt, vagy bővítményen keresztül kell menni.

Elérés: csatolt profillal minden, amit te is elérsz. Ugyanazok a sütik, ugyanazok a bővítmények, ugyanaz az eszköz a passkeyekhez.

Szivárog: a relé minden oldalt, minden DOM-ot, minden billentyűleütést lát, amit átküld. Aki a relé végpontját birtokolja, azé a böngésződ. Az URL-ben lévő token a teljes munkamenethez hozzáférést biztosító hitelesítő adat, és úgy kell kezelni.

Megáll: ha a Chrome nem fut. A nyers CDP a hibakeresési porton ráadásul mindent vagy semmit ad: a protokollban nincs „csak ez a lap” vagy „olvas, de nem gépel”, a Network.getAllCookies pedig a teljes sütitárolót visszaadja, így minden szűkítést rá kell építeni.

Erős, és jó válasz, ha az ügynök már a te gépeden fut. Kockázatos, ha az ügynök a szolgáltató gépén fut, és a relé az interneten át megy.

3. Böngészőbővítmény

A Chrome-odban futó kód, azokkal a jogosultságokkal, amelyeket a bővítmény manifestje kér. Az ügynök műveleti kéréseket küld; a bővítmény helyben hajtja végre őket.

Elérés: arra terjed ki, amit a bővítmény kódja átenged az általa kezelhető lapokon, illetve amit a manifest jogosultságai megengednek. A cookies-t kérő bővítmény olvashat sütiket; a debugger-t kérő ugyanazt a CDP felületet kapja, mint egy relé, azokra a lapokra szűkítve, amelyekhez csatlakozik. A te nevedben fut, a te eszközödön, így a bejelentkezések és az eszközhöz kötött 2FA elérhetők, ha a bővítmény hozzáférést biztosít hozzájuk.

Szivárog: az oldal tartalma odamegy, ahová a bővítmény küldi. Egy jól megírt bővítmény az éppen használt lap akadálymentességi fáját vagy képernyőképét küldi, nem az egész böngésződet. A hatókör ellenőrizhető: benne van a manifestben és a Chrome jogosultsági párbeszédablakában.

Megáll: ugyanott, ahol a CDP-relé. A Chrome-nak futnia kell, így semmi sem történik, amíg a laptopod le van csukva. A Chrome ezenkívül letiltja a bővítményeket a böngésző belső oldalain és a Web Store-on.

Szűkebb, mint a nyers CDP, ha így építették. Ez a lényege, és a bővítmény szerzőjének döntése, nem az átviteli módé.

Így csinálja a TODO for AI

A Chrome-bővítmény a 2. és a 3. módszer hibridje, és érdemes pontosan megmondani, melyik rész melyik.

• CDP-szerű parancsok, a bővítményen keresztül. Az ügynök a CDP egy részhalmazának parancsaival kommunikál WebSocketen keresztül az API-nkkal, a bővítmény pedig végrehajtja. Két mód van, és a különbség számít: az alapértelmezett shim mód az oldalszintű metódusok fix listáját szolgálja ki (DOM, Accessibility, Input, Runtime.evaluate, képernyőképek) úgy, hogy egy motort injektál az oldalba, debugger-sáv és böngészőszintű domainek nélkül; a debugger mód a parancsokat a Chrome debugger API-jának adja tovább teljes funkcionalitással, a sávval együtt, és ekkor az elérhető felület maga a CDP.
• Csak csatolt lapok. A bővítmény popupjában az „attach” gombra kattintasz egy lapnál. Az ügynök ezeket a lapokat vezérelheti, meg azokat az új lapokat, amelyeket maga nyit. A nem csatolt lapot célzó parancsot mindkét módban elutasítja. A debugger mód és az explicit allow-unattached beállítás együtt ezt feloldja, és ekkor az az ügynök, amely megadja egy lap azonosítóját, bármelyik lapot elérheti. A Chrome belső oldalait és a Web Store-t egyáltalán nem lehet csatolni.
• Sütik: nincs bővítményes cookie API, de ezt ne tekintsd korlátnak. A bővítmény nem kéri a cookies jogosultságot. Shim módban az ügynök azt olvassa, amit az oldalon futó szkript is olvashatna, a document.cookie-t is. Debugger módban a CDP változtatás nélkül megy a Chrome-nak, és a Network domain szélesebb egy lapnál: a Network.getAllCookies az egész böngészőre kiterjedő olvasás. A határ a választott mód és az ügynöknek adott jogosultság, nem a hiányzó cookies jogosultság.
• Az oldal tartalma átmegy a vezetéken. A csatolt lapok snapshotjai, DOM-ja és képernyőképei az API-hoz kerülnek, hogy az ügynök lássa őket. Ez a szivárgási felület. A csatolt lapok listája határt szab neki, kivéve ha debugger módban bekapcsolod az allow-unattached-et, amivel az ügynök azonosító alapján bármelyik lapot megcélozhatja.
• Ügynökszintű jogosultságok és stop gomb. A böngészőhozzáférés ügynökönként beállítható képesség: allow, ask-first vagy block, és új ügynöknél az alapértelmezés az allow. Az ask-first minden eszközhívást jóváhagyáshoz köt, nem minden eredményt, a shell pedig külön eszköz, amely szintén elérhet böngészőt, így ha ez számít, mindkettőt kösd jóváhagyáshoz. Bármelyik futás megállítható menet közben; a lap az akkori állapotában marad.
• Felhős böngésző a többihez. A bejelentkezést nem igénylő kutatás fiókonkénti felhős böngészőben fut, így nem foglalja le a Chrome-odat, a laptopod pedig be lehet csukva.

Amit nem csinál: nem fut, ha a Chrome be van zárva. Nincs oldalankénti tiltólista és nincs csak olvasható mód; a hatókört a csatolt lapok listája, a mód és az ügynökönkénti jogosultság szabályozza. Ha azt akarod, hogy az ügynök soha ne férhessen hozzá egy oldalhoz, ne hagyd csatolva.

Melyik, egy táblázatban

Az utolsó oszlop a mi bővítményünk, nem a bővítmények általában; másik bővítmény másképp is dönthet.

	Felhős böngésző	CDP-relé	TODO for AI bővítmény
A meglévő bejelentkezéseidet használja	Csak miután átadtad őket	Igen, csatolt profillal	Igen
Passkey, hardveres 2FA	Nem	Igen, te vagy az eszköznél	Igen, te vagy az eszköznél
Mi megy át a vezetéken	A teljes munkamenet	Minden a böngészőben	A csatolt lapok tartalma
Hatókör-szabályozás	n/a	Mindent vagy semmit	Csatolt lapok, shim vs debugger mód, ügynökönkénti jogosultság
Fut, amíg a laptop le van csukva	Igen	Nem	Nem, a Chrome-nak futnia kell
Adatközponti IP-címek miatti tiltások	Gyakran	Nem	Nem

Ha a feladathoz te kellesz, használd a bővítményt. Ha senki sem kell hozzá, használd a felhős böngészőt. A relé akkor való, ha az ügynök már a te gépeden fut, és minden láncszemben megbízol. Hogy mit jelent ez egy olyan to-do lista számára, amely tényleg lezárja a tételeket, a to-do posztban olvashatod.