Wanneer automatisering met Agents bij opschaling ineens vastloopt, ligt het probleem vaak niet bij het model of script maar bij de browseromgeving. Dit artikel bespreekt vier veelvoorkomende foutpatronen, hun waarneembare signalen en de bijbehorende technische aanpak.
Een Agent bouwen met LangChain, AutoGen of CrewAI en die via Playwright of Puppeteer websites laten bedienen is niet bijzonder moeilijk. De uitdaging is om hem langdurig te laten doorwerken.
Kort na de livegang zijn problemen meestal nauwelijks zichtbaar. Zodra het taakvolume stijgt, stapelen de afwijkingen zich op: websites blokkeren taken, accountsessies verlopen plotseling of meerdere Agents zitten elkaar in de weg wanneer ze tegelijk draaien. De eerste reactie is vaak om de code na te lopen, om uiteindelijk te ontdekken dat daar niets mis mee is.
Het probleem zit vaak in de laag van de browseromgeving. In projecten die veel draaien, komen de storingen meestal terug in een klein aantal vaste patronen. Als je die eenmaal herkent, zijn ze doorgaans goed te beheersen.
Starten voordat de omgeving gereed is
Wanneer een nieuw aangemaakte browseromgeving direct voor een taak wordt gebruikt, zijn mislukte aanmeldingen, onvolledig geladen pagina-elementen of een verificatie bij de eerste stap heel gebruikelijk. De reden is eenvoudig: de omgeving heeft geen bezoekgeschiedenis, geen cookies en geen browseverleden. Voor het platform lijkt dit op een volledig onbekend apparaat, waardoor het vertrouwen van nature laag is.
Het waarneembare patroon is dat fouten vooral optreden tijdens de eerste paar taken na het aanmaken van de omgeving. Verplaats dezelfde taak naar een omgeving die al enige tijd in gebruik is, en de taak wordt vaak zonder problemen voltooid.
De passende aanpak is om gereedheid van de omgeving als een expliciete status te behandelen in plaats van standaard aan te nemen dat de omgeving bruikbaar is. Laat een nieuwe omgeving eerst een periode met lichte browse-activiteit doorlopen en geef pas echte taken wanneer de status stabiel is. De scheduler hoort deze stap vóór taaktoewijzing te controleren in plaats van een omgeving direct te gebruiken.
Meerdere taken strijden om dezelfde omgeving
Wanneer de paralleliteit toeneemt, is het meest zichtbare symptoom dat processen zich opstapelen, het geheugen volloopt en het systeem trager wordt. Lastiger zijn de verborgen problemen: twee taken gebruiken na elkaar dezelfde cookies en lokale opslag, de aanmeldstatus van A verdringt die van B en in de logs lijkt het alsof af en toe een willekeurige taak faalt. Dat is moeilijk te achterhalen.
Browseromgevingen moeten daarom worden behandeld als resources die kunnen worden aangevraagd en vrijgegeven. Een taak vraagt bij de start één omgeving aan en geeft die na afloop terug, met een één-op-éénrelatie tussen taak en omgeving. Opslag van verschillende omgevingen is onderling niet zichtbaar, zodat de aanmeldstatus van de ene taak niet in een andere terechtkomt. Bij tientallen Agents die parallel draaien wordt het verschil met “in een script gewoon veel browserprocessen starten” zeer duidelijk.
Als het scenario meerdere accounts omvat, moet de isolatie nog strikter zijn: ieder account krijgt een vaste omgeving, waarbij fingerprintparameters en opslag niet overlappen met die van andere accounts. PurpleMark biedt precies deze laag voor omgevingsisolatie en centrale planning, zodat accounts en omgevingen stabiel één op één gekoppeld blijven.
Niemand merkt dat de sessie is verlopen
Dit type storing wordt gemakkelijk gemist omdat er niet per se een foutmelding verschijnt. De taak blijft doorlopen en de logs blijven verschijnen, maar in werkelijkheid wordt een inlogpagina of lege data teruggegeven. Pas wanneer het resultaat de datapipeline bereikt wordt het probleem zichtbaar, waarna het onderzoek vanaf downstream terug moet worden uitgevoerd. Dat kost veel tijd en moeite.
De oplossing is om de aanmeldstatus als expliciete voorwaarde te controleren. Controleer vóór de start van een taak of de huidige sessie nog geldig is. Als die is verlopen, voer dan een volledige aanmeldprocedure uit in plaats van de taak met een ongeldige status verder te laten gaan. De status zelf hoort in de omgevingslaag: cookies, lokale opslag en browsegeschiedenis blijven in de omgeving opgeslagen en kunnen bij een volgende start volledig worden hersteld, zodat accounttaken niet telkens opnieuw hoeven te worden geïnitialiseerd.
Een praktische ervaring: bij accounts die langdurig actief zijn, kunnen frequente veranderingen in de aanmeldstatus op zichzelf al als afwijkend signaal worden gezien en extra verificatie veroorzaken. Vermijd daarom onnodig opnieuw aanmelden.
Een blokkade legt de hele batch stil
Een ander fouttype verschijnt plotseling in groepen: veel taken leveren tegelijkertijd geen resultaat meer op. De website geeft daarbij niet altijd een duidelijke weigering. Vaker wordt beperkte inhoud of een lege pagina teruggegeven, waarna de Agent met waardeloze data doorgaat totdat het probleem pas in de dataverwerking aan het licht komt.
In zo'n situatie is de eerste stap om een blokkade te onderscheiden van een gewone fout. Wanneer dezelfde groep omgevingen rond hetzelfde moment afwijkend gedrag vertoont, ligt de oorzaak zeer waarschijnlijk in de omgevingslaag. Blijven proberen vergroot alleen de impact, dus stop en isoleer deze omgevingen eerst en onderzoek daarna wat de trigger was.
Veelvoorkomende triggers vallen in drie richtingen: meerdere omgevingen gebruiken sterk overlappende fingerprintconfiguraties, zoals vrijwel identieke WebGL-, Canvas-, lettertype- of engineversies; uitgaand IP-adres, tijdzone en taal sluiten niet op elkaar aan, bijvoorbeeld een Amerikaans IP-adres met een Aziatische tijdzone; of de intervallen tussen acties zijn zo regelmatig dat het ritme zelf een herkenbaar patroon wordt. Zorg dat de configuratie klopt, beheers het tempo en log zowel de omgevingsstatus als de taakresultaten zodat vroege signalen zichtbaar worden voordat een hele batch uitvalt.
Haal deze laag apart uit het systeem
Volwassen projecten halen de browseromgeving meestal los van de Agent en behandelen die als een afzonderlijke laag: de Agent doet planning en besluitvorming, de omgevingslaag beheert identiteit en status, en de uitvoeringslaag blijft Playwright of Puppeteer. Na deze scheiding is duidelijk waar je beheert of een identiteit geloofwaardig is, of status kan worden hersteld en of taken onderling geïsoleerd blijven.
Als je de vier bovenstaande fouttypen naast elkaar zet, hebben ze één ding gemeen: ze zitten niet in het model en ook niet in de scriptlogica. Modellen en code moeten natuurlijk verder worden verbeterd, maar of automatisering op lange termijn stabiel blijft werken wordt vaak door deze lagere laag bepaald.
Deze inhoud is bedoeld voor technisch onderzoek en het delen van ontwikkelpraktijken. Automatisering moet rechtmatig en volgens de regels worden gebruikt, met naleving van de servicevoorwaarden van het doelplatform en de toepasselijke lokale wet- en regelgeving.
