Por qué los agentes de IA no deberían hacer clic en la pantalla: un plano de control local para una app de escritorio

En resumen

Lo tentador, para que un agente de IA use una app de escritorio, es dejarle mirar la pantalla y hacer clic, como haría una persona. En una app de vídeo, ese es el diseño equivocado. Los clics son frágiles, el agente llega a todo lo que alcanza un ratón y «hizo clic en Exportar» no demuestra que la exportación esté bien.

• Dejar que un agente de IA maneje una app de escritorio mirando capturas de pantalla y haciendo clic funciona en las demos, pero es frágil, lento y le concede al agente todo lo que puede hacer un ratón.
• KwaFlux ofrece en su lugar un plano de control estructurado: herramientas MCP tipadas, pocos parámetros por llamada y comprobaciones en la app antes de poner nada en la cola.
• El agente no escribe el trabajo completo. El proceso de trabajo de KwaFlux lo reconstruye con el mismo generador de trabajos que usa la app cuando usted hace clic en Exportar.
• Las reglas que comparte con la app se generan, no se copian, y las pruebas fallan si ambas versiones se separan.

KwaFlux va por el otro camino: un plano de control local que acepta peticiones tipadas, las comprueba y monta el trabajo real dentro de la app.

En esta guía verá por qué la automatización de pantalla se queda corta para esta tarea, cómo encajan las capas de KwaFlux, por qué el agente solo envía parámetros pequeños y qué es lo que este diseño no puede hacer, a propósito.

Contenido

1. ¿Qué es un plano de control para agentes de IA?
2. Automatización de pantalla frente a plano de control
3. Las capas, del chat al proceso de trabajo
4. Parámetros pequeños que reconstruye la app
5. Una sola fuente de reglas para la app y el agente
6. Qué comprueba el plano de control antes de encolar
7. Resultados en los que el agente puede confiar
8. A qué renuncia este diseño
9. Preguntas frecuentes

¿Qué es un plano de control para agentes de IA?

Un plano de control para agentes de IA es una interfaz programática y acotada que permite a un agente pedirle a una aplicación que haga cosas concretas, mientras la aplicación conserva la autoridad para comprobar, rechazar y ejecutar cada petición.

En KwaFlux, la interfaz es un conjunto de herramientas MCP y la autoridad reside en la app de escritorio en ejecución. El agente pide; KwaFlux decide.

Automatización de pantalla frente a plano de control

Los agentes de uso del ordenador que trabajan a partir de capturas de pantalla son un avance real, y para las apps sin API son la única opción. La propia documentación de Anthropic sobre su herramienta computer use habla con franqueza de sus límites. Señala que el modelo «a veces actúa como si sus acciones hubieran tenido éxito sin comprobar explícitamente sus resultados», que los menús desplegables y las barras de desplazamiento «pueden ser complicados» de manejar con el ratón y que las instrucciones de las páginas web o de las imágenes «podrían anular sus instrucciones». Recomienda ejecutar computer use en «una máquina virtual o un contenedor dedicados con privilegios mínimos».

En una app de vídeo instalada en su propio ordenador, como KwaFlux con su Reparación de calidad y sus herramientas de conversión, esos límites importan:

La última fila no es una competición de cifras exactas. Lo importante es que una llamada estructurada cuesta lo mismo tanto si la exportación tarda diez segundos como diez minutos, mientras que un agente que vigila la pantalla paga por cada vistazo.

Las capas, del chat al proceso de trabajo

Una petición atraviesa seis capas. Cada capa tiene una sola función y cualquiera de ellas puede decir que no.

1. El host de IA (Cursor, Claude, Codex y otros) arranca el servidor MCP de KwaFlux como un proceso local y se comunica con él por la entrada y la salida estándar.
2. El proceso MCP convierte las llamadas a herramientas en peticiones pequeñas y tipadas y comprueba las rutas igual que la app antes de tocar ningún archivo.
3. El canal local conecta el proceso MCP con la app en ejecución: una canalización con nombre para su cuenta de usuario en Windows y, en Mac, un socket que solo su cuenta puede abrir. Cada conexión empieza con un intercambio de token. El artículo sobre el canal local trata esta capa.
4. El plano de control de la app comprueba la petición: ¿la ruta es local y absoluta?, ¿el usuario ha iniciado sesión con el plan adecuado?, ¿la tarea pertenece a este agente?, ¿el agente está dentro de su límite de frecuencia?, ¿lo permite el ajuste de descargas?
5. El planificador pone el trabajo en la cola junto a los que usted lanzó en la ventana, de modo que comparten la misma GPU y la misma lista de tareas.
6. El proceso de trabajo monta el trabajo completo, verifica una concesión firmada para las funciones de pago, ejecuta el motor y escribe el resultado junto al archivo de origen.

Parámetros pequeños que reconstruye la app

Esta es la decisión que determina todo lo demás: el agente no envía una descripción completa del trabajo.

Un trabajo de exportación de KwaFlux tiene muchos campos: ajustes del decodificador, elección de modelos, tamaños de tesela, opciones del codificador, tratamiento del color y más. Si el agente pudiera enviar toda esa estructura, fallarían dos cosas. El modelo se inventaría valores que no puede comprobar, y cualquiera capaz de dirigir al modelo, mediante un nombre de archivo o una página web envenenados, podría llegar a todos los parámetros del motor.

Por eso cada herramienta recibe solo los pocos campos que elegiría una persona: el archivo de entrada, el módulo, un tamaño de salida de la lista de la app, un nivel de calidad, un intervalo de tiempo para un GIF. Después, el proceso de trabajo monta el trabajo completo con el mismo generador de trabajos que usa la app cuando usted hace clic en Exportar, y lo recorta al contrato de parámetros que el motor acepta en tiempo de ejecución.

El resultado es que un trabajo lanzado por el agente y uno lanzado con clics pasan por el mismo código a partir del generador. Lo describimos como «las mismas reglas de parámetros que la app», no como «una salida idéntica», porque algunas herramientas son más limitadas por MCP. El artículo sobre las capacidades recoge esas diferencias.

Una sola fuente de reglas para la app y el agente

Dos copias de las mismas reglas acaban separándose. KwaFlux evita mantener dos copias:

• El catálogo de módulos que ofrece MCP, con la ruta, los ajustes y los valores permitidos de cada módulo, se genera a partir del mismo archivo de configuración que las pantallas de la app. Las variantes para fotos salen de la sección de imagen de ese mismo archivo.
• Cinco conjuntos de reglas se traducen directamente del código fuente de la app para el servidor MCP: los niveles de resolución de salida, la elección de contenedor y códec del Compresor, los parámetros de algoritmo del espacio de trabajo de audio, la lista de voces del Cambio de voz IA y una regla de detección.
• Una prueba de deriva falla si cambia la versión de la app de cualquiera de esas reglas y la versión de MCP no se ha vuelto a generar.

La misma idea mantiene cortas las descripciones de las herramientas, como explica el artículo sobre el diseño de las herramientas.

Qué comprueba el plano de control antes de encolar

La especificación de MCP dice que los servidores deben («MUST») validar todas las entradas de las herramientas, implementar controles de acceso adecuados, limitar la frecuencia de las invocaciones y sanear las salidas de las herramientas. En KwaFlux esas comprobaciones están en la app, no en el script de MCP, para que otro cliente no pueda saltárselas:

Resultados en los que el agente puede confiar

Cada herramienta de KwaFlux declara un esquema de salida, así que el resultado son datos estructurados que el host puede validar, no un párrafo que el modelo tenga que interpretar. Cuando el host pasa un token de progreso, KwaFlux envía notificaciones de progreso mientras se ejecuta la tarea. Cuando el usuario detiene la petición en el host, KwaFlux deja de esperar y el agente puede cancelar la tarea.

Los resultados de las tareas solo dicen «salida lista» cuando una tarea ha terminado bien de verdad, e indican el nombre del archivo de salida. Una tarea en cola o fallida no afirma haber producido nada.

A qué renuncia este diseño

Un plano de control abarca solo lo que abarcan sus herramientas. Nueve funciones de KwaFlux necesitan que alguien dibuje sobre el fotograma, haga clic en un sujeto o valore una vista previa, como la eliminación de objetos y la sustitución del cielo. Podríamos haber dejado que el agente adivinara coordenadas, o haber aceptado una descripción de trabajo en bruto. Lo primero da resultados que nadie puede prever, con un justificante que dice que ha funcionado. Lo segundo elimina el límite que hace seguro el diseño. Por eso esas funciones se quedan en la app y el agente tiene instrucciones de remitir allí al usuario.

Es una decisión de producto, no un hueco que pensemos cerrar relajando las reglas.

Conclusión

Si un agente tiene que mirar píxeles para usar su app, usted no puede comprobar lo que está a punto de hacer. Un plano de control le da la vuelta a eso: el agente pide en un lenguaje acotado y tipado, y la app comprueba, monta y ejecuta el trabajo con su propio código. En KwaFlux, así es como una exportación lanzada por un agente pasa por el mismo generador de trabajos que una que usted lanza haciendo clic.

El servidor MCP local de KwaFlux permite que Codex, Claude, Cursor y otras apps MCP pongan trabajos reales en la cola de la app de escritorio. El procesamiento de IA corre en su propia GPU y sus archivos multimedia no se suben para procesarlos. Funciona en Windows 10 (64 bits, versión 1809 o posterior), Windows 11 y macOS 12 o posterior en Apple Silicon. Importar archivos y explorar la app no requieren cuenta. Iniciar sesión con un plan de pago solo hace falta para exportar, convertir, reparar un archivo o descargar un archivo desde un enlace.

Descargar KwaFlux · Ver planes