Un Agent într-o singură fereastră este suficient pentru o demonstrație. În producție, zeci de sarcini concurente au nevoie de medii separate; altfel sesiunile se amestecă, filele concurează pentru control, iar erorile sunt greu de diagnosticat.
O singură fereastră de browser este suficientă pentru a demonstra ce poate face un AI Agent. Când îl introduci într-un flux de lucru real, necesarul devine rapid de ordinul zecilor de ferestre care nu trebuie să se influențeze reciproc. Cauza nu este Agentul în sine, ci browserul pe care acesta se bazează.
Ce probleme apar când un singur mediu este partajat
Cea mai evidentă problemă este contaminarea reciprocă a cookie-urilor și a stărilor de autentificare. În același director de date al browserului, două sarcini care se autentifică pe rând în conturi diferite își pot suprascrie sesiunile. Dacă una dintre sarcini golește cache-ul, cealaltă își poate pierde și starea paginii.
Urmează concurența pentru resurse. Într-o singură instanță de browser, filele, focusul, directorul de descărcări și ferestrele pop-up sunt resurse comune. Dacă două sarcini deschid simultan file noi, nu mai este clar care sarcină controlează ce pagină. O casetă de dialog deschisă de una poate bloca scriptul celeilalte. Conflictele de autentificare, suprascrierea datelor și interferențele sunt aproape inevitabile în condiții de concurență.
A treia problemă apare după un eșec. Devine greu de spus dacă logica scriptului a fost greșită sau dacă mediul a fost perturbat de o altă sarcină într-un anumit pas. Când mai multe sarcini folosesc același proces și același jurnal, simptomele pot varia, iar costul depanării crește rapid.
Mai există un risc mai puțin evident: mai multe identități care rulează mult timp în același mediu lasă semnale de corelare. Parametrii dispozitivului, starea stocării și ieșirea de rețea sunt identice, astfel că o platformă le poate interpreta ușor ca operațiuni în serie de pe același dispozitiv. Dacă un cont este considerat anormal, și celelalte pot fi afectate.
Mai multe ferestre nu înseamnă izolare
Prima reacție a multora este să deschidă manual mai multe ferestre. Par separate, dar în realitate folosesc același profil de browser: aceleași cookie-uri, aceeași stocare locală și aceleași informații despre dispozitiv. Ferestrele își pot vedea reciproc starea de autentificare, iar o acțiune într-una o poate afecta pe alta.
Izolarea reală trebuie aplicată directorului de date și parametrilor mediului. Fiecare mediu are nevoie de propriul director de stocare, de propriii parametri ai dispozitivului — rezoluție, limbă, fus orar, fonturi, Canvas, WebGL și altele — și de propria ieșire de rețea. Dacă lipsește oricare dintre cele trei, izolarea este incompletă. Chiar și cu medii separate, o ieșire de rețea comună poate activa în continuare corelarea.
Ce costă izolarea și ce oferă în schimb
Izolarea nu este gratuită. În spatele fiecărui mediu există un proces de browser independent și un director de date separat. Pe măsură ce numărul mediilor crește, memoria și CPU-ul resimt primele presiunea. Dacă zeci de medii rulează pe aceeași mașină, este de preferat să calculezi din timp rezerva de resurse, nu să aștepți o cădere.
Există câteva compromisuri posibile: reciclează mediile folosite rar și pornește-le din nou la nevoie; distribuie sarcinile după încărcare pe mai multe mașini în loc să le concentrezi pe una singură; și stabilește un ciclu de viață clar pentru medii, fără a lăsa sute dintre ele active permanent. Contează și structura sarcinilor. Sarcinile seriale din același cont nu au nevoie de medii separate; împărțirea lor ar irosi resurse.
La celălalt capăt sunt beneficiile. Odată implementată corect izolarea, comportamentul erorilor devine stabil: problema aparține unui anumit mediu și nu mai pare un fenomen inexplicabil. La scară, această predictibilitate valorează mult mai mult decât mica economie de resurse obținută prin partajare.
Trei lucruri care trebuie mutate la nivelul mediului după scalare
Primul este planificarea în lot. Mediile ar trebui solicitate și eliberate ca resurse de calcul, cu creare la cerere, pornire în lot, control al concurenței, reîncercare după eșec și reciclare automată, în loc să fie create și închise unul câte unul în scripturi.
Al doilea este ieșirea de rețea independentă. Fiecare mediu ar trebui legat de propria ieșire, iar regiunea acesteia să corespundă parametrilor geografici ai mediului. Acest aspect este ușor de omis, dar este o condiție prealabilă pentru o izolare coerentă.
Al treilea este o stare care poate fi interogată. În orice moment ar trebui să poți vedea ce medii rulează, care sunt libere și care sunt anormale. Agenții funcționează fără supraveghere; dacă starea nu poate fi verificată, depanarea devine ghicit.
Aceste trei funcții sunt incomod de implementat în scripturi. Ele necesită stocare, configurare și planificare la nivel de mediu. Unele instrumente de administrare a mai multor medii funcționează exact la acest nivel. PurpleMark este unul dintre ele și transformă mediile de browser în resurse care pot fi izolate, planificate în lot și accesate prin interfețe.
Când nu sunt necesare mai multe medii
Dacă un Agent folosește un singur cont și rulează rar, un browser obișnuit este suficient, iar izolarea suplimentară doar crește efortul de întreținere. Dar dacă apare oricare dintre următoarele situații, nivelul de mediu ar trebui separat: sarcinile trebuie să ruleze în paralel, mai multe identități trebuie să acceseze aceeași platformă, starea de autentificare trebuie păstrată mult timp sau nivelul de concurență va continua să crească.
Toate aceste cazuri au ceva în comun: problema nu este dacă Agentul este suficient de inteligent, ci dacă mediul pe care rulează este suficient de curat și separat.
Limite
Indiferent de soluția aleasă, limitele regulilor rămân aceleași: respectă termenii de utilizare și regulile robots ale fiecărei platforme, nu utiliza informații de identitate false, nu ocoli măsuri tehnice de protecție, controlează frecvența solicitărilor și nu afecta funcționarea normală a serviciilor altor părți.
