LangChain gibt Managed Deep Agents einen eigenen Browser
Der Dienst betreibt den Browser selbst, die Tools sind laut Hersteller auf kontexteffiziente Nutzung abgestimmt. Zu Speicherung der Zugangsdaten, Preisen und Verfügbarkeit bleiben Fragen offen.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- LangSmith lässt Nutzer Agenten ohne eigene Infrastruktur bauen und deployen; LangSmith betreibt Harness und Runtime.
- Managed Deep Agents betreibt jetzt einen Browser für Agenten mit kontexteffizienten Tools.
- Nutzer loggen sich per Handoff auf Webseiten ein; Zugangsdaten bleiben sitzungsübergreifend gespeichert.
- Der Browser ermöglicht Klicken, Scrollen und Formulare; reines curl liefert nur HTML vor dem Rendering.
Managed Deep Agents bekommt einen Browser, den LangChain selbst betreibt
LangChain stattet Managed Deep Agents in LangSmith mit einem Browser aus. Den Betrieb übernimmt der Dienst selbst, so steht es in der Ankündigung des Unternehmens. Die Tools für den Browser seien laut LangChain auf eine kontexteffiziente Nutzung abgestimmt („tuned“). Einen Vorteil gegenüber anderen Ansätzen beziffert der Hersteller nicht. Ob die Abstimmung den Token- oder Kontextverbrauch tatsächlich spürbar senkt, lässt sich anhand der vorliegenden Angaben nicht beurteilen. Dafür bräuchte es unabhängige Tests.
Managed Deep Agents richtet sich an Entwickler, die Agenten in LangSmith bauen und ausliefern wollen, ohne eigene Infrastruktur zu betreiben. Nutzer schreiben Instruktionen und Tools. LangSmith betreibt Harness und Runtime. Der Browser soll diese Aufteilung auf Aufgaben im Web ausdehnen: Der Dienst betreibt den Browser, der Agent erhält dafür passende Werkzeuge. Wie der Browser technisch umgesetzt ist, geht aus den Angaben nicht hervor.
Sessions pro Thread und Nutzer, Login per Handoff
Laut LangChain unterstützt Managed Deep Agents Browser-Sessions, die an einen Thread und an einen Nutzer gebunden sind. Über sogenannte Handoffs melden sich Nutzer selbst auf Webseiten an und interagieren danach mit ihnen. Die Zugangsdaten bleiben sitzungsübergreifend gespeichert. Wie der Agent mit diesen gespeicherten Zugangsdaten umgeht, bleibt offen; die Ankündigung äußert sich dazu nicht.
Offen bleibt auch, wo und wie die Zugangsdaten abgelegt werden. Speicherort, Verschlüsselung und Widerruf nennt die Ankündigung nicht. Zwei Punkte liegen für Betreiber nahe. Der erste ist die Sicherheit. Ein Agent, der in eingeloggten Sitzungen arbeitet und fremde Webseiten verarbeitet, lässt sich per Prompt Injection manipulieren. Der Zugriff auf diese Sitzungen muss sich deshalb begrenzen lassen. Der zweite ist der Datenschutz. Dauerhaft gespeicherte Zugangsdaten werfen Datenschutzfragen auf, etwa zu Speicherort, Zugriff und Löschung. Die Ankündigung äußert sich dazu nicht.
Warum LangChain den Browser statt APIs einsetzt
LangChain begründet den Schritt damit, dass viele Aufgaben im Web keine API haben. Buchungen, Kündigungen oder Schadensmeldungen laufen auf Seiten ab, die für klickende Menschen gebaut sind. Ein Browser erlaubt es Agenten, zu klicken, zu scrollen und Formulare auszufüllen. Ein reiner Abruf per curl liefert dagegen nur das HTML vor dem Rendern durch JavaScript. Klicken kann er damit nichts.
Als Marktkontext nennt das Unternehmen Personal Agents wie Instinct und Metas Muse, die bereits browserbasiert arbeiten. Außerdem habe DataDome im September einen Anstieg agentischer Browser-Anfragen um das 4,7-Fache beobachtet. Beides sind Angaben von LangChain, die hier nicht unabhängig geprüft wurden. Die Aussage, Agenten seien inzwischen gut genug, um dort zu arbeiten, wo Menschen arbeiten, ist eine werbliche Einschätzung des Herstellers. Belegt sind weder Verfügbarkeitsstatus noch Preise. Ein Vergleich mit dem Vorgängerstand oder mit Konkurrenzangeboten fehlt ebenfalls.



