Wenn Agent-Automatisierung unter Last plötzlich ausfällt, liegt die Ursache oft nicht im Modell oder Skript, sondern in der Browser-Umgebung. Der Artikel erklärt vier häufige Fehlermuster, ihre beobachtbaren Symptome und passende technische Maßnahmen.
Einen Agenten mit LangChain, AutoGen oder CrewAI aufzubauen und ihn über Playwright oder Puppeteer Webseiten bedienen zu lassen, ist nicht besonders schwer. Schwierig ist, ihn dauerhaft stabil laufen zu lassen.
Direkt nach dem Start sind Probleme oft kaum sichtbar. Sobald das Aufgabenvolumen steigt, häufen sich die Ausfälle: Websites blockieren Aufgaben, Anmeldesitzungen von Konten laufen plötzlich ab oder mehrere Agents kommen sich bei paralleler Ausführung in die Quere. Die erste Reaktion ist häufig, den Code zu prüfen – nur um am Ende festzustellen, dass der Code in Ordnung ist.
Die Ursache liegt oft in der Browser-Umgebung. In Projekten mit hoher Auslastung wiederholen sich die Fehlermuster meist in wenigen Varianten. Sind sie einmal erkannt, lassen sie sich relativ geradlinig behandeln.
Start, bevor die Umgebung bereit ist
Wird eine neu erstellte Browser-Umgebung sofort für eine Aufgabe verwendet, sind fehlgeschlagene Anmeldungen, unvollständig geladene Seitenelemente oder eine Verifizierungsabfrage gleich beim ersten Schritt typische Folgen. Der Grund ist einfach: Die Umgebung hat weder bisherigen Besuchsverlauf noch Cookies noch eine Browser-Historie. Für die Plattform wirkt sie wie ein völlig unbekanntes Gerät, entsprechend gering ist zunächst das Vertrauen.
Beobachtbar ist, dass sich die Fehler auf die ersten Aufgaben direkt nach Erstellung der Umgebung konzentrieren. Verschiebt man dieselbe Aufgabe in eine Umgebung, die schon eine Weile genutzt wurde, läuft sie häufig normal durch.
Die passende Maßnahme besteht darin, die Bereitschaft der Umgebung als expliziten Zustand zu behandeln, statt standardmäßig von Nutzbarkeit auszugehen. Nach der Erstellung sollte die Umgebung zunächst eine Phase mit geringer Browser-Aktivität durchlaufen und erst nach Stabilisierung für produktive Aufgaben eingesetzt werden. Der Scheduler sollte diesen Status vor der Zuweisung einer Aufgabe prüfen, statt eine neue Umgebung sofort zu verwenden.
Mehrere Aufgaben konkurrieren um dieselbe Umgebung
Mit zunehmender Parallelität ist das offensichtlichste Symptom, dass immer mehr Prozesse entstehen, der Speicher vollläuft und das System langsamer wird. Problematischer sind verdeckte Fehler: Zwei Aufgaben verwenden nacheinander dieselben Cookies und denselben lokalen Speicher, der Login-Zustand von A verdrängt den von B, und in den Logs sieht es so aus, als würde gelegentlich irgendeine zufällige Aufgabe scheitern. Das ist schwer zu lokalisieren.
Browser-Umgebungen sollten deshalb wie Ressourcen behandelt werden, die angefordert und wieder freigegeben werden können. Beim Start erhält jede Aufgabe eine Umgebung und gibt sie nach Abschluss zurück; Aufgabe und Umgebung stehen dabei eins zu eins zueinander. Speicherbereiche verschiedener Umgebungen sind gegenseitig unsichtbar, sodass der Login-Zustand einer Aufgabe nicht in eine andere hineinwirkt. Bei mehreren Dutzend parallel laufenden Agents wird der Unterschied zu „im Skript einfach viele Browser-Prozesse starten“ sehr deutlich.
Wenn das Szenario mehrere Konten umfasst, muss die Isolation noch konsequenter sein: Jedes Konto erhält eine feste Umgebung, deren Fingerprint-Parameter und Speicher sich nicht mit denen anderer Konten überschneiden. PurpleMark stellt dafür die Ebene zur Umgebungsisolation und zentralen Planung bereit, damit Konten und Umgebungen dauerhaft in einer stabilen Eins-zu-eins-Zuordnung bleiben.
Abgelaufene Sitzungen bleiben unbemerkt
Dieser Fehler wird leicht übersehen, weil nicht unbedingt eine Fehlermeldung erscheint. Die Aufgabe läuft weiter und die Logs werden geschrieben, tatsächlich wird aber eine Login-Seite oder ein leerer Datensatz zurückgegeben. Erst wenn das Ergebnis die Datenpipeline erreicht, fällt das Problem auf, und die Fehlersuche muss vom Ende her rückwärts erfolgen. Das ist teuer.
Der Login-Zustand sollte deshalb als explizite Vorbedingung geprüft werden. Vor dem Start einer Aufgabe wird kontrolliert, ob die aktuelle Sitzung noch gültig ist. Ist sie abgelaufen, wird ein vollständiger Login-Prozess ausgeführt, statt die Aufgabe mit einem ungültigen Zustand fortzusetzen. Der Zustand selbst gehört in die Umgebungsebene: Cookies, lokaler Speicher und Browser-Verlauf liegen in der Umgebung und können beim nächsten Start vollständig wiederhergestellt werden, sodass Kontenaufgaben nicht jedes Mal neu initialisiert werden müssen.
Eine praktische Erfahrung: Bei langfristig genutzten Konten können häufige Änderungen des Login-Zustands selbst als auffälliges Signal gewertet werden und zusätzliche Verifizierung auslösen. Unnötige Neuanmeldungen sollte man daher vermeiden.
Nach einer Blockierung steht die ganze Gruppe still
Ein weiteres Fehlermuster tritt plötzlich in größeren Gruppen auf: Viele Aufgaben liefern gleichzeitig keine Ergebnisse mehr. Die Website muss dabei keine eindeutige Ablehnung anzeigen. Häufiger wird abgespeckter Inhalt oder eine leere Seite zurückgegeben, während der Agent mit bedeutungslosen Daten weiterarbeitet und das Problem erst später in der Datenverarbeitung sichtbar wird.
In diesem Fall muss zuerst zwischen einer Blockierung und einem gewöhnlichen Fehler unterschieden werden. Wenn dieselbe Gruppe von Umgebungen ungefähr zur gleichen Zeit auffällig wird, spricht vieles dafür, dass die Ursache in der Umgebungsebene liegt. Weitere Wiederholungsversuche vergrößern dann nur den betroffenen Bereich. Die Umgebungen sollten zunächst gestoppt und isoliert werden, bevor die Auslöser untersucht werden.
Typische Auslöser lassen sich in drei Richtungen einteilen: Mehrere Umgebungen verwenden stark überlappende Fingerprint-Konfigurationen, etwa nahezu identische Werte für WebGL, Canvas, Schriftlisten oder Engine-Versionen; Ausgangs-IP, Zeitzone und Sprache passen nicht zusammen, zum Beispiel eine US-IP mit asiatischer Zeitzone; oder die Abstände zwischen Aktionen sind so regelmäßig, dass schon der Rhythmus zum Merkmal wird. Konfigurationen müssen konsistent sein, das Timing kontrolliert und sowohl Umgebungszustand als auch Aufgabenergebnisse protokolliert werden, damit Warnzeichen vor einem größeren Ausfall sichtbar werden.
Diese Ebene separat behandeln
Reifere Projekte lösen die Browser-Umgebung in der Regel vom Agenten und behandeln sie als eigene Ebene: Der Agent übernimmt Planung und Entscheidungen, die Umgebungsebene Identität und Zustand, und die Ausführung erfolgt weiterhin über Playwright oder Puppeteer. Durch diese Trennung gibt es klare Zuständigkeiten dafür, ob eine Identität plausibel ist, ob sich ein Zustand wiederherstellen lässt und ob Aufgaben voneinander isoliert bleiben.
Rückblickend haben die vier Fehlerarten etwas gemeinsam: Sie liegen weder im Modell noch in der Skriptlogik. Modell und Code müssen natürlich weiter verbessert werden, aber ob eine Automatisierung langfristig stabil läuft, entscheidet sich häufig auf dieser tieferen Ebene.
Diese Inhalte dienen dem Austausch zu technischer Forschung und Entwicklungspraxis. Automatisierung sollte nur rechtmäßig und regelkonform eingesetzt werden und die Nutzungsbedingungen der Zielplattform sowie die geltenden lokalen Gesetze und Vorschriften beachten.
