Remote-Browser: Vergleich der Webinfrastruktur für KI-Agenten

KI-Agenten nutzen Remote-Browser, um Webaufgaben zu automatisieren, ohne von Anti-Scraping-Maßnahmen blockiert zu werden. Die Leistungsfähigkeit dieser Browserinfrastruktur ist entscheidend für den Erfolg eines Agenten.

Wir verglichen acht Anbieter hinsichtlich Erfolgsquote, Geschwindigkeit und Funktionen. Dazu führten wir 160 automatisierte Aufgaben aus und testeten vier verschiedene Szenarien jeweils fünfmal pro Dienst, um dessen Leistung im realen Einsatz zu messen. Zusätzlich führten wir einen Lasttest mit 250 parallelen KI-Agenten durch.

Benchmark-Ergebnisse der besten Remote-Browser

Hier sind die besten Remote-Browser basierend auf ihren Fähigkeiten und ihrer Leistung während unseres Benchmarks:

Der Gesamtscore ist der Durchschnitt der Scores für Erfolgsquote, Geschwindigkeit und Funktionen. Er spiegelt die Kernleistung eines Anbieters in Szenarien mit einer einzigen Aufgabe wider.

Der Skalierbarkeitswert gibt die Erfolgsquote eines Anbieters während unseres Lasttests mit hoher Parallelität an. Diese Kennzahl bewertet explizit die Stabilität und Zuverlässigkeit der Infrastruktur unter dem Einfluss einer hohen Anzahl paralleler Aufgaben. Da dieser intensive Lasttest nicht für jeden Anbieter durchgeführt werden konnte, wird der Skalierbarkeitswert als separate Kennzahl dargestellt.

Die einzelnen Komponenten unseres Bewertungssystems werden im Folgenden erläutert:

Erfolgsquote

Die Auswertung der Benchmark-Ergebnisse zeigt Unterschiede in den Fähigkeiten der führenden Anbieter auf:

• Bright Data hat eine Erfolgsquote von 95 % erreicht.
• BrowserAI, Steel.dev und Anchor Browser weisen Erfolgsquoten von 85 %, 70 % bzw. 70 % auf.
• Browserbase und Airtop weisen niedrigere Erfolgsquoten auf (50 % bzw. 40 %).

Um zu verstehen, wie wir diese Erfolgsquoten berechnet haben, lesen Sie bitte unsere Methodik für die Remote-Browser-Nutzung .

Geschwindigkeit

• Bright Data erreicht eine Geschwindigkeitsbewertung von 100 %.
• BrowserAI bietet die kürzeste Browserstartzeit (durchschnittlich 1 Sekunde).
• Airtop hat die längste Browserzeit (durchschnittlich 160 Sekunden).

Der Geschwindigkeitswert quantifiziert den Durchsatz des Remote-Browserdienstes und gibt die Anzahl der erfolgreich abgeschlossenen Aufgaben pro definierter Zeiteinheit an. Er spiegelt die Gesamteffizienz und Verarbeitungskapazität wider.

Die durchschnittliche Suchzeit für korrekte Ergebnisse misst die Zeit, die der Browser im Durchschnitt für die aktive Interaktion mit Webseiten benötigte, um einzelne Aufgaben erfolgreich abzuschließen. Dies umfasst die Zeit für Seitennavigation, JavaScript-Rendering und direkte Interaktionen mit Elementen (z. B. Klicks, Eingabe).

• Diese Kennzahl schließt jegliche absichtliche Verzögerungen auf Agentenseite oder Verarbeitungszeiten externer Komponenten wie großer Sprachmodelle (LLMs) aus.

Die Browser-Startzeit (avg) misst die durchschnittliche Zeit, die benötigt wird, bis die Remote-Browser-Sitzung bereit ist, nachdem die erste Anfrage zum Erstellen oder Verbinden einer Sitzung gestellt wurde.

Die Gesamtzeit für korrekte Ergebnisse (Durchschnitt) stellt die durchschnittliche Dauer für die einzelnen abgeschlossenen Aufgaben dar.

• Diese Metrik umfasst die Browserstartzeit, alle aktiven Browsing-/Interaktionszeiten, jegliche agentenseitige Verarbeitung oder absichtliche Verzögerungen sowie Kommunikationslatenzen mit externen Diensten (z. B. LLMs), die Teil des Ausführungsablaufs der Aufgabe sind.

Um zu verstehen, wie diese Werte berechnet werden und was die leistungsstärksten Browser auszeichnet, lesen Sie bitte unsere Methodik zur Ermittlung der Gesamtzeit für korrekte Ergebnisse .

Skalierbarkeit

Unser Lasttest, der gemäß der Benchmark-Methodik für die Skalierbarkeit von Remote-Browsern durchgeführt wurde, nutzte 250 gleichzeitig laufende Agenten, um die Infrastrukturleistung unter Last zu messen. Der Test ergab folgende wesentliche Unterschiede:

• BrowserAI erzielte mit 86,4 % die höchste Erfolgsquote und benötigte dafür 220 Sekunden .
• Bright Data verzeichnete eine Erfolgsquote von 81,2 % bei einer Gesamtausführungszeit von 254 Sekunden .
• ZenRows erreichte eine Erfolgsquote von 51,2 % und eine Gesamtausführungszeit von 195 Sekunden .

Gründe für die Leistungsunterschiede

Unsere Benchmark-Ergebnisse zeigen Unterschiede in Zuverlässigkeit, Geschwindigkeit und Skalierbarkeit zwischen führenden Anbietern von Remote-Browsern. Diese Unterschiede resultieren hauptsächlich aus Abweichungen im Infrastrukturdesign, im Sitzungsmanagement und in der Entwicklung von Automatisierungsfunktionen.

1. Strategien zur Infrastruktur- und Ressourcenallokation

Anbieter mit einer fortschrittlicheren, verteilten Infrastruktur erzielen in der Regel höhere Erfolgs- und Geschwindigkeitswerte.

• Bright Data ist führend mit einer Erfolgsquote von 95 % und einer perfekten Geschwindigkeitsbewertung von 100 %, was auf eine starke Lastverteilung, eine schnelle Bereitstellung von Browserinstanzen und eine stabile Sitzungsisolation schließen lässt.
• BrowserAI liegt zwar in der Erfolgsquote etwas hinter Bright Data zurück, weist aber die schnellste Startzeit (1 Sekunde) auf, was auf ein hochoptimiertes Instanz-Bootstrapping hindeutet.

Im Gegensatz dazu greifen leistungsschwächere Anbieter wie Airtop und Browserbase möglicherweise auf langsamere Bereitstellungswarteschlangen oder weniger optimierte Ausführungsumgebungen zurück, was zu ihren niedrigeren Erfolgsquoten (40–50 %) und deutlich längeren Browser- oder Gesamtausführungszeiten beiträgt.

2. Browseroptimierung und Automatisierungsbereitschaft

Die Erfolgsraten unterscheiden sich erheblich, je nachdem, wie gut die einzelnen Anbieter automatisierte Interaktionsmuster wie Formularausfüllung, DOM-Rendering, Navigation und JavaScript-intensive Arbeitsabläufe unterstützen.

• Bright Data, BrowserAI und Steel.dev erledigen Aufgaben im Zusammenhang mit Navigation, Parsing und Interaktion zuverlässig, da ihre Browser für Automatisierungs-Workloads optimiert zu sein scheinen (z. B. Umgang mit Weiterleitungen, Pop-ups, JS-Rendering).
• ZenRows und Hyperbrowser , die sowohl bei den Funktionen als auch bei der Erfolgsquote schlechter abschnitten, bieten möglicherweise keine vollständige Automatisierung oder stoßen bei komplexen Websites auf Schwierigkeiten.

Die Stabilität der Automatisierung scheint ein Hauptgrund für die Streuung der Ergebnisse zu sein, insbesondere bei Aufgaben, die mehrstufige Interaktionen erfordern (E-Commerce-Käufe, Lead-Generierung).

3. Latenz und Browsereffizienz

Unterschiede in der Zeit bis zum Erreichen korrekter Suchergebnisse verdeutlichen die Diskrepanzen in der Effizienz, mit der die einzelnen Browser Seiten verarbeiten:

• Bright Data und BrowserAI laden und interagieren mit Seiten in etwa 2 Sekunden, was auf effektives Caching, effizientes Netzwerk-Routing und schnelle JS-Ausführungsumgebungen schließen lässt.
• Airtop weist eine durchschnittliche Browserzeit von 13,6 Sekunden auf, was auf eine deutlich langsamere Verarbeitung hindeutet, wahrscheinlich aufgrund höherer Netzwerklatenz, langsamerer JS-Ausführung oder Engpässen bei der Ressourcenzuweisung auf Container-/VM-Ebene.

Diese Faktoren beeinflussen sowohl die Geschwindigkeit als auch die Konsistenz bei der Aufgabenerfüllung direkt.

4. Funktionsumfang und Aufgabenabdeckung

Einige Anbieter bieten umfangreichere Funktionsumfänge an, wie z. B.Proxy-Rotation , CAPTCHA-Handling und Mechanismen zur Blockvermeidung, die zu einer höheren Zuverlässigkeit in komplexen Szenarien beitragen (z. B. Google-Suche + LinkedIn-Crawling in Aufgabe 2).

• Bright Data (95 % Funktionsabdeckung) und Anchor Browser (91 %) weisen eine starke Abdeckung der Funktionen auf und unterstützen komplexe Automatisierungsabläufe.
• Steel.dev (45%) und Hyperbrowser (41%) bieten eingeschränktere Funktionen, was ihre niedrigeren Erfolgs- und Geschwindigkeitswerte bei mehrstufigen Aufgaben erklären könnte.

Der Reifegrad der Funktionen korreliert direkt mit dem Gesamtergebnis im gesamten Benchmark.

5. Skalierbarkeit bei hoher Parallelität

Unser Lasttest mit 250 gleichzeitig laufenden Agenten zeigt deutliche Unterschiede in der Skalierbarkeit von Infrastrukturen unter Druck:

• BrowserAI erzielt die höchste Skalierbarkeitsrate (86,4 %) bei kurzen Gesamtausführungszeiten, was auf eine optimierte Orchestrierung und effektive automatische Skalierung schließen lässt.
• Bright Data skaliert mit 81,2 % recht gut, allerdings mit etwas längeren Ausführungszeiten.

Diese Skalierbarkeitsvariabilität ist für Unternehmensanwendungen oder Workloads mit hohem Durchsatz von entscheidender Bedeutung.

Benchmark-Methodik für Remote-Browser

Unsere Benchmark-Methodik dient der Bewertung der realen Leistungsfähigkeit jedes Remote-Browsers anhand zweier Schlüsselfaktoren: Einzelaufgabenausführung und Skalierbarkeit unter Last .

Wir verwendeten Agenten, die von einem fortschrittlichen LLM unterstützt wurden, um eine Reihe realistischer, mehrstufiger Aufgaben auszuführen, die gängige Automatisierungsszenarien nachbilden.

Um einen fairen und einheitlichen Vergleichsmaßstab zu gewährleisten, konzentrierten wir uns auf Dienste, die eine programmatische Steuerung über die Playwright-Automatisierungsbibliothek ermöglichen. Dadurch konnten wir für alle Anbieter dieselbe Codebasis verwenden.

Leistungsbewertung bei Einzelaufgaben

Dieser Teil des Benchmarks bewertet die Zuverlässigkeit und Geschwindigkeit der einzelnen Anbieter bei der Ausführung einzelner, isolierter Automatisierungsaufgaben.

Wie wir die Erfolgsquote gemessen haben

Die Erfolgsquote misst die Zuverlässigkeit der Browserinfrastruktur. Eine Aufgabe wurde nur dann als „erfolgreich“ markiert, wenn der Agent sein endgültiges, nachweisbares Ziel von Anfang bis Ende erreicht hat. Dieser Wert spiegelt die Fähigkeit des Browsers wider, komplexe Websites zu verarbeiten, Blockierungen zu vermeiden und dem Agenten eine stabile Umgebung zu bieten.

Wir haben die folgenden vier Hauptaufgaben durchgeführt:

• Aufgabe 1 – E-Commerce (KI-Käufer):
  • Szenario: Einem KI-Agenten wird ein Budget und Geschenkideen zur Verfügung gestellt. Er durchsucht eine E-Commerce-Website, um das beste Geschenk zu finden und zu kaufen.
  • Ziel: Erfolgreich suchen, navigieren, Formulare ausfüllen und den letzten Schritt der Kaufbestätigung erreichen.
• Aufgabe 2 – Leadgenerierung (KI-SDR):
  • Szenario: Ein KI-Agent erhält einen Firmennamen. Um passende Kontakte zu finden, führt er eine gezielte Google-Suche nach öffentlich indexierten Profilen aus Quellen wie LinkedIn durch. Anschließend durchsucht er die Suchergebnisseite, um Namen potenzieller Leads und Profil-URLs zu extrahieren.
  • Ziel: Mindestens einen gültigen Lead aus den Suchergebnissen identifizieren und dessen LinkedIn-Profilseite aufrufen, um den Zugriff zu überprüfen.
• Aufgabe 3 – Reiseplanung (Reiseassistent):
  • Szenario: Ein KI-Agent navigiert zu Booking.com, um Hotels zu finden. Er gibt das Reiseziel (Miami, South Beach) ein, wählt den An- und Abreisetermin (16.–17. Juni 2025) und startet eine Suche. Auf der Ergebnisseite muss der Agent die angezeigten Hotels identifizieren und analysieren und sie filtern, um Unterkünfte im angegebenen Preisbereich (100–200 US-Dollar) zu finden.
  • Ziel: Mindestens zwei Hotels erfolgreich extrahieren und auflisten, die alle Kriterien (Lage, Preis und Datum) erfüllen.
• Aufgabe 4 – Webformulare (Formularausfüller):
  • Szenario: Ein KI-Agent navigiert zu einer Unternehmenswebsite (aimultiple.com) und muss zunächst alle Cookie-Einwilligungs-Pop-ups bearbeiten. Anschließend findet er das Newsletter-Anmeldeformular, gibt eine Test-E-Mail-Adresse (test@example.com) ein und klickt auf den Button „Abonnieren“, um die Anmeldung abzuschließen.
  • Ziel: Das Formular erfolgreich absenden und einen Bestätigungsstatus erreichen.

Wie wir die Gesamtzeit für korrekte Ergebnisse gemessen haben

Diese Kennzahl misst die Gesamtgeschwindigkeit und Effizienz des Dienstes, wird aber nur für erfolgreiche Durchläufe berechnet. Dadurch wird sichergestellt, dass Anbieter danach beurteilt werden, wie schnell sie eine Aufgabe korrekt erledigen können, ohne für die Zeit, die für fehlgeschlagene Versuche aufgewendet wurde, bestraft zu werden.

Die Zeitmessung beginnt mit dem Start eines Tests und endet, sobald der Agent sein letztes Ziel erfolgreich erreicht hat. Diese Gesamtdauer ist eine umfassende Angabe, die Folgendes beinhaltet:

• Browser-Startzeit: Die anfängliche Zeit, die benötigt wird, um eine Verbindung zum Remote-Browser herzustellen und eine Sitzung für Befehle vorzubereiten.
• Seitennavigation & Rendering: Zeitaufwand für die Ausführung aller page.goto()-Aufrufe und das Warten auf das vollständige Laden und Rendern der Seiten, einschließlich komplexer JavaScript-Anweisungen.
• Agenten-„Denkzeit“: Die Latenzzeit von allen Aufrufen an das Large Language Model (LLM) zur Entscheidung über die nächste Aktion.
• Tool-Ausführungszeit: Die kumulative Dauer aller Browserinteraktionen, wie z. B. .click(), .fill() und das Ausführen benutzerdefinierter Skripte zum Extrahieren von Daten.

Was führt zu einem besseren (schnelleren) Ergebnis?

Eine niedrigere Zeitangabe im Diagramm deutet auf eine effizientere Browserinfrastruktur hin. Anbieter erzielen eine bessere Bewertung, indem sie in folgenden Bereichen herausragende Leistungen erbringen:

• Schnelle Sitzungsinitialisierung: Bietet Verbindungen mit geringer Latenz und kurze Browserstartzeiten, wodurch die anfängliche Wartezeit minimiert wird.
• Effizientes Seitenrendering: Schnelle Verarbeitung von JavaScript-lastigen Seiten und dynamischen Inhalten, sodass der Agent schneller mit den Elementen interagieren kann.
• Stabile und reaktionsschnelle Infrastruktur: Aufrechterhaltung der Leistung ohne Hänger oder Abstürze bei mehrstufigen Aufgaben, Gewährleistung, dass Browser-Interaktionen (.click(), .fill()) ohne Verzögerung ausgeführt werden.

Eine Beispielrechnung

Um dies zu verdeutlichen, sehen Sie sich an, wie ein hypothetischer „Anbieter X“ nach der Ausführung von 10 Aufgaben in unserem Diagramm dargestellt würde:

1. Berechnung der Erfolgsquote:
   • Anbieter X erledigt 7 Aufgaben erfolgreich und 3 Aufgaben nicht .
   • Die Erfolgsquote beträgt 70 % . Dies bestimmt die Position auf der x-Achse.
2. Berechnung der durchschnittlichen Zeit:
   • Die Bearbeitungszeiten für die 7 erfolgreich abgeschlossenen Aufgaben sind: 90s, 95s, 100s, 105s, 110s, 115s und 120s.
   • Die Zeiten für die 3 fehlgeschlagenen Aufgaben werden vollständig ignoriert .
   • Die Durchschnittszeit wird nur aus den erfolgreichen Durchläufen berechnet:
     (90 + 95 + 100 + 105 + 110 + 115 + 120) / 7 = 105 Sekunden
   • Dieser 105s- Wert bestimmt seine Position auf der y-Achse.

Anbieter X würde daher an den Koordinaten (70 %, 105 s) im Leistungsdiagramm platziert. Diese Methodik gewährleistet, dass das Diagramm sowohl die Zuverlässigkeit als auch die tatsächliche Geschwindigkeit jedes Dienstes korrekt widerspiegelt.

Anbieterspezifische Konfigurationen

Um einen fairen und einheitlichen Vergleichsmaßstab zu gewährleisten, der die beabsichtigten Anwendungsfälle jedes Dienstes widerspiegelt, wurden während der Tests spezifische Abonnementpläne und Konfigurationen verwendet:

• Steel.dev: Entwicklerplan.
• Hyperbrowser: Maßstabsplan.
• Anchor Browser: Für alle Aufgaben wurden die folgenden spezifischen Parameter aktiviert:
  • dedicated_sticky_ip: True
  • extra_stealth: {“active”: True}

Diese Konfigurationen dienen dazu, den Leistungsergebnissen einen Kontext zu geben, da unterschiedliche Pläne oder Einstellungen zu unterschiedlichen Ergebnissen führen können.

Skalierbarkeitsleistungsbewertung (Lasttest)

Dieser Benchmark misst die Leistungsfähigkeit der Remote-Browser-Infrastruktur unter gleichzeitiger Last. Die primäre Kennzahl ist die Erfolgsquote, berechnet aus der Anzahl der abgeschlossenen Aufgaben bei paralleler Ausführung von 250 Agenten.

Testarchitektur und -durchführung

Die Testarchitektur nutzte ein Python-Orchestrierungsskript, das die Multiprocessing-Bibliothek verwendete, um einen Pool von 250 Worker-Prozessen zu starten und zu verwalten. Jeder Prozess lief unabhängig, wodurch eine Umgebung mit hoher Parallelität geschaffen wurde, um einen realen, groß angelegten Einsatz zu simulieren.

• Aufgabenverteilung: Jedem Agenten wurde eine individuelle Produktsuchanfrage aus einer vordefinierten Liste zugewiesen. Dieser Ansatz verhindert eine potenzielle Leistungssteigerung durch serverseitiges Caching und simuliert ein abwechslungsreicheres Nutzungsmuster.
• Datenerfassung: Der Orchestrator aggregierte Protokolle und Artefakte (HTML-Inhalte, Screenshots) von jedem Worker-Prozess zur Analyse nach der Ausführung.

Agenten-Workflow

Jeder der 250 Agenten führte eine Reihe automatisierter Schritte auf Amazon.com aus. Eine Aufgabe wurde erst dann als erfolgreich registriert, wenn der gesamte Workflow abgeschlossen war. Die Abfolge war wie folgt:

1. Verbindung: Der Agent hat über seine Treiber-URL eine Verbindung zum Remote-Browser des Anbieters hergestellt.
2. Erste Navigation: Es navigierte zur Startseite der Website und bewältigte alle Anti-Bot-Herausforderungen, um fortzufahren.
3. Identifizierung des Suchfelds: Der Agent erstellte einen Screenshot der Seite und übermittelte diesen an ein LLM mit Bildverarbeitungsfunktion, um den CSS-Selektor für das Hauptsuchfeld zu erhalten.
4. Abfrageausführung: Der Agent nutzte den ermittelten Selektor, um die ihm zugewiesene Abfrage einzugeben und die Suche abzuschicken. Anschließend überprüfte er, ob die Suchergebnisseite geladen wurde, indem er das Vorhandensein eines Produktlistenelements bestätigte.
5. Extraktion der Ergebnislinks: Auf der Ergebnisseite wiederholte der Agent den LLM-Vision-Prozess, um einen CSS-Selektor für Produktlinks zu erhalten. Anschließend filterte er die extrahierten URLs, um direkte Produktseitenlinks zu isolieren und Werbung oder Weiterleitungen auszuschließen.
6. Abschließende Navigation: Der Agent navigierte zu einer der gültigen Produkt-URLs. Das erfolgreiche Laden dieser letzten Seite markierte den Abschluss der Aufgabe.

Definition der Gesamtzeit

Die in den Lasttestergebnissen angegebene „Gesamtzeit“ entspricht der Dauer, die für die vollständige Ausführung aller 250 parallelen Aufgaben benötigt wird. Sie ist ein Maß für die Gesamtbearbeitungszeit der Arbeitslast und wird durch die blockierende Funktion `pool.map` in unserem Orchestrator-Skript gesteuert.

Diese Berechnung berücksichtigt die Ausführungszeit sowohl erfolgreicher als auch fehlgeschlagener Aufgaben. Die Berechnung funktioniert wie folgt:

1. Ein Zeitstempel (start_time) wird unmittelbar vor Beginn der Verteilung der 250 Worker-Tasks durch den Multiprocessing-Pool aufgezeichnet.
2. Der Orchestrator wartet dann, bis alle 250 parallelen Prozesse ihre jeweiligen Arbeitsabläufe vollständig abgeschlossen und ein Ergebnis zurückgegeben haben, unabhängig vom Ausgang (Erfolg oder Misserfolg).
3. Ein endgültiger Zeitstempel wird erst nach Abschluss der längsten Aufgabe erfasst.

Merkmale

Die von führenden Anbietern bereitgestellten Funktionen sind nachfolgend aufgeführt. Die Bewertung jeder Funktion wird gemäß unserer Methodik berechnet und anschließend über alle Funktionen gemittelt. Bei Funktionen mit mehreren Ausprägungen (z. B. Unterstützung mehrerer Programmiersprachen) erhält das Produkt mit den meisten Ausprägungen (z. B. das Produkt mit der größten Unterstützung für Programmiersprachen) die volle Punktzahl von 1, während die übrigen Funktionen anteilig bewertet werden.

In den folgenden Abschnitten werden die Funktionen dieser Dienste detailliert beschrieben:

Technische Fähigkeiten und Fehlerbehandlung

Die technischen Möglichkeiten geben Entwicklern die Flexibilität, mit verschiedenen Websites zu arbeiten, ohne eigene Code-Module erstellen und pflegen zu müssen:

CAPTCHA-Lösung: Diese Funktion erkennt und löst automatisch eine Vielzahl von CAPTCHA-Typen , darunter bildbasierte CAPTCHAs, hCaptcha, reCAPTCHA und Cloudflare-Herausforderungen. Der Dienst verarbeitet auch CAPTCHA-Abfragen mit begrenzter Durchsatzrate und passt sich an sich weiterentwickelnde CAPTCHA-Mechanismen an, um einen konsistenten Zugriff auf geschützte Websites zu gewährleisten.

Fehlerbehandlung: Diese Funktion wertet das Standardverhalten des Dienstes für Standard-HTTP-Statuscodes aus, die für eine zuverlässige Navigation entscheidend sind:

• 404-Fehlererkennung : Das System erkennt und meldet „Nicht gefunden“-Fehler, sodass Agenten fehlende Seiten angemessen behandeln können. Wir haben dies getestet, indem wir eine nicht existierende URL aufgerufen und überprüft haben, ob der Agent eine eindeutige 404-Fehlermeldung vom Dienst erhält und nicht etwa eine ungenaue Antwort (z. B. eine allgemeine Fehlerseite mit dem Statuscode 200 OK).
• 301/302 (Weiterleitungs-)Management : Automatische Weiterleitungsverwaltung, um sicherzustellen, dass der Agent die korrekte Ziel-URL erreicht. Wir haben dies getestet, indem wir eine URL aufgerufen haben, die bekanntermaßen eine Weiterleitung auslöst, und bestätigt haben, dass der Agent ohne manuelles Eingreifen zur Ziel-URL navigiert wird.

JavaScript-Interaktion : Diese Funktion ist für Webseiten mit hohem JavaScript-Aufkommen geeignet und unterstützt die Emulation von Benutzerinteraktionen.

• JavaScript-Ausführung : Rendert JavaScript vollständig, um auf dynamisch geladene Inhalte zuzugreifen.
• Browser-Aktionsautomatisierung : Unterstützt programmatische Interaktionen wie das Klicken auf Elemente, das Eingeben von Text in Felder, das Scrollen von Seiten (einschließlich unendlichem Scrollen), das Warten auf das Erscheinen bestimmter Elemente oder auf eine festgelegte Dauer sowie die Behandlung von Pop-ups oder Modals.
• Elementauswahl : Bietet Methoden zur Auswahl von Elementen, einschließlich CSS-Selektoren und XPath.

Anmeldung: Diese Funktion ermöglicht die Eingabe von Benutzernamen, Passwörtern und anderen Anmeldeinformationen in Anmeldeformulare und die Simulation des Absendens dieser Formulare (z. B. durch Klicken auf Anmeldeschaltflächen). Dies basiert in der Regel auf der grundlegenden Fähigkeit des Browsers zur Interaktion mit Webelementen.

Programmiersprache

Die Abdeckung von Programmiersprachen ermöglicht es Entwicklern, ihren bestehenden Code auf entfernte Browserplattformen zu portieren.

Diese Funktion bewertet den Umfang der vom Dienst angebotenen Programmiersprachenkompatibilität. Eine höhere Anzahl unterstützter Sprachen bedeutet mehr Flexibilität für Entwicklungsteams und ermöglicht ihnen die Integration der Remote-Browser-Funktionen in ihren bevorzugten oder bereits vorhandenen Technologie-Stack.

Sitzungsverwaltung

Sitzungsmanagement ist für längere Interaktionen mit mehreren Schritten (z. B. beim Kauf eines Flugtickets) auf derselben Website erforderlich:

Diese Funktion bewertet die Fähigkeit des Dienstes, den Zustand über mehrere Interaktionen innerhalb einer Browsersitzung hinweg zu verwalten und aufrechtzuerhalten.

• Sitzungspersistenz : Unterstützung für die Beibehaltung einer konsistenten Sitzungs-ID über mehrere Anfragen oder Aktionen hinweg, wodurch mehrstufige Arbeitsabläufe ermöglicht werden.
• Cookie-Verwaltung : Funktionen zur automatischen Verwaltung von Cookies (Speichern, Senden, Löschen) oder zur Ermöglichung des Einfügens/Verwaltens benutzerdefinierter Cookies durch Benutzer zur Aufrechterhaltung des Anmeldezustands oder bestimmter Website-Einstellungen.
• Zustandserhaltung : Die Fähigkeit, den Zustand des Browsers (z. B. ausgefüllte Formulare, Scrollpositionen) über eine Abfolge von Aktionen innerhalb einer einzelnen Aufgabe hinweg zu erhalten.

Geografische Abdeckung

Die geografische Abdeckung umfasst sowohl eine Abdeckung auf Länderebene, sodass Benutzer auf globale Websites zugreifen können, als auch eine detaillierte Abdeckung wie beispielsweise eine gezielte Ansprache auf Basis spezifischer ASN- oder Postleitzahlen.

Stadtbezogene Ausrichtung : Die Möglichkeit, eine bestimmte Stadt als Ursprung für Webanfragen festzulegen. Dies ermöglicht einen hochgradig lokalisierten Datenabruf und Tests und spiegelt wider, was Nutzer in einem bestimmten Stadtgebiet sehen würden.

Postleitzahlenbasiertes Targeting : Die Möglichkeit, Anfragen anhand bestimmter Postleitzahlen gezielt auszurichten. Dies ist besonders relevant für den E-Commerce (Prüfung der lokalen Produktverfügbarkeit, Preise und Versandoptionen) und Dienstleistungen mit hyperlokalen Unterschieden.

ASN-Targeting (Autonome Systemnummer) : Die Möglichkeit, Anfragen über bestimmte Internetdienstanbieter (ISPs) oder Netzwerkblöcke zu leiten, die durch ihre ASN identifiziert werden. Dieses erweiterte Targeting kann nützlich sein, um Datenverkehr aus bestimmten Netzwerksegmenten zu simulieren oder um sehr spezifische Entsperrungsstrategien umzusetzen.

Integrationen

Integrationen in Browserautomatisierungsbibliotheken oder Protokolle wie MCP erleichtern die Nutzung von Agenten :

Playwright-Kompatibilität : Bewertet die Fähigkeit, mit Playwright eine Verbindung zu Remote-Browsersitzungen herzustellen und diese zu steuern.

Puppeteer-Kompatibilität : Bewertet die Integration mit Puppeteer und nutzt dabei häufig Puppeteer-core für die Verbindung zu entfernten Browserinstanzen.

Selenium-Kompatibilität : Misst die Unterstützung für die Steuerung von Remote-Browsersitzungen über Selenium WebDriver .

MCP- Unterstützung (Model Context Protocol) : Gibt an, ob der Dienst eine Integration mit dem Model Context Protocol bietet. MCP dient dem Austausch strukturierter Daten zwischen Tools (wie Browsern) und KI-Modellen (LLMs) und ermöglicht es KI-Agenten, Webinhalte besser zu verstehen und effektiver zu nutzen.

Suchmaschinen

Diese Funktion prüft, ob der Remote-Browser-Dienst spezielle Funktionen oder optimierte Unterstützung für die direkte Extraktion strukturierter Daten von den wichtigsten Suchmaschinenergebnisseiten (SERPs) wie Google, Bing, DuckDuckGo und Baidu bietet.

Sicherheit

Datensicherheit ist für Agenten von entscheidender Bedeutung, insbesondere für diejenigen, die Aktionen auf gesicherten Systemen durchführen. Wir haben anhand ihrer Websites geprüft, ob die Entwickler dieser Remote-Browser über entsprechende Datensicherheitszertifizierungen verfügen.

Anforderungen an Remote-Browser für KI-Agententypen

Die Anforderungen an Remote-Browser variieren je nach Art und Verwendungszweck des KI-Agenten, der sie einsetzt. KI-Agenten lassen sich grob nach ihrem Betriebsmodus kategorisieren, der wiederum spezifische Anforderungen an die Remote-Browser-Infrastruktur stellt:

• Backend-KI-Agenten : Diese Agenten arbeiten typischerweise autonom oder mit minimaler direkter menschlicher Aufsicht und werden häufig durch Systemereignisse oder geplante Aufgaben ausgelöst. Sie benötigen Remote-Browser, die für Stabilität, Skalierbarkeit und robuste Fehlerbehandlung bei längeren Betriebszeiten optimiert sind.
• Echtzeit-KI-Agenten : Diese Agenten interagieren direkt mit Endnutzern, die aktiv auf eine Antwort warten. Für diese müssen Remote-Browser geringe Latenz, hohe Reaktionsfähigkeit und konstante Leistung priorisieren.

Backend-Agenten

Typische Anwendungsfälle und Agenten:

• Bewerberverfolgung und -verwaltung
• AI SDR
• Terminplanung
• Preisüberwachung
• Webautomatisierung

Orchestrator-Arbeiter-Agenten

Diese Agenten nutzen einen Koordinator, der Aufgaben an mehrere spezialisierte Agenten delegiert, die parallel oder nacheinander arbeiten.

Kritische Anforderungen:

• Sitzungspersistenz über Agenten hinweg: Kontext beibehalten, während verschiedene Agenten ihre jeweiligen Teile ausführen.
• Multi-Tab-Koordination: Mehrere Agenten durchsuchen gleichzeitig verschiedene Quellen
• Zuverlässigkeit der Werkzeugausführung: Jeder Agent verwendet unterschiedliche Werkzeuge, die zuverlässig funktionieren müssen.

Bright Data (95 % Erfolgsquote, 95 % Feature-Abdeckung) und BrowserAI (85 % Erfolgsquote, 86 % Features) bewältigen die Multi-Agenten-Koordination zuverlässig.

Überwachungsagenten

Diese Agenten führen in regelmäßigen Abständen geplante Prüfungen an mehreren Zielen durch.

Kritische Anforderungen:

• Geografische Ausrichtung: Präzision auf Stadt- und Postleitzahlenebene für standortspezifische Daten
• Hohe Zuverlässigkeit: Umfangreiche Überwachung verstärkt die Ausfallkosten
• CAPTCHA-Behandlung: Automatische Lösung für unbeaufsichtigten Betrieb

Bright Data erzielt eine Erfolgsquote von 95 % beim Targeting nach Postleitzahl und ASN. BrowserAI erreicht mit ähnlichen Funktionen eine Erfolgsquote von 85 %. Anbieter ohne detailliertes Geo-Targeting übersehen standortspezifische Unterschiede.

Echtzeit-Agenten

Typische Anwendungsfälle und Agenten:

• Forschung: OpenAI Deep Research
• Finanzanalyst

Routing-Agenten

Diese Agenten klassifizieren die Eingaben und leiten sie an die entsprechenden spezialisierten Bearbeiter weiter.

Kritische Anforderungen:

• Schnelle Klassifizierung und Übergabe: Minimierung des Routing-Overheads
• Sofortige Spezialisteninitialisierung: Keine Startverzögerungen nach Routing-Entscheidungen
• Kontexterhalt bei Übergaben: Sitzungsstatus an weitergeleitete Agenten übertragen

BrowserAIs Startzeit von 1 Sekunde reduziert die Latenz beim Multi-Hop-Routing. Bright Data bietet eine Startzeit von 2 Sekunden bei einer Geschwindigkeitsbewertung von 100 %. Airtops Startzeit von 4 Sekunden und die fehlende Zustandserhaltung erhöhen die Gesamtantwortzeit.

Forschungsagenten

Diese Agenten sammeln Informationen aus verschiedenen Quellen und synthetisieren die Ergebnisse.

Kritische Anforderungen:

• Kontext mit mehreren Tabs: Status über mehrere gleichzeitig geöffnete Quellen hinweg beibehalten
• Suchmaschinenabdeckung: Zugang zu verschiedenen Suchplattformen
• Qualität der Inhaltsextraktion: Saubere strukturierte Daten für die LLM-Verarbeitung

Bright Data und BrowserAI unterstützen Google, Bing, DuckDuckGo und Baidu mit einer Funktionsabdeckung von 95 % bzw. 86 %. Steel.dev unterstützt lediglich Google und Bing mit 45 % der Funktionen. Anchor Browser bietet 91 % der Funktionen, jedoch nur eine Erfolgsquote von 70 %.

Zusätzliche Anforderungen

• Schnelle Reaktionen
• Infrastrukturstabilität für die Echtzeitnutzung (d. h. die Antwortzeiten sollten sich bei paralleler Nutzung nicht verschlechtern).

Herausforderungen und Gegenmaßnahmen

Obwohl wir bestrebt sind, für alle Remote-Browser exakt denselben Test durchzuführen, gibt es einige Herausforderungen:

• LLMs arbeiten probabilistisch ; daher fordern unsere Agenten verschiedene Agentenbrowser auf, unterschiedliche Websites aufzurufen. Gegenmaßnahmen: Wir
  • Nutzen Sie Schutzgeländer und eine niedrige Temperatureinstellung, um Abweichungen zu minimieren.
  • Stellen Sie Ihre Fragen so präzise wie möglich.
  • Wir haben jeden Agenten mehrmals ausgeführt (z. B. 5 Mal), um sicherzustellen, dass alle getesteten Lösungen ähnliche Anfragen erhielten.

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 55 % der Fortune 500. Cems Arbeit wurde von führenden globalen Publikationen wie Business Insider, Forbes und der Washington Post, von globalen Unternehmen wie Deloitte und HPE sowie von NGOs wie dem Weltwirtschaftsforum und supranationalen Organisationen wie der Europäischen Kommission zitiert. Weitere namhafte Unternehmen und Ressourcen, die AIMultiple referenziert haben, finden Sie hier. Im Laufe seiner Karriere war Cem als Technologieberater, Technologieeinkäufer und Technologieunternehmer tätig. Über ein Jahrzehnt lang beriet er Unternehmen bei McKinsey & Company und Altman Solon in ihren Technologieentscheidungen. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung. Bei einem Telekommunikationsunternehmen leitete er die Technologiestrategie und -beschaffung und berichtete direkt an den CEO. Darüber hinaus verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von null auf einen siebenstelligen jährlichen wiederkehrenden Umsatz und eine neunstellige Unternehmensbewertung kam. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider gewürdigt. Er ist ein gefragter Redner auf internationalen Technologiekonferenzen. Cem absolvierte sein Studium der Informatik an der Bogazici-Universität und besitzt einen MBA der Columbia Business School.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten