Agentes móviles que se mejoran: versiones, pruebas y reversión

Qué significa que un agente móvil se mejore solo

Un agente móvil que se mejora solo aprende de sus resultados operativos para ejecutar mejor tareas futuras. Revisa qué pasos funcionaron, dónde se detuvo el recorrido y qué condiciones provocaron un fallo. Después propone cambios acotados en su planificación, sus herramientas, sus reglas o sus skills y los somete a pruebas antes de utilizarlos de forma más amplia.

Esta definición no exige cambiar los pesos del modelo de IA. El modelo configurado puede mantenerse fijo mientras evoluciona el harness del agente, es decir, el conjunto operativo que rodea al modelo. Ese entorno incluye prompts, herramientas, mecanismos de ejecución, reglas de verificación, lógica de orquestación y procedimientos de recuperación.

Una skill puede aprender a localizar un botón por función en lugar de por posición, tratar un cuadro de permiso como un estado esperado o conservar un borrador cuando falla el envío. Son mejoras del comportamiento operativo. El modelo sigue aportando razonamiento y la skill sigue limitada por las acciones y permisos que Android pone a disposición.

Crear una skill a partir de una demostración pertenece a una fase anterior. Nuestra guía Enseñar a un agente móvil mostrándole la tarea: grabación, skills y seguridad explica esa captura inicial. Aquí el problema es distinto: cómo mejorar una skill ya desplegada sin romper lo que funcionaba.

Lo que aporta el ciclo Self-Harness

La investigación Self-Harness ofrece un marco concreto para mejorar agentes sin modificar el modelo base. El artículo de Self-Harness define un ciclo de tres etapas: localizar debilidades en trazas de ejecución, generar propuestas acotadas para el harness y validar cada propuesta antes de aceptarla.

La primera etapa parte de evidencia. No basta con que una tarea termine como fallo: hay que identificar en qué paso apareció el problema, qué observación recibió el agente, qué herramienta eligió y qué resultado devolvió. Una traza bien estructurada permite diferenciar una mala planificación de una aplicación que cambió, un permiso ausente o un resultado mal verificado.

Después se formula el cambio mínimo capaz de abordar la debilidad. Puede ser una instrucción más precisa, una comprobación antes de utilizar una herramienta, un argumento validado o una estrategia de recuperación. Limitar la propuesta reduce la superficie que debe probarse y facilita atribuir cualquier regresión a una modificación concreta.

La tercera etapa exige validación. Los autores informan de mejoras en la tasa de éxito sobre casos reservados de Terminal-Bench-2.0 para tres modelos base fijos. En esos experimentos cambió el harness, no los pesos de los modelos. Los resultados pertenecen al estudio y muestran que mejorar el entorno operativo puede elevar el rendimiento sin convertir cada hallazgo en una garantía para cualquier agente o tarea Android.

La reflexión de Salesforce sobre agentes que se mejoran sitúa este problema dentro de una tendencia más amplia: los agentes necesitan aprender de su operación, no limitarse a repetir una configuración inicial. En el teléfono, ese aprendizaje debe conservar límites de aplicación, permisos, confirmación y recuperación.

Los entornos simulados y el entrenamiento de agentes móviles responden a otra pregunta. Para conocer ese ámbito sin confundirlo con la mejora del harness desplegado, consulte PhoneBuddy-4B y entrenamiento de agentes móviles: por qué Mock-App RL importa en Android.

Cómo se mejora FoneClaw sin reescribir el modelo

FoneClaw es un agente móvil que se mejora solo. Utiliza resultados de ejecución y trazas de fallos para perfeccionar la planificación, el comportamiento de su harness y las skills reutilizables. Cada evolución sigue un proceso gobernado con pruebas, aprobación, registro de versiones, despliegue gradual y reversión.

El usuario configura un modelo compatible dentro del flujo de FoneClaw. Ese modelo aporta comprensión del lenguaje, razonamiento y planificación. FoneClaw mantiene la responsabilidad operativa: expone las acciones Android admitidas, ejecuta los pasos compatibles, muestra el estado, utiliza permisos concedidos y solicita confirmación en momentos relevantes.

La mejora puede comenzar con un resultado incompleto. Supongamos que una skill prepara un mensaje correctamente, pero falla cuando existen dos contactos con el mismo nombre. La traza revela que el plan seleccionó el primer resultado sin pedir una aclaración. La propuesta mínima puede añadir una regla: cuando haya varios contactos compatibles, mostrar las opciones y solicitar la elección del usuario.

Ese cambio no necesita reentrenar Claude, Gemini u otro modelo configurado. Modifica la forma en que FoneClaw presenta el contexto, valida la selección y recupera el flujo. La nueva versión debe probar el contacto único, los duplicados, la ausencia de coincidencias y la cancelación. También debe confirmar que el permiso de contactos no se amplió y que el envío sigue requiriendo la decisión prevista.

La mejora conserva los controles de Android. Una skill más precisa no recibe automáticamente acceso a otra aplicación, nuevos datos o una acción más sensible. Los permisos continúan ligados a las capacidades disponibles y la confirmación permanece en el punto correspondiente. Para profundizar en esta relación, consulte Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real.

Cuando un recorrido no puede completarse, FoneClaw mantiene el trabajo útil y ofrece una alternativa práctica. Esa respuesta también alimenta futuras mejoras: una secuencia repetida de pasos manuales puede indicar que la skill necesita una ruta de recuperación mejor definida, siempre dentro de las acciones compatibles.

Del fallo observado a una versión desplegable

Una mejora fiable necesita más que una propuesta acertada. Debe recorrer una cadena en la que cada etapa responda una pregunta: ¿el fallo es real?, ¿el cambio es mínimo?, ¿se mantienen los permisos?, ¿funciona fuera del ejemplo original? Solo después se convierte en una versión candidata.

1. Evidencia: reunir trazas, estado de la aplicación, acción solicitada y resultado observado.
2. Clasificación: distinguir error de planificación, percepción, herramienta, permiso, aplicación o verificación.
3. Propuesta mínima: cambiar únicamente la regla, herramienta o recuperación necesaria.
4. Pruebas de regresión: ejecutar casos exitosos anteriores, el fallo original y nuevas variaciones.
5. Diferencia de permisos: comparar capacidades, aplicaciones y datos antes y después.
6. Aprobación: revisar evidencia, cambio, riesgos y puntos de confirmación.
7. Versión: asignar identificador, descripción, compatibilidad y ruta de reversión.
8. Despliegue gradual: habilitar la versión para un ámbito reducido antes de ampliarla.
9. Seguimiento: observar éxito, latencia, confirmaciones, fallos y recuperaciones.
10. Reversión: restaurar la versión anterior si aparecen regresiones o comportamiento inesperado.

La diferencia de permisos es una revisión independiente. Una propuesta que cambia cómo se busca un contacto no debería añadir acceso a mensajes, archivos o ubicación. Si necesita una capacidad nueva, esa ampliación debe quedar explícita, probarse por separado y presentarse al usuario cuando la tarea la requiera.

El despliegue gradual limita el alcance de una regresión. Una versión puede probarse primero con una aplicación, idioma o recorrido concreto. La monitorización debe comparar su comportamiento con la versión anterior: no solo cuántas tareas finaliza, sino cuántas veces pide confirmación correctamente, cuántos reintentos utiliza y si deja resultados parciales aprovechables.

El registro de versión debe relacionar la propuesta con la evidencia que la originó, las pruebas superadas y la persona o proceso que la aprobó. Esta trazabilidad complementa la arquitectura desarrollada en Identidad, permisos y auditoría de agentes IA: la capa de seguridad que necesita un teléfono.

Cuando una supuesta mejora crea un problema nuevo

La mejora automática puede equivocarse incluso cuando parece prudente. El estudio Phantom Guardrails de julio de 2026 describe un riesgo concreto: un optimizador puede inventar un fallo y añadir una protección innecesaria. Si el criterio de aceptación solo comprueba que la supuesta incidencia desapareció, la nueva regla puede aprobarse sin resolver un problema real.

Una protección fantasma puede bloquear tareas legítimas, añadir confirmaciones repetitivas o desviar el flujo hacia una ruta más lenta. Por eso, toda propuesta debe demostrar primero que el fallo existe y puede reproducirse. Después necesita pruebas positivas que confirmen que los casos normales siguen funcionando.

El sobreajuste aparece cuando una corrección memoriza el ejemplo. Si una app movió temporalmente un botón, fijar nuevas coordenadas puede resolver esa captura y fallar en otro tamaño de pantalla. Una mejora general busca el propósito del control, comprueba el estado y contempla alternativas. Las pruebas deben variar resolución, tamaño de texto, idioma y orden de los elementos.

Los cambios de interfaz también generan falsos diagnósticos. Una pantalla diferente puede proceder de una cuenta cerrada, una prueba regional o una actualización de la aplicación. Antes de modificar la skill, hay que identificar la causa. De lo contrario, el agente puede introducir una rama permanente para un estado que nunca volverá a aparecer.

La variación lingüística exige casos propios. Una instrucción válida en español puede activar otra interpretación en inglés, o una etiqueta localizada puede no coincidir con el selector esperado. Probar únicamente el idioma del fallo original no demuestra que la versión sea estable.

Por último, el permission drift ocurre cuando sucesivas correcciones amplían poco a poco la autoridad. Cada cambio aislado puede parecer menor, pero el conjunto termina ofreciendo más acceso del necesario. La comparación de permisos por versión y los límites del sistema siguen siendo necesarios aunque la ejecución se realice en un entorno aislado, como explica Sandbox de agentes de IA y permisos del teléfono: por qué aún hacen falta límites.

Lista de control antes de llevar el cambio a Android

¿Cuándo está lista una mejora para uso real? La respuesta debe basarse en evidencia reproducible y no en que una única tarea haya terminado bien. Esta lista permite revisar una nueva versión de skill o harness antes de ampliar su despliegue.

La reversión debe estar preparada antes de desplegar. Incluye conservar la definición anterior de la skill, sus permisos, dependencias y compatibilidad. Si la versión nueva aumenta fallos, cambia confirmaciones o produce resultados ambiguos, el agente vuelve a la versión estable y mantiene las trazas necesarias para investigar.

También conviene definir umbrales. Un cambio puede mejorar la tasa de finalización y empeorar mucho la latencia, los reintentos o la intervención requerida. La aceptación debe equilibrar éxito, tiempo, coste, claridad y autoridad. Una ganancia pequeña no compensa una expansión de permisos ni una recuperación menos fiable.

FoneClaw aplica este enfoque para mejorar su planificación, su harness y sus skills reutilizables manteniendo la arquitectura esencial: el modelo configurado entiende y planifica; FoneClaw realiza acciones Android compatibles con resultados visibles, permisos, confirmación y alternativas prácticas. La mejora se convierte así en una disciplina operativa, no en una modificación silenciosa.

Un agente móvil que se mejora solo es útil cuando aprende sin perder control. Las versiones permiten saber qué cambió; las pruebas demuestran dónde funciona; el despliegue gradual limita el impacto, y la reversión devuelve rápidamente un comportamiento estable. Esa combinación permite evolucionar sobre evidencia mientras Android y el usuario conservan la autoridad final.