Smettiamo di insegnare agli agenti a guardare lo schermo: CLI-Anything dà una riga di comando a ogni programma

C'è un tipo molto particolare di disperazione che ti prende quando guardi un agente IA che prova a usare un software desktop. Fa uno screenshot, indovina dov'è il menu, clicca, sbaglia, fa un altro screenshot. Venti secondi dopo ha spostato uno slider di due pixel e non ha imparato niente.

CLI-Anything, del Data Intelligence Lab della University of Hong Kong, sostiene che l'intero approccio sia sbagliato. Non insegnare all'agente a vedere lo schermo. Dai al software una riga di comando e lascia che l'agente scriva.

Il pitch sta in una riga: rendere ogni software agent-native. Il meccanismo è meno appariscente e più interessante: punti un comando verso qualsiasi applicazione di cui hai i sorgenti e una pipeline in sette fasi genera per lei un wrapper CLI strutturato, completo di test, documentazione e un pacchetto che si installa con pip.

Le sette fasi

La pipeline gira dentro un agente di coding e si invoca con /cli-anything <source path or repo>. Analizzare: scansionare i sorgenti e mappare le operazioni della GUI su chiamate API. Progettare: decidere gruppi di comandi, modello di stato, formati di output. Implementare: costruire una CLI basata su Click, con REPL, output JSON e undo/redo. Pianificare i test: scrivere un piano di test dentro TEST.md. Scrivere i test: implementare la suite. Documentare: riportare i risultati nello stesso file. Pubblicare: creare un setup.py e installare il comando nel PATH.

C'è anche una fase 6.5 che genera un SKILL.md, così la CLI risultante è scopribile da un agente come skill invece di essere qualcosa che un umano deve cablare a mano. E un comando /cli-anything:refine che fa analisi dei buchi e allarga la copertura un pezzo alla volta.

La nomenclatura è rigida di proposito: i comandi vivono sotto il namespace cli_anything.<software>, i pacchetti si chiamano cli-anything-<software>. Sono le convenzioni noiose a rendere il tooling componibile, e questo progetto sta chiaramente pensando a un mondo in cui ne esistono centinaia.

Backend veri, non reimplementazioni giocattolo

Il dettaglio che separa questo da un progetto da weekend: i wrapper guidano il software vero. LibreOffice produce un PDF vero. Blender renderizza una scena 3D vera. GIMP fa a un'immagine quello che GIMP fa alle immagini. L'alternativa — reimplementare in Python un sottoinsieme del comportamento dell'app — produce qualcosa che sembra funzionare finché non ti serve quella funzione che la reimplementazione ha saltato.

Il costo è che devi avere le applicazioni installate. Il vantaggio è che l'output è indistinguibile da quello che avrebbe prodotto un operatore umano, perché l'ha prodotto lo stesso motore.

Ogni comando emette JSON quando glielo chiedi, ed è la differenza tra una CLI che un agente può parsare e una CLI davanti alla quale deve strizzare gli occhi. C'è una REPL con stato per il lavoro interattivo e sottocomandi normali per gli script, più stato di progetto persistente e undo/redo.

Che cosa copre

La portata è ampia di proposito, e si legge come una lista dei software che la gente prova e riprova a automatizzare senza riuscirci: GIMP, Blender e Kdenlive per la creatività; LibreOffice per i documenti d'ufficio; Godot e s&box per 3D e giochi; QGIS e FreeCAD per scienza e ingegneria; ComfyUI e Ollama sul fronte IA; LLDB, RenderDoc e Nsight per il debug.

ComfyUI è il punto su cui vale la pena fermarsi se lavori con le immagini. ComfyUI ha già un'API, ma è un'API a grafo: nodi, fili e un blob JSON il cui schema dipende da quali nodi personalizzati hai installato. Un wrapper CLI che espone comandi a livello di intento, con un modello di stato definito e output JSON, è esattamente ciò che serve a un agente per far girare una pipeline di immagini senza fare reverse engineering del file di workflow di qualcun altro.

La questione dei test

Il repository dichiara circa 2.461 test: 1.732 unitari, 579 end-to-end e 19 Node.js, con un tasso di successo dichiarato del 100 per cento. Lo strato E2E gira contro il backend reale, che è l'unico tipo di E2E che qui conti. Se LibreOffice smette di produrre un PDF, il test fallisce, e lo scopri prima che il tuo agente generi quaranta file rotti.

Prendi quel «100 per cento» come un'istantanea, non come una garanzia. Le suite generate hanno il vizio di cementare le assunzioni di chi le ha generate. Però la struttura a quattro strati — unitario, E2E nativo, E2E su backend reale e sottoprocesso della CLI — ha la forma giusta.

I limiti, detti con onestà

Il README li elenca, il che è buon segno.

Dipende da modelli di frontiera. Claude Opus 4.6 o Sonnet 4.6, GPT-5.4, quella classe lì. Un modello più debole produce CLI incompleti o sbagliati che vanno riparati a mano, il che significa che l'utilità dello strumento è legata a un abbonamento che potresti non avere.

Dipende dal codice sorgente. La pipeline analizza i sorgenti; se hai solo un binario compilato, qualità e copertura crollano. Il che esclude in silenzio la maggior parte del software commerciale, cioè la maggior parte del software che la gente vorrebbe davvero automatizzare.

Una sola esecuzione raramente copre tutto. Metti in conto di lanciare /refine parecchie volte prima che l'harness sia a livello di produzione. Alcune CLI richiedono che l'applicazione a monte sia installata. La maturità varia da piattaforma a piattaforma: Goose, OpenCode, Codex, Hermes e Reasonix sono marcati come sperimentali, e chi usa Windows incontrerà problemi di compatibilità con bash e cygpath.

La domanda sulla manutenzione che nessuno vuole fare

Un wrapper generato è un impegno. Nel momento in cui adotti cli-anything-libreoffice hai aggiunto uno strato tra il tuo agente e l'applicazione, e quello strato deve continuare a funzionare quando LibreOffice cambia il modello di documento o Blender rinomina un operatore.

In pratica significa tre cose. Tieni l'harness generato nel tuo repository invece di dipendere da quello di qualcun altro, così puoi metterci le pezze. Riesegui la pipeline quando aggiorni l'app di base, e fai il diff del risultato. E tratta TEST.md come il contratto: i test sono l'unica ragione per cui ti accorgerai di una rottura prima che il tuo agente produca quaranta file malformati.

L'economia funziona perché rigenerare costa poco. È questa l'intuizione vera: il wrapper non deve essere perfetto per sempre, perché la cosa che l'ha prodotto può produrlo di nuovo. Gli SDK tradizionali costano cari da mantenere perché li scrivono gli umani. Qui non è così.

La scommessa sul CLI-Hub

C'è un package manager, cli-anything-hub, per sfogliare e installare i wrapper fatti dalla community. È la parte del progetto con più margine di crescita e con il rischio più ovvio. Un hub di CLI generati è un hub di codice che gira con i tuoi permessi e tocca i tuoi file.

Che diventi un ecosistema utile o un caso di supply chain dipende interamente dal fatto che il progetto consideri la revisione parte della pubblicazione. Al momento la risposta è «in parte»: i test sono generati, la documentazione è generata, e la revisione è quello che fa la community.

Perché conta oltre il repository

Per due anni il computer use è stata la demo preferita del settore e il prodotto meno amato. Le demo funzionano perché qualcuno ha sceneggiato con cura un compito. I prodotti si bloccano perché il controllo a livello di pixel è fragile in un modo che non se ne va mai del tutto.

CLI-Anything propone un'altra divisione del lavoro: invece di rendere gli agenti più bravi a fare gli umani, rendere il software più bravo a fare la macchina. Ogni applicazione con un albero dei sorgenti diventa candidata a un'interfaccia generata, e quell'interfaccia è testabile in un modo in cui un loop di screenshot non sarà mai.

Il compromesso è reale. Le CLI generate valgono quanto il modello che le ha scritte, e qualcuno dovrà occuparsi del wrapper quando l'app a monte cambia. Ma la direzione è quella giusta. Un agente che scrive cli-anything-blender render --scene scene.blend --out frame.png e ottiene un output deterministico sta facendo qualcosa di radicalmente più utile di un agente che clicca qua e là nel viewport e spera.