Hvad er computerbrug, og hvorfor er det vigtigt? Computerbrug er en enkel idé med vidtrækkende konsekvenser: I stedet for at bede modeller om at besvare spørgsmål beder vi dem betjene software – navigere på websites, udfylde formularer, klikke sig gennem arbejdsgange og løse opgaver autonomt fra start til slut.
Det åbner for en stor gruppe opgaver fra den virkelige verden, som i dag er spredt på tværs af grænseflader, f.eks. komplette bookingforløb, betaling i webshops, rejseplanlægning i flere trin og administrative arbejdsgange uden et tilsvarende enkelt API. Det er ikke nye problemer. Det nye er, at de nu kan løses med generelle modeller.
Nyere systemer fra Anthropic og OpenAI har demonstreret agenter, som ikke blot handler, men ræsonnerer over tilstanden, retter op på fejl og skaber opgavespecifikke løsninger undervejs. Det gør browseren til et generelt udførelsesmiljø for agenter, men rejser straks et designspørgsmål: Hvor meget af miljøet bør vi eksponere for modellen?
De tidlige systemers svar var at indkapsle browseren i et fast sæt sikre, foruddefinerede handlinger. Som vi vil argumentere for i dette indlæg, er den tilgang ved at nå sin grænse.
Når man bygger browseragenter, er der en velkendt impuls: Stol ikke for meget på modellen.
Derfor indkapsler vi browseren. Vi stiller foruddefinerede værktøjer som click, type, scroll, select og read_text til rådighed. Vi forenkler Document Object Model (DOM). Vi indsnævrer handlingsrummet. Vi forsøger at gøre adfærden forståelig og styrbar gennem abstraktioner, vi selv designer.
Det er et fornuftigt udgangspunkt. Men det er også i stigende grad den forkerte langsigtede arkitektur.
Efterhånden som banebrydende modeller bliver bedre, er begrænsningen ikke længere blot, at modellen mangler værktøjer. Begrænsningen er, at vi tvinger den til at arbejde gennem abstraktioner, der fjerner for meget af det underliggende system. Vi komprimerer et rodet, dynamisk miljø til en fast handlingsgrænseflade og beder derefter modellen præstere godt trods dette informationstab.
Det kompromis bliver stadig mindre attraktivt.
Det skift, vi har undersøgt, er enkelt at beskrive, men har vidtrækkende konsekvenser. I stedet for at betragte agenten som en vælger af foruddefinerede handlinger betragter vi den som en programgenerator, der arbejder i et begrænset kørselsmiljø.
Modellerne er blevet virkelig gode og har ikke længere brug for dine abstrakte sikkerhedsværn – de har brug for hele handlingsrummet, så de kan designe, udføre og justere opgaven, indtil de når deres mål.
Dette indlæg handler om skiftet fra browserautomatisering med mange abstraktioner til begrænset computerbrug – og om, hvad der ændrer sig, når man designer systemer på denne måde.
Problemet er ikke, at faste handlingsgrænseflader principielt er forkerte. Det er, at nettet ikke retter sig efter dem.
Moderne grænseflader er bygget med React, Vue og Angular og bruger asynkrone tilstandsopdateringer, syntetiske hændelsessystemer og indlejrede tredjepartswidgets, der befinder sig i cross-origin-iframes med deres egne livscyklusser. En wrapper, der siger »skriv i dette inputfelt«, fungerer kun korrekt, hvis siden deler din definition af det at skrive. Det gør mange sider ikke. Hvis en værdi angives direkte, omgår det ofte frameworkets registrering af ændringer fuldstændigt. Inputfeltet ser udfyldt ud. Valideringen udløses aldrig. Formularen virker stadig ikke.
Det kan du lappe på. Du kan tilføje særtilfælde for React-inputfelter, udløse blur-hændelser efter fokus og vente på netværksinaktivitet, før tilstanden aflæses. Hver rettelse er isoleret set korrekt. Tilsammen vokser de til et system, der bliver stadig sværere at vedligeholde og stadig mere specifikt for de websites, du allerede har set.
Det dybereliggende problem er, at du indkoder antagelser om, hvordan interaktioner bør fungere, i abstraktionslaget og derefter opdager, at nettet bygger på andre antagelser.
Forestil dig en betalingsformular fra Stripe eller Adyen, der er indlejret i en cross-origin-iframe. Din wrapper kan ikke tilgå den direkte, fordi den befinder sig på en anden origin. Værktøjet read_text kan ikke observere dens interne tilstand. Værktøjet type kan ikke tilgå dens inputfelter. Her rammer en wrapperbaseret agent en mur. Abstraktionen blev designet til hoveddokumentet. Den egentlige opgave ligger et sted, abstraktionen ikke kan se.
En lignende uoverensstemmelse opstår i mindre åbenlyse forløb. En frameworkstyret rullemenu reagerer måske slet ikke på direkte klik, fordi det synlige element ikke er det egentlige kontrolelement. Det kan kræve en række tastaturhændelser at udløse den underliggende tilstandsændring. Udefra ser brugergrænsefladen ud til at kunne klikkes på. Abstraktionen siger »klik«. Intet sker.
Eller forestil dig et modalforløb i flere trin, hvor opdateringerne af den synlige DOM er forsinkede i forhold til ændringerne i den interne tilstand. Den næste korrekte handling afhænger af en tilstandsændring, som endnu ikke afspejles i de elementer, din wrapper kan se. En wrapperbaseret agent ender med at handle for tidligt eller aflæse en forældet tilstand, fordi den arbejder ud fra et ufuldstændigt billede af systemet.
I hvert tilfælde skjuler abstraktionen de signaler, agenten faktisk har brug for.
En model, der arbejder på et lavere niveau – inspicerer den aktive DOM, ræsonnerer over framegrænser og genererer interaktionssekvensen til netop denne flade – kan navigere i disse situationer. Det skyldes ikke, at modellen i sig selv er mere intelligent. Det skyldes, at den har adgang til de oplysninger, som blev fjernet.
Den ændring, vi har arbejdet hen imod, er enkel at beskrive: I stedet for at bede modellen vælge mellem foruddefinerede handlinger giver vi den en udførelsesflade på et lavere niveau og begrænser fladen gennem politikker i kørselsmiljøet frem for gennem abstraktionsdesign.
Dette designvalg udspringer af et bredere skift i branchen mod primitive værktøjer på et lavere niveau. De udnytter agentens iboende evne til at rette kursen under kørslen og producere kode af høj kvalitet, i stedet for at bruge robuste, hårdkodede specialværktøjer, som begrænser modellens evne til at tilpasse sig forskellige miljøer.
Tænk på Claude Codes succes som et af de foretrukne værktøjer blandt mange udviklere og branchens bredere bevægelse mod terminalbaserede agenter. Claude Codes største fordel er ikke selve modellen, men dens harness på et lavere niveau. Når modellen får færre, mere modulære værktøjer på et lavere niveau – dvs. terminalen – bliver dens brug af værktøjer bedre, især fordi agenten kan ræsonnere og oprette skræddersyede scripts til den aktuelle opgave frem for at forsøge at bruge generaliserede værktøjer, der fylder kontekstvinduet med støj.
I praksis betyder det for browserautomatisering, at modellen direkte kan inspicere sidens aktuelle tilstand, bevæge sig mellem frames og konstruere skræddersyet interaktionskode til den aktuelle grænseflade frem for at kortlægge alt til et fast sæt forudbyggede handlinger.
Modellen opfører sig mindre som en vælger og mere som en udvikler i kørselsmiljøet. Den inspicerer den aktuelle tilstand, ræsonnerer over grænsefladen og genererer interaktionslogikken til den konkrete situation. Den kan opbygge sekvenser med flere trin, tilpasse sig usædvanlige forløb og validere resultaterne, før den fortsætter. Når en handling mislykkes, ser modellen den underliggende fejl og retter selv kursen. Det er mere effektivt og mere risikabelt – men ligger langt tættere på problemets faktiske form.
Det er vigtigt at understrege, at systemet ikke bliver mindre disciplineret, når abstraktionslaget fjernes. Disciplinen flyttes blot.
Det arbejde, der før lå i wrapperdesign og håndtering af særtilfælde, flyttes til tre steder: prompten (som bliver en form for operationel træning), kørselsmiljøet (som håndhæver grænser for bl.a. navigation, følsomme handlinger og gentagne forsøg) og evalueringslaget (som ikke blot vurderer, om opgaven lykkedes, men også om de mellemliggende trin var korrekte). Færre skrøbelige abstraktioner. Stærkere omgivende systemer.
Et resultat af dette skift er, at produktkoden ofte bliver enklere, selvom det samlede system bliver mere kompetent. I stedet for at indkode interaktionsmønstre som genanvendelige wrappers genererer agenten adfærd under kørslen. Du vedligeholder et lille sæt effektive primitiver og et begrænset kørselsmiljø frem for en voksende samling specialiserede værktøjer og logik til særtilfælde.
Det ændrer også den måde, systemet generaliserer på. En wrapperbaseret agent generaliserer godt til opgaver, der minder om de wrappers, du allerede har bygget. En agent med et begrænset kørselsmiljø generaliserer til opgaver, der deler et fælles udførelsesgrundlag, selvom den synlige grænseflade er anderledes.
Interaktion med en søgeformular, et bookingforløb eller en indstillingsside kan for eksempel se vidt forskellig ud på brugergrænsefladen. Men nedenunder deler de de samme mønstre: aflæsning af tilstand, udløsning af hændelser, validering af resultater og håndtering af asynkrone opdateringer. Et system, der arbejder på dette niveau, overfører mere naturligt sine evner mellem opgaver.
Den genanvendelige komponent er ikke listen over handlinger. Det er modellens evne til at inspicere tilstanden, handle sikkert og kontrollere resultaterne.
Den tydeligste lære af dette arbejde er, at pålidelighed ikke kommer af at give modellen flere hjælpefunktioner. Den kommer ofte af at give modellen færre og mere effektive primitiver og begrænse dem på de rigtige måder. Overdreven hjælp fastlåser antagelser om, hvordan en opgave bør løses. Begrænsninger fastlægger sikre rammer for driften og giver modellen mulighed for at finde bedre lokale løsninger.
En mere effektiv udførelsesflade kræver også en skarpere sikkerhedsmodel. Når agenten ikke længere er begrænset til et lille sæt foruddefinerede handlinger, arbejder den reelt direkte med rigtig software. Det ændrer straks risikoprofilen.
Der er fire hensyn, som designet skal tage højde for:
Dataeksponering. Når agenten interagerer med rigtige grænseflader, vil den ofte støde på følsomme oplysninger. Det kræver en disciplineret tilgang til maskering og adgangskontrol. Data bør kun vises, når det er nødvendigt for udførelsen, og logfiler og spor skal håndteres omhyggeligt, så observerbarheden ikke bliver systemets mest følsomme del.
Udførelsens omfang. En effektiv agent bør ikke kunne operere vilkårligt. I praksis betyder det, at man begrænser, hvor den kan navigere, hvilke domæner den kan tilgå, og hvilke systemer den må interagere med. Begrænsningerne bør håndhæves i kørselsmiljøet og ikke blot være konventioner i prompten.
Tillid til miljøet. Moderne grænseflader kan indeholde instruktioner, indhold eller forløb, der er vildledende eller direkte fjendtlige. Prompt injection via sideindhold udgør en reel angrebsflade. Systemet har brug for et klart instruktionshierarki, valideringskontroller og stopbetingelser, så agenten ikke følger utilsigtede anvisninger.
Spektrum for autonomi. Ikke alle handlinger bør være fuldt autonome. I mange produktionsmiljøer er det vigtigt at betragte autonomi som et spektrum. Systemet kan arbejde meget agentbaseret, når det udforsker og udfører, men stadig kræve godkendelse af bestemte kategorier af handlinger.
Det grundlæggende princip er enkelt: Når modellen får mere magt, skal det omgivende system gøres stærkere. Autonomi uden politikker er ikke klar til produktion.
Vi holdt op med at spørge: Hvilke browserhandlinger er de rigtige at stille til rådighed?
Vi begyndte at spørge: Hvordan kan vi give modellen et komplet handlingsrum – og hvordan opbygger vi politikker omkring kørselsmiljøet, som stadig gør det sikkert?
Det nye perspektiv ændrer, hvad der er vigtigt. Handlingstaksonomier og komplette wrappers betyder mindre. Politikker for kørselsmiljøet, observerbarhed og evaluering af hvert trin betyder mere. Modellens evner og systemdesignet kan ikke erstatte hinanden. Efterhånden som modellerne bliver bedre, bliver systemets arbejde vigtigere – ikke mindre vigtigt.
Browseragenter, der virker i demonstrationer, lykkes ofte, fordi opgaven er snæver, og miljøet er samarbejdsvilligt. Produktionssystemer kræver noget andet: begrænset udførelse, instrumenteret adfærd og evaluering, der kan skelne mellem et korrekt resultat og et heldigt resultat.
Mindre wrapperdesign. Mere systemudvikling.
Og selvom vi har fokuseret på browseragenter, peger det mod en bredere forståelse af computerbrug som en systemdisciplin.