Bei Webaufgaben von Agents entstehen Fehler häufig in vier Bereichen: Elementlokalisierung, Wartezeiten und Timeouts, Zustandsspeicherung sowie Blockierungen durch die Laufzeitumgebung. Idempotente Schritte, gezielte Wiederholungen, persistierter Zustand und getrennte Umgebungen pro Aufgabe machen die Erfolgsquote deutlich stabiler.
Beim Einstieg in die Webautomatisierung wirkt der Ansatz meist einfach: Ablauf festlegen und das Skript ausführen. Die Logik sieht korrekt aus, trotzdem schlagen Aufgaben sporadisch fehl und Kontozustände verhalten sich gelegentlich ungewöhnlich. Zuerst sucht man den Fehler im Code, doch bei genauerer Analyse konzentrieren sich die Ursachen meist auf vier Bereiche.
Eine Seitenänderung macht die Elementlokalisierung unbrauchbar
Die meisten Skripte suchen Elemente über Selektoren. Sobald ein Selektor fest verdrahtet ist, kann nahezu jede Seitenänderung ihn brechen: Eine Schaltfläche erhält einen anderen Klassennamen, ein Wort im Text ändert sich, ein Bereich wechselt von serverseitigem Rendering zu asynchronem Laden oder ein Element wird in einen neuen Container verschoben. Bei einem A/B-Test kann dieselbe Seite für verschiedene Konten sogar unterschiedliche Strukturen haben.
Typische Symptome sind nicht auffindbare Elemente, Klicks an der falschen Stelle oder ein Klick auf ein gleichnamiges Steuerelement an einer anderen Position. Solche Fehler entstehen nicht durch Netzwerkschwankungen und verschwinden auch nach mehreren Wiederholungen nicht.
Sinnvoll ist, weniger von absoluten Pfaden abhängig zu sein. Bevorzugt werden sollten Accessibility-Attribute, stabile fachliche IDs oder relative Beziehungen zwischen Elementen; für denselben Seitentyp sollten alternative Selektoren vorbereitet werden, auf die automatisch zurückgefallen wird, wenn der primäre Selektor ausfällt. Enthält die Seite ein iframe oder Shadow DOM, muss zuerst in den richtigen Kontext gewechselt werden, sonst schlägt die Suche sicher fehl.
Wartezeiten und Timeouts liegen im falschen Bereich
Ist die Wartezeit zu kurz, wird ein Element als fehlgeschlagen bewertet, bevor es gerendert ist, was wie ein Skriptfehler wirkt. Ist sie zu lang, wächst die Laufzeit einzelner Aufgaben unnötig, der Durchsatz sinkt und lange Timeouts können den eigentlichen Fehler verdecken.
Zuverlässiger als ein festes sleep sind explizite Wartebedingungen: etwa bis das Zielelement erscheint, eine Anfrage zurückkommt oder eine Ladeanimation verschwindet. Timeout-Budgets sollten gestaffelt werden, mit eigenen Grenzen für Einzelschritt, Seite und Gesamtaufgabe, die schrittweise enger gefasst werden, statt überall denselben Wert zu verwenden.
Außerdem muss zwischen „Seite ist nutzbar“ und „fachliches Ergebnis wurde erzeugt“ unterschieden werden. Für Ersteres reicht es meist, auf einen bereiten DOM zu warten; für Letzteres muss gegebenenfalls auf einen API-Callback oder eine Änderung des Statustexts gewartet werden. Wer auf das falsche Signal wartet, kann einen scheinbar erfolgreichen Ablauf erhalten, obwohl die Daten gar nicht geschrieben wurden.
Bei mehrstufigen Aufgaben geht unterwegs der Fortschritt verloren
Registrierung, Bestellung oder Veröffentlichung umfassen schnell mehr als zehn Schritte. Beendet sich der Prozess zwischendurch, etwa durch Timeout, Browserabsturz oder Neustart des Hosts, und liegt der Zustand nur im Arbeitsspeicher, muss der nächste Lauf entweder von vorn beginnen oder den vorherigen Schritt erneut absenden.
Doppelte Ausführung ist oft schwerer zu untersuchen als ein einfacher Fehlschlag: Dieselbe Aktion wird zweimal ausgeführt, im vorgelagerten System entsteht ein zusätzlicher Datensatz und dessen Herkunft ist schwer nachzuvollziehen.
Die Lösung ist ein Persistenzpunkt für jeden Schritt. Nach jedem abgeschlossenen Schritt wird der Fortschritt zusammen mit einer eindeutigen Aufgaben-ID dauerhaft gespeichert; nach einem Neustart geht es am letzten erfolgreichen Punkt weiter. Dafür ist kein komplexes Framework nötig, eine Datei oder ein einzelner Zustandsdatensatz genügt.
Blockierungen durch die Umgebung sehen aus wie Codefehler
Die ersten drei Problemklassen liegen innerhalb der Aufgabe, eine weitere kommt von der Umgebung. Eine Website kann Browsermerkmale, Zugriffsverhalten und Netzwerkherkunft gemeinsam auswerten. Wird der Zugriff als verdächtig eingestuft, kann sie eine Prüfseite, leeren Inhalt oder schlicht einen Timeout liefern. Im Aufgabenprotokoll ist das kaum von einem Ausführungsfehler zu unterscheiden.
Typische Auslöser sind:
- Region der Ausgangs-IP, Zeitzone und Sprache passen nicht zusammen
- Alle Aufgaben senden aus derselben Browserumgebung, wodurch die Anfragedichte pro Zeiteinheit deutlich über der realer Nutzer liegt
- Die Umgebung wechselt häufig oder das Konto meldet sich wiederholt neu an
Vier Maßnahmen für eine höhere Erfolgsquote
- Jeden Schritt idempotent gestalten. Vor der Ausführung prüfen, ob die Voraussetzung bereits erfüllt ist, damit eine Wiederholung keine zusätzlichen Nebenwirkungen erzeugt. Leseoperationen sind von Natur aus idempotent; Schreiboperationen brauchen eine eindeutige Kennung oder einen Deduplizierungsschlüssel.
- Fehler klassifizieren. Temporäre Fehler wie noch nicht gerenderte Elemente, Netzwerkschwankungen oder eine API-Antwort mit 5xx können mit Backoff wiederholt werden. Deterministische Fehler wie Kontosperren, ungültige Parameter oder eine fehlende Zielressource ändern sich durch weitere Versuche nicht und sollten beendet werden, statt dauerhaft Parallelitätskapazität zu belegen.
- Zustand regelmäßig persistieren. Fortschritt, Zwischenergebnisse und aktueller Schritt werden gespeichert, damit die Aufgabe nach einem Neustart fortgesetzt wird und nicht wieder bei Schritt eins beginnt.
- Laufzeitumgebung pro Aufgabe isolieren. Jedes Konto oder jede Aufgabe erhält eine eigene Browserumgebung; Cookies und lokaler Speicher werden nicht geteilt, Fingerprint-Merkmale unterscheiden sich in plausibler Weise und Zeitzone sowie Sprache passen zur Region der Ausgangs-IP.
Der vierte Punkt wird mit wachsender Aufgabenmenge besonders wichtig. Wenn Dutzende oder Hunderte Aufgaben parallel laufen, bestimmt die Umgebungsebene die Obergrenze der Stabilität und die Größe des möglichen Auswirkungsbereichs. PurpleMark bietet für solche Szenarien die bedarfsgerechte Erstellung und gebündelte Freigabe isolierter Umgebungen, sodass jedes Konto seine eigene Umgebung hat und sich Zustände zwischen Aufgaben nicht gegenseitig beeinflussen.
Diese Inhalte dienen ausschließlich der technischen Forschung und dem Austausch über Entwicklungspraxis. Verwenden Sie die genannten Technologien nur rechtmäßig und regelkonform und beachten Sie die Nutzungsbedingungen der Zielplattform.
