Enseñar a un agente móvil mostrándole la tarea: grabación, skills y seguridad

Enseñar una tarea no consiste en grabar cada toque

¿Puede un agente aprender un flujo a partir de una grabación de pantalla? La idea ya tiene una forma concreta: observar cómo una persona completa una tarea, escuchar por qué toma cada decisión y convertir el ejemplo en instrucciones reutilizables. El objetivo no es conservar una película de los toques, sino identificar la intención, los datos variables, las condiciones y el resultado que define el éxito.

Según el informe de ITmedia del 22 de julio de 2026, Record a Skill de Claude Cowork registra una tarea junto con la explicación hablada y la transforma en una skill reutilizable. Las pruebas publicadas por Android Authority el 21 de julio describen el mismo principio: grabar la pantalla mientras el usuario explica el recorrido para reducir las instrucciones repetidas en tareas recurrentes. Es una señal relevante para el diseño de agentes, aunque Claude Cowork desempeña su propia función y esta capacidad no constituye control Android.

Aprender por demostración se diferencia de cuatro mecanismos cercanos. Un prompt describe el objetivo con palabras, pero no enseña necesariamente la secuencia real. Una macro determinista reproduce eventos predefinidos. Una grabación de pantalla conserva evidencia visual, aunque por sí sola no contiene una regla ejecutable. El entrenamiento de un modelo modifica o ajusta su comportamiento general mediante datos y evaluación; crear una skill a partir de un ejemplo busca encapsular un procedimiento concreto.

La distinción importa porque un teléfono cambia constantemente. Una demostración sólida debe enseñar «selecciona la factura pendiente del mes indicado y prepara el envío» en lugar de «toca estas coordenadas». Para conocer el contexto más amplio de estas interfaces, consulte Claude Cowork en el móvil: por qué el teléfono será la interfaz del agente de IA.

De la grabación a una skill reutilizable

¿Cómo pasa un ejemplo observado a convertirse en un procedimiento que pueda utilizarse de nuevo? El ciclo empieza antes de pulsar el botón de grabación. La persona debe definir una tarea con principio y final reconocibles, preparar datos ficticios o no sensibles y saber qué decisiones explicará en voz alta. «Voy a elegir el pedido con estado pendiente, no el primero de la lista» aporta una regla; «ahora pulso aquí» solo describe un gesto.

Durante la captura se recogen dos canales complementarios. La pantalla muestra aplicaciones, controles, transiciones y resultados. La narración identifica el objetivo, justifica elecciones y señala excepciones: qué hacer si no aparece un elemento, cuándo detenerse o qué dato debe solicitarse. Esta combinación permite separar la lógica de negocio de los detalles incidentales, como el orden actual de una lista o la posición temporal de un botón.

Después llega la extracción. El sistema necesita identificar entradas variables, acciones constantes y condiciones. Un flujo para preparar un mensaje de seguimiento podría parametrizar el contacto, la fecha y el contenido, mientras conserva reglas como comprobar el destinatario y presentar el borrador antes de enviarlo. También debe distinguir entre un valor elegido durante la demostración y un valor que siempre debe mantenerse.

La skill resultante requiere una definición operativa: nombre, propósito, aplicaciones implicadas, datos de entrada, pasos permitidos, resultado esperado, permisos y puntos de confirmación. Conviene añadir respuestas para estados alternativos, como una sesión cerrada, un contacto duplicado, una pantalla que tarda en cargar o un dato obligatorio ausente. El paquete se vuelve reutilizable cuando puede invocarse con parámetros nuevos sin arrastrar información privada del ejemplo original.

Finalmente, la invocación debe ser natural y verificable. Una petición como «prepara el informe de gastos de esta semana» puede activar la skill, pero antes de actuar el agente necesita resolver el periodo, las fuentes y el destino. Para recorridos de este tipo, nuestra guía sobre Cómo automatizar tareas Android de varios pasos con una orden de voz explica cómo una intención se transforma en acciones encadenadas y comprobables.

Por qué Android exige algo más que una repetición literal

La misma tarea rara vez presenta exactamente la misma pantalla dos veces. Una aplicación puede abrir una promoción, cambiar la navegación tras una actualización o mostrar contenido distinto según la cuenta. El tamaño del dispositivo, la orientación, la escala de texto y el diseño adaptable también alteran posiciones y dimensiones. Por eso, una secuencia de coordenadas que funcionó durante la grabación puede seleccionar otro elemento en la siguiente ejecución.

El idioma añade otra variable. Un botón identificado como «Continuar» puede adoptar otra etiqueta al cambiar la configuración regional, y las fechas, monedas o direcciones pueden usar formatos diferentes. La skill debe apoyarse en el significado del control, su función y su contexto, no únicamente en una coincidencia visual o textual rígida.

Android ofrece información estructurada mediante los árboles de accesibilidad cuando la aplicación expone correctamente sus elementos. La guía de servicios de accesibilidad de Android muestra cómo estos servicios pueden recibir información sobre la interfaz y actuar de acuerdo con su finalidad declarada. Para un agente, esa estructura puede ayudar a identificar controles por función, aunque la disponibilidad y calidad de los datos dependen de cada aplicación y pantalla.

Los cuadros de permisos merecen un tratamiento específico. Pueden aparecer la primera vez, después de una actualización o cuando el sistema revoca un acceso que llevaba tiempo sin usarse. No son obstáculos que deban descartarse: cambian la autoridad disponible. Una skill bien diseñada reconoce el diálogo, explica por qué se necesita el permiso y permite continuar, elegir un alcance más reducido o recurrir a un paso manual.

También influyen la sesión de la cuenta, la conectividad, las notificaciones superpuestas y los estados vacíos. El flujo debe comprobar dónde se encuentra antes de avanzar. Si esperaba una lista de pedidos y aparece una pantalla de inicio de sesión, su siguiente acción correcta no es tocar donde estaba el primer pedido, sino detenerse y presentar el nuevo estado. La investigación sobre PhoneBuddy-4B y entrenamiento de agentes móviles: por qué Mock-App RL importa en Android aporta contexto adicional sobre la necesidad de evaluar agentes frente a variaciones controladas.

Cómo grabar una demostración limpia y útil

Una buena captura enseña decisiones sin incorporar secretos. Antes de comenzar, conviene usar una cuenta de prueba o preparar registros ficticios, cerrar notificaciones, limpiar el portapapeles y retirar de la pantalla cualquier dato que no forme parte de la tarea. La grabación debe mostrar solo el recorrido necesario y detenerse antes de introducir información reservada.

Nunca deben aparecer contraseñas, códigos de autenticación, números completos de tarjetas, datos bancarios, conversaciones privadas, historiales médicos, documentos de identidad ni información personal de terceros. Tampoco es suficiente ocultarlos mediante la narración si siguen visibles en la pantalla. Los valores sensibles deben reemplazarse por datos de prueba o introducirse fuera de la captura en un punto que la skill marque como intervención del usuario.

La documentación de MediaProjection de Android exige consentimiento del usuario para cada sesión de proyección y establece expectativas para el tratamiento del contenido capturado. Esto recuerda que grabar la pantalla es una capacidad concedida para una sesión concreta, no una autorización permanente. La persona debe saber cuándo empieza la captura, qué superficie se comparte y cuándo termina.

La narración debe explicar las reglas que no son evidentes. Resulta útil decir «si hay más de un contacto con este nombre, pregunta cuál corresponde», «no envíes hasta que revise el texto» o «si el total supera este límite, detente». También debe nombrar el resultado esperado: un borrador guardado, una cita preparada o una configuración visible. Sin esa meta, el sistema puede aprender los gestos y perder el propósito.

Un protocolo breve mejora la captura: definir el objetivo, preparar datos seguros, enumerar decisiones, grabar una sola ejecución limpia, describir excepciones y revisar el vídeo antes de procesarlo. Si durante la revisión aparece información sensible, la captura se descarta y se repite con un entorno saneado. Las recomendaciones de privacidad y seguridad de Android sitúan permisos y acceso a datos como capacidades delimitadas, principio que debe mantenerse al convertir una demostración en skill.

Probar, limitar y recuperar cada flujo

Una skill no queda lista porque reproduzca correctamente el ejemplo original. Debe superar situaciones distintas sin abandonar sus reglas. El primer paso es una ejecución en seco: el agente recorre el plan, identifica pantallas y muestra las acciones previstas, pero no realiza cambios importantes. Así se comprueba si entendió el objetivo antes de concederle capacidad operativa.

Después se prueban variaciones deliberadas. Cambie el orden de una lista, utilice otra cuenta de prueba, aumente el tamaño de fuente, altere el idioma o retire temporalmente un permiso. Añada un elemento duplicado y provoque una pantalla vacía. La skill debe reconocer la diferencia, adaptar el recorrido cuando exista una alternativa autorizada y pedir ayuda cuando falte información.

Cada acción necesita un mapa de permisos. Abrir una aplicación, leer contenido visible, modificar un ajuste y enviar un mensaje implican capacidades distintas. La skill debe solicitar solo las necesarias para su cometido y mantener confirmaciones en acciones como enviar, publicar, borrar, comprar o compartir datos. Nuestra guía de Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real desarrolla cómo relacionar cada capacidad con el momento exacto de uso.

La gobernanza continúa después de la prueba. Cada versión debería indicar qué cambió, con qué aplicaciones se comprobó y qué permisos utiliza. Los registros deben mostrar entradas relevantes, decisiones, acciones completadas y motivos de detención, evitando almacenar secretos. Si una actualización de la aplicación rompe el recorrido, debe ser posible volver a la versión anterior o desactivar la skill mientras se corrige.

La recuperación forma parte del diseño, no es un añadido. Un flujo que crea un borrador puede eliminarlo; uno que modifica una preferencia puede restaurar el valor anterior; una acción irreversible necesita confirmación reforzada. La trazabilidad permite explicar qué ocurrió y facilita corregirlo. Para ampliar este punto, consulte Identidad, permisos y auditoría de agentes IA: la capa de seguridad que necesita un teléfono.

La visión de FoneClaw sobre los flujos reutilizables

Desde FoneClaw entendemos una skill móvil como una intención reutilizable con parámetros, acciones compatibles, permisos y resultados esperados. El modelo configurado aporta comprensión del lenguaje, razonamiento y planificación. FoneClaw convierte ese plan en acciones Android admitidas, muestra su progreso y conserva la confirmación del usuario en los puntos de mayor consecuencia.

En el alcance actual de FoneClaw, la creación automática de una skill a partir de una grabación de pantalla todavía no forma parte del producto. La señal de Record a Skill resulta valiosa porque muestra hacia dónde puede evolucionar la definición de flujos: enseñar con un ejemplo y una explicación, en lugar de describir cada paso desde cero. Nuestro enfoque presente se concentra en ejecutar de forma clara los recorridos Android compatibles.

La demostración puede servir como especificación para diseñar una skill, siempre que se revise antes de utilizarla. Hay que extraer el objetivo, sustituir datos concretos por parámetros y decidir qué acciones necesitan autorización. El modelo puede planificar una ruta según el estado observado, mientras FoneClaw mantiene las acciones dentro de los permisos disponibles. Esta combinación evita reducir el flujo a una serie rígida de coordenadas.

Los resultados visibles son esenciales. Si la tarea consiste en preparar un mensaje, el usuario debe ver el destinatario y el borrador. Si modifica un ajuste, debe observar el nuevo valor. Cuando una aplicación cambia o una acción no está disponible, FoneClaw presenta el estado alcanzado y ofrece una alternativa práctica, como abrir la pantalla adecuada o solicitar que la persona complete el paso restante.

El criterio para decidir si merece la pena reutilizar un flujo es concreto: debe repetirse con frecuencia, tener entradas identificables, admitir una comprobación objetiva y contar con puntos claros de confirmación. Las tareas ambiguas, excepcionales o cargadas de información sensible requieren más intervención. Enseñar un agente móvil por demostración será realmente útil cuando la grabación deje de ser una repetición y se convierta en una especificación comprobable, adaptable y gobernada.