Stagehand 3.7: das SDK, das Browser-Agenten Playwright-Vertrautheit gibt
Projektüberblick: Das SDK für Browser-Agents. Bei den meisten bestehenden Browser-Automatisierungstools müssen Sie entweder Low-Level-Code in einem Framework wie Selenium, Playwright oder Puppeteer schreiben oder High-Level-Agents verwenden, die in der Produktion unvorhersehbar sein können.
Auf einen Blick
- Was ist das?
- Stagehand von Browserbase positioniert sich gegen Playwright als Tests-Werkzeug und liefert Agenten vertraute APIs, selbstheilende Aktionen und Token-Disziplin über TypeScript, Python und Go.
- Für wen ist es gedacht?
- Stagehand passt für Teams, die Browser-Agenten mit Produktionsansprüchen bauen: bekannte Playwright-Methoden für deterministische Stellen, act, observe und extract für Stellen, wo sich Seiten ändern, plus OTel und Batch-Befehle für Betrieb. Ungünstig ist es, wer einen reinen No-Code-Agenten sucht, denn die Kontrolle liegt bewusst im Code und der Beschaffung von BROWSERBASE_API_KEY und einem LLM-Schlüssel.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Playwright war für Tests gebaut, Stagehand für Agenten
Stagehand kommt von Browserbase und beschreibt sich als das SDK für Browser-Agenten. Die Kernthese des README: Playwright wurde für Tests gebaut, Stagehand für Agenten. Die Begründung liegt in der Werkzeugkluft, die der Repository-Kontext benennt: Bestehende Automatisierung verlangt entweder Low-Level-Code in Frameworks wie Selenium, Playwright oder Puppeteer, oder High-Level-Agenten, die in der Produktion unvorhersehbar sind. Stagehand will beide Seiten verbinden.
Die Metadaten ordnen das Projekt ein: TypeScript als Hauptsprache in einem Monorepo mit Python und Go, MIT-Lizenz, rund 24090 Sterne und 1658 Forks, 341 offene Issues, Branch main, Homepage stagehand.dev, Dokumentation unter docs.stagehand.dev. Das Release-Tempo ist dicht, stagehand-server-v3 v3.7.6 und @browserbasehq/stagehand 3.7.3 erschienen beide am 28. August 2026, davor v3.7.5 am 20. August.
act, observe und extract: die selbstheilenden Primitive
Der Kern der Agentenschnittstelle sind drei Primitive, die natürliche Sprache entgegennehmen: act, observe und extract. Wenn sich Webseiten ändern, erkennt Stagehand das laut README und aktualisiert selbst, wie die Aktionen auf der Seite ausgeführt werden. Genau dieses Self-Healing unterscheidet die Primitive von starren Selektoren, die bei jedem Redesign brechen.
Um die Primitiven herum sammelt das README die Agenten-Features: WebMCP, Clipboard-Unterstützung, Batch-Befehle, Deep Locators für verschachtelte iframes und OTel-Unterstützung für Beobachtbarkeit. Ausdrücklich genannt werden auch schwierige DOM-Strukturen, out-of-process iframes und geschlossene Shadow DOMs, für die das SDK native Unterstützung mitbringt. Für Produktionsszenarien zählt besonders der letzte Block, denn ohne Beobachtbarkeit und Batching bleiben Agentenläufe schwer zu betreiben.
Token-Diät durch hybrid Accessibility-Tree-Trimming
Ein eigener Abschnitt widmet sich den Kosten. Stagehands hybrid Accessibility-Tree-Trimming gibt Agenten laut README genau das, was sie brauchen, um die Seite zu verstehen, und nichts weiter. Das ist die Antwort auf das klassische Problem von Browser-Agenten, die bei jedem Schritt ganze Seiten als Kontext mitziehen und dadurch teuer und langsam werden.
Dazu passt die Architekturangabe zur Latenz: Stagehand läuft als Erweiterung neben dem Browser, verkürzt den Weg und senkt die Round-Trip-Latenz aller Aktionen auf der Seite. Das README verspricht daraus drei Effekte: Agenten verbrauchen weniger Tokens, erholen sich, wenn sich Webseiten ändern, und schließen Aufgaben zuverlässiger ab. Diese Angaben sind Selbstauskunft des Herstellers, sie benennen aber nachvollziehbar, an welchen Stellen das Design greift, Kontextaufbereitung, Ausführungsnähe und Wiederherstellung.
Das TypeScript-Beispiel mit browserbase.launch und Stagehand.create
Das Beispiel im README zeigt den Aufbau im Detail. Zuerst werden BROWSERBASE_API_KEY und OPENAI_API_KEY aus process.env gelesen. Der Browser entsteht mit await browserbase.launch({ apiKey: BROWSERBASE_API_KEY }), danach await Stagehand.create({ browser, model: { modelName: 'openai/gpt-5.4-mini', apiKey: OPENAI_API_KEY } }). Die erste Seite kommt aus browser.context.pages(), ein goto auf https://github.com/browserbase folgt.
Der Kommentar im Beispiel nennt die CDP-Engine von Stagehand eine optimierte, Low-Level-Schnittstelle zum Browser, gebaut für Automation. Die Playwright-artigen Methoden goto, click, locator und screenshot bleiben daneben verfügbar, das ist die bewusste Brücke: Deterministisches bleibt Code, Unbekanntes geht an die Primitive. Äquivalente Beispiele für die anderen Sprachen verlinkt das README unter packages/sdk-python/README.md und packages/sdk-go/README.md.
Bau aus dem Quellcode mit just install, just generate und just build
Das Monorepo vereint TypeScript, Python und Go, angetrieben vom Werkzeug just, das pnpm, uv und go zusammenführt. Der Weg aus dem Quellcode lautet: git clone https://github.com/browserbase/stagehand.git, cd stagehand, dann just install, just generate und just build. Für Läufe mit echtem Modell braucht es export OPENAI_API_KEY und export BROWSERBASE_API_KEY, damit die Schlüssel in process.env liegen.
Die Beispiele liegen unter packages/sdk-ts/examples, ausgeführt mit just example act, was das Skript act.ts startet. Diese Befehlskette ist zugleich der sauberste Prüfpfad für Neulinge: Wer die Beispiele gegen die eigene Zielseite laufen lässt, sieht sofort, ob die Primitive mit den eigenen Seitenstrukturen klarkommen, ob der Zugriff über Browserbase-Credentials funktioniert und wie sich Latenz und Tokenverbrauch beim eigenen Modell verhalten. Details zum Python- und Go-Setup verweist das README an CONTRIBUTING.md.
Beitragsprioritäten: Zuverlässigkeit vor Erweiterbarkeit vor Geschwindigkeit vor Kosten
Der Contributing-Abschnitt nennt die Projektprioritäten ausdrücklich in fester Reihenfolge: Zuverlässigkeit, Erweiterbarkeit, Geschwindigkeit, Kosten. Beiträge werden geschätzt, Fragen und Support gehen in die Discord-Community. Als Einstieg empfohlen sind Bugfixes und kleine Verbesserungen, für umfangreichere Features soll man vorher Miguel Gonzalez oder Paul Klein über Discord kontaktieren, damit der Beitrag zu den Zielen passt.
Für Nutzer ist diese Rangfolge ein brauchbarer Hinweis darauf, was im Projekt stabiler Versprechen gilt: Zuverlässigkeit wird als erste Dimension geführt, Geschwindigkeit und Kosten folgen danach. Rechtlich gehört zur Einordnung noch die Trademark-Zeile: Stagehand ist eine Marke von Browserbase, Inc., der Code steht unter MIT mit Copyright 2026 Browserbase, Inc. Wer das SDK in ein eigenes Produkt einbaut, darf das unter MIT tun, den Namen selbst aber nicht einfach weiterverwenden.
Redaktionelles Fazit
Stagehand passt für Teams, die Browser-Agenten mit Produktionsansprüchen bauen: bekannte Playwright-Methoden für deterministische Stellen, act, observe und extract für Stellen, wo sich Seiten ändern, plus OTel und Batch-Befehle für Betrieb. Ungünstig ist es, wer einen reinen No-Code-Agenten sucht, denn die Kontrolle liegt bewusst im Code und der Beschaffung von BROWSERBASE_API_KEY und einem LLM-Schlüssel. Vor einem Ernstbetrieb sollte man das Beispiel aus packages/sdk-ts/examples mit just example act gegen die eigene Zielseite fahren und prüfen, wie das Self-Healing reagiert, wenn ein Selektor sich ändert.
Community-Notizen