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. 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 letzte Prüfung: 34.531 Stars, Apache 2.0, Rust-CLI, aktive Vercel-Labs-Maintenance. Repo unter github.com/vercel-labs/agent-browser.
Wie installiere ich Agent-Browser?
Voraussetzung ist Node.js 24+ (das Rust-Binary wird via npm verteilt). 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 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. Der Profile-Pfad lässt sich per Flag überschreiben, wenn du strikte Isolation brauchst.
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 4.6 oder Claude Code für die Orchestrierung, MCP-Server (Notion, Drive, eigener Vector-Store) als Memory, n8n oder Cron als Trigger.
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.