Mis on arvutikasutus ja miks on see oluline? Arvutikasutus on lihtne, kuid laia mõjuga idee: selle asemel et paluda mudelitel küsimustele vastata, palume neil tarkvara kasutada — veebisaitidel liikuda, vorme täita, töövooge läbida ja ülesandeid algusest lõpuni autonoomselt täita.
See teeb võimalikuks suure hulga päriselulisi ülesandeid, mis on praegu eri liideste vahel killustunud, näiteks terviklikud broneeringud, e-poodide ostuprotsessid, mitmeetapiline reisiplaneerimine ja kontoritöövood, millele pole korralikku API-põhist vastet. Need probleemid pole uued. Uus on võimalus lahendada neid üldotstarbeliste mudelitega.
Anthropicu ja OpenAI hiljutised süsteemid on näidanud agente, kes mitte ainult ei tegutse, vaid arutlevad oleku üle, taastuvad vigadest ning loovad käigu pealt ülesandepõhiseid lahendusi. See muudab brauseri agentide üldiseks täitmiskeskkonnaks, kuid tõstatab kohe disainiküsimuse: kui suure osa sellest keskkonnast peaksime mudelile avama?
Varased süsteemid lahendasid selle, pakkides brauseri kindlaks hulgaks ohututeks eelmääratud toiminguteks. Nagu selles postituses näitame, on see lähenemine jõudmas oma piirideni.
Brauseriagente luues tekib tuttav mõte: mudelit ei tasu liiga palju usaldada.
Seetõttu paneme brauseri ümbrisesse. Anname kasutada eelmääratud tööriistad, nagu click, type, scroll, select ja read_text. Lihtsustame dokumendi objektimudelit (DOM-i). Vähendame võimalike toimingute hulka. Püüame muuta käitumise enda loodud abstraktsioonide kaudu mõistetavaks ja juhitavaks.
See on mõistlik lähtekoht. Üha enam on see aga ka pikas plaanis vale arhitektuur.
Tipptasemel mudelite paranedes pole piirang enam üksnes selles, et mudelil puuduvad tööriistad. Probleem on selles, et sunnime seda töötama abstraktsioonide kaudu, mis eemaldavad alussüsteemist liiga palju teavet. Surume korratu ja dünaamilise keskkonna fikseeritud toiminguliideseks ning palume mudelil sellest teabekaost hoolimata hästi töötada.
See kompromiss muutub üha vähem ahvatlevaks.
Meie uuritavat muutust on lihtne kirjeldada, kuid selle tagajärjed on märkimisväärsed. Selle asemel et käsitleda agenti eelmääratud toimingute valijana, näeme seda piiratud käituskeskkonnas töötava programmisüntesaatorina.
Mudelid on muutunud väga võimekaks ega vaja enam abstraktseid kaitsepiirdeid. Nad vajavad täielikku toiminguruumi, et ülesande lahendus kavandada, täita ja seda täiustada, kuni eesmärk on saavutatud.
See postitus käsitleb üleminekut abstraktsioonirohkelt brauseriautomaatikalt piiratud arvutikasutusele ning seda, mis muutub, kui süsteeme niimoodi kavandada.
Probleem pole selles, et fikseeritud toiminguliidesed oleksid põhimõtteliselt valed. Veeb lihtsalt ei allu neile.
Nüüdisaegsed liidesed põhinevad Reactil, Vue'l ja Angularil ning kasutavad asünkroonseid olekuvärskendusi, sünteetilisi sündmusesüsteeme ja manustatud kolmandate osapoolte vidinaid, mis paiknevad eri päritoluga iframe'ides ning järgivad oma elutsüklit. Ümbris, mis käsib „sisestada teksti sellele sisestusväljale“, toimib ainult siis, kui leht nõustub teie arusaamaga teksti sisestamisest. Paljud lehed ei nõustu. Väärtuse otse määramine läheb sageli raamistiku muudatuste tuvastamisest täielikult mööda. Sisestusväli näib täidetud. Valideerimine ei käivitu. Vorm ei tööta endiselt.
Seda saab paigata. Saate lisada Reacti sisestusväljade erijuhud, käivitada pärast fookust blur-sündmused ja oodata enne oleku lugemist võrgu jõudeolekut. Iga parandus on eraldi võttes õige. Koos kasvavad need süsteemiks, mida on üha raskem hooldada ja mis sobib üha täpsemalt ainult juba nähtud saitidele.
Sügavam probleem on see, et kodeerite abstraktsioonikihti eeldused interaktsioonide toimimise kohta ja avastate seejärel, et veeb lähtub teistsugustest eeldustest.
Võtame näiteks Stripe'i või Adyeni kaudu eri päritoluga iframe'i manustatud maksevormi. Teie ümbris ei pääse sellele otse ligi, sest see asub eraldi päritolus. Tööriist read_text ei näe selle sisemist olekut. Tööriist type ei pääse selle sisestusväljadele ligi. Ümbrisel põhinev agent jõuab siin ummikusse. Abstraktsioon loodi põhidokumendi jaoks. Tegelik ülesanne asub kohas, mida abstraktsioon ei näe.
Sarnane ebakõla ilmneb ka vähem ilmsetes töövoogudes. Raamistiku juhitav rippmenüü ei pruugi otsestele klõpsudele üldse reageerida, sest nähtav element pole tegelik juhtelement. Aluseks oleva olekumuutuse käivitamiseks võib vaja minna klaviatuurisündmuste jada. Väljastpoolt vaadates näib kasutajaliides klõpsatav. Abstraktsioon ütleb „klõpsa“. Midagi ei juhtu.
Või võtame mitmeetapilise modaalakna voo, kus nähtava DOM-i värskendused jäävad sisemistest olekumuutustest maha. Õige järgmine toiming sõltub olekumuutusest, mis ei kajastu veel elementides, mida ümbris näeb. Ümbrisel põhinev agent tegutseb lõpuks liiga vara või loeb aegunud olekut, sest selle vaade süsteemile on puudulik.
Igal juhul peidab abstraktsioon signaalid, mida agent tegelikult vajab.
Madalamal tasandil töötav mudel, mis kontrollib aktiivset DOM-i, arutleb kaadripiiride üle ja sünteesib konkreetse liidese jaoks interaktsioonijada, suudab neis olukordades toime tulla. Asi pole selles, et mudel oleks loomu poolest nutikam. Tal on lihtsalt juurdepääs teabele, mis varem eemaldati.
Meie sihitud muutust on lihtne kirjeldada: selle asemel et paluda mudelil valida eelmääratud toimingute seast, anname talle madalama tasandi täitmispinna ja piirame seda abstraktsioonidisaini asemel käitusreeglitega.
See disainivalik tuleneb valdkonna laiemast muutusest, mis hakkab eelistama madalama tasandi primitiivseid tööriistu. Need rakendavad agendi loomupärast võimet end käitusajal parandada ja kvaliteetset koodi luua, selle asemel et kasutada kindlaid sissekodeeritud tööriistu, mis on küll töökindlad, kuid vähendavad mudeli kohanemisvõimet eri keskkondadega.
Mõelgem Claude Code'i edule paljude arendajate ühe põhitööriistana ja valdkonna laiemale liikumisele terminalipõhiste agentide suunas. Claude Code'i suurim eelis pole mudel ise, vaid madalama tasandi täitmiskeskkond. Kui anda mudelile vähem, kuid modulaarsemaid ja madalama tasandi tööriistu — näiteks terminal —, kasutab see tööriistu paremini. Peamine põhjus on see, et agent saab arutleda ja luua käsiloleva ülesande jaoks kohandatud skripte, selle asemel et püüda kasutada üldistatud tööriistu, mis risustavad kontekstivaadet.
Brauseriautomaatika puhul tähendab see praktikas, et mudel saab otse kontrollida lehe aktiivset olekut, liikuda kaadrite vahel ja luua praeguse liidese jaoks kohandatud interaktsioonikoodi, selle asemel et sobitada kõik toimingud eelvalmistatud toimingute fikseeritud hulka.
Mudel käitub vähem valija ja rohkem käitusaja lahenduse autorina. See uurib praegust olekut, arutleb liidese üle ja sünteesib konkreetse olukorra jaoks interaktsiooniloogika. See suudab koostada mitmeetapilisi jadasid, kohaneda ebatavaliste voogudega ja tulemusi enne jätkamist valideerida. Kui toiming nurjub, näeb mudel aluseks olevat viga ja parandab end ise. See on võimekam ja riskantsem, kuid vastab palju paremini probleemi tegelikule olemusele.
Oluline on see, et abstraktsioonikihi eemaldamine ei muuda süsteemi vähem distsiplineerituks. Distsipliin lihtsalt kolib mujale.
Varem ümbrise disainis ja erandite käsitlemises tehtud töö liigub kolme kohta: viipa, millest saab omamoodi töökorralduslik väljaõpe; käituskeskkonda, mis jõustab selliseid piire nagu liikumisulatus, tundlikud toimingud ja korduskatsete käitumine; ning hindamiskihti, mis hindab peale ülesande õnnestumise ka vaheetappide õigsust. Vähem hapraid abstraktsioone. Tugevamad ümbritsevad süsteemid.
Selle muutuse üks tulemus on sageli lihtsam tootekood, kuigi süsteem tervikuna muutub võimekamaks. Selle asemel et kodeerida interaktsioonimustreid korduskasutatavate ümbristena, sünteesib agent käitumise käitusajal. Üha kasvava hulga eritööriistade ja erandloogika asemel haldate väikest hulka võimekaid primitiive ning piiratud täitmiskeskkonda.
See muudab ka süsteemi üldistusvõimet. Ümbristel põhinev agent üldistab hästi ülesannetele, mis sarnanevad juba loodud ümbristega. Piiratud käituskeskkonnas tegutsev agent üldistab ülesannetele, millel on ühine täitmisalus, isegi kui nähtav liides on erinev.
Näiteks võivad otsinguvormi, broneerimisvoo või seadete lehega suhtlemine kasutajaliidese tasandil täiesti erinevad välja näha. Ent nende aluseks on ühised mustrid: oleku lugemine, sündmuste käivitamine, tulemuste valideerimine ja asünkroonsete värskenduste käsitlemine. Sellel tasandil töötava süsteemi oskused kanduvad loomulikumalt ühelt ülesandelt teisele.
Korduskasutatav komponent ei ole toimingute loend, vaid mudeli võime olekut kontrollida, ohutult tegutseda ja tulemusi kinnitada.
Selle töö selgeim õppetund on, et töökindlus ei tulene mudelile rohkemate abifunktsioonide andmisest. Sageli tuleb see hoopis väiksemast hulgast võimekamatest primitiividest, mida piiratakse õigel viisil. Liigne abistamine kinnistab eeldused selle kohta, kuidas ülesannet tuleks täita. Piirangud määravad ohutu tegutsemisruumi ja võimaldavad mudelil leida paremaid kohalikke lahendusi.
Võimekam täitmispind eeldab ka rangemat ohutusmudelit. Kui agent ei piirdu enam väikese hulga eelmääratud toimingutega, tegutseb ta sisuliselt otse päris tarkvaras. See muudab kohe riskiprofiili.
Arvestada tuleb nelja valdkonnaga:
Andmete paljastumine. Kui agent suhtleb päris liidestega, puutub ta sageli kokku tundliku teabega. See nõuab läbimõeldud maskimist ja juurdepääsukontrolli. Andmeid tuleks avaldada ainult siis, kui neid on täitmiseks vaja, ning logisid ja jälgi tuleb hoolikalt käsitleda, et jälgitavusest ei saaks süsteemi kõige tundlikum osa.
Täitmise ulatus. Võimekas agent ei tohiks saada tegutseda suvaliselt. Praktikas tähendab see piiranguid sellele, kuhu ta saab liikuda, millistele domeenidele ligi pääseda ja milliste süsteemidega suhelda. Neid piiranguid tuleb jõustada käituskeskkonna tasandil, mitte jätta viibas kirjeldatud tavade hooleks.
Keskkonna usaldusväärsus. Nüüdisaegsed liidesed võivad sisaldada eksitavaid või otseselt vaenulikke juhiseid, sisu ja vooge. Lehe sisu kaudu toimuv viipade süstimine on tegelik ründevektor. Süsteem vajab selget juhiste hierarhiat, valideerimiskontrolle ja lõpetamistingimusi, et agent ei järgiks soovimatuid suuniseid.
Autonoomsuse skaala. Kõik toimingud ei peaks olema täielikult autonoomsed. Paljudes tootmiskeskkondades on tähtis käsitleda autonoomsust skaalana. Süsteem võib uurida ja tegutseda väga agendipõhiselt, nõudes samal ajal teatud liiki toiminguteks heakskiitu.
Aluspõhimõte on lihtne: mudelile suurema võimekuse andmine nõuab seda ümbritseva süsteemi tugevdamist. Reegliteta autonoomsus pole tootmisküps.
Me ei küsinud enam: millised brauseritoimingud peaksime kättesaadavaks tegema?
Hakkasime küsima: kuidas anda mudelile täielik toiminguruum ja kehtestada selle ümber käitusreeglid, mis tagavad siiski ohutuse?
See vaatenurk muudab prioriteete. Toimingute taksonoomiad ja ümbriste terviklikkus muutuvad vähem oluliseks. Käitusreeglid, jälgitavus ja iga sammu hindamine muutuvad olulisemaks. Mudeli võimekus ja süsteemidisain ei asenda teineteist. Mudelite paranedes muutub süsteemi roll olulisemaks, mitte vähem oluliseks.
Demodes toimivad brauseriagendid õnnestuvad sageli seetõttu, et ülesanne on kitsas ja keskkond koostööaldis. Tootmissüsteemid vajavad midagi muud: piiratud täitmist, seiratud käitumist ja hindamist, mis suudab eristada õiget tulemust juhuslikust õnnestumisest.
Vähem ümbriste disaini. Rohkem süsteemiinseneeriat.
Kuigi keskendusime brauseriagentidele, osutab see laiemale käsitlusele, milles arvutikasutus on süsteemiinseneeria valdkond.