DeskVNC DeskVNC

title: "Die Maschinen, die keine Agenten installieren, sind genau die, die ein Agent erreichen muss" description: "Citrix, VDI, Sprungserver und kundeneigene Arbeitsplätze verweigern einhellig jede neue Laufzeitumgebung auf der gesteuerten Maschine. DeskVNC bringt den KI-Agenten über genau das Protokoll dorthin, das diese Maschinen ohnehin sprechen, ohne Installation am Endpunkt und mit der Möglichkeit, dass eine Person jederzeit die Steuerung übernimmt." date: 2026-10-09 tags: ["remote-desktop", "ki-agent", "mcp", "vnc", "rdp", "ssh", "citrix", "vdi"]

Eine Citrix-Farm, in die man ausschließlich per RDP hineinkommt. Ein Sprungserver, der keine neuen Dienste zulässt. Ein kundeneigener Laptop, auf dessen Whitelist nur die Standardwerkzeuge für Remote-Support stehen. Drei Maschinen, die unterschiedlich wirken und sich dennoch in einem einzigen Punkt einig sind: Die gesteuerte Maschine verweigert die Installation jeder neuen Laufzeitumgebung.

Diese Einigkeit ist unangenehm, denn genau diese Gruppe ist es, die die meisten Automatisierungsprojekte erreichen wollen. RPA-Plattformen installieren einen kleinen residenten Dienst, der Screenshots anfertigt, Eingabeereignisse abhört und Daten an die Steuerebene zurückspielt. Auf dem Entwicklerlaptop funktioniert das hervorragend. In der Produktion stößt es immer wieder an dieselbe Wand. Die Verweigerung der Installation am Endpunkt ist keine Ausnahme, sondern die Standardhaltung des produktiven Endpunkts in regulierten und ausgereiften Umgebungen.

Die Paradoxie hat die Branche lange belastet: Sobald man Automatisierung mit einem Agenten verlangt, sind die interessantesten Maschinen ausgerechnet die am schwierigsten zu erreichenden. Die Tür, die diese Wand durchbricht, liegt anderswo.

Die Tür liegt im Protokoll. Wir öffnen sie Schritt für Schritt.

Sechs Maschinen, die installierende Agenten abweisen

Auf den ersten Blick sind es unterschiedliche Umgebungen. Die Schlussfolgerung ist dieselbe: Die gesteuerte Maschine nimmt keine neue Software an. RPA-Werkzeuge haben jahrelang die Welt in zwei Listen geteilt, "Maschinen, auf denen man installieren darf" und "Boxen, auf denen man es nicht darf", und die zweite in die Kategorie "nicht automatisierbar" verschoben. DeskVNC schrumpft diese zweite Liste auf nahezu leer.

Veröffentlichte Citrix-Anwendungen und RemoteApp. Was der Anwender auf seinem Endgerät sieht, ist das Fenster einer einzigen Anwendung, während Prozesse, Dateisystem, Zwischenablage und GPU auf dem Citrix-Host im Rechenzentrum laufen. Die gesteuerte Maschine existiert schlicht nicht, es gibt keine "jenes Gerät", auf dem man installieren könnte. Das Endgerät ist ein reiner Renderer, der Host ist geteilt, die Gruppenrichtlinie sperrt ab, und das Imaging-Team lässt keine RPA-Laufzeit zu.

Gepoolte VDI-Desktops. Bei jeder Anmeldung erhält der Anwender einen neuen Desktop, abgeleitet aus dem Goldimage, und gibt ihn beim Abmelden wieder zurück. Benutzerprofile werden umgeleitet, die Festplatte ist konstruktionsbedingt nicht persistent. Was auf der Benutzerseite installiert wird, verschwindet mit der Sitzung; was auf der Systemseite installiert wird, verstößt gegen die Image-Basislinie.

Sprungserver und Bastion-Gateways. Die Aufgabe eines Sprungsservers besteht genau darin, abzuweisen. Nur die Protokolle, die das Sicherheitsteam ausgewählt hat, kommen durch. Sobald man neue Software installieren darf, ist es kein Sprungserver mehr, und die Auditfläche wächst über Nacht.

Kundeneigene, streng verwaltete Arbeitsplätze. Die IT-Abteilung des Kunden führt die Anwendungswhitelist, betreibt AppLocker oder MDM, entzieht lokale Administratorrechte und blockiert unbekannte Binärdateien. Soll ein Dienstleister etwas installieren, ist eine monatelange Beschaffungsverhandlung nötig.

Kioske und Shell-Ersetzungen. Die gesamte Maschine ist so umgebaut, dass sie nur eine Anwendung oder eine einzige Webseite ausführt und nichts anderes anzeigt. Explorer wird ersetzt, der Task-Manager abgeschaltet, signierte Images werden über den regulären Verteilungsweg ausgeliefert. Eine Shell, die eine andere Binärdatei starten lässt, ist nicht mehr die Shell des Kiosks.

Abgeriegelte Serverimages. Häufig Windows Server Core, ohne Desktop, ohne Explorer, mit einer kleinen Auswahl an Verwaltungswerkzeugen und einer lokalen Richtlinie, die die Installation von Agent-Software ausdrücklich verbietet. Selbst in der Variante mit Desktop-Erfahrung weist das Change-Advisory-Board den Antrag zurück.

Wie der Protokollweg jede dieser Maschinen anschließt

Die sechs genannten Kategorien hören, ob aus Design oder aus Compliance, jeweils genau ein Anzeige- oder Terminalprotokoll ab, das sie ohnehin akzeptieren. Der Citrix-Host öffnet RDP für den Betrieb, und VNC-Server werden mit dem Image ausgeliefert. Der Sprungserver lässt SSH durch. Auf dem Laptop des Kunden hat dessen IT-Abteilung den Remote-Support-Pfad bereits über das Standardwerkzeug geöffnet. Das Kiosk-Image bringt RDP für die Betreiber bereits mit. Der abgeriegelte Server wird per Definition über RDP, WinRM oder SSH verwaltet.

Die Steuerebene dvv von DeskVNC spricht diese drei Protokolle direkt. Auf der gesteuerten Maschine installiert sie nichts. Auf der Clientseite führt sie keine neuen Prozesse ein. Mensch und Agent betrachten denselben Frame, so ist es konstruiert. Das Lease-Modell ist sitzungsbasiert und jederzeit widerrufbar: Sobald die Bedienperson am Endpunkt ins Fenster klickt, geht die Steuerung vom Agenten an die Person über, der nächste dvv_click liefert LEASE_REVOKED, und der Agent erkennt sofort, dass er zu stoppen hat. Der Agent entreißt der Bedienperson nicht die Steuerung, sondern wurde von Anfang an dafür gebaut, sie ihr zu überlassen. Wessen Bildschirm es ist, bleibt jederzeit klar.

Das ist die in Ingenieurssprache übersetzte Fassung des Satzes aus dem README:

Die finanzierten Werkzeuge, die einem Agenten die Nutzung eines Windows-Desktops erlauben, installieren alle einen Agenten auf diesem Desktop, was auf Citrix, auf VDI, auf Sprungservern und auf jeder kundeneigenen Maschine verweigert wird. Ein Protokoll jedoch, das diese Maschinen bereits sprechen, kommt durch.

Die Beobachten-und-Handeln-Schleife, mit echtem JSON

Der MCP-Server dvv läuft im selben Prozess wie der DeskVNC-Client. Der Client hält die Verbindung zum Endpunkt, der Agent entscheidet nur, welche Taste gedrückt und welche Koordinate angeklickt wird. Jeder Klick trägt ein generation, das aus dem letzten Screenshot gelesen wurde. Auf Basis eines veralteten Bildschirms berechnete Klicks werden abgewiesen, bevor sie die Protokollschicht erreichen, was den Unfall eines "Klicks an der gedachten Stelle" auf Agenten- wie auf Endpunktseite ausschließt.

dvv_hosts listet, was sich öffnen lässt. dvv_open mit perceive: true richtet Verbindung, Bild und Zustand in einem Aufruf ein. dvv_control holt ein exklusives Eingabe-Lease. Danach tritt der Agent in eine stabile Zwei-Aufruf-Schleife ein: schauen, handeln. Nochmals schauen, nochmals handeln. Der erste Aufruf öffnet die Maschine, die folgenden halten die Schleife ohne Unterbrechung am Laufen.

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

Agenten ohne MCP-Werkzeuge finden nach dvv setup einen gleichwertigen Weg über die Kommandozeile:

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>

Jede Maschine bildet einen eigenen Limb mit eigenem Lease: Zehn Maschinen sind zehn voneinander unabhängige Schleifen. dvv_screen gibt zusätzlich eine imageSpace-Zeile aus, die das Verhältnis zwischen skalierten und tatsächlichen Koordinaten beschreibt. Bei --scale 0.5 entspricht ein Punkt (mx, my) im Bild (mx2, my2) auf der Maschine. Vergisst der Agent diese Umrechnung, wird der Klick wegen geometrischer Inkohärenz abgewiesen, bevor er ausgeht.

generation ist ein Sicherheitszaun auf Ebene der Zustandsmaschine. Die innere Schleife des Agenten hat drei Schritte: schauen, entscheiden, handeln. Feuert der dritte Schritt gegen eine Welt, die es nicht mehr gibt, sind die Folgen gravierend. generation ist eine monotone Ganzzahl, die mit jedem Frame mitläuft; die nächste Eingabe muss sie zurücktragen. Sobald der Bildschirm fortschreitet, werden Klicks mit veraltetem generation abgewiesen, der Agent liest den Bildschirm neu und rechnet die Koordinaten nach. Der Zaun benötigt keine zusätzlichen Vision- oder Planungsmodelle: Es genügen zwei Ganzzahlen in jedem Aufruf.

Gemessene Zahlen

Die folgenden Werte stammen aus der vom Projekt veröffentlichten Benchmark-Suite, gemessen auf einem realen Windows-Desktop mit 1920x1080 über LAN:

Die Zahl 19 ms wird aus gutem Grund hervorgehoben: Sie liegt eine Größenordnung unter den Kosten der äußeren Schleife, also des Aufrufs des Sprachmodells (im unteren Bereich Hunderte Millisekunden, im oberen Sekunden). Mit einer inneren Schleife von 19 ms kann das Modell zwischen zwei Überlegungen Dutzende von Aktionen einschieben. Der Agent muss den Bildschirm nicht "abwarten" und verfällt auch nicht in jenes langsame Warten, das eine Person vor einem trägen VNC erlebt.

Die innere Schleife von 19 ms ist zudem kürzer als die menschliche Wahrnehmungs-Roundtrip-Zeit zwischen Klick und nächstem Repaint. Der Agent imitiert keine Person, sondern führt eine Schleife aus, die eine Person nicht schließen kann.

Den MCP-Server dvv im Agenten registrieren

Das Auslieferungspaket des DeskVNC-Clients enthält bereits den dvv-Server und die Skill-Beschreibung, die ihn dokumentiert. Im Repository ist skills/deskvnc/SKILL.md der Einstiegspunkt, den ein Agent beim Durchsuchen eines Skill-Verzeichnisses liest, sodass von Beginn an eine Leitung existiert, über die der Agent diese Fähigkeit selbst entdeckt.

Die Registrierung in einem üblichen MCP-Client läuft auf zwei Schritte hinaus. Erstens wird der Client auf der Bedienungsseite installiert, also Windows, macOS oder Linux. Anmeldedaten werden im Schlüsselbund des Betriebssystems hinterlegt, sodass der Ausgangszustand bereits sicher ist. Zweitens wird dvv als MCP-Server in der Konfiguration des Agenten registriert. In den meisten Fällen reicht eine Stdio-Zeile mit dem Pfad zur ausführbaren Datei des jeweiligen Systems: unter Windows %LOCALAPPDATA%\DeskVNCViewer\dvv.exe oder C:\Program Files\DeskVNCViewer\dvv.exe, unter macOS /Applications/DeskVNCViewer.app/Contents/MacOS/dvv, unter Linux /usr/bin/dvv.

Nach der Registrierung sieht der Agent eine Reihe von dvv_*-Werkzeugen, die Host-Erkennung, Verbindung, Leases, Screenshot, Klick, Texteingabe, Tasten, Zwischenablage, Dateien, Terminal-Lese- und -Schreiboperationen, SSH-Befehlsausführung und mit dem Präfix dvv_group_ einen Satz von Werkzeugen abdecken, die mehrere Maschinen als eine einzige ansprechen. Alles ist sofort einsatzbereit.

Die Fehlercodes, die der Agent innerhalb der Schleife behandeln muss, sind nur zwei. LIMB_GONE bedeutet, dass der Limb verloren ist; er wird mit dvv_limbs neu aufgelistet und wieder geöffnet. SCREEN_CHANGED bedeutet, dass der Bildschirm fortgeschritten ist; er wird neu gelesen und der Versuch wiederholt. Beide sind behebbar, und die einzig richtige Antwort lautet "anhalten und neu lesen".

Die Grenze des Ganzen

Die gesteuerte Maschine verweigert die Installation neuer Laufzeitumgebungen standardmäßig. Doch in jeder Umgebung, die Installationen verweigert, bleibt genau ein Anzeige- oder Terminalprotokoll übrig, über das die eigenen Betreiber sie erreichen. Dieses Protokoll ist der eigentliche tragende Balken des Sicherheitsmodells: Das Sicherheitsteam vertraut ihm, das Auditteam hat es bereits genehmigt, und das Change-Advisory-Board hat es bereits freigegeben. Ein Agent, der dieses Protokoll spricht, tritt durch die Tür ein, die die gesteuerte Maschine ohnehin offen hat. Ein Agent, der Installation verlangt, zwingt das Sicherheitsteam, die Oberfläche erneut zu öffnen, die es jahrelang verkleinert hat. Der erste skaliert, der zweite nicht.

Der DeskVNC-Client ist eine native Anwendung, geschrieben in Rust auf Tauri 2, verfügbar für Windows, macOS und Linux, veröffentlicht unter der Doppellizenz MIT OR Apache-2.0. Das Zusammenwirken des MCP-Servers dvv, der vollständigen Abwesenheit von Installation am Endpunkt und der Möglichkeit, dass eine Person jederzeit die Steuerung übernimmt, ist die ingenieurmäßige Form des Protokollwegs.

Das dritte Element ist entscheidend. Gerade weil eine Person jederzeit die Steuerung übernehmen kann, ruht die Automatisierung auf einer Selbstverständlichkeit: Jemand nutzt die Maschine von jemandem. Der Agent ist nicht die Hauptperson, er ist Gast. Der Gast bewegt sich auf dem Bildschirm des Eigentümers und räumt den Platz, sobald dieser zurückkehrt. Das richtig und schnell zu tun, reicht aus, damit die meisten Maschinen, die Installation verweigern, aufhören, nicht automatisierbar zu sein.

Das Repository liegt unter github.com/psmux/DeskVNC. Weiteres Material und Updates für die deutschsprachige Community finden sich unter deskvnc-hub.pages.dev.