Open-Source-Frameworks für Smartphone-Agenten: Open-AutoGLM, Mobilerun und mobile-use
Drei Frameworks nach Gerät, Modellroute und Betriebsaufwand auswählen. Mit aktuellen Mobilerun-Prüfungen für Geräteauswahl, App-Karten und Fehlerbehandlung.
- Open-AutoGLM passt, wenn Sie ein visuelles Android-Agenten-Framework mit ADB-Ausführung, eigener Modellroute und Übernahmepunkten für sensible Schritte bewerten möchten.
- Mobilerun eignet sich für CLI- oder Python-Automation mit Accessibility-Baum, Screenshots und Tracing. Vor dem Lauf sind Zielgerät, plattformspezifische App-Karten und Portal-Zustand ausdrücklich zu prüfen; Framework und Managed Cloud bleiben getrennte Wege.
- Minitap mobile-use ist interessant für strukturierte mobile UI-Aufgaben mit konfigurierbaren LLM-Anbietern, Android per ADB und eingeschränkter iOS-Unterstützung nach Projekt-Setup.
- FoneClaw ist kein Open-Source-Framework, sondern ein fertiger Android-Agent für unterstützte Telefonaufgaben. Das Modell plant; aktivierte Werkzeuge handeln unter tatsächlichen Android-Berechtigungen und Freigaberegeln.
Nach Aufgabe das passende Framework wählen
Bei Open-Source-Frameworks für Smartphone-Agenten gibt es keinen universellen Sieger. Die passende Wahl hängt von Aufgabe, Zielgerät und der Frage ab, wie viel Betriebsverantwortung Sie selbst übernehmen möchten: Geräte vorbereiten, Modellroute betreiben, Telefonaktionen ausführen und Fehler untersuchen. Für diese Auswahl zählen drei dokumentierte Frameworks: Open-AutoGLM, Mobilerun und Minitap mobile-use.
| Framework | Am besten geeignet für | Erster Realitätscheck |
|---|---|---|
| Open-AutoGLM | Visuelle Android-Agenten mit ADB-Steuerung und eigener Modellroute | Android-Gerät mit Debugging, ADB Keyboard, Modell-Endpunkt und Übernahme für sensible Schritte |
| Mobilerun | CLI- oder Python-Abläufe mit Bedienhilfebaum, Bildschirmfotos, strukturierten Ergebnissen und Ablaufverfolgung | Beabsichtigtes Gerät auswählen, Portal-Zustand und App-Karten prüfen; lokales Framework oder Managed Cloud getrennt planen |
| Minitap mobile-use | Strukturierte Mobile-UI-Aufgaben mit konfigurierbaren LLM-Anbietern | Android per ADB; iOS nur nach projektbezogenem Setup, nicht als pauschale Geräteparität |
Wählen Sie Open-AutoGLM, wenn Sie nah an visueller Telefonsteuerung und Modellinferenz arbeiten wollen. Wählen Sie Mobilerun, wenn Tracing, strukturierte Ergebnisse und Cloud-Optionen wichtig sind. Wählen Sie mobile-use, wenn Sie Mobile-UI-Automation als klaren Python-Workflow mit strukturierten Ausgaben betrachten. Bei jeder Route zählt vor dem ersten Auftrag, welches Gerät tatsächlich verbunden ist und wie ein fehlgeschlagener Schritt untersucht wird.
Setup, Ausführung, Modelle und Lizenz vergleichen
Trennen Sie vier Schichten, bevor Sie sich festlegen: Framework-Laufzeitumgebung, Modellinferenz, Telefonausführung und Gerätebereitstellung. Open Source bedeutet hier, dass der Framework-Code unter seiner Lizenz nutzbar ist. Es bedeutet nicht, dass Modellaufrufe, Cloud-Geräte, Wartung, Tokenkosten, Tracing-Dienste oder physische Testgeräte kostenlos sind.
| Kriterium | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| Repository-Lizenz | Apache-2.0 | MIT | Apache-2.0 |
| Bereitstellung | Eigene Framework-Umgebung; gehostete oder selbst gehostete Modellinferenz | Framework auf eigener Maschine oder separater Managed-Cloud-Weg | Eigenes Framework-Setup; Android-orientierter Docker-Schnellstart |
| Android-Verbindung | ADB; Entwickleroptionen, USB-Debugging und ADB Keyboard | ADB plus Portal Accessibility Service; Zielgerät ausdrücklich auswählen | ADB für physische Android-Geräte und Emulatoren |
| Modellweg | Gehosteter Modell-Endpunkt oder selbst gehostete Inferenz | Auswahl von Modellanbietern; lokale Framework-Ausführung bedeutet nicht automatisch lokale Inferenz | Konfigurierbare LLM-Anbieter |
| Zugriff und Kontrolle | Bestätigung sensibler Operationen und menschliche Übernahme dokumentiert | Portal-Dienst, Tastatur und tatsächliche Geräterechtelage kontrollieren | ADB-Zugriff und verfügbare Accessibility-Informationen im Ziel-Setup prüfen |
| App-Konfiguration | Ziel-App und zugehörigen Aktionsweg anhand der Projektkonfiguration prüfen | App-Karten in getrennten Android- und iOS-Unterordnern; Plattformkennungen nicht vermischen | Ziel-App auf brauchbare UI- und Accessibility-Informationen prüfen |
| Inspektion und Fehler | Visuellen Ablauf und Übernahmepunkte prüfen | Accessibility-Baum, Screenshots, strukturierte Ergebnisse, Trajektorien und Tracing; nach Fehlern tatsächlichen Teilzustand prüfen | Strukturierte Extraktion kontrollieren; Grenzen bei Apps ohne brauchbare Accessibility-Informationen |
| iOS | Separates WebDriverAgent-Setup | Separater Portal-Setup-Flow | README nennt iOS-Simulatoren auf macOS; physische iOS-Geräte sind dort noch nicht unterstützt |
Die offiziellen Repositories sind die relevanten Ausgangspunkte: Open-AutoGLM auf GitHub, Mobilerun auf GitHub und Minitap mobile-use auf GitHub. Prüfen Sie Installation, Lizenz und Abhängigkeiten für den verwendeten Stand. Repository-Lizenz, Modellbedingungen und Cloud-Vertrag sind getrennte Prüfungen; ein Demo-Video ersetzt keine davon.
Wann Open-AutoGLM passt
Open-AutoGLM passt, wenn Ihr Team ein visuelles Phone-Agent-Framework aufbauen möchte und bereit ist, Android-Geräte per ADB vorzubereiten. Das Projekt dokumentiert Android-Steuerung über ADB, zusätzlich HDC für HarmonyOS, und beschreibt für Android Entwickleroptionen, USB-Debugging sowie ADB Keyboard. Damit ist es näher an einer Framework- und Forschungsumgebung als an einer sofort fertigen Endnutzer-App.
Der Modellteil ist getrennt von der Telefonausführung. Open-AutoGLM kann mit einem gehosteten Modell-Endpunkt arbeiten oder mit selbst gehosteter Inferenz verbunden werden. Ein lokaler GPU-Server ist für den gehosteten API-Weg nicht zwingend, aber Modellkosten, Verfügbarkeit, Datenschutzanforderungen und Latenz bleiben eigene Entscheidungen. Die Apache-2.0-Lizenz des Repositories überträgt sich nicht automatisch auf jedes Modell, jeden Dienst oder jede Abhängigkeit.
Besonders wichtig ist die menschliche Kontrolle. Das Projekt beschreibt Bestätigung bei sensiblen Operationen sowie menschliche Übernahme bei Login oder Captcha. Diese Grenzen sind keine Schwäche, sondern ein realistischer Teil von Telefonagenten: Manche Schritte sollten sichtbar geprüft oder manuell übernommen werden.
Wann Mobilerun Framework oder Cloud passt
Mobilerun, früher im Umfeld von DroidRun bekannt, ist interessant, wenn Sie mobile Steuerung als Entwickler-Workflow mit CLI oder Python brauchen. Das Framework arbeitet mit Accessibility-Bäumen, Screenshots, Modellanbieter-Auswahl und strukturierten Ergebnissen. Für Android werden ADB, Entwickler- beziehungsweise USB-Debugging und der Portal Accessibility Service beschrieben.
Wichtig ist die Trennung zwischen Mobilerun Framework und Mobilerun Cloud. Das Framework läuft auf Ihrer Maschine und steuert angebundene Geräte in Ihrer Umgebung. Die Managed Cloud ist ein eigener Betriebsweg mit verbundenen lokalen Telefonen oder gehosteten virtuellen beziehungsweise physischen Geräten und API-Workflows. Wer Datenschutz, Kosten, Wartung und Reproduzierbarkeit bewertet, muss diese beiden Wege getrennt kalkulieren.
Für bestehende Installationen sind zwei Oktober-Änderungen relevant. Die Veröffentlichung vom 5. Oktober 2026 zur App-Karten-Migration trennt die Dateien nach Plattform: app_cards_dir/android/app_cards.json und app_cards_dir/ios/app_cards.json. Eine flache Datei direkt im Stamm von app_cards_dir wird ignoriert. Verschieben Sie Karten in den passenden Unterordner und prüfen Sie Android-Paketkennungen beziehungsweise iOS-Bundle-IDs. Das Setup verwendet die für den Framework-Stand vorgesehene Portal-Version und lässt eine bereits neuere Portal-Installation bestehen.
Die Veröffentlichung vom 14. Oktober 2026 nach UTC präzisiert die Geräteauswahl: mobilerun run berücksichtigt zuerst -d, dann ANDROID_SERIAL, danach nur ein eindeutig einziges online verfügbares Gerät. Bei mehreren Geräten ohne Auswahl entsteht ein Fehler statt einer stillen Wahl des ersten Geräts. Prüfen Sie daher vorab die Verbindungsliste und wählen Sie das beabsichtigte Testtelefon bewusst aus.
FastAgent verarbeitet nur den ersten function_calls-Block einer Modellantwort; spätere Blöcke bleiben unberücksichtigt. Nach einem fehlgeschlagenen Aufruf wird der Rest dieses Blocks übersprungen. Bereits ausgeführte Schritte werden dadurch nicht automatisch rückgängig gemacht. Stoppen Sie, prüfen Sie den tatsächlichen Gerätezustand und beheben Sie die Ursache vor einer Wiederholung.
Portal kann während eines Laufs seinen Bedienungshilfedienst und seine Tastatur wiederherstellen. Wenn Sie den Zugriff entziehen möchten, stoppen Sie zuerst den Agenten und kontrollieren Sie anschließend den tatsächlichen Dienst- und Berechtigungszustand. Deaktivieren Sie dafür keine Sicherheitsmechanismen. Änderungen an der Cloud-SDK-Kompatibilität des UI-Baums und an Tipp- beziehungsweise Texteingabeaktionen ohne automatische Wiederholung gehören ebenfalls in die Wartungsprüfung, sind aber kein Erfolgsversprechen.
Für die Untersuchung solcher Fälle dokumentiert Mobilerun Tracing über Arize Phoenix oder Langfuse sowie gespeicherte Trajektorien. Diese helfen, Modellantwort, ausgewähltes UI-Ziel und tatsächliche Telefonansicht gegenüberzustellen.
Wann Minitap mobile-use passt
Minitap mobile-use passt, wenn Sie mobile UI-Aufgaben in einem strukturierten Framework erfassen möchten. Das Projekt beschreibt Natural-Language-Mobile-Automation, konfigurierbare LLM-Anbieter und strukturierte Extraktion. Android-Geräte und Emulatoren werden über ADB angebunden; der Docker-Schnellstart ist ausdrücklich Android-orientiert.
Bei iOS lohnt sich genaue Lektüre statt grober Plattformannahmen. Das README nennt iOS-Simulatoren auf macOS im manuellen Geräteabschnitt und sagt zugleich, dass physische iOS-Geräte noch nicht unterstützt werden. Wenn Ihr Ziel ein echtes iPhone in der Hand eines Nutzers ist, ist das etwas anderes als ein Simulator-Setup auf einem Mac. Behandeln Sie iOS-Unterstützung daher projektbezogen, nicht als allgemeine Gleichwertigkeit zu Android.
Auch mobile-use hat Grenzen, die bei der Auswahl wichtig sind. Das Projekt weist auf Schwierigkeiten bei Spielen oder Oberflächen hin, die keine brauchbaren Accessibility-Tree-Informationen liefern. Für formularartige Apps, Einstellungen, strukturierte Ansichten und wiederholbare UI-Schritte ist das ein anderer Risikotyp als für stark grafische oder spielähnliche Interfaces.
Eine umkehrbare Aufgabe testen und Fehler prüfen
Bewerten Sie kein Framework an einer großen Demo-Aufgabe. Ein kompakter, aus den dokumentierten Einrichtungswegen abgeleiteter Vergleichsauftrag lautet: „Öffne auf meinem ausgewählten Testtelefon die bereits installierte Rechner-App. Gib nichts ein und führe keine weitere Aktion aus.“ Das ist ein vorgeschlagener Prüfablauf, kein von uns durchgeführter Test. Verwenden Sie ein eigenes Gerät ohne vertrauliche Inhalte.
- Gerät bestätigen: Angeschlossene Geräte und ihren Verbindungszustand prüfen. Bei Mobilerun das Ziel mit
-doderANDROID_SERIALfestlegen und auf widersprüchliche Einstellungen achten. - Umgebung prüfen: Android-Version, Debugging und je nach Framework Portal oder ADB Keyboard kontrollieren. Bei einer Mobilerun-Migration die plattformspezifischen App-Karten einbeziehen.
- Modellweg festhalten: Anbieter, Endpunkt und mögliche Datenübertragung getrennt von der Framework-Lizenz bewerten.
- Nur die kleine Aufgabe ausführen: Keine Nachricht, Zahlung oder Kontoänderung als Beispiel verwenden. Bei falschem Gerät oder unerwarteter Aktion sofort stoppen.
- Ergebnis vergleichen: Ist die gewählte App auf dem vorgesehenen Telefon tatsächlich im Vordergrund? Stimmen Screenshot, UI-Baum und Protokoll damit überein?
- Fehler gezielt bearbeiten: Nach einem gescheiterten Schritt Teilzustand und Ursache prüfen. Nicht blind erneut ausführen und keinen automatischen Rollback voraussetzen.
Dokumentieren Sie, was das Framework sieht, welches Modell entscheidet und welcher Executor die Aktion ausführt. Für eine Unterbrechungsprüfung stoppen Sie den Lauf kontrolliert und prüfen anschließend Dienste und Zugriffe. Eine laufende Wiederherstellung von Portal darf nicht mit dauerhaft entzogenem Zugriff verwechselt werden.
Für eine breitere Bewertungsmethode führt Android Phone Agent Benchmark: So bewertet man mobile KI-Agenten 2026 tiefer in Aufgabenqualität, Sicherheit und Wiederholbarkeit. Wenn die Modellwahl selbst im Vordergrund steht, ergänzt KI-Modelle für Android-Agenten nach Aufgabe auswählen die Framework-Entscheidung, ohne daraus eine Framework-Rangliste zu machen.
Den fertigen Android-Weg wählen
Nicht jeder Leser möchte ein Open-Source-Framework betreiben. FoneClaw ist in dieser Auswahl deshalb kein viertes Framework, sondern unser fertiger Android-Produktweg für unterstützte Telefonaufgaben. Ein konfiguriertes Modell verarbeitet Absicht und Planung; aktivierte Werkzeuge führen unterstützte Aktionen unter den tatsächlich erteilten Android-Berechtigungen und geltenden Freigaberegeln aus.
Das ist die passendere Route, wenn Sie nicht ADB-Setups, Tracing-Backends, Modellserver, Gerätefarmen oder Framework-Wartung übernehmen wollen. FoneClaw bietet ein kostenloses Standardmodell und unterstützt kompatible Modellrouten, aber Telefonlaufzeit bedeutet nicht, dass jede Inferenz automatisch auf dem Gerät bleibt. Welche Aktionen möglich sind und welche Bestätigung erforderlich ist, hängt vom Werkzeug, Zugriff und eingestellten Freigabemodus ab. Daraus folgt weder universelle App-Steuerung noch eine Bestätigungsabfrage bei jeder einzelnen Aktion.
Die deutsche FoneClaw-Funktionsseite zeigt, welche Android-Bereiche unterstützt werden. Für den Übergang von Absicht zu bestätigter Telefonaktion erklärt Android-Handy mit KI-Agent steuern: von Absicht zu bestätigter Aktion die Produktlogik ausführlicher. Eine native Integration der hier verglichenen Frameworks ist damit nicht behauptet. Wählen Sie FoneClaw, wenn Sie eine nutzbare Android-Agentenoberfläche suchen; wählen Sie ein Framework, wenn Sie die Laufzeit selbst bauen, instrumentieren und warten möchten.