Resumo Técnico: TERMINALWORLD: Avaliação de Agentes em Tarefas de Terminal do Mundo Real

Declaração do Problema

Agentes autônomos impulsionados por Modelos de Linguagem de Grande Escala (LLMs) estão cada vez mais capazes de automatizar fluxos de trabalho complexos de terminal ao emitir comandos, compor ferramentas e interpretar feedback dentro de sessões interativas de Interface de Linha de Comando (CLI). No entanto, avaliar com confiabilidade esses agentes em tarefas autênticas e do mundo real permanece um desafio em aberto.

Os padrões de avaliação atuais dependem fortemente de benchmarks curados manualmente (por exemplo, Terminal-Bench, LongCLI-Bench). Esses benchmarks sofrem de três limitações primárias:

1. Lacuna de Autenticidade: Especialistas frequentemente priorizam puzzles adversariais para maximizar a dificuldade, fazendo com que as tarefas se desviem dos fluxos de trabalho autênticos e rotineiros que os desenvolvedores realmente executam.
2. Gargalo de Escalabilidade: A curadoria manual é intensiva em mão de obra e luta para acompanhar as práticas de terminal em evolução e as diversas ferramentas emergentes, levando a benchmarks de escopo restrito e rapidamente desatualizados.
3. Déficit de Validação: Métodos recentes de síntese automatizada tentam contornar a curadoria manual, mas são projetados principalmente para geração de dados de treinamento. Raramente passam pela validação rigorosa necessária para garantir autenticidade verdadeira e solidez dos testes.

Consequentemente, há uma falta de um sistema de avaliação que seja tanto autêntico às práticas reais de desenvolvedores quanto escalável o suficiente para evoluir junto com elas.

Metodologia: O Motor de Dados TERMINALWORLD

Para abordar essas limitações, os autores introduzem o TERMINALWORLD, um motor de dados escalável que reverse-engineera automaticamente tarefas de avaliação de alta fidelidade a partir de gravações de terminal "in-the-wild". O motor opera sobre um corpus de 80.870 gravações de sessões de terminal colhidas da plataforma asciinema, um repositório público onde desenvolvedores compartilham voluntariamente transcrições de sessões.

O motor processa gravações brutas através de quatro etapas sistemáticas para transformar logs ruidosos em benchmarks rigorosos:

1. Coleta e Filtragem de Gravações Humanas

O motor recupera transcrições e metadados do asciinema. Um processo de filtragem multiestágio garante qualidade e segurança dos dados:

• Privacidade e Segurança: Exclusão de gravações contendo Informações Pessoalmente Identificáveis (PII), credenciais sensíveis ou comandos maliciosos (por exemplo, rm -rf *).
• Definição de Escopo: Descarte de gravações envolvendo Interfaces de Usuário de Texto (TUIs como vim ou nano) ou GUIs, focando estritamente em fluxos de trabalho CLI puros.
• Reprodutibilidade: Remoção de sessões dependentes de URLs inacessíveis, ambientes Windows ou software proprietário que não pode ser containerizado.
• Pontuação de Qualidade: Uso de um LLM para filtrar sessões opacas ou puramente exploratórias, retendo apenas fluxos de trabalho de alta qualidade e determinísticos.
• Resultado: 9.492 gravações de alta qualidade foram retidas para síntese.

2. Síntese de Tarefas de Terminal

Transcrições brutas são ruidosas, contendo erros de digitação, tentativas repetidas e saída de sistema verbosa. O motor usa um LLM (por exemplo, Claude Sonnet 4.6) para destilar essas transcrições em dois artefatos:

• Formalização da Instrução da Tarefa: O LLM infere a intenção subjacente do desenvolvedor para gerar uma instrução orientada a resultados. Crucialmente, a instrução especifica o estado final (por exemplo, "salvar IPs bloqueados em /app/result.txt") em vez do caminho procedural, impedindo que dicas específicas da solução vazem para a tarefa.
• Extração da Solução de Referência: O LLM extrai um script Bash limpo e executável da transcrição, removendo duplicatas e tentativas falhas para criar uma solução de referência de verdade absoluta (ground-truth).

3. Reprodução de Ambientes Executáveis

Como as gravações brutas dependem do estado específico do sistema do desenvolvedor original, o motor deve reverse-engineerar o ambiente de execução.

• Síntese de Ambiente: Um agente LLM (por exemplo, Claude Code) infere dependências (imagens base, pacotes de sistema, runtimes) a partir da solução de referência para sintetizar um Dockerfile e um docker-compose.yaml.
• Loop de Refinamento Baseado em Execução: Para garantir que o ambiente seja fiel e não alucinado, o agente constrói a imagem Docker, tenta reproduzir a solução de referência e usa falhas em tempo de execução (por exemplo, bibliotecas ausentes, variáveis não configuradas) como feedback para reparar iterativamente o Dockerfile.
• Resultado: Este loop reproduz com sucesso ambientes executáveis para 5.035 tarefas.

4. Geração de Suítes de Teste

Para julgar automaticamente o sucesso da tarefa, o motor gera uma suíte de testes dentro do contêiner Docker reproduzido usando um loop de refinamento baseado em tentativas:

• Síntese de Testes: Um agente gera asserções com base na instrução formalizada e nas alterações reais do sistema de arquivos (deltas de estado) causadas pela solução de referência.
• Validação de Três Tentativas:
  1. Tentativa AllPassing: Executa a solução de referência; todos os testes devem passar (garante solvabilidade).
  2. Tentativa Nop: Não executa nada; todos os testes devem falhar (garante não trivialidade).
  3. Tentativas Parciais: Executa soluções truncadas/ablatadas; pelo menos um teste deve falhar (garante discriminabilidade contra soluções incompletas).
• Resultado: Apenas tarefas onde a suíte de testes passa nas três tentativas são admitidas. Este processo produz 1.530 tarefas de terminal validadas para o benchmark completo.

Deste conjunto completo, os autores curaram um subconjunto VERIFIED de 200 tarefas, revisado manualmente pelos autores para garantir alinhamento semântico e correção, servindo como um campo de testes rigoroso para modelos de fronteira.

Contribuições Principais

1. Benchmark TERMINALWORLD: Um conjunto de dados de 1.530 tarefas validadas abrangendo 18 categorias do mundo real (por exemplo, orquestração de contêineres, CI/CD, segurança) e cobrindo 1.280 comandos únicos. Notavelmente, 91% desses comandos estão ausentes em benchmarks existentes como o Terminal-Bench.
2. Motor de Dados Automatizado: Um pipeline totalmente automatizado que reverse-engineera tarefas a partir de gravações do mundo real, garantindo que o benchmark seja "autêntico e escalável por construção".
3. Subconjunto VERIFIED: Um núcleo manualmente verificado de 200 tarefas projetado para avaliação de alta fidelidade de fluxos de trabalho complexos.
4. Avaliação Abrangente: Avaliação extensa de oito LLMs de fronteira e seis agentes de terminal líderes no subconjunto VERIFIED.

Resultados Experimentais

Os autores avaliaram modelos de fronteira (por exemplo, Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) e agentes (por exemplo, Terminus-2, Claude Code, OpenHands) no subconjunto TERMINALWORLD-VERIFIED.

• Teto de Desempenho: Sistemas atuais lutam significativamente com fluxos de trabalho autênticos de terminal. O modelo de melhor desempenho (Claude Opus 4.7) alcançou uma taxa de aprovação de apenas 62,5%.
• Paradoxo de Eficiência: Há uma fraca correlação negativa entre consumo de recursos (turnos, tokens) e sucesso. Modelos frequentemente gastam computação excessiva explorando ambientes sem fazer progresso. Tentativas falhas consomem significativamente mais recursos (3,3× mais tokens) do que as bem-sucedidas.
• Especificidade de Domínio: O desempenho varia drasticamente por domínio. Modelos performam bem na configuração de ambiente (87,5%), mas lutam com otimização de desempenho (28,1%) e scripting/automação (39,1%).
• Impacto do Framework de Agente: Frameworks de agentes influenciam principalmente a relação custo-benefício, e não o teto de capacidade subjacente. Por exemplo, Terminus-2 e mini-SWE-agent alcançaram taxas de aprovação semelhantes às do Claude Code, mas a uma fração do custo.
• Correlação Fraca com Benchmarks Existentes: Pontuações no Terminal-Bench 2.0 mostram apenas uma correlação fraca (Pearson $r = 0,20$) com as pontuações do TERMINALWORLD-VERIFIED. Modelos que dominam desafios curados por especialistas (por exemplo, GPT-5.5) frequentemente performam mal em fluxos de trabalho do mundo real, sugerindo que benchmarks existentes não capturam totalmente as capacidades necessárias.
• Divergência de Fluxos de Trabalho Humanos: Agentes raramente imitam os caminhos específicos de comandos das gravações humanas originais. A sobreposição mediana do conjunto de comandos entre as trajetórias do agente e as soluções de referência humanas é de apenas 21,4%, indicando que os agentes frequentemente resolvem tarefas via estratégias alternativas válidas, mas distintas.

Significado e Afirmações

O artigo afirma que o TERMINALWORLD estabelece um novo padrão para avaliar agentes de terminal, mudando de puzzles adversariais curados por especialistas para fluxos de trabalho autênticos, escaláveis e do mundo real.

• Autenticidade: Ao reverse-engineerar tarefas a partir de gravações reais de desenvolvedores, o benchmark captura as nuances de dependências do mundo real, diversidade de ferramentas e complexidade de fluxo de trabalho que benchmarks sintéticos ou manualmente elaborados perdem.
• Escalabilidade: A natureza automatizada do motor permite que o benchmark evolua continuamente à medida que novas gravações são enviadas ao asciinema, impedindo que o conjunto de dados fique obsoleto.
• Valor Diagnóstico: O benchmark revela que os modelos e agentes atuais de última geração carecem de habilidades robustas de uso de ferramentas em espaços de ação abertos e do mundo real. Destaca que altas pontuações em benchmarks existentes podem superestimar a competência de um agente em ambientes de terminal práticos e em evolução.

Os autores concluem que o TERMINALWORLD fornece uma fundação necessária para desenvolver agentes que sejam confiáveis em ambientes de terminal do mundo real, movendo a comunidade além de avaliações estáticas e curadas por especialistas.