O HarnessDev coloca uma questão mais operacional do que a maioria dos benchmarks de agentes: pode um modelo de linguagem conceber a estrutura de software que envolve outro agente e depois melhorar essa estrutura ao longo do tempo? Os autores avaliam infraestrutura executável, e não apenas respostas finais. O resultado expõe um problema relevante para equipas que trabalham com sistemas autoaperfeiçoáveis: uma versão pode melhorar nas tarefas visíveis e, ao mesmo tempo, piorar em tarefas ocultas ou quando muda o modelo executor.
Isto importa porque essa estrutura concentra muitos controlos de produção: decomposição do trabalho, chamadas a ferramentas, gestão de estado, novas tentativas, verificação de resultados e condições de paragem. Se o próprio agente começar a alterar essa camada, avaliar apenas o modelo deixa de ser suficiente. A estrutura de execução passa a ser um artefacto de software versionado que precisa de disciplina de lançamento.
O benchmark avalia infraestrutura, não apenas respostas
O preprint HarnessDev, submetido a 1 de setembro, tem duas fases. Na fase de criação, seis modelos criadores geram estruturas de agente em quatro domínios e cinco benchmarks a jusante, num total de 2 207 instâncias únicas. O ponto de partida é deliberadamente fraco: não inclui ciclo de agente, lógica de decomposição, política de ferramentas, gestão de contexto, estado persistente, verificador, novas tentativas nem regras de paragem. Qualquer desempenho acima de zero depende, por isso, do que o modelo criador acrescenta.
As estruturas produzidas são executáveis, mas a qualidade varia consoante o domínio. Os autores relatam que continuam atrás de referências humanas maduras em programação e pesquisa, enquanto algumas tarefas de escrita e experimentação de aprendizagem automática igualam ou ultrapassam as referências selecionadas.
A transferência é a principal fragilidade
A fase de evolução é mais reveladora para utilização em produção. O projeto acompanha 73 versões oficiais em nove trajetórias de otimização. Segundo a página do projeto, o conjunto usado para orientar as alterações e o conjunto oculto concordam em apenas 34 de 64 transições comparáveis, ou 53,1%. Apenas duas das nove versões declaradas finais são também ótimas no conjunto oculto.
O desempenho também pode mudar quando muda o modelo executor. Numa comparação apresentada pelo projeto, a substituição do executor por um modelo Gemini fixo torna negativas três de quatro trajetórias. O executor deve, portanto, ser tratado como parte do sistema avaliado, e não como um detalhe substituível.
Alterações à estrutura devem ser promovidas como versões de software
A conclusão mais sólida não é que os agentes já consigam construir agentes melhores de forma autónoma. Os resultados são demasiado mistos para essa afirmação. O que mostram é que a autoalteração da infraestrutura cria um problema clássico de gestão de versões.
Cada versão deveria ter uma identidade imutável, um conjunto de validação separado das tarefas que motivaram a alteração, registo do modelo executor usado e possibilidade de reversão. A promoção para produção deveria depender de limites previamente definidos para regressões de qualidade, custo, latência e comportamento relevante para segurança.
Isto é mais exigente do que olhar para uma tabela classificativa. Uma melhoria num benchmark pode ser uma regressão no contexto real de utilização. O HarnessDev torna esse risco visível ao avaliar transições entre versões e não apenas pontuações finais.
Um mecanismo presente no código pode não existir na prática
O projeto também verifica se os componentes gerados são realmente utilizados. Em 108 instâncias de componentes, 18 nunca são observadas durante a execução, e todas pertencem a mecanismos de estado ou memória. Onze artefactos definem uma classe de estado, mas apenas um expõe gravação de estado, apenas um implementa pontos de controlo periódicos e o projeto relata zero eventos de ponto de controlo em 26 679 trajetórias de tarefas.
Este é um sinal importante para governação e garantia. A inspeção estática pode mostrar que um controlo existe sem demonstrar que alguma vez é acionado. A mesma distinção aplica-se a novas tentativas, verificadores, memória, controlos de autorização e mecanismos de segurança.
O que as equipas devem retirar deste resultado
O HarnessDev continua a ser um preprint. Os modelos, benchmarks e sistemas de referência são seletivos, e a análise oculta posterior à congelação da fase de evolução concentra-se sobretudo em engenharia de software. Os resultados não devem ser interpretados como prova geral de que a evolução autónoma destas estruturas é insegura ou ineficaz.
Ainda assim, o trabalho estabelece um padrão útil de validação. Se um agente puder alterar a sua própria camada de orquestração, a unidade controlada de implementação deixa de ser apenas o modelo. Passa a incluir o modelo, a estrutura de execução, o executor, a política de ferramentas, o sistema de estado e o processo de promoção.
A pergunta de engenharia torna-se: esta versão concreta do sistema melhorou sob validação independente, com os controlos efetivamente ativos durante a execução? Para equipas que avançam para agentes autoaperfeiçoáveis, esse é um critério de lançamento mais defensável.