DeskVNC DeskVNC

title: "Las máquinas que se niegan a instalar agentes son justo las que un agente debería poder tocar" description: "Citrix, VDI, hosts de salto y los equipos propiedad del cliente rechazan de forma unánime cualquier runtime nuevo en la máquina controlada. DeskVNC lleva al agente de IA hasta ellas por el protocolo que ya hablan, sin instalar nada en el extremo y con una persona siempre lista para recuperar el control." date: 2026-10-09 tags: ["escritorio-remoto", "ia-agente", "mcp", "vnc", "rdp", "ssh", "citrix", "vdi"]

Una granja Citrix a la que solo se entra por RDP. Un host de salto que no admite servicios nuevos. Un portátil propiedad del cliente cuyo departamento de TI solo autoriza en la lista blanca las herramientas estándar de asistencia remota. Tres máquinas que parecen distintas y, sin embargo, coinciden en un único punto: la máquina controlada rechaza la instalación de cualquier runtime nuevo.

Esa coincidencia resulta incómoda, porque ese conjunto es precisamente el que la mayoría de los proyectos de automatización querría tocar. Las plataformas RPA instalan un pequeño servicio residente que toma capturas, escucha eventos de entrada y devuelve datos al plano de control. En el portátil del desarrollador funciona muy bien. En producción choca contra una pared tras otra. El rechazo a instalar en el extremo no es una excepción, es la postura por defecto del endpoint productivo más habitual en entornos regulados.

La paradoja lleva tiempo lastrando al sector: cuando se pide automatizar con un agente, las máquinas más interesantes son, justo, las más difíciles de alcanzar. La puerta está en el protocolo.

Las seis máquinas que rechazan a los agentes de instalación

A primera vista son entornos distintos. La conclusión es la misma: la máquina controlada no acepta software nuevo. DeskVNC reduce la lista de máquinas "no automatizables" hasta casi vaciarla.

Aplicaciones publicadas de Citrix y RemoteApp. Lo que el usuario ve en su terminal es la ventana de una sola aplicación, mientras que los procesos, el sistema de archivos, el portapapeles y la GPU se ejecutan en el host Citrix del centro de datos. La máquina controlada simplemente no existe. El terminal es un mero renderizador, el host está compartido, la directiva de grupo lo bloquea y el equipo de gestión de imágenes no autoriza un runtime de RPA.

Escritorios VDI agrupados. Cada vez que el usuario inicia sesión recibe un escritorio recién derivado de la imagen maestra y, al cerrar sesión, lo devuelve. Los perfiles de usuario se redirigen y el disco es no persistente por diseño. Lo que se instale del lado del usuario se va con la sesión; lo que se instale del lado del sistema infringe la línea base de la imagen.

Hosts de salto y puertas fortaleza. El trabajo de un host de salto es, precisamente, rechazar. Solo deja pasar los protocolos que ha elegido el equipo de seguridad. En cuanto se permite instalar software nuevo, deja de ser host de salto y la superficie auditada se dispara.

Estaciones de trabajo propiedad del cliente y con gestión estricta. El departamento de TI del cliente gestiona la lista blanca de aplicaciones, ejecuta AppLocker o MDM, retira los derechos de administrador local y bloquea binarios desconocidos. Para que un proveedor instale algo hace falta una compra negociada durante meses.

Quioscos y reemplazos de shell. La máquina completa se reconfigura para ejecutar solo una aplicación o una sola página web, sin mostrar nada más. Explorer se sustituye, el Administrador de tareas se desactiva, las imágenes firmadas se entregan por el cauce establecido. Una shell que permita arrancar otro binario ya no es la shell del quiosco.

Imágenes de servidor bloqueadas. Muchas veces Windows Server Core, sin escritorio y sin Explorer, con un conjunto muy seleccionado de herramientas administrativas y una directiva local que prohíbe instalar software de agente. Incluso en la versión con "experiencia de escritorio", el comité de control de cambios rechaza la solicitud.

Cómo el camino del protocolo conecta cada una de estas máquinas

Las seis categorías anteriores, por diseño o por cumplimiento, escuchan un único protocolo que ya aceptan. El host Citrix abre RDP para operaciones, y los servidores VNC llegan con la imagen. El host de salto permite SSH. En el portátil del cliente, su propio departamento de TI ya abrió el camino de la asistencia remota con la herramienta estándar. La imagen del quiosco trae RDP de fábrica para sus operadores. El servidor bloqueado se gestiona, por definición, con RDP, WinRM o SSH.

El plano de control dvv de DeskVNC habla directamente esos tres protocolos. En la máquina controlada no instala nada. En el cliente no introduce procesos nuevos. Persona y agente miran el mismo fotograma, porque así se construyó. El modelo de concesión es por sesión y siempre revocable: cuando el operador hace clic en la ventana desde la máquina controlada, el control pasa del agente a la persona, el siguiente dvv_click devuelve LEASE_REVOKED y el agente entiende al instante que debe detenerse. El agente no toma el control al operador, sino que fue diseñado desde el inicio para cedérselo.

Esta es la versión en lenguaje de ingeniería de la frase del README:

Las herramientas financiadas que permiten a un agente usar un escritorio de Windows instalan todas un agente en ese escritorio, lo que se rechaza en Citrix, en VDI, en hosts de salto y en cualquier máquina propiedad del cliente. Un protocolo que esas máquinas ya hablan, en cambio, sí pasa.

El bucle observar y actuar, con JSON real y reproducible

El servidor MCP dvv se ejecuta en el mismo proceso que el cliente DeskVNC. El cliente sostiene la conexión con el extremo y el agente solo decide qué tecla pulsar y qué coordenada clicar. Cada clic lleva un generation leído de la última captura. Los clics calculados a partir de una pantalla caducada se rechazan antes de llegar a la capa de protocolo, lo que evita el accidente de pulsar donde uno pensaba que estaba, tanto en el agente como en el extremo.

dvv_hosts lista lo que se puede abrir. dvv_open con perceive: true deja listos, en una sola llamada, la conexión, la imagen y el estado. dvv_control obtiene una concesión exclusiva de entrada. A partir de ahí el agente entra en un bucle estable de dos llamadas: mirar, mover. Mirar otra vez, mover otra vez. La primera llamada abre la máquina; las siguientes mantienen el bucle en marcha sin interrupciones.

dvv_hosts   {}                                    // what there is to open
dvv_open    {"hostId": "<id>", "perceive": true}  // -> limbId, size, state
dvv_control {"limbId": "...", "action": "acquire"}
dvv_screen  {"limbId": "...", "form": "full", "scale": 0.25}
dvv_click   {"limbId": "...", "x": 700, "y": 400, "generation": 1}
dvv_screen  {"limbId": "...", "form": "damage-crop"}  // look again
dvv_type    {"limbId": "...", "text": "notepad", "wpm": 3000}
dvv_key     {"limbId": "...", "keys": "meta+r"}

Los agentes que no tienen herramientas MCP cuentan con un camino equivalente desde la línea de comandos tras ejecutar dvv setup:

dvv hosts
dvv limbs
dvv open <name or hostId> --perceive
dvv wait <limbId> --until connected
dvv control acquire <limbId>
dvv screen <limbId> --scale 0.5 --out ./dvv-screen.png
dvv click <limbId> <x> <y>
dvv click <limbId> <x> <y> --action double
dvv type <limbId> "text to type"
dvv key <limbId> super+r
dvv wait <limbId> --until screen-stable
dvv reconnect <limbId>
dvv close <limbId>

Cada máquina es un limb independiente con su propia concesión: diez máquinas equivalen a diez bucles que no se interfieren. dvv_limbs los lista en cualquier momento, dvv_reconnect los recupera tras una caída de la red y dvv_close los devuelve al reposo. dvv_screen imprime una línea imageSpace que aclara la conversión entre coordenadas reducidas y reales. Con --scale 0.5, un punto (mx, my) en la imagen equivale a (mx2, my2) en la máquina. Si el agente olvida esa conversión, o si la pantalla cambió de tamaño desde que calculó la coordenada, el clic se rechaza por GEOMETRY_CHANGED y no entrega nada.

El generation es una valla de seguridad a nivel de máquina de estados. El bucle interno del agente tiene tres pasos: mirar, decidir, mover. Si el tercer paso se dispara contra un mundo que ya no existe, las consecuencias son serias. El generation es un entero monótono que viaja con cada fotograma; la siguiente entrada debe llevarlo de vuelta. En cuanto la pantalla avanza, los clics calculados con un generation antiguo se rechazan, el agente vuelve a leer y recomputa. La valla no necesita modelos adicionales de visión ni de planificación: basta con dos enteros presentes en cada llamada.

Números medidos

Los siguientes números proceden de la batería publicada por el proyecto, medidos sobre un escritorio Windows real a 1920x1080 a través de la LAN:

El número 19 ms se destaca por una razón clara: está fuera de escala con el coste del bucle externo del agente, la llamada al modelo de lenguaje (cientos de milisegundos en el extremo bajo, segundos en el alto). Con un bucle interno de 19 ms, el modelo puede intercalar docenas de acciones entre dos razonamientos. El agente no necesita "esperar la pantalla" ni cae en la espera lenta que sufre una persona delante de un VNC lento.

El bucle interno de 19 ms es más corto que el viaje redondo perceptual humano entre pulsar y ver el siguiente repintado. El agente no imita a una persona, ejecuta un bucle que esta no puede cerrar.

Registrar el servidor MCP dvv en el agente

El paquete del cliente DeskVNC incluye ya el servidor dvv y la descripción de la habilidad que lo documenta. En el repositorio, skills/deskvnc/SKILL.md es el punto de entrada que recorre un agente al escanear un directorio de habilidades, lo que deja desde el inicio un conducto para que el agente descubra esta capacidad por sí solo.

El registro en un cliente MCP habitual se reduce a dos pasos. Primero, se instala el cliente en el lado del operador, ya sea Windows, macOS o Linux. Las credenciales quedan a cargo del llavero del sistema operativo, así que el estado inicial ya es seguro. Segundo, se registra dvv como servidor MCP en la configuración del agente. En la mayoría de los casos basta con una línea de stdio, con la ruta del ejecutable correspondiente: en Windows, %LOCALAPPDATA%\DeskVNCViewer\dvv.exe o C:\Program Files\DeskVNCViewer\dvv.exe; en macOS, /Applications/DeskVNCViewer.app/Contents/MacOS/dvv; en Linux, /usr/bin/dvv.

Tras el registro, el agente ve el conjunto completo de herramientas dvv_*: dvv_hosts y dvv_limbs para descubrir, dvv_open para abrir, dvv_wait para esperar a que la conexión esté lista, dvv_control para tomar la concesión, dvv_screen para mirar, dvv_click, dvv_type y dvv_key para actuar, dvv_status para consultar el estado sin leer un solo píxel, dvv_signals para ver las señales negociadas, dvv_reconnect y dvv_close para cerrar el ciclo. Añádanse dvv_files y dvv_clipboard para archivos y portapapeles, dvv_term_read, dvv_term_send y dvv_run para el terminal y los comandos, y, con el prefijo dvv_group_, un lote de herramientas para tratar varias máquinas como un único conjunto. Todo funciona desde el primer momento.

Los códigos de error que el agente debe manejar dentro del bucle son cuatro, todos verificados contra el manifiesto. LIMB_GONE significa que el limb se ha perdido; se vuelve a listar con dvv_limbs y se reabre. GEOMETRY_CHANGED significa que la pantalla cambió de tamaño desde que se calculó la coordenada; se vuelve a mirar y se reintenta. SCREEN_CHANGED significa que algo se repintó desde la última lectura de píxeles; se lee de nuevo y se reintenta. LEASE_REVOKED significa que una persona recuperó el control, que es justo el comportamiento previsto, y ahí la única respuesta correcta es detenerse.

El límite del conjunto

La máquina controlada rechaza la instalación de nuevos runtimes por defecto. Sin embargo, en todo entorno que rechaza la instalación queda siempre un protocolo de visualización o de terminal por el que pasan sus propios operadores. Ese protocolo es el pilar de carga del modelo de seguridad: el equipo de seguridad lo confía, el equipo de auditoría ya lo aprobó y el comité de cambios ya lo autorizó. Un agente que habla ese protocolo entra por la puerta que la máquina controlada ya tenía abierta. Un agente que pide instalar algo nuevo obliga a reabrir la superficie que el equipo de seguridad tardó años en reducir. El primero escala, el segundo no.

El cliente DeskVNC es una aplicación nativa escrita en Rust sobre Tauri 2, disponible para Windows, macOS y Linux, publicada bajo la doble licencia MIT OR Apache-2.0. La conjunción del servidor MCP dvv, la ausencia total de instalación en el extremo y la posibilidad de que una persona recupere el control en cualquier momento es la forma de ingeniería del camino por el protocolo.

El tercer elemento es clave. Precisamente porque una persona puede recuperar el control cuando quiera, la automatización se asienta sobre un hecho obvio: alguien está usando la máquina de alguien. El agente no es el protagonista, es el invitado. El invitado se mueve con la pantalla prestada por el dueño y, cuando el dueño vuelve, le cede el asiento. Hacer esto bien, y hacerlo rápido, basta para que la mayoría de las máquinas que rechazan la instalación dejen de ser máquinas no automatizables.

El repositorio está en github.com/psmux/DeskVNC. Los recursos adicionales para la comunidad hispanohablante están en deskvnc-hub.pages.dev.