Šta je korištenje računara i zašto je važno? Korištenje računara jednostavna je ideja sa širokim implikacijama: umjesto da od modela tražimo odgovore na pitanja, tražimo da upravljaju softverom — da se kreću web-stranicama, ispunjavaju obrasce, prolaze kroz radne tokove klikovima i samostalno izvršavaju zadatke od početka do kraja.
Time se otvara velik skup zadataka iz stvarnog svijeta koji su trenutno rascjepkani među različitim sučeljima, poput kompletnih rezervacija, završetka kupovine na internetu, planiranja putovanja u više koraka i pozadinskih poslovnih tokova bez odgovarajućeg API-ja. To nisu novi problemi. Nova je mogućnost njihovog rješavanja modelima opće namjene.
Nedavni sistemi kompanija Anthropic i OpenAI predstavili su agente koji ne samo da djeluju nego i rezonuju o stanju, oporavljaju se od grešaka te u hodu stvaraju rješenja prilagođena zadatku. Time preglednik postaje opće izvršno okruženje za agente, ali se odmah nameće projektno pitanje: koliki dio tog okruženja treba izložiti modelu?
Rani sistemi odgovorili su tako što su preglednik obuhvatili omotačem s fiksnim skupom sigurnih, unaprijed definiranih radnji. Kao što ćemo pokazati u ovom tekstu, taj pristup dostiže svoje granice.
Pri izradi agenata za preglednike često se javlja poznat instinkt: ne vjerujte modelu previše.
Zato preglednik stavljamo u omotač. Izlažemo unaprijed definirane alate poput click, type, scroll, select i read_text. Pojednostavljujemo objektni model dokumenta (DOM). Smanjujemo prostor radnji. Pokušavamo ponašanje učiniti razumljivim i upravljivim pomoću apstrakcija koje sami projektujemo.
To je razumna polazna tačka. Ali sve više predstavlja i pogrešnu dugoročnu arhitekturu.
Kako granični modeli napreduju, ograničenje više nije samo u tome što modelu nedostaju alati. Problem je u tome što ga prisiljavamo da radi kroz apstrakcije koje uklanjaju previše informacija o temeljnom sistemu. Neuredno i dinamično okruženje sažimamo u fiksno sučelje za radnje, a zatim od modela tražimo da dobro radi uprkos tom gubitku informacija.
Taj kompromis postaje sve manje privlačan.
Promjenu koju istražujemo lako je opisati, ali su njene posljedice značajne. Umjesto da agenta posmatramo kao birača unaprijed definiranih radnji, posmatramo ga kao sintetizator programa koji radi unutar ograničenog izvršnog okruženja.
Modeli su postali zaista dobri i više im nisu potrebne vaše apstraktne zaštitne ograde — potreban im je cijeli prostor radnji kako bi osmislili, izvršili i ponavljali zadatak dok ne ostvare cilj.
Ovaj tekst govori o toj promjeni — od automatizacije preglednika opterećene apstrakcijama do ograničenog korištenja računara — i o tome šta se mijenja kada sisteme projektujete na taj način.
Problem nije u tome što su fiksna sučelja za radnje konceptualno pogrešna. Problem je u tome što web ne sarađuje s njima.
Savremena sučelja izgrađena su pomoću tehnologija React, Vue i Angular, uz asinhrona ažuriranja stanja, sintetičke sisteme događaja i ugrađene dodatke trećih strana koji se nalaze u iframeovima drugog porijekla i imaju vlastite životne cikluse. Omotač koji kaže „upiši u ovo polje“ ispravan je samo ako se stranica slaže s vašom definicijom unosa. Mnoge se ne slažu. Direktno postavljanje vrijednosti često potpuno zaobilazi mehanizam okvira za otkrivanje promjena. Čini se da je polje ispunjeno. Provjera valjanosti nikada se ne pokrene. Obrazac i dalje ne radi.
To možete zakrpiti. Možete dodati posebne slučajeve za React polja, poslati događaje blur nakon događaja focus i sačekati mirovanje mreže prije očitavanja stanja. Svaka zakrpa zasebno je ispravna. Zajedno se gomilaju u sistem koji je sve teže održavati i koji je sve više prilagođen samo web-lokacijama koje ste već vidjeli.
Dublji problem jeste to što u sloj apstrakcije ugrađujete pretpostavke o tome kako bi interakcije trebale funkcionirati, a zatim otkrivate da web počiva na drugačijim pretpostavkama.
Razmotrite obrazac za plaćanje ugrađen putem sistema Stripe ili Adyen u iframe drugog porijekla. Vaš omotač ne može mu direktno pristupiti jer se nalazi na zasebnom porijeklu. Vaš alat read_text ne može pratiti njegovo unutrašnje stanje. Vaš alat type ne može pristupiti njegovim poljima za unos. Agent zasnovan na omotaču ovdje nailazi na zid. Apstrakcija je projektovana za glavni dokument. Stvarni zadatak nalazi se tamo gdje ga apstrakcija ne može vidjeti.
Slična nepodudarnost javlja se i u manje očiglednim tokovima. Padajući izbornik kojim upravlja radni okvir možda uopće neće reagovati na direktne klikove jer vidljivi element nije stvarna kontrola. Možda će biti potreban niz događaja s tastature kako bi se pokrenuo prijelaz temeljnog stanja. Izvana se čini da je na element korisničkog sučelja moguće kliknuti. Apstrakcija kaže „klikni“. Ništa se ne događa.
Ili razmotrite modalni tok u više koraka u kojem ažuriranja vidljivog DOM-a kasne za promjenama unutrašnjeg stanja. Ispravna sljedeća radnja zavisi od prijelaza stanja koji se još ne vidi u elementima dostupnim vašem omotaču. Agent zasnovan na omotaču na kraju djeluje prerano ili očitava zastarjelo stanje jer radi na osnovu nepotpunog prikaza sistema.
U svakom od tih slučajeva apstrakcija skriva signale koji su agentu zaista potrebni.
Model koji radi na nižem nivou — ispituje aktivni DOM, rezonuje o granicama okvira i stvara niz interakcija za tu konkretnu površinu — može se snaći u tim situacijama. Nije riječ o tome da je model sam po sebi pametniji. Riječ je o tome da ima pristup informacijama koje su prethodno uklonjene.
Promjenu kojoj težimo lako je opisati: umjesto da od modela tražimo izbor među unaprijed definiranim radnjama, dajemo mu izvršnu površinu nižeg nivoa i ograničavamo je pravilima izvršnog okruženja, a ne projektovanjem apstrakcije.
Ova projektna odluka proizlazi iz šire promjene u industriji, koja sve više daje prednost primitivnim alatima nižeg nivoa. Oni koriste urođenu sposobnost agenta da se ispravlja tokom izvršavanja i stvara kvalitetan kôd, umjesto fiksno kodiranih specifičnih alata koji jesu robusni, ali modelu oduzimaju sposobnost prilagođavanja različitim okruženjima.
Uzmite u obzir uspjeh alata Claude Code kao jednog od glavnih izbora mnogih programera, kao i širi zaokret industrije prema agentima zasnovanim na terminalu. Najveća prednost alata Claude Code nije sam model, nego harness nižeg nivoa. Pružanje manjeg broja modularnijih alata nižeg nivoa modelu — tj. terminala — omogućava bolje korištenje alata, prvenstveno zato što agent može rezonovati i stvarati prilagođene skripte za konkretan zadatak, umjesto da pokušava koristiti općenite alate koji zagušuju kontekstni prozor.
U praksi, kod automatizacije preglednika, to znači da model može direktno ispitati aktivno stanje stranice, prolaziti kroz okvire i izrađivati prilagođeni kôd za interakciju s trenutnim sučeljem, umjesto da sve preslikava na fiksni skup unaprijed izrađenih radnji.
Model se ponaša manje kao birač, a više kao autor izvršnog procesa. Ispituje trenutno stanje, rezonuje o sučelju i stvara logiku interakcije za konkretnu situaciju. Može sastaviti nizove od više koraka, prilagoditi se neuobičajenim tokovima i provjeriti ishode prije nego što nastavi. Kada radnja ne uspije, model vidi izvornu grešku i sam je ispravlja. To je moćnije i rizičnije, ali mnogo bolje odgovara stvarnoj prirodi problema.
Važno je da uklanjanje sloja apstrakcije ne čini sistem manje discipliniranim. Samo premješta disciplinu na drugo mjesto.
Posao koji se ranije obavljao kroz projektovanje omotača i obradu rubnih slučajeva premješta se na tri mjesta: u upit (koji postaje oblik operativne obuke), izvršno okruženje (koje nameće granice poput opsega navigacije, osjetljivih radnji i ponašanja pri ponovnim pokušajima) te sloj evaluacije (koji ne procjenjuje samo je li zadatak uspio nego i jesu li međukoraci bili ispravni). Manje krhkih apstrakcija. Jači sistemi koji ih okružuju.
Jedan od rezultata ove promjene jeste da programski kôd proizvoda često postaje jednostavniji, iako cijeli sistem postaje sposobniji. Umjesto da obrasce interakcije kodira kao višekratno upotrebljive omotače, agent stvara ponašanje tokom izvršavanja. Održavate mali skup moćnih primitiva i ograničeno izvršno okruženje, umjesto sve većeg broja specijaliziranih alata i logike za rubne slučajeve.
To mijenja i način na koji sistem generalizira. Agent zasnovan na omotačima dobro generalizira na zadatke koji nalikuju omotačima koje ste već izradili. Agent u ograničenom izvršnom okruženju generalizira na zadatke sa zajedničkom izvršnom osnovom, čak i kada im se vidljiva sučelja razlikuju.
Naprimjer, interakcije s obrascem za pretragu, postupkom rezervacije ili stranicom postavki mogu izgledati potpuno različito na nivou korisničkog sučelja. Međutim, u osnovi dijele iste obrasce: očitavanje stanja, pokretanje događaja, provjeru ishoda i obradu asinhronih ažuriranja. Sistem koji radi na tom nivou prirodnije prenosi sposobnosti s jednog zadatka na drugi.
Komponenta za višekratnu upotrebu nije spisak radnji. To je sposobnost modela da ispita stanje, sigurno djeluje i provjeri rezultate.
Najjasnija pouka iz ovog rada jeste da pouzdanost ne proizlazi iz pružanja većeg broja pomoćnih funkcija modelu. Često proizlazi iz manjeg broja moćnijih primitiva, ograničenih na odgovarajuće načine. Pretjerana pomoć ugrađuje pretpostavke o tome kako bi zadatak trebalo izvršiti direktno u kôd. Ograničenja određuju sigurne granice rada i omogućavaju modelu da pronađe bolja lokalna rješenja.
Moćnija izvršna površina zahtijeva i precizniji sigurnosni model. Kada agent više nije ograničen na mali skup unaprijed definiranih radnji, on zapravo radi direktno sa stvarnim softverom. To odmah mijenja profil rizika.
Pri projektovanju treba uzeti u obzir četiri pitanja:
Izloženost podataka. Ako agent koristi stvarna sučelja, često će nailaziti na osjetljive podatke. Zato je potreban discipliniran pristup maskiranju i kontroli pristupa. Podatke treba otkrivati samo kada su neophodni za izvršenje, a zapisima i tragovima mora se pažljivo upravljati kako mogućnost praćenja ne bi postala najosjetljiviji dio sistema.
Opseg izvršavanja. Moćan agent ne smije moći djelovati bez ograničenja. U praksi to znači ograničiti kuda se može kretati, kojim domenama može pristupiti i s kojim sistemima smije stupati u interakciju. Ta ograničenja treba provoditi na nivou izvršnog okruženja, a ne ostavljati ih kao pravila u upitu.
Pouzdanost okruženja. Savremena sučelja mogu sadržavati obmanjujuće ili aktivno neprijateljske upute, sadržaj ili tokove. Ubrizgavanje upita kroz sadržaj stranice predstavlja stvarnu površinu napada. Sistemu su potrebni jasna hijerarhija uputa, provjere valjanosti i uslovi prekida kako agent ne bi slijedio neželjene smjernice.
Spektar autonomije. Ne trebaju sve radnje biti potpuno autonomne. U mnogim produkcijskim okruženjima važno je autonomiju posmatrati kao spektar. Sistem može djelovati izrazito agentski pri istraživanju i izvršavanju, a ipak zahtijevati odobrenje za određene kategorije radnji.
Temeljno načelo je jednostavno: davanje veće moći modelu zahtijeva jačanje sistema koji ga okružuje. Autonomija bez pravila nije spremna za produkciju.
Prestali smo pitati: koje radnje preglednika treba izložiti?
Počeli smo pitati: kako modelu možemo pružiti cijeli prostor radnji i oko njega uspostaviti pravila izvršnog okruženja koja i dalje garantuju sigurnost?
Ta nova perspektiva mijenja ono što smatrate važnim. Taksonomije radnji i potpunost omotača postaju manje važne. Pravila izvršnog okruženja, mogućnost praćenja i evaluacija pojedinačnih koraka postaju važniji. Sposobnost modela i projektovanje sistema ne mogu zamijeniti jedno drugo. Kako modeli napreduju, rad sistema postaje važniji, a ne manje važan.
Agenti za preglednike koji rade u demonstracijama često uspijevaju zato što je zadatak usko definiran, a okruženje pogodno. Produkcijski sistemi zahtijevaju nešto drugo: ograničeno izvršavanje, instrumentirano ponašanje i evaluaciju koja može razlikovati ispravan ishod od pukog slučajnog uspjeha.
Manje projektovanja omotača. Više sistemskog inženjerstva.
Iako smo se usredotočili na agente za preglednike, ovo ukazuje na širi način razmišljanja o korištenju računara kao sistemskoj disciplini.