Terminalen som arbetsyta: Hur kodbaserad automation slår browser sessions

De flesta ser webbautomation som en AI som styr en webbläsare – klickar, skriver och scrollar sig igenom sidor. Men den modellen bygger på ett grundantagande som kanske är själva begränsningen.

Problem med bestående browser sessions

Traditionella agenter är låsta till en enda browser session. Varje steg bygger på det föregående, och när något går snett blir det snabbt rörigt att felsöka. Det finns ingen tydlig gräns mellan det som tänker och det som utför.

Det leder till flera konkreta problem:

• Tillväxt av state: Långa sessioner samlar på sig komplexitet och oväntade fall
• Svårt att debugga: Svårt att inspektera eller köra om delar av uppgiften
• Ingen återanvändning: Varje uppgift börjar om från början

Webwrights approach: kasta browsern, behåll koden

Webwright vänder på det hela. Istället för en långlivad browser session skapar agenten nya instanser vid behov – använder dem för att hämta data eller utforska, och slänger sedan bort dem. Det som sparas är koden, loggarna och skärmdumparna som hamnar i arbetsytan.

Browsern blir ett verktyg bland andra. Det verkliga resultatet är koden som skrivs för att använda den.

Tre grundprinciper

1. Kod istället för steg-för-steg Istället för långa kedjor av "klicka → vänta → skriv → skicka" låter Webwright agenten bygga funktioner. Datumval, formulärhantering och datainsamling blir återanvändbara funktioner snarare än sekvenser av primitiva åtgärder.

2. Artefakter som består Varje körning lämnar efter sig kod, loggar och skärmdumpar. Det är det som blir värdefullt över tid – inte browserns tillstånd. Arbetsytan blir både dokumentation och grund för framtida automatisering.

3. Enkel arkitektur Systemet består av tre delar: en runner, en modell och en terminalmiljö. Totalt runt 1000 rader kod. Inga komplexa orkestreringslager, bara en tight loop mellan observation och åtgärd.

Så fungerar loopen

1. Runnern skickar uppgift, arbetsyta och senaste observationer till modellen
2. Modellen svarar med tänkande och ett bash-kommando – ofta en Playwright-skript
3. Miljön kör kommandot och returnerar output, loggar och filer
4. Loopen upprepas tills agenten producerar en slutgiltig skript som verifieras i ren miljö

Prestanda på riktiga webbplatser

På Odyssey-benchmarket når Webwright 60,8 % accuracy – en förbättring med 35 % relativt tidigare toppresultat. På Online-Mind2Web klarar systemet 86,7 % över 300 uppgifter på 136 olika webbplatser. Även mindre modeller som Qwen 3.5-9B presterar bra när de får tillgång till återanvändbara verktyg.

Kontrollmekanismer

Full terminalåtkomst kräver säkerhet. Webwright använder tre skydd:

• Premature Done Gate: Agenten får inte säga att den är klar förrän den genererat ett skript, kört det i ren miljö och granskat resultatet själv
• Context Compaction: Historik komprimeras regelbundet för att hålla nere token-användningen
• Återanvändbara verktyg: Lösta uppgifter kan exporteras som CLI-verktyg och delas mellan agenter

Vad det betyder för utvecklare

Webwright pekar på några principer som är värda att ta med sig:

• Håll agentens intelligens åtskild från exekveringsmiljön
• Använd engångssessioner men spara resultatet
• Bygg funktioner istället för att kedja primitiva åtgärder
• Låt agenten bevisa att lösningen fungerar innan den deklareras klar

Terminalen är inte bara ett gränssnitt här – den är arbetsytan där koden, loggarna och artefakterna lever. Browsern är temporär. Terminalen består.