Glavna navigacija

Od omotača preglednika do ograničene upotrebe računala

Sposobniji agenti zahtijevaju manje automatizacije preglednika opterećene apstrakcijama i pažljivije ograničena izvršna okruženja.

Sažetak za rukovoditelje

  • Što je upotreba računala i zašto je važna? Upotreba računala jednostavna je zamisao sa širokim posljedicama: umjesto da od modela tražimo odgovore na pitanja, tražimo da upravljaju softverom — kreću se web-mjestima, ispunjavaju obrasce, prolaze kroz radne tijekove klikovima te autonomno izvršavaju zadatke od početka do kraja.

  • Time se otvara velik skup praktičnih zadataka koji su trenutačno rascjepkani među sučeljima, poput cjelovitih rezervacija, dovršavanja kupnje na internetu, planiranja putovanja u više koraka i pozadinskih poslovnih procesa bez odgovarajućeg jednostavnog API-ja. To nisu novi problemi. Novo je to što ih je sada moguće rješavati modelima opće namjene.

  • Nedavni sustavi tvrtki Anthropic i OpenAI pokazali su agente koji ne samo da djeluju nego i rasuđuju o stanju, oporavljaju se od pogrešaka te u hodu stvaraju rješenja prilagođena zadatku. Time preglednik postaje opće izvršno okruženje za agente, ali odmah se nameće projektno pitanje: koliko tog okruženja treba izložiti modelu?

  • Rani sustavi odgovorili su tako što su preglednik obuhvatili fiksnim skupom sigurnih, unaprijed definiranih radnji. Kao što ćemo pokazati u ovom tekstu, taj pristup doseže svoje granice.

Dijagram koji prikazuje sažetak za rukovoditelje.

Pri izradi agenata za preglednike javlja se poznat instinkt: nemojte previše vjerovati modelu.

Zato preglednik obuhvaćamo omotačem. Izlažemo unaprijed definirane alate kao što su click, type, scroll, select i read_text. Pojednostavnjujemo objektni model dokumenta (DOM). Smanjujemo prostor mogućih radnji. Ponašanje nastojimo učiniti razumljivim i upravljivim pomoću apstrakcija koje sami oblikujemo.

To je razumno polazište. No sve je češće i pogrešna dugoročna arhitektura.

Kako se granični modeli poboljšavaju, ograničenje više nije samo u tome što modelu nedostaju alati. Problem je u tome što ga prisiljavamo da radi putem apstrakcija koje uklanjaju previše elemenata temeljnog sustava. Neuredno, dinamično okruženje sažimamo u fiksno sučelje radnji, a zatim od modela tražimo da dobro radi unatoč tom gubitku informacija.

Takav kompromis postaje sve manje privlačan.

Pomak koji istražujemo lako je opisati, ali njegove su posljedice znatne. Umjesto da agent promatramo kao alat za odabir unaprijed definiranih radnji, promatramo ga kao sintetizator programa koji djeluje unutar ograničenog izvršnog okruženja.

Modeli su postali vrlo dobri i više ne trebaju vaše apstraktne zaštitne ograde — potreban im je cijeli prostor mogućih radnji kako bi osmislili, izvršili i ponavljali zadatak dok ne ostvare cilj.

Ovaj tekst govori o tom pomaku, od automatizacije preglednika opterećene apstrakcijama prema ograničenoj upotrebi računala, te o tome što se mijenja kada sustave projektirate na taj način.

Zašto apstrakcije prestaju funkcionirati

Problem nije u tome što su fiksna sučelja radnji konceptualno pogrešna. Problem je u tome što im web ne ide na ruku.

Dijagram koji prikazuje zašto apstrakcije prestaju funkcionirati.

Moderna sučelja izrađena su tehnologijama React, Vue i Angular, uz asinkrona ažuriranja stanja, sustave sintetičkih događaja i ugrađene widgete trećih strana koji se nalaze u iframeovima drugog podrijetla te 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 upisivanja. Mnoge se ne slažu. Izravno postavljanje vrijednosti često u potpunosti zaobilazi mehanizam okvira za otkrivanje promjena. Čini se da je polje ispunjeno. Provjera valjanosti nikad se ne pokrene. Obrazac i dalje ne radi.

To možete zakrpati. Možete dodati posebne slučajeve za ulazna polja u Reactu, odašiljati događaje blur nakon fokusa te prije očitavanja stanja pričekati da mreža bude neaktivna. Svaka je zakrpa lokalno ispravna. Zajedno se gomilaju u sustav koji je sve teže održavati i koji je sve više prilagođen samo web-mjestima s kojima ste se već susreli.

Dublji je problem to što u sloj apstrakcije ugrađujete pretpostavke o tome kako bi interakcije trebale funkcionirati, a zatim otkrivate da web počiva na drukčijim pretpostavkama.

Što se događa kada apstrakcija naiđe na stvarni tijek

Zamislite obrazac za plaćanje koji je Stripe ili Adyen ugradio u iframe drugog podrijetla. Vaš mu omotač ne može izravno pristupiti jer se nalazi na zasebnom podrijetlu. Vaš alat read_text ne može promatrati njegovo unutarnje stanje. Vaš alat type ne može pristupiti njegovim ulaznim poljima. Agent temeljen na omotačima ovdje nailazi na zid. Apstrakcija je osmišljena za glavni dokument. Stvarni se zadatak nalazi ondje gdje ga apstrakcija ne može vidjeti.

Slična neusklađenost pojavljuje se i u manje očitim tijekovima. Padajući izbornik kojim upravlja programski okvir možda uopće neće reagirati na izravne klikove jer vidljivi element nije stvarna kontrola. Za pokretanje temeljne promjene stanja možda je potreban niz događaja tipkovnice. Izvana korisničko sučelje izgleda kao da se na njega može kliknuti. Apstrakcija kaže „klikni”. Ništa se ne događa.

Ili zamislite modalni tijek u više koraka u kojem ažuriranja vidljivog DOM-a kasne za promjenama unutarnjeg stanja. Ispravna sljedeća radnja ovisi o promjeni stanja koja se još ne odražava u elementima vidljivima vašem omotaču. Agent temeljen na omotačima na kraju djeluje prerano ili očitava zastarjelo stanje jer radi s nepotpunim prikazom sustava.

U svakom od tih slučajeva apstrakcija skriva signale koji su agentu doista potrebni.

Model koji radi na nižoj razini — pregledava aktivni DOM, rasuđuje o granicama okvira i stvara slijed interakcija za to određeno sučelje — 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.

Arhitektonski pomak

Promjenu prema kojoj idemo lako je opisati: umjesto da od modela tražimo odabir unaprijed definiranih radnji, pružamo mu izvršnu površinu niže razine i ograničavamo je pravilima izvršavanja, a ne projektiranjem apstrakcije.

Ta projektna odluka proizlazi iz šireg pomaka u industriji prema osnovnim alatima niže razine, koji iskorištavaju urođenu sposobnost agenta da tijekom izvođenja ispravlja pogreške i stvara kvalitetan kod, umjesto prema robusnim, posebno izrađenim alatima s ugrađenom logikom koji modelu oduzimaju mogućnost prilagodbe različitim okruženjima.

Uzmite u obzir uspjeh alata Claude Code kao jednog od glavnih izbora mnogih razvojnih programera te širi pomak industrije prema agentima koji rade putem terminala. Najveća prednost alata Claude Code nije sam model, nego testni sklop niže razine. Pružanje manjeg broja modularnijih alata niže razine modelu — odnosno terminala — poboljšava učinkovitost pozivanja alata, ponajprije zato što agent može rasuđivati i stvarati prilagođene skripte za konkretan zadatak umjesto da pokušava upotrebljavati generalizirane alate koji zagušuju kontekstni prozor.

U praksi, pri automatizaciji preglednika, to znači da model može izravno pregledavati trenutačno stanje stranice, prolaziti kroz okvire i stvarati prilagođeni kod za interakciju s trenutačnim sučeljem, umjesto da sve preslikava na fiksni skup unaprijed izrađenih radnji.

Model se ponaša manje kao alat za odabir, a više kao autor logike koja nastaje tijekom izvođenja. Pregledava trenutačno stanje, rasuđuje o sučelju i stvara logiku interakcije za konkretnu situaciju. Može stvarati nizove od više koraka, prilagođavati se neuobičajenim tijekovima i provjeravati ishode prije nastavka. Kada radnja ne uspije, model vidi temeljnu pogrešku i sam se ispravlja. To je moćnije i rizičnije, ali mnogo vjernije stvarnoj prirodi problema.

Važno je istaknuti da uklanjanje sloja apstrakcije ne čini sustav manje discipliniranim. Samo premješta disciplinu.

Posao koji se prije obavljao projektiranjem omotača i obradom rubnih slučajeva premješta se na tri mjesta: u upit (koji postaje oblik operativne obuke), izvršno okruženje (koje provodi ograničenja poput opsega navigacije, osjetljivih radnji i ponašanja pri ponovnim pokušajima) te evaluacijski sloj (koji ne procjenjuje samo je li zadatak uspio nego i jesu li međukoraci bili ispravni). Manje krhkih apstrakcija. Jači okolni sustavi.

Iznenađujuća posljedica: jednostavniji programski kod proizvoda, šira generalizacija

Jedan je od ishoda ovog pomaka to da programski kod proizvoda često postaje jednostavniji, iako sustav u cjelini postaje sposobniji. Umjesto da se obrasci interakcije kodiraju kao višekratno upotrebljivi omotači, agent stvara ponašanje tijekom izvođenja. Održavate malen skup moćnih osnovnih funkcija i ograničeno izvršno okruženje umjesto sve većeg broja specijaliziranih alata i logike za rubne slučajeve.

Time se mijenja i način na koji sustav generalizira. Agent temeljen na omotačima dobro generalizira na zadatke slične onima za koje ste već izradili omotače. Agent u ograničenom izvršnom okruženju generalizira na zadatke koji dijele istu izvršnu podlogu, čak i kada je vidljivo sučelje drukčije.

Primjerice, interakcija s obrascem za pretraživanje, postupkom rezervacije ili stranicom postavki može izgledati posve drukčije na razini korisničkog sučelja. No u podlozi dijele iste obrasce: očitavanje stanja, pokretanje događaja, provjeru ishoda i obradu asinkronih ažuriranja. Sustav koji djeluje na toj razini prirodnije prenosi sposobnosti s jednog zadatka na drugi.

Komponenta za višekratnu upotrebu nije popis radnji, nego sposobnost modela da pregleda stanje, sigurno djeluje i provjeri rezultate.

Ograničite, nemojte pretjerano pomagati

Dijagram koji prikazuje načelo „ograničite, nemojte pretjerano pomagati”.

Najjasnija je pouka ovog rada da se pouzdanost ne postiže pružanjem većeg broja pomoćnih funkcija modelu. Često se postiže pružanjem manjeg broja moćnijih osnovnih funkcija, ograničenih na odgovarajuće načine. Pretjerana pomoć ugrađuje pretpostavke o tome kako bi zadatak trebalo izvršiti izravno u kod. Ograničenja određuju sigurne granice djelovanja i omogućuju 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 malen skup unaprijed definiranih radnji, zapravo izravno upravlja stvarnim softverom. Time se profil rizika odmah mijenja.

Pri projektiranju treba uzeti u obzir četiri pitanja:

Izlaganje podataka. Ako agent komunicira sa stvarnim sučeljima, često će naići na osjetljive podatke. To zahtijeva discipliniran pristup maskiranju i kontroli pristupa. Podatke treba otkriti samo kada su nužni za izvršavanje, a zapisnicima i tragovima treba pažljivo rukovati kako mogućnost nadzora ne bi postala najosjetljiviji dio sustava.

Opseg izvršavanja. Moćan agent ne bi smio proizvoljno djelovati. U praksi to znači ograničiti kamo se može kretati, kojim domenama može pristupati i s kojim sustavima smije komunicirati. Ta ograničenja treba provoditi na razini izvršnog okruženja, a ne ih ostaviti kao konvencije u upitima.

Pouzdanost okruženja. Moderna sučelja mogu sadržavati upute, sadržaj ili tijekove koji obmanjuju ili su aktivno zlonamjerni. Ubrizgavanje upita putem sadržaja stranice predstavlja stvarnu površinu napada. Sustav treba jasnu hijerarhiju uputa, provjere valjanosti i uvjete prekida kako agent ne bi slijedio neželjene smjernice.

Spektar autonomije. Ne bi sve radnje trebale biti potpuno autonomne. U mnogim produkcijskim okruženjima autonomiju je važno promatrati kao spektar. Sustav može djelovati izrazito agentski pri istraživanju i izvršavanju, a ipak zahtijevati odobrenje za određene kategorije radnji.

Temeljno je načelo jednostavno: davanje većih ovlasti modelu zahtijeva jačanje okolnog sustava. Autonomija bez pravila nije spremna za produkciju.

Novi pogled koji je promijenio naše razmišljanje

Prestali smo se pitati: koje radnje preglednika treba izložiti?

Počeli smo se pitati: kako modelu pružiti cijeli prostor mogućih radnji — i kako oko njega uspostaviti pravila izvršavanja koja i dalje jamče sigurnost?

Takav novi pogled mijenja vaše prioritete. Taksonomije radnji i potpunost omotača postaju manje važne. Pravila izvršavanja, mogućnost nadzora i evaluacija pojedinačnih koraka postaju važniji. Sposobnost modela i projektiranje sustava ne mogu zamijeniti jedno drugo. Kako modeli napreduju, rad sustava postaje važniji, a ne manje važan.

Agenti za preglednike koji rade u demonstracijama često uspijevaju zato što je zadatak uzak, a okruženje suradljivo. Produkcijski sustavi zahtijevaju nešto drugo: ograničeno izvršavanje, instrumentirano ponašanje i evaluaciju koja može razlikovati ispravan ishod od pukog slučajnog uspjeha.

Završna misao

Manje projektiranja omotača. Više sistemskog inženjerstva.

Iako smo se usredotočili na agente za preglednike, to upućuje na širi pogled na upotrebu računala kao sistemsku disciplinu.

Autor

Yuxi Huan, Yuliyan Stefanov Savchev i Sheah Wen Liaw