Pare de ensinar agentes a olhar para a tela: CLI-Anything dá uma linha de comando para cada software

Existe um tipo muito específico de desespero que dá quando você assiste a um agente de IA tentando usar um software de desktop. Ele tira um print, adivinha onde fica o menu, clica, erra, tira outro print. Vinte segundos depois, moveu um controle deslizante dois pixels e não aprendeu nada.

O CLI-Anything, do Data Intelligence Lab da University of Hong Kong, sustenta que toda a abordagem está errada. Não ensine o agente a ver a tela. Dê uma linha de comando ao software e deixe o agente digitar.

O argumento cabe em uma linha: tornar todo software agent-native. O mecanismo é menos glamouroso e mais interessante — aponte um comando para qualquer aplicação cujo código-fonte você tenha e um pipeline de sete estágios gera para ela um wrapper CLI estruturado, com testes, documentação e um pacote que se instala com pip.

Os sete estágios

O pipeline roda dentro de um agente de programação, invocado com /cli-anything <source path or repo>. Analisar: varrer o código e mapear operações da GUI para chamadas de API. Projetar: decidir grupos de comandos, modelo de estado, formatos de saída. Implementar: construir um CLI baseado em Click, com REPL, saída JSON e undo/redo. Planejar testes: escrever um plano de testes em TEST.md. Escrever testes: implementar a suíte. Documentar: registrar os resultados no mesmo arquivo. Publicar: criar um setup.py e instalar o comando no seu PATH.

Há também um estágio 6.5 que gera um SKILL.md, para que o CLI resultante possa ser descoberto por um agente como skill, em vez de ser algo que um humano precisa ligar na mão. E um comando /cli-anything:refine que faz análise de lacunas e amplia a cobertura aos poucos.

A nomenclatura é rígida de propósito: os comandos vivem sob o namespace cli_anything.<software>, os pacotes se chamam cli-anything-<software>. Convenções chatas são o que torna o ferramental componível, e este projeto está claramente pensando em um mundo com centenas desses.

Backends de verdade, não reimplementações de brinquedo

O detalhe que separa isto de um projeto de fim de semana: os wrappers dirigem o software de verdade. O LibreOffice produz um PDF de verdade. O Blender renderiza uma cena 3D de verdade. O GIMP faz com a imagem o que o GIMP faz com imagens. A alternativa — reimplementar em Python um subconjunto do comportamento do aplicativo — gera algo que parece funcionar até você precisar daquele recurso que a reimplementação pulou.

O custo é que você precisa ter as aplicações instaladas. O ganho é que a saída é indistinguível da que um operador humano teria produzido, porque foi produzida pelo mesmo motor.

Todo comando emite JSON quando solicitado, e essa é a diferença entre um CLI que um agente consegue parsear e um CLI diante do qual ele precisa apertar os olhos. Existe um REPL com estado para trabalho interativo e subcomandos simples para scripts, além de estado de projeto persistente e undo/redo.

O que ele cobre

O escopo é amplo de propósito, e lê-se como uma lista do software que as pessoas vêm tentando automatizar sem conseguir: GIMP, Blender e Kdenlive para criação; LibreOffice para documentos de escritório; Godot e s&box para 3D e jogos; QGIS e FreeCAD para ciência e engenharia; ComfyUI e Ollama no lado da IA; LLDB, RenderDoc e Nsight para depuração.

ComfyUI é o item em que vale a pena parar se você trabalha com imagens. O ComfyUI já tem uma API, mas é uma API de grafo — nós, fios e um blob JSON cujo schema depende de quais nós personalizados você instalou. Um wrapper CLI que exponha comandos no nível da intenção, com modelo de estado definido e saída JSON, é exatamente o que um agente precisa para rodar um pipeline de imagens sem fazer engenharia reversa do arquivo de workflow de outra pessoa.

A alegação sobre os testes

O repositório reporta cerca de 2.461 testes: 1.732 unitários, 579 ponta a ponta e 19 de Node.js, com uma taxa de aprovação declarada de 100 por cento. A camada E2E roda contra o backend real, que é o único tipo de E2E que importa aqui. Se o LibreOffice parar de produzir PDF, o teste quebra, e você descobre antes de o seu agente gerar quarenta arquivos quebrados.

Trate os «100 por cento» como uma fotografia, não como garantia. Suítes geradas têm o hábito de cristalizar as premissas de quem as gerou. Mas a estrutura em quatro camadas — unitária, E2E nativa, E2E contra backend real e subprocesso do CLI — tem o formato certo.

As limitações, ditas com honestidade

O README as lista, o que é bom sinal.

Depende de modelos de fronteira. Claude Opus 4.6 ou Sonnet 4.6, GPT-5.4, essa classe. Um modelo mais fraco produz CLIs incompletos ou errados, que exigem muita reparação manual — ou seja, a utilidade da ferramenta fica atrelada a uma assinatura que talvez você não tenha.

Depende de código-fonte. O pipeline analisa os fontes; se você só tem um binário compilado, qualidade e cobertura caem bastante. Isso exclui silenciosamente a maior parte do software comercial, que é a maior parte do software que as pessoas realmente querem automatizar.

Uma execução raramente cobre tudo. Conte com rodar /refine várias vezes antes de o harness chegar ao nível de produção. Alguns CLIs exigem a aplicação upstream instalada. A maturidade varia por plataforma — Goose, OpenCode, Codex, Hermes e Reasonix estão marcados como experimentais, e usuários de Windows vão esbarrar em problemas de compatibilidade com bash e cygpath.

A pergunta de manutenção que ninguém quer fazer

Um wrapper gerado é um compromisso. No momento em que você adota o cli-anything-libreoffice, colocou uma camada entre o seu agente e a aplicação, e essa camada precisa continuar funcionando quando o LibreOffice mudar o modelo de documento ou o Blender renomear um operador.

Na prática, isso significa três coisas. Mantenha o harness gerado no seu próprio repositório em vez de depender do de outra pessoa, para poder corrigi-lo. Rode o pipeline de novo quando atualizar o aplicativo por baixo, e faça diff do resultado. E trate o TEST.md como contrato — os testes são o único motivo pelo qual você vai notar uma quebra antes de o seu agente produzir quarenta arquivos malformados.

A economia fecha porque regenerar é barato. É essa a ideia de verdade: o wrapper não precisa ser perfeito para sempre, porque aquilo que o produziu pode produzi-lo de novo. SDKs tradicionais custam caro para manter porque humanos os escrevem. Aqui não é isso.

A aposta no CLI-Hub

Existe um gerenciador de pacotes, o cli-anything-hub, para navegar e instalar wrappers feitos pela comunidade. É a parte do projeto com mais potencial e com o risco mais óbvio. Um hub de CLIs gerados é um hub de código que roda com as suas permissões e mexe nos seus arquivos.

Se vai virar um ecossistema útil ou um caso de cadeia de suprimentos depende inteiramente de o projeto tratar a revisão como parte da publicação. Por enquanto a resposta é «em parte»: os testes são gerados, a documentação é gerada, e a revisão é o que a comunidade fizer.

Por que isso importa além do repositório

Há dois anos o computer use é a demo favorita da indústria e o produto de que ela menos gosta. As demos funcionam porque alguém roteirizou a tarefa com cuidado. Os produtos travam porque o controle em nível de pixel é frágil de um jeito que nunca desaparece de todo.

O CLI-Anything propõe outra divisão de trabalho: em vez de deixar os agentes melhores em ser humanos, deixar o software melhor em ser máquina. Toda aplicação com uma árvore de fontes vira candidata a uma interface gerada, e essa interface é testável de um jeito que um loop de prints nunca será.

O trade-off é real. CLIs gerados valem o quanto vale o modelo que os escreveu, e alguém vai ter que cuidar do wrapper quando o aplicativo upstream mudar. Mas a direção está certa. Um agente que digita cli-anything-blender render --scene scene.blend --out frame.png e recebe saída determinística está fazendo algo fundamentalmente mais útil do que um agente que clica pelo viewport e torce.