Beste Open-Source-Frameworks für Handy-Agenten: Open-AutoGLM, Mobilerun und mobile-use

Nach Aufgabe das passende Framework wählen

Bei den besten Open-Source-Frameworks für Handy-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.

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.

Setup, Ausführung, Modelle und Lizenz vergleichen

Trennen Sie vier Schichten, bevor Sie sich festlegen: Framework-Runtime, Modellinferenz, Telefonausführung und Gerätebereitstellung. Open Source bedeutet hier, dass der Framework-Code öffentlich nutzbar ist. Es bedeutet nicht, dass Modellaufrufe, Cloud-Geräte, Wartung, Tokenkosten, Tracing-Dienste oder physische Testgeräte kostenlos sind.

Die offiziellen Repositories sind die relevanten Ausgangspunkte: Open-AutoGLM auf GitHub, Mobilerun auf GitHub und Minitap mobile-use auf GitHub. Prüfen Sie dort Installation, Lizenz, Gerätevoraussetzungen und Modellkonfiguration für Ihre Zielumgebung, statt aus einem Demo-Video auf Alltagstauglichkeit zu schließen.

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.

Mobilerun hat einen starken Inspektionsvorteil, wenn Sie Agentenläufe nachvollziehen möchten. Das Repository dokumentiert Tracing über Arize Phoenix oder Langfuse sowie gespeicherte Trajektorien. Das hilft bei Fehlern wie falschem UI-Ziel, fehlendem Zugriff, unklarer App-Oberfläche oder Modellantworten, die zwar plausibel klingen, aber nicht zur tatsächlichen Telefonansicht passen.

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. Starten Sie mit einem reversiblen, sichtbaren Test: eine App öffnen, einen harmlosen Bildschirmzustand lesen, einen Entwurf vorbereiten oder eine Notiz in einer Test-App anlegen. Dokumentieren Sie, was das Framework sieht, welches Modell die Entscheidung trifft, welcher Executor tippt oder navigiert und wie das Ergebnis kontrolliert wird.

1. Gerät vorbereiten: Android-Version, Debugging, Accessibility-Service, Portal oder ADB Keyboard passend zum Framework prüfen.
2. Modellweg festlegen: Hosted API, eigener Server oder Anbieterroute getrennt von der Framework-Lizenz bewerten.
3. Aufgabe klein halten: Eine reversible Aktion wählen, keine Zahlung, kein Versand, keine Kontoänderung.
4. Fehler sichtbar machen: Screenshot, Accessibility-Baum, Trace, gespeicherte Trajektorie oder Log prüfen.
5. Wiederherstellung testen: Berechtigung verweigern, App wechseln, Schritt abbrechen und beobachten, ob der Agent sinnvoll stoppt.

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: sechs Kandidaten 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 bewusst kein viertes Open-Source-Framework, sondern der fertige Android-Produktweg für unterstützte Telefonaufgaben. Ein konfiguriertes Modell verarbeitet Absicht und Planung; FoneClaw führt unterstützte Android-Werkzeuge mit Berechtigungen, Freigaben und sichtbaren Ergebnissen.

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. Ebenso sind nicht alle Android-Aktionen unattended: Besonders Kommunikation, Gerätesteuerung und sensible Schritte brauchen Freigabe und sichtbare Prüfung.

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. 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.