KI-Agenten im Browser: So funktioniert Browser Use

Mit Browser Use können KI-Agenten Aufgaben auf Webseiten erledigen, während die Automatisierung in der eigenen Anwendung bleibt. Die Open-Source-Bibliothek setzt Python 3.11 oder neuer voraus; Browser Use Cloud kann den Browser oder den gesamten Agenten betreiben. Für den Einstieg eignet sich eine Aufgabe mit überprüfbarem Ergebnis, etwa das Auslesen eines Datensatzes in einem Portal. Erst danach sollte der Agent Änderungen übermitteln dürfen.

Am 2. November 2026 mit der README von Browser Use auf GitHub und der verlinkten offiziellen Dokumentation abgeglichen. Die folgende Anleitung basiert auf diesen Quellen; sie ist kein selbst durchgeführter Leistungstest.

Wie Browser Use KI-Agenten durch Webseiten steuert

Browser Use verbindet ein Sprachmodell mit einem Browser. Dadurch kann die Anwendung ein Ziel vorgeben, statt jeden Klick einzeln festzulegen. Das eignet sich etwa für die Suche nach einem Datensatz im Lieferantenportal, das Auslesen eines Dashboards oder ein Formular, dessen nächste Seite von der vorherigen Antwort abhängt. Die Open-Source-Bibliothek stellt den Agenten bereit: die Software, die wiederholt Aktionen auswählt und ausführt, um dieses Ziel zu erreichen. README der Bibliothek

Das Sprachmodell lässt sich mit einem Fahrer vergleichen, Browser Use mit den Bedienelementen und Rückmeldungen im Cockpit und der Browser mit dem Fahrzeug. Die Straße gehört allerdings weiterhin jemand anderem: dem Betreiber der Webseite. Auch ein guter Fahrer kann eine gesperrte Straße nicht befahrbar machen. Und aus einem Lieferauftrag darf er keine Erlaubnis für einen sachfremden Einkauf ableiten.

Der Ablauf wiederholt sich in einer Schleife:

1. Beobachten: Der aktuelle Seitenzustand einschließlich der interaktiven Elemente wird erfasst. Browser Use kann dem Modell zusätzlich Screenshots übergeben.
2. Entscheiden: Das große Sprachmodell, kurz LLM, wählt anhand der Aufgabe und des aktuellen Zustands die nächste Aktion aus.
3. Handeln: Der Browser navigiert, klickt, gibt Text ein oder führt eine andere verfügbare Aktion aus.
4. Erneut beobachten: Die nächste Entscheidung beruht auf der veränderten Seite. Das geht weiter, bis der Agent stoppt oder eine konfigurierte Grenze den Ablauf unterbricht.

Das DOM, die Baumstruktur der Seitenelemente, macht Bedienelemente für den Agenten zugänglich; Screenshots liefern zusätzlichen visuellen Kontext. Browser Use dokumentiert sowohl die DOM-Verarbeitung als auch eine konfigurierbare Bildauswertung. Die Beschreibung als Modell, das lediglich Bilder betrachtet, greift deshalb zu kurz. Browsersteuerung, Agenteneinstellungen

Wer als Gründer einen Einkaufsassistenten entwickelt, könnte mit der Aufgabe „Finde den Versandstatus dieser Bestellung“ beginnen. Bei der Abnahme zählen die richtige Bestellung, ihr Status und der zugehörige Quelldatensatz. Ein überzeugend formulierter Absatz des Agenten reicht dafür nicht aus.

Browser Use als Open Source: Browser Automation einrichten

Die Grundausstattung besteht aus dem Python-Paket browser-use, einem steuerbaren Browser und dem Zugang zu einem unterstützten Modell. Die Bibliothek steht unter der MIT-Lizenz. Laut README ist Python 3.11 oder neuer erforderlich; die Schnellstartanleitung verwendet Python 3.12. Der Agent kann im eigenen Prozess laufen und einen lokalen oder entfernten Browser nutzen. README und Installation

„Lokal“ bezeichnet dabei den Ausführungsort des Prozesses oder Browsers. Wer eine entfernte Modell-API auswählt, sendet die erfassten Beobachtungen weiterhin an diesen Modelldienst. Ein lokaler Browser macht das Gesamtsystem also nicht automatisch lokal.

Welche Modelle lassen sich einsetzen?

Browser Use unterstützt Adapter für mehrere Anbieter. Das eigene Modell des Projekts ist daher keine Voraussetzung:

• Browser Use BU2: ChatBrowserUse(model="bu-2-0"), mit BROWSER_USE_API_KEY.
• Modelle von OpenAI: ChatOpenAI, mit OPENAI_API_KEY.
• Claude-Modelle von Anthropic: ChatAnthropic, mit ANTHROPIC_API_KEY.
• Gemini-Modelle von Google: ChatGoogle, mit GOOGLE_API_KEY.
• Lokale Modelle über Ollama: ChatOllama, verbunden mit dem lokalen Modelldienst.

Die Dokumentation der unterstützten Modelle führt außerdem Integrationen für DeepSeek, Mistral, Microsoft Azure OpenAI, Amazon Web Services Bedrock und OpenRouter auf. Maßgeblich ist die aktuelle Modellverfügbarkeit beim jeweiligen Anbieter. Eine alte Modell-ID aus einem Beispiel sollte nicht als Empfehlung gelten.

Ein vorhandener Adapter garantiert keine guten Ergebnisse. Dieselbe Dokumentation warnt, dass manche Qwen-Modelle ein fehlerhaftes Aktionsschema erzeugen: Anweisungen in einem Format, das der Agent nicht ausführen kann. Für diese Integration empfiehlt sie derzeit qwen-vl-max. Bevor ein Modell zusätzliche Aufgaben übernimmt, sollte es auf den tatsächlich verwendeten Seiten und anhand der benötigten Ergebnisse geprüft werden.

Die Weboberfläche von Browser Use

Browser Use Web UI ist ein separates Projekt mit einer Gradio-Oberfläche, über die sich der Agent im Browser bedienen lässt. Es hat eine eigene Installation und eigene Abhängigkeiten. Für die Integration in eine Anwendung ist die aktuelle Dokumentation der Python-Bibliothek der richtige Ausgangspunkt. Die Einrichtung aus dem Web-UI-Repository darf dabei nicht mit dem SDK des gehosteten Dienstes vermischt werden.

Was Browser Use Cloud übernimmt

Browser Use Cloud kann die Browserinfrastruktur, den gesamten Agenten oder beides übernehmen. Davon hängt ab, wie viel Code selbst betrieben werden muss. Die aktuelle Cloud-Schnellstartanleitung unterscheidet diese Wege ausdrücklich:

Beim eigenen Agenten wählt Browser(use_cloud=True) den von Browser Use gehosteten Browser aus. Dafür ist BROWSER_USE_API_KEY erforderlich. Der verwaltete Browser bietet Stealth-Funktionen, Proxys und eine Live-Vorschau. Die README beschreibt außerdem die Handhabung von CAPTCHAs, weist aber ausdrücklich darauf hin, dass die Ergebnisse von der Webseite und der jeweiligen Abfrage abhängen. Anleitung zum Cloud-Browser, README

Bei der dokumentierten Infrastrukturvariante erfolgt die Fernsteuerung über CDP, das Chrome DevTools Protocol. Ein gehosteter Browser lässt sich damit auch aus Code steuern, der weiterhin in der eigenen Umgebung läuft.

Für die vollständig gehostete Variante heißt das Paket browser-use-sdk, nicht browser-use. Aktuelle Cloud-Beispiele verwenden API V4 und den Python-Import from browser_use_sdk.v4 import BrowserUse. Das eigene Programm übermittelt eine Aufgabe und ruft das Ergebnis ab, statt die lokale Agent-Schleife auszuführen. Schnellstart für gehostete Agenten

Aus Entwicklersicht ist das eine Entscheidung über die Bereitstellung. Für den Betrieb bleibt dieselbe Verantwortung: festlegen, worauf der Agent zugreifen darf und welche Nachweise eine Aufgabe als erledigt gelten lassen.

Wann sich eine Alternative zu Browser Use anbietet

Entscheidend ist, welche Ebene selbst kontrolliert werden soll. Browser Use ist ein guter Ausgangspunkt, wenn sich die Aufgabe vollständig auf Webseiten abspielt und eine fertige Browseragentenschleife mit freier Modellwahl gefragt ist. Eine Computer-Use-API passt, wenn die Anwendung auf deren Aktionsschnittstelle aufbauen soll oder Aufgaben außerhalb von Webseiten anstehen.

OpenAI bietet außerdem eine separate Agents API mit einem von OpenAI gehosteten Browser. Die Faustregel „Computer Use bedeutet immer, den Browser selbst zu hosten“ hilft daher nicht mehr weiter. Auch Browserbase bietet Agentenprodukte über die Browserinfrastruktur hinaus.

Browser Use und Browserbase schließen sich nicht grundsätzlich aus: Browser Use akzeptiert eine cdp_url, und Browserbase stellt eine CDP-Verbindungs-URL bereit. Über diese dokumentierten Schnittstellen lässt sich die Agentenbibliothek mit dieser Laufzeitumgebung verbinden. Dieser Artikel beansprucht allerdings nicht, die Integration getestet zu haben. Verbindungseinstellungen von Browser Use

Eine bestehende, zuverlässige API-Anbindung oder ein festes Browserskript sollte bleiben, wenn es die Aufgabe bereits erfüllt. Ein stabiles Formular gewinnt nichts dadurch, dass ein Modell denselben Ablauf immer wieder neu herleiten muss. Der umfassendere Leitfaden zu Computer-Use-Agenten behandelt die Wahl der Steuerung; der Vergleich von Browsern für KI-Agenten betrachtet die Infrastruktur.

Welche Risiken die eigene Anwendung abfangen muss

Die schwierigste Grenze im Produktivbetrieb betrifft die Rechte des angemeldeten Browsers. Ein anderer Hostingort macht Anweisungen auf Webseiten weder vertrauenswürdig noch beseitigt er die Folgen einer irrtümlich übermittelten Änderung.

Prompt Injection durch Seiteninhalte

Bei einer Prompt Injection versuchen Inhalte, die der Agent liest, seine Anweisungen umzulenken. In einem Portal könnte das eine von einem Kunden eingegebene Notiz sein, die den Agenten auffordert, einen Bericht an einem anderen Ziel hochzuladen. Die Notiz ist als Dateneingabe zu behandeln, selbst wenn sie sich als Anweisung eines Administrators ausgibt.

Dafür eignen sich eigene Konten, die nur die für die Aufgabe nötigen Rechte erhalten. Die Navigation lässt sich mit allowed_domains von Browser Use einschränken; für Aktionen mit erheblichen Folgen muss die Anwendung oder Ausführungsumgebung eine Freigabe erzwingen. Auch eine erlaubte Webseite kann bösartige nutzergenerierte Inhalte anzeigen. Eine Domainliste allein schafft deshalb keine Vertrauensgrundlage. Browserbeschränkungen, Sicherheitshinweise zu Computer Use

Ein Prompt wie „Vor dem Absenden nachfragen“ ist keine technisch erzwungene Berechtigungsgrenze. Kann die Integration die betreffende Aktion nicht zuverlässig abfangen, darf sie nicht zu den Rechten des Agenten gehören. Dann muss ein Mensch sie ausführen. Der Leitfaden zu Prompt Injection erklärt, wie sich eine Freigabe an genau die Aktion binden lässt, die autorisiert werden soll.

Anmeldungen, gespeicherte Sitzungsdaten und Protokolle

Eine gespeicherte Anmeldung gewährt Zugriff. Browser Use kann Chrome über Browser.from_system_chrome() wiederverwenden oder gespeicherte Cookies und Local Storage mit Browser(storage_state="auth.json") laden. Eine solche Zustandsdatei ist wie ein Zugangsschlüssel zu schützen und von der Versionsverwaltung auszuschließen. Für unbeaufsichtigte geschäftliche Aufgaben sollte kein privates Browserprofil zum Einsatz kommen. Dokumentation zur Authentifizierung

Für die Übertragung gilt eine konkrete Grenze: Laut README überträgt die lokale Profilsynchronisierung Cookies, aber weder Local Storage noch IndexedDB oder Erweiterungen. IndexedDB ist ein weiterer Datenspeicher im Browser. Unabhängig davon können Cloud-Profile Cookies, Local Storage und den Anmeldestatus über mehrere Cloud-Browser hinweg erhalten. Daraus folgt nicht, dass die lokale Synchronisierung sämtliche Speichermechanismen kopiert hat. Manche Webseiten erfordern eine erneute Anmeldung. Einschränkung der Synchronisierung

Für jede Endnutzerin und jeden Endnutzer sollte ein getrenntes Profil bestehen. Vor der Verarbeitung privater Portaldaten ist außerdem zu prüfen, welche Informationen in Modelleingaben, Screenshots und gespeicherte Gesprächsverläufe gelangen. Browser Use bietet Einstellungen für Screenshots und das Speichern von Gesprächen; diese sollten bewusst konfiguriert werden. Agenteneinstellungen

Zugriffslimits und Wiederholungen bei unklarem Ausgang

Ein verfügbarer Cloud-Browser bedeutet keinen unbegrenzten Zugriff auf die Zielseite. Limits des Modelldienstes, Kapazitäts- und Anfragelimits von Browser Use Cloud sowie Drosselung und Zugangsprüfungen der Webseite müssen getrennt eingeplant werden.

Die Zahl gleichzeitiger Aufgaben pro Zielseite sollte begrenzt bleiben. Verlangt die Seite eine Wartezeit, ist diese einzuhalten; wiederholt blockierte Versuche sind zu stoppen. Bei Fehlern der Cloud-API ist zu unterscheiden, ob die Kapazität oder die Anfragehäufigkeit betroffen ist. Die zurückgegebenen Hinweise für erneute Versuche sind zu beachten. Cloud-Limits

Vor allem darf ein Timeout des Clients nicht dazu führen, dass dieselbe Aktion erneut abgesendet wird. Zuerst sind der bestehende Lauf und der Datensatz im Zielsystem zu prüfen. Nach einem Timeout kann unklar sein, ob die Aktion bereits ausgeführt wurde.

Browser Use in der Praxis: Der erste Lauf nach Dokumentation

Der Einstieg erfolgt am besten mit einer öffentlichen Seite und einer reinen Leseaufgabe. So lässt sich prüfen, ob Paket, Browser und Modell zusammenspielen, ohne eine Anmeldung oder einen Geschäftsvorgang einzubeziehen. Die Befehle folgen der Open-Source-Schnellstartanleitung. Das Beispiel übernimmt deren Python-3.12-Umgebung und die ausdrückliche Auswahl des BU2-Modells aus der README.

Browser Use mit Python einrichten

1. 1

   Paket und Browser installieren

   Unter macOS oder Linux mit vorhandenem Python und pip zunächst eine Bash-Shell in einem neuen Projektverzeichnis öffnen:

   pip install uv
   uv venv --python 3.12
   source .venv/bin/activate
   uv pip install browser-use
   uvx browser-use install

   Der letzte Befehl installiert den Browser. Unter Windows gilt anstelle von source der Befehl zur Umgebungsaktivierung aus der Schnellstartanleitung.

2. 2

   API-Schlüssel für das Modell hinterlegen

   Im Dashboard, das die Schnellstartanleitung verlinkt, einen Browser Use API-Schlüssel anlegen. Anschließend in derselben Bash-Shell eingeben, ohne ihn anzuzeigen:

   read -rsp "Browser Use API key: " BROWSER_USE_API_KEY
   printf '\n'
   export BROWSER_USE_API_KEY

   Dieser Schlüssel ermöglicht den Zugriff auf den gewählten Modelldienst. Er verlagert den Browser nicht automatisch in die Cloud.

3. 3

   Eine kleine Leseaufgabe ausführen

   Den folgenden Code als agent.py speichern:

   import asyncio
   from browser_use import Agent, ChatBrowserUse
   
   async def main():
       agent = Agent(
           task=(
               "Open https://example.com and report the page heading. "
               "Do not follow links or submit anything."
           ),
           llm=ChatBrowserUse(model="bu-2-0"),
       )
       history = await agent.run()
       print(history.final_result())
   
   if __name__ == "__main__":
       asyncio.run(main())

   Anschließend ausführen:

   python agent.py

   Die ausgegebene Überschrift selbst mit der Seite abgleichen. Für dieses harmlose Beispiel ist die Aufgabenanweisung eine geeignete erste Einschränkung. Im Produktivbetrieb müssen Beschränkungen außerhalb des Prompts durchgesetzt werden.

Bei einem Fehler sollte zuerst die Fehlermeldung gelesen werden, bevor das Modell gewechselt wird: Browserinstallation, Modellauthentifizierung und Webseitenzugriff sind unterschiedliche Fehlerquellen. Sobald der Lauf funktioniert, sollten die verwendeten Versionen der Abhängigkeiten beibehalten werden. Danach kann der Wechsel zu einem Testkonto auf der vorgesehenen Webseite folgen.

Wo die Versprechen zu weit gehen

Ein abgeschlossener Agentenlauf belegt keinen abgeschlossenen Geschäftsvorgang. Die Ausgabedokumentation von Browser Use unterscheidet ausdrücklich: is_done() bedeutet, dass der Agent eine Abschlussaktion ausgegeben hat; is_successful() ist seine eigene Einschätzung. Wichtige Ergebnisse außerhalb des Agenten müssen weiterhin im Zielsystem überprüft werden. Bedeutung der Ausgaben

Bei einer Adressänderung zählt die gespeicherte Adresse. Bei einem heruntergeladenen Bericht sind die Datei und der Berichtszeitraum zu prüfen. Nach dem Absenden einer Aktion sollte die Bestätigung des Zielsystems erfasst werden. Ein unklarer Ausgang muss geklärt sein, bevor ein erneuter Versuch erfolgt.

Dieselbe Zurückhaltung ist bei „Funktioniert auf jeder Webseite“ angebracht. Funktionen verwalteter Browser können Zugangshürden senken, doch die README des Projekts verspricht nicht, dass sich jedes CAPTCHA vermeiden oder lösen lässt. Auch ein besseres Modell kann keine Kontoberechtigungen vergeben, die dem Nutzer fehlen. Die Anwendung muss das tatsächliche Verhalten der Webseite berücksichtigen, einschließlich des Punkts, an dem ein Mensch übernehmen muss.

Der nächste konkrete Schritt

Für technisch versierte Gründer eignet sich als erster Pilot eine eng begrenzte Leseaufgabe in einem Portal mit einer eindeutig überprüfbaren Antwort. Dafür braucht es ein separates Testkonto, festgelegte erlaubte Seiten und eine schriftlich festgehaltene Prüfung des zurückgegebenen Datensatzes. Fehlgeschlagene Versuche sollten ebenso dokumentiert werden wie abgeschlossene Läufe.

Erst wenn diese Fehler verstanden sind, sollte die Vorbereitung von Formularen hinzukommen. Das Absenden bleibt bei einem Menschen, bis die Anwendung eine Freigabe erzwingen, das gespeicherte Ergebnis prüfen und Fehler beheben kann, ohne die Aktion doppelt auszuführen. Deckt eine unterstützte API oder ein stabiles Skript den Ablauf bereits ab, sollte diese einfachere Integration bestehen bleiben.

Praktische Hinweise zum Aufbau verlässlicher KI-Workflows gibt es im Newsletter.