Browser Harness: Wenn der Agent seinen eigenen Browser-Treiber schreibt

Wer schon einmal einen Agenten gebaut hat, der „einfach mal kurz" eine Webseite bedienen soll, kennt das Drama: Selektoren, die nach dem nächsten Deploy verschwinden. Playwright-Wrapper, die für 80 % der Seiten funktionieren – und ausgerechnet bei der Seite scheitern, die der Kunde gerade braucht. Captchas, Iframes, Shadow-DOM, Single-Page-Apps, die ihre Knöpfe per JavaScript an unerwarteten Stellen rendern.

Browser Use, eines der bekanntesten Projekte für browserbasierte AI-Agenten, legt jetzt einen Gegenentwurf vor, der bewusst mit den bisherigen Frameworks bricht: Browser Harness – ein „self-healing harness" für Browser-Agenten, mit zugehöriger Landing-Page unter browser-harness.com.

Die zentrale Idee in einem Satz: Statt dem Agenten Werkzeuge zu geben, gibt man ihm einen sehr dünnen, editierbaren Werkzeugkasten – und lässt ihn die fehlenden Werkzeuge selbst schreiben, während er arbeitet.

Was ist daran neu?

Bisherige Stacks für Browser-Automatisierung haben eines gemeinsam: sie sind aufgebläht. Playwright, Puppeteer und ihre Agent-Wrapper schleppen tausende Zeilen Code für Selektor-Engines, Retry-Logik, Session-Management, DOM-Snapshots und Click-Heuristiken mit sich herum. Das hilft, solange die Welt sich genau so verhält, wie sich der Framework-Autor das vorgestellt hat. Sobald das nicht mehr der Fall ist, kämpft der Agent gegen die Abstraktion an, statt mit ihr.

Browser Harness dreht das um:

• Eine einzige WebSocket-Verbindung zu Chrome über das Chrome DevTools Protocol (CDP) – nichts dazwischen.
• ~1.000 Zeilen Code, verteilt auf vier Kerndateien. Das ist kein Tippfehler. Der gesamte Harness ist klein genug, dass ein Modell ihn in einem einzigen Kontextfenster überblickt.
• Der Agent editiert seine eigenen Helfer. In agent-workspace/agent_helpers.py legt er zur Laufzeit neue Funktionen ab, sobald er merkt, dass eine fehlt. Diese Helfer bleiben für den nächsten Lauf erhalten – der Harness wird mit jedem Task ein bisschen mächtiger.
• Domain-Skills als Community-Playbooks. Unter agent-workspace/domain-skills/<site>/ sammeln sich pro Domain stabile Selektoren, API-Tricks und Edge-Cases – nicht von Menschen geschrieben, sondern vom Agenten selbst gefunden und per PR beigesteuert.

Das ist die titelgebende „Selbstheilung": Wenn ein Schritt scheitert, schreibt der Agent den fehlenden Helper, führt ihn aus, und das nächste Mal ist er bereits da. Aus dem klassischen Bild „Werkzeug + Agent" wird ein lebendes System, das mit Nutzung wächst.

Wie sieht das in der Praxis aus?

Die Aufrufkonvention ist absichtlich primitiv – ein Heredoc voll Python an ein CLI:

browser-harness <<'PY'
new_tab("https://docs.browser-use.com")
wait_for_load()
print(page_info())
PY

Keine Subcommands, kein argparse, kein „Session-Manager", keine Konfigurationspipeline. run.py startet den Daemon, führt den Python-Block aus, fertig. Wer Browser-Wrapper aus dem Playwright-Universum gewohnt ist, sucht hier instinktiv nach Vertrautem – und genau das ist der Punkt.

Der vom Projekt empfohlene Interaktionsstil ist ebenso minimalistisch:

Screenshot machen → Pixel ablesen → click_at_xy(x, y) → Screenshot zur Verifikation.

Statt sich durch CSS- oder XPath-Selektoren zu kämpfen, nutzt der Agent Koordinaten-Clicks via Input.dispatchMouseEvent. Das geht durch Iframes, Shadow DOM und Cross-Origin-Grenzen einfach hindurch, weil Chrome das im Compositor auflöst – nicht im DOM. Selektoren werden zur Ausnahme, nicht zur Regel.

Was bekomme ich aus der Box?

• Lokaler Modus: Der Agent verbindet sich mit dem schon laufenden Chrome des Users (Stichwort chrome://inspect/#remote-debugging). Keine eigenen Browser-Launches, keine Session, die parallel zur echten des Users läuft.
• Stealth-Browser in der Cloud über Browser Use Cloud – inkl. Proxies und Captcha-Solving, mit kostenfreiem Tier (3 parallele Browser).
• 24/7-Deployments auf einer „Browser Use Box".
• Sub-Agenten: jeder bekommt seinen eigenen isolierten Browser (BU_NAME), parallel ausführbar.

Setup-Aufwand für Nutzer:innen: ein einziger Prompt an Claude Code oder Codex, „lies install.md und folge den Schritten" – der Agent installiert sich quasi selbst.

Warum die Architektur klein bleibt – und warum das wichtig ist

In der README finden sich Design-Constraints, die fast schon den Tonfall eines Manifests haben:

Don't add a manager layer. No retries framework, session manager, daemon supervisor, config system, or logging framework.

Das ist keine Faulheit, das ist eine These: Je mehr Logik der Harness selbst übernimmt, desto weniger kann der Agent verstehen, was schiefläuft, und desto schwerer kann er korrigieren. Eine fette Abstraktion versteckt die Wahrheit der Maschine vor dem Modell. Ein dünner Harness lässt das Modell direkt mit dem Browser verhandeln – und gibt ihm einen Workspace, in dem es seine Erkenntnisse ablegen kann.

Das passt zu einer These, die das Browser-Use-Team gerade systematisch ausformuliert – siehe ihre Posts „The Bitter Lesson of Agent Harnesses" und „Web Agents That Actually Learn": Frameworks, die das Modell „smart" zu machen versuchen, indem sie ihm Entscheidungen abnehmen, altern schlecht. Frameworks, die dem Modell rohen Zugang und einen Platz zum Lernen geben, altern gut.

Die Vorteile – jetzt und in Zukunft

Drei Stränge, warum dieses Projekt mehr ist als nur „noch ein Automation-Tool":

1. Robust gegen Layout-Änderungen. Koordinaten-Clicks und runtime-generierte Helfer überleben Frontend-Refactors deutlich besser als hartkodierte Selektoren. Wenn doch etwas bricht, wird der Fix Teil des Skills für die nächste Runde.

2. Skaliert mit Modell-Fähigkeit, nicht mit Framework-Code. Je besser die zugrundeliegenden LLMs werden, desto kompetenter wird der Harness automatisch – ohne dass jemand eine neue Abstraktion in die Codebase schreiben muss. Klassische Wrapper profitieren genau umgekehrt: jede Modellverbesserung legt eine weitere Schicht ihres Overheads frei.

3. Wissen kumuliert öffentlich. Die domain-skills/-Sammlung ist der vielleicht spannendste Teil. Wenn ein Agent für LinkedIn-Outreach, Amazon-Bestellungen oder Expense-Filing einmal die zuverlässigen Pfade gefunden hat, landen die als PR im Repo und stehen allen zur Verfügung. Das ist im Kern ein versioniertes, kollaboratives Gedächtnis für das Web, geschrieben von Agenten, kuratiert von Menschen.

Für Indie Hacker, Solo-Founder und kleine Teams bedeutet das: Browser-Automatisierung wird von einer Spezialdisziplin zu etwas, das man am Abend nebenbei aufsetzt – mit der berechtigten Hoffnung, dass es Wochen später noch funktioniert.

Wo ich vorsichtig wäre

Der ehrliche Teil: Ein selbstheilender Harness, der Python-Code schreibt und ausführt, ist genau so mächtig und genau so gefährlich, wie es klingt.

• Code-Ausführung im Workspace ist explizit Teil des Designs – nicht etwas, was man „abschalten" sollte, ohne die Idee zu verlieren. Sandboxing wird zur Verantwortung des Nutzers.
• Auth ist explizit ausgeschlossen. Das Projekt sagt offen: Wenn der Agent vor einer Login-Wand steht, soll er stoppen und nachfragen, nicht Credentials aus Screenshots eintippen. Das ist die richtige Default-Haltung, verschiebt aber das Secret-Management auf die Aufrufer-Seite.
• Domain-Skills sind öffentlich. Wer per PR beiträgt, sollte sich daran erinnern: keine Pixel-Koordinaten, keine Secrets, keine Task-Narration – nur die dauerhafte Struktur der Seite.

Nichts davon ist ein Showstopper, aber alles davon ist ein Stück Disziplin, das man als Team etablieren sollte, bevor man Browser Harness in produktive Workflows einbaut.

Warum das wichtig ist

Browser-Agenten sind eine der wenigen Stellen, an denen LLMs auf eine Welt treffen, die sich nicht um sie schert. Webseiten ändern sich, ohne dem Agenten Bescheid zu sagen. Frameworks, die diesen Konflikt durch zusätzliche Schichten lösen wollen, häufen Tech-Debt an, der mit jedem neuen Modell-Release veraltet.

Browser Harness wählt den entgegengesetzten Weg: weniger Code, mehr Modell, ein offener Workspace zum Lernen. Das ist nicht der einzige denkbare Ansatz – aber er ist konsequent, MIT-lizenziert, und ab heute öffentlich. Für alle, die Agenten bauen, die nicht nur in Demos funktionieren, sondern auch in der zweiten Woche noch, lohnt sich ein langer Blick darauf.

Ein WebSocket. Kein Wrapper. Ein Agent, der seine Werkzeuge selbst schmiedet.

Damit kommt man erstaunlich weit.