Googles ARTEMIS: Automatisierung echter Android-Smartphones in natürlicher Sprache

Beim Aufstieg der KI-Agenten waren Smartphones bisher die Ausnahme. Auf dem Desktop oder im Browser klicken sich Agenten zunehmend durch Oberflächen, steuern Anwendungen, schreiben Code, lesen Dateien und folgen Anweisungen in Alltagssprache mit wenig Aufsicht. Auf dem Handy sah das deutlich weniger beeindruckend aus. Herkömmliche Test-Frameworks sind oft fragil, stützen sich stark auf feste Element-IDs und brechen, sobald sich ein Layout ändert. Schlimmer noch: Keines davon wurde für einen Agenten entworfen, dem man einfach ein Ziel nennt und der die Schritte selbst herausfindet.

Die Lücke fällt auf, weil die meisten Menschen den Großteil ihrer digitalen Zeit am Smartphone verbringen. Software, die Computer und Browser gut bedient, tut sich mit einem echten Telefon immer noch schwer.

ARTEMIS, ein Projekt, das Google gerade als Open Source veröffentlicht hat, geht das Problem anders an. Entwickler müssen nicht vorab jeden Bildschirm, jedes Widget und jede Interaktion beschreiben. Ein KI-Agent erhält eine Anweisung in natürlicher Sprache und führt sie auf einem echten Android-Gerät oder einem Emulator aus. Laut Projekt erledigt er mehr als 99 Prozent der Aufgaben eines anspruchsvollen mehrstufigen Benchmarks und lässt sich in Coding-Agenten einbinden, die Entwickler bereits nutzen, darunter Codex, Claude Code und Antigravity.

Noch spannender ist die Richtung auf der Roadmap: vollständig lokale Ausführung auf dem Gerät mit leichten Vision-Modellen, damit nicht jede Interaktion zu einem Cloud-Dienst reisen muss. Gelingt das, könnte sich mobile Automatisierung von einem fragilen Stapel Skripte hin zu agentenartigen Oberflächen bewegen, wie man sie von Desktops und Browsern kennt: etwas, das versteht, was zu tun ist, und das Gerät bedient, um es zu erledigen.

Skripte gegen einen Agenten, der hinsieht

Klassische mobile Automatisierung verlangt vom Testautor, jedes Element zu benennen, das ein Skript berührt, meist über eine in die App kompilierte ID, und vorab eine starre Abfolge von Aktionen festzulegen. Das funktioniert passabel auf einem stabilen Bildschirm in einer App, deren Innenleben der Autor sehen und kontrollieren kann. Es bricht zusammen, sobald sich etwas bewegt. Ein neu gestalteter Button, eine umbenannte ID oder eine ungewohnte, selbst gezeichnete Oberfläche aus einem modernen UI-Toolkit können ein Skript, das monatelang zuverlässig lief, still kaputtmachen, und um herauszufinden warum, muss meist ein Mensch den Fehler von Hand nachvollziehen.

Ein KI-gestützter Ansatz dreht dieses Modell um. Statt fest codierte, an IDs gebundene Schritte abzuspielen, sieht sich der Agent an, was der Bildschirm gerade zeigt, interpretiert die Anweisung und wählt die nächste Aktion spontan, ähnlich wie jemand, der zum ersten Mal eine unbekannte App öffnet. Ist ein Button verschoben, umbeschriftet oder komplett neu gestaltet, passt sich der Agent an das an, was er vor sich hat, statt an einem Verweis auf etwas zu scheitern, das nicht mehr existiert.

Ein Satz statt eines Skripts

Der Nutzen zeigt sich am deutlichsten, wenn eine einzige Anweisung ersetzt, was sonst ein langer, handgeschriebener Test wäre. Statt Taps, Swipes und Elementsuchen aufzuzählen, lässt sich eine Aufgabe so formulieren, wie man sie einer Kollegin erklären würde:

Open Settings, find Battery and tell me current level

Mit dieser Anfrage bewegt sich der Agent durch die Oberfläche des echten Telefons. Er findet den richtigen Bildschirm, indem er Wissen über den Aufbau der App mit einer visuellen Auswertung des Angezeigten kombiniert, liest den gewünschten Wert aus und meldet ihn zurück. Niemand hat eine Zeile klassischen Automatisierungscode geschrieben, der auf bestimmte Bildschirmelemente zielt.

Derselbe Ansatz skaliert auf komplexere Abläufe über mehrere Apps hinweg. Eine Anweisung kann eine Abfolge beschreiben, die zwischen voneinander unabhängigen Anwendungen springt, wofür ein herkömmliches Skript meist mehrere getrennte, sorgfältig abgestimmte Teile bräuchte. Gerade das Nachdenken über die Absicht statt des Abarbeitens eines festen Skripts macht diese App-übergreifende Flexibilität realistisch, ohne enormen Vorab-Engineering-Aufwand für jeden Ablauf.

Das Diagramm oben aus dem Repository des Projekts zeigt einen autonomen Testablauf, in dem Antigravity mit ARTEMIS zusammenarbeitet.

Ein überprüfbares Benchmark-Ergebnis

Kühne Automatisierungsversprechen gibt es überall, an einem anerkannten unabhängigen Maßstab gemessene sind viel seltener. ARTEMIS meldet mehr als 99 Prozent erledigte Aufgaben in einem Benchmark, der eigens dafür gebaut wurde, mobile Agenten über viele echte Anwendungen und mehrstufige Szenarien hinweg zu bewerten, nicht an einer kleinen handverlesenen Sammlung einfacher Beispiele.

Das Diagramm stammt von der Projektseite und zeigt die Erfolgsquote von über 99 Prozent bei AndroidWorld, einem Benchmark von Google Research mit mehr als 20 Apps und über 100 mehrstufigen Aufgaben.

Ein Benchmark mit so vielen Anwendungen und Aufgaben soll genau das belasten, womit fest codierte Automatisierung kämpft: unbekannte Layouts, Aufgaben, bei denen mehrere Aktionen korrekt verkettet werden müssen, und Oberflächen, die niemand mit Blick auf Automatisierung gebaut hat. Ihn mit mehr als 99 Prozent zu bestehen, ist eine andere Zuverlässigkeitsklasse als bei früheren KI-gestützten Werkzeugen, die bei offener, mehrstufiger Arbeit in echten, unveränderten Apps historisch ins Stolpern gerieten.

Anbindung über MCP

ARTEMIS ist kein eigenständiges Werkzeug mit isoliertem Workflow. Es dockt über das Model Context Protocol, kurz MCP, an die Coding-Agenten an, die täglich im Einsatz sind, darunter Codex, Claude Code und Antigravity. MCP ist ein offener Standard, mit dem ein KI-Agent externe Tools einheitlich finden und aufrufen kann, egal welches Tool oder Modell gerade steuert.

Da die Verbindung auf einem offenen Protokoll beruht statt auf einer einmaligen Anbindung an ein einzelnes Produkt, kann jeder Coding-Agent, der MCP spricht, ein echtes Telefon als weiteres Werkzeug in seinem Repertoire steuern, neben seinen Fähigkeiten, Code zu lesen, Befehle auszuführen oder im Web zu surfen. Die Einrichtung besteht in der Regel darin, den Automatisierungsserver in der Konfiguration des Coding-Agenten zu registrieren, ganz ähnlich wie bei jedem anderen externen Tool:

{
  "mcpServers": {
    "mobile-automation": {
      "command": "/path/to/tool/.venv/bin/python",
      "args": ["-m", "mcp_server"],
      "cwd": "/path/to/tool"
    }
  }
}

Danach kann ein Entwickler eine mobile Testaufgabe in Alltagssprache im Chat des Coding-Agenten beschreiben, so wie er eine Codeänderung beschreiben würde, und der Agent steuert das angeschlossene Gerät direkt. Ein Wechsel in eine separate Test-App ist nicht nötig.

Komplette Entwicklungsschleifen auf dem Gerät

Der Nutzen reicht weit über schnelle Einzelprüfungen wie das Auslesen einer Einstellung hinaus. Ein mit einem echten Gerät verbundener Coding-Agent kann deutlich größere Entwicklungsabläufe selbstständig ausführen:

• die neueste Version einer Anwendung bauen
• diesen frischen Build auf einem angeschlossenen physischen Gerät installieren
• eine bestimmte User Journey durchlaufen, etwa die Anmeldung mit einem Testkonto
• nach unerwartetem Verhalten suchen, zum Beispiel einem Popup, das nach dem Login nicht erscheinen sollte
• Screenshots als visuelle Belege dafür zurückgeben, was in jeder Phase passiert ist

Der Screenshot oben zeigt eine Live-Demo des Projekts: Autorouten in Google Maps planen und ihre Dauer zusammenrechnen, dann YouTube öffnen.

So ein durchgängiger Ablauf aus Bauen, Installieren, Navigieren und Prüfen entspricht dem, was ein QA-Engineer tut, wenn er eine Änderung vor dem Release prüft, nur folgt hier ein KI-Agent Anweisungen in natürlicher Sprache, statt dass ein Mensch auf ein physisches Gerät tippt. Teams, die ohnehin in weiten Teilen ihrer Entwicklung auf Agenten setzen, können diesen agentengesteuerten Ansatz nun auf echte Hardware ausweiten und damit einen der hartnäckigsten manuellen Schritte in einer ansonsten zunehmend automatisierten Pipeline beseitigen.

Wissen, warum ein Lauf fehlschlug

Ein Gerät zu steuern, ist nur die Hälfte eines nützlichen Testwerkzeugs. Wenn etwas kaputtgeht, ist das Warum genauso wichtig wie das Auslösen der Interaktion. Neben den Aktionen auf dem Bildschirm erfasst ARTEMIS während eines Ablaufs Diagnosedaten vom Gerät, darunter Systemlogs und Screenshots in aussagekräftigen Momenten.

Diese Aufzeichnungen zählen beim echten Debugging, nicht nur bei der Automatisierung des Happy Path. Ein Test, der mitten in einer langen Abfolge scheitert, ist viel nützlicher, wenn er einen Screenshot vom Moment des Fehlers plus die Systemlog-Ausgabe aus genau diesem Augenblick liefert, statt nur ein nacktes Bestanden oder Nicht bestanden. Ein fehlgeschlagener Lauf wird zum praktischen Ausgangspunkt für die Untersuchung, statt zur Sackgasse, die zwingt, das ganze Szenario manuell nachzustellen, nur um zu sehen, was passiert ist.

Die Roadmap: privat und lokal

Die aktuellen Fähigkeiten sind schon ein großer Schritt über klassische mobile Automatisierung hinaus, doch die veröffentlichte Roadmap weist auf etwas, das langfristig wohl noch größer ist: Ausführung auf dem Gerät selbst, angetrieben von leichten, lokal laufenden Vision-Language-Modellen, statt einer ständigen Verbindung zu einem Cloud-Modell für jede Aktion.

Diese Verschiebung bringt zwei praktische Vorteile. Der erste ist die Latenz. Wenn Schlussfolgern und Ausführung vollständig auf dem Telefon stattfinden, ohne Netzwerk-Roundtrip zu einem entfernten Modell bei jedem Schritt, kommen Antworten viel schneller, und das zählt bei Automatisierung, die mit einer interaktiven Echtzeitoberfläche Schritt halten muss, statt vor jeder Aktion zu pausieren.

Der zweite, wohl gewichtigere Vorteil ist der Datenschutz. Automatisierung, die nie einen Screenshot oder irgendeine andere Aufzeichnung des Bildschirminhalts vom Gerät schickt, eignet sich viel besser für sensibles Material, seien es personenbezogene Daten, vertrauliche Geschäftsinformationen oder alles andere, was eine Person oder Firma lieber auf eigener Hardware behält.

Vor dem Hintergrund des Trends, der auf Desktops und in Browsern längst läuft und oft Computer Use genannt wird, trägt die Roadmap diese Idee in die mobile Welt, mit bewusster Betonung auf Privatsphäre und lokaler Ausführung statt dauerhafter Abhängigkeit von der Cloud. Desktop-Pendants leiten das Bildschirmverständnis meist noch über ein gehostetes Modell, ein Plan rund um leichte Vision-Modelle auf dem Gerät deutet für Telefone also einen eigenständigeren Weg an.

Was sich für Mobile-Teams ändert

Zusammengenommen ergeben Steuerung eines Telefons in natürlicher Sprache, ein überprüfbares Benchmark-Ergebnis mit hoher Zuverlässigkeit, Integration in beliebte Coding-Agenten, eingebaute Diagnose und eine auf lokale Ausführung ausgerichtete Roadmap etwas Neues für alle, die mobile Apps bauen oder testen.

• Exploratives Testen, für das früher jemand auf der Suche nach Überraschungen in einer App herumstochern musste, lässt sich als eine Anweisung formulieren und automatisch ausführen.
• Regressionsprüfungen, die sorgfältig gepflegte, fragile, an Element-IDs gebundene Skripte erforderten, lassen sich in Alltagssprache schreiben, während sich der Agent an die sich entwickelnde Oberfläche anpasst.
• Entwicklungsabläufe, die früher mit einer Codeänderung endeten und die Prüfung auf dem Gerät einem Menschen überließen, können einen vollständig automatisierten Zyklus aus Bauen, Installieren und Prüfen durchlaufen, erledigt vom selben Agenten, der schon beim Rest der Arbeit hilft.

Nichts davon macht das Urteil erfahrener Tester überflüssig, besonders bei subtilen, subjektiven Qualitätsfragen jenseits dessen, ob eine Aktion technisch geklappt hat. Was sich ändert, ist, wohin die menschliche Aufmerksamkeit geht: viel weniger in die Pflege fragiler, fest codierter Skripte gegen eine ständig wechselnde Oberfläche und viel mehr in die Entscheidung, was getestet werden sollte, während ein Agent, der über Absichten nachdenkt, es ausführt.

Wo das die mobile Automatisierung lässt

Mobile Automatisierung hinkte jahrelang dem hinterher, was Agenten auf Desktops und in Browsern bereits schaffen. ARTEMIS verkleinert die Lücke, indem es KI-Agenten ein echtes Gerät per Anweisung in natürlicher Sprache steuern lässt. Die gemeldete Erfolgsquote von über 99 Prozent bei einem anspruchsvollen unabhängigen Benchmark ist bemerkenswert, ebenso die direkte Integration in die Coding-Agenten, die Entwickler ohnehin täglich nutzen.

Die interessantere Geschichte liegt vielleicht noch vor uns. Die Roadmap zielt auf vollständig lokale Ausführung auf dem Gerät mit leichten Vision-Modellen. Kommt das, wären mobile Agenten mehr als nur fähig. Sie wären privat und eigenständig und könnten arbeiten, ohne eine einzige Interaktion an einen entfernten Dienst zu schicken.

Die größere Bedeutung reicht über das Automatisieren von Taps, Swipes oder einzelnen Testfällen hinaus. Sie deutet auf eine Zukunft, in der ein echtes Smartphone eine weitere Umgebung ist, die ein Agent versteht und bedient, neben Terminal, Dateisystem, Browser und Codebasis. Für alle, die mobile Apps bauen, testen und pflegen, könnte das erheblich verändern, was ein KI-Coding-Agent leisten kann. Der Code liegt im öffentlichen ARTEMIS-Repository von Google auf GitHub.