Kaj je uporaba računalnika in zakaj je pomembna? Uporaba računalnika je preprosta zamisel z daljnosežnimi posledicami: namesto da bi modele prosili, naj odgovarjajo na vprašanja, jim naročimo, naj samostojno upravljajo programsko opremo – krmarijo po spletnih mestih, izpolnjujejo obrazce, se prebijajo skozi postopke in naloge opravijo od začetka do konca.
To omogoča obsežen razred resničnih nalog, ki so zdaj razdrobljene po različnih vmesnikih, kot so celovite rezervacije, zaključevanje spletnih nakupov, večstopenjsko načrtovanje potovanj in zaledni postopki brez ustreznega enotnega API-ja. To niso nove težave. Nova je možnost, da jih rešujemo s splošnonamenskimi modeli.
Nedavni sistemi podjetij Anthropic in OpenAI so pokazali agente, ki ne le ukrepajo, temveč tudi sklepajo o stanju, odpravljajo napake in sproti oblikujejo rešitve za posamezne naloge. Brskalnik tako postane splošno izvajalno okolje za agente, vendar se takoj pojavi vprašanje zasnove: kolikšen del tega okolja naj izpostavimo modelu?
Zgodnji sistemi so se odzvali tako, da so brskalnik ovili v nespremenljiv nabor varnih, vnaprej določenih dejanj. Kot bomo pojasnili v tej objavi, ta pristop dosega svoje meje.
Pri razvoju brskalniških agentov se pogosto pojavi znan vzgib: modelu ne zaupaj preveč.
Zato brskalnik ovijemo. Izpostavimo vnaprej določena orodja, kot so click, type, scroll, select in read_text. Poenostavimo objektni model dokumenta (DOM). Zmanjšamo prostor možnih dejanj. Z abstrakcijami, ki jih zasnujemo sami, poskušamo poskrbeti, da je vedenje razumljivo in obvladljivo.
To je smiselno izhodišče. Vendar je obenem vse bolj tudi napačna dolgoročna arhitektura.
Z izboljševanjem prelomnih modelov omejitev ni več le pomanjkanje orodij. Težava je v tem, da model silimo k delovanju prek abstrakcij, ki odstranijo preveč podrobnosti temeljnega sistema. Neurejeno, dinamično okolje stisnemo v nespremenljiv vmesnik dejanj, nato pa od modela pričakujemo dobro delovanje kljub tej izgubi informacij.
Ta kompromis postaja vse manj privlačen.
Premik, ki ga raziskujemo, je preprosto opisati, vendar ima pomembne posledice. Agenta ne obravnavamo več kot izbirnik vnaprej določenih dejanj, temveč kot sintetizator programov, ki deluje v omejenem izvajalnem okolju.
Modeli so postali zelo zmogljivi in ne potrebujejo več vaših abstraktnih varoval. Potrebujejo celoten prostor dejanj, da lahko nalogo zasnujejo, izvedejo in izboljšujejo, dokler ne dosežejo cilja.
Ta objava govori o premiku od avtomatizacije brskalnika, polne abstrakcij, k omejeni uporabi računalnika ter o tem, kaj se spremeni, ko sisteme zasnujemo na ta način.
Težava ni v tem, da bi bili nespremenljivi vmesniki dejanj že v osnovi napačni. Težava je, da splet z njimi ne sodeluje.
Sodobni vmesniki temeljijo na ogrodjih React, Vue in Angular ter vključujejo asinhrone posodobitve stanja, sisteme sintetičnih dogodkov in vdelane gradnike drugih ponudnikov, ki delujejo v okvirjih iframe iz drugih izvorov in imajo lastne življenjske cikle. Ovojnica z navodilom »vnesi besedilo v to vnosno polje« je pravilna le, če se stran strinja z vašo opredelitvijo vnosa. Številne se ne. Neposredna nastavitev vrednosti pogosto povsem zaobide zaznavanje sprememb v ogrodju. Vnosno polje je videti izpolnjeno. Preverjanje veljavnosti se nikoli ne sproži. Obrazec še vedno ne deluje.
To lahko zakrpate. Dodate lahko posebne primere za vnosna polja React, po postavitvi fokusa razpošljete dogodke blur in pred branjem stanja počakate, da se omrežna dejavnost umiri. Vsak popravek je v svojem primeru pravilen. Skupaj pa se kopičijo v sistem, ki ga je vse težje vzdrževati in je vse bolj prilagojen spletnim mestom, ki ste jih že srečali.
Globlji problem je, da v abstrakcijsko plast vgrajujete predpostavke o tem, kako naj interakcije delujejo, nato pa ugotovite, da splet temelji na drugačnih predpostavkah.
Predstavljajte si plačilni obrazec ponudnika Stripe ali Adyen, vdelan v okvir iframe iz drugega izvora. Vaša ovojnica ga ne more doseči neposredno, ker deluje v ločenem izvoru. Orodje read_text ne more opazovati njegovega notranjega stanja. Orodje type ne more dostopati do njegovih vnosnih polj. Agent, ki temelji na ovojnicah, tu naleti na nepremostljivo oviro. Abstrakcija je bila zasnovana za glavni dokument. Dejanska naloga pa je nekje, kamor abstrakcija ne vidi.
Podobno neskladje se pojavi tudi v manj očitnih postopkih. Spustni seznam, ki ga nadzoruje ogrodje, se morda sploh ne odzove na neposredne klike, saj vidni element ni dejanski kontrolnik. Za sprožitev spremembe notranjega stanja je morda potrebno zaporedje dogodkov tipkovnice. Navzven je uporabniški vmesnik videti tak, kot da ga je mogoče klikniti. Abstrakcija ukaže »klikni«. Ne zgodi se nič.
Ali pa si predstavljajte večstopenjski postopek v modalnem oknu, pri katerem vidne posodobitve DOM-a zaostajajo za spremembami notranjega stanja. Pravilno naslednje dejanje je odvisno od spremembe stanja, ki je elementi, vidni ovojnici, še ne odražajo. Agent, ki temelji na ovojnicah, ukrepa prezgodaj ali prebere zastarelo stanje, ker deluje na podlagi nepopolnega pogleda na sistem.
V vsakem od teh primerov abstrakcija skrije signale, ki jih agent dejansko potrebuje.
Model, ki deluje na nižji ravni – pregleduje živi DOM, sklepa o mejah okvirjev in sintetizira zaporedje interakcij za konkretno površino – se lahko znajde v takšnih okoliščinah. Ne gre za to, da bi bil model že sam po sebi pametnejši. Gre za to, da ima dostop do informacij, ki so bile prej odstranjene.
Spremembo, h kateri stremimo, je preprosto opisati: namesto da bi model prosili, naj izbira med vnaprej določenimi dejanji, mu ponudimo izvajalno površino nižje ravni in jo omejimo s pravilniki izvajalnega okolja, ne z zasnovo abstrakcij.
Ta odločitev izhaja iz širšega premika v panogi, ki začenja dajati prednost osnovnim orodjem nižje ravni. Ta izkoriščajo agentovo prirojeno sposobnost sprotnega popravljanja in ustvarjanja kakovostne kode, namesto da bi uporabljala robustna, a strogo namenska orodja, ki modelu odvzamejo zmožnost prilagajanja različnim okoljem.
Pomislite na uspeh orodja Claude Code, ki je postalo ena glavnih izbir številnih razvijalcev, in na širši premik panoge k agentom, ki temeljijo na terminalu. Največja prednost orodja Claude Code ni sam model, temveč ogrodje nižje ravni. Če modelu ponudimo manj bolj modularnih orodij nižje ravni – tj. terminal –, učinkoviteje kliče orodja, predvsem zato, ker lahko agent sklepa in ustvari skripte po meri za trenutno nalogo, namesto da bi poskušal uporabljati posplošena orodja, ki obremenjujejo kontekstno okno.
Pri avtomatizaciji brskalnika to v praksi pomeni, da lahko model neposredno pregleda trenutno stanje strani, prehaja med okvirji in sestavi interakcijsko kodo po meri trenutnega vmesnika, namesto da bi vse preslikal na nespremenljiv nabor vnaprej izdelanih dejanj.
Model se vede manj kot izbirnik in bolj kot avtor kode med izvajanjem. Pregleda trenutno stanje, sklepa o vmesniku in sintetizira logiko interakcije za konkretne okoliščine. Sestavi lahko večstopenjska zaporedja, se prilagodi neobičajnim postopkom in pred nadaljevanjem preveri rezultate. Ko dejanje ne uspe, model vidi izvorno napako in se sam popravi. To je zmogljivejše in bolj tvegano, vendar veliko bolje ustreza dejanski naravi problema.
Pomembno je, da odstranitev abstrakcijske plasti ne zmanjša discipliniranosti sistema. Disciplino le prestavi drugam.
Delo, ki je bilo prej del zasnove ovojnic in obravnavanja robnih primerov, se preseli na tri področja: v poziv (ki postane oblika operativnega usposabljanja), izvajalno okolje (ki uveljavlja omejitve, kot so obseg krmarjenja, občutljiva dejanja in ravnanje ob ponovnih poskusih) ter plast vrednotenja (ki ne presoja le, ali je bila naloga uspešna, temveč tudi, ali so bili vmesni koraki pravilni). Manj krhkih abstrakcij. Zmogljivejši podporni sistemi.
Ena od posledic tega premika je, da koda izdelka pogosto postane preprostejša, čeprav celoten sistem pridobi več zmogljivosti. Namesto da bi vzorce interakcij zapisali v obliki ovojnic za večkratno uporabo, agent vedenje sintetizira med izvajanjem. Namesto vse večjega nabora specializiranih orodij in logike za robne primere vzdržujete majhen nabor zmogljivih osnovnih gradnikov ter omejeno izvajalno okolje.
S tem se spremeni tudi način posploševanja sistema. Agent, ki temelji na ovojnicah, dobro posplošuje na naloge, podobne tistim, za katere ste že izdelali ovojnice. Agent z omejenim izvajalnim okoljem posplošuje na naloge s skupno izvajalno osnovo, tudi če je njihov vidni vmesnik drugačen.
Interakcija z iskalnim obrazcem, postopkom rezervacije ali stranjo z nastavitvami je lahko na ravni uporabniškega vmesnika na primer videti povsem drugače. V ozadju pa imajo skupne vzorce: branje stanja, proženje dogodkov, preverjanje rezultatov in obravnavanje asinhronih posodobitev. Sistem, ki deluje na tej ravni, se naravneje prenaša med nalogami.
Komponenta za večkratno uporabo ni seznam dejanj, temveč sposobnost modela, da pregleda stanje, varno ukrepa in preveri rezultate.
Najjasnejše spoznanje tega dela je, da zanesljivosti ne dosežemo tako, da modelu ponudimo več pomožnih funkcij. Pogosto jo dosežemo tako, da mu ponudimo manj osnovnih gradnikov, ki so zmogljivejši in ustrezno omejeni. Pretirana pomoč v kodo vgrajuje predpostavke o tem, kako naj se naloga izvede. Omejitve določajo varne meje delovanja in modelu omogočajo, da odkrije boljše rešitve za posamezne primere.
Zmogljivejša izvajalna površina zahteva tudi strožji varnostni model. Ko agent ni več omejen na majhen nabor vnaprej določenih dejanj, dejansko neposredno upravlja pravo programsko opremo. S tem se profil tveganja nemudoma spremeni.
Pri zasnovi je treba upoštevati štiri vidike:
Izpostavljenost podatkov. Če agent uporablja prave vmesnike, bo pogosto naletel na občutljive podatke. Zato sta nujna dosledno prikrivanje in nadzor dostopa. Podatki se smejo razkriti le, kadar so potrebni za izvedbo, dnevnike in sledi pa je treba skrbno obravnavati, da opazljivost ne postane najobčutljivejši del sistema.
Obseg izvajanja. Zmogljiv agent ne sme delovati brez omejitev. V praksi je treba omejiti, kam lahko krmari, do katerih domen lahko dostopa in s katerimi sistemi sme komunicirati. Te omejitve je treba uveljaviti na ravni izvajalnega okolja, ne pa jih prepustiti pravilom v pozivu.
Zaupanje v okolje. Sodobni vmesniki lahko vsebujejo navodila, vsebino ali postopke, ki so zavajajoči ali dejavno sovražni. Vstavljanje zavajajočega poziva prek vsebine strani je resnična površina za napad. Sistem potrebuje jasno hierarhijo navodil, preverjanja veljavnosti in pogoje za ustavitev, da agent ne bi sledil neželenim navodilom.
Spekter avtonomije. Vsa dejanja ne bi smela biti povsem avtonomna. V številnih produkcijskih okoljih je avtonomijo pomembno obravnavati kot spekter. Sistem lahko zelo samostojno raziskuje in izvaja naloge, za nekatere kategorije dejanj pa še vedno zahteva odobritev.
Temeljno načelo je preprosto: večja moč modela zahteva zmogljivejši sistem, ki ga obdaja. Avtonomija brez pravilnikov ni pripravljena za produkcijsko uporabo.
Nehali smo se spraševati: katera dejanja brskalnika naj izpostavimo?
Začeli smo se spraševati: kako lahko modelu zagotovimo celoten prostor dejanj in ga z varnostnimi pravilniki izvajalnega okolja še vedno ohranimo varnega?
Ta novi pogled spremeni naše prednostne naloge. Taksonomije dejanj in popolnost ovojnic so manj pomembne. Pomembnejši so pravilniki izvajalnega okolja, opazljivost in vrednotenje posameznih korakov. Zmogljivost modela in zasnova sistema se ne moreta nadomestiti. Z izboljševanjem modelov postaja delo sistema pomembnejše, ne manj pomembno.
Brskalniški agenti, ki delujejo v predstavitvah, so pogosto uspešni zato, ker je naloga ozka, okolje pa sodeluje. Produkcijski sistemi zahtevajo nekaj drugega: omejeno izvajanje, merljivo vedenje in vrednotenje, ki zna razlikovati med pravilnim in zgolj srečnim rezultatom.
Manj načrtovanja ovojnic. Več sistemskega inženirstva.
Čeprav smo se osredotočili na brskalniške agente, ta pristop nakazuje širši način razmišljanja o uporabi računalnika kot sistemski disciplini.