Agent Browser von Vercel Labs: Der fehlende Feedback-Loop für Coding-Agenten

Dein Coding-Agent kann das Feature schreiben, es ausführen, sogar einen Test dafür bauen. Was er nicht kann — was bisher keiner konnte — ist der eine Schritt, den du automatisch machst: den Browser aufmachen und wirklich hinschauen, was du gerade gebaut hast.

Genau diese Lücke schließt Vercel Labs jetzt. Agent Browser ist ein natives Rust-CLI für Headless-Browser-Automatisierung, das deinem Agenten ein neues Werkzeug gibt: eine Seite besuchen, Elemente anklicken, Formulare ausfüllen, das Ergebnis screenshotten — und selbst entscheiden, ob das Feature wirklich funktioniert.

Die einzige Option davor war Playwright MCP — eine komplette Browser-Engine, angeflanscht als MCP-Server, gebaut für ganze End-to-End-Test-Suites. Agent Browser ist bewusst schmaler. Ein Job: den Agenten selbst hinschauen lassen, was er gebaut hat.

Im Video#

• 00:00 — Warum Coding-Agenten der Feedback-Loop fehlt
• 00:33 — Das Problem am Whiteboard
• 02:08 — Installation (npm install -g agent-browser) und erste manuelle Demo: Snapshot, Klick, Screenshot
• 04:33 — Agent-Modus: Tests in natürlicher Sprache über AGENTS.md definieren
• 06:41 — Der automatisierte Test läuft end-to-end mit Codex
• 07:53 — Fazit

(Das Video oben ist auf Englisch — die Schritte sind in der deutschen UI identisch.)

Ressourcen:

• Docs: agent-browser.dev
• Beispiel-AGENTS.md: gist.github.com/XamHans

Wie es funktioniert#

Global installieren:

npm install -g agent-browser

Seite anvisieren, Snapshot machen:

agent-browser snapshot -e

Das liefert einen Accessibility-Tree des DOM — jeder Link, jeder Button, jeweils mit Referenznummer (e26, e5, was auch immer). Genau diese Referenz ist der Trick. Der Agent rät nicht an einem CSS-Selektor rum, der bricht, sobald sich dein Markup verschiebt — er klickt eine stabile, nummerierte Referenz direkt aus dem aktuellen Seitenzustand.

agent-browser click e26

Kurz warten, bis die Seite sich beruhigt, nochmal snapshotten — weniger Elemente, andere Refs, Beweis, dass sich was bewegt hat. Dann:

agent-browser screenshot block.png

Jetzt kann der Agent seinen eigenen Screenshot anschauen und Dinge erkennen, die ein DOM-Tree nie zeigen wird: ein kaputtes Layout, ein Modal, das nicht zugegangen ist, eine Design-Regression, für die niemand einen Selektor geschrieben hat.

Daraus eine echte Test-Suite bauen#

Die Commands oben sind nur die Bausteine. Der eigentliche Gewinn ist, das Ganze in AGENTS.md einzubauen, damit der Agent es fährt, ohne dass du einen einzigen Befehl selbst tippst. Im Video werden drei Dinge definiert:

• Eine Browser-Testing-Engine — "Ich bin mit agent-browser ausgestattet. Wenn ich gebeten werde, einen Testfall auszuführen, folge ich der Standard Operating Procedure."
• Testfälle in Klartext — ein Name, eine Start-URL, die Schritte ("finde den letzten Artikel, klick auf den Read-Article-Button, warte bis die Seite lädt"), das erwartete Ergebnis.
• Die Standard Operating Procedure — Test finden, URL und Session-Namen extrahieren, agent-browser Schritt für Schritt durchlaufen lassen, nach jeder Aktion snapshotten, Ergebnis verifizieren, zurückmelden.

Sag "run test blog", und der Agent liest die Definition, öffnet die Session, klickt sich durch, screenshottet das Ergebnis und prüft es gegen das, was du erwartet hast. Niemand liest einen Diff nochmal. Niemand lädt die Seite von Hand neu.

Warum das das eigentlich fehlende Stück ist#

Agentischen Coding-Tools hat es nie an der Fähigkeit gefehlt, Code zu generieren und auszuführen. Gefehlt hat der Schritt, den jeder Entwickler im Autopilot macht: hinschauen. Agent Browser schließt diesen Loop — und ist bewusst schmal gebaut, ein schnelles CLI für genau diesen Job, kein Browser-Automatisierungs-Framework, das du erst zurechtbiegen musst.

Wenn du Agenten schon gegen eine echte Codebase laufen lässt, kosten dich zwei, drei dieser Klartext-Tests in AGENTS.md fast nichts. Was du zurückbekommst: ein Agent, der dir "es funktioniert" sagen kann — und es auch wirklich meint.