Een Agent Browser laat een model bepalen hoe een webpagina wordt bediend in plaats van vooraf vastgelegde stappen te volgen. De belangrijkste verschillen zitten in wie beslist, hoe de pagina wordt gelezen, hoe acties worden uitgevoerd en waar de praktische grenzen liggen.
Browserautomatisering met scripts is bekend: elementen lokaliseren, paden vastleggen, foutafhandeling toevoegen en stabiel draaien — totdat de pagina wordt aangepast. Als een wijziging een belangrijk punt raakt, moet vaak het hele script opnieuw worden geschreven, omdat de code een concrete structuur herkent en juist die structuur het gemakkelijkst verandert.
Een Agent Browser kiest een andere aanpak. Het model kijkt naar de inhoud van de pagina en beslist wat de volgende stap moet zijn. Daardoor is het systeem ook minder gevoelig voor redesigns.
Verschil 1: wie beslist over de volgende stap
In een traditioneel script wordt het pad door een mens geschreven. Waar eerst wordt geklikt, wat daarna wordt ingevuld en hoe lang vervolgens wordt gewacht, ligt vooraf vast. Tijdens de uitvoering volgt het script alleen die instructies.
Een Agent Browser geeft de beslissingen aan het model. Je beschrijft het doel, bijvoorbeeld inhoud uit een bron onder bepaalde voorwaarden in een tabel ordenen. Welke pagina moet worden geopend, of eerst moet worden gefilterd of gebladerd en hoe een pop-up wordt afgehandeld, wordt tijdens de uitvoering bepaald.
Dit verschil wordt gemakkelijk onderschat. De onderhoudskosten verschuiven van code schrijven naar eisen helder formuleren. De technische moeilijkheid neemt af, maar een nauwkeurige doelomschrijving wordt belangrijker.
Verschil 2: hoe het weet wat er op de pagina staat
Scripts herkennen elementen met selectors. XPath- en CSS-selectors wijzen naar de positie van een knooppunt in de structuur. Verandert die positie, dan werkt de selector niet meer.
Een Agent Browser stuurt in plaats daarvan structuurinformatie van de pagina of een screenshot naar het model. Het model bepaalt dat dit een inlogknop is, dat daar een zoekveld staat en dat een ander gebied de productprijs toont. De interpretatie is meer semantisch dan gebaseerd op coördinaten.
Daar staat een duidelijke prijs tegenover. Om het model een pagina te laten begrijpen, moeten de DOM-structuur of screenshots worden meegestuurd; hoe complexer de pagina, hoe meer gegevens nodig zijn. Bij lange taken kunnen die kosten flink oplopen. Elke stap moet bovendien wachten op de inferentie van het model, waardoor het geheel duidelijk trager is dan een hardgecodeerd script.
Verschil 3: hoe acties worden uitgevoerd
Na de beslissing moet de actie nog echt plaatsvinden. Zulke tools verpakken browserfuncties meestal als aanroepbare acties: een pagina openen, klikken, een formulier invullen, inloggen, een bestand uploaden, scrollen of pagineren en gegevens extraheren. Het model geeft aan welke actie met welke parameters moet worden aangeroepen. De browser voert die uit en stuurt het resultaat terug naar het model als invoer voor de volgende ronde.
Ook het opdelen van taken en het corrigeren van fouten gebeurt op deze laag. Een doel wordt in meerdere stappen gesplitst en in volgorde uitgevoerd. Als het model merkt dat het een verkeerde route heeft genomen, kan het een andere ingang proberen in plaats van direct met een fout te stoppen. Dit is vooral belangrijk op onregelmatig opgebouwde pagina's, waar de voltooiingsgraad sterk afhangt van het herstelgedrag.
Wat vandaag al werkt
Taken met veel voorspelbaarheid en duidelijke stappen kunnen al worden uitgevoerd: openbare informatie volgens voorwaarden verzamelen en in gestructureerde gegevens omzetten; herhaalde invoer en geformatteerde verzendingen in eigen systemen uitvoeren; of een specifieke pagina volgen en een melding geven wanneer prijzen, voorraad of aankondigingen veranderen. Deze scenario's hebben drie dingen gemeen: het pad is voorspelbaar, fouten kunnen opnieuw worden geprobeerd en een mens kan het resultaat controleren.
Waar het nog niet stabiel is
Semantische interpretatie levert het snelst problemen op. Om te bepalen of op een knop moet worden geklikt, moet het model eerst de zakelijke betekenis begrijpen. Bij complexe pagina's of onverwachte teksten ontstaan vergissingen: de verkeerde ingang wordt gekozen of het verkeerde veld wordt uitgelezen. Hoe dieper de procesketen, hoe gemakkelijker fouten zich opstapelen. Een kleine afwijking aan het begin kan later niet meer te herstellen zijn.
Sterk tegenwerkende situaties zijn nog lastiger. CAPTCHA's, risicoblokkades en verlopen inlogsessies hangen vooral af van de onderliggende omgeving en niet van het model zelf. Hoe slim het model ook is, het kan een geweigerd verzoek niet in een geslaagd verzoek veranderen. Cloudgebaseerde uitvoering en door de dienstverlener beheerde proxy's kunnen een deel van het probleem afdekken, maar brengen ook gebruikskosten en afhankelijkheid van infrastructuur van derden mee.
Waar je op moet letten bij de keuze
Of de uitvoering kan worden bekeken en afgespeeld, wordt vaak vergeten, maar is bij problemen het belangrijkste diagnosemiddel. Kijk ook naar foutcorrectie: stopt de tool bij een fout of probeert hij een andere route? Controleer of modelkeuze en kosten beheersbaar zijn, want lange taken vallen vaak duurder uit dan verwacht. Bekijk of eigen tools en workflows kunnen worden gekoppeld en controleer tot slot hoe de inlogstatus behouden blijft. Alles opnieuw moeten doen omdat een sessie verloren ging, is erg vervelend.
Maak de regels duidelijk vóór gebruik
Wat technisch mogelijk is, is niet hetzelfde als wat is toegestaan. Controleer eerst of de servicevoorwaarden van het doelplatform geautomatiseerde toegang toelaten en of de aanvraagfrequentie het platform kan belasten. Dit soort tools gebruiken om massaal accounts te registreren of automatisch platformtaken uit te voeren in ruil voor opbrengsten, is in strijd met platformregels. Platforms worden beter in het herkennen van bedieningsritme, gedragspaden en consistente omgevingen, en maatregelen treffen vaak meerdere accounts tegelijk.
Als de taak zelf wel conform de regels is, maar meerdere accounts hun eigen inlogstatus gescheiden moeten houden, wordt omgevingsisolatie relevant. PurpleMark biedt bijvoorbeeld onafhankelijke omgevingen, zodat de sessie en opslag van elk account niet zichtbaar zijn voor de andere accounts.
Een praktische manier om een tool te testen is een kleine, bekende taak met duidelijke stappen te kiezen, die volledig te laten uitvoeren, het resultaat met handmatig werk te vergelijken, vast te leggen hoe de tool op fouten reageert en de werkelijke tijd te berekenen. Als één kleine taak goed loopt, kun je daarna uitbreiden. Meteen het hele proces willen automatiseren loopt meestal ergens halverwege vast.
