Warum KI-Agenten nicht auf den Bildschirm klicken sollten: eine lokale Steuerungsebene für eine Desktop-App

Kurz gesagt

Am naheliegendsten scheint es, einen KI-Agenten eine Desktop-App so bedienen zu lassen wie ein Mensch: auf den Bildschirm schauen und klicken. Für eine Video-App ist das der falsche Ansatz. Klicks sind fragil, der Agent erreicht alles, was eine Maus erreicht, und „er hat auf Exportieren geklickt“ beweist nicht, dass der Export stimmt.

• Einen KI-Agenten eine Desktop-App per Screenshot und Mausklick bedienen zu lassen, klappt in Demos, ist aber fragil und langsam und gibt dem Agenten alles in die Hand, was eine Maus erreicht.
• KwaFlux bietet stattdessen eine strukturierte Steuerungsebene: typisierte MCP-Tools, wenige Parameter pro Aufruf und Prüfungen in der App, bevor irgendetwas in die Warteschlange kommt.
• Der Agent schreibt nicht den kompletten Auftrag. Der KwaFlux-Worker baut ihn neu, mit demselben Auftragsbaustein, den die App beim Klick auf Exportieren nutzt.
• Regeln, die App und Agent teilen, werden generiert statt kopiert, und Tests schlagen fehl, sobald beide auseinanderlaufen.

KwaFlux geht den anderen Weg: eine lokale Steuerungsebene, die typisierte Anfragen annimmt, sie prüft und den eigentlichen Auftrag in der App baut.

In diesem Leitfaden erfahren Sie, warum Bildschirmautomatisierung für diese Aufgabe nicht reicht, wie die Schichten von KwaFlux ineinandergreifen, warum der Agent nur wenige Parameter schickt und was dieser Entwurf bewusst nicht kann.

Inhalt

1. Was ist eine Steuerungsebene für KI-Agenten?
2. Bildschirmautomatisierung oder Steuerungsebene
3. Die Schichten, vom Chat bis zum Worker
4. Wenige Parameter, von der App neu aufgebaut
5. Eine Regelquelle für App und Agent
6. Was die Steuerungsebene vor dem Einreihen prüft
7. Ergebnisse, auf die sich der Agent verlassen kann
8. Worauf dieser Entwurf verzichtet
9. Häufige Fragen

Was ist eine Steuerungsebene für KI-Agenten?

Eine Steuerungsebene (Control Plane) für KI-Agenten ist eine schmale, programmatische Schnittstelle, über die ein Agent eine Anwendung um bestimmte Dinge bitten kann, während die Anwendung die Hoheit behält, jede Anfrage zu prüfen, abzulehnen und auszuführen.

In KwaFlux besteht die Schnittstelle aus einer Reihe von MCP-Tools, und die Hoheit liegt bei der laufenden Desktop-App. Der Agent fragt; KwaFlux entscheidet.

Bildschirmautomatisierung oder Steuerungsebene

Computer-Use-Agenten, die mit Screenshots arbeiten, sind ein echter Fortschritt, und für Apps ohne API sind sie die einzige Möglichkeit. Anthropics eigene Dokumentation zum Computer-Use-Tool spricht die Grenzen offen an. Dort heißt es, das Modell handle „manchmal so, als seien seine Aktionen erfolgreich gewesen, ohne deren Ergebnisse ausdrücklich zu prüfen“, Dropdowns und Scrollbalken mit der Maus zu bedienen „könnte knifflig sein“, und Anweisungen auf Webseiten oder in Bildern „könnten Ihre Anweisungen außer Kraft setzen“. Empfohlen wird, Computer Use in „einer eigenen virtuellen Maschine oder einem Container mit minimalen Rechten“ zu betreiben.

Für eine Video-App auf Ihrem eigenen Computer, etwa KwaFlux mit seiner Qualitätsreparatur und seinen Konvertierungswerkzeugen, fallen diese Grenzen ins Gewicht:

In der letzten Zeile geht es nicht um einen Wettstreit exakter Zahlen. Entscheidend ist, dass ein strukturierter Aufruf gleich viel kostet, ob der Export zehn Sekunden oder zehn Minuten dauert, während ein Agent, der den Bildschirm beobachtet, für jeden Blick bezahlt.

Die Schichten, vom Chat bis zum Worker

Eine Anfrage durchläuft sechs Schichten. Jede Schicht hat eine Aufgabe, und jede kann Nein sagen.

1. Der KI-Host (Cursor, Claude, Codex und andere) startet den KwaFlux-MCP-Server als lokalen Prozess und spricht über Standardein- und -ausgabe mit ihm.
2. Der MCP-Prozess übersetzt Tool-Aufrufe in kleine typisierte Anfragen und prüft Pfade auf dieselbe Weise wie die App, bevor er eine Datei anfasst.
3. Der lokale Kanal verbindet den MCP-Prozess mit der laufenden App: unter Windows eine Named Pipe für Ihr Benutzerkonto, am Mac ein Socket, den nur Ihr Konto öffnen kann. Jede Verbindung beginnt mit einem Token-Handshake. Diese Schicht behandelt der Beitrag zum lokalen Kanal.
4. Die Steuerungsebene in der App prüft die Anfrage: Ist der Pfad lokal und absolut, ist der Nutzer mit dem passenden Plan angemeldet, gehört die Aufgabe diesem Agenten, hält der Agent sein Ratenlimit ein, lässt die Download-Einstellung es zu?
5. Der Scheduler reiht den Auftrag neben denen ein, die Sie im Fenster gestartet haben. Sie teilen sich also dieselbe GPU und dieselbe Aufgabenliste.
6. Der Worker baut den kompletten Auftrag, prüft bei kostenpflichtigen Funktionen eine signierte Lease, startet die Engine und schreibt das Ergebnis neben die Quelldatei.

Wenige Parameter, von der App neu aufgebaut

Eine Entscheidung prägt alles andere: Der Agent schickt keine komplette Auftragsbeschreibung.

Ein Exportauftrag in KwaFlux hat viele Felder: Decoder-Einstellungen, Modellwahl, Kachelgrößen, Encoder-Optionen, Farbbehandlung und mehr. Könnte der Agent diese ganze Struktur schicken, ginge zweierlei schief. Das Modell würde Werte erfinden, die es nicht prüfen kann, und wer das Modell lenken kann, etwa über einen manipulierten Dateinamen oder eine Webseite, käme an jeden Engine-Parameter heran.

Deshalb nimmt jedes Tool nur die wenigen Felder an, die auch ein Mensch wählen würde: die Eingabedatei, das Modul, eine Ausgabegröße aus der Liste der App, eine Qualitätsstufe, einen Zeitbereich für ein GIF. Der Worker baut daraus den kompletten Auftrag mit demselben Auftragsbaustein, den die App beim Klick auf Exportieren nutzt, und kürzt ihn auf den Parametervertrag, den die Engine zur Laufzeit akzeptiert.

Im Ergebnis durchlaufen ein vom Agenten gestarteter und ein angeklickter Auftrag ab dem Baustein denselben Code. Wir sprechen von „denselben Parameterregeln wie in der App“ und nicht von „identischer Ausgabe“, weil einige Tools über MCP enger gefasst sind. Der Beitrag zu den Funktionen listet diese Unterschiede auf.

Eine Regelquelle für App und Agent

Zwei Kopien derselben Regeln laufen auseinander. KwaFlux vermeidet es, zwei Kopien zu pflegen:

• Der Modulkatalog, den MCP anbietet, samt Route, Einstellungen und erlaubten Werten jedes Moduls, wird aus derselben Konfigurationsdatei erzeugt wie die Oberflächen der App. Die Fotovarianten stammen aus dem Bildabschnitt derselben Datei.
• Fünf Regelwerke werden für den MCP-Server direkt aus dem Quellcode der App übertragen: die Stufen der Ausgabeauflösung, die Container- und Codecwahl des Kompressors, die Algorithmusparameter des Audio-Arbeitsbereichs, die Stimmenliste der KI-Stimmwandlung und eine Erkennungsregel.
• Ein Drift-Test schlägt fehl, wenn sich die App-Fassung einer dieser Regeln ändert und die MCP-Fassung nicht neu erzeugt wurde.

Derselbe Gedanke hält auch die Tool-Beschreibungen klein; darum geht es im Beitrag zum Tool-Design.

Was die Steuerungsebene vor dem Einreihen prüft

Laut MCP-Spezifikation müssen Server („MUST“) alle Tool-Eingaben validieren, angemessene Zugriffskontrollen umsetzen, die Häufigkeit von Tool-Aufrufen begrenzen und Tool-Ausgaben bereinigen. In KwaFlux sitzen diese Prüfungen in der App und nicht im MCP-Skript, sodass ein anderer Client sie nicht umgehen kann:

Ergebnisse, auf die sich der Agent verlassen kann

Jedes KwaFlux-Tool deklariert ein Ausgabeschema. Das Ergebnis sind also strukturierte Daten, die der Host validieren kann, kein Absatz, den das Modell deuten muss. Übergibt der Host ein Progress-Token, sendet KwaFlux während einer Aufgabe Fortschrittsmeldungen. Stoppt der Nutzer die Anfrage im Host, hört KwaFlux auf zu warten, und der Agent kann die Aufgabe abbrechen.

Aufgabenergebnisse melden „Ausgabe bereit“ nur, wenn eine Aufgabe tatsächlich erfolgreich war, und nennen dann den Namen der Ausgabedatei. Eine wartende oder fehlgeschlagene Aufgabe behauptet nicht, etwas erzeugt zu haben.

Worauf dieser Entwurf verzichtet

Eine Steuerungsebene reicht nur so weit wie ihre Tools. Neun Funktionen von KwaFlux verlangen, dass jemand ins Bild zeichnet, ein Motiv anklickt oder eine Vorschau beurteilt, etwa das Entfernen von Objekten und das Ersetzen des Himmels. Wir hätten den Agenten Koordinaten raten lassen oder eine rohe Auftragsbeschreibung annehmen können. Das Erste liefert unvorhersehbare Ergebnisse samt einer Quittung, dass alles geklappt habe. Das Zweite beseitigt genau die Grenze, auf der die Sicherheit dieses Entwurfs beruht. Deshalb bleiben diese Funktionen in der App, und der Agent ist angewiesen, den Nutzer dorthin zu schicken.

Das ist eine Produktentscheidung und keine Lücke, die wir durch gelockerte Regeln schließen wollen.

Fazit

Muss ein Agent Pixel ansehen, um Ihre App zu bedienen, können Sie nicht prüfen, was er als Nächstes vorhat. Eine Steuerungsebene dreht das um: Der Agent fragt in einer schmalen, typisierten Sprache, und die App prüft, baut und startet den Auftrag mit ihrem eigenen Code. Bei KwaFlux läuft ein vom Agenten gestarteter Export deshalb durch denselben Auftragsbaustein wie einer, den Sie anklicken.

Über den lokalen MCP-Server von KwaFlux reihen Codex, Claude, Cursor und andere MCP-Apps echte Aufträge in die Desktop-App ein. Die KI-Verarbeitung läuft auf Ihrer eigenen GPU, und Ihre Mediendateien werden für die Verarbeitung nicht hochgeladen. KwaFlux läuft unter Windows 10 (64-Bit, Version 1809 oder neuer), Windows 11 und macOS 12 oder neuer auf Apple Silicon. Dateien importieren und die App erkunden geht ohne Konto. Anmeldung und ein bezahlter Plan sind nur für Export, Konvertierung, Dateireparatur und Datei-Download aus einem Link nötig.

KwaFlux laden · Pläne ansehen