Kas yra kompiuterio valdymas ir kodėl jis svarbus? Kompiuterio valdymas – paprasta, bet didelę reikšmę turinti idėja: užuot prašę modelių atsakyti į klausimus, prašome jų valdyti programinę įrangą – naršyti svetaines, pildyti formas, atlikti procesų veiksmus ir savarankiškai įvykdyti užduotis nuo pradžios iki pabaigos.
Tai suteikia galimybę atlikti daug realių užduočių, kurios šiuo metu suskaidytos tarp skirtingų sąsajų: nuo viso užsakymo proceso, atsiskaitymo el. parduotuvėje ir kelių etapų kelionės planavimo iki vidinių administravimo procesų, neturinčių tinkamo API atitikmens. Šios problemos nėra naujos. Nauja tai, kad jas jau įmanoma spręsti bendrosios paskirties modeliais.
Naujausios „Anthropic“ ir OpenAI sistemos parodė, kad agentai gali ne tik veikti, bet ir samprotauti apie būseną, atsitaisyti po klaidų bei realiuoju laiku kurti konkrečiai užduočiai skirtus sprendimus. Taip naršyklė tampa universalia agentų vykdymo aplinka, tačiau iškart kyla projektavimo klausimas: kokią šios aplinkos dalį turėtume atverti modeliui?
Ankstyvosiose sistemose naršyklė buvo apgaubiama fiksuotu saugių, iš anksto nustatytų veiksmų rinkiniu. Kaip pagrįsime šiame straipsnyje, šis metodas jau artėja prie savo galimybių ribos.
Kuriant naršyklės agentus dažnai vadovaujamasi įprasta nuostata: pernelyg nepasitikėti modeliu.
Todėl naršyklę apgaubiame abstrakcijos sluoksniu. Suteikiame iš anksto nustatytus įrankius, tokius kaip click, type, scroll, select ir read_text. Supaprastiname dokumento objektinį modelį (DOM). Sumažiname galimų veiksmų erdvę. Savo sukurtomis abstrakcijomis stengiamės padaryti veikseną suprantamą ir valdomą.
Tai pagrįstas pradinis sprendimas. Tačiau ilgalaikėje perspektyvoje tai vis dažniau yra netinkama architektūra.
Tobulėjant priešakiniams modeliams, problema nebėra vien tai, kad modeliui trūksta įrankių. Problema ta, kad verčiame jį veikti per abstrakcijas, kurios pašalina pernelyg daug bazinės sistemos informacijos. Sudėtingą ir dinamišką aplinką sutraukiame į fiksuotą veiksmų sąsają, o tada prašome modelio gerai veikti nepaisant prarastos informacijos.
Toks kompromisas tampa vis mažiau patrauklus.
Mūsų nagrinėjamą pokytį lengva apibūdinti, tačiau jo pasekmės reikšmingos. Užuot laikę agentą iš anksto nustatytų veiksmų parinkikliu, laikome jį programų kūrėju, veikiančiu ribojamoje vykdymo aplinkoje.
Modeliai tapo išties pajėgūs, todėl jiems nebereikia abstrakčių jūsų apsaugos priemonių – jiems reikia visos veiksmų erdvės, kad galėtų suplanuoti ir įvykdyti užduotį, ją tobulinti ir galiausiai pasiekti tikslą.
Šiame straipsnyje aptariamas perėjimas nuo abstrakcijomis apkrauto naršyklės automatizavimo prie ribojamo kompiuterio valdymo ir tai, kas pasikeičia taip projektuojant sistemas.
Problema nėra ta, kad fiksuotos veiksmų sąsajos iš esmės netinkamos. Problema ta, kad saitynas prie jų neprisitaiko.
Šiuolaikinės sąsajos kuriamos naudojant „React“, „Vue“ ir „Angular“, jose vyksta asinchroniniai būsenos naujinimai, naudojamos sintetinės įvykių sistemos ir įterptieji trečiųjų šalių valdikliai, veikiantys kitos kilmės iframe elementuose ir turintys savo gyvavimo ciklus. Apvalkalas, nurodantis „įvesti tekstą į šį lauką“, veikia tinkamai tik tada, jei puslapio įvesties samprata sutampa su jūsų. Daugelyje puslapių taip nėra. Tiesiogiai nustačius reikšmę dažnai visiškai apeinamas sistemos pakeitimų aptikimo mechanizmas. Atrodo, kad įvesties laukas užpildytas. Tikrinimas taip ir nepradedamas. Forma lieka neveikianti.
Tai galima pataisyti. Galima pridėti specialių „React“ įvesties laukų atvejų, po fokusavimo siųsti blur įvykius, o prieš nuskaitant būseną palaukti, kol tinkle nebeliks aktyvumo. Kiekviena tokia pataisa konkrečiu atveju yra tinkama. Tačiau visos kartu jos sukuria sistemą, kurią vis sunkiau prižiūrėti ir kuri vis labiau pritaikyta tik jau matytoms svetainėms.
Gilesnė problema ta, kad abstrakcijos sluoksnyje įtvirtinate prielaidas apie tai, kaip turėtų veikti sąveika, o tada paaiškėja, jog saitynas remiasi kitomis prielaidomis.
Panagrinėkime mokėjimo formą, įterptą per „Stripe“ arba „Adyen“ į kitos kilmės iframe elementą. Jūsų apvalkalas negali jos tiesiogiai pasiekti, nes ji yra kitos kilmės srityje. Jūsų įrankis read_text negali stebėti jos vidinės būsenos. Jūsų įrankis type negali pasiekti jos įvesties laukų. Apvalkalais pagrįstas agentas čia atsitrenkia į sieną. Abstrakcija buvo sukurta pagrindiniam dokumentui. O tikroji užduotis yra ten, kur abstrakcija jos nemato.
Panaši neatitiktis pasireiškia ir ne tokiuose akivaizdžiuose procesuose. Programavimo sistemos valdomas išskleidžiamasis sąrašas gali visiškai nereaguoti į tiesioginius spustelėjimus, nes matomas elementas nėra tikrasis valdiklis. Bazinei būsenos kaitai suaktyvinti gali reikėti klaviatūros įvykių sekos. Iš išorės atrodo, kad naudotojo sąsajos elementą galima spustelėti. Abstrakcija nurodo „spustelėti“. Nieko neįvyksta.
Arba įsivaizduokite kelių etapų modalinį procesą, kuriame matomo DOM naujiniai atsilieka nuo vidinės būsenos pokyčių. Tinkamas kitas veiksmas priklauso nuo būsenos pokyčio, kuris dar neatsispindi apvalkalui matomuose elementuose. Apvalkalais pagrįstas agentas galiausiai veikia per anksti arba nuskaito pasenusią būseną, nes remiasi neišsamiu sistemos vaizdu.
Kiekvienu atveju abstrakcija paslepia signalus, kurių agentui iš tikrųjų reikia.
Žemesniu lygmeniu veikiantis modelis, kuris tikrina aktyvų DOM, analizuoja kadrų ribas ir kuria konkrečiai sąsajai skirtą sąveikos seką, gali įveikti tokias situacijas. Modelis savaime nėra išmanesnis. Jis tiesiog turi prieigą prie anksčiau pašalintos informacijos.
Pokytį, kurio siekiame, apibūdinti paprasta: užuot prašę modelio rinktis iš iš anksto nustatytų veiksmų, suteikiame jam žemesnio lygmens vykdymo sąsają ir ribojame ją vykdymo taisyklėmis, o ne abstrakcijos konstrukcija.
Šį projektavimo sprendimą paskatino platesnis pokytis sektoriuje: vis dažniau pirmenybė teikiama žemesnio lygmens baziniams įrankiams, kurie išnaudoja įgimtą agento gebėjimą vykdymo metu taisyti veiksmus ir kurti kokybišką kodą, o ne patikimiems, bet griežtai užkoduotiems specializuotiems įrankiams, ribojantiems modelio gebėjimą prisitaikyti prie skirtingų aplinkų.
Tai rodo „Claude Code“, tapusio vienu pagrindinių daugelio programuotojų įrankių, sėkmė ir platesnis sektoriaus posūkis terminaluose veikiančių agentų link. Didžiausias „Claude Code“ pranašumas yra ne pats modelis, o žemesnio lygmens infrastruktūra. Suteikiant modeliui mažiau, tačiau modularesnių ir žemesnio lygmens įrankių, t. y. terminalą, įrankiai iškviečiami tiksliau. Taip yra daugiausia todėl, kad agentas gali samprotauti ir kurti konkrečiai užduočiai pritaikytus scenarijus, užuot bandęs naudoti apibendrintus įrankius, kurie teršia konteksto langą.
Naršyklės automatizavimo atveju tai reiškia, kad modelis gali tiesiogiai tikrinti aktyvią puslapio būseną, pereiti tarp kadrų ir kurti konkrečiai dabartinei sąsajai pritaikytą sąveikos kodą, užuot viską siejęs su fiksuotu iš anksto sukurtų veiksmų rinkiniu.
Modelis veikia ne tiek kaip parinkiklis, kiek kaip vykdymo logikos autorius. Jis patikrina dabartinę būseną, analizuoja sąsają ir sukuria konkrečiai situacijai skirtą sąveikos logiką. Jis gali kurti kelių etapų sekas, prisitaikyti prie neįprastų procesų ir prieš tęsdamas patikrinti rezultatus. Veiksmui nepavykus, modelis mato bazinę klaidą ir pats pasitaiso. Tai galingesnis ir rizikingesnis metodas, tačiau jis daug geriau atitinka tikrąjį problemos pobūdį.
Svarbu tai, kad pašalinus abstrakcijos sluoksnį sistema netampa mažiau kontroliuojama. Kontrolė tiesiog perkeliama kitur.
Anksčiau apvalkalų projektavimui ir išimtinių atvejų tvarkymui tekęs darbas perkeliamas į tris sritis: užklausą, kuri tampa tam tikru praktiniu mokymu; vykdymo aplinką, užtikrinančią tokias ribas kaip naršymo apimtis, neskelbtini veiksmai ir pakartotinių bandymų tvarka; ir vertinimo sluoksnį, kuris tikrina ne tik tai, ar užduotis atlikta, bet ir ar tarpiniai veiksmai buvo tinkami. Mažiau trapių abstrakcijų. Stipresnės pagalbinės sistemos.
Vienas šio pokyčio rezultatų – produkto kodas dažnai tampa paprastesnis, nors visa sistema įgyja daugiau galimybių. Užuot sąveikos modelius kodavęs kaip daugkartinius apvalkalus, agentas veikseną sukuria vykdymo metu. Užuot plėtę specializuotų įrankių ir išimtinių atvejų logikos rinkinį, prižiūrite nedidelį galingų bazinių operacijų rinkinį ir ribojamą vykdymo aplinką.
Dėl to keičiasi ir sistemos gebėjimas apibendrinti. Apvalkalais pagrįstas agentas gerai apibendrina užduotis, panašias į tas, kurioms jau sukūrėte apvalkalus. Ribojamoje vykdymo aplinkoje veikiantis agentas gali apibendrinti užduotis, turinčias bendrą vykdymo pagrindą, net jei jų matoma sąsaja skiriasi.
Pavyzdžiui, sąveika su paieškos forma, užsakymo procesu ar nustatymų puslapiu naudotojo sąsajos lygmeniu gali atrodyti visiškai skirtingai. Tačiau giliau kartojasi tie patys modeliai: būsenos nuskaitymas, įvykių inicijavimas, rezultatų tikrinimas ir asinchroninių naujinių apdorojimas. Šiuo lygmeniu veikianti sistema lengviau pritaiko įgūdžius skirtingoms užduotims.
Daugkartinis komponentas yra ne veiksmų sąrašas, o modelio gebėjimas patikrinti būseną, saugiai veikti ir patvirtinti rezultatus.
Aiškiausia šio darbo pamoka – patikimumą užtikrina ne didesnis modeliui suteiktų pagalbinių funkcijų skaičius. Dažnai patikimumą lemia mažiau, bet galingesnių bazinių operacijų ir tinkamai nustatyti jų apribojimai. Perteklinė pagalba kode įtvirtina prielaidas, kaip turi būti atliekama užduotis. Apribojimai nustato saugias veikimo ribas ir leidžia modeliui rasti geresnius konkrečiai situacijai pritaikytus sprendimus.
Galingesnei vykdymo sąsajai reikia ir griežtesnio saugos modelio. Kai agentas nebėra apribotas nedideliu iš anksto nustatytų veiksmų rinkiniu, jis iš esmės tiesiogiai valdo tikrą programinę įrangą. Tai iškart pakeičia rizikos pobūdį.
Projektuojant reikia atsižvelgti į keturis aspektus:
Duomenų atskleidimas. Sąveikaudamas su tikromis sąsajomis agentas dažnai susidurs su neskelbtina informacija. Todėl būtina nuosekliai taikyti maskavimą ir prieigos kontrolę. Duomenys turėtų būti atskleidžiami tik tada, kai jų reikia užduočiai vykdyti, o žurnalus ir sekimo duomenis būtina tvarkyti atsargiai, kad stebimumo sistema netaptų jautriausia visos sistemos dalimi.
Vykdymo apimtis. Galingam agentui negalima leisti veikti bet kur ir bet kaip. Praktiškai tai reiškia, kad reikia riboti, kur jis gali naršyti, kokius domenus pasiekti ir su kokiomis sistemomis sąveikauti. Šie apribojimai turi būti užtikrinami vykdymo aplinkoje, o ne paliekami kaip užklausų rengimo susitarimai.
Aplinkos patikimumas. Šiuolaikinėse sąsajose gali būti klaidinančių ar net sąmoningai priešiškų nurodymų, turinio ir procesų. Užklausos įterpimas per puslapio turinį yra reali atakų galimybė. Kad agentas nevykdytų nenumatytų nurodymų, sistemai reikia aiškios instrukcijų hierarchijos, patikros veiksmų ir nutraukimo sąlygų.
Autonomijos spektras. Ne visi veiksmai turėtų būti visiškai autonomiški. Daugelyje realiai naudojamų sistemų autonomiją svarbu vertinti kaip spektrą. Sistema gali labai savarankiškai tyrinėti ir vykdyti užduotis, bet tam tikrų kategorijų veiksmams vis tiek reikalauti patvirtinimo.
Pagrindinis principas paprastas: suteikiant modeliui daugiau galios, būtina stiprinti jį supančią sistemą. Autonomija be taisyklių dar netinka realiam naudojimui.
Nustojome klausti: kokius naršyklės veiksmus turėtume suteikti?
Pradėjome klausti: kaip suteikti modeliui visą veiksmų erdvę ir kartu nustatyti tokias vykdymo taisykles, kad ji išliktų saugi?
Toks požiūris pakeičia prioritetus. Veiksmų klasifikacija ir apvalkalų išsamumas tampa ne tokie svarbūs. Didesnę reikšmę įgyja vykdymo taisyklės, stebimumas ir kiekvieno žingsnio vertinimas. Modelio galimybės ir sistemos projektavimas vienas kito nepakeičia. Modeliams tobulėjant, sistemos atliekamas darbas tampa ne mažiau, o labiau svarbus.
Demonstracijose veikiantiems naršyklės agentams dažnai pavyksta todėl, kad užduotis yra siaura, o aplinka palanki. Realiai naudojamoms sistemoms reikia ko kita: ribojamo vykdymo, stebimos veiksenos ir vertinimo, galinčio atskirti teisingą rezultatą nuo paprasčiausiai sėkmingo atsitiktinumo.
Mažiau apvalkalų projektavimo. Daugiau sistemų inžinerijos.
Nors daugiausia dėmesio skyrėme naršyklės agentams, tai atveria platesnį požiūrį į kompiuterio valdymą kaip sistemų inžinerijos discipliną.