Mejores frameworks de agentes móviles de código abierto: Open-AutoGLM, Mobilerun y mobile-use

Elige según el trabajo que necesitas

Los mejores frameworks de agentes móviles de código abierto no se eligen como una lista de ganadores absolutos. La pregunta práctica es qué quieres controlar: un teléfono Android real, un emulador, una nube gestionada, una prueba de investigación visual o una automatización móvil repetible. Después importa cuánto entorno estás dispuesto a mantener y cómo explicarás una ejecución fallida.

Código abierto no significa llamadas de modelo gratis, dispositivos en la nube gratis ni mantenimiento cero. Separar framework, inferencia del modelo y ejecución en el teléfono evita confundir una instalación correcta con una tarea completada. Las comprobaciones propuestas aquí se basan en documentación; no representan resultados de pruebas ni una clasificación por velocidad o precisión.

Compara instalación, ejecución, modelos y licencia

Un framework de agente móvil tiene varias capas. El entorno de ejecución coordina al agente; el modelo interpreta pantallas e instrucciones; el ejecutor toca el teléfono, lee accesibilidad o usa ADB; y las trazas permiten revisar qué ocurrió. Si una capa funciona y otra falla, el resultado del teléfono también puede fallar.

Verifica la licencia en la revisión concreta que vas a incorporar. La licencia del repositorio no cubre automáticamente modelos, datos, dependencias, dispositivos remotos o condiciones comerciales. Un proveedor externo puede añadir coste, límites, retención de datos y requisitos de cuenta. Para separar elección de modelo de elección de framework, consulta Mejores modelos de IA para agentes Android en 2026: seis opciones por tarea.

Cuándo elegir Open-AutoGLM

Open-AutoGLM encaja cuando tu equipo quiere trabajar cerca de la investigación de agentes visuales de teléfono. El proyecto documenta control de Android mediante ADB, preparación con depuración USB y ADB Keyboard, y uso de un endpoint de modelo. También documenta HDC para HarmonyOS e iOS con una configuración separada basada en WebDriverAgent; eso no convierte la ruta Android por ADB en soporte iOS universal.

Ese endpoint puede ser una API alojada o una inferencia propia; tener el framework no significa que todo el razonamiento ocurra localmente en el móvil. Su punto fuerte es el enfoque visual y experimental sobre pantallas móviles. También documenta confirmación para operaciones sensibles y toma de control humana en inicios de sesión o captchas, dos detalles importantes cuando el agente se acerca a acciones reales.

La parte que conviene revisar antes de adoptarlo es el coste de integración. Necesitas mantener el entorno Python, el puente con el teléfono, la ruta del modelo y la observabilidad suficiente para explicar errores. Si tu objetivo es una aplicación de consumidor lista para usar, Open-AutoGLM probablemente es más infraestructura de investigación que producto final.

Cuándo elegir Mobilerun Framework o Cloud

Mobilerun, anteriormente DroidRun, debe leerse en dos niveles. Mobilerun Framework es el proyecto de código abierto: ejecuta el agente en tu máquina, usa CLI o Python y trabaja con árboles de accesibilidad, capturas, proveedores de modelo y resultados estructurados. Mobilerun Cloud es una oferta gestionada diferente, con flujos API y teléfonos locales conectados o dispositivos virtuales y físicos alojados.

El framework encaja cuando quieres controlar el entorno de ejecución y revisar lo que el agente hizo. Su documentación menciona trazas con Arize Phoenix o Langfuse y trayectorias guardadas, útiles cuando el fallo es una cadena concreta de lectura, decisión y toque. Para Android, revisa ADB, depuración USB y Portal. Para iOS, confirma la ruta separada y el modo admitido, sin asumir paridad universal.

La publicación oficial del 14 de octubre de 2026 en UTC, ya 15 de octubre en China, cambia una comprobación importante: mobilerun run selecciona primero el dispositivo indicado con -d, después el definido en ANDROID_SERIAL y, en ausencia de ambos, el único dispositivo conectado y disponible. Si hay varios sin selección, devuelve un error en vez de elegir el primero. Antes de ejecutar, revisa la lista con adb devices y selecciona deliberadamente el teléfono de pruebas.

También hay una migración que puede explicar configuraciones aparentemente perdidas. Desde el cambio de fichas de aplicaciones del 5 de octubre, se utilizan app_cards_dir/android/app_cards.json y app_cards_dir/ios/app_cards.json. El archivo app_cards.json directamente en app_cards_dir se ignora. Reubica las fichas y comprueba que los identificadores correspondan a Android o iOS, según el destino.

La configuración instala la versión de Portal fijada para la versión de Mobilerun y conserva una más reciente si ya está instalada. Revisa esa relación en la instalación real, sin imponer manualmente un número tomado de otro entorno. En Cloud, la compatibilidad del árbol de interfaz del SDK y los cambios de operaciones de toque y escritura sin reintento son asuntos de mantenimiento que debes comprobar; no garantizan que cualquier tarea termine correctamente.

Cuándo encaja Minitap mobile-use

Minitap mobile-use encaja cuando quieres describir tareas móviles en lenguaje natural, configurar un proveedor LLM y obtener automatización con extracción estructurada. Es especialmente interesante para flujos donde el resultado puede revisarse como datos: abrir una pantalla, buscar información, completar una acción reversible o extraer un estado visible.

Su documentación distingue entornos con cuidado. Android puede usar dispositivos físicos o emuladores mediante ADB, y el arranque con Docker se presenta para Android. En la sección manual, el proyecto lista simuladores iOS en macOS, pero indica que los dispositivos iOS físicos todavía no están soportados. Por eso no conviene convertir una mención amplia de iOS en promesa de paridad con Android.

También hay límites de superficie. El README advierte sobre juegos que no exponen información útil mediante árbol de accesibilidad. Si tu tarea depende de una interfaz gráfica cerrada, animaciones rápidas o controles personalizados, evalúa primero si el framework puede observar lo necesario antes de comparar modelos o costes.

Prueba una tarea reversible e inspecciona fallos

No hace falta empezar con una compra, un envío o una modificación irreversible. Para comparar las tres opciones, propone la misma tarea: abrir una aplicación inocua elegida por ti en un teléfono de pruebas propio y detenerse cuando su pantalla inicial sea visible. Es una comprobación de instalación y control, no un resultado medido en esta guía.

1. Identifica el teléfono o emulador y revisa la lista de dispositivos conectados. En Mobilerun, confirma también la selección con -d o ANDROID_SERIAL.
2. Registra sistema, conexión, modelo, proveedor y permisos. Comprueba que la aplicación elegida esté instalada en ese dispositivo.
3. Verifica la configuración específica del framework; si migraste Mobilerun, revisa las fichas por plataforma y Portal.
4. Pide únicamente abrir la aplicación y parar. No incluyas mensajes, pagos ni operaciones sobre cuentas reales.
5. Comprueba físicamente la pantalla final y contrástala con la traza. Detén la ejecución si actúa en otro dispositivo o falla un paso.
6. Antes de repetir, identifica qué se ejecutó y corrige la causa. No supongas que un fallo deshizo acciones anteriores.

En FastAgent de Mobilerun, el cambio del 14 de octubre limita la ejecución al primer bloque function_calls de la respuesta: ignora los posteriores y, si una llamada falla, omite el resto de ese bloque. Por tanto, una secuencia propuesta por el modelo no demuestra que todos sus pasos se hayan ejecutado. Revisa el resultado real antes de reparar y reintentar; no hay que interpretarlo como una transacción con reversión automática.

Portal puede restablecer el servicio de accesibilidad y el teclado Portal si se desactivan durante una ejecución. Inspecciona su estado real en el dispositivo. Si tu intención es retirar ese acceso, detén primero el agente y después revoca o cambia los servicios correspondientes. No desactives Play Protect ni otras protecciones para mantener una prueba en marcha.

La comparación útil no es “qué framework gana”, sino qué fallo puedes explicar y reparar. Si entiende la tarea pero no ejecuta, revisa el puente con el dispositivo; si toca donde no debe, revisa observación y traza. Para ampliar esta evaluación, usa Benchmark de agentes Android: cómo evaluar un phone agent en 2026.

Elige una ruta Android lista para usar

FoneClaw no es un framework de código abierto y no debe ponerse en la misma categoría que estos repositorios. Ofrecemos una aplicación Android lista para usar con rutas de modelo compatibles y herramientas para tareas admitidas. Esa diferencia importa: no necesitas construir desde cero la infraestructura de un framework para empezar a utilizar las capacidades disponibles.

En FoneClaw, el modelo configurado interpreta la intención y planifica; las herramientas habilitadas ejecutan bajo los permisos reales de Android y la política de aprobación aplicable. No todas las acciones muestran siempre una solicitud de confirmación. Tampoco ofrecemos control universal de cualquier aplicación ni se debe deducir una integración nativa con los frameworks comparados.

Esta ruta encaja si quieres realizar tareas compatibles en tu teléfono sin mantener tu propio entorno de ejecución. Conserva límites: ejecutar herramientas en Android no significa que toda la inferencia sea local, y los modelos o servicios opcionales tienen condiciones propias. Elegir un producto listo para usar cambia la carga de integración, no elimina la necesidad de comprobar permisos y resultados.

Para entender esa separación, lee Controlar un teléfono Android con agente de IA: de intención a acción verificada. Si necesitas revisar capacidades antes de decidir entre producto y framework, la página de funciones de FoneClaw presenta el alcance disponible sin confundirlo con una plataforma de código abierto.