OpenMobile-2 verbindet simulierte Smartphone-Apps mit nativen Werkzeugaufrufen

Trainingsdaten mit automatischer Erfolgskontrolle

Auf der Umgebung bauen zwei Arten von Trainingsmaterial auf. Das Team kuratiert knapp 12.000 mobile Interaktionsverläufe für Supervised Fine-Tuning, also überwachte Feinabstimmung. Zusätzlich nennt das Paper mehr als 2.000 ausführbare Aufgaben für Reinforcement Learning. Für diese Aufgaben sollen automatische Prüfer bewerten, ob das angestrebte Ergebnis erreicht wurde. [1][2]

Der Unterschied ist für das Training zentral: Ein aufgezeichneter Verlauf zeigt, welche Aktionen in einer Situation ausgeführt wurden; eine ausführbare Aufgabe mit Prüfer kann darüber hinaus wiederholt bearbeitet und anhand ihres Endzustands bewertet werden. Die Autoren stellen die kontrollierbaren Apps als Grundlage dar, um beides in größerem Umfang zu erzeugen. Im Abstract bezeichnen sie die Sammlung der verifizierbaren Reinforcement-Learning-Daten als die größte offene ihrer Art für mobile Agenten. Diese Einordnung ist eine Aussage des Forschungsteams und wird in den vorliegenden Quellen nicht unabhängig verglichen. [1][2]

Für die betriebliche Bewertung solcher Systeme könnte ein programmatischer Prüfer aussagekräftiger sein als eine reine Einschätzung, ob eine Aktion auf dem Bildschirm plausibel wirkt: Er kann feststellen, ob beispielsweise ein Auftrag oder ein anderer modellierter Geschäftszustand tatsächlich wie gefordert geändert wurde. Das ist eine methodische Stärke der beschriebenen Umgebung. Ihre Aussagekraft bleibt aber an die Genauigkeit der jeweiligen App-Replikate und der formulierten Erfolgsbedingungen gebunden. [2]

GUI und app-native Werkzeuge in einer Aufgabe

OpenMobile-2 untersucht außerdem einen experimentellen Interaktionsmodus, in dem mobile Apps neben ihrer grafischen Oberfläche ausgewählte app-native Werkzeuge bereitstellen. Ein Agent kann dadurch innerhalb derselben Aufgabe Bildschirmaktionen mit strukturierten Aufrufen kombinieren. Laut Paper greifen beide Kanäle auf denselben persistenten App-Zustand zu und sollen semantisch vergleichbare Änderungen bewirken. Die Autoren nennen mehr als 300 Werkzeuge in über 50 Apps. [1][2]

Der Ansatz verbindet zwei unterschiedliche Eigenschaften. Über eine GUI kann ein Agent grundsätzlich sichtbare Bedienelemente nutzen, doch der Weg kann langsam und anfällig für Änderungen an Oberfläche oder Ablauf sein. Strukturierte Aufrufe können bestimmte Funktionen direkter zugänglich machen, sind aber auf die bereitgestellten Operationen beschränkt. MobileGym++ soll einen kontrollierten Vergleich ermöglichen, indem Aufgaben, Ausgangszustände und Erfolgskriterien gleich bleiben, während sich der verfügbare Interaktionskanal unterscheidet. [2]

Die Werkzeuge sind nach Angaben der Autoren auf ausgewählte Lese- oder Schreiboperationen über app-eigene Geschäftsdaten begrenzt. Das Paper nennt etwa eine Suchfunktion in einer Fitness-App als Beispiel und beschreibt eine Spannweite von wenigen Such- und Abfragefunktionen bis zu mehr als zehn Lese- und Schreiboperationen je App. Alle Benchmark-Aufgaben sollen weiterhin ausschließlich über die GUI lösbar sein. Die Werkzeugnutzung ist somit als zusätzliche Möglichkeit angelegt, nicht als Voraussetzung für die Aufgabenlösung. [2]

Für Unternehmen ist die Trennung von Oberfläche und strukturiertem Zugriff als Analyse besonders relevant, wenn mobile Automatisierung bewertet werden soll. Ein gemischter Test kann sichtbar machen, ob ein Agent Funktionen zuverlässig über die sichtbare Oberfläche ausführt oder für ausgewählte Operationen besser einen strukturierten Zugang nutzt. Daraus folgt aber nicht, dass reale Apps dieselben Werkzeuge anbieten oder dass ein solcher Zugriff ohne zusätzliche Berechtigungs- und Sicherheitsprüfung produktiv eingesetzt werden kann. [2]

Benchmark für längerfristige mobile Abläufe

Mit MobileGym++ Bench führen die Autoren einen Benchmark mit 215 längerfristigen Aufgaben über mehrere Apps ein. Die Aufgaben arbeiten mit persistenten Nutzerzuständen und werden anhand programmatischer Prüfungen bewertet. Jede Aufgabe soll sowohl GUI-only als auch im hybriden Modus mit App-Werkzeugen lösbar sein. Dadurch kann das Team beide Interaktionsweisen auf derselben Aufgabensammlung vergleichen, statt aus unterschiedlichen Benchmarks Rückschlüsse zu ziehen. [2]

Der Benchmark soll kommerzielle mobile Szenarien abbilden und unterscheidet sich damit von Tests, die nur eine kurze Interaktion oder ein einzelnes App-Fenster prüfen. Für die Evaluierung zählt nicht allein, ob der Agent eine plausible Aktion ausgeführt hat, sondern ob der beabsichtigte Zustand der Anwendungsdaten erreicht wurde. Das kann besonders bei mehrstufigen Aufgaben helfen, Fehler zu lokalisieren: Ein fehlgeschlagener Endzustand lässt sich auf eine konkrete Aufgabenfolge und deren Übergänge zurückführen. [2]

Gleichzeitig bleibt es ein Benchmark in einer kontrollierten Simulationsumgebung. Die beschriebenen Aufgaben und Zustandsprüfungen bieten daher eine reproduzierbare Vergleichsbasis, aber keinen umfassenden Nachweis für Leistung in allen echten Apps, mit variierenden Konten, Netzbedingungen oder betrieblichen Richtlinien. Diese Abgrenzung folgt aus dem beschriebenen Versuchsaufbau und sollte bei der Interpretation der Resultate berücksichtigt werden. [2]

Berichtete Ergebnisse und Grenzen der Aussagekraft

Die Autoren berichten für OpenMobile-2 Scores von 79,9 auf AndroidWorld und 50,4 auf MobileWorld. Für den Realgeräte-Benchmark SPA-Bench nennen sie einen Anstieg von 31,9 auf 59,6 und beschreiben die Verbesserung als nahezu eine Verdopplung. Der Papertext ordnet das Ergebnis als Transfer auf reale mobile Nutzung ein und erklärt, das Modell übertreffe starke Open-Source-Baselines. [1][2]

Die Werte sind Ergebnisse aus der Arbeit selbst und keine unabhängige Bestätigung. Die vorliegenden Textauszüge legen zudem nicht für alle Kennzahlen im Detail offen, welche Auswertungsbedingungen, Modellvarianten oder Vergleichssettings hinter den Zahlen stehen. Deshalb sollten die Scores nicht ohne Weiteres als allgemeine Erfolgswahrscheinlichkeit oder als direkte Prognose für den Betrieb in einer konkreten Unternehmens-App gelesen werden. Die Quellen stützen die berichteten Benchmarkresultate, nicht eine darüber hinausgehende Produktionsreife. [1][2]

Für Entscheider ist insbesondere der SPA-Bench-Wert ein Hinweis, dass die Autoren nicht ausschließlich auf simulierte Aufgaben zielen. Er ersetzt aber keine eigene Prüfung auf den Geräten, Apps und Berechtigungsmodellen, die ein Unternehmen tatsächlich einsetzen will. Die Forschungsergebnisse liefern vielmehr einen möglichen Ausgangspunkt für kontrollierte Tests: zunächst Aufgaben und Erfolgskriterien definieren, dann GUI-only- und hybride Verfahren unter gleichen Bedingungen vergleichen. Diese Einordnung ist eine Analyse der im Paper beschriebenen Benchmarks und keine Aussage über eine bereits erfolgte Unternehmensbereitstellung. [2]

Bedeutung für die Entwicklung mobiler Automatisierung

Die Arbeit verschiebt den Schwerpunkt von einzelnen Agentenaktionen auf die Infrastruktur, die solche Systeme trainierbar und vergleichbar machen soll. Dazu gehören eine breitere App-Auswahl, reproduzierbare Zustände, ausführbare Aufgaben mit Prüfern und ein gemeinsamer Benchmark für grafische und strukturierte Interaktion. Für Entwicklungsteams kann eine solche Infrastruktur helfen, Fehler nicht nur anhand einzelner Bildschirmaktionen, sondern anhand des erreichten Anwendungszustands zu messen. [1][2]

Der Ansatz legt auch eine konkrete Evaluierungsfrage nahe: Welche Schritte einer mobilen Aufgabe sollten über die GUI erfolgen, und wo ist ein begrenzter strukturierter Zugriff vertretbar? Die Paperumgebung kann diese Frage für die von ihr modellierten Funktionen vergleichbar machen. In realen Unternehmensumgebungen kommen jedoch weitere Kriterien hinzu, etwa tatsächliche App-Kompatibilität und die Kontrolle darüber, welche Änderungen ein Agent auslösen darf. Die vorliegenden Quellen liefern keine Ergebnisse zu solchen betrieblichen Rahmenbedingungen. [2]

OpenMobile-2 ist damit vor allem als Forschungs- und Evaluierungsbeitrag einzuordnen. Das Team veröffentlicht nach eigener Darstellung Umgebungen, Trainingsdaten und Rezepte; die Paper-Seite verweist auf weitere Projektressourcen. Wie weit einzelne Bestandteile in der Praxis unmittelbar wiederverwendbar sind, muss anhand der jeweiligen Artefakte und ihrer Dokumentation geprüft werden. Die berichteten Scores, die simulierten Apps und der Realgeräte-Test liefern unterschiedliche Evidenzarten und sollten nicht zu einem pauschalen Leistungsversprechen zusammengezogen werden. [1][2]

Quellen

1. [1] Paper page - OpenMobile-2: Building Versatile Mobile Agents with Scalable Environments and App-Native Tools — https://huggingface.co/papers/2610.14157 (abgerufen am 2026-10-19)
2. [2] OpenMobile-2: Building Versatile Mobile Agents with Scalable Environments and App-Native Tools — https://arxiv.org/html/2610.14157v1 (abgerufen am 2026-10-19)