Hören Sie auf, Agenten das Hinsehen beizubringen: CLI-Anything gibt jeder Software eine Kommandozeile

Es gibt eine ganz eigene Art von Verzweiflung, die einen befällt, wenn man einem KI-Agenten dabei zusieht, wie er versucht, Desktop-Software zu bedienen. Er macht einen Screenshot, rät, wo das Menü ist, klickt, trifft daneben, macht den nächsten Screenshot. Zwanzig Sekunden später hat er einen Regler um zwei Pixel verschoben und nichts gelernt.

CLI-Anything vom Data Intelligence Lab der University of Hong Kong behauptet, dass der ganze Ansatz falsch ist. Bringen Sie dem Agenten nicht bei, den Bildschirm zu sehen. Geben Sie der Software eine Kommandozeile und lassen Sie den Agenten tippen.

Der Pitch passt in eine Zeile: jede Software agent-native machen. Der Mechanismus ist weniger glamourös und interessanter — richten Sie einen Befehl auf irgendeine Anwendung, deren Quellcode Sie haben, und eine Pipeline mit sieben Stufen erzeugt dafür einen strukturierten CLI-Wrapper, samt Tests, Dokumentation und einem Paket, das sich mit pip installieren lässt.

Die sieben Stufen

Die Pipeline läuft in einem Coding-Agenten und wird mit /cli-anything <source path or repo> aufgerufen. Analysieren: den Quellcode durchsuchen und GUI-Operationen auf API-Aufrufe abbilden. Entwerfen: Befehlsgruppen, Zustandsmodell und Ausgabeformate festlegen. Implementieren: eine Click-basierte CLI bauen, mit REPL, JSON-Ausgabe und Undo/Redo. Tests planen: einen Testplan in TEST.md schreiben. Tests schreiben: die Suite umsetzen. Dokumentieren: die Ergebnisse in dieselbe Datei zurückschreiben. Veröffentlichen: eine setup.py erzeugen und den Befehl im PATH installieren.

Dazu kommt eine Stufe 6.5, die eine SKILL.md generiert, damit die entstandene CLI von einem Agenten als Skill gefunden werden kann und nicht erst von einem Menschen verdrahtet werden muss. Und ein Befehl /cli-anything:refine, der eine Lückenanalyse macht und die Abdeckung schrittweise erweitert.

Die Namensgebung ist mit Absicht starr: Befehle liegen im Namensraum cli_anything.<software>, Pakete heißen cli-anything-<software>. Langweilige Konventionen sind das, was Tooling kombinierbar macht, und dieses Projekt denkt offensichtlich schon an eine Welt, in der es Hunderte davon gibt.

Echte Backends, keine Spielzeug-Nachbauten

Das Detail, das dieses Projekt von einem Wochenendprojekt trennt: Die Wrapper steuern die tatsächliche Software. LibreOffice erzeugt ein echtes PDF. Blender rendert eine echte 3D-Szene. GIMP macht mit einem Bild, was GIMP eben mit Bildern macht. Die Alternative — einen Teil des Verhaltens der Anwendung in Python nachzubauen — liefert etwas, das funktioniert aussieht, bis man genau das eine Feature braucht, das der Nachbau ausgelassen hat.

Der Preis ist, dass die Anwendungen installiert sein müssen. Der Gewinn ist, dass die Ausgabe nicht von der eines menschlichen Bedieners zu unterscheiden ist, weil dieselbe Engine sie erzeugt hat.

Jeder Befehl gibt auf Wunsch JSON aus, und genau das ist der Unterschied zwischen einer CLI, die ein Agent parsen kann, und einer, bei der er die Augen zusammenkneifen muss. Es gibt eine REPL mit Zustand für interaktive Arbeit und schlichte Unterbefehle für Skripte, dazu persistenter Projektzustand und Undo/Redo.

Was abgedeckt ist

Der Umfang ist bewusst breit, und er liest sich wie eine Liste der Software, die Leute seit Jahren zu automatisieren versuchen und dabei scheitern: GIMP, Blender und Kdenlive für die Kreativarbeit; LibreOffice für Bürodokumente; Godot und s&box für 3D und Spiele; QGIS und FreeCAD für Wissenschaft und Technik; ComfyUI und Ollama auf der KI-Seite; LLDB, RenderDoc und Nsight fürs Debugging.

ComfyUI ist der Punkt, bei dem man kurz innehalten sollte, wenn man mit Bildern arbeitet. ComfyUI hat bereits eine API, aber es ist eine Graph-API — Knoten, Verbindungen und ein JSON-Blob, dessen Schema davon abhängt, welche Custom Nodes installiert sind. Ein CLI-Wrapper mit Befehlen auf der Ebene von Absichten, definiertem Zustandsmodell und JSON-Ausgabe ist genau das, was ein Agent braucht, um eine Bild-Pipeline laufen zu lassen, ohne die Workflow-Datei von irgendwem rückwärts zu entwickeln.

Die Testbehauptung

Das Repository meldet rund 2.461 Tests: 1.732 Unit-Tests, 579 End-to-End und 19 Node.js, bei einer behaupteten Erfolgsquote von 100 Prozent. Die E2E-Ebene läuft gegen das echte Backend, und das ist hier die einzige Art von E2E, die zählt. Wenn LibreOffice kein PDF mehr produziert, schlägt der Test fehl, und Sie erfahren es, bevor Ihr Agent vierzig kaputte Dateien erzeugt.

Nehmen Sie die „100 Prozent“ als Momentaufnahme, nicht als Garantie. Generierte Test-Suiten haben die Angewohnheit, die Annahmen des Generators einzubetonieren. Aber die Vier-Schichten-Struktur — Unit, natives E2E, E2E gegen echtes Backend und CLI-Subprozess — hat die richtige Form.

Die ehrlichen Grenzen

Das README listet sie auf, was ein gutes Zeichen ist.

Es hängt von Frontier-Modellen ab. Claude Opus 4.6 oder Sonnet 4.6, GPT-5.4, diese Klasse. Ein schwächeres Modell liefert unvollständige oder falsche CLIs, die massiv von Hand repariert werden müssen — womit der Nutzen des Werkzeugs an ein Abo gebunden ist, das Sie vielleicht nicht haben.

Es hängt vom Quellcode ab. Die Pipeline analysiert Quellcode; wenn Sie nur ein kompiliertes Binary haben, fallen Qualität und Abdeckung deutlich ab. Das schließt stillschweigend den Großteil kommerzieller Software aus, also genau das, was die meisten Leute eigentlich automatisieren wollen.

Ein Lauf deckt selten alles ab. Rechnen Sie damit, /refine mehrfach laufen zu lassen, bevor der Harness produktionsreif ist. Manche CLIs setzen die Installation der vorgelagerten Anwendung voraus. Die Reife variiert je nach Plattform — Goose, OpenCode, Codex, Hermes und Reasonix sind als experimentell markiert, und Windows-Nutzer werden auf Kompatibilitätsprobleme mit bash und cygpath stoßen.

Die Wartungsfrage, die niemand stellen will

Ein generierter Wrapper ist eine Verpflichtung. In dem Moment, in dem Sie cli-anything-libreoffice übernehmen, haben Sie eine Schicht zwischen Ihren Agenten und die Anwendung gelegt, und diese Schicht muss weiter funktionieren, wenn LibreOffice sein Dokumentmodell ändert oder Blender einen Operator umbenennt.

Praktisch heißt das drei Dinge. Halten Sie den generierten Harness im eigenen Repository, statt sich auf den von jemand anderem zu verlassen, damit Sie ihn patchen können. Lassen Sie die Pipeline erneut laufen, wenn Sie die darunterliegende App aktualisieren, und diffen Sie das Ergebnis. Und behandeln Sie TEST.md als Vertrag — die Tests sind der einzige Grund, warum Sie einen Bruch bemerken, bevor Ihr Agent vierzig fehlerhafte Dateien produziert.

Die Ökonomie geht auf, weil Regeneration billig ist. Das ist die eigentliche Erkenntnis: Der Wrapper muss nicht für immer perfekt sein, weil das, was ihn erzeugt hat, ihn erneut erzeugen kann. Klassische SDKs sind teuer in der Wartung, weil Menschen sie schreiben. Hier ist das nicht so.

Die Wette auf den CLI-Hub

Es gibt einen Paketmanager, cli-anything-hub, um von der Community gebaute Wrapper zu durchsuchen und zu installieren. Das ist der Teil des Projekts mit dem meisten Potenzial und dem offensichtlichsten Risiko. Ein Hub generierter CLIs ist ein Hub von Code, der mit Ihren Rechten läuft und Ihre Dateien anfasst.

Ob daraus ein nützliches Ökosystem wird oder eine Geschichte über Lieferketten, hängt ganz davon ab, ob das Projekt Review als Teil des Veröffentlichens begreift. Momentan lautet die Antwort „teilweise“: Die Tests sind generiert, die Doku ist generiert, und das Review ist das, was die Community eben tut.

Warum das über das Repository hinaus zählt

Computer Use ist seit zwei Jahren die Lieblingsdemo der Branche und ihr unbeliebtestes Produkt. Die Demos funktionieren, weil jemand eine Aufgabe sorgfältig geskriptet hat. Die Produkte stocken, weil Kontrolle auf Pixelebene auf eine Weise fragil ist, die nie ganz verschwindet.

CLI-Anything schlägt eine andere Arbeitsteilung vor: Statt Agenten besser darin zu machen, Menschen zu sein, machen wir Software besser darin, Maschinen zu sein. Jede Anwendung mit einem Source-Tree wird zum Kandidaten für eine generierte Schnittstelle, und diese Schnittstelle ist auf eine Art testbar, wie es eine Screenshot-Schleife nie sein wird.

Der Kompromiss ist real. Generierte CLIs sind nur so gut wie das Modell, das sie geschrieben hat, und irgendjemand muss den Wrapper betreuen, wenn sich die vorgelagerte App ändert. Aber die Richtung stimmt. Ein Agent, der cli-anything-blender render --scene scene.blend --out frame.png tippt und deterministische Ausgabe bekommt, tut etwas grundlegend Nützlicheres als ein Agent, der im Viewport herumklickt und hofft.