LangChain: Das richtige Browser-Tool kann Kosten vervierfachen

Browser-Nutzung wird für Agenten immer wichtiger

Laut einem Beitrag von LangChain vom 3. November ist die Browser-Nutzung eine wichtige Fähigkeit für Agenten, die autonom arbeiten. Diese Systeme können Aufgaben auf Websites ausführen, die keine öffentliche API anbieten. Als Beispiele nennt das Unternehmen persönliche Agenten von Instinct und Meta Muse. Sie planen Routen für Reisen quer durch die USA, kündigen nicht mehr benötigte Abonnements und stellen Autos zum Verkauf ein.

Unter Berufung auf Daten von DataDome erklärt LangChain, dass die Zahl der Browser-Anfragen von Agenten allein im September um das 4,7-Fache gestiegen ist. Ein weiterer wichtiger Einsatzbereich der Browser-Steuerung ist das End-to-End-Testen von Webanwendungen, die von Coding-Agenten erstellt wurden.

Dafür benötigt ein Agent Tools zum Öffnen, Lesen und Interagieren mit Seiten sowie einen Browser. Der Dienst Managed Deep Agents von LangChain ermöglicht es Nutzern, Agenten in LangSmith zu erstellen und bereitzustellen, ohne eine eigene Infrastruktur zu betreiben. Der Browser kann von einem gehosteten Dienst wie Browserbase bereitgestellt werden, der laut der Ankündigung auch CAPTCHAs, Bot-Blockaden und den Betrieb großer Browser-Anzahlen übernimmt.

Stagehand wurde aus sieben Tools ausgewählt

LangChain bewertete die Tools anhand von drei Aufgabensätzen, die auf Live-Websites ausgeführt wurden. WebVoyager umfasste 100 alltägliche Aufgaben auf beliebten Websites wie Allrecipes, Amazon und Google Flights. Die Tests wurden mit Claude Sonnet 5.5 durchgeführt und von einem Jev-Judge bewertet.

HardBench bestand aus 102 schwierigeren Aufgaben, die von Browserbase zusammengestellt wurden und größtenteils Claude Opus 5.5 verwendeten. WebTailBench enthielt die sogenannten Tail Cases von Microsoft aus der realen Nutzung, von denen 150 in den Stagehand-Auswertungen durchgeführt wurden. Jedes Test-Harness gab eine strukturierte Antwort im JSON-Format zurück. Eine einzeilige Antwort statt einer Tabelle senkte die Browsing-Leistung daher beispielsweise nicht separat.

Die sieben Tools erledigten zwischen 78 und 90 Prozent der WebVoyager-Aufgaben, wobei sich Kosten und Geschwindigkeit deutlich unterschieden. Stagehand erzielte 90 Prozent bei Gesamtkosten von $1.98 und einer medianen Zeit von 17,4 Sekunden pro Aufgabe. Playwright MCP erreichte 78 Prozent bei Kosten von $26.71. Nach Berechnung von LangChain war das ungefähr 13-mal teurer, während die Aufgaben dreimal so lange dauerten.

Bei 38 Kernaufgaben aus dem schwierigeren HardBench erledigten Deep Agents mit dem codebasierten run-Tool von Stagehand 30 Aufgaben. Bei Verwendung der Kommandozeilen-browse-CLI von Browserbase waren 21 Aufgaben erfolgreich, bei dreimal höheren Kosten pro Aufgabe.

Codebasierte Abläufe verringern die Kontextlast

Nach Angaben von LangChain bringen Browser-Aufgaben zwei besondere Herausforderungen mit sich. Sie sind langwierig und erfordern daher viele aufeinanderfolgende Tool-Aufrufe, während Webseiten große Mengen an Inhalten zurückgeben, von denen oft nur ein kleiner Teil relevant ist. Eine WebVoyager-Aufgabe mit Playwright MCP erforderte durchschnittlich 26 Modellschritte. Auf dem gehosteten MCP-Server von Browserbase hatte eine Navigation eine mediane Größe von etwa 17.000 Zeichen.

Stagehand bietet drei zentrale Tools. snapshot extrahiert den Accessibility Tree der Seite und weist interaktiven Elementen Kennungen zu. run führt Aktionen aus, bündelt also entweder mehrere Klicks und Eingaben in Feldern in einem einzigen Vorgang oder verwendet JavaScript-Code im Playwright-Stil. screenshot erfasst die dargestellte Seite.

Bei einem codebasierten Ablauf kann ein Agent die gesamte Abfolge der Schritte in einem einzigen Codeblock beschreiben, etwa das Öffnen einer Seite, das Ausfüllen eines Feldes, das Klicken und die Überprüfung des Ergebnisses. Zwischendaten bleiben in Variablen, und nur die vom Agenten zurückgegebenen Inhalte werden wieder in den Kontext aufgenommen. In einem früheren Vergleich von LangChain senkte die Nutzung von Browserbase-MCP-Tools über Code und einen Interpreter die Kosten von $17.87 auf $4.52.

Das run-Tool von Stagehand verarbeitet diesen Ablauf nativ. Es nutzte durchschnittlich 10 Schritte pro Aufgabe, verglichen mit 26 bei Playwright MCP, während eine Navigation median 117 Zeichen zurückgab. Das Navigationstool von Browserbase lieferte dagegen etwa 17.000 Zeichen. Als LangChain die native API von Stagehand testete, war das Ergebnis um 5,3 Prozentpunkte schlechter, während die Kosten pro erfolgreicher Aufgabe um 19 Prozent stiegen.

Kompakte Seitenbeschreibungen und weniger Verbindungen sind ebenfalls entscheidend

Statt das vollständige HTML der Seite oder einen Screenshot zurückzugeben, stellt snapshot den Teil des Accessibility Tree bereit, den der Agent benötigt. Interaktive Elemente erhalten Kennungen, sodass der Agent sie direkt ansprechen kann, etwa in einem Klickvorgang. Browserbase zufolge erreicht Stagehand v4 eine rund 80 Prozent effizientere Token-Nutzung als Playwright.

In LangChains WebTailBench-Durchläufen hatte ein Screenshot eine mediane Größe von 89 Kilobytes. Nach den Erfahrungen des Unternehmens senkte es die Kosten nicht, das Ergebnis anschließend auf 8000 Zeichen zu kürzen, weil die Agenten die Seite einfach erneut anforderten. Das deutet darauf hin, dass die benötigten Inhalte bereits an der Quelle ausgewählt werden müssen.

Auch die Zahl der Verbindungen zwischen Browser und Agent beeinflusst die Leistung. Das Beispiel von LangChain zeigt, dass ein einzelner Playwright-Klick fünf Chrome-DevTools-Protocol-Aufrufe erfordert, weil das Tool zunächst das Element sichtbar macht, seine Position abruft und anschließend separate Aktionen zum Bewegen, Drücken und Loslassen ausführt. Stagehand v4 arbeitet als Erweiterung im Browser und sendet einen Aktionsstapel über eine einzige Verbindung. Nach eigenen Benchmarks von Browserbase ist v4 doppelt so schnell wie Playwright.

LangChain kam zu dem Schluss, dass das Design der Tools die Browsing-Leistung von Agenten deutlich beeinflusst. Entwickler untersuchten die Traces in LangSmith, um festzustellen, an welchen Stellen das System Schritte oder Tokens verschwendete, und überprüften anschließend jede Änderung durch weitere Auswertungen.