Agent-Browser ist ein reines Browser-CLI von Vercel Labs, das einem KI-Agenten strukturellen Zugriff auf eine Webseite gibt statt Screenshots. Der Agent liest den Accessibility-Tree mit Referenzen wie @e1 und @e2 und klickt per Ref statt per Pixel. Ergebnis: rund 90% weniger Tokens als Playwright MCP, schneller und billiger.
Was ist Agent-Browser?
Browser-Automatisierung war lange ein QA-Thema. Tester wollten Klicks simulieren, Screenshots vergleichen, Bugs reproduzieren. Daraus wurde Playwright, dann Playwright MCP. Sobald KI-Agenten das Tool als Klick-Roboter nutzen, kippt es in einen Token-Brand.
Agent-Browser dreht die Logik um. Statt visueller Wahrnehmung bekommt der Agent DOM, semantische Selektoren und persistenten Session-State. Der Agent sieht nicht, er liest. Den Barrierefreiheitsbaum bauen Browser ohnehin aus dem DOM, damit Screenreader die Seite verstehen. Jeder Knoten darin trägt laut MDN Web Docs Name, Beschreibung, Rolle und Zustand, also die Angaben, mit denen sich ein Element ohne Pixel ansprechen lässt. Das Tool selbst ist ein CLI, kein KI-Agent. Es hat keine eigene KI-Auth (kein OpenAI- oder Anthropic-Key im Tool), die KI sitzt drumherum und ruft Commands auf.
Stand 17.08.2026: 40,8k Stars, Apache 2.0, Rust-CLI, aktive Vercel-Labs-Maintenance. Im Repository von Vercel Labs beschreibt sich das Tool selbst als „Browser automation CLI for AI agents. Fast native Rust CLI.“, der Snapshot steht dort als „Accessibility tree with refs (best for AI)“.
Wie installiere ich Agent-Browser?
Für die empfohlene globale npm-Installation nennt das Repository keine Node-Mindestversion, das Rust-Binary kommt fertig gebaut über npm. Nur wer selbst aus dem Quellcode baut, braucht laut README Node.js 24+, pnpm 11+ und Rust. Der Kern-Ablauf:
- 1.Global installieren mit npm (
npm install -g agent-browser). - 2.Einmalig
agent-browser installlaufen lassen (zieht Chrome for Testing, ca. 171 MB). - 3.Smoke-Test: eine Seite öffnen, Snapshot ziehen, per Ref klicken, schließen.
Hast du bereits Chrome, Brave, Playwright oder Puppeteer installiert, erkennt agent-browser das automatisch und der Chrome-Pull ist optional. Alternativen: brew install agent-browser (macOS), cargo install agent-browser (Rust-Devs), agent-browser install --with-deps (Linux mit System-Dependencies). Updates via agent-browser upgrade (erkennt die Install-Methode selbst).
Welche Commands brauche ich?
Die wichtigsten Befehle im Überblick:
| Command | Was es macht |
|---|---|
open <url> | Browser starten und URL öffnen |
snapshot | Accessibility-Tree mit Refs holen (das Kern-Feature) |
click @eN | Element via Ref klicken |
fill @eN "text" | Input-Feld füllen (Clear und Insert) |
type @eN "text" | Type-Event simulieren |
press <key> | Taste drücken (Enter, Tab, Control+a) |
get text @eN | Text-Content holen |
find role <role> | Element nach Rolle suchen (button, link, textbox) |
screenshot <file.png> | PNG-Screenshot für Vergleich oder Doku |
close | Browser schließen |
Klassische CSS- oder jQuery-Selektoren funktionieren auch (click "#submit"). Für Agenten sind die @eN-Refs aber stabiler, weil sie nicht an fragilen Markup-Details hängen.
Wie sieht ein erster Run aus?
Der Snapshot ist der Hebel. Ein agent-browser snapshot liefert Text statt Bild:
- heading "Example Domain" [level=1, ref=e1]
- link "Learn more" [ref=e2]Läuft das, ist alles korrekt installiert. Für einen echten Use-Case öffnest du eine Seite, schreibst den Snapshot in ein Text-File und holst einzelne Elemente per get text @eN. Du hast dann die Page-Struktur als Text und reichst sie an Claude für die Content-Analyse weiter. Kein Screenshot, keine 18k Tokens pro Aktion, kein OCR-Overhead.
Wie gut der Snapshot ausfällt, hängt an der Seite, die du öffnest. WebAIM hat im Februar 2026 die Startseiten von einer Million Websites aus dem Tranco-Ranking automatisiert geprüft, das mehrere Quellen für Top-Websites kombiniert und keine Besuchszahlen-Rangliste ist, und fand auf 95,9 Prozent davon erkannte WCAG-2-Fehler. Das ist das WCAG-Gesamtbild. Der häufigste Fehlertyp ist mit 83,9 Prozent zu geringer Textkontrast, und der berührt den Accessibility-Tree gar nicht. Für den Snapshot zählen andere Zahlen derselben Auswertung: fehlende Formular-Labels auf 51,0 Prozent der Startseiten, leere Links auf 46,3 Prozent, leere Buttons auf 30,6 Prozent. Die dort genannten 56,1 Fehler pro Seite sind der Schnitt über alle eine Million geprüften Startseiten, nicht je betroffener Seite. Untersucht wurden ausschließlich Startseiten und nur maschinell erkennbare Fehler, die Dunkelziffer liegt also höher. Fehlende Labels und falsche Rollen treffen Screenreader und Agenten gleichermaßen: Taucht ein Button ohne Namen im Snapshot auf, hilft dir der Ref allein nicht weiter.
Wie persistiere ich den Login-State?
Profile, Cookies und Session-Storage liegen in ~/.agent-browser/ und bleiben zwischen Runs erhalten. Du konfigurierst nichts. Der Ablauf für Tools mit Login (Notion-Export, Stripe-Dashboard):
- 1.Run 1: Seite öffnen und von Hand einloggen. Der Token wird gespeichert.
- 2.Run 2 bis N: Der Agent öffnet die Seite direkt und ist schon eingeloggt.
Bei sensiblen Workloads (Banking, Admin-Panels) prüf, ob Token-Persistenz für deinen Fall okay ist. Das BSI empfiehlt für KI-Agenten eine Trennung der Zugriffsrechte: „Kein Agent sollte etwa gleichzeitig Zugang zu Ihren E-Mails, Ihrem Bankkonto und Ihren persönlichen Dateien haben.“ Der Profile-Pfad lässt sich per Flag überschreiben, wenn du strikte Isolation brauchst. Ein eigenes Profil pro Aufgabe ist die praktische Umsetzung dieser Empfehlung.
Wie orchestriere ich Agent-Browser mit Claude Code?
Hier liegt der adcompany-Spin. Claude Code ruft agent-browser per Bash-Tool auf, parst den Snapshot, entscheidet welchen Ref es klickt und ruft den nächsten Command auf. Das ist die volle Agent-Loop ohne Screenshot-Spam.
Du beschreibst das Ziel, nicht jeden Klick. Beispiel: Headlines und CTAs einer Konkurrenz-Seite als Markdown-Tabelle. Claude Code öffnet die Seite, liest den Accessibility-Tree, filtert auf heading- und button-Rollen, holt bei Bedarf den Text pro Ref und gibt die Tabelle zurück. Es orchestriert, dokumentiert und liefert strukturiertes Output.
Empfohlener Stack: agent-browser für die Browser-Ebene, Claude Sonnet 5 oder Claude Code für die Orchestrierung, MCP-Server (Notion, Drive, eigener Vector-Store) als Memory, n8n oder Cron als Trigger. Das Model Context Protocol ist dabei der Stecker. t3n beschreibt es 2025 als Standard, um große Sprachmodelle mit externen Anwendungen und Daten zu verknüpfen, bis hin dazu, dass ein Modell die Kontrolle über den Webbrowser übernimmt.
Wann ist Agent-Browser NICHT die Lösung?
- ·One-Off-Screenshots: Für einen einmaligen Screenshot ist Playwright überdimensioniert. Browser-Plugin oder curl reicht.
- ·Visual Regression Testing: Da war und bleibt Playwright stark. Nicht dein Tool.
- ·Komplexe Visual-State-Flows: Muss der Agent visuell verstehen (Canvas, WebGL, komplexe Animationen), brauchst du einen Hybrid.
Häufige Fallen: einen Mega-Agenten bauen statt drei kleiner, die zusammenspielen. Den Login-State nicht persistent ablegen, sodass jeder Run bei Null startet. Den Browser für Tasks nutzen, die per REST-API schneller wären. Der Browser ist Fallback, nicht Default.
Was bringt der Token-Vorteil konkret?
Rechenbeispiel aus dem Pack für 20 Browser-Tasks pro Tag: Mit Playwright MCP rund 360.000 Tokens täglich (20 Tasks mal 20 Steps mal 18k Tokens). Mit agent-browser rund 36.000 Tokens, also 90% weniger. Dazu fällt die Run-Zeit, weil der Screenshot-Overhead wegfällt. Heißt: schneller iterieren, mehr testen, weniger warten. Das Pack ersetzt nicht die offizielle Vercel-Doku. Geh durch das Repo, bevor du produktiv gehst.