ARTEMIS de Google: automatización en lenguaje natural para teléfonos Android reales

En el auge de los agentes de IA, los teléfonos han sido la excepción. En el escritorio o en el navegador, los agentes recorren cada vez más interfaces a base de clics, manejan aplicaciones, escriben código, leen archivos y siguen instrucciones en lenguaje corriente con poca supervisión. En el móvil, la historia ha sido mucho menos impresionante. Los frameworks de pruebas convencionales suelen ser frágiles, dependen mucho de identificadores de elementos fijos y se rompen en cuanto cambia un diseño. Peor aún, ninguno se pensó para un agente al que basta con decirle un objetivo para que deduzca los pasos por sí mismo.

La brecha llama la atención porque el smartphone es donde la mayoría de la gente pasa la mayor parte de su tiempo digital. El software que se maneja bien con ordenadores y navegadores todavía tiene problemas para operar un teléfono real.

ARTEMIS, un proyecto que Google acaba de publicar como código abierto, aborda el problema de otra manera. Los desarrolladores no tienen que describir de antemano cada pantalla, widget e interacción. Un agente de IA recibe una instrucción en lenguaje natural y la ejecuta en un dispositivo Android real o en un emulador. Según el proyecto, completa más del 99 por ciento de las tareas de un exigente benchmark de varios pasos y se conecta a los agentes de programación que los desarrolladores ya usan, entre ellos Codex, Claude Code y Antigravity.

Aún más interesante es la dirección de la hoja de ruta: ejecución totalmente local en el dispositivo, impulsada por modelos de visión ligeros, para que no todas las interacciones tengan que viajar a un servicio en la nube. Si sale bien, la automatización móvil podría pasar de un frágil montón de scripts a interfaces de estilo agente como las que ya conocemos en escritorios y navegadores: algo que entiende qué hay que hacer y maneja el dispositivo para conseguirlo.

Scripts frente a un agente que mira

La automatización móvil clásica exige a quien escribe la prueba nombrar cada elemento que toca un script, normalmente mediante un identificador compilado en la app, y definir de antemano una secuencia rígida de acciones. Funciona aceptablemente en una pantalla estable dentro de una app cuyo interior el autor puede ver y controlar. Se derrumba en cuanto algo se mueve. Un botón rediseñado, un identificador renombrado o una interfaz desconocida dibujada a medida con un toolkit de UI moderno pueden romper en silencio un script que funcionó de forma fiable durante meses, y averiguar por qué suele obligar a una persona a repasar el fallo a mano.

Un diseño basado en IA le da la vuelta a ese modelo. En lugar de reproducir pasos codificados atados a identificadores, el agente mira lo que muestra la pantalla en ese momento, interpreta qué significa la instrucción y elige la siguiente acción sobre la marcha, como alguien que abre por primera vez una app desconocida. Si un botón se ha movido, ha cambiado de etiqueta o se ha rediseñado por completo, el agente se adapta a lo que tiene delante en vez de fallar por una referencia a algo que ya no existe.

Una frase en lugar de un script

La ventaja se ve más fácilmente cuando una sola instrucción sustituye lo que de otro modo sería una prueba larga escrita a mano. En vez de enumerar toques, deslizamientos y búsquedas de elementos, una tarea se puede formular como se le explicaría a un compañero:

Open Settings, find Battery and tell me current level

Con esa petición, el agente se mueve por la interfaz del teléfono real. Encuentra la pantalla correcta combinando el conocimiento de cómo está organizada la app con una lectura visual de lo que se muestra, extrae el valor solicitado y lo devuelve. Nadie ha escrito una sola línea de código de automatización tradicional dirigido a elementos concretos de la pantalla.

El mismo enfoque escala a flujos más complejos que cruzan varias apps. Una instrucción puede describir una secuencia que salta entre aplicaciones sin relación entre sí, algo para lo que un script convencional normalmente necesitaría varias piezas separadas y cuidadosamente coordinadas. Razonar sobre la intención, en lugar de ejecutar un script fijo, es lo que hace realista esa flexibilidad entre apps sin una enorme ingeniería previa para cada flujo.

El diagrama de arriba, tomado del repositorio del proyecto, muestra un flujo de pruebas autónomo en el que Antigravity trabaja junto con ARTEMIS.

Un resultado de benchmark que se puede comprobar

Las promesas audaces de automatización están por todas partes; las medidas con un referente independiente reconocido son mucho más raras. ARTEMIS afirma completar más del 99 por ciento de las tareas de un benchmark creado específicamente para evaluar agentes móviles en muchas aplicaciones reales y escenarios de varios pasos, no en un pequeño conjunto de ejemplos fáciles elegidos a mano.

El gráfico procede de la página del proyecto y muestra la tasa de finalización superior al 99 por ciento en AndroidWorld, un benchmark de Google Research que abarca más de 20 apps y más de 100 tareas de varios pasos.

Un benchmark con tantas aplicaciones y tareas está diseñado para poner a prueba justo aquello con lo que lucha la automatización codificada: diseños desconocidos, tareas que requieren encadenar correctamente varias acciones e interfaces que nadie construyó pensando en la automatización. Superarlo por encima del 99 por ciento supone un nivel de fiabilidad distinto al de las herramientas de IA anteriores, que históricamente tropezaban con el trabajo abierto y de varios pasos en apps reales sin modificar.

Conexión mediante MCP

ARTEMIS no es una herramienta independiente con su propio flujo aislado. Se conecta a los agentes de programación que ya se usan a diario, incluidos Codex, Claude Code y Antigravity, mediante el Model Context Protocol, o MCP. Es un estándar abierto que permite a un agente de IA descubrir y llamar a herramientas externas de forma coherente, sea cual sea la herramienta o el modelo que esté al mando.

Como la conexión se basa en un protocolo abierto y no en una integración puntual con un solo producto, cualquier agente de programación que hable MCP puede controlar un teléfono real como una herramienta más de su repertorio, junto a sus capacidades de leer código, ejecutar comandos o navegar por la web. La configuración suele consistir en registrar el servidor de automatización en la propia configuración del agente de programación, de forma muy parecida a añadir cualquier otra herramienta externa:

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

Después, un desarrollador puede describir una tarea de pruebas móviles en lenguaje corriente dentro del chat del agente de programación, igual que describiría un cambio de código, y el agente maneja directamente el dispositivo conectado. No hace falta cambiar a una aplicación de pruebas aparte.

Ciclos de desarrollo completos en un dispositivo

La ventaja va mucho más allá de comprobaciones rápidas y puntuales como leer un ajuste. Un agente de programación conectado a un dispositivo real puede ejecutar por sí solo flujos de desarrollo mucho más amplios:

• compilar la versión más reciente de una aplicación
• instalar esa compilación nueva en un dispositivo físico conectado
• recorrer un recorrido de usuario concreto, por ejemplo iniciar sesión con una cuenta de prueba
• buscar comportamientos inesperados, como una ventana emergente que no debería aparecer tras el inicio de sesión
• devolver capturas de pantalla como prueba visual de lo que ocurrió en cada fase

La captura de arriba muestra una demo en vivo del proyecto: planificar rutas en coche y sumar su duración en Google Maps, y después abrir YouTube.

Ese tipo de flujo de extremo a extremo, que abarca compilar, instalar, navegar y verificar, reproduce lo que hace un ingeniero de QA al revisar un cambio antes de publicarlo, con un agente de IA siguiendo instrucciones en lenguaje natural en lugar de una persona tocando un dispositivo físico. Los equipos que ya se apoyan en agentes en buena parte de su desarrollo pueden llevar ese enfoque al hardware real, lo que elimina uno de los pasos manuales más persistentes de una canalización que, por lo demás, está cada vez más automatizada.

Saber por qué falló una ejecución

Manejar un dispositivo es solo la mitad de una herramienta de pruebas útil. Cuando algo se rompe, entender por qué importa tanto como provocar la interacción. Además de las acciones en pantalla, ARTEMIS recoge diagnósticos del dispositivo mientras se ejecuta un flujo, incluidos registros del sistema y capturas de la pantalla en momentos significativos.

Esas capturas importan para depurar de verdad, no solo para automatizar el camino feliz. Una prueba que falla a mitad de una secuencia larga es mucho más útil si devuelve una captura de la pantalla en el momento del fallo, más la salida del registro del sistema de ese mismo instante, que un simple veredicto de aprobado o suspenso. Una ejecución fallida se convierte en un punto de partida práctico para investigar, no en un callejón sin salida que obliga a reproducir todo el escenario a mano solo para ver qué pasó.

La hoja de ruta: privado y local

La capacidad actual ya es un gran paso respecto a la automatización móvil clásica, pero la hoja de ruta publicada apunta a algo posiblemente mayor con el tiempo: la ejecución en el propio dispositivo, impulsada por modelos ligeros de visión y lenguaje que corren en local, en lugar de una conexión constante a un modelo en la nube para cada acción.

Ese cambio trae dos ventajas prácticas. La primera es la latencia. Cuando el razonamiento y la ejecución ocurren por completo en el teléfono, sin un viaje de ida y vuelta por la red a un modelo remoto en cada paso, las respuestas llegan mucho más rápido, y eso importa en una automatización que tiene que seguir el ritmo de una interfaz interactiva en tiempo real en vez de detenerse antes de cada acción.

La segunda ventaja, posiblemente de más peso, es la privacidad. Una automatización que nunca saca del dispositivo una captura de pantalla ni ningún otro registro de lo que aparece en ella es mucho más adecuada para material sensible, ya sean datos personales, información empresarial confidencial o cualquier otra cosa que una persona o empresa prefiera mantener en su propio hardware.

Frente a la tendencia ya muy avanzada en escritorios y navegadores, a menudo llamada computer use, la hoja de ruta lleva esa idea al mundo móvil, con un énfasis deliberado en que sea privada y local en lugar de depender permanentemente de la nube. Los equivalentes de escritorio todavía suelen pasar la comprensión de la pantalla por un modelo alojado, así que un plan basado en modelos de visión ligeros en el dispositivo sugiere un camino más autónomo para los teléfonos.

Qué cambia para los equipos móviles

En conjunto, el control de un teléfono en lenguaje natural, un resultado de benchmark verificable y de alta fiabilidad, la integración con agentes de programación populares, el diagnóstico integrado y una hoja de ruta orientada a la ejecución local suponen algo nuevo para quien crea o prueba apps móviles.

• Las pruebas exploratorias, que antes requerían a una persona curioseando por una app en busca de sorpresas, pueden formularse como una sola instrucción y ejecutarse automáticamente.
• Las comprobaciones de regresión, que exigían scripts frágiles y cuidadosamente mantenidos atados a identificadores de elementos, pueden escribirse en lenguaje corriente mientras el agente se adapta a la evolución de la interfaz.
• Los flujos de desarrollo que antes terminaban en un cambio de código, dejando la verificación en el dispositivo a una persona, pueden completar un ciclo automatizado de compilar, instalar y verificar, a cargo del mismo agente que ya ayuda con el resto del trabajo.

Nada de esto elimina el valor del criterio de un tester experimentado, sobre todo en cuestiones de calidad sutiles y subjetivas que van más allá de si una acción tuvo éxito técnicamente. Lo que cambia es adónde va la atención humana: mucho menos a mantener scripts codificados y frágiles frente a una interfaz que no para de cambiar, y mucho más a decidir qué importa probar, para luego dejar que lo ejecute un agente que razona sobre la intención.

Dónde deja esto a la automatización móvil

Durante años, la automatización móvil fue por detrás de lo que los agentes ya logran en escritorios y navegadores. ARTEMIS reduce la distancia al permitir que los agentes de IA controlen un dispositivo real mediante instrucciones en lenguaje natural. Su tasa de finalización declarada, superior al 99 por ciento en un exigente benchmark independiente, es notable, igual que su integración directa con los agentes de programación que los desarrolladores ya usan a diario.

Lo más interesante quizá esté por llegar. La hoja de ruta apunta a una ejecución totalmente local en el dispositivo, impulsada por modelos de visión ligeros. Si llega, los agentes móviles no solo serían capaces. Serían privados y autónomos, capaces de trabajar sin enviar ninguna interacción a un servicio remoto.

La relevancia de fondo va más allá de automatizar toques, deslizamientos o casos de prueba aislados. Apunta a un futuro en el que un smartphone real es un entorno más que un agente entiende y maneja, junto al terminal, el sistema de archivos, el navegador y la base de código. Para quienes crean, prueban y mantienen apps móviles, eso podría cambiar sustancialmente lo que un agente de programación con IA es capaz de hacer. El código está en el repositorio público de ARTEMIS de Google en GitHub.