Computer Use, Browser Use oder Playwright im UI-Test

Auf wie vielen Wegen kann ein Agent eine Oberfläche sehen?

Wenn ein Coding-Agent eine Oberfläche ändert, ist die Arbeit noch nicht fertig: Er muss sehen, dass die Änderung wirklich funktioniert. Diese Schleife, in der der Agent seine eigene Arbeit prüft, haben wir im Beitrag über Harness Engineering beschrieben. Bei einer Oberfläche gibt es für diese Prüfung drei Wege, und alle drei bringen Coding-Tools heute schon mit:

Bei Computer Use sieht der Agent den Bildschirm als Bild und arbeitet mit Maus und Tastatur. Das Tool von Anthropic liefert Screenshots sowie Maus- und Tastatursteuerung. Auch die Dokumentation von Google schreibt, dass das Modell den Bildschirm über Bilder „sieht“ und Aktionen wie Klicks und Tastenanschläge erzeugt. Dieser Weg erreicht alles, was auf dem Bildschirm ist: Das Tool von Google arbeitet im Browser, auf Mobilgeräten und auf dem Desktop.

Bei Browser Use schaut der Agent nicht auf das Bild der Seite, sondern auf ihre Struktur. Das Browser-Use-Tool von Anthropic liest die Seite aus dem Accessibility Tree: Jedes Element kommt mit Rolle und Namen und einer Referenz wie [ref_2], und beim Klicken gibt der Agent diese Referenz statt Koordinaten an. Wo der Baum nichts sieht, etwa in einem Canvas, greift es wieder auf Screenshots und Koordinaten zurück. Auch Playwright MCP liest die Seite aus diesem Baum statt aus Screenshots. Die Open-Source-Bibliothek Browser Use, die in Suchergebnissen auftaucht, ist ein eigenes Projekt; mit „Browser Use“ meinen wir in diesem Beitrag die Methode.

Auf dem Weg über Code und Tests steuert der Agent den Browser über eine Bibliothek: Er schreibt einen Playwright-Test oder ruft die CLI von Playwright auf. Playwright CLI lädt die Daten der Seite nicht ins Modell; der Agent liest nur die Ausgabe des Befehls. Auch der Computer-Use-Leitfaden von OpenAI empfiehlt für GPT-6 Astra den Weg über Code: Das Modell schreibt Playwright- oder PyAutoGUI-Code, der die Oberfläche steuert, und das strukturierte computer-Tool bleibt eine Alternative. Der eigentliche Unterschied von Code: Einmal geschrieben, kann er ohne Modell erneut laufen.

Was kostet welcher Weg, und wie zuverlässig ist er?

Wir haben die drei Wege anhand von drei Fragen verglichen: Wie viele Token kostet ein Schritt, wie lange dauert eine Aufgabe, und wie oft wird sie vollständig erledigt? Die meisten Zahlen stammen aus der Dokumentation der Anbieter; bei Benchmark-Ergebnissen sagen wir dazu, wer sie gemeldet hat.

Ein Agent, der vom Bildschirm aus arbeitet, liest bei jedem Schritt einen Screenshot, und Bilder werden als Token abgerechnet. Die drei Anbieter rechnen das unterschiedlich: Anthropic teilt das Bild in Quadrate von 28 Pixeln, OpenAI in Quadrate von 32 Pixeln, und Google nimmt bei Gemini 4 und 3 eine feste Zahl, unabhängig von der Größe. Bei der Auflösung 1280×800, die Anthropic für Web-Apps empfiehlt, kostet ein einzelner Screenshot so viel:

Was das Diagramm nicht zeigt, ist, wie sich das summiert. Der Agent macht bei jedem Schritt einen neuen Screenshot, und die alten bleiben im Kontext. Laut Anthropic ist ein Kontextfenster von 200K Token lange vor 100 Screenshots voll. Enthält eine Anfrage mehr als 20 Bilder, gilt für jedes Bild eine strengere Größengrenze. Deshalb empfiehlt Anthropic für seine neueren Modelle, Screenshots auf höchstens 2000 Pixel pro Seite zu verkleinern und alte Screenshots serverseitig zu entfernen. Was der Agent vergisst, wenn der Kontext voll ist, steht im Beitrag über Auto-Compact.

Auch das Toolset selbst kostet etwas. Bei Anthropic fügt das Computer-Use-Toolset jeder Anfrage etwa 4.500 Eingabe-Token hinzu, das Browser-Use-Toolset etwa 6.600. Weil dieser Aufschlag bei jeder Anfrage gleich ist, lohnt sich hier Prompt Caching. Für den Accessibility Tree gibt es keine einzelne Zahl, sie hängt von der Seite ab; laut der Dokumentation von Anthropic kostet das Lesen des Baums auf einer gewöhnlichen Seite meist weniger Eingabe-Token als ein Screenshot. Auch der Baum kann groß werden: Das Playwright-Team empfiehlt Coding-Agenten die CLI statt MCP, weil die CLI keine großen Tool-Schemas und keine langen Accessibility Trees in den Kontext des Modells lädt.

Für die Zeit nennen die Anbieter keine Zahl pro Schritt; in keiner der Dokumentationen, die wir gelesen haben, steht eine Sekundenzahl pro Aktion. Anthropic schreibt, dass Computer Use im Vergleich zu einem Menschen, der dieselben Schritte von Hand macht, langsam sein kann, und empfiehlt es für Aufgaben, bei denen Tempo keine Rolle spielt, etwa automatisierte Softwaretests. Die Zeit pro Aufgabe meldet OpenAI: Nach eigener Messung erledigte GPT-6 Astra eine Aufgabe aus OSWorld 2.0 in etwa 40 Minuten, GPT-5.6 Sol in etwa 75 Minuten. Diese Aufgaben sind lang: Laut der Seite von OSWorld 2.0 braucht ein Mensch für eine Aufgabe etwa 1,6 Stunden (Median), und Claude Opus 4.7 macht pro Aufgabe im Schnitt 318 Tool-Aufrufe; im alten OSWorld waren es etwa 30.

Für die Zuverlässigkeit ist OSWorld der meistbeachtete Maßstab. Alle drei Anbieter haben ihre neuen Modelle mit einer neueren Version von OSWorld gemessen und die Ergebnisse veröffentlicht, aber jeder auf einer anderen Version oder Teilmenge, und alle geben Teilpunktzahlen an:

Quelle: die eigenen Ankündigungen und Model Cards der Anbieter, 20. Oktober 2026; alle Ergebnisse sind vom Anbieter gemeldet. Weil Version und Teilmenge verschieden sind, lassen sich die Zeilen nicht miteinander vergleichen. Die Model Cards von Google nennen einen Monat, keinen Tag.

Die Teilpunktzahl misst, wie viele der Prüfpunkte einer Aufgabe erfüllt sind; OSWorld 2.0 bewertet eine Aufgabe im Schnitt mit 27,25 Prüfpunkten. Das eigentliche Hauptmaß des Benchmarks ist aber, ob die Aufgabe vollständig erledigt wird. Der Abstand zwischen beiden ist groß. In der Tabelle von OSWorld 2.0 (Aktualisierung vom 15. Oktober, Version v2.1) ist das beste Ergebnis unter den Läufen, in denen das Modell allein arbeitet, der Lauf von Claude Opus 5 mit dem höchsten Effort: Teilpunktzahl 77,67 %, vollständig erledigte Aufgaben 44,33 %. Mit dem niedrigsten Effort erledigt dasselbe Modell 18,81 %.

In der aktuellen Version enthält die Tabelle kein Modell von OpenAI; in der Offline-Teilmenge der vorigen Version erreichte GPT-5.6 Sol mit dem höchsten Effort eine Teilpunktzahl von 64,13 % und erledigte 28,1 % vollständig. Gemini-Modelle fehlen in der Tabelle ganz. Die Zahlen, die die Anbieter veröffentlichen, sagen also, dass der Agent den größten Teil der Arbeit macht, aber nicht, dass er sie zu Ende bringt. Wie man einen Score liest, steht im Beitrag über SWE-bench.

Warum die Arbeit am Bildschirm nicht jedes Mal dasselbe Ergebnis bringt, schreiben die Anbieter selbst. Laut GitHub kann eine Änderung im Timing oder im Zustand eines Fensters zu einem anderen Ergebnis führen und dazu, dass der Agent eine Aktion wiederholt oder hängen bleibt. Anthropic schreibt, dass das Modell beim Erzeugen von Koordinaten Fehler machen kann, Google, dass unerwartete Pop-ups und Layoutänderungen das Modell verwirren können. Der Accessibility Tree löst einen Teil dieses Problems: Laut Anthropic ist eine Elementreferenz von Layoutverschiebungen, die Pixelkoordinaten unbrauchbar machen, nicht betroffen. Im Playwright-Test wird ein Element über Rolle und Namen gefunden, Playwright wartet, bis der erwartete Zustand eintritt, und der Test macht bei jedem Lauf dieselben Schritte in derselben Reihenfolge.

Quelle: die in diesem Abschnitt verlinkte Dokumentation, 20. Oktober 2026.

Was bieten die drei Anbieter für Computer Use und Browser Use?

Wenn Sie Ihren eigenen Agenten über die API bauen, hat jeder der drei Anbieter ein fertiges Tool. Die Schleife ist überall gleich: Das Modell verlangt eine Aktion, Ihr Code führt sie in Ihrem eigenen Browser oder Ihrer virtuellen Maschine aus und gibt das Ergebnis zurück. Stand 20. Oktober 2026:

Quelle: die Dokumentation der drei Anbieter zu Computer Use, Browser Use und Preisen, 20. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu.

Bei Anthropic gab es vor Kurzem einen Wechsel. Laut den Release Notes hat Computer Use die Beta am 19. August verlassen, und das Browser-Use-Tool kam am selben Tag. Bei Opus 5.5, erschienen am 22. September, gibt das alte Tool computer_20251124 in der Claude API und in Google Cloud den Fehler 400 zurück; auch Sonnet 5.5 und Haiku 5.5 akzeptieren die alten Tools nicht. Das neue Toolset kann in einem Zug mehrere Aktionen zusammen zurückgeben; Ihr Code sollte sie der Reihe nach ausführen und beim ersten Fehler anhalten.

Bei OpenAI gibt es zwei Wege. Der Leitfaden beschreibt sowohl das computer-Tool, bei dem das Modell Aktionen wie Klicken und Tippen zurückgibt, als auch den Weg, auf dem das Modell Playwright- oder PyAutoGUI-Code schreibt. Auf dem Code-Weg kann das Modell mehrere Aktionen, eine Schleife oder eine Bedingung in einem einzigen Aufruf zusammenfassen. Der Leitfaden verlangt außerdem, am Ende das tatsächliche Ergebnis zu prüfen, statt der Antwort des Modells zu vertrauen. Seit dem 29. September bietet auch die Agents API Computer Use in einem von OpenAI gehosteten Browser an.

Das Tool von Google ist in der Vorschau, und Google empfiehlt bei wichtigen Aufgaben eine enge Beaufsichtigung. Das Modell gibt Koordinaten in einem Raster von 1000×1000 an; Ihr Code rechnet sie auf die Größe des Bildschirms um. Ist eine Aktion riskant, enthält die Antwort require_confirmation, und Sie müssen den Nutzer fragen. Die Prüfung von Screenshots auf Prompt Injection ist optional und standardmäßig aus.

Bei der Modellwahl empfehlen die drei Anbieter Unterschiedliches. Google empfiehlt für Computer Use Gemini 3.8 Flash. Anthropic hält Haiku 5.5 für Browser-Use-Aufgaben geeignet, bei denen Tempo zählt. Die Dokumentation von Codex empfiehlt GPT-6 Astra für schwierige Aufgaben, die von Screenshots oder visuellem Urteil abhängen. Die allgemeinen Unterschiede zwischen den Modellen stehen im Beitrag über die Modellwahl.

Wie testen Coding-Agenten eine Oberfläche?

In allen fünf Coding-Tools kann der Agent den Browser oder den Bildschirm nutzen, aber wo das läuft und was standardmäßig gilt, ist verschieden. Die Tabelle haben wir am 20. Oktober 2026 aus der Dokumentation des jeweiligen Tools gelesen:

Quelle: Dokumentation und Release Notes des jeweiligen Tools, 20. Oktober 2026. „Steht nicht in der Dokumentation“ heißt: Auf den Seiten, die wir an diesem Tag gelesen haben, fanden wir keinen Satz dazu. In Copilot ging Computer Use am 1. Oktober in die Vorschau und ist standardmäßig aus.

Wenn Sie noch Gemini CLI nutzen: Der Browser-Agent ist standardmäßig aus; eingeschaltet arbeitet er mit der Seite über den Accessibility Tree. Für Nutzer des kostenlosen Kontingents und von Google One hat Google Gemini CLI am 18. Juni 2026 durch Antigravity CLI ersetzt; mit kostenpflichtigen API-Schlüsseln lässt sich Gemini CLI weiter nutzen.

Die Dokumentation von drei dieser Tools empfiehlt dieselbe Reihenfolge. Claude Code sieht die Bildschirmsteuerung als breitesten und langsamsten Weg: Es probiert zuerst einen MCP-Server, dann Bash, dann Claude in Chrome und nutzt den Bildschirm nur, wenn nichts davon reicht. Laut GitHub liefern eine API, ein MCP-Server, ein Terminalbefehl oder ein Browser-Tool, wenn sie die Aufgabe erledigen können, strukturiertere Informationen und besser vorhersehbare Ergebnisse. Auch die Dokumentation von Codex empfiehlt für eine lokale Web-App zuerst den eingebauten Browser und für wiederkehrende Aufgaben einen MCP-Server.

Ein Unterschied liegt auch in der Sitzung. Claude in Chrome teilt den Anmeldestatus Ihres Browsers und kommt auf jede Seite, bei der Sie angemeldet sind; an einer Anmeldeseite oder einem CAPTCHA hält es an und fragt Sie. In VS Code laufen die Seiten, die der Agent öffnet, in einer eigenen, temporären Sitzung. Der eingebaute Browser von Codex und die Antigravity IDE nutzen ein Profil, das von Ihrem getrennt ist.

Warum ist es meist besser, den Agenten einen Playwright-Test schreiben zu lassen?

Die Prüfung, die der Agent im Browser macht, ist weg, sobald die Sitzung endet. Machen Sie aus derselben Prüfung einen Playwright-Test, bleibt sie im Repository und läuft bei jedem Pull Request ohne Modell erneut: Sie kostet keine Token, sammelt keine Screenshots an und macht jedes Mal dieselben Schritte. Die Dokumentation von VS Code empfiehlt dasselbe: Browser-Tools sind für die Prüfung innerhalb einer Sitzung da; Prüfungen, die in der CI jedes Mal laufen oder die Rückkehr eines alten Fehlers erkennen sollen, gehören als Playwright- oder andere automatisierte Tests ins Repository.

In der Praxis bewährt sich ein Ablauf in zwei Schritten. Zuerst erkundet der Agent die Seite mit einem Browser-Tool oder mit Playwright MCP und sieht, wie Selektoren und Texte tatsächlich lauten. Dann schreibt er diesen Ablauf in einen Test, führt ihn aus und zeigt, dass er besteht. Playwright liefert dafür auch fertige Agenten: Playwright Test Agents bestehen aus dem Planner, der die App erkundet und einen Testplan erstellt, dem Generator, der aus dem Plan Tests schreibt, und dem Healer, der kaputte Tests repariert. npx playwright init-agents --loop=claude fügt diese Definitionen für Claude Code hinzu; es gibt auch die Optionen codex und vscode. Der Generator prüft Selektoren und Assertions live, während er das Szenario ausführt. So könnte ein Test aussehen, den ein Agent für ein Registrierungsformular schreibt:

// Beispiel: vom Agenten geschriebener Test, läuft bei jedem Pull Request in der CI.
import { test, expect } from '@playwright/test';

test('Registrierungsformular lehnt ungültige E-Mail ab', async ({ page }) => {
  await page.goto('/signup');
  await page.getByLabel('E-Mail').fill('keine-adresse');
  await page.getByRole('button', { name: 'Registrieren' }).click();
  await expect(page.getByText('Geben Sie eine gültige E-Mail-Adresse ein')).toBeVisible();
  await expect(page).toHaveScreenshot('signup-fehler.png');
});

Der Test enthält zwei Arten von Prüfung. toBeVisible prüft das Verhalten: Erscheint die Fehlermeldung? toHaveScreenshot prüft das Aussehen: Die Seite wird Pixel für Pixel mit dem Referenzbild im Repository verglichen. Laut Playwright können Betriebssystem, Browserversion und sogar die Hardware das Bild verändern; erzeugen Sie das Referenzbild deshalb in der Umgebung, in der der Test laufen wird. Wenn Sie die Struktur der Seite statt über ein Bild über den Accessibility Tree vergleichen möchten, gibt es toMatchAriaSnapshot.

Damit der Agent sieht, warum ein Test fehlschlägt, hinterlassen Sie ihm Belege. Die Konfiguration unten speichert bei jedem fehlgeschlagenen Test einen Screenshot und beim ersten Wiederholungsversuch in der CI einen Trace; im Trace können Sie vor- und zurückgehen und sehen, was bei jedem Schritt des Tests passiert ist. Die Dateien landen im Ausgabeordner der Tests, meist test-results; sagen Sie dem Agenten, dass er beim Beheben des Fehlers zuerst dort nachsehen soll.

// Beispiel: eine Konfiguration, die Belege von fehlgeschlagenen Tests aufhebt.
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: 'http://localhost:3000',
    screenshot: 'only-on-failure',
    trace: 'on-first-retry',
  },
});

Prüfungen auf Basis von Screenshots braucht man für diese Aufgaben weiterhin: Layoutverschiebungen, Fehler bei Farbe oder Ausrichtung, ein Diagramm oder eine Karte, die in einen Canvas gezeichnet wird. Auch die Dokumentation von Anthropic zählt Canvas, eingebettete Videos und Remote-Desktop-Oberflächen zu den Stellen, die der Baum nicht sieht. Um einen solchen Fehler zu finden, reicht es, wenn der Agent einmal auf einen Screenshot schaut; damit er nicht wiederkommt, lassen Sie einen Test mit toHaveScreenshot schreiben.

Welcher Weg passt zu welcher Aufgabe?

Alle Belege führen zur selben Reihenfolge: Was sich mit Code erledigen lässt, mit Code; liegt die Seite im Browser, über den Baum; gibt es keinen anderen Zugang, über den Bildschirm. Für häufige Aufgaben:

Die Gründe für die Karten stehen oben. Ein Test, um eine Web-Oberfläche zu prüfen, weil der Test in der CI ohne Modell und jedes Mal mit denselben Schritten läuft. Ein Browser-Tool für eine einmalige Prüfung, weil das Lesen des Baums meist günstiger ist als ein Screenshot und eine Referenz von Layoutverschiebungen nicht betroffen ist. Heben Sie sich Computer Use für Apps ohne API, CLI oder MCP-Server auf; auch GitHub stellt es für solche Apps vor.

Bei Aufgaben wie Zahlungen, Passwörtern und Kontoänderungen sagen alle drei Anbieter dasselbe: Den letzten Schritt soll ein Mensch freigeben. Anthropic empfiehlt eine menschliche Freigabe bei Entscheidungen wie dem Akzeptieren von Cookies, Finanztransaktionen oder der Zustimmung zu Nutzungsbedingungen. OpenAI wertet schon das Eintippen sensibler Daten in ein Formular als Datenübermittlung. Die Beispielanweisung von Google verlangt vom Modell, niemals zu versuchen, ein CAPTCHA zu lösen. Lassen Sie den Agenten in einer eigenen virtuellen Maschine oder mit einem eigenen Browserprofil laufen, und beschränken Sie die Seiten, die er aufrufen darf, mit einer Allowlist. Wie ein Text auf einer Seite den Agenten steuern kann, steht im Beitrag über MCP-Sicherheit.

diffox liest als Tool für KI-Code-Review den Pull Request mit git; es öffnet keine Oberfläche und macht keine Screenshots. Deshalb erfüllt ein Test, den der Agent für die Oberfläche schreibt, im Pull Request zwei Aufgaben: Die CI zeigt, dass die Oberfläche funktioniert, und im Review lässt sich im diff lesen, was der Test prüft. Warum ein bestandener Test nicht immer etwas prüft, steht im Beitrag über das Review von KI-generiertem Code.