Vad är datoranvändning, och varför spelar den roll? Datoranvändning är en enkel idé med långtgående följder: i stället för att be modeller besvara frågor ber vi dem använda programvara – navigera på webbplatser, fylla i formulär, klicka sig igenom arbetsflöden och självständigt slutföra uppgifter från början till slut.
Det gör en stor kategori verkliga uppgifter möjliga, som i dag är uppdelade mellan olika gränssnitt: kompletta bokningar, köp i e-handel, reseplanering i flera steg och administrativa arbetsflöden som saknar en tydlig API-motsvarighet. Det här är inga nya problem. Det nya är att de nu kan lösas med generella modeller.
Nya system från Anthropic och OpenAI har demonstrerat agenter som inte bara agerar, utan också resonerar om tillstånd, återhämtar sig från fel och skapar uppgiftsspecifika lösningar i stunden. Det gör webbläsaren till en generell körmiljö för agenter, men väcker genast en designfråga: hur mycket av miljön ska modellen få tillgång till?
Tidiga system löste det genom att kapsla in webbläsaren i en fast uppsättning säkra, fördefinierade åtgärder. Som vi kommer att argumentera för i det här inlägget börjar den metoden nå sin gräns.
När man bygger webbläsaragenter är en vanlig instinkt att inte lita för mycket på modellen.
Därför kapslar vi in webbläsaren. Vi tillhandahåller fördefinierade verktyg som click, type, scroll, select och read_text. Vi förenklar dokumentobjektmodellen (DOM). Vi begränsar handlingsutrymmet. Vi försöker göra beteendet begripligt och styrbart genom abstraktioner som vi själva utformar.
Det är en rimlig utgångspunkt. Men det blir också alltmer fel arkitektur på lång sikt.
När banbrytande modeller blir bättre är begränsningen inte längre bara att modellen saknar verktyg. Problemet är att vi tvingar den att arbeta genom abstraktioner som tar bort för mycket av det underliggande systemet. Vi pressar in en rörig, dynamisk miljö i ett fast åtgärdsgränssnitt och ber sedan modellen prestera väl trots informationsförlusten.
Den avvägningen blir allt mindre attraktiv.
Förändringen vi har utforskat är enkel att beskriva, men har stora konsekvenser. I stället för att behandla Agenten som en väljare av fördefinierade åtgärder ser vi den som en programsyntetiserare som arbetar i en begränsad körmiljö.
Modellerna har blivit riktigt bra och behöver inte längre dina abstrakta skyddsräcken – de behöver hela handlingsutrymmet för att utforma, utföra och iterera på uppgiften tills de når målet.
Det här inlägget handlar om övergången från abstraktionstung webbläsarautomation till begränsad datoranvändning – och om vad som förändras när system utformas på det sättet.
Problemet är inte att fasta åtgärdsgränssnitt är principiellt fel. Problemet är att webben inte samarbetar med dem.
Moderna gränssnitt byggs med React, Vue och Angular och har asynkrona tillståndsuppdateringar, syntetiska händelsesystem och inbäddade tredjepartswidgetar i iframe-element från andra ursprung, med egna livscykler. Ett omslag som säger ”skriv i det här inmatningsfältet” fungerar bara om sidan delar din definition av att skriva. Många gör inte det. Att ange ett värde direkt kringgår ofta ramverkets ändringsdetektering helt. Inmatningsfältet ser ifyllt ut. Valideringen utlöses aldrig. Formuläret fungerar fortfarande inte.
Det går att lappa ihop. Du kan lägga till specialfall för React-fält, utlösa blur-händelser efter fokus och vänta tills nätverket är inaktivt innan tillståndet läses. Varje korrigering fungerar i sitt specifika fall. Tillsammans växer de till ett system som blir allt svårare att underhålla och alltmer anpassat till de webbplatser du redan har sett.
Det djupare problemet är att du bygger in antaganden om hur interaktioner ska fungera i abstraktionslagret och sedan upptäcker att webben bygger på andra antaganden.
Tänk dig ett betalningsformulär från Stripe eller Adyen, inbäddat i ett iframe-element från ett annat ursprung. Ditt omslag kommer inte åt det direkt eftersom det ligger på ett separat ursprung. Verktyget read_text kan inte observera dess interna tillstånd. Verktyget type kan inte adressera dess inmatningsfält. Här tar det stopp för en omslagsbaserad Agent. Abstraktionen utformades för huvuddokumentet. Den verkliga uppgiften finns någonstans dit abstraktionen inte kan se.
En liknande diskrepans uppstår i mindre uppenbara flöden. En ramverksstyrd listruta kanske inte alls reagerar på direkta klick, eftersom det synliga elementet inte är den faktiska kontrollen. Det kan krävas en serie tangentbordshändelser för att utlösa den underliggande tillståndsövergången. Utifrån ser användargränssnittet klickbart ut. Abstraktionen säger ”klicka”. Ingenting händer.
Eller tänk dig ett modalt flöde i flera steg där uppdateringarna av den synliga DOM:en släpar efter ändringarna i det interna tillståndet. Nästa korrekta åtgärd beror på en tillståndsövergång som ännu inte syns i de element som omslaget kan se. En omslagsbaserad Agent agerar då för tidigt eller läser inaktuellt tillstånd, eftersom den arbetar utifrån en ofullständig bild av systemet.
I samtliga fall döljer abstraktionen de signaler som Agenten faktiskt behöver.
En Modell som arbetar på en lägre nivå – granskar den aktuella DOM:en, resonerar om ramgränser och skapar en interaktionssekvens för just den aktuella ytan – kan hantera dessa situationer. Det beror inte på att modellen i sig är smartare. Det beror på att den har tillgång till informationen som tidigare togs bort.
Förändringen vi har arbetat mot är enkel att beskriva: i stället för att be modellen välja bland fördefinierade åtgärder ger vi den en exekveringsyta på lägre nivå och begränsar ytan med policyer i körmiljön snarare än genom abstraktionsdesign.
Det här designvalet följer ett bredare skifte i branschen mot primitiver på lägre nivå – verktyg som utnyttjar Agentens inneboende förmåga att korrigera sig under körning och skapa kod av hög kvalitet, i stället för robusta men hårdkodade specialverktyg som begränsar modellens möjlighet att anpassa sig till olika miljöer.
Tänk på Claude Codes framgång som ett förstahandsval i många utvecklares verktygslådor och branschens bredare rörelse mot terminalbaserade agenter. Claude Codes största fördel är inte själva modellen, utan körmiljön på lägre nivå. När modellen får färre, mer modulära verktyg på lägre nivå – det vill säga terminalen – blir verktygsanropen bättre. Det beror främst på att Agenten kan resonera och skapa anpassade skript för den aktuella uppgiften, i stället för att försöka använda generaliserade verktyg som fyller kontextfönstret med brus.
För webbläsarautomation innebär det i praktiken att modellen direkt kan granska sidans aktuella tillstånd, navigera mellan ramar och skapa skräddarsydd interaktionskod för det aktuella gränssnittet, i stället för att mappa allt till en fast uppsättning förbyggda åtgärder.
Modellen fungerar mindre som en väljare och mer som en skapare av körlogik. Den granskar det aktuella tillståndet, resonerar om gränssnittet och skapar interaktionslogiken för just den situationen. Den kan skapa sekvenser i flera steg, anpassa sig till ovanliga flöden och validera resultat innan den fortsätter. När en åtgärd misslyckas ser modellen det underliggande felet och korrigerar sig själv. Det är kraftfullare och mer riskfyllt – men ligger mycket närmare problemets verkliga natur.
Viktigt är att systemet inte blir mindre disciplinerat när abstraktionslagret tas bort. Disciplinen flyttas bara.
Arbete som tidigare låg i utformningen av omslag och hanteringen av specialfall flyttas till tre ställen: prompten (som blir en form av operativ träning), körmiljön (som upprätthåller gränser för bland annat navigering, känsliga åtgärder och återförsök) samt utvärderingslagret (som inte bara bedömer om uppgiften lyckades, utan även om de mellanliggande stegen var korrekta). Färre sköra abstraktioner. Starkare omgivande system.
En följd av den här förändringen är att produktkoden ofta blir enklare, samtidigt som systemet som helhet blir mer kapabelt. I stället för att koda interaktionsmönster som återanvändbara omslag skapar Agenten beteendet vid körning. Du underhåller en liten uppsättning kraftfulla primitiver och en begränsad körmiljö, i stället för en växande uppsättning specialverktyg och logik för specialfall.
Det förändrar också hur systemet generaliserar. En omslagsbaserad Agent generaliserar väl till uppgifter som liknar dem som dina befintliga omslag är byggda för. En Agent i en begränsad körmiljö generaliserar till uppgifter som delar samma exekveringsgrund, även när det synliga gränssnittet skiljer sig.
Att interagera med ett sökformulär, ett bokningsflöde eller en inställningssida kan till exempel se helt olika ut i användargränssnittet. Men under ytan delar de samma mönster: läsa tillstånd, utlösa händelser, validera resultat och hantera asynkrona uppdateringar. Ett system som arbetar på den nivån kan lättare överföra sin förmåga mellan uppgifter.
Den återanvändbara komponenten är inte åtgärdslistan. Det är modellens förmåga att granska tillstånd, agera säkert och verifiera resultat.
Den tydligaste lärdomen från det här arbetet är att tillförlitlighet inte kommer av att modellen får fler hjälpfunktioner. Ofta kommer den av att modellen får färre men kraftfullare primitiver, som begränsas på rätt sätt. Överdriven hjälp låser fast antaganden om hur en uppgift ska utföras. Begränsningar anger säkra ramar och låter modellen hitta bättre lösningar för den aktuella situationen.
En kraftfullare exekveringsyta kräver också en skarpare säkerhetsmodell. När Agenten inte längre är begränsad till en liten uppsättning fördefinierade åtgärder arbetar den i praktiken direkt i verklig programvara. Det förändrar riskprofilen omedelbart.
Utformningen behöver ta hänsyn till fyra områden:
Dataexponering. När Agenten interagerar med verkliga gränssnitt kommer den ofta att stöta på känslig information. Det kräver ett disciplinerat arbete med maskering och åtkomstkontroll. Data ska bara visas när de behövs för exekveringen, och loggar och spår måste hanteras varsamt så att observerbarheten inte blir systemets känsligaste del.
Exekveringens omfattning. En kraftfull Agent ska inte kunna agera godtyckligt. I praktiken innebär det att begränsa vart den kan navigera, vilka domäner den kan nå och vilka system den får interagera med. Begränsningarna ska tillämpas i körmiljön och inte bara vara konventioner i prompten.
Tillit till miljön. Moderna gränssnitt kan innehålla instruktioner, innehåll eller flöden som är vilseledande eller direkt fientliga. Promptinjektion via sidinnehåll är en verklig angreppsyta. Systemet behöver en tydlig instruktionshierarki, valideringskontroller och avslutningsvillkor som hindrar Agenten från att följa oavsiktliga anvisningar.
Spektrum av autonomi. Alla åtgärder bör inte vara helt autonoma. I många produktionsmiljöer är det viktigt att se autonomi som ett spektrum. Systemet kan agera med stor självständighet när det utforskar och utför uppgifter, men ändå kräva godkännande för vissa typer av åtgärder.
Grundprincipen är enkel: ju mer kraft modellen får, desto starkare måste det omgivande systemet vara. Autonomi utan policy är inte redo för produktion.
Vi slutade fråga: vilka webbläsaråtgärder bör vi tillhandahålla?
Vi började fråga: hur kan vi ge modellen ett fullständigt handlingsutrymme – och vilka policyer kan vi bygga runt körmiljön för att ändå hålla den säker?
Det nya perspektivet förändrar vad som är viktigt. Åtgärdstaxonomier och heltäckande omslag blir mindre viktiga. Policyer för körmiljön, observerbarhet och utvärdering av enskilda steg blir viktigare. Modellens kapacitet och systemdesignen kan inte ersätta varandra. När modellerna blir bättre blir systemets arbete viktigare, inte mindre viktigt.
Webbläsaragenter som fungerar i demonstrationer lyckas ofta eftersom uppgiften är snäv och miljön samarbetsvillig. Produktionssystem kräver något annat: begränsad exekvering, instrumenterat beteende och utvärdering som kan skilja ett korrekt resultat från ren tur.
Mindre design av omslag. Mer systemutveckling.
Och även om vi har fokuserat på webbläsaragenter pekar detta mot ett bredare synsätt på datoranvändning som systemdisciplin.