DeskVNC DeskVNC

title: "As máquinas que se recusam a instalar agentes são exatamente as que um agente deveria alcançar" description: "Citrix, VDI, jump hosts e estações de trabalho pertencentes ao cliente recusam de forma unânime qualquer runtime novo na máquina controlada. DeskVNC leva o agente de IA até elas pelo protocolo que elas já falam, sem instalar nada no endpoint e com uma pessoa sempre pronta para retomar o controle." date: 2026-10-09 tags: ["area-de-trabalho-remota", "agente-ia", "mcp", "vnc", "rdp", "ssh", "citrix", "vdi"]

Uma granja Citrix pela qual só se entra por RDP. Um jump host que não aceita nenhum serviço novo. Um notebook de propriedade do cliente cujo departamento de TI só mantém na lista branca as ferramentas padrão de suporte remoto. Três máquinas que parecem distintas e, ainda assim, concordam em um único ponto: a máquina controlada recusa a instalação de qualquer runtime novo.

Essa coincidência é incômoda, porque é exatamente esse o conjunto que a maioria dos projetos de automação gostaria de alcançar. Plataformas RPA instalam um pequeno serviço residente que tira screenshots, escuta eventos de entrada e devolve dados ao plano de controle. No notebook do desenvolvedor funciona muito bem; em produção, esbarra em uma parede atrás da outra. A recusa de instalar no endpoint não é exceção, é a postura padrão do endpoint produtivo em ambientes regulados.

A ironia tem pesado o setor: quando se pede automação com um agente, as máquinas mais interessantes são justamente as mais difíceis de alcançar. A porta para atravessar essa parede estava em outro lugar, e está no protocolo. Vamos abri-la passo a passo.

As seis máquinas que rejeitam agentes de instalação

À primeira vista são ambientes diferentes. A conclusão é a mesma: a máquina controlada não aceita software novo. Ferramentas de automação com RPA passaram anos separando o mundo em duas listas, "máquinas em que dá para instalar" e "caixas em que não dá", empurrando as segundas para a categoria de "não automatizáveis". DeskVNC reduz essa segunda lista até quase esvaziá-la.

Aplicativos publicados Citrix e RemoteApp. O que o usuário vê em seu terminal é a janela de um único aplicativo, enquanto processos, sistema de arquivos, área de transferência e GPU rodam no host Citrix do data center. A máquina controlada simplesmente não existe, não há "aquela máquina" na qual instalar. O terminal é um mero renderizador, o host é compartilhado, a diretiva de grupo trava e a equipe de gestão de imagens não autoriza um runtime de RPA.

Desktops VDI em pool. Cada vez que o usuário autentica recebe um desktop novinho, derivado da imagem mestra, e o devolve ao sair. Os perfis de usuário são redirecionados e o disco é não persistente por projeto. O que se instala do lado do usuário se vai com a sessão; o que se instala do lado do sistema infringe a linha de base da imagem.

Jump hosts e gateways bastião. O trabalho de um jump host é, justamente, recusar. Só passam os protocolos escolhidos pelo time de segurança. No instante em que se permite instalar software novo, ele deixa de ser jump host, e a superfície auditada dispara de um dia para o outro.

Estações de trabalho pertencentes ao cliente e geridas com rigor. O departamento de TI do cliente mantém a lista branca de aplicações, executa AppLocker ou MDM, remove direitos de administrador local e bloqueia binários desconhecidos. Para que um prestador instale algo é preciso uma negociação de meses.

Quiosques e substituições de shell. A máquina inteira é reconfigurada para rodar apenas um aplicativo ou uma única página web, sem mostrar mais nada. O Explorer é substituído, o gerenciador de tarefas é desativado, imagens assinadas são distribuídas pelo fluxo regular. Uma shell que permita iniciar outro binário já não é a shell do quiosque.

Imagens de servidor trancadas. Muitas vezes Windows Server Core, sem desktop, sem Explorer, com um conjunto bastante restrito de ferramentas administrativas e uma política local que proíbe explicitamente instalar software de agente. Mesmo na variante com "experiência de desktop", o comitê de mudanças rejeita o pedido.

Como o caminho do protocolo conecta cada uma dessas máquinas

As seis categorias acima escutam, seja por projeto, seja por compliance, um único protocolo de visualização ou de terminal que já aceitam. O host Citrix abre RDP para operação, e servidores VNC vêm com a imagem. O jump host libera SSH. No notebook do cliente, o próprio departamento de TI já abriu o caminho de suporte remoto pela ferramenta padrão. A imagem do quiosque traz RDP de fábrica para os operadores. O servidor trancado é gerenciado, por definição, via RDP, WinRM ou SSH.

O plano de controle dvv do DeskVNC fala diretamente esses três protocolos. Na máquina controlada não instala nada. No cliente não introduz processos novos. Pessoa e agente olham o mesmo frame, porque foi assim que se construiu. O modelo de lease é por sessão e sempre revogável: no instante em que o operador clica na janela a partir da máquina controlada, o controle passa do agente para a pessoa, o próximo dvv_click devolve LEASE_REVOKED, e o agente entende de imediato que deve parar. O agente não toma o controle do operador, foi projetado desde o início para cedê-lo. De quem é a tela fica sempre claro.

Esta é a versão em linguagem de engenharia da frase do README:

As ferramentas financiadas que permitem a um agente usar um desktop Windows instalam todas um agente nesse desktop, o que é recusado em Citrix, em VDI, em jump hosts e em qualquer máquina de propriedade do cliente. Um protocolo que essas máquinas já falam, em contrapartida, passa.

O laço observar e agir, com JSON real e reproduzível

O servidor MCP dvv roda no mesmo processo do cliente DeskVNC. O cliente sustenta a conexão com o endpoint e o agente só decide qual tecla pressionar e qual coordenada clicar. Cada clique carrega um generation lido do último screenshot. Cliques calculados a partir de uma tela vencida são rejeitados antes de alcançar a camada de protocolo, o que evita o acidente de clicar onde se pensava estar, tanto do lado do agente quanto do lado do endpoint.

dvv_hosts lista o que pode ser aberto. dvv_open com perceive: true deixa prontos, em uma única chamada, a conexão, a imagem e o estado. dvv_control obtém um lease exclusivo de entrada. A partir daí o agente entra em um laço estável de duas chamadas: olhar, mover. Olhar de novo, mover de novo. A primeira chamada abre a máquina; as seguintes mantêm o laço rodando sem interrupções.

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"}

Agentes que não dispõem de ferramentas MCP contam com um caminho equivalente pela linha de comando após executar 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 é um limb independente com lease próprio: dez máquinas equivalem a dez laços que não se interferem. dvv_screen imprime ainda uma linha imageSpace que esclarece a conversão entre coordenadas reduzidas e coordenadas reais da máquina. Com --scale 0.5, um ponto (mx, my) na imagem equivale a (mx2, my2) na máquina. Se o agente esquece essa conversão, o clique é rejeitado por incoerência geométrica antes de sair.

O generation é uma cerca de segurança no nível da máquina de estados. O laço interno do agente tem três passos: olhar, decidir, mover. Se o terceiro dispara contra um mundo que já não existe, as consequências são sérias. O generation é um inteiro monótono que viaja com cada frame; a próxima entrada precisa levá-lo de volta. Assim que a tela avança, cliques com generation antigo são rejeitados, o agente lê a tela de novo e recalcula as coordenadas. A cerca não precisa de modelos adicionais de visão nem de planejamento: bastam dois inteiros em cada chamada.

Números medidos

Os valores a seguir vêm da bateria de benchmarks publicada pelo projeto, medidos em um desktop Windows real a 1920x1080 através da LAN:

O número 19 ms se destaca por uma razão clara: está fora da escala do custo do laço externo do agente, ou seja, a chamada ao modelo de linguagem (centenas de milissegundos no extremo baixo, segundos no alto). Com um laço interno de 19 ms, o modelo consegue intercalar dezenas de ações entre dois raciocínios. O agente não precisa "esperar a tela" nem cai naquela espera lenta que uma pessoa sofre diante de um VNC lento.

O laço interno de 19 ms é mais curto que o round-trip perceptual humano entre clicar e ver o próximo repaint em uma sessão interativa. O agente não imita uma pessoa, executa um laço que uma pessoa não consegue fechar.

Registrando o servidor MCP dvv no agente

O pacote de distribuição do cliente DeskVNC já traz o servidor dvv e a descrição da skill que o documenta. No repositório, skills/deskvnc/SKILL.md é o ponto de entrada que um agente percorre ao varrer um diretório de skills, o que deixa desde o início um conduto para que o agente descubra essa capacidade por conta própria.

O registro em um cliente MCP comum se resume a dois passos. Primeiro, instala-se o cliente no lado do operador, seja Windows, macOS ou Linux. As credenciais ficam a cargo do chaveiro do sistema operacional, de modo que o estado inicial já é seguro. Segundo, registra-se dvv como servidor MCP no arquivo de configuração do agente. Na maioria dos casos basta uma linha de stdio com o caminho do executável correspondente a cada sistema: no Windows, %LOCALAPPDATA%\DeskVNCViewer\dvv.exe ou C:\Program Files\DeskVNCViewer\dvv.exe; no macOS, /Applications/DeskVNCViewer.app/Contents/MacOS/dvv; no Linux, /usr/bin/dvv.

Depois do registro, o agente vê um conjunto de ferramentas dvv_* que cobrem descoberta de hosts, conexão, leases, captura de tela, clique, digitação, teclas, área de transferência, arquivos, leitura e escrita do terminal, execução de comandos por SSH e, com o prefixo dvv_group_, um lote para tratar várias máquinas como um único conjunto. Tudo funciona desde o primeiro momento.

Os códigos de erro que o agente precisa tratar dentro do laço são apenas dois. LIMB_GONE significa que o limb se perdeu; lista-se de novo com dvv_limbs e reabre-se. SCREEN_CHANGED significa que a tela avançou; lê-se de novo e tenta-se outra vez. Ambos são recuperáveis e a única resposta correta é "parar e ler de novo".

A fronteira do conjunto

A máquina controlada recusa por padrão a instalação de runtimes novos. No entanto, em todo ambiente que recusa instalação fica sempre um protocolo de visualização ou de terminal pelo qual passam os seus próprios operadores. Esse protocolo é a viga de carga real do modelo de segurança: o time de segurança confia nele, o time de auditoria já o aprovou e o comitê de mudanças já o liberou. Um agente que fala esse protocolo entra pela porta que a máquina controlada já tinha aberta. Um agente que pede instalação força a reabertura da superfície que o time de segurança levou anos para encolher. O primeiro escala, o segundo não.

O cliente DeskVNC é um aplicativo nativo escrito em Rust sobre Tauri 2, disponível para Windows, macOS e Linux, publicado sob a licença dupla MIT OR Apache-2.0. A conjunção do servidor MCP dvv, da ausência total de instalação no endpoint e da possibilidade de uma pessoa retomar o controle a qualquer momento é a forma de engenharia do caminho pelo protocolo.

O terceiro elemento é chave. Justamente porque uma pessoa pode retomar o controle quando quiser, a automação se assenta sobre um fato óbvio: alguém está usando a máquina de alguém. O agente não é o protagonista, é o convidado. O convidado se move com a tela cedida pelo dono e, quando o dono volta, cede o assento. Fazer isso bem, e fazer rápido, basta para que a maioria das máquinas que recusam instalação deixe de ser "máquinas não automatizáveis".

O repositório está em github.com/psmux/DeskVNC. Recursos e atualizações adicionais para a comunidade lusófona estão em deskvnc-hub.pages.dev.