Benchmark de agentes Android: cómo evaluar un phone agent en 2026
Guía práctica para crear un benchmark de agentes Android: tareas, métricas, seguridad, aprobaciones, recuperación y matriz de evaluación para phone agents como FoneClaw.
- Un benchmark de agentes Android debe medir resultado verificado y proceso controlado: intención entendida, efecto correcto, permisos apropiados, aprobación, recuperación y trazabilidad.
- Los benchmarks móviles de 2026 cubren ángulos distintos: B-MoCA prueba configuraciones Android, MobileWorld evalúa tareas largas multiapp, KnowU-Bench añade personalización y consentimiento, y PhoneHarness puntúa efectos observables y trazas.
- La tasa de éxito aislada no basta para evaluar un phone agent; hay que registrar efectos secundarios, intervención humana, reintentos, latencia, coste, recuperación y calidad de auditoría.
- La base actual de FoneClaw ofrece clases de prueba para una suite propia: pantalla visible, acciones reversibles, aprobaciones, detención, permisos, DND, volumen, Bluetooth, capturas, tareas y workflows.
Qué debe medir un benchmark de agentes Android
Un benchmark de agentes Android debe medir algo más exigente que una secuencia plausible de toques. En un teléfono, el éxito real es un resultado verificado con proceso controlado: el agente entendió la intención, usó la autoridad correcta, produjo el efecto esperado, evitó efectos secundarios innecesarios, pidió aprobación cuando la acción lo requería y dejó una ruta de recuperación si el flujo se bloqueó.
Construyendo FoneClaw hemos aprendido que un phone agent falla de formas distintas a un chatbot. Puede abrir la pantalla correcta y tocar el control equivocado. Puede completar una tarea reversible y, aun así, usar más permisos de los necesarios. Puede enviar un resultado correcto después de ignorar una cancelación del usuario. Por eso la evaluación de agentes móviles debe unir dos planos: resultado y trayectoria.
La pregunta inicial para cualquier suite es: ¿qué estado del teléfono debe cambiar y cómo lo verificamos? En una tarea de No molestar, el resultado es el estado final del modo. En un SMS, el resultado puede ser un borrador visible, envío confirmado o una pausa de aprobación. En una auditoría de permisos, el resultado es un informe que refleja el estado real. Para evolucionar esa evaluación con versiones, pruebas y reversión, Agentes móviles que se mejoran: versiones, pruebas y reversión desarrolla el ciclo de harness y gobernanza.
El panorama de benchmarks móviles en 2026
Los benchmarks de agentes IA 2026 no forman un único ranking universal. Cada uno ilumina una debilidad distinta del agente móvil: variación de dispositivos, tareas largas, personalización, consentimiento, herramientas mixtas o efectos observables. Leerlos juntos ayuda a diseñar una suite de producto más realista.
| Benchmark | Qué aporta | Lección para Android |
|---|---|---|
| B-MoCA | El artículo de PMLR Benchmarking Mobile Device Control Agents across Diverse Configurations define 131 tareas diarias Android y varía configuraciones como layouts e idioma. | Un agente debe generalizar entre dispositivos, idiomas y diseños; probar solo un móvil pulido infla confianza. |
| MobileWorld | El paper de ACL MobileWorld incluye 201 tareas en 20 aplicaciones, con media de 27,8 pasos y 62,2% multiapp. El propio paper reporta 51,7% para su mejor framework agentivo y 20,9% para su mejor modelo end-to-end en ese entorno. | Las tareas largas y multiapp exigen estado, recuperación, interacción con usuario y herramientas híbridas. |
| KnowU-Bench | El preprint KnowU-Bench cubre 42 tareas GUI generales, 86 personalizadas y 64 proactivas; oculta el perfil del usuario y expone registros conductuales. | La personalización útil requiere consentimiento, aclaración y contención después de un rechazo. |
| PhoneHarness | El preprint PhoneHarness combina acciones GUI, CLI y herramientas del host, puntúa efectos observables y registra trazas auditables. | La evaluación debe verificar efectos secundarios reales y separar harness de benchmark. |
Comparar porcentajes entre estos trabajos como si fueran una sola tabla de líderes crea una lectura pobre. Cambian tareas, dispositivos, herramientas, horizonte, criterios y entorno. Lo útil es extraer dimensiones: configuración, duración, apps, interacción con usuario, superficie de acción, trazas y efectos. En agentes reales, también importa qué capacidades descubre el sistema y cómo las autoriza. Para esa parte, Agentic Resource Discovery: catálogos fiables sin confundir descubrimiento y autorización conecta descubrimiento de recursos con confianza.
Seis dimensiones para una suite real de pruebas Android
Una suite práctica de pruebas de agentes GUI Android debe variar dimensiones de forma independiente. Si cambias todo a la vez, no sabrás si el fallo viene del idioma, la interfaz, el permiso o la longitud de la tarea. Nosotros usaríamos seis ejes principales.
Configuración. Cambia idioma, densidad de pantalla, modo oscuro, fabricante, permisos iniciales, apps predeterminadas y estado de red. Un agente robusto no vive solo en el dispositivo de desarrollo.
Horizonte. Separa tareas de un paso, secuencias cortas y flujos largos multiapp. Más pasos no siempre significan más dificultad: una tarea corta con un botón ambiguo puede ser más dura que una ruta larga bien estructurada.
Apps y estado inicial. Prueba app abierta, app cerrada, sesión caducada, pantalla inesperada, notificación encima y teclado visible. El estado inicial cambia la estrategia.
Intención del usuario. Usa instrucciones claras, vagas, incompletas y corregidas a mitad del flujo. Un phone agent debe pedir aclaración cuando falta información crítica.
Superficie de acción. Alterna GUI visible, herramienta estructurada, ajuste del sistema, workflow guardado y toma manual. Esta dimensión revela si el agente elige la ruta más fiable.
Consecuencia y recuperación. Incluye acciones reversibles, efectos externos, permisos denegados, cancelación del usuario y fallo de red. Ahí aparece la diferencia entre automatizar y operar con confianza.
Métricas más allá de la tasa de éxito
La tasa de éxito es necesaria, pero deja fuera gran parte de la fiabilidad. Para métricas de fiabilidad phone agent, el denominador debe estar fijado: número de intentos, política de reintentos, entorno, dispositivo, versión de app, idioma, permisos iniciales y criterio de verificación. Sin ese marco, el porcentaje final cuenta poco.
La primera métrica es el pase verificado: el estado final coincide con lo esperado y se comprueba por una fuente adecuada. La segunda son checkpoints parciales: entendió la intención, eligió la app correcta, pidió permiso, preparó el borrador, llegó a aprobación, aplicó y verificó. La tercera son efectos secundarios incorrectos: mensajes enviados de más, ajustes alterados, datos compartidos o navegación a una app equivocada.
También medimos recuperación. ¿El agente explicó el bloqueo? ¿Propuso un siguiente paso? ¿Conservó estado después de un permiso denegado? ¿Permitió detener? La intervención humana debe clasificarse: aclaración normal, aprobación esperada, toma manual por ambigüedad o rescate tras fallo. Latencia, coste de tokens, número de acciones y calidad de traza completan el cuadro.
PhoneHarness es útil aquí porque subraya efectos observables y trazas auditables. En FoneClaw, esa lección encaja con nuestra obsesión por permisos, aprobaciones y registros de tarea. Identidad de agentes de IA: permisos, aprobación por herramienta y auditoría en Android profundiza en la capa de identidad, permiso y auditoría.
Probar aprobaciones, permisos, contención y detención
La seguridad debe puntuar dentro de la tarea, no como apéndice. Un agente que completa un flujo saltando una aprobación esperada no obtiene el mismo resultado que uno que lo completa con autoridad correcta. En Android, probar seguridad significa mirar permiso mínimo, momento de aprobación, claridad de consecuencia, capacidad de detener y comportamiento después de un rechazo.
KnowU-Bench aporta una señal importante al evaluar aclaración, consentimiento proactivo y contención después de rechazo. Esa idea encaja con teléfono móvil: si el usuario rechaza enviar un mensaje, el agente puede guardar un borrador o preguntar si quiere un recordatorio, pero debe respetar la decisión. Una tasa de negativa por sí sola no mide seguridad; lo que importa es si el agente actúa cuando tiene autoridad, pregunta cuando falta información y se contiene cuando el usuario marca un límite.
En una suite local, incluiríamos pruebas como: permiso de ubicación denegado, solicitud ambigua de enviar SMS, ajuste sensible de DND, stop durante ejecución, aprobación caducada, contacto duplicado y pantalla alterada antes de confirmar. La evaluación debe registrar qué vio el usuario en el momento de decidir. UX de aprobación de agentes de IA: decisiones claras en el teléfono desarrolla cómo una aprobación debe mostrar destino, consecuencia y evidencia.
Cómo evaluaríamos tareas actuales de FoneClaw
La base actual de FoneClaw ofrece una referencia concreta para diseñar pruebas de producto: asistente flotante, adjuntar pantalla actual, continuidad de tarea, aprobaciones y detención, recuperación de permisos, mejoras en DND, volumen, modo reunión, fiabilidad de captura y acciones rápidas. La página de funciones de FoneClaw resume capacidades actuales y 100+ built-in tools. Esta guía define método de evaluación; aquí no publicamos una puntuación de benchmark de FoneClaw.
| Clase de prueba | Ejemplo | Qué medir |
|---|---|---|
| Lectura de estado | Revisar pantalla visible o salud del teléfono. | Frescura de observación, precisión del resumen, ausencia de cambios. |
| Control reversible | Ajustar volumen, Bluetooth o DND temporal. | Permiso correcto, aplicación verificable, reversión o recuperación. |
| Efecto externo | Preparar SMS, calendario, memo o tarea. | Aprobación visible, destinatario o contenido correcto, estado final verificado. |
| Workflow repetible | Modo reunión, captura y nota, o rutina de salida. | Estado entre pasos, interrupción, reintento, trazabilidad. |
| Pérdida de permiso | Revocar un permiso durante el flujo. | Detección, explicación, guía de recuperación y continuación segura. |
| Cambio de pantalla | Modificar la app visible antes de ejecutar. | Relectura del estado y decisión entre continuar, aclarar o ceder control. |
También probaríamos una auditoría de permisos como caso completo: leer estado, clasificar riesgo, pedir aprobación si una acción cambia algo y registrar resultado. Para un escenario de usuario de ese tipo, Comprobar salud del teléfono Android con IA: permisos, accesos especiales y apps ocultas muestra cómo una revisión de salud del teléfono puede convertirse en prueba práctica.
Nuestro criterio interno de producto es claro: completar una acción importa, pero respetar intención y control importa más. Si una tarea termina con toma manual bien explicada, puede ser mejor resultado que una ejecución automática con estado dudoso.
Crear un protocolo repetible de benchmark móvil
Para crear una suite repetible de pruebas móviles, empieza por congelar el entorno: dispositivo, versión de Android, fabricante, idioma, apps instaladas, base actual de FoneClaw o del agente, permisos iniciales, red, batería y política de reintentos. Después define estado inicial y estado esperado para cada tarea. Un caso debe poder repetirse por otra persona con el mismo punto de partida.
El protocolo que usamos como guía tiene siete pasos: 1. fijar entorno; 2. describir intención y estado inicial; 3. variar un eje por vez; 4. registrar acciones, permisos, aprobaciones y modelo usado; 5. verificar efectos por fuente independiente cuando sea posible; 6. clasificar recuperación e intervención humana; 7. publicar limitaciones, fallos y casos excluidos.
La primera prueba debe ser reversible. Por ejemplo: activar DND durante diez minutos, verificar estado, detener o revertir. Después sube a tareas con borrador, permiso perdido, pantalla cambiada y flujo multiapp. El scorecard mínimo incluye pase verificado, checkpoints, efectos secundarios, intervención humana, latencia, coste, recuperación y calidad de traza. Así un benchmark de agentes Android deja de ser una cifra aislada y se convierte en una herramienta para construir mejor.