Googles Gemini-2.5-Modell „Computer Use“ steuert Browser-Agenten über eine Screenshot-zu-Aktion-Schleife

Die Schleife: Screenshot rein, UI-Aktion raus

Das Modell wird über ein neues `computer_use`-Tool in der Gemini API bereitgestellt, und Google macht deutlich, dass es innerhalb einer Schleife laufen soll, nicht als einzelner Aufruf. Jede Runde erhält drei Dinge: die Nutzeranfrage, einen Screenshot der aktuellen Umgebung und einen Verlauf der letzten Aktionen.

Das Modell antwortet mit einem Funktionsaufruf, der eine einzelne UI-Aktion repräsentiert — Klicken, Tippen, Scrollen. Client-seitiger Code führt diese Aktion aus, erfasst dann einen neuen Screenshot samt aktueller URL und sendet beides als Funktionsantwort zurück, wodurch die Schleife erneut startet. Das läuft weiter, bis die Aufgabe abgeschlossen ist, ein Fehler auftritt oder eine Sicherheitsantwort bzw. der Nutzer den Vorgang stoppt.

Dieses Design ist für Frontend-Teams bemerkenswert: Das Modell liest nicht das DOM aus und greift nicht auf die internen Strukturen einer App zu. Es arbeitet mit Pixeln und einer URL — derselben Oberfläche, die auch ein Mensch sieht. Die Referenzimplementierungen spiegeln das wider — Google empfiehlt Entwicklern, die Agenten-Schleife lokal mit Playwright oder in einer Cloud-VM über Browserbase aufzubauen.

Begrenzt auf den Browser, nicht auf den Desktop

Google ist präzise darin, wo das Modell funktioniert. Es ist primär für Web-Browser optimiert und zeigt vielversprechende Ansätze bei der Steuerung mobiler UIs, ist aber ausdrücklich noch nicht für die Steuerung auf Desktop-Betriebssystemebene optimiert.

Die Demos bleiben innerhalb dieser Grenze: Haustierdaten werden aus einem Webformular extrahiert und in ein CRM eingetragen, um einen Termin zu vereinbaren, sowie Haftnotizen werden in einer Web-App per Drag-and-Drop in Kategorien sortiert. Beides sind gewöhnliche Browser-Aufgaben — Formulare ausfüllen, Dropdowns und Filter bedienen, hinter Logins agieren — die Google als genau die Fähigkeit einordnet, die bislang fehlte, wenn Agenten nur mit strukturierten APIs sprechen konnten.

Sicherheitsprüfung pro Schritt läuft außerhalb des Modells

Google benennt drei Risiken, die speziell für Agenten gelten, die Computer steuern: absichtlicher Missbrauch durch Nutzer, unerwartetes Modellverhalten sowie Prompt-Injections und Betrugsversuche in der Web-Umgebung. Sicherheitsfunktionen sind ins Modell eintrainiert, doch der interessantere Baustein für Entwickler ist die modellexterne Prüfung.

Sicherheitsdienst pro Schritt: Ein modellexterner Sicherheitsdienst zur Inferenzzeit, der jede vom Modell vorgeschlagene Aktion bewertet, bevor sie ausgeführt wird.Montana Labs

Darüber hinaus können Entwickler über Systemanweisungen festlegen, dass der Agent riskante Aktionen ablehnt oder vor deren Ausführung eine Bestätigung des Nutzers einholt. Das Modell selbst kann außerdem signalisieren, dass eine Bestätigung durch den Endnutzer erforderlich ist — etwa vor einem Kauf. Google nennt konkrete Aktionen, die es als hochriskant einstuft: die Systemintegrität zu beschädigen, die Sicherheit zu gefährden, CAPTCHAs zu umgehen und medizinische Geräte zu steuern.

UI-Testing ist der Anwendungsfall, den Google zuerst ausgeliefert hat

Bei den frühen Einsätzen hebt Google UI-Testing in den eigenen Produktivteams hervor und sagt, dass dies die Softwareentwicklung deutlich beschleunigen kann. Versionen des Modells treiben bereits Project Mariner, den Firebase Testing Agent und einige agentische Funktionen im KI-Modus der Suche an.

Diese Einordnung ist wichtig. Ein Agent, der einen echten Browser anhand von Screenshots steuert, passt natürlich zu End-to-End-Frontend-Tests — durch Abläufe klicken, Formulare absenden, prüfen, ob interaktive Elemente sich richtig verhalten — ohne handgeschriebene Selektoren, die bei UI-Änderungen brechen. Der Referenzweg mit Playwright deckt sich direkt damit, wie viele Teams bereits Browser-Tests schreiben.

Was ein pixelgesteuerter Agent für die Frontend-Arbeit verändert

Da das Modell mit Screenshots und URLs arbeitet statt mit App-internen Strukturen, behandelt es jedes Web-Frontend so, wie es ist, als testbare, automatisierbare Oberfläche. Es gibt keine Integrationsschicht, die man gegen die eigenen Komponenten bauen müsste — der Agent nutzt die Oberfläche, die auch ein Nutzer sehen würde.

Die praktische Konsequenz ist, dass dieselbe gerenderte UI jetzt zwei Zielgruppen bedient — menschliche Nutzer und einen Agenten, der sie visuell navigiert. Googles eigener Vorbehalt gilt weiterhin: Die Schutzmaßnahmen verringern das Risiko, beseitigen es aber nicht, und das Unternehmen rät Entwicklern, ihre Systeme vor dem Launch gründlich zu testen. Für Teams, die dies bewerten, liegt der kurzfristige Nutzen weniger in autonomen Endnutzer-Agenten als vielmehr darin, bestehende Web-Abläufe in schnelle, selbstlaufende Testdurchläufe gegen die echte Oberfläche zu verwandeln.