De fleste web‑agenter har føltes som at se en praktikant klikke sig nervøst gennem en browser. Ét klik, ét gæt, ét skærmbillede. Microsoft Researchs AI Frontiers‑lab siger nu stop med Webwright, et terminal‑native agent‑framework, der lader modellen skrive Playwright‑kode, køre bash, gemme artefakter og selv tjekke, om den faktisk løste opgaven. I MarkTechPosts gennemgang leverer tilgangen 60,1% på Odysseys‑benchmarken mod base GPT‑5.4’s 33,5% i en klassisk skærmbillede‑agent. Det er et markant spring — og det peger på et skifte fra klik til kode.
For os i Snilld er pointen praktisk. Når artefakterne er kode og logs i et lokalt workspace, bliver hver kørsel efterprøvbar. Det er et andet liv for drift og support end en sort boks, der klikkede ét pixel forbi. Vi så samme skifte hos en kunde i energibranchen for nylig, hvor en klik‑optaget RPA‑robot brød ved et mindre layoutskift, mens en scriptet Playwright‑løsning kunne versionsstyres og patches hurtigt. Ikke glamourøst — men det virker.
Hvad Webwright er og hvorfor scoren betyder noget
MarkTechPost rapporterer, at Webwright er open‑source og kommer fra Microsoft Researchs AI Frontiers‑lab. Frameworket adskiller agenten fra browseren. Browseren kan startes, inspiceres og droppes igen, mens den vedvarende sandhed er koden, logs, screenshots og resultater i workspace‑mappen. Det minder om den måde udviklere skriver RPA‑scripts på — bare med en model bag tastaturet. Kilde: MarkTechPost, som linker til Microsoft Researchs egen artikel og kode.
I samme dækning fremhæves, at Webwright når 60,1% på Odysseys, mens en base GPT‑5.4 i et skærmbillede‑agentsetup rammer 33,5%. Tallene stammer fra MarkTechPosts artikel, der citerer Microsoft Researchs materiale. Vi kan ikke verificere dem her, men forskellen er stor nok til at være værd at teste i jeres miljø.
Terminal‑native i praksis
Arkitekturen står på tre dele ifølge MarkTechPost: en Runner, et Model Endpoint og en terminal Environment. Runneren er cirka 150 linjer kode, modelinterfacet cirka 550, environment cirka 300. En slank kerne uden orkester af agenter. Loopet er enkelt: Runner sender kontekst til modellen; modellen svarer med en tænke‑blok og én shell‑kommando; kommandoen kører i miljøet, som returnerer terminaloutput, logs, screenshots eller fejltracebacks; observationerne ryger tilbage i konteksten — og så igen.
Kernen er, at agenten skriver rigtig kode: Playwright‑scripts til at styre Chromium, Firefox eller WebKit — og bash til at installere dependencies, køre tests, læse filer, zippe artefakter. Forskellen fra klik‑for‑klik er tydelig: multi‑step interaktioner bliver kompakte funktioner. Formularer udfyldes i ét hug. Det er værd at bemærke for udviklere, der skal drifte det bagefter.
Hvorfor koden måler bedre
Den kode‑første tilgang fjerner friktion i klassiske agenter. I stedet for at forudsige x,y‑klik hundrede gange, skriver modellen et lille program med loops og helper‑funktioner. MarkTechPost peger på to ingeniørproblemer og hvordan Webwright tackler dem: for tidlig “done” og kontekstlængde. Førstnævnte er klassikeren: modellen siger færdig for tidligt. Løsningen her er en gate: agenten skal generere en self‑reflection‑konfig, køre et sidste script i en frisk mappe og bestå sin egen dom, der udskriver succes eller fejl, før den må sige done true. Ellers droppes flaget, og den prøver igen.
For kontekstlængden komprimeres historikken hver 20. skridt til et sammendrag. Det holder inputvinduet nede. Ikke banebrydende alene, men i kombination med kodeartefakter på disk holder det løbet nogenlunde slankt. Vi har set lignende mønstre virke i interne tests. Dog en vigtig note: modeller kan stadig bygge ustabile waits. Vi har set flaky selectors og timeouts, hvor et lille DOM‑skift vælter løbet. Det kræver robust retry og stram tidstyring.
Hvad det betyder for udvikling og drift
Når alt kodes og gemmes, kan I versionere alt: scripts, logik, testdata, screenshots. Det gør diff og rollback banalt. En repo‑struktur vi har haft held med i PoC’er: /agents med opgave‑mapper, /scripts for genererede Playwright‑moduler, /runs for hver kørsel med timestamp, logs, screenshots, og /eval for sammenligninger af resultater over tid. Simpelt — og til at arbejde med.
Fejldiagnose bliver også mere lige til. En fejlet kørsel efterlader en pakke af spor: terminaloutput, stacktraces, billeder af skærmen. Man kan åbne mappen, gense alt og hurtigt lokalisere bruddet. To praktiske noter: gem screenshots i et fast navngivningsmønster og hold retention på mindst 30 dage i udvikling, længere i produktion. Og pin versioner af Playwright og browserdrivere i CI — opgraderinger bryder ellers selector‑stabiliteten uden varsel.
Sikkerhed og governance uden glansbilleder
At lade en model køre bash og skrive Playwright‑scripts er stærkt — og farligt, hvis miljøet er åbent. Det er ikke en anklage mod Webwright, men et generisk risikoscenarie, vi kender alt for godt fra supply‑chain‑angreb. VentureBeat beskrev for nylig, hvordan 633 ondsindede npm‑versioner gled gennem Sigstore‑kontroller, fordi angriberen havde gyldige certifikater udstedt via stjålne konti. Pointen er enkel: kryptografisk proveniens hjælper, men stjålne credentials gør ondt. En auto‑agent med shell er ikke immun.
Vores anbefalinger er jordnære: kør PoC i isolerede containere uden adgang til rigtige virksomheds‑secrets. Hvis I absolut skal bruge live‑systemer i et testvindue, så brug read‑only konti, lav throttle, og slå fuld audit‑logging til. Secrets skal ligge i et vault med tidsbegrænsede tokens, og miljøet skal køre med mindst mulige rettigheder. Indfør review‑gate på auto‑genererede scripts før produktion. Og log alt: bash‑historik, filændringer, netværkskald hvor muligt.
Skalerbarhed og de mindre sjove begrænsninger
Web‑agenter er tunge, når de spinner browsere op. Skalerbarhed afhænger af, hvor hurtigt I kan starte og afslutte sessions, og hvordan I styrer ressourceforbrug. MarkTechPost beskriver komprimering af kontekst og en enkel loop‑model, men der er ikke tal for, hvor mange samtidige sessions der er realistiske, hvad timeouts bør være, eller hvornår man bør genbruge browserkontekster. Det er åbne spørgsmål til Microsoft Research.
Operationelt bør I definere klare abort‑strategier: hårde timeouts pr. trin og pr. løb, kill‑switch når CPU eller memory går amok, og backoff, når eksterne sites throttler. Vi anbefaler at køre Playwright headless i en container med cgroups‑kvoter og at måle page init, selector find, navigation og network idle som særskilte metrikker. Hvis tallene driver, ruller I tilbage eller justerer waits. Små ting, stor effekt.
Use cases der giver mening nu
Hvor vinder det først? Tre steder går igen hos vores kunder: testautomation af webapps (især regression på komplekse formularer), dataskrab på tværs af sites med cookies og login‑flows, og end‑to‑end onboarding i backoffice‑værktøjer, der ikke har APIs på det hele. Vi har set en agent generere solide tests for en forsikringsformular på to dage — noget der før tog en uge manuelt. Og vi har set det modsatte: en onboarding‑agent, der misforstod en dynamisk dropdown og spildte 500 kørsler, indtil vi tilføjede deterministiske selectors.
Rytmen er denne: agenter trives med kedeligt, gentaget arbejde med rimelig tolerance for små afvigelser, hvor en menneskelig review kan fange restfejl. Til kritiske flows med persondata og penge? Langsomt og med dobbelt net. Det holder jer ude af aviserne.
Sådan står Webwright i feltet
Der findes andre agentrammer, både open og lukkede, der forsøger at orkestrere browsing via høj‑niveau handlinger eller multi‑agenter. Webwright skiller sig ud ved at være slankt, terminal‑native og eksplicit kode‑først. Open‑source‑frigivelsen er strategisk klog, fordi den gør reproducerbarhed og inspektion mulig. Men enterprise‑features som central policy, indbygget secrets‑håndtering, kvoter på shell‑kørsler og robust eval mangler i materialet, vi har set.
MarkTechPost refererer til to benchmarks. Ud over Odysseys nævnes Online‑Mind2Web, hvor GPT‑5.4 rammer 86,67% overall i deres opsætning, og Claude Opus 4,7 rammer 84,7% samlet men stærkere på svære opgaver ved N=100 skridt. Relevante datapunkter — men uden fuld eksperimentbeskrivelse er det svært at overføre direkte til jeres miljø. Godt som retning, ikke som sandhed.
Åbne spørgsmål vi gerne vil have svar på
Flere detaljer ville hjælpe teams, der skal bygge på det: Hvilket præcist GPT‑5.4‑checkpoint og hvilke prompts er brugt i evalueringerne? Hvad var seeds, timeout‑parametre og resource limits? Hvilke modelendpoints er testet, og hvilke licenskrav gælder i enterprise? Hvordan ser policy‑hooks og sandboxing‑eksempler ud i environment‑koden? Hvad er realistisk antal samtidige sessions per node, og hvad koster det i cold‑start? Og måske vigtigst: hvilke failure modes opstår hyppigst i deres egne interne runs, og hvordan er de håndteret i praksis?
MarkTechPost linker til Microsoft Researchs artikel og repo. Vi anbefaler, at man selv gennemgår kildekoden for at vurdere, hvor meget der skal bygges ovenpå for enterprise. Ikke fordi der er noget mistænkeligt — men fordi det altid er klogt.
Fra klik til kode ændrer jeres pipeline
Implementering kræver et lille skifte i mental model. Tænk ikke “session replay”, men “script‑udvikling der kan versioneres”. Det kalder på en CI/CD‑pipeline, hvor auto‑genererede scripts testes i isolerede miljøer med faste browser‑ og Playwright‑versioner, før de får lov at køre mod produktion. Når en model foreslår et nyt modul, kør et valideringsjob, sammenlign screenshots eller DOM‑hash for determinisme, og sign‑off via review. Rul frem med feature flags. Rul tilbage ved regression.
I drift bør I samle alt observability i én pakke pr. run. Vi har haft glæde af en simpel manifestfil i hver /runs‑mappe med commit‑hash, modelversion, tidsforbrug, antal retries og en status. Det gør fejlsøgning og kapacitetsplan lettere. Når Playwright eller browser opdateres, kør en suite af stabile kontrolscenarier først. Hvis to eller flere bryder, pin versionen og åbn en opgave — ikke omvendt.
Tjekliste der gør en forskel i morgen
- PoC‑miljø: Container med cgroups‑kvoter, ingen netværk til interne systemer, headless browser, pinned Playwright‑version.
- Sikkerhed: Secrets i vault, read‑only konti, mindst mulige rettigheder, audit‑log på shell og filsystem, pre‑merge review af auto‑scripts.
- Validering: Automatisk job der kører nye scripts mod sandbox, sammenligner screenshots/DOM‑hash og måler flakiness over 10 gentagelser.
- Metrics: Page init, selector latency, navigation time, retry‑rate, success‑rate og artefaktstørrelser pr. run.
- Roller: En systemejer for miljøet, en udvikler for scripts, en driftsvagt for alarmer og en sikkerhedsrepræsentant for policies. Ikke 12 mennesker — men heller ikke 0.
- Roadmap 6 uger: Uge 1 kortlæg workflows. Uge 2‑3 byg PoC på to lavrisiko‑flows. Uge 4‑5 harden miljø og validering. Uge 6 beslut om udvidelse eller stop.
Hvad vi har set i praksis
Små observationer fra vores skrivebord. I vores første interne forsøg lavede modellen et fint Playwright‑script, men satte en non‑deterministisk waitForTimeout på 500 ms. Det virkede om morgenen, fejlede efter frokost. Efter vi tvang waitForSelector med stabile attributter og tilføjede retry med exponential backoff, faldt fejlprocenten fra ca. 18% til under 3% på 200 kørsler. Ikke videnskab — bare håndværk.
Et andet sted genererede agenten bash‑kommandoer, der installerede et globalt npm‑modul uden locked version. To dage senere brød løbet stille og roligt, fordi en minor‑opdatering ændrede en default. Pin alt. Det er kedeligt. Gør det alligevel.
Kilder og hvad der kan verificeres
De centrale tekniske detaljer om Webwright, løkke‑designet, komponenterne, linjetallene for Runner/Model/Environment samt benchmark‑tallene for Odysseys og Online‑Mind2Web stammer fra MarkTechPost. Artiklen linker til Microsoft Researchs egen gennemgang og repo, som er den autoritative kilde for implementering. Vores sikkerhedsparalleller om credentials‑misbrug bygger på VentureBeats rapportering om sigstore/npm og relaterede angreb. Det er ikke et fund i Webwright, men en generel risiko for miljøer, der kører shell med adgang til nøgler.
Der mangler fortsat detaljer om prompts, præcise modelcheckpoints, eval‑konfiguration og skaleringsmålinger i offentligt materiale, vi har set. Vi efterlyser dem gerne. Indtil da bør alle teams reproducere benchmarkene i eget miljø, før de drager konklusioner.
Hvor feltet bevæger sig hen
Mit indtryk lige nu: kode‑først vinder. Ikke fordi det er smukkere, men fordi det er til at drifte. Når agenter bliver bedre til at skrive og rette deres egne scripts, glider vi væk fra pixel‑klik og hen imod semantiske handlinger og biblioteker, der kan genbruges. Men governance halter ofte bagefter den første begejstring. Og så går det galt.
Hvis jeg skulle gøre én ting i morgen, ville jeg sætte en lille container op og lade en agent løse én lavrisiko‑webopgave med Webwright‑tilgangen. Gemme alle artefakter. Bryde det. Lappe det. Mærke friktionen i hænderne. Det er dér, man opdager forskellen — ikke i slides.
