Browser-basierte Ausführung für KI-Agenten: Playwright, MCP und ein sicherer Ausführer

Produktionsagenten beherrschen die Maschinen bereits fließend. Sie rufen APIs auf, verbinden sich mit MCP-Servern, führen Code aus, abfragen das Web, öffnen Dateien und geben Shell-Befehle ein. Dennoch stellt ein überraschend großer Anteil an echtem Software-Code einige seiner wichtigsten Operationen nur über eine Browser-Oberfläche zur Verfügung – und genau diese Lücke soll die Browserausführung schließen.

Die neuesten Agentenprodukte stellen dem Agenten einen Browser oder einen Cloud-Computer zur Verfügung. Es ist verlockend, dies als weitere Demonstration einer KI abzutun, die nur auf Knöpfe klickt. Eine nützlichere Sichtweise ist architektonischer Natur: Der Browser ist keine neue Art von Agent, sondern eine neue Ausführungsumgebung.

Der Unterschied ist wichtig. Wenn ein System bereits MCP-Server, Fähigkeiten, ausführbaren Code, programmatische Toolaufrufe, Sandboxes, Suchfunktionen sowie direkte Backend-Anbindungen bietet, sollte ein Browser keines dieser Funktionen ersetzen. Er erweitert das System in Bereiche, die es nicht zuverlässig abdecken kann: statebasierte, stark auf JavaScript basierende, authentifizierte Anwendungen, die für Menschen entwickelt wurden.

Suchfunktionen suchen nach Informationen. APIs und MCP kommunizieren mit Systemen. Code wandelt Daten um und koordiniert Schritte. Ein Browser nutzt die für Menschen entwickelte Benutzeroberfläche.

Die in Vergessenheit geratende Benutzeroberfläche

Agent-Architekturen beginnen in der Regel mit strukturierten Funktionalitäten. Wenn ein Service eine übersichtliche REST-API, ein SDK oder einen MCP-Server bereitstellt, ist das fast immer die beste Benutzeroberfläche für einen Agenten: ein expliziter Vertrag, typisierte Eingaben und Ausgaben, Fehler, mit denen leichter umgegangen werden kann, sowie klare Sicherheitsgrenzen.

Danach kommt die Ausführung des Codes. Anstatt dass das Modell nacheinander zwanzig Tools aufruft, soll es ein kleines Programm schreiben, das diese Tools aufruft, die Ergebnisse lokal aggregiert, Daten filtert und schließlich eine kompakte Antwort zurückgibt. Das eignet sich für große Tool-Kataloge, wiederholte Aufrufe sowie datenintensive Arbeitsabläufe. Ein Sandbox bietet zusätzlich eine Umgebung mit Python, Shell, Dateien sowie möglicherweise Kubernetes- oder GitHub-Tools in einem kontrollierten Umfeld. Zu diesem Zeitpunkt kann der Agent bereits viel bewältigen, geht aber weiterhin davon aus, dass alles Nützliche über maschinenlesbare Schnittstellen zugänglich ist.

Nicht unbedingt. Viele Tools sind ausschließlich hinter Bildschirmen zugänglich: interne Admin-Panels, alte Anbieterportale, Berichts-Dashboards, Partner-Systeme, Stellenbörsen, Analyse-Produkte, SaaS-Einstellungsseiten oder Apps, die nur dann echte Daten abrufen, wenn mehrere Filter gesetzt wurden. Die Daten können öffentlich sein, während der nutzbare Zustand durch JavaScript erzeugt wird. Eine Person hält die Aufgabe für trivial, doch es gibt keine dokumentierte API. Gelegentlich existiert zwar eine interne API, sie ist jedoch privat, instabil oder absichtlich nicht unterstützt.

Das ist der eigentliche Anwendungsfall: Es geht nicht darum, der KI im Allgemeinen das Surfen im Internet zu ermöglichen, sondern den Browser als Ersatzinterface zu nutzen, wenn die Anwendung selbst Teil der Aufgabe ist.

Warum MCP das noch nicht abdeckt

Jedes Mal, wenn es um die Ausführung in einem Browser geht, taucht diese Frage auf, und sie verdient eine klare Antwort. MCP erfordert niemals, dass das Zielsystem über eine API verfügt; es legt lediglich fest, wie ein Agent mit einer Funktionalität kommuniziert. Angenommen, die Zielanwendung bietet lediglich eine Benutzeroberfläche für Menschen. Der Code hinter einem MCP-Tool kann dann selbst einen Browser steuern. Die Grenze liegt nicht bei MCP, sondern am Fehlen einer stabilen, strukturierten Schnittstelle hinter dem Zielsystem.

Das Ziel kann nichts Strukturiertes bereitstellen. Was auch immer hinter MCP steht, kann ein Browser, eine Sandbox, ein Workflow-Engine oder etwas völlig anderes sein. Probleme entstehen, wenn die Anwendung keine öffentliche API, kein SDK, keine Datenbankintegration oder keinen unterstützten programmatischen Weg zur gewünschten Aktion bietet. MCP kann zwar ein Tool mit dem Namen browser_execute veröffentlichen, doch etwas dahinter muss das System steuern – und das bedeutet Browserausführung. Sie sind keine Konkurrenten: MCP kann das Protokoll sein, das die Browserfunktionen freigibt, während der Browser die Möglichkeit bietet, auf die an Nutzer gerichtete Anwendung zuzugreifen, wenn es nichts Besseres gibt.

Die Authentifizierung kann an den Browser gebunden sein. MCP verfügt über ein eigenes Autorisierungsmodell, einschließlich OAuth-Flüsse, doch es umfasst nur den Austausch zwischen dem MCP-Client und dem MCP-Server. Die Anmelderegeln des Systems, in dem das Tool schließlich arbeiten muss, bleiben unberührt. Viele interne Portale, Anwendungen von Drittanbietern sowie ältere SaaS-Produkte ermöglichen den Zugriff nur über einen interaktiven Browser-Fluss mit SSO, MFA, Sitzungskookies oder anderen beim manuellen Anmelden erstellten Zuständen – es existieren dabei weder Dienst-Zertifikate noch delegierte Token. Ein MCP-Tool kann diese Funktionalität dennoch bereitstellen, wobei ein authentifiziertes Browserprofil im Hintergrund steht. Der Benutzer meldet sich über den Browser an, der Sitzungszustand wird unter kontrolliertem Zugriff aufbewahrt, und später werden Aufgaben unter dieser Identität ausgeführt. Die Grenze ist das Authentifizierungsmodell der Zielanwendung, nicht das von MCP.

Einige Aufgaben sind UI-Workflows und keine einzelnen Anfragen. Betrachten Sie beispielsweise den Vorgang „Wählen Sie Einzelhandel, Europa und die letzten 90 Tage aus, um anschließend den durchschnittlichen Konversionsgrad pro Land zu berechnen.“ Dafür könnten mehrere Filter, ein Render-Schritt sowie die Extraktion des resultierenden Zustands erforderlich sein, wobei kein Endpunkt die Antwort direkt zurückgibt. Ein Browser kann die Benutzeroberfläche bedienen und das Ausgabeergebnis der Anwendung abrufen.

Strukturierte APIs, die direkt oder über MCP aufgerufen werden, bleiben immer die erste Wahl, sofern sie vorhanden sind. Sie sind günstiger, deterministischer und leichter zu sichern. Der Browser übernimmt den Teil, der sich ausschließlich hinter der für den Benutzer sichtbaren Oberfläche befindet.

Suchen ist kein Surfen

In vielen Agent-Stacks werden Web-Suchen, HTTP-Abfragen, Browser-Automatisierung und Computernutzung als eine einzige, unpräzise „Web“-Fähigkeit zusammengefasst, obwohl es sich um unterschiedliche Werkzeuge handelt.

Falls gefragt wird, was sich in der neuesten MCP-Spezifikation geändert hat, reicht vermutlich eine Websuche aus. Bei der URL eines gewöhnlichen öffentlichen Artikels kann eine direkte Abfrage ausreichen. Wenn gefordert wird, mit Salesforce zu arbeiten, sollte dessen API oder MCP genutzt werden. Um Statistiken aus JSON zu berechnen, muss Code verwendet werden.

Stellen Sie sich nun eine weitere Anfrage vor: Ein öffentliches Dashboard öffnen, Ukraine auswählen, das Jahr auf 2026 setzen, „Enterprise“ auswählen, durch jede Kategorie gehen und für jede Kennzahl den Durchschnitt berechnen. Ein Suchmaschine kann diese Interaktion nicht durchführen, und eine einfache HTTP-Anfrage liefert möglicherweise nur die leere Struktur der Seite. Die interessanten Daten werden erst angezeigt, nachdem der Browser JavaScript ausgeführt hat, clientseitige Anfragen gesendet hat, den Zustand der Anwendung aktualisiert hat und das Ergebnis darstellt.

Oder eine Stellenbörse: Wählen Sie „AI Engineering“, „Remote“ und „Deutschland“ aus und zählen Sie anschließend, wie viele Stellenanzeigen in der Beschreibung RAG erwähnen. Das ist eigentlich keine Suchanfrage – es handelt sich um einen Benutzeroberflächen-Ablauf, dem Extraktion und Berechnung folgen. Genau hier bietet ein echter Browser dem Agenten etwas Neues: eine Zustandsbasierte Web-Ausführungsplattform.

Der Browser ist eine Laufzeitumgebung

Ein verwalteter Browser wie der Amazon Bedrock AgentCore Browser ist Infrastruktur – eine isolierte, ferngesteuerte Browser-Sitzung, die programmgesteuert kontrolliert werden kann. Das große Sprachmodell kommuniziert nicht auf magische Weise damit. Sie definieren den Vertrag zwischen Agent und Umgebung.

AgentCore Browser stellt Sessions über einen WebSocket-Automatisierungs-Endpunkt zur Verfügung, und Bibliotheken wie Playwright können über das Chrome DevTools Protocol mit dem entfernten Chromium verbinden. AWS bietet zusätzliche Browseraktionen auf Betriebssystemebene für Interaktionen, die CDP nicht sauber handhaben kann. Der Browser ist eine entfernte Ausführumgebung und keine Intelligenzschicht. Aus dieser Sicht wird die Integration einfacher: Der Agent benötigt eine programmierbare Funktionalität, und die Browser-Ausführumgebung ist der Ort, an dem diese ausgeführt wird.

Lassen Sie den Agenten den Browsercode schreiben

Ein Browser kann auf verschiedene Weise mit einem Agenten kommunizieren. Eine Option ist ein hochrangiges Tool wie browser_task(task="find the latest invoice"), bei dem ein agentenspezifischer Teil im Browser die Aufgabe liest, die Seite durchsucht, entscheidet, worauf geklickt werden soll, und anschließend Bericht erstattet. Dies kann bei unbekannten Seiten hilfreich sein, bei denen der Arbeitsablauf erst entdeckt werden muss, doch es handelt sich dabei um einen schlechten Ausgangspunkt.

Falls das Hauptmodell ein fähiger Programmierer ist, ist ein saubereres Erstdesign, dass es das Browserprogramm generiert und es an einen Browser-Executor weiterleitet. Eine Signatur wie browser_execute(code, profile_id, allowed_domains) reicht aus:

browser_execute(
    code=generated_playwright_code,
    profile_id="vendor-portal-user-42",
    allowed_domains=["portal.example.com"]
)

Beim Erhalt des Anrufs prüft der Ausführende die Anfrage, startet anschließend eine isolierte Sitzung (oder verwendet eine bereits vorhandene) und verbindet Playwright mit dem entfernten Browser. Er führt das Programm aus und gibt strukturierte Daten zurück. Der Hauptagent führt seine Überlegungen nur einmal durch. Ein zweiter LLM, der denselben Auftrag neu interpretiert, macht nur dann Sinn, wenn tatsächlich eine Erkundung erforderlich ist. Für eine vorhersehbare Anzeige, einen Katalog oder ein Portal ist dies preislich vorteilhafter und einfacher in der Beobachtung als ein verschachtelter Browseragent.

Warum der Code-Modus geeignet ist

Das ist besonders wichtig dort, wo bereits die programmierte Aufrufung von Tools genutzt wird. Das verschwenderische Muster ist leicht zu erkennen: Das Modell ruft click auf, erhält ein Ergebnis, ruft screenshot auf, überlegt erneut, ruft type auf und erhält ein weiteres Ergebnis. Was ein einfaches Skript in Millisekunden erledigen würde, erfordert bei diesem Ansatz Dutzende von Aufrufen des Modells.

Das bessere Mustererkennungs-Tool ist die Aggregation: Lassen Sie das Modell ein einziges Programm schreiben, das im Ausführungsumfeld viele Browseroperationen durchführt und ein einziges, kompaktes Ergebnis zurückgibt.

page = await browser.page()
await page.goto("https://jobs.example.com")
await page.get_by_label("Category").select_option("AI Engineering")
await page.get_by_label("Location").select_option("Germany")
await page.get_by_label("Remote").check()
await page.get_by_role("button", name="Apply").click()
jobs = await page.locator(".job-card").all_inner_texts()

rag_jobs = [job for job in jobs if "RAG" in job.upper()]
return {
    "total_jobs": len(jobs),
    "jobs_mentioning_rag": len(rag_jobs)
}

Das Modell schreibt ein Programm, der Ausführer führt Dutzende oder Hunderte deterministischer DOM-Operationen durch, und der Agent erhält ein kleines JSON-Objekt anstelle einer langen Abfolge von Klicks und Screenshots.

Man kann noch weiter gehen. Eine kodebasierte Laufzeitumgebung, die Fähigkeiten berücksichtigt, kann dem generierten Programm mehrere kontrollierte Schnittstellen zur Verfügung stellen: MCP-Klienten, einfaches HTTP, Dateien, Browsersteuerung sowie lokale Berechnungen. Ein einziges Programm könnte über MCP Konten aus Salesforce abrufen, ein veraltetes Portal öffnen, für jedes Konto eine Metrik lesen, diese zusammenfassen und eine einzige Antwort zurückgeben.

customers = await mcp.salesforce.search_accounts(segment="enterprise")

results = []
for customer in customers:
    await browser.goto(f"https://legacy.example.com/customer/{customer.id}")
    metric = await browser.locator("#health-score").inner_text()
    results.append({
        "customer": customer.name,
        "health_score": metric,
    })
return summarize(results)

Das ist keine KI, die zufällig klickt. Es handelt sich um eine programmierte Koordination von Maschinen- und Mensch-Interfaces zusammen.

Ein funktionierender Ablauf

Nehmen wir eine scheinbar einfache Anfrage: Man geht zu einer öffentlichen Analyse-Übersichtsseite, wählt „Einzelhandel“, „Europa“, beschränkt sich auf die letzten 90 Tage und vergleicht, wie sich Konversionsraten und Kundenbindung in den verschiedenen Ländern unterscheiden.

Der Agent sollte nicht direkt in einen Browser wechseln. Ein Funktionsrouter prüft zunächst, ob ein günstigerer, strukturierterer Weg funktioniert. Kann die Suche eine Antwort liefern, wird sie genutzt. Wenn die Seite eine stabile API bereitstellt, wird diese aufgerufen. Liegen die Daten bereits über direkten HTTP-Aufrufen vor, wird Chromium nicht gestartet.

Falls die Werte erst nach einer Interaktion auf der Client-Seite angezeigt werden, wählt der Router die Ausführung im Browser. Der Hauptagent erzeugt ein Playwright-Programm, der Ausführer läuft es in der verwalteten Sitzung ab, wartet, bis sich die Seite nicht mehr ändert, liest die dargestellten Zahlen und gibt sie als strukturierte Daten zurück. Im Anschluss führt der Code-Modus den Vergleich durch, und der Agent schreibt das Ergebnis auf. Der Benutzer muss nicht wissen, dass ein Browser geöffnet wurde. In vielen Produkten sollte dies eine unsichtbare Backend-Funktion sein, ähnlich wie eine Datenbankabfrage oder ein Code-Sandbox.

Erst Automatisierung, dann Computernutzung

Browserautomatisierung und Computernutzung werden manchmal als dasselbe angesehen, doch sie gehören zu unterschiedlichen Ebenen der Architektur. Playwright und CDP arbeiten mit der Struktur des Browsers: Seiten, Selektoren, DOM-Elemente, Formulare, Netzwerkanfragen, Downloads und Zustände. Dadurch laufen sie schneller und sind kostengünstiger, außerdem sind sie einfacher zu testen und abzugrenzen.

Die Nutzung von Computern ist visuell. Das Modell beobachtet den Bildschirm und führt Maus- oder Tastaturaktionen aus. Es kommt zum Einsatz, wenn das DOM die Benutzeroberfläche nicht zuverlässig handhaben kann: Canvas-Apps, native Dialogfelder, Kontextmenüs sowie ungewöhnliche Drag-and-Drop-Verfahren. AWS zieht in AgentCore Browser eine ähnliche Linie – dort basiert der WebSocket-Automatisierungsweg auf CDP, und die InvokeBrowser-API bietet eine Steuerung auf Betriebssystemebene für Aufgaben, die CDP nicht bewältigen kann. Nutzen Sie daher zunächst strukturierte Automatisierung und wenden Sie visuelle Steuerung nur dann an, wenn es unbedingt notwendig ist. Je tiefer der Agent in der Architektur vordringt, desto flexibler wird er – doch jede Aktion wird dabei teurer, erfordert mehr Zustandsverwaltung und birgt mehr Risiken.

Nach einem Rückgriff auf den Computergebrauch sollte der Ausführende einen geschlossenen Überprüfungszyklus durchführen, nicht eine Abfolge blinden Handelns. Ein Klick, der ohne Fehler zurückkehrt, beweist nichts über die durchgeführte Operation. Die Seite könnte noch geladen werden, ein Modalfenster könnte die Aktion aufgenommen haben oder ein anderes Element könnte den Klick abgefangen haben. Nach jedem folgenden Schritt sollte die Laufzeit den neuen Zustand prüfen und bestätigen, dass die erwartete Änderung eingetreten ist, bevor sie fortfährt. Zudem sollten wiederholte Aktionen, die nichts bewirken, erkannt werden. Wenn derselbe Schritt ohne Veränderung wiederholt wird, ist ein erneuter Versuch falsch; die Lösung besteht darin, den Ablauf neu zu planen oder auf eine strukturiertere Strategie zurückzugreifen.

Dieser Zyklus stützt sich auf drei Sicherheitsmechanismen: eine Begrenzung der Anzahl aufbewahrter Screenshote, die Erkennung wiederholter Aktionen, die nichts ändern, sowie die Anwendung von Berechtigungsstufen Schritt für Schritt.

Authentifizierung macht es zu einer echten Arbeit

Öffentliche Dashboards eignen sich für ein Proof of Concept, doch der eigentliche Unternehmenswert zeigt sich in authentifizierten Anwendungen. Playwright verfügt bereits über ein solides Konzept für Browserkontexte sowie wiederverwendbaren Authentifizierungsstatus, und AgentCore Browser fügt verwaltete Profile hinzu, die Cookies und lokalen Speicher über verschiedene Sitzungen hinweg beibehalten. Der Benutzer meldet sich einmal an, das Profil wird gespeichert, und eine spätere Sitzung lädt diesen Zustand wieder herunter. Dies ist nützlich für interne Portale, Kunden-Systeme, veraltete SaaS-Lösungen sowie Anwendungen von Drittanbietern, bei denen eine API-Integration sonst eine maßgeschneiderte Umkehringenieurarbeit erfordern würde oder gar nicht möglich wäre.

Es verändert außerdem die Art und Weise, wie Identitäten modelliert werden. Ein Browserprofil ist im Grunde eine identifizierte Ausführungsidentität und kein allgemeines Hilfselement. Ein Profil, das auf ein Finanzportal zugreifen kann, sollte nicht automatisch für jeden Agenten oder jeden Workflow verfügbar sein. In der Produktion sollten Profile an Mieter, Benutzer, Zweck sowie Richtlinienscope gebunden werden, wobei dem Agenten nur Zugriff auf ein bestimmtes Profil gewährt werden sollte – und nicht allgemeiner Zugriff auf alle Sessions, die der Benutzer besitzt.

Sicherheit ist wichtiger als die Demo

Die Ausführung im Browser ist mächtig, weil sie über dieselbe Schnittstelle abläuft, die auch Menschen verwenden – was auch bedeutet, dass Fehler mit den Rechten eines Menschen auftreten können.

Die erste Grenze ist der Ausführende. Der generierte Browsercode sollte in Isolation laufen, wobei explizite Domainbeschränkungen, Zeitlimits, Ressourcenbegrenzungen sowie kontrollierter Zugriff auf Profile gelten. Das Modell sollte weder Umgebungsvariablen des Hosts, willkürliche Anmeldeinformationen noch allgemeine Netzwerkpfade erhalten, nur weil es Playwright ausführen kann.

Die zweite Grenze ist die Aktionspolitik. Das Extrahieren von Metriken von einer Seite ist eine andere Handlung als das Veröffentlichen von Inhalten, das Versenden von Nachrichten, das Ändern von Kontoberechtigungen, das Löschen von Daten oder die Freigabe einer Zahlung. Solche Nebeneffekte sollten außerhalb des Modells klassifiziert und auf der Ausführungsebene kontrolliert werden.

Drittens gibt es die Prompt-Injektion. Sobald ein Agent beliebige Seiten liest, wird alles, was dargestellt wird, zu unzuverlässigem Eingabedaten. Texte in einem Dashboard, E-Mails, Bannern oder Dokumenten können wie Befehle für den Agenten aussehen. Der Ausführende darf den auf dem Bildschirm angezeigten Inhalt niemals als Zustimmung des Benutzers betrachten. Auch OpenAI’s Richtlinien zur Computernutzung besagen dasselbe: Behandeln Sie Inhalte Dritter als unzuverlässig und holen Sie sich vor riskanten Aktionen wie Veröffentlichung, Versand, Löschung, Änderung von Berechtigungen oder Geldüberweisung stets eine Bestätigung ein. Das ist ein Problem der Ausführungspolitik, nicht nur der Prompt-Engineerung. Der Browser kann zwar allgemein beobachten, sollte die Welt jedoch nur durch explizite Richtlinien verändern.

Darauf folgt die Beobachtbarkeit. Ein Produktionsausführender sollte die angeforderte Aufgabe, das verwendete Profil, die aufgerufenen Domänen, das ausgeführte Programm, heruntergeladene Dateien, versuchte externe Nebeneffekte sowie die Stellen, an denen menschliche Genehmigung erforderlich war, aufzeichnen. AgentCore Browser kann in Echtzeit überwacht werden, und benutzerdefinierte Browser unterstützen die Aufzeichnung und Wiedergabe einer Sitzung, was einer Prüfung eine solide Grundlage bietet.

Wie es sich zu MCP, Skills und Sandboxes verhält

Hier ersetzt nichts anderes etwas anderes. MCP und APIs bleiben die bevorzugten Lösungen für strukturierte Geschäftsprozesse. Das Fähigkeitsprofil umfasst wiederholbare Verfahren, Kontextwissen sowie betriebliches Wissen. Der Code-Modus bleibt die effiziente Lösung für wiederholte Aufrufe, Aggregationen und Transformationen. Sandboxes bilden den kontrollierten Raum für Dateien, Shell-Befehle, Python, Tests sowie rechenintensive Aufgaben. Die Ausführung im Browser schließt eine separate Lücke: Er ermöglicht die Bedienung einer benutzerorientierten Schnittstelle, wenn keine maschinenorientierte Alternative ausreichend zuverlässig ist.

Bleiben Sie bei konservativem Routing. Kann eine API die Aufgabe erledigen? Verwenden Sie sie. Kann eine direkte Abfrage ausreichen? Öffnen Sie keinen Browser. Muss die Website selbst bedient werden, um das Ergebnis zu erhalten? Dann ist die Ausführung im Browser die richtige Wahl. Kann strukturierte Automatisierung die Interaktion nicht abschließen? Der Einsatz eines Computers ist dann die letzte Option.

MCP als Vertrag

In der Praxis bleiben die verschiedenen Komponenten selten getrennt. Die Ausführung von Code, die Ausführung im Browser und sogar die Suche nach Tools finden in der Regel hinter einem MCP-Server statt. MCP ist nicht nur die API-Komponente – es handelt sich dabei um den Vertrag, über den ein Agent jegliche Funktionalität erhält, egal ob es sich um einen REST-Aufruf, ein in einer Sandbox ausgeführtes Skript oder einen entfernten Chromium-Prozess handelt.

Die Verpackung in Form eines dedizierten MCP- Servers, der eine Handvoll Tools wie execute_code, browser_execute und find_tool anbietet, funktioniert gut – anstelle eines Tools pro zugrunde liegender Aktion. Die Anzahl der Tools bleibt bei drei oder vier und nicht bei dreißig. Ein Modell hat keinen Bedarf an separaten Tools für Klicken, Screenshots und Auswahl von Optionen, genauso wenig wie es separate Tools für Neustart, Skalierung und Rollback benötigt, wenn eine einzige Operation mit einem Plan ausreicht.

Portabilität ist ein weiterer Grund. Ein Server kann hinter einem benutzerdefinierten Agenten-Tool laufen oder genauso gut in Claude, ChatGPT oder jeden MCP-kompatiblen Client integriert werden, sodass dieselben Funktionen über eine vertraute Benutzeroberfläche getestet werden können, ohne eine zusätzliche Integration nötig zu haben.

Halten Sie den Ausführer getrennt

Von der Seite des Agents aus kann der Browser wie ein Teil des Code-Modus erscheinen, da ein generierter Skript sowohl browser.goto() als auch browser.locator() neben MCP-Clienten, Dateien und Compute-APIs innerhalb eines einzigen logischen Laufzeitumfelds verwenden kann. Bei der Implementierung ist der Browser Executor dennoch als separates Komponente besser geeignet. Browser bringen ihr eigenes Lebenszyklus- und Risikomanagement mit: Sessions, Cookies, lokaler Speicher, heruntergeladene Dateien, Netzwerkrichtlinien, eingeloggte Profile, Seitenzustand, Aufzeichnungen sowie Nebeneffekte außerhalb Ihres Systems. Ein Code-Sandbox hingegen kümmert sich um CPU, Speicher, Dateien, Pakete und Prozesse. Durch die Trennung können jeweils die Laufzeitumgebungen das für sie geeignete Sicherheitsmodell durchsetzen. Das Code-Modus kann einen eingeschränkten Browser-Client bieten, während der Executor die entfernte Session steuert – so bleibt das Programmiermodell einheitlich, während die Infrastruktur geteilt bleibt.

Langweilig beginnen

Überspringen Sie den universellen autonomen Browser-Agenten zu Beginn. Die erste nützliche Version ist absichtlich schlicht: eine isolierte entfernte Chromium-Sitzung, ein kleiner browser_execute-Vertrag, Playwright für die Automatisierung, eine strenge Domain-Allowlist sowie strukturierte Ergebnisse. Testen Sie sie an einer öffentlichen, stark auf JavaScript basierenden Konsole oder einer Beispielanwendung, bei der Sie zeigen können, dass der Browser Suchfunktionen und HTTP-Aufrufe übertrifft.

Sobald das funktioniert, verbinden Sie es mit dem bereits für den Code-Modus verwendeten programmatischen Muster, damit der Hauptagent ein Browserprogramm erstellt und nicht immer wieder auf niedrigstufige Klickwerkzeuge zurückgreift. Fügen Sie anschließend authentifizierte Profile für kontrollierte interne Anwendungen hinzu, sowie Aktionspolitiken und Genehmigungsmechanismen, bevor ein Workflow externe Nebeneffekte verursachen kann. Verwenden Sie visuelle Computerbenutzeroberflächen nur für solche Schnittstellen, die Playwright nicht zuverlässig handhaben kann, und betrachten Sie einen spezialisierten Browser-Agenten-Zyklus, der beobachtet, analysiert, erneut versucht und nur dann weiter vorgeht, wenn eine Aufgabe zu unklar ist, um vom Hauptagenten ein stabiles Programm erstellt zu werden. Diese Reihenfolge sorgt dafür, dass die Architektur verständlich bleibt, und verlagert das kostspieligste sowie am wenigsten deterministische Verhalten an den Rand, anstatt es zum Standard zu machen.

Der größere Wandel

Das Interessante ist nicht, dass ein LLM einen Button klicken kann – Browser-Automatisierung existiert bereits seit Jahren. Neu ist vielmehr, dass ein Agent entscheiden kann, wann der Browser die richtige Plattform ist, das Programm schreiben kann, das ihn steuert, das Ergebnis mit MCP-Aufrufen und Codeausführung kombinieren kann und so weitermachen kann, ohne dass ein Entwickler für jede an Endbenutzer gerichtete Anwendung eine maßgeschneiderte Integration erstellen muss.

Maschineninterfaces sind weiterhin besser: zuverlässiger, sicherer und einfacher zu verwalten. Doch die Welt ist voller Systeme, die die notwendigen Operationen nicht über eine einheitliche Schnittstelle anbieten, und Workflows endeten früher oft damit, dass ein Mensch die Website öffnen und die Arbeit abschließen musste. Die Browserausführung verschiebt diese Grenze – sie macht die menschliche Benutzeroberfläche zu einer weiteren programmierbaren Plattform, die sorgfältig genutzt, streng isoliert und nur dann bevorzugt werden sollte, wenn strukturierte Interfaces nicht ausreichen.

Die nächste Generation von Agentenplattformen lässt sich am besten nicht als größere Sammlungen an Werkzeugen oder Armeen an Browser-Bots verstehen, sondern als Systeme mit mehreren Ausführungsumgebungen sowie einem Router, der entscheidet, welche Umgebung für welchen Teil einer Aufgabe zuständig ist. Das Ziel besteht nicht darin, die Agenten dazu zu bringen, häufiger zu klicken, sondern ihnen zu ermöglichen, auf jene Teile der Software zuzugreifen, die von APIs noch nicht bereitgestellt werden.