Cómo depurar y recuperar fallos de un agente móvil Android sin repetir acciones peligrosas

Primeros cinco minutos tras el fallo

Cuando necesitas depurar y recuperar fallos de un agente móvil, la primera regla es detener antes de repetir. Un fallo de pantalla, un error de permiso o una respuesta confusa del modelo pueden aparecer al final de la tarea, pero la causa real puede haber ocurrido varios pasos antes. Si repites todo sin revisar, puedes duplicar efectos externos: enviar dos mensajes, crear dos eventos, cambiar un ajuste de nuevo o llamar a la persona equivocada.

Usa una respuesta de cinco minutos. Primero, pausa o detén la tarea si el agente ofrece ese control. Segundo, mira el último resultado visible: ¿se abrió la app correcta, se preparó un mensaje, se tocó un botón, se pidió un permiso? Tercero, distingue si la tarea era solo de lectura, reversible o con consecuencias externas. Leer batería o abrir una app permite reintentos más tranquilos; enviar, borrar, llamar, comprar o modificar datos exige confirmación de estado antes de cualquier repetición.

Cuarto, captura el contexto mínimo: pantalla actual, acción esperada, último paso visible y mensaje de error. Quinto, decide si puedes continuar desde el paso fallido o si debes cerrar la tarea. Esta disciplina coincide con una lección del trabajo de AgentDebugX: el fallo mostrado puede ser tarde en la trayectoria, mientras que la atribución útil exige mirar el recorrido completo.

Capturar un paquete mínimo de evidencia

Un buen diagnóstico necesita suficiente evidencia, pero no necesita exponer secretos. Guarda la intención original en una frase: quería enviar un SMS a Ana, crear un evento mañana, cambiar el modo No molestar o resumir la pantalla actual. Después anota el resultado esperado y el resultado real. Esta comparación evita perderse en síntomas vagos como falló todo o el agente no entendió.

El paquete mínimo incluye cuatro bloques. El primero es la trayectoria: pasos visibles, herramientas usadas cuando aparezcan, permisos solicitados, confirmaciones mostradas y resultado de cada paso. El segundo es el estado del teléfono: app en primer plano, pantalla bloqueada o desbloqueada, red, batería, idioma, cuenta y permisos relevantes. El tercero es el punto de fallo: mensaje exacto, pantalla, botón tocado, herramienta que falló o respuesta del servicio externo. El cuarto es privacidad: elimina contraseñas, tokens, contactos completos, contenido de mensajes y datos financieros antes de compartir.

Una captura de pantalla aislada rara vez basta. Puede mostrar el final, pero no la decisión que llevó allí. Para agentes de teléfono, la identidad de la herramienta, el permiso y la aprobación importan tanto como el texto de la petición. Si quieres profundizar en esa trazabilidad, la guía Identidad de agentes de IA: permisos, aprobación por herramienta y auditoría en Android explica cómo separar quién planifica, qué herramienta actúa y qué evidencia queda.

Clasificar la capa que falló

La causa raíz de un agente no se descubre mirando solo el último mensaje. En Android conviene clasificar por capas. La entrada puede estar mal si el usuario pidió algo ambiguo o el dictado cambió un nombre. El modelo puede haber interpretado mal la intención. El enrutamiento puede elegir una capacidad incorrecta. El contexto puede estar incompleto si la pantalla actual no se adjuntó o cambió. El permiso puede estar revocado. La herramienta puede recibir argumentos equivocados. La interfaz puede mostrar otro elemento. El servicio externo puede estar caído. La aprobación puede bloquearse. La verificación puede no comprobar el resultado final.

Android añade una complicación concreta: los permisos pueden cambiar durante la vida de la app. La guía oficial sobre permisos en tiempo de ejecución recuerda que las apps deben comprobar permisos cuando los usan, porque el usuario puede denegarlos, revocarlos o marcarlos como no volver a preguntar. Por eso dos errores iguales en pantalla pueden tener causas distintas: una falta de permiso, una app en segundo plano o un argumento mal construido.

El enrutamiento merece atención propia. Una sugerencia de capacidad no es ejecución, y una alternativa de respaldo no significa que la acción final ya esté autorizada. Para entender esos fallos de selección, la guía Enrutamiento de capacidades de agentes de IA: AutoAttach, Suggest y Fallback en Android mantiene la arquitectura de rutas y alternativas en su página dedicada.

Encontrar el primer paso causal

AgentDebugX resume el ciclo de depuración como Detectar, atribuir, recuperar y volver a ejecutar. Adaptado al teléfono, detectar significa localizar el primer punto observable donde el flujo se desvió. Atribuir significa nombrar la causa más probable con evidencia, no con intuición. Recuperar significa reparar la precondición fallida. Volver a ejecutar significa repetir solo el tramo necesario cuando sea seguro.

Empieza desde el error visible y retrocede. Si el mensaje no se envió, pregunta: ¿el texto estaba preparado, el contacto era correcto, la app estaba abierta, el permiso existía, la confirmación apareció, la red funcionaba? Si una llamada no se inició, revisa contacto, app Teléfono, permiso, estado de SIM, pantalla bloqueada y confirmación. La causa raíz suele ser el primer paso que hizo imposible el resto, no el último mensaje rojo.

Para atribuir con rigor, usa precondiciones de solo lectura antes de actuar. Verifica red, permisos, app activa, contacto, calendario o ajuste actual sin repetir el envío ni el cambio. Después compara plan y argumentos: destinatario, fecha, texto, herramienta, app y acción. Si hay varias causas posibles, escribe confianza y alternativa: probablemente permiso de contactos revocado; alternativa, contacto duplicado.

El artículo de AgentDebugX aporta un marco reciente, pero sus resultados pertenecen a los benchmarks evaluados. En un teléfono real, la fiabilidad se comprueba con tareas, permisos y estado del dispositivo. Para convertir incidentes en pruebas repetibles, enlazamos Benchmark de agentes Android: cómo evaluar un phone agent en 2026.

Recuperar sin duplicar efectos

La recuperación segura empieza con inventario de efectos. Marca cada paso como no iniciado, completado, incierto o fallido. Una lectura de pantalla completada no preocupa. Un mensaje preparado pero no enviado puede reutilizarse. Un evento creado debe verificarse antes de crear otro. Un pago, una llamada, un borrado o un correo enviado necesitan comprobación fuera del agente antes de cualquier reintento.

Después repara la precondición más pequeña. Si falló un permiso, abre la pantalla correspondiente y concede solo lo necesario para la tarea. Si la app perdió el primer plano, vuelve a la pantalla correcta. Si la red falló, reconecta y prueba conectividad. Si el objetivo era ambiguo, corrige contacto, fecha o texto. Si una aprobación quedó pendiente, resuélvela antes de pedir un nuevo plan.

La escalera de reintento debe ir de menor a mayor riesgo. Primero reintenta una lectura o comprobación. Segundo reintenta el paso de herramienta que falló si no produjo efecto externo. Tercero reintenta el sufijo de la tarea desde el estado corregido. Cuarto vuelve a iniciar la tarea solo si has confirmado que no hubo efecto previo que pueda duplicarse.

Android recomienda degradar con claridad cuando falta un permiso y probar combinaciones de permisos concedidos o revocados. Esa práctica encaja con agentes: una tarea fallida agente IA debe dejar una explicación accionable, no un bucle de intentos. En tareas largas o múltiples conversaciones, el estado importa; por eso usamos colas, continuidad y controles visibles para evitar mezclar una recuperación con otra tarea activa.

Usar FoneClaw para diagnosticar y recuperar

En FoneClaw diseñamos la recuperación como parte del producto, no como un mensaje final de error. Cuando una tarea compatible avanza, el usuario puede ver estado, resultados de herramienta, confirmaciones y bloqueos. Si hace falta detener, el control de parada permite cortar el flujo antes de acumular pasos inciertos. Si falta un permiso, guiamos la recuperación hacia la pantalla o acción necesaria para continuar.

El contexto de pantalla actual es deliberado. El usuario decide adjuntarlo cuando necesita que FoneClaw razone sobre lo que está viendo. Eso ayuda a diagnosticar fallos de contexto: si una app cambió, una pantalla se cerró o un botón ya no está visible, el siguiente intento puede partir del estado real. Para entender este mecanismo sin duplicar aquí todo el flujo, consulta Asistente de IA flotante en Android: usar la pantalla actual con control.

FoneClaw trabaja con más de 100 herramientas integradas en familias de acciones Android compatibles: lectura de estado, ajustes reversibles, comunicación, calendario, pantalla, web, flujos y extensiones. En diagnóstico, tratamos el resultado de herramienta como evidencia: qué se intentó, qué permiso faltó, qué devolvió Android y qué queda por confirmar. En acciones con consecuencias, el reintento se hace después de revisar si el paso anterior ya produjo efecto.

También mantenemos controles para reintento y recuperación. Un reintento útil no repite todo por costumbre; repara la precondición y vuelve al paso necesario. Si el problema pertenece al enrutamiento de capacidad, a un complemento o a una Skill, la revisión de activación y capacidades ayuda a distinguir una herramienta ausente de una herramienta presente pero bloqueada por permisos o estado. Las páginas de funciones actuales de FoneClaw y novedades de FoneClaw mantienen las capacidades públicas en lenguaje de producto.

Crear un reporte útil para soporte

Escala a soporte cuando el mismo fallo aparece después de reparar permisos, confirmar estado de app y repetir una prueba de bajo riesgo; cuando una herramienta produce un resultado incoherente; o cuando el agente declara éxito y la app final muestra otro estado. Un buen reporte acelera la solución porque separa intención, trayectoria y evidencia.

Usa esta plantilla redactada:

• Objetivo: qué querías conseguir en una frase.
• Resultado esperado: cómo debía verse el éxito.
• Resultado real: mensaje, pantalla o estado final observado.
• Paso causal probable: permiso, contexto, herramienta, app, red o confirmación.
• Estado del dispositivo: modelo, Android, app en primer plano, red y permisos relevantes.
• Evidencia: captura o texto redactado, sin contraseñas, tokens, datos financieros ni contenido privado innecesario.
• Reproducción: pasos mínimos para repetir el fallo.

Incluye marcas de tiempo aproximadas y elimina información sensible. Soporte necesita una reproducción limpia, no una copia completa de tu vida digital.

Prevenir recurrencias con pruebas

Cierra el incidente con una prueba de aceptación. Toma la causa raíz y crea una variante pequeña: permiso concedido, permiso revocado, app en primer plano, app en segundo plano, red estable, red cortada, contacto claro y contacto ambiguo. La guía de buenas prácticas de permisos de Android recomienda probar flujos con combinaciones de permisos concedidos y revocados; en agentes, eso evita que una corrección funcione solo en el estado ideal.

Define evidencia de éxito antes de volver a confiar en la tarea. Por ejemplo: el agente detecta permiso ausente, explica el bloqueo, abre la recuperación, reintenta solo el paso fallido y verifica el resultado final. Define también criterios de parada: destinatario ambiguo, app cambiada, permiso denegado permanentemente o efecto externo incierto.

Una ejecución correcta no prueba una solución permanente. Convierte el caso en una prueba corta y repítela cuando cambien app, permisos, modelo, complemento o versión de Android. Para equipos que quieren llevar esto a un ciclo de mejora formal, Harness de mejora para agentes de teléfono: pruebas, gobierno y control desarrolla cómo pasar de un incidente a una suite de regresión.