Çfarë është përdorimi i kompjuterit dhe pse ka rëndësi? Përdorimi i kompjuterit është një ide e thjeshtë me ndikim të gjerë: në vend që t'u kërkojmë modeleve t'u përgjigjen pyetjeve, u kërkojmë të përdorin softuer—të lundrojnë në sajte, të plotësojnë formularë, të kalojnë nëpër procese dhe t'i përfundojnë detyrat nga fillimi në fund, në mënyrë autonome.
Kjo mundëson një kategori të gjerë detyrash nga bota reale, të cilat aktualisht janë të copëzuara nëpër ndërfaqe, si rezervimet nga fillimi në fund, përfundimi i blerjeve elektronike, planifikimi shumëhapësh i udhëtimeve dhe proceset administrative pa një ekuivalent të mirëfilltë API-je. Këto nuk janë probleme të reja. E re është mundësia për t'i zgjidhur me modele për përdorim të përgjithshëm.
Sistemet e fundit nga Anthropic dhe OpenAI kanë demonstruar agjentë që jo vetëm veprojnë, por edhe arsyetojnë për gjendjen, rikuperohen nga gabimet dhe ndërtojnë aty për aty zgjidhje specifike për detyrën. Kjo e kthen shfletuesin në një mjedis të përgjithshëm ekzekutimi për agjentët, por ngre menjëherë një pyetje projektimi: sa nga ky mjedis duhet t'ia ekspozojmë modelit?
Sistemet e hershme u përgjigjën duke e mbështjellë shfletuesin me një grup të pandryshueshëm veprimesh të sigurta e të paracaktuara. Siç do të argumentojmë në këtë artikull, kjo qasje po arrin kufijtë e saj.
Kur ndërtojmë agjentë për shfletues, kemi një prirje të njohur: të mos i besojmë tepër modelit.
Prandaj e mbështjellim shfletuesin. Ekspozojmë mjete të paracaktuara si click, type, scroll, select dhe read_text. Thjeshtojmë Modelin e Objekteve të Dokumentit (DOM). Zvogëlojmë hapësirën e veprimeve. Përpiqemi ta bëjmë sjelljen të kuptueshme dhe të kontrollueshme përmes abstraksioneve që projektojmë.
Kjo është një pikënisje e arsyeshme. Por gjithnjë e më shumë po bëhet edhe arkitektura e gabuar afatgjatë.
Ndërsa modelet avangardë përmirësohen, kufizimi nuk është më vetëm mungesa e mjeteve për modelin. Kufizimi është se po e detyrojmë të veprojë përmes abstraksioneve që heqin një pjesë tepër të madhe të sistemit bazë. Ne ngjeshim një mjedis të çrregullt e dinamik në një ndërfaqe të pandryshueshme veprimesh dhe më pas i kërkojmë modelit të funksionojë mirë pavarësisht kësaj humbjeje informacioni.
Ky kompromis po bëhet më pak tërheqës.
Ndryshimi që kemi shqyrtuar përshkruhet lehtë, por ka pasoja të rëndësishme. Në vend që ta trajtojmë agjentin si përzgjedhës veprimesh të paracaktuara, e trajtojmë si sintetizues programesh që vepron brenda një mjedisi ekzekutimi të kufizuar.
Modelet janë bërë vërtet të afta dhe nuk kanë më nevojë për kufizimet tuaja abstrakte—u duhet hapësira e plotë e veprimeve që ta projektojnë, ekzekutojnë dhe përmirësojnë detyrën derisa të arrijnë objektivin.
Ky artikull trajton këtë kalim, nga automatizimi i shfletuesit i mbështetur shumë në abstraksione te përdorimi i kufizuar i kompjuterit, si dhe çfarë ndryshon kur sistemet projektohen në këtë mënyrë.
Problemi nuk është se ndërfaqet me veprime të pandryshueshme janë konceptualisht të gabuara. Problemi është se uebi nuk bashkëpunon me to.
Ndërfaqet moderne ndërtohen me React, Vue dhe Angular, me përditësime asinkrone të gjendjes, sisteme ngjarjesh sintetike dhe miniaplikacione të integruara nga palë të treta, që qëndrojnë në iframe me origjinë të ndryshme dhe kanë ciklet e veta të jetës. Një shtresë mbështjellëse që thotë «shkruaj në këtë fushë» është e saktë vetëm nëse faqja pajtohet me përkufizimin tuaj të të shkruarit. Shumë faqe nuk pajtohen. Caktimi i drejtpërdrejtë i një vlere shpesh e anashkalon plotësisht zbulimin e ndryshimeve nga platforma. Fusha duket e plotësuar. Vërtetimi nuk aktivizohet kurrë. Formulari mbetet jofunksional.
Këtë mund ta arnoni. Mund të shtoni raste të veçanta për fushat e React-it, të dërgoni ngjarje blur pas fokusimit dhe të prisni qetësimin e rrjetit para se të lexoni gjendjen. Çdo arnim është i saktë për rastin konkret. Së bashku, ato grumbullohen në një sistem që bëhet gjithnjë e më i vështirë për t'u mirëmbajtur dhe gjithnjë e më specifik për sajtet që keni hasur tashmë.
Problemi më i thellë është se po kodoni në shtresën e abstraksionit supozime për mënyrën se si duhet të funksionojnë ndërveprimet, për të zbuluar më pas se uebi bazohet në supozime të tjera.
Merrni si shembull një formular pagese të integruar përmes Stripe ose Adyen brenda një iframe-i me origjinë të ndryshme. Shtresa juaj mbështjellëse nuk mund ta arrijë drejtpërdrejt, sepse ai ndodhet në një origjinë të veçantë. Mjeti juaj read_text nuk mund ta vëzhgojë gjendjen e tij të brendshme. Mjeti juaj type nuk mund t'u drejtohet fushave të tij. Një agjent i bazuar në shtresa mbështjellëse ngec këtu. Abstraksioni ishte projektuar për dokumentin kryesor. Detyra e vërtetë ndodhet diku ku abstraksioni nuk mund të shohë.
Një mospërputhje e ngjashme shfaqet edhe në procese më pak të dukshme. Një listë me lëshim e kontrolluar nga platforma mund të mos reagojë fare ndaj klikimeve të drejtpërdrejta, sepse elementi i dukshëm nuk është kontrolli i vërtetë. Mund të kërkojë një varg ngjarjesh të tastierës për të aktivizuar kalimin bazë të gjendjes. Nga jashtë, ndërfaqja duket sikur mund të klikohet. Abstraksioni thotë «kliko». Asgjë nuk ndodh.
Ose merrni një proces modal me shumë hapa, ku përditësimet e DOM-it të dukshëm mbeten prapa ndryshimeve të gjendjes së brendshme. Veprimi i saktë pasues varet nga një kalim gjendjeje që ende nuk pasqyrohet në elementet që mund të shohë shtresa juaj mbështjellëse. Një agjent i bazuar në shtresa mbështjellëse përfundon duke vepruar tepër herët ose duke lexuar një gjendje të vjetruar, sepse mbështetet në një pamje jo të plotë të sistemit.
Në secilin rast, abstraksioni fsheh sinjalet që i nevojiten vërtet agjentit.
Një model që vepron në nivel më të ulët—duke inspektuar DOM-in aktiv, duke arsyetuar për kufijtë e kornizave dhe duke sintetizuar vargun e ndërveprimeve për atë sipërfaqe specifike—mund t'i përballojë këto situata. Nuk është se modeli është vetvetiu më inteligjent. Arsyeja është se ai ka qasje në informacionin që ishte hequr.
Ndryshimi drejt të cilit kemi punuar përshkruhet thjesht: në vend që t'i kërkojmë modelit të zgjedhë ndërmjet veprimeve të paracaktuara, i japim një sipërfaqe ekzekutimi të nivelit më të ulët dhe e kufizojmë përmes politikave të ekzekutimit, jo përmes projektimit të abstraksioneve.
Kjo zgjedhje projektimi buron nga një ndryshim më i gjerë në industri, që po fillon të favorizojë mjete primitive të nivelit më të ulët—mjete që shfrytëzojnë aftësinë e lindur të agjentit për korrigjim gjatë ekzekutimit dhe krijim kodi cilësor, në vend të mjeteve specifike të ngulitura në kod, të cilat janë të qëndrueshme, por ia heqin modelit aftësinë për t'u përshtatur me mjedise të ndryshme.
Merrni si shembull suksesin e Claude Code si zgjedhje kryesore në arsenalin e shumë zhvilluesve dhe kalimin më të gjerë të industrisë drejt agjentëve të bazuar në terminal. Avantazhi më i madh i Claude Code nuk është vetë modeli, por struktura e nivelit më të ulët. Dhënia e më pak mjeteve modelit, por më modulare dhe të nivelit më të ulët—pra, terminali—sjell performancë më të mirë në thirrjen e mjeteve, kryesisht sepse agjenti mund të arsyetojë dhe të krijojë skripte të posaçme për detyrën konkrete, në vend që të përpiqet të përdorë mjete të përgjithësuara që mbingarkojnë dritaren e kontekstit.
Në praktikë, për automatizimin e shfletuesit, kjo do të thotë se modeli mund të inspektojë drejtpërdrejt gjendjen aktive të faqes, të përshkojë kornizat dhe të ndërtojë kod të posaçëm ndërveprimi për ndërfaqen aktuale, në vend që gjithçka ta përkthejë në një grup të pandryshueshëm veprimesh të gatshme.
Modeli sillet më pak si përzgjedhës dhe më shumë si autor gjatë ekzekutimit. Ai inspekton gjendjen aktuale, arsyeton për ndërfaqen dhe sintetizon logjikën e ndërveprimit për atë situatë specifike. Mund të ndërtojë vargje me shumë hapa, të përshtatet me procese të pazakonta dhe të vërtetojë rezultatet para se të vazhdojë. Kur një veprim dështon, modeli sheh gabimin bazë dhe vetëkorrigjohet. Kjo është më e fuqishme dhe më e rrezikshme—por përkon shumë më mirë me natyrën e vërtetë të problemit.
Është e rëndësishme që heqja e shtresës së abstraksionit nuk e bën sistemin më pak të disiplinuar. Ajo thjesht e zhvendos disiplinën.
Puna që më parë bëhej në projektimin e shtresës mbështjellëse dhe trajtimin e rasteve skajore zhvendoset në tri vende: te kërkesa (që bëhet një formë trajnimi operacional), te mjedisi i ekzekutimit (që zbaton kufij si fusha e lundrimit, veprimet sensitive dhe sjellja gjatë riprovimit) dhe te shtresa e vlerësimit (që vlerëson jo vetëm nëse detyra u krye me sukses, por edhe nëse hapat e ndërmjetëm ishin të saktë). Më pak abstraksione të brishta. Sisteme më të fuqishme përreth.
Një rezultat i këtij ndryshimi është se kodi i produktit shpesh bëhet më i thjeshtë, edhe pse sistemi në tërësi bëhet më i aftë. Në vend që modelet e ndërveprimit të kodohen si shtresa mbështjellëse të ripërdorshme, agjenti e sintetizon sjelljen gjatë ekzekutimit. Ju mirëmbani një grup të vogël primitivësh të fuqishëm dhe një mjedis ekzekutimi të kufizuar, në vend të një game në zgjerim mjetesh të specializuara dhe logjike për rastet skajore.
Kjo ndryshon edhe mënyrën se si përgjithëson sistemi. Një agjent i bazuar në shtresa mbështjellëse përgjithëson mirë për detyra që u ngjajnë shtresave që keni ndërtuar tashmë. Një agjent me mjedis ekzekutimi të kufizuar përgjithëson për detyra që ndajnë të njëjtën bazë ekzekutimi, edhe kur ndërfaqja e dukshme është e ndryshme.
Për shembull, ndërveprimi me një formular kërkimi, një proces rezervimi ose një faqe cilësimesh mund të duket krejtësisht i ndryshëm në nivelin e ndërfaqes së përdoruesit. Por në themel ato ndajnë të njëjtat modele: leximin e gjendjes, aktivizimin e ngjarjeve, vërtetimin e rezultateve dhe trajtimin e përditësimeve asinkrone. Një sistem që vepron në atë nivel përshtatet më natyrshëm me detyra të ndryshme.
Komponenti i ripërdorshëm nuk është lista e veprimeve. Është aftësia e modelit për të inspektuar gjendjen, për të vepruar në mënyrë të sigurt dhe për të verifikuar rezultatet.
Mësimi më i qartë nga kjo punë është se besueshmëria nuk vjen duke i dhënë modelit më shumë funksione ndihmëse. Shpesh ajo vjen duke i dhënë më pak primitivë, por më të fuqishëm, dhe duke i kufizuar ata në mënyrat e duhura. Ndihma e tepërt ngulit në kod supozime se si duhet kryer një detyrë. Kufizimet përcaktojnë caqe të sigurta veprimi dhe i mundësojnë modelit të zbulojë zgjidhje më të mira për situatën konkrete.
Një sipërfaqe ekzekutimi më e fuqishme kërkon edhe një model sigurie më të rreptë. Pasi agjenti nuk kufizohet më në një grup të vogël veprimesh të paracaktuara, ai në thelb vepron drejtpërdrejt mbi softuer real. Kjo e ndryshon menjëherë profilin e rrezikut.
Gjatë projektimit duhen marrë parasysh katër çështje:
Ekspozimi i të dhënave. Nëse agjenti ndërvepron me ndërfaqe reale, ai do të hasë shpesh informacione sensitive. Kjo kërkon një qasje të disiplinuar ndaj maskimit dhe kontrollit të qasjes. Të dhënat duhet të zbulohen vetëm kur janë të nevojshme për ekzekutimin, ndërsa regjistrat dhe gjurmët duhen trajtuar me kujdes, që vëzhgueshmëria të mos bëhet pjesa më sensitive e sistemit.
Fusha e ekzekutimit. Një agjent i fuqishëm nuk duhet të jetë në gjendje të veprojë pa kufizime. Në praktikë, kjo nënkupton kufizimin e vendeve ku mund të lundrojë, domeneve ku mund të ketë qasje dhe sistemeve me të cilat lejohet të ndërveprojë. Këto kufizime duhet të zbatohen në nivelin e mjedisit të ekzekutimit, jo të lihen si konvencione në formulimin e kërkesave.
Besueshmëria e mjedisit. Ndërfaqet moderne mund të përmbajnë udhëzime, përmbajtje ose procese që janë mashtruese apo qëllimisht armiqësore. Injektimi i kërkesave përmes përmbajtjes së faqes përbën një sipërfaqe reale sulmi. Sistemit i nevojiten një hierarki e qartë udhëzimesh, kontrolle vërtetimi dhe kushte përfundimi, për të mos e lejuar agjentin të ndjekë udhëzime të paqëllimshme.
Spektri i autonomisë. Jo të gjitha veprimet duhet të jenë plotësisht autonome. Në shumë mjedise prodhimi është e rëndësishme që autonomia të trajtohet si spektër. Sistemi mund të jetë shumë agjentik në mënyrën se si eksploron dhe ekzekuton, por të kërkojë përsëri miratim për kategori të caktuara veprimesh.
Parimi bazë është i thjeshtë: dhënia e më shumë fuqie modelit kërkon forcimin e sistemit përreth. Autonomia pa politika nuk është gati për prodhim.
Nuk pyetëm më: cilat janë veprimet e duhura të shfletuesit që duhet të ekspozojmë?
Filluam të pyesnim: çfarë mund të bëjmë për t'i siguruar modelit një hapësirë të plotë veprimesh—dhe si të krijojmë rreth saj politika ekzekutimi që ruajnë sigurinë?
Ky riformulim ndryshon çfarë konsideroni të rëndësishme. Taksonomitë e veprimeve dhe plotësia e shtresave mbështjellëse kanë më pak rëndësi. Politikat e ekzekutimit, vëzhgueshmëria dhe vlerësimi në nivel hapi kanë më shumë rëndësi. Aftësia e modelit dhe projektimi i sistemit nuk e zëvendësojnë njëra-tjetrën. Ndërsa modelet përmirësohen, puna e sistemit bëhet më e rëndësishme, jo më pak.
Agjentët e shfletuesit që funksionojnë në demonstrime shpesh kanë sukses sepse detyra është e ngushtë dhe mjedisi bashkëpunues. Sistemet e prodhimit kërkojnë diçka tjetër: ekzekutim të kufizuar, sjellje të instrumentuar dhe vlerësim që dallon një rezultat të saktë nga një rezultat i arritur me fat.
Më pak projektim shtresash mbështjellëse. Më shumë inxhinieri sistemesh.
Dhe ndonëse u përqendruam te agjentët e shfletuesit, kjo na drejton drejt një mënyre më të gjerë të të menduarit për përdorimin e kompjuterit si disiplinë sistemesh.