Kimi Code v0.34 stellt Computer Use seit dem 6. August 2026 für Windows x64 bereit. Unterstützt werden Windows 10 ab Version 1903 beziehungsweise Build 18362 sowie Windows 11. Die Funktion läuft als offizielles Kimi-Code-Plugin und benötigt nach der Installation einen Neustart oder Reload.
Computer Use erlaubt einem KI-Agenten, Desktop-Anwendungen über Klicks, Ziehen, Scrollen und Texteingaben zu bedienen. Damit wird Software erreichbar, die keine geeignete API oder Kommandozeile besitzt. Für Unternehmen ist das vor allem bei Legacy-Anwendungen interessant – zugleich ist die grafische Bedienung fehleranfälliger als eine klar definierte Schnittstelle.
Was die Windows-Version technisch voraussetzt
Die Funktion benötigt einen interaktiven Desktop. Auf Windows Server ist dafür Desktop Experience erforderlich. Während einer Aktion kann das Plugin kurz die reale Maus und Tastatur übernehmen und die Zielanwendung in den Vordergrund holen. Das hat praktische Folgen: Der Arbeitsplatz ist während des Laufs nicht wie gewohnt parallel nutzbar, und unbeabsichtigte Eingaben können den Ablauf beeinflussen.
Läuft eine Zielanwendung mit Administratorrechten, benötigt auch das Plugin dasselbe Berechtigungsniveau. Technisch kann das notwendig sein, sicherheitlich vergrößert es jedoch den möglichen Schaden eines Fehlers. Unternehmen sollten deshalb nicht den gesamten Arbeitsplatz pauschal höher privilegieren, sondern zunächst Prozesse und Anwendungen auswählen, die mit Standardrechten funktionieren.
Offizielle Einsatzbeispiele umfassen das Zusammenführen verteilter Informationen in Notizen oder Tabellen, das Durchlaufen und Dokumentieren von App-Flows, wiederkehrende Kopier- und Prüfaufgaben, klar definierte Schrittfolgen sowie die Bedienung von Software ohne API oder Kommandozeile. Diese Beispiele belegen mögliche Bedienpfade, nicht deren Wirtschaftlichkeit oder Fehlerfreiheit im eigenen Prozess.
Welche Aufgaben sich für einen ersten Pilot eignen
- Wiederholbare Datenerfassung aus einer internen Anwendung in eine vorbereitete Tabelle.
- Dokumentation eines festen App-Ablaufs in einer isolierten Testumgebung.
- Vergleich sichtbarer Felder mit einer klaren Soll-Liste ohne automatische Änderung.
- Kopieraufgaben mit begrenztem Arbeitsordner und vollständig prüfbarem Ergebnis.
- Seltene Legacy-Prozesse, bei denen eine eigene API-Integration unverhältnismäßig wäre.
- Machbarkeitsproben, bevor ein stabilerer Workflow oder eine Schnittstelle gebaut wird.
Nicht geeignet sind nach der Kimi-Dokumentation Zahlungen, Überweisungen, das Löschen wichtiger Dateien, Passwortänderungen oder das Veröffentlichen von Inhalten. Diese Grenze sollte nicht durch zusätzliche Bestätigungsdialoge schöngerechnet werden. Bei finanziellen, rechtlichen oder reputativen Folgen bleibt ein Desktop-Agent ein ungeeigneter autonomer Entscheider.
Sicherheitscheckliste für Rechte und Arbeitsumgebung
- Einen separaten Testnutzer ohne lokale Administratorrechte verwenden.
- Erlaubte Anwendungen, Fenster, Ordner und Dateitypen vor dem Lauf festlegen.
- Produktivdaten vermeiden oder geeignete Test- und pseudonymisierte Daten einsetzen.
- Schreibrechte auf den kleinsten notwendigen Arbeitsbereich begrenzen.
- Zahlungen, Löschvorgänge, Passwortänderungen und Veröffentlichungen technisch ausschließen.
- Jeden Lauf mit Eingabe, erwarteten Schritten, Ergebnis und Abweichungen protokollieren.
- Einen jederzeit erreichbaren Abbruchweg und eine verantwortliche Person benennen.
- Für jede kritische Änderung eine separate menschliche Freigabe verlangen.
Minimale Rechte sind nicht nur eine Compliance-Maßnahme. Sie vereinfachen auch die Fehlersuche: Wenn ein Prozess ausschließlich einen festgelegten Ordner und eine Anwendung erreichen kann, lässt sich das Ergebnis leichter prüfen. Administratorrechte sollten nur für einen klar begründeten Testfall vergeben und anschließend wieder entzogen werden.
Pilotablauf mit Zustandsprüfungen statt blindem Durchklicken
Ein guter Pilot beginnt mit einem wiederholbaren Prozess und einem eindeutigen Soll-Ergebnis. Vor jedem Schritt wird festgelegt, woran der korrekte Zustand erkennbar ist. Nach der Aktion prüft der Ablauf, ob das erwartete Fenster, Feld oder Dokument tatsächlich vorhanden ist. Bei Abweichungen wird beendet und eskaliert, statt mit dem nächsten Klick fortzufahren.
Benutzeroberflächen ändern sich, Fenster können verdeckt sein und Ladezeiten variieren. Deshalb sollten Aufgaben in kleine Pakete zerlegt werden. Zeitlimits, begrenzte Wiederholungen und sichtbare Zwischenstände verhindern, dass ein hängender oder falsch positionierter Ablauf unkontrolliert weiterarbeitet.
- Soll-Ablauf und Abnahmekriterien anhand eines Testkontos dokumentieren.
- Erlaubte Programme und Aktionen technisch und organisatorisch begrenzen.
- Den Prozess zunächst beobachtet mit wenigen Datensätzen ausführen.
- Fehlerfälle wie verdeckte Fenster, Verzögerungen und unerwartete Dialoge gezielt testen.
- Zeitgewinn, Korrekturaufwand, Fehlerrate und menschliche Eingriffe messen.
- Erst nach bestandenem Test über einen begrenzten produktiven Einsatz entscheiden.
Updates und Betrieb nicht vergessen
Offizielle Plugins aktualisieren sich laut Dokumentation nicht automatisch. Bei einer neuen Version wird der Nutzer informiert und muss die Installation erneut anstoßen. Für Unternehmen folgt daraus ein kontrollierter Updateprozess: Version dokumentieren, Änderung prüfen, Testfälle erneut ausführen und erst danach produktive Arbeitsplätze aktualisieren.
Die GNS-Einordnung lautet: Kimi Code Computer Use kann eine praktische Brücke zu Windows- und Legacy-Software sein. Es ist aber kein Ersatz für stabile Schnittstellen bei hohem Volumen, sensiblen Daten oder schwer reversiblen Aktionen. Der richtige Start ist ein kleiner, sichtbarer und jederzeit abbrechbarer Prozess mit minimalen Rechten.