Warum Coding Agents den Browser ständig neu erfinden
Warum langlaufende Programmieragenten zu toolbasierten Lösungen im Browser-Stil konvergieren: Hilfsskripte, Cookies als Speicher, kompakte Seitenansichten, HTTP-Fallbacks und Bias in den Trainingsdaten.
Der Browser, den niemand wollte
Die Programmieragenten zeigen ein wiederkehrendes Muster. Mit freiem Zugang zum Web, der Möglichkeit, Code zu schreiben und auszuführen, sowie einer Aufgabe, die lange genug andauert, neigen sie dazu, etwas zu entwickeln, das einem Browser ähnelt. Der Wunsch nach einem Browser ist nicht der Antrieb. Was die Agenten eigentlich anstreben, ist ein günstiges, wiederverwendbares Werkzeug, das eine URL öffnen, Klicks ausführen, Formulare ausfüllen, auf Daten warten und diese extrahieren kann, Cookies und Sitzungen speichern sowie nach einem Fehler einen Screenshot erstellen kann. Aus dieser Perspektive handelt es sich dabei einfach um gewöhnliche Ingenieurarbeit, wie sie auch ein menschlicher Entwickler erledigen würde.
Chromium als Produkt ist nicht das Endziel. Die Agenten streben vielmehr die Funktion an, die ein Browser erfüllt: die Umwandlung von Webprotokollen und -konventionen in ausführbare Operationen.
Produkt versus Abstraktion
Ein Browser im Sinne von Chrome oder Firefox ist eine umfangreiche Anwendung: Tabs, eine Adressleiste, ein Rendering-Engine sowie ein Prozessmodell. Nichts davon entspricht dem, was ein Agent benötigt. Ein Agent will vielmehr die zugrundeliegende Aufgabe erledigen, nämlich die Funktionsweise des Internets in ausführbare Operationen umzuwandeln.
Menschen nutzen diese Benutzeroberfläche, ohne es zu bemerken. Eine Anmeldeseite fordert offensichtlich Anmeldedaten an, ein Button kann offensichtlich gedrückt werden – man klickt darauf, wartet auf die nächste Seite und setzt fort. Ein Agent kann sich nicht auf dieses stillschweigende Verständnis stützen, daher muss er dieselbe Arbeit in explizite Operationen umwandeln. Wenn man einem Programmieragenten aufträgt, auf beliebigen Webseiten zu arbeiten, gibt man ihm ein Problem, dessen natürliche Abstraktion bereits bekannt ist – wodurch der Agent in diese Richtung tendiert.
Das moderne Web ist auch nicht so konzipiert, dass es als strukturierte API genutzt werden kann. In der Regel gibt es ein HTML-Dokument, das von JavaScript umgeben ist, sowie Anmeldesitzungen, Cookies, Umleitungen, Client-Seite-Rendering, unbegrenztes Scrollen, Popups, Dateiuploads und asynchrone Anfragen. Ein einfacher HTTP GET ist nur der Anfang – tatsächliche Aufgaben in dieser Umgebung erfordern letztendlich eine Reihe solcher Operationen.
open(url)
click(selector)
fill(selector, text)
wait_for(selector)
extract(selector)
go_back()
screenshot()
Das ist kein grafischer Browser, aber es handelt sich zweifellos um eine Allzweck-Schnittstelle zum Web.
Warum lange Aufgaben Hilfsmittel erzeugen
Kurze Aufgaben können ad hoc erledigt werden. Eine einmalige Suche wird ohne jegliche Infrastruktur durch brute Force durchgeführt, da sie sich nicht wiederholt und in Sekunden abgeschlossen ist.
"Find the current exchange rate."
"Look up this company's homepage."
"Find the opening hours of this restaurant."
Lang andauernde Aufgaben sind anders. Stellen Sie sich einen Agenten vor, der alle paar Stunden Hunderte von Webseiten überwacht, wiederholt komplexe Arbeitsabläufe ausführt, Seiten scrappt, während er weiterhin eingeloggt bleibt, über mehrere Tage hinweg Beweise sammelt oder einen Dienst abfragt, bis sich etwas ändert. Wenn das Modell jeden Klick und jede Überprüfung selbst handhaben muss, steigen die Kosten enorm an. Ein naiver Ablauf sieht so aus:
- Öffnen Sie einen Browser, das ist das Werkzeug, mit dem die Seite abgerufen wird.
- Überprüfen Sie die Seite, wobei der dargestellte DOM als Quelle für die Beobachtungen dient.
- Finden Sie das Suchfeld, geben Sie die Abfrage ein, klicken Sie auf „Suchen“ und warten Sie.
- Extrahieren Sie die Daten.
- Analysieren Sie sie.
- Wiederholen Sie den Vorgang.
Ein fähiger Agent reagiert wie ein menschlicher Entwickler, indem er einen wiederverwendbaren Hilfsprogramm schreibt. Der nächste Ablauf verläuft dann wie folgt:
- Führen Sie das Skript aus.
- Prüfen Sie, ob die Ausgabe immer noch korrekt aussieht.
Das ist eine umfassende architektonische Änderung. Das Modell stoppt die Ausführung aller Operationen. Es wird zur Komponente, die entscheidet, welches Verfahren ausgeführt werden soll, während herkömmliche Software das gewählte Werkzeug verwendet und Beobachtungen sammelt. Mit anderen Worten: Der Agent fasst seine eigenen Erfahrungen in ein Skript zusammen.
Im Browser erkunden, im Code nachspielen
Ein Browser ist ein hervorragender Ort zum Erkunden. Ein Agent kann herumstöbern, navigieren, die Ergebnisse betrachten und herausfinden, welche Aktionsserie ein Ziel erreicht. Danach ist es verschwenderisch, jede Aktion erneut durchzudenken.
Nehmen wir an, der Agent erfährt, dass das Finden eines Produkts auf einer Einkaufsseite immer bedeutet, zur Startseite zu gehen, nach „USB-C-Kabeln“ zu suchen, Filter für vier Sterne und mehr, schnelle Lieferung sowie einen Preislimit anzuwenden, durch die Ergebnisse zu blättern und dabei Titel, Preise sowie Produkt IDs zu extrahieren. Es gibt keinen Grund dafür, dass ein Sprachmodell diese fünf Schritte bei jedem Ausführungsvorgang erneut entdecken muss. Es kann sie in einen Prozess umwandeln und für ähnliche Probleme wiederverwenden. Dafür ist jedoch eine aktive Sitzung mit Cookies erforderlich, weshalb sich der Agent für Puppeteer, Playwright oder ein ähnliches Tool als Mittel zur Seiteabfrage entscheidet.
async function getNewProducts(query) {
const browser = await playwright.chromium.connectOverCDP(
`wss://${AUTH}@brd.superproxy.io:9222`,
);
const page = await browser.newPage();
await page.goto("https://example.com/products");
await page.fill("input[name=q]", query);
await page.click("button[type=submit]");
await page.waitForSelector(".results");
return extractResults(page);
}
Der Auszug verbindet Playwright mit einem über das Chrome DevTools Protocol entfernt gehosteten Browser. Ein gehosteter Browser ist sinnvoll, wenn ein langlaufender Agent seine Sitzung alle paar Stunden ohne Beteiligung eines Modells am Leben halten muss. Dafür werden Kontoinformationen in Form einer Verbindungszeichenkette benötigt, die durch den Platzhalter ${AUTH} dargestellt wird.
Eine wiederholbare, strukturierte Extraktion auf einer Website ohne vorgefertigten Scraper erfordert nicht einmal eine lokale Playwright-Datei. Derselbe Workflow kann in ein gehostetes Scraping-Tool umgewandelt werden: Man beschreibt die gewünschten Daten in einfachen Worten, erhält einen generierten Sammler und führt ihn im Klickzyklus ohne Modell aus. Seine Interaktions- und Parserfunktionen bestehen aus denselben Aufgaben – öffnen, klicken, ausfüllen, warten, extrahieren und Screenshot machen – nur dass sie gehostet werden.
Ein solches Skript versagt, sobald sich die CSS-Selektoren ändern, wodurch der Agent erneut suchen und ein neues Skript erstellen muss. Wenn dieser Prozess in einer gehosteten Tool-Plattform stattfindet, kann die KI ihn möglicherweise reparieren, ohne dass jemand die Selektoren neu schreiben muss.
Menschliche Entwickler verhalten sich genauso. Der erste Besuch auf einer Website lehrt einen, wie sie funktioniert, und danach denkt niemand mehr über jeden Klick nach. Wenn sich die Website ändert, muss man es erneut lernen, behält dieses Wissen aber implizit bei. Ein LLM verfügt über ein weitaus teureres „Gedächtnis“. Wenn es den Prozess jedes Mal aus dem Kontext neu aufbauen muss, zahlt es immer wieder für dieselbe Erkundung. Deshalb speichert es den gelernten Arbeitsablauf in einem Skript und führt dieses aus, bis die Seite nicht mehr übereinstimmt.
Cookies als Gedächtnis außerhalb des Modells
Kein Sprachmodell kann derzeit eine lange Web-Sitzung in seinem Kontext speichern. Das Schreiben einer .py-Datei ruft weiterhin das Modell auf, während das Speichern von Cookies dies nicht tut. Im Laufe einer Sitzung sammelt der Browser selbst Speicherplatz an, wodurch dieser bereits außerhalb der Speicherung für den Agenten liegt. Es gibt drei relevante Bereiche:
- Die Cookie-Datenbank, einschließlich HttpOnly-Cookies sowie solcher, die von JavaScript nach einem Anmelden oder Bot-Check gesetzt werden. Oft kann das Modell diese überhaupt nicht lesen, doch der Browser behält sie bei und fügt sie der nächsten Anfrage hinzu.
- Die Origin-Speicherung, also
localStorage,sessionStorageund IndexedDB, die fast ausschließlich von der Website geschriebene Werte enthalten. - Die Sitzungshistorie, der „Zurück“- und „Vorwärts“-Pfad, der es ermöglicht,
back()odertabs.goBack()zu verwenden.
Einige Zustände existieren außerhalb des Browser-Speichers, wie beispielsweise eine Serverseitensitzung oder eine URL, die erst dann existiert, wenn JavaScript ausgeführt wird. Der Agent muss das nicht selbst lesen – er muss lediglich eine Browser-Schicht steuern, die bereits die Sitzung enthält.
Sicherheitsrisiken beim Übergeben eines Browsers
Wenn ein Agent jede Seite sowie jedes Cookie lesen und eine aktive Sitzung steuern kann, ist die Eingabefälschung nicht mehr nur eine Frage besserer Eingabefelder, sondern wird zu einem architektonischen Risiko. Jedes System, das einen aktiven Browser betreibt, ist damit konfrontiert, doch kodierende Agenten sind in einer schlechteren Lage, da sie in der Regel alles schreiben und ausführen können, was ihnen begegnet. Beschränken Sie das, was der Agent ohne Aufsicht einer Person tun kann, und beginnen Sie mit einer Sandbox.
Ein gutes Muster ist Anthropics Checkliste für den Computergebrauch: Verwenden Sie eine dedizierte VM oder einen Container, vermeiden Sie Anmeldungen, es sei denn, die Aufgabe erfordert sie, halten Sie Listen mit erlaubten Domains bei und verlangen Sie, dass ein Mensch alles genehmigt, was Geld oder Zustimmung betrifft.
Warum rohes HTML eine schlechte Eingabe darstellt
Rohdaten von Seiten sind eine schreckliche Eingabe für ein Sprachmodell, weil es dort so viel „Rauschen“ gibt. Was das Modell benötigt, kann in Tausenden von Tokens aus Markup, Styling und Anwendungsmechanismen versteckt sein. Ein gutes Browser-Tool liefert daher anstelle des vollständigen HTMLs einen kleineren Umfang an Aktionen und Beobachtungen.
Die Abbildung zeigt das Document Object Model einer HTML-Seite, den Baum, den eine kompakte Ansicht oder ein Barrierefreiheitstreeck komprimieren muss. Ein nützliches Tool kann ihn in etwas viel Kleineres umwandeln. Anstelle eines ganzen Dokuments kann es dem Modell beispielsweise eine kurze Übersicht wie diese liefern.
Title: Search results
Links:
[1] Home
[2] Next page
Forms:
search: input[name=q]
Buttons:
submit: button[type=submit]
Main content:
...
Oder es kann einen Zugänglichkeitsbaum freigeben.
- navigation
- link "Home"
- link "Search"
- main
- heading "Results"
- list
- listitem "Item 1"
- listitem "Item 2"
Diese Form ist weitaus näher daran, was ein Reasoning-Modell verwenden kann. Die browserförmige Schicht ermöglicht daher nicht nur Interaktionen: Sie komprimiert die Umgebung in eine kompakte Menge an Aktionen und Beobachtungen. Der Agent sieht nur die für seine Aufgabe relevanten Teile des Webs, nicht die Mechanismen hinter der Seitendarstellung. Der Kontext wird gespeichert, die Inferenz wird günstiger und Fehler gehen oft – wenn auch nicht immer – zurück.
Es gibt jedoch eine Einschränkung: Ein vollständiger Zugänglichkeits-Snapshot mit allen Referenzen kann größer sein als der sichtbare Text. Die Kompression ist nur dann sinnvoll, wenn der Wrapper tatsächlich eine kurze, handhabbare Liste an Steuerelementen zurückgibt. Wie kurz diese Liste ist, hängt vom Modell ab. Ein kleines Modell kann keinen rohen DOM verwenden, während ein leistungsstarkes Modell dies zwar kann, aber dennoch Kosten für die Tokens trägt. Keines der Modelle benötigt den vollständigen HTML-Code.
Wann reiner HTTP ausreicht
Nachdem der Agent verstanden hat, wie eine Website funktioniert, erfordert die günstigste und zuverlässigste Umsetzung möglicherweise überhaupt keine Browserautomatisierung. Manchmal erweist sich der Browser im Grunde genommen nur als Werkzeug für ganz einfache Aufgaben. Eine „Nächste Seite“-Schaltfläche könnte letztendlich genau das ausführen.
GET /api/products?page=2
Wenn das der Fall ist, ist das Rendern der Seite sinnlos, und der Agent kann den Endpunkt direkt aufrufen. Das Ergebnis ist eine Hierarchie von Optionen.
human interface
↓
browser automation
↓
discovered workflow
↓
direct HTTP/API calls ← only if the site still allows it
Ihr Wert lag darin, zu zeigen, wie sich die Anwendung verhält. Sobald das verstanden ist, kann der Agent Schichten entfernen und manchmal auf reines HTTP zurückgreifen. Ein Agent, der niemals eine JavaScript-reiche Seite berührt, kann die Browserautomatisierung ganz überspringen und sich ausschließlich auf HTTP verlassen, idealerweise mit einem Unblocking-Service als Ersatz für abgelehnte Anfragen. Unabhängig vom Weg benötigen autonome Agenten einen Notfallplan, denn eine Cloudflare-Sperre oder eine Anti-Bot-Prüfung ist im offenen Internet fast unvermeidlich. Ohne kostengünstige Wiederholungsversuche irrt das Modell umher, verbraucht Token und erhöht die Rechnungskosten.
Zwei Komplikationen treten auf.
Zunächst können viele Websites nicht auf HTTP reduziert werden. Die meisten lassen sich nicht rückentwickeln: Sie drosseln nicht-browserbasierten Verkehr, ändern Selektoren, erstellen Fingerprints der Clients und fügen Anti-Bot-Prüfungen oder CAPTCHAs hinzu. Für solche Fälle sollte man den vollständigen Browser-Ansatz beibehalten, egal ob lokal oder gehostet.
Zweitens lohnt sich ein Ersatzansatz nicht immer. Eine dokumentierte öffentliche JSON-API ist strukturiert, begrenzt und einfach zu protokollieren. Ein interner Endpunkt ohne Dokumentation, den das Agent selbst herausgefunden hat, ist etwas anderes: Er ist zwar günstiger in der Anrufung, doch für einen Menschen schwieriger zu überprüfen als ein Skript, das auf einen sichtbaren Button klickt, und liefert außerdem weniger Protokolle. Eine 200-Antwort, die voller Unnötigkeiten ist, fällt leicht übersehen, während eine fehlerhafte Seite auffällt.
Letztendlich hat das Agent keine Loyalität gegenüber Browsern. Es sucht vielmehr nach der kostengünstigsten Schnittstelle zu seiner Umgebung, die dennoch funktioniert:
- Falls diese Schnittstelle ein JSON-Endpunkt ist und die Website ihn unterstützt, verwendet man JSON.
- Falls JavaScript-Ausführung und Sitzungszustand erforderlich sind, verwendet man einen echten Browser über Puppeteer oder Playwright oder einen gehosteten Browser.
- Falls nur heruntergeladenes HTML benötigt wird, verwendet man HTTP – mit einem Proxy oder Unblocker, falls die GET-Anfrage blockiert ist.
Langlebige Web-Agenten verwenden in der Regel mehrere dieser Methoden gleichzeitig. Entscheidend ist die Fähigkeit, je nach Situation in der Hierarchie nach oben oder unten zu wechseln.
Erklärt das Trainingsdaten?
Die Antwort ist gemischt. Trainingsdaten können erklären, warum ein Modell auf Playwright oder Puppeteer zurückgreift, doch sie können nicht erklären, warum überhaupt browserähnliche Tools entwickelt werden.
In einer 2026 von Oxford und Microsoft durchgeführten Studie mit dem Namen BiasBusters wurde eine nahe Verwandte dieser Frage getestet, nämlich ob die Exposition während des Trainings die Wahl des von einem Modell ausgewählten Tools beeinflusst. Das Team setzte das Training eines kleinen Modells anhand eines mit Metadaten reichhaltigen Korpus für eine bestimmte Wetter-API fort, die zu den mehreren Anbietern desselben Services gehört.
- Zuvor wählte das Modell diese API fast nie, nur etwa 0,6 % der Zeit – das entspricht ungefähr der reinen Zufallswahrscheinlichkeit.
- Nach dem Training mit dem verzerrten Korpus wurde sie etwa 12 % der Zeit ausgewählt, also zwanzigmal häufiger.
Kurz gesagt neigt die Exposition während des Trainings allein, unabhängig von der Aufgabe, messbar dazu, zu bestimmen, welches Tool oder Produkt ein Modell bevorzugt. Dabei geht es jedoch um die Auswahl eines Tools. Die Abstraktion (öffnen, klicken, ausfüllen, warten, als Form extrahieren – je nachdem, welche Bibliothek dies bereitstellt) wird vom Umfeld vorgegeben. Ein Modell, das noch nie Playwright gesehen hat, bräuchte dennoch etwas, um Seiten zu öffnen, auf Inhalte zu warten und Ergebnisse zu melden, da interaktive Seiten dies erfordern.
Zwei verschiedene Faktoren sind hier im Spiel:
- Die Abstraktionen von
open,click,fill,waitundextractwerden vom Umfeld vorgegeben. Interaktive Seiten beinhalten Navigation, Zeitsteuerung, Steuerelemente sowie dargestellte Ausgaben – unabhängig davon, ob Playwright in den Gewichten irgendeines Modells enthalten ist.
Die Trainingsdaten umfassen den letzteren Fall, aber nicht den ersten. Das Modell kann nicht erklären, warum das Problem ständig zu browserähnlichen Abstraktionen neigt. Der grundlegendere Grund ist, dass das Web bereits auf diese Weise strukturiert ist.
Adapter mit der besten Leistung
Agenten wie Claude Code entwickeln eigentlich keine Browser. Sie erstellen Adapter zwischen einem Reasoning-System und einer Umgebung, die zufällig browserähnlich ist.
In der Evolutionsbiologie gibt es ein Konzept namens Karzinisierung: die seltsame Tendenz unverwandter Krebstiere, im Laufe der Zeit zu krabbenähnlichen Körpern zu entwickeln.
Diese Arten kamen zu dem Schluss, dass es kein kluger Plan war, Krabben zu sein. Ihre Umgebung belohnte einfach immer wieder dieselbe Lösung für dieselben Probleme. Code-Agenten könnten einen ähnlichen Weg einschlagen. Sie stellen fest, dass der aktuelle Ansatz langsam ist, schreiben ein Skript, fügen bei Fehlern Wiederholungsversuche hinzu, implementieren Session-Persistence, sobald Authentifizierung möglich ist, und fügen DOM- oder Barrierefreiheitsextraktion hinzu, wenn die Seiten zu groß werden, um sie noch verarbeiten zu können.
The task requires the web.
↓
The web exposes a browser-shaped interface.
↓
The agent needs a way to operate that interface.
↓
Repeated operations make ad-hoc reasoning expensive.
↓
The agent writes reusable tools.
↓
Those tools accumulate state, retries, and abstractions.
↓
The tools start looking like a browser.
↓
Known workflows get compiled into deterministic code.
↓
The page changes so the agent re-explores.
↓
If an API exists, use it to get the data.
If not, and the site allows it, fall back to regular HTTP.
If not, stay on the browser.
Bei ausreichend vielen Durchgängen ähnelt das Ergebnis erstaunlich stark einem kleinen Browser. Das ist ein besseres mentales Modell für autonome Agenten als die Vorstellung von digitalen Personen mit einem seltsamen Interesse an Browsern. Sie verhalten sich wie gute Ingenieure, untersuchen eine unübersichtliche Umgebung, erkennen die tatsächlich vorhandene Schnittstelle und entwickeln Abstraktionen für alles, was repetitiv, zustandsbehaftet und aufwändig ist. Das Web verfügt bereits über eine alte und äußerst erfolgreiche Abstraktion zu diesem Zweck – sie trägt den Namen Browser.