Resumo Técnico: AgentLens

Declaração do Problema

Os atuais benchmarks de agentes de codificação reduzem predominantemente a avaliação a um resultado binário: o agente passou no teste final ou não? Embora seja suficiente para leaderboards de pesquisa, essa métrica de "bit único" falha em capturar a realidade dos assistentes de codificação interativos usados em produção. Uma tarefa pode passar em uma verificação estreita enquanto o agente exibe comportamento não confiável, excesso de confiança, uso inadequado de ferramentas ou desalinhamento com a intenção do usuário. Por outro lado, uma execução que falha em uma verificação final pode ter demonstrado comportamentos intermediários valiosos, como localização correta de bugs ou recuperação graciosa de erros.

O problema central é a falta de um benchmark que avalie a trajetória completa da interação do agente. Desenvolvedores precisam entender não apenas se uma tarefa foi concluída, mas como ela foi concluída: como o agente seguiu instruções, usou ferramentas, verificou o trabalho, recuperou-se de erros e comunicou-se com o usuário. Os benchmarks existentes frequentemente colapsam essas dinâmicas em estados finais ou dependem de tarefas simples demais para refletir os fluxos de trabalho diários dos desenvolvedores.

Metodologia

AgentLens é um benchmark avaliado em ambiente de produção, projetado para avaliar agentes de código interativos analisando trajetórias completas de interação. A metodologia combina verificação formal com revisões qualitativas impulsionadas por LLM.

1. Conjunto de Tarefas e Simulação

• Definição de Trajetória: Uma trajetória inclui o registro completo da sessão: mensagens do usuário (simuladas), respostas do agente, chamadas de ferramentas, edições de arquivos, execuções de comandos, tentativas de verificação e o estado final do repositório.
• Geração de Tarefas: Os cenários são derivados de entrevistas com programadores (relembrando trabalhos recentes) e resumos de uso de produção anonimizados. Eles são organizados em fluxos de trabalho envolvendo inspeção de código, edição, documentação, depuração e testes.
• Personas de Usuário: O benchmark utiliza usuários simulados por LLM com personas distintas para testar a robustez do agente:
  • Padrão (Default): Um usuário relaxado que intervém apenas em caso de falha clara.
  • Prestativo (Helpful): Um usuário cooperativo que oferece orientação sobre erros.
  • Tóxico (Toxic): Um usuário levemente frustrado que desafia o agente, mas mantém o objetivo da tarefa.
• Escala: O lançamento inicial inclui 16 cenários executados com duas personas cada, gerando 32 trajetórias por agente.

2. Protocolo de Avaliação

O AgentLens avalia cada trajetória usando dois mecanismos complementares:

A. Verificação Formal
Verificações objetivas são aplicadas onde possível, incluindo:

• Verificações de Estado do Repositório: Garantir que apenas arquivos permitidos foram modificados e que os arquivos alvo foram alterados.
• Verificações de Regex: Verificar padrões específicos no código, argumentos de ferramentas ou histórico de chat.
• Execução de Testes: Executar suítes de teste (ex: via Maven/Gradle) e verificar a cobertura.
• Análise Estática: Invocar ferramentas de IDE para detectar erros ou avisos.
  Uma execução passa na verificação formal apenas se todos os verificadores aplicáveis forem aprovados.

B. Revisões de Juiz LLM (LLM Judge Reviews)
Juízes de LLM revisam a trajetória completa através de cinco dimensões específicas, produzindo tanto uma pontuação quanto uma narrativa escrita baseada em evidências:

1. ENDRESULT (Resultado Final): Completude e adequação ao propósito em relação ao resultado final.
2. INSTRUCTIONCOMPLIANCE (Conformidade de Instrução): Adesão a regras explícitas, restrições de ordem e meta-instruções.
3. PITFALLS (Armadilhas): Identificação de falhas comportamentais corrigíveis (ex: uso indevido de ferramentas, loops não produtivos, conclusão prematura, falta de validação).
4. PLEASANTNESS (Agradabilidade): Qualidade da interação com o usuário (clareza, precisão, utilidade, produtividade).
5. TOOLCALLS (Chamadas de Ferramentas): Qualidade do uso de ferramentas, incluindo escolha, correção de argumentos e recuperação de erros.

C. Agregação e Métricas

• Índice de Qualidade (QI): Uma pontuação agregada única calculada como a média não ponderada das cinco métricas do juiz e da taxa de aprovação da verificação formal.
• Revisões Lado a Lado (Side-by-Side): Para análise comparativa, um juiz pareado compara dois agentes na mesma tarefa, usando revisões de trajetória única prévias como evidência primária para minimizar o viés de posição.
• Telemetria: Estatísticas rígidas (latência, custo, throughput de tokens, taxas de sucesso de chamada de ferramenta) são coletadas para quantificar a confiabilidade operacional.

3. Verificações de Confiabilidade e Viés

Os autores realizaram várias verificações para garantir a robustez:

• Análise de Variância: Execuções repetidas mostraram que a variância está concentrada na verificação formal (conclusão instável da tarefa) e não na pontuação do juiz.
• Viés de Posição: Testes de inversão de ordem indicaram que as pontuações lado a lado são amplamente insensíveis à ordem de apresentação do agente.
• Auto-preferência do Juiz: Embora os juízes tenham mostrado uma leve preferência por suas próprias famílias de modelos (particularmente na métrica subjetiva de "Agradabilidade"), o efeito foi pequeno e não alterou o vencedor médio nas comparações de modelos de fronteira.

Principais Resultados

O benchmark foi avaliado em tarefas de codificação Java usando vários modelos (ex: Opus 4.7, GPT-5.5, DeepSeek V4, Gemini 3.1) através de dois harnesses (Explyt AI Agent e Claude Code).

• Rankings Divergentes: O Índice de Qualidade (QI) do AgentLens correlaciona-se moderadamente com benchmarks públicos (ex: Spearman $\rho = 0.82$ com APEX-Agents), mas diverge significativamente de benchmarks focados em raciocínio. Modelos otimizados para tarefas de raciocínio acadêmico frequentemente ranqueiam abaixo no AgentLens, enquanto modelos construídos para uso sustentado de ferramentas ranqueiam acima.
• Insights Diagnósticos:
  • Gemini 3.1 Pro Preview: Desempenhou abaixo do esperado devido a problemas de confiabilidade no loop do agente (pular etapas, edições prematuras), em vez de capacidade de geração de código.
  • DeepSeek V4 Pro vs. Flash: O Pro demonstrou melhor conformidade de instrução e controle, enquanto o Flash alcançou maior throughput e taxas de conclusão ao relaxar restrições.
  • Kimi K2.6: Ficou em último lugar, mas a revisão revelou que a falha foi um erro de parser de ferramenta do lado do provedor (argumentos malformados), não uma falta de capacidade de raciocínio.
  • Detecção de Regressão: O pipeline noturno identificou com sucesso uma condição de corrida em chamadas de ferramentas paralelas que causava uma ConcurrentModificationException, que era invisível na resposta final, mas capturada na revisão da trajetória.

Significância e Contribuições

O artigo reivindica as seguintes contribuições:

1. Benchmark Avaliado em Produção: Um framework que avalia agentes de código interativos com base em fluxos de trabalho realistas de múltiplos passos, em vez de estados finais isolados.
2. Protocolo de Nível de Trajetória: Um método de avaliação inovador que combina verificação formal com revisões escritas por LLM que explicam por que uma pontuação foi atribuída, separando a qualidade do resultado da qualidade do processo.
3. Utilidade Diagnóstica: O sistema é projetado não apenas para ranking, mas para diagnosticar o comportamento do modelo, comparar versões e detectar regressões de produto em um pipeline de integração contínua.
4. Lançamento Open Source: O código do benchmark, as dobras de tarefas e o pipeline de avaliação são lançados publicamente para facilitar mais pesquisas e adoção.

Os autores concluem que o campo de benchmarks de agentes de codificação está subatendido no que diz respeito à avaliação semelhante à de produção. O AgentLens visa preencher esse nicho ao fornecer uma "explicação legível" do desempenho do agente, permitindo que desenvolvedores priorizem correções baseadas em modos de falha específicos (ex: instabilidade de ferramenta vs. conformidade de instrução) em vez de uma métrica única e opaca.