Deja de enseñar a los agentes a mirar la pantalla: CLI-Anything le pone una línea de comandos a cada programa

Hay un tipo muy concreto de desesperación que aparece cuando ves a un agente de IA intentar usar software de escritorio. Hace una captura, adivina dónde está el menú, hace clic, falla, hace otra captura. Veinte segundos después ha movido un deslizador dos píxeles y no ha aprendido nada.

CLI-Anything, del Data Intelligence Lab de la University of Hong Kong, sostiene que todo el enfoque está mal. No le enseñes al agente a ver la pantalla. Dale al programa una línea de comandos y deja que el agente escriba.

El argumento cabe en una frase: convertir todo el software en agent-native. El mecanismo es menos vistoso y más interesante: apuntas un comando a cualquier aplicación cuyo código fuente tengas y un pipeline de siete etapas genera para ella un wrapper CLI estructurado, con tests, documentación y un paquete que se instala con pip.

Las siete etapas

El pipeline corre dentro de un agente de programación y se invoca con /cli-anything <source path or repo>. Analizar: recorrer el código y mapear las operaciones de la GUI a llamadas de API. Diseñar: decidir grupos de comandos, modelo de estado y formatos de salida. Implementar: construir un CLI basado en Click, con REPL, salida JSON y undo/redo. Planificar tests: escribir un plan de pruebas en TEST.md. Escribir tests: implementar la suite. Documentar: registrar los resultados en el mismo archivo. Publicar: crear un setup.py e instalar el comando en tu PATH.

También hay una etapa 6.5 que genera un SKILL.md, para que el CLI resultante lo pueda descubrir un agente como skill en lugar de ser algo que un humano tenga que cablear a mano. Y un comando /cli-anything:refine que hace análisis de huecos y amplía la cobertura de forma incremental.

La nomenclatura es rígida a propósito: los comandos viven bajo el espacio de nombres cli_anything.<software> y los paquetes se llaman cli-anything-<software>. Las convenciones aburridas son lo que hace que las herramientas se puedan componer, y este proyecto está pensando claramente en un mundo con cientos de estos.

Backends reales, no reimplementaciones de juguete

El detalle que separa esto de un proyecto de fin de semana: los wrappers manejan el software de verdad. LibreOffice produce un PDF real. Blender renderiza una escena 3D real. GIMP le hace a la imagen lo que GIMP le hace a las imágenes. La alternativa — reimplementar en Python un subconjunto del comportamiento de la aplicación — da como resultado algo que parece funcionar hasta que necesitas esa función que la reimplementación se saltó.

El coste es que necesitas las aplicaciones instaladas. La ventaja es que la salida es indistinguible de la que habría producido un operador humano, porque la produjo el mismo motor.

Cada comando emite JSON cuando se le pide, y esa es la diferencia entre un CLI que un agente puede parsear y uno ante el que tiene que entrecerrar los ojos. Hay un REPL con estado para el trabajo interactivo y subcomandos simples para scripts, además de estado de proyecto persistente y undo/redo.

Qué cubre

El alcance es amplio a propósito, y se lee como una lista del software que la gente lleva años intentando automatizar sin conseguirlo: GIMP, Blender y Kdenlive para creación; LibreOffice para documentos de oficina; Godot y s&box para 3D y videojuegos; QGIS y FreeCAD para ciencia e ingeniería; ComfyUI y Ollama en el lado de la IA; LLDB, RenderDoc y Nsight para depuración.

ComfyUI es el apartado en el que merece la pena detenerse si trabajas con imágenes. ComfyUI ya tiene una API, pero es una API de grafo: nodos, cables y un blob JSON cuyo esquema depende de qué nodos personalizados tengas instalados. Un wrapper CLI que exponga comandos a nivel de intención, con un modelo de estado definido y salida JSON, es justo lo que necesita un agente para ejecutar un pipeline de imágenes sin ingeniería inversa del archivo de workflow de otra persona.

La afirmación sobre los tests

El repositorio reporta unas 2.461 pruebas: 1.732 unitarias, 579 de extremo a extremo y 19 de Node.js, con una tasa de éxito declarada del 100 por cien. La capa E2E corre contra el backend real, que es el único tipo de E2E que importa aquí. Si LibreOffice deja de producir un PDF, el test falla, y te enteras antes de que tu agente genere cuarenta archivos rotos.

Tómate el «100 por cien» como una foto fija, no como una garantía. Las suites generadas tienen la costumbre de dejar grabados los supuestos de quien las generó. Pero la estructura de cuatro capas — unitaria, E2E nativa, E2E contra backend real y subproceso del CLI — tiene la forma correcta.

Las limitaciones, dichas con honestidad

El README las enumera, lo cual es buena señal.

Depende de modelos de frontera. Claude Opus 4.6 o Sonnet 4.6, GPT-5.4, esa clase. Un modelo más flojo produce CLIs incompletos o directamente erróneos que hay que reparar a mano, lo que significa que la utilidad de la herramienta va atada a una suscripción que quizá no tengas.

Depende del código fuente. El pipeline analiza fuentes; si lo único que tienes es un binario compilado, la calidad y la cobertura caen en picado. Eso excluye en silencio a la mayor parte del software comercial, que es la mayor parte del software que la gente realmente quiere automatizar.

Una sola ejecución rara vez lo cubre todo. Cuenta con lanzar /refine varias veces antes de que el harness esté a nivel de producción. Algunos CLIs exigen tener instalada la aplicación de origen. La madurez varía según la plataforma: Goose, OpenCode, Codex, Hermes y Reasonix están marcados como experimentales, y los usuarios de Windows se encontrarán con problemas de compatibilidad con bash y cygpath.

La pregunta de mantenimiento que nadie quiere hacer

Un wrapper generado es un compromiso. En el momento en que adoptas cli-anything-libreoffice, has añadido una capa entre tu agente y la aplicación, y esa capa tiene que seguir funcionando cuando LibreOffice cambie su modelo de documento o Blender renombre un operador.

En la práctica son tres cosas. Guarda el harness generado en tu propio repositorio en lugar de depender del de otro, para poder parchearlo. Vuelve a ejecutar el pipeline cuando actualices la aplicación de base, y haz diff del resultado. Y trata TEST.md como el contrato: los tests son la única razón por la que notarás una rotura antes de que tu agente produzca cuarenta archivos mal formados.

La economía funciona porque regenerar es barato. Ahí está la idea de verdad: el wrapper no tiene que ser perfecto para siempre, porque lo que lo produjo puede volver a producirlo. Los SDK tradicionales son caros de mantener porque los escriben humanos. Esto no es eso.

La apuesta del CLI-Hub

Hay un gestor de paquetes, cli-anything-hub, para explorar e instalar wrappers hechos por la comunidad. Es la parte del proyecto con más recorrido y con el riesgo más evidente. Un hub de CLIs generados es un hub de código que se ejecuta con tus permisos y toca tus archivos.

Que se convierta en un ecosistema útil o en un caso de cadena de suministro depende enteramente de si el proyecto trata la revisión como parte de la publicación. Ahora mismo la respuesta es «en parte»: los tests son generados, la documentación es generada, y la revisión es lo que haga la comunidad.

Por qué esto importa más allá del repositorio

Durante dos años, el computer use ha sido la demo favorita de la industria y su producto menos favorito. Las demos funcionan porque alguien guionizó la tarea con cuidado. Los productos se atascan porque el control a nivel de píxel es frágil de una manera que nunca termina de irse.

CLI-Anything propone otro reparto del trabajo: en vez de hacer que los agentes sean mejores siendo humanos, hacer que el software sea mejor siendo máquina. Cualquier aplicación con un árbol de fuentes pasa a ser candidata a una interfaz generada, y esa interfaz se puede testear de una forma que un bucle de capturas de pantalla nunca podrá.

El intercambio es real. Los CLIs generados valen lo que vale el modelo que los escribió, y alguien tendrá que hacerse cargo del wrapper cuando cambie la aplicación de origen. Pero la dirección es la correcta. Un agente que escribe cli-anything-blender render --scene scene.blend --out frame.png y obtiene una salida determinista está haciendo algo mucho más útil que un agente que hace clic por el viewport y confía en la suerte.