LangChain stattet Deep Agents mit verwaltetem Browser für Web-Aufgaben aus

Warum Agenten einen Browser brauchen

LangChain argumentiert, dass ein großer Teil der Aufgaben, die Menschen an Agenten abgeben wollen, im Browser stattfindet. Reisen buchen, ein Abo kündigen oder einen Schadensfall melden: All das läuft auf Websites ab, die für Menschen gebaut sind, die sich durch Seiten klicken. Oft gibt es keine API, die ein Agent aufrufen könnte, und wer eine Seite per curl abruft, erhält das HTML, bevor JavaScript gerendert wurde, und kann nichts anklicken.

Das Unternehmen verweist auf persönliche Agenten wie Instinct und Metas Muse, die bereits auf diese Weise arbeiten. Zudem nennt es DataDome, wo die Anfragen agentischer Browser allein im September um das 4,7-Fache gestiegen sind.

LangChain nennt bislang zwei gängige Anwendungsfälle. Der erste sind Aktionen, die eine API nicht abdecken kann, etwa einen Flug oder einen Restauranttisch zu buchen. Bietet eine Website für die Aufgabe eine API, sollte der Agent diese nutzen. Der zweite ist End-to-End-Testing, zum Beispiel um eine Änderung am Frontend vor dem Merge zu prüfen. Das setzt LangChain nach eigenen Angaben in Open SWE ein, seinem Coding-Agenten.

Einrichtung, Sitzungen und Login-Übergabe

Entwickler fügen einen Browser hinzu, indem sie ihn mit der Funktion define_browser aus der Datei browser.py im Projektstamm exportieren. Die Einstellung scope steuert, wie Sitzungen geteilt werden:

• thread (Standard): Jeder Thread erhält einen eigenen Browser, ohne Cookies oder Logins aus einem anderen Thread.
• user: Ein Browser wird über die Threads eines angemeldeten Nutzers hinweg geteilt. Jeder Thread hat sein eigenes Fenster, Cookies und anderer Zustand werden aber geteilt.

Der Browser stoppt nach idle_ttl_seconds ohne Aktivität, standardmäßig nach 10 Minuten, damit Nutzer nicht für einen ungenutzten Browser zahlen.

Für Schritte, die einen Menschen erfordern, etwa die Anmeldung, ruft der Agent browser_handoff mit einer Begründung auf. In LangSmith Studio erhält der Nutzer eine interaktive Karte mit demselben Browser, meldet sich selbst an und klickt auf Hand back. Der Agent macht danach bereits angemeldet weiter. So bleibt das Passwort aus den Nachrichten des Modells, aus den Traces und vom Modellanbieter fern. Die Übergabe gehört zu jedem verwalteten Browser und funktioniert automatisch in Kanälen wie Slack. Mit dem Scope user bleibt die Anmeldung für spätere Threads erhalten.

So funktionieren Browser und Tools

Managed Deep Agents betreibt den Browser in einer eigenen LangSmith-Sandbox, getrennt vom Agenten, sodass nichts auf dem Rechner des Nutzers läuft. LangChain zufolge gibt es außerdem eine private Verbindung zur Sandbox des Agenten, die End-to-End-Tests ermöglicht.

Der Agent erhält vier Tools:

• browser_snapshot liest den Accessibility-Baum der Seite und versieht interaktive Elemente mit IDs.
• browser_run führt Aktionen auf der Seite aus, entweder als Stapel von Aktionen wie Klicken und Ausfüllen oder per JavaScript über ein Page-Objekt im Playwright-Stil, das Stagehand in eigene Befehle übersetzt.
• browser_screenshot erfasst die gerenderte Seite.
• browser_handoff übergibt den Browser an einen Menschen.

Weil browser_run Code entgegennimmt, kann der Agent eine ganze Kette von Schritten als einen einzigen Aufruf schreiben und nur das zurückgeben, was er braucht. Das hält laut LangChain lange Aufgaben schnell und den Großteil der Seite aus dem Kontext des Agenten heraus. Die Tools basieren auf Stagehand, dem Open-Source-SDK von Browserbase.

Bei 100 Aufgaben aus WebVoyager, einem Benchmark für alltägliche Aufgaben auf Live-Websites, bestanden die Tools laut LangChain 90 % und kosteten insgesamt 1,98 US-Dollar. Das war die höchste Erfolgsquote unter den sieben getesteten Toolsets. Am nächsten kam der MCP-Server von Browserbase mit 89 % bei dem 9-Fachen der Kosten.

End-to-End-Tests und was das bedeutet

Für Tests läuft die App in der eigenen Sandbox des Agenten, und der Browser erreicht sie über eine Localhost-Brücke. Öffnet der Browser localhost:5173, wandert die Anfrage über eine private Verbindung zu Port 5173 in der Agent-Sandbox, sodass die App keine öffentliche URL braucht. Der Agent startet die App, klickt sich durch Abläufe wie ein Registrierungsformular und prüft, was gerendert wird. Nach einem bestandenen Test kann er seine Schritte als Testdatei speichern, da jeder browser_run-Aufruf ein Baustein eines gewöhnlichen Playwright-Skripts ist. Spätere Durchläufe spielen diese Datei ohne Modellaufrufe erneut ab, bis sich die Seite ändert.

Für Entwickler braucht es laut LangChain nur wenige Zeilen Code, um einem verwalteten Agenten einen Browser zu geben. Auch Agenten, die mit dem Open-Source-Projekt Deep Agents gebaut wurden, können einen Browser nutzen, wobei Nutzer ihren eigenen mitbringen, etwa einen gehosteten von Browserbase. LangChain plant für nächste Woche einen ausführlichen Beitrag dazu, wie die Tools getestet und abgestimmt wurden.