Alibaba lancerer Page Agent som open source og placerer agenten inde i selve websiden. Ikke via skærmbilleder og ikke fra et eksternt proceslag. Ifølge primærkilden læser den den levende DOM som tekst og udfører brugerhandlinger i samme session. Det er den korte version. Se gennemgangen hos MarkTechPost her.
Kildens hovedpointe er, at datavejen bliver kortere. Agenten kører i browser-sessionen, arver cookies og auth, og taler med DOM’en direkte. Det gør tilgangen mindre afhængig af skærmbilleder eller eksterne drivere og mere rettet mod apps, hvor man kontrollerer sin egen frontend.
Hvad Page Agent er – på teknikniveau
Page Agent beskrives som et klient-side bibliotek i JavaScript/TypeScript, udgivet under MIT-licens, og model-agnostisk via OpenAI-kompatible endpoints. Alt kører i siden som almindelig JS, og interaktionen med modellen er tekstbaseret. Det fremgår eksplicit af MarkTechPosts artikel.
Agenten agerer som en bruger: finder elementer i DOM’en, klikker, skriver i felter og scroller – fra selve siden. Fordi den bor i sessionen, rammer den de samme UI-valideringer og sikkerhedsregler som en almindelig bruger. Kilden understreger også, at der ikke er et separat backend-lag, der skal skrives for at “se” siden.
DOM-dehydrering og FlatDomTree
Kernen er DOM-dehydrering. En moderne side kan have tusindvis af noder, og rå HTML er for tungt til at sende til en model. Page Agent skanner DOM’en, finder interaktive elementer (knapper, links, input), tildeler indeks, rolle og label, og fjerner overflødig markup. Det komprimerede resultat kaldes en FlatDomTree – et tekstligt kort over, hvad der er vigtigt for handling. Ifølge kilden gør det mindre tekstmodeller i stand til at vælge mere præcist.
Designvalget har konsekvenser. Skift i labels/roller eller DOM-struktur kan påvirke, hvordan elementer identificeres. Stabil semantik i UI’et bliver vigtigere, fordi dehydreringen baserer sig på netop de informationer.
Handlinger indefra siden
Eksekveringen sker via almindelige DOM-hændelser fra siden selv. Ingen headless browser eller DevTools-driver i midten, som kilden formulerer det. Det betyder også, at fejl bliver konkrete i DOM-termer – og kan spores til de elementer, agenten forsøgte at bruge.
Et simpelt, kildenært scenarie er in-app copilots til formularhjælp. Agenten læser relevante felter fra den dehydrerede struktur, indtaster værdier og fortsætter trin for trin. Netop i apps, man selv ejer, fremhæves tilgangen som velegnet, fordi labels og struktur kan holdes stabile over tid.
Ydelse og realisme
Kilderne argumenterer for, at tekstlig adgang til DOM kan reducere friktion og ofte latenstid sammenlignet med billedbaserede tilgange, fordi man flytter fra pixels til komprimeret tekst og direkte DOM-events. Der leveres dog ingen benchmarks. De konkrete gevinster afhænger af model, netværk og implementering.
Det model-agnostiske design betyder, at man kan pege mod et OpenAI-kompatibelt endpoint og bruge en stærk tekstmodel. Det er ikke en anbefaling af en bestemt udbyder – blot en arkitekturfleksibilitet beskrevet i kilden.
Sikkerhed, scope og modelvalg
MarkTechPost kalder to grænser ud: prompt-niveau sikkerhed og et single-page scope. For risikofyldte handlinger anbefales server-side validering. Det er et tydeligt forbehold i materialet.
Brug af eksterne, OpenAI-kompatible endpoints rejser også styringshensyn omkring adgang til brugerdata og isolation. Det fremgår af den medfølgende manual-briefs fokus på governance og isolation som centrale implementeringshensyn.
Hvad Page Agent taber – og hvad den vinder
Ved at undgå skærmbilleder og eksterne drivere mister man mulige visuelle kompensationer for DOM-variationer, som nogle vision-baserede tilgange arbejder med. Til gengæld opnås mere direkte kontrol og gennemsigtighed i DOM. Kilderne beskriver gevinsterne som lavere friktion, tættere kontakt til appens logik og bedre tekstkontekst – især i produkter, man selv ejer.
Kilderne afgrænser samtidig anvendelsen: bedst til in-app copilots og form-fyldning i egne applikationer. Ikke målrettet eksterne eller låste sider.
Multi-turn og evaluering
Så snart en agent skal gennemføre flere trin – læse, handle, tjekke, rette, prøve igen – vokser behovet for træning og evaluering. AWS beskriver best practices for multi-turn læring: en træningsmiljø man kan stole på, ekstern evaluering, belønningsdesign, håndtering af, hvad der ændrer sig i multi-turn, samt overvågning af relevante metrikker. Pointen er, at uden en god evalueringssløjfe risikerer man forkerte genveje. Se AWS’ gennemgang her.
På driftsniveau peger materialet i samme retning: planlæg gradvis indførsel og etabler test- og overvågningsmekanismer, inklusive hensyn til kompatibilitet på tværs af browsere. De hensyn går igen i manual-briefen om vedligeholdelse og cross-browser udfordringer.
Konkrete, kildestøttede startsteder
Kilderne anbefaler at begynde med in-app copilots og formularhjælp i applikationer, man selv ejer. Her kan man styre labels, roller og DOM-stabilitet, som er centrale for DOM-dehydreringens præcision.
Brede automatiseringer på tværs af fremmede sites adresseres ikke som mål for Page Agent. Kildens anbefalinger peger mod afgrænsede flows i eget produktionsmiljø.
Hvad der er sikkert – og hvad der er åbent
Fakta, der fremgår af kilden: klient-side JS, live DOM som tekst, MIT-licens, TypeScript-first, model-agnostisk tekstflow via OpenAI-kompatible endpoints, DOM-dehydrering til FlatDomTree og handlinger i brugerens session med arv af cookies og auth. Forbeholdene: prompt-sikkerhed, single-page scope og anbefalet server-side validering ved risikofyldte skridt.
Åbne spørgsmål er performance og robusthed i konkrete apps. Der er ingen officielle benchmarks i materialet, og resultatet vil afhænge af model, netværk, DOM-kompleksitet og hyppigheden af UI-ændringer.
Implikationer for teams, der bygger webapps
At bruge en in-page agent flytter fokus mod at gøre UI’et maskinlæsbart: tydelige labels og roller, som understøtter DOM-dehydrering. Det er en implikation, der kan udledes af, hvordan FlatDomTree’en dannes og anvendes.
Derudover peger kilderne på governance, isolation/sandboxing, vedligeholdelse af frontend og cross-browser hensyn som væsentlige områder at adressere, inden der skaleres ud over små, afgrænsede flows.
