Agentes de fronteira concluíram 30% de um workflow de pesquisa. Esse é o número.

Stanford tem um novo benchmark chamado Terminal-Bench-Science 0.1, e o resultado principal é bem menos empolgante do que o marketing em torno de agentes costuma ser. O benchmark colocou 70 workflows de pesquisa escritos por especialistas diante de agentes de fronteira. O melhor deles concluiu 30% deles.

Trinta por cento é o número a reter. Ele não se lê como fracasso nem como triunfo. É uma medição honesta de onde a tecnologia está, publicada por pessoas que escreveram as tarefas à mão.

O que o benchmark realmente testa

As tarefas são workflows científicos, escritos por especialistas de domínio, e os agentes rodam em um terminal. Essa escolha importa. Um terminal é um ambiente de trabalho onde a tarefa é real: você precisa de fato instalar a dependência, escrever o arquivo, rodar a análise e conferir a saída. Não há crédito parcial por descrever a abordagem correta. O comando ou funciona, ou não funciona.

Os workflows vêm da prática de pesquisa, que é um alvo muito mais bagunçado do que uma tarefa de programação com uma suíte de testes arrumadinha. Um benchmark de programação costuma ter uma resposta correta definida, então pode ser pontuado automaticamente. O trabalho de pesquisa muitas vezes não tem, e é por isso que construir um benchmark como este exigiu especialistas escrevendo as tarefas, em vez de extraí-las de um repositório.

Por que 30 por cento é o enquadramento certo

Benchmarks tendem a ser lidos como aprovado ou reprovado. Um modelo que marca 90 em um benchmark de programação é tratado como praticamente resolvido. Um modelo que conclui 30% dos workflows de pesquisa pode, no mesmo espírito, ser lido como fracassando na maioria das vezes.

Essa leitura não entende para que serve o número. Trinta por cento de conclusão em tarefas escritas à mão por especialistas significa que os agentes conseguem lidar com o terço rotineiro do trabalho de pesquisa: montar ambientes, rodar pipelines estabelecidos, limpar dados, produzir saídas padronizadas. Os outros 70% são onde a tarefa exige um julgamento que o workflow não explicita, ou onde um passo quebra de um jeito que precisa de um humano para decidir o que fazer em seguida.

É uma divisão útil. Ela diz a um laboratório onde apontar um agente hoje, e diz a quem constrói ferramentas onde está a lacuna.

O terminal é a parte interessante

Rodar agentes em um terminal é uma escolha deliberada de testá-los onde o trabalho acontece. O software de pesquisa é, em grande parte, software de linha de comando. Um modelo que só sabe operar uma janela de chat não ajuda um laboratório. Um modelo que consegue sentar em um shell, ler a documentação, instalar um toolchain e se recuperar quando um build falha é uma categoria diferente de útil.

É também onde os modos de falha são mais visíveis. Um terminal não esconde um erro. Quando um comando retorna uma mensagem ambígua ou um script completa pela metade, o agente tem que decidir se tenta de novo, muda de abordagem ou para. Esse ponto de decisão é onde a maior parte dos 70% se perde, e é exatamente o tipo de coisa que um benchmark de programação com uma suíte de testes limpa nunca vai revelar.

Como isso difere dos benchmarks de programação

A comparação óbvia é com os benchmarks de programação, que se tornaram a forma padrão de anunciar o progresso dos agentes. Um benchmark de programação normalmente vem com um repositório e uma suíte de testes, então a resposta correta está definida e a pontuação é automática. Isso o torna barato de rodar e fácil de comparar, e é por isso que esses números dominam a conversa.

Os workflows de pesquisa resistem a esse tratamento. Muitas vezes não há uma única saída correta, e a qualidade de um resultado depende de julgamento sobre o que medir e como. É por isso que as tarefas aqui foram escritas por especialistas em vez de extraídas de um repositório, e por que o benchmark reporta conclusão em vez de uma taxa de aprovação em testes.

A troca é cobertura por realismo. Um benchmark de programação pode ser rodado milhares de vezes por dia e produzir um número preciso. Um benchmark de workflows é mais lento e mais ruidoso, mas testa o ambiente onde boa parte do trabalho técnico de fato acontece. Os dois são úteis, e só um deles era amplamente disponível antes.

Por que o número é medido assim

Conclusão é uma métrica crua, e os autores a escolheram de propósito. Um workflow ou termina, ou não termina, e isso é um fato que um observador externo pode verificar sem julgar a qualidade do resultado. Elegância não é pontuada. Correção não é discutida. O agente ou produziu a saída que o workflow pedia, ou parou em algum ponto antes.

Essa crueza é o ponto. Benchmarks que tentam pontuar qualidade em tarefas de pesquisa abertas tendem a colapsar no gosto do autor do benchmark. Ao pontuar conclusão, este troca nuance por reprodutibilidade. Dois laboratórios rodando o mesmo workflow chegam à mesma resposta, e é isso que faz um número valer a pena ser citado.

O custo é que ele não consegue distinguir um agente que quase terminou de um que falhou imediatamente. Ambos contam como falhas. Isso é uma limitação, e uma versão futura pode resolvê-la, mas um número grosseiro com o qual todos concordam é melhor do que um número refinado em que ninguém confia.

O que o resultado diz sobre o trabalho científico

O benchmark é uma resposta discreta a uma alegação barulhenta: a de que os agentes logo farão pesquisa. O que ele mostra é que os agentes conseguem executar pesquisa, ou seja, executar um procedimento que um humano já elaborou, em uma parcela crescente de passos rotineiros. Ainda não conseguem fazer a parte em que o procedimento é desconhecido e alguém precisa inventá-lo.

Essa lacuna não é um pequeno detalhe de engenharia. O trabalho rotineiro ocupa uma grande parte do tempo de um cientista, e automatizá-lo economiza dinheiro e horas de verdade. Também não é a parte que produz descobertas. A distinção importa para quem faz previsões sobre o que a IA fará com a ciência nos próximos anos.

Como ler benchmarks como este

Duas ressalvas valem para qualquer benchmark novo. A primeira é o número da versão. Este é o 0.1, o que significa que o conjunto de tarefas vai mudar conforme os autores descobrirem quais tarefas estão bem formuladas e quais são ambíguas. Pontuações de versões diferentes não são diretamente comparáveis.

A segunda é que um benchmark mede os workflows que seus autores escolheram. Setenta tarefas extraídas de domínios científicos são uma amostra, não um censo. A cifra de 30% é um bom sinal do formato geral da capacidade dos agentes no trabalho de pesquisa. Não é um número preciso que vai sobreviver à próxima revisão.

O que observar

O progresso a observar não é o percentual da manchete subindo. É quais tarefas começam a passar. Se os agentes começarem a concluir workflows que exigem recuperação em múltiplos passos, isso é um avanço real. Se o ganho vier apenas de tarefas mais fáceis de configuração e limpeza de dados, o teto é mais baixo do que a manchete sugere.

Um benchmark que reporta um número baixo com honestidade é mais útil do que um que reporta um número alto que as pessoas não conseguem reproduzir. Este está fazendo a primeira coisa, e a área precisa de mais disso.