Claude Browser Use API: Unternehmensportale mit eigenen Agenten bedienen

Was die Claude Browser Use API von Computer Use unterscheidet

Direktantwort: Browser Use arbeitet in einem Browser, den deine Anwendung betreibt. Es verwendet Seitenstruktur und Screenshots, um beispielsweise Felder oder Schaltflächen anzusteuern. Computer Use bedient dagegen eine Desktopumgebung über Bildschirmbilder, Maus und Tastatur. Für reine Webportale ist Browser Use daher der naheliegende erste Test; bei Aufgaben zwischen mehreren Desktopprogrammen kommt Computer Use infrage. Quelle: Browser-Use-Dokumentation.

Die Produktankündigung vom 20. August verbindet diese Werkzeuge mit zwei weiteren Bausteinen: Skills enthalten wiederverwendbare Arbeitsanweisungen und Vorlagen; die Files API stellt Dateien über eine ID für wiederholte Verarbeitung bereit. Daraus entsteht noch kein fertiger Geschäftsprozess. Zuordnung zum Auftrag, Berechtigungen, Fehlerbehandlung und Abnahme muss deine Anwendung organisieren.

Wenn du direkt in deinem eigenen Chrome-Browser arbeiten möchtest, lies stattdessen unseren praktischen Leitfaden zu Claude in Chrome. Der vorliegende Artikel richtet sich an Verantwortliche für eigene Anwendungen und Automatisierungen. Ein vorhandenes Claude-Teamkonto beantwortet die technischen und organisatorischen Fragen einer API-Integration nicht automatisch.

Architektur: Claude plant, deine Anwendung führt aus

Bei Computer Use liefert Claude Werkzeuganforderungen zurück. Dein Programm setzt sie in der eigenen Umgebung um und sendet Ergebnisse an die API. Das aktuelle Toolset kann mehrere Aktionen in einer Antwort liefern. Jede benötigt ein zugehöriges Ergebnis; nach einem Fehler müssen auch übersprungene Aktionen korrekt beantwortet werden. Die Umgebung und die Programmschleife gehören damit zu deiner Integration. Quelle: Ausführung und Agentenschleife.

Unser Architekturvorschlag: Trenne Auftragsverwaltung, Ausführung und Freigabe. Die Auftragsverwaltung hält die fachliche Aufgabe und ihren Status. Ein begrenztes Ausführungskonto bedient das Portal. Eine Freigabeansicht zeigt dem Mitarbeiter die vorbereitete Änderung samt Quelle. Erst dessen Bestätigung erlaubt eine verbindliche Übertragung.

1. Ein Auftrag benennt Datenquelle, Zielportal und gewünschtes Ergebnis.
2. Die Anwendung stellt freigegebene Daten und benötigte Werkzeuge bereit.
3. Claude schlägt Aktionen vor; die Anwendung prüft Rechte und führt erlaubte Schritte aus.
4. Die Anwendung liest den tatsächlichen Zustand zurück und protokolliert das Ergebnis.
5. Ein Mensch prüft die Zusammenfassung und bestätigt gegebenenfalls den letzten Schritt.

Plane den Abbruch genauso konkret wie den Erfolgsfall. Wenn eine Sitzung abläuft, eine Schaltfläche fehlt oder eine Datei nicht lesbar ist, soll der Auftrag einen nachvollziehbaren Status erhalten. Ein erneuter Start darf nicht versehentlich denselben Vorgang zweimal anlegen. Dafür empfehlen wir eine stabile Auftragsnummer und einen Zustandscheck vor schreibenden Aktionen.

Skills und Files: Fachwissen und Dokumente getrennt verwalten

Die Skills API erlaubt eigene, versionierte Skills. In der API laufen sie in der Codeausführungsumgebung; externe Netzwerkzugriffe und nachträgliche Paketinstallationen sind dort laut Dokumentation eingeschränkt: API-Skills haben keinen Netzwerkzugriff und verwenden vorinstallierte Pakete. Skills aus claude.ai, Claude Code und der API synchronisieren sich nicht automatisch. Quelle: Skills, Laufzeit und Grenzen.

Für unseren vorgeschlagenen Lieferantenprozess würde ein Skill beispielsweise festlegen, welche Felder ein Prüfbericht braucht, wie Abweichungen markiert werden und welche Vorlage verwendet wird. Zugangsdaten würden wir weder in diesen Anweisungen noch in einer Berichtsvorlage speichern. Die Anwendung stellt die erlaubten Portalaktionen getrennt bereit.

Die Files API nimmt Dokumente auf und liefert eine file_id. Dateien sind innerhalb ihres Workspace nutzbar. Ein optionales Ablaufdatum begrenzt die spätere Abrufbarkeit; es ist keine Zusage sofortiger vollständiger Löschung. Die Dokumentation nennt bis zu 500 MB pro Datei und 1 TB pro Organisation. Quelle: Dateiverwaltung und Lebenszyklus.

Praktisch empfehlen wir eine Zuordnung aus Auftrag, Dateiversion und freigegebenem Verwendungszweck. Wenn eine korrigierte Tabelle eingeht, muss erkennbar sein, welche Version das Ergebnis erzeugt hat. Bewahre das finale Dokument zusammen mit den benötigten Quellenangaben auf. Eine bloße Datei-ID erklärt deinem Fachteam später nicht, warum eine Entscheidung zustande kam.

Verfügbarkeit und Datenfluss vor der Auswahl prüfen

Stand 29. September führen die aktuellen Dokumentationen Browser Use und das neue Computer-Toolset für Claude API und Google Cloud. Andere Plattformen unterstützen teilweise ältere Computer-Use-Versionen. Die Files API ist auf Claude API, Claude Platform on AWS und Microsoft Foundry aufgeführt; bei Foundry erfordert sie ein „Hosted on Anthropic“-Deployment. Produktname und Modellzugang allein garantieren daher nicht dieselben Werkzeuge. Browser-Kompatibilität, Computer-Kompatibilität und Files-Kompatibilität.

Der Browser kann in deiner Infrastruktur laufen; an Claude zurückgesendete Screenshots, Seitentexte und Tabinformationen werden trotzdem API-Inhalt. Browser Use ist grundsätzlich für Zero-Data-Retention-Vereinbarungen geeignet, abhängig von den dokumentierten Ausnahmen. Skills und Files sind laut ihren Dokumentationen nicht durch ZDR-Vereinbarungen abgedeckt. Eine lokal ausgeführte Portalaktion bedeutet deshalb keine lokale Modellinferenz. Browser-Datenfluss, Skills-Aufbewahrung und Files-Aufbewahrung.

Unsere Empfehlung für die Freigabe: Zeichne den tatsächlichen Weg eines Beispielauftrags auf. Markiere Portal, Browserumgebung, API, Dateiablage und Ergebnisempfänger. Prüfe für jeden Übergang, welche Inhalte notwendig sind. Beschränke Bildschirm- und Seiteninhalte auf den konkreten Auftrag; eine breite Administratoransicht ist für einen einfachen Statusabruf unnötig. Den betrieblichen Rahmen erläutert unser Datenschutz-Leitfaden.

Pilotbeispiel: Lieferantenunterlagen im Portal vorbereiten

Vorgeschlagener Pilot, kein Kundenbericht: Ein Handelsunternehmen erhält regelmäßig aktualisierte Produktdaten. Ein Mitarbeiter liest eine freigegebene Tabelle, vergleicht sie mit dem Lieferantenportal und erstellt anschließend eine Liste der nötigen Änderungen. Genau diesen begrenzten Ablauf würden wir zunächst mit einem Testkonto und Beispieldaten abbilden.

• Eingabe: Eine datierte Produktliste, eindeutige Artikelnummern und eine Vorlage für den Vergleich.
• Erlaubte Arbeit: Bestehende Portalwerte lesen, Abweichungen berechnen und Änderungen als Entwurf vorbereiten.
• Stopp: Fehlende Artikelnummer, widersprüchliche Einheit, unerwarteter Empfänger oder eine verbindliche Bestätigung.
• Ausgabe: Vergleich mit Quellen, offene Fragen und eine Liste der tatsächlich ausgeführten Schritte.

Erfolg bedeutet hier, dass ein Mitarbeiter jede vorgeschlagene Änderung nachvollziehen kann. Prüfe deshalb bewusst einen doppelten Artikel, eine leere Zelle und einen abgelaufenen Login. Setze außerdem ein Zeit- und Aufruflimit. Nach dessen Erreichen liefert der Agent einen Zwischenstand, anstatt unbemerkt weiterzuarbeiten.

Vergleiche vor einer Ausweitung Bearbeitungszeit, Nacharbeit und Anzahl unklarer Fälle mit dem bisherigen Verfahren. Gibt es eine stabile Fach-API für dasselbe Portal, prüfe sie als zusätzlichen Integrationsweg: Eindeutige Datenfelder können viele Oberflächenprobleme vermeiden. Browser Use ist besonders interessant, wenn relevante Arbeitsschritte nur über die Oberfläche erreichbar sind.

Einen Portalprozess für Claude prüfen lassen: Beschreibe die wiederkehrende Aufgabe, das Zielsystem und das gewünschte Ergebnis. Gemeinsam grenzen wir einen Pilot ein und prüfen, ob API-Integration, Browser Use oder eine Kombination den passenden Einstieg bietet.