Ce este utilizarea computerului și de ce contează? Utilizarea computerului este o idee simplă, cu implicații ample: în loc să le cerem modelelor să răspundă la întrebări, le cerem să opereze software — să navigheze pe site-uri, să completeze formulare, să parcurgă fluxuri prin clicuri și să ducă autonom sarcinile la bun sfârșit.
Astfel devine posibilă o categorie amplă de sarcini din lumea reală, fragmentate în prezent între mai multe interfețe: rezervări complete, finalizarea comenzilor online, planificarea călătoriilor în mai mulți pași și fluxuri administrative fără un echivalent API adecvat. Aceste probleme nu sunt noi. Noutatea este că acum pot fi rezolvate cu modele de uz general.
Sisteme recente de la Anthropic și OpenAI au demonstrat agenți care nu doar acționează, ci raționează asupra stării, își revin după erori și construiesc din mers soluții specifice sarcinii. Astfel, browserul devine un mediu general de execuție pentru agenți, dar apare imediat o întrebare de proiectare: cât de mult din acest mediu ar trebui să expunem modelului?
Primele sisteme au răspuns înglobând browserul într-un set fix de acțiuni sigure și predefinite. După cum vom argumenta în acest articol, abordarea își atinge limitele.
La crearea agenților pentru browser apare un instinct firesc: să nu avem prea multă încredere în model.
Așa că înglobăm browserul într-un adaptor. Expunem instrumente predefinite precum click, type, scroll, select și read_text. Simplificăm modelul obiectelor documentului (DOM). Restrângem spațiul acțiunilor. Încercăm să facem comportamentul ușor de înțeles și de controlat prin abstracții proiectate de noi.
Este un punct de plecare rezonabil. Dar devine tot mai mult și arhitectura greșită pe termen lung.
Pe măsură ce modelele de vârf se îmbunătățesc, limitarea nu mai constă doar în lipsa instrumentelor. Problema este că obligăm modelul să opereze prin abstracții care elimină prea mult din sistemul subiacent. Comprimăm un mediu dezordonat și dinamic într-o interfață fixă de acțiuni, apoi îi cerem modelului să funcționeze bine în ciuda acestei pierderi de informații.
Acest compromis devine tot mai puțin atractiv.
Schimbarea pe care o explorăm este simplu de descris, dar are consecințe importante. În loc să tratăm agentul drept un selector de acțiuni predefinite, îl tratăm ca pe un sintetizator de programe care operează într-un mediu de execuție limitat.
Modelele au devenit foarte performante și nu mai au nevoie de barierele abstracte create de voi — au nevoie de întregul spațiu al acțiunilor pentru a proiecta, executa și perfecționa sarcina până când își ating obiectivul.
Acest articol analizează trecerea de la automatizarea browserului bazată masiv pe abstracții la utilizarea controlată a computerului și schimbările pe care le implică această abordare de proiectare.
Problema nu este că interfețele cu acțiuni fixe ar fi greșite conceptual. Problema este că webul nu se conformează acestora.
Interfețele moderne sunt construite cu React, Vue și Angular, folosind actualizări asincrone ale stării, sisteme de evenimente sintetice și widgeturi terțe încorporate în iframe-uri cross-origin, fiecare cu propriul ciclu de viață. Un adaptor care spune „introdu text în acest câmp” funcționează corect numai dacă pagina împărtășește definiția voastră pentru introducerea textului. Multe pagini nu o fac. Setarea directă a unei valori ocolește adesea complet mecanismul cadrului software de detectare a modificărilor. Câmpul pare completat. Validarea nu este declanșată niciodată. Formularul rămâne nefuncțional.
Puteți remedia punctual problema. Puteți adăuga cazuri speciale pentru câmpurile React, puteți declanșa evenimente blur după focus și puteți aștepta inactivitatea rețelei înainte de a citi starea. Fiecare corecție este validă local. Împreună, ele formează un sistem tot mai greu de întreținut și tot mai specific site-urilor pe care le-ați întâlnit deja.
Problema mai profundă este că integrați în stratul de abstracție presupuneri despre cum ar trebui să funcționeze interacțiunile, apoi descoperiți că webul funcționează după alte presupuneri.
Să luăm un formular de plată Stripe sau Adyen încorporat într-un iframe cross-origin. Adaptorul nu îl poate accesa direct, deoarece se află într-o origine separată. Instrumentul read_text nu îi poate observa starea internă. Instrumentul type nu îi poate accesa câmpurile. Un agent bazat pe adaptoare se împotmolește aici. Abstracția a fost proiectată pentru documentul principal. Sarcina propriu-zisă se află într-un loc pe care abstracția nu îl poate vedea.
O nepotrivire similară apare și în fluxuri mai puțin evidente. Este posibil ca o listă derulantă controlată de cadrul software să nu răspundă deloc la clicuri directe, deoarece elementul vizibil nu este controlul propriu-zis. Poate fi necesară o secvență de evenimente de tastatură pentru a declanșa tranziția stării subiacente. Din exterior, interfața pare să răspundă la clicuri. Abstracția spune „fă clic”. Nu se întâmplă nimic.
Sau să luăm un flux modal în mai mulți pași, în care actualizările DOM-ului vizibil rămân în urma schimbărilor stării interne. Următoarea acțiune corectă depinde de o tranziție de stare care încă nu se reflectă în elementele vizibile adaptorului. Un agent bazat pe adaptoare ajunge să acționeze prea devreme sau să citească o stare învechită, deoarece operează pe baza unei imagini incomplete a sistemului.
În fiecare caz, abstracția ascunde semnalele de care agentul are nevoie în realitate.
Un model care operează la un nivel inferior — inspectând DOM-ul activ, analizând limitele cadrelor și sintetizând secvența de interacțiune pentru suprafața respectivă — poate gestiona aceste situații. Nu pentru că modelul ar fi în mod inerent mai inteligent. Ci pentru că are acces la informațiile care fuseseră eliminate.
Schimbarea pe care o urmărim este simplu de descris: în loc să-i cerem modelului să aleagă dintre acțiuni predefinite, îi oferim o suprafață de execuție de nivel inferior și o limităm prin politici aplicate în timpul rulării, nu prin proiectarea abstracțiilor.
Această opțiune de proiectare provine dintr-o schimbare mai amplă a industriei, care începe să favorizeze instrumente primitive de nivel inferior. Acestea valorifică abilitatea înnăscută a agentului de a se corecta în timpul rulării și de a produce cod de calitate, în locul instrumentelor specifice, fixe în cod, care sunt robuste, dar limitează adaptarea modelului la medii diferite.
Luați drept exemplu succesul Claude Code ca opțiune principală în trusele multor dezvoltatori și orientarea mai amplă a industriei către agenți bazați pe terminal. Cel mai mare avantaj al Claude Code nu este modelul în sine, ci cadrul de testare de nivel inferior. Dacă modelului i se oferă mai puține instrumente, dar mai modulare și de nivel inferior — adică terminalul — performanța apelării instrumentelor se îmbunătățește, în principal deoarece agentul poate raționa și crea scripturi personalizate pentru sarcina curentă, în loc să încerce să folosească instrumente generalizate care aglomerează fereastra contextuală.
În cazul automatizării browserului, aceasta înseamnă că modelul poate inspecta direct starea activă a paginii, poate traversa cadre și poate construi cod de interacțiune personalizat pentru interfața curentă, în loc să asocieze totul unui set fix de acțiuni prefabricate.
Modelul se comportă mai puțin ca un selector și mai mult ca un autor al execuției. Inspectează starea curentă, raționează asupra interfeței și sintetizează logica interacțiunii pentru situația respectivă. Poate construi secvențe în mai mulți pași, se poate adapta fluxurilor neobișnuite și poate valida rezultatele înainte de a continua. Când o acțiune eșuează, modelul vede eroarea subiacentă și se autocorectează. Este o abordare mai puternică și mai riscantă, dar mult mai apropiată de natura reală a problemei.
Important este că eliminarea stratului de abstracție nu reduce rigoarea sistemului. Doar mută această rigoare în altă parte.
Activitatea care ținea înainte de proiectarea adaptoarelor și gestionarea cazurilor-limită se mută în trei zone: solicitarea, care devine o formă de instruire operațională; mediul de execuție, care impune limite precum domeniul navigării, acțiunile sensibile și comportamentul la reîncercare; și stratul de evaluare, care verifică nu doar dacă sarcina a reușit, ci și dacă pașii intermediari au fost corecți. Mai puține abstracții fragile. Sisteme înconjurătoare mai robuste.
Un rezultat al acestei schimbări este că adesea codul produsului devine mai simplu, chiar dacă sistemul per ansamblu devine mai capabil. În loc să codifice tiparele de interacțiune sub forma unor adaptoare reutilizabile, agentul sintetizează comportamentul în timpul rulării. Mențineți un set restrâns de primitive puternice și un mediu de execuție limitat, în locul unei game tot mai mari de instrumente specializate și logică pentru cazuri-limită.
Acest lucru schimbă și modul în care generalizează sistemul. Un agent bazat pe adaptoare generalizează bine pentru sarcini similare celor pentru care ați creat deja adaptoare. Un agent cu un mediu de execuție limitat generalizează pentru sarcini care folosesc același substrat de execuție, chiar dacă interfața vizibilă diferă.
De exemplu, interacțiunea cu un formular de căutare, un flux de rezervare sau o pagină de setări poate arăta complet diferit la nivelul interfeței. Însă, în profunzime, acestea au tipare comune: citirea stării, declanșarea evenimentelor, validarea rezultatelor și gestionarea actualizărilor asincrone. Un sistem care operează la acest nivel se transferă mai natural între sarcini.
Componenta reutilizabilă nu este lista de acțiuni, ci capacitatea modelului de a inspecta starea, de a acționa în siguranță și de a verifica rezultatele.
Cea mai clară lecție a acestei activități este că fiabilitatea nu vine din oferirea mai multor funcții auxiliare modelului. Adesea, ea vine din oferirea unui număr mai mic de primitive, dar mai puternice, și din limitarea lor în modurile potrivite. Ajutorul excesiv fixează în cod presupuneri despre modul în care trebuie realizată o sarcină. Constrângerile definesc limite sigure de operare și permit modelului să descopere soluții locale mai bune.
O suprafață de execuție mai puternică necesită și un model de siguranță mai riguros. Când agentul nu mai este limitat la un set restrâns de acțiuni predefinite, el operează practic direct asupra software-ului real. Acest lucru schimbă imediat profilul de risc.
Proiectarea trebuie să țină cont de patru aspecte:
Expunerea datelor. Dacă agentul interacționează cu interfețe reale, va întâlni adesea informații sensibile. De aceea, mascarea și controlul accesului trebuie abordate riguros. Datele trebuie dezvăluite numai când sunt necesare execuției, iar jurnalele și urmele trebuie gestionate cu grijă, astfel încât observabilitatea să nu devină cea mai sensibilă parte a sistemului.
Domeniul execuției. Un agent puternic nu trebuie să poată opera fără restricții. În practică, trebuie limitate zonele în care poate naviga, domeniile pe care le poate accesa și sistemele cu care poate interacționa. Aceste limite trebuie aplicate la nivelul mediului de execuție, nu lăsate ca simple convenții în solicitare.
Încrederea în mediu. Interfețele moderne pot include instrucțiuni, conținut sau fluxuri înșelătoare ori chiar ostile. Injectarea solicitării prin conținutul paginii reprezintă o suprafață reală de atac. Sistemul are nevoie de o ierarhie clară a instrucțiunilor, verificări de validare și condiții de oprire, pentru a împiedica agentul să urmeze indicații nedorite.
Spectrul autonomiei. Nu toate acțiunile trebuie să fie complet autonome. În multe medii de producție, este important ca autonomia să fie tratată ca un spectru. Sistemul poate avea un grad ridicat de autonomie în explorare și execuție, solicitând totuși aprobarea pentru anumite categorii de acțiuni.
Principiul de bază este simplu: dacă modelul primește mai multă putere, sistemul din jurul său trebuie consolidat. Autonomia fără politici nu este pregătită pentru producție.
Am încetat să ne întrebăm: care sunt acțiunile potrivite din browser pe care să le expunem?
Am început să ne întrebăm: cum putem oferi modelului un spațiu complet al acțiunilor și cum putem crea în jurul acestuia politici pentru mediul de execuție care să păstreze siguranța?
Această nouă perspectivă schimbă prioritățile. Taxonomiile acțiunilor și caracterul complet al adaptoarelor contează mai puțin. Politicile mediului de execuție, observabilitatea și evaluarea fiecărui pas contează mai mult. Capacitatea modelului și proiectarea sistemului nu se pot substitui reciproc. Pe măsură ce modelele se îmbunătățesc, contribuția sistemului devine mai importantă, nu mai puțin importantă.
Agenții pentru browser care funcționează în demonstrații reușesc adesea deoarece sarcina este restrânsă, iar mediul este cooperant. Sistemele de producție necesită altceva: execuție limitată, comportament instrumentat și o evaluare capabilă să deosebească un rezultat corect de unul obținut din noroc.
Mai puțină proiectare de adaptoare. Mai multă inginerie de sistem.
Deși ne-am concentrat pe agenții pentru browser, această abordare sugerează un mod mai amplu de a privi utilizarea computerului ca disciplină a ingineriei de sistem.