Resumo Técnico: ReProAgent

Definição do Problema

Relatórios de problemas em repositórios de software de código aberto (ex: GitHub) raramente incluem testes executáveis que reproduzam os bugs relatados. Essa ausência impede que desenvolvedores confirmem os problemas antes de corrigi-los e validem patches posteriormente, aumentando significativamente os custos de depuração e manutenção. Embora abordagens recentes baseadas em Grandes Modelos de Linguagem (LLMs) tenham tentado gerar esses "testes de reprodução" (testes que falham no código com erro, mas passam no código corrigido), os métodos existentes dependem amplamente de pipelines de prompts fixos. Esses pipelines tipicamente recuperam contexto textual e geram testes diretamente, sofrendo de duas limitações fundamentais:

1. Compreensão de Contexto Limitada: Eles têm dificuldade em compreender o comportamento do problema em bases de código de escala de repositório, particularmente dependências comportamentais entre arquivos, pois dependem primariamente de recuperação baseada em texto.
2. Falta de Planejamento Estruturado: Eles tratam a geração de testes como um mapeamento direto de contexto para código, falhando em modelar explicitamente o processo de raciocínio de múltiplas etapas (localização de bug, análise de causa raiz, construção de configuração de teste e verificação) que os desenvolvedores humanos utilizam.

Metodologia: ReProAgent

Os autores propõem o ReProAgent, um framework de agente multiestágio e auxiliado por ferramentas, projetado para decompor a tarefa complexa de geração de testes de reprodução em quatro estágios agênticos distintos. Inspirado no fluxo de trabalho manual de desenvolvedores, o framework integra três categorias de ferramentas para suportar a exploração autônoma e a tomada de decisão.

1. Conjunto de Ferramentas do Agente (Agent Toolset)

O ReProAgent equipa o LLM com um conjunto de ferramentas dedicado para facilitar o raciocínio e a interação:

• Ferramentas de Decomposição de Tarefas e Reflexão: Utiliza Sequential-Thinking para decompor objetivos complexos, manter trajetórias de raciocínio e revisar decisões dinamicamente com base em feedback intermediário.
• Ferramentas de Recuperação de Contexto Híbrido: Combina a recuperação baseada em palavras-chave via linha de comando (ex: grep, glob) com a recuperação de dependências baseada em Grafo de Conhecimento (KG). O KG é construído usando Tree-sitter para extrair entidades de programa (classes, funções) e seus relacionamentos semânticos, permitindo que o agente rastreie cadeias de chamadas e dependências entre arquivos.
• Ferramentas de Interação em Tempo de Execução: Inclui um sandbox baseado em Docker para executar comandos e scripts Python interativos, permitindo que o agente observe o comportamento de execução dinâmica e valide hipóteses.

2. Fluxo de Trabalho Agêntico de Quatro Estágios

O processo de geração é organizado em quatro estágios sequenciais:

• Estágio 1: Localização de Bug via Análise Hierárquica
  O agente constrói uma consulta inicial a partir do relatório do problema (sintomas, stack traces) e utiliza recuperação híbrida para identificar arquivos suspeitos. Em seguida, realiza uma análise de grosso a fino, classificando funções e classes por relevância semântica e refinando a busca até linhas de código específicas. O agente fornece justificativas em linguagem natural e pontuações de confiança para cada região suspeita.

• Estágio 2: Análise de Causa Raiz via Caminho de Execução
  Usando as localizações suspeitas e a descrição do problema, o agente rastreia o caminho de execução desde o ponto de entrada até o ponto de falha. Ele reconstrói a cadeia de chamadas para identificar o defeito lógico subjacente (ex: verificações de condição incorretas, tratamento de limites). A saída é um relatório estruturado detalhando o resumo da causa raiz, categoria de erro, caminho de execução, condições de gatilho e uma pontuação de confiança.

• Estágio 3: Planejamento de Teste Consciente de Asserções
  Antes de gerar o código, o agente deriva um plano de teste estruturado. Isso envolve analisar as condições de gatilho, construir a configuração de reprodução (restrições de ambiente, dependências) e derivar as asserções necessárias. O plano especifica os inputs mínimos necessários para expor o bug e os sinais de falha esperados (ex: tipos específicos de exceção ou valores de retorno incorretos).

• Estágio 4: Geração de Teste via Revisão Triádica
  O agente gera um teste candidato baseado no plano e o executa no sandbox. Um processo de Revisão Triádica avalia o teste contra três critérios:

  1. Alinhamento semântico com o relatório do problema.
  2. Consistência da falha observada com a lógica do teste (descartando erros de sintaxe ou de ambiente).
  3. Correspondência entre o resultado da execução e o problema relatado (mensagem de erro, tipo de exceção).
     Se o teste falhar na revisão ou passar quando deveria falhar, o agente refina iterativamente o teste usando o feedback até que uma reprodução válida seja alcançada ou o orçamento de iteração se esgote.

Principais Contribuições

1. Framework de Agente Multiestágio: A proposta do ReProAgent, que decompõe a geração de testes de reprodução em localização de bug, análise de causa raiz, planejamento de teste e geração de teste, indo além de pipelines de prompting fixos.
2. Conjunto de Ferramentas Específicas para a Tarefa: O design de um conjunto de ferramentas especializado incluindo pensamento sequencial para reflexão, recuperação híbrida (texto + grafo de conhecimento) para contexto e interação em tempo de execução para validação.
3. Avaliação Abrangente: Experimentos abrangentes demonstrando que o ReProAgent supera as linhas de base de estado da arte, generaliza-se através de múltiplos backbones de LLM e melhora as tarefas de reparo automatizado subsequentes.

Resultados Experimentais

O framework foi avaliado no SWT-bench-lite e SWT-bench-verified, dois benchmarks especificamente desenhados para a geração de testes de reprodução de problemas.

• Desempenho: O ReProAgent alcançou uma Taxa de Falha-para-Passagem (FP) de 58,43% no SWT-bench-lite e 70,30% no SWT-bench-verified.
• Comparação: Superou significativamente todas as linhas de base. Por exemplo, no SWT-bench-lite, melhorou o forte baseline AssertFlip em 53,76% e o OpenHands (usando o mesmo backbone GPT-5-mini) em 20,43 pontos percentuais.
• Generalização: O framework demonstrou desempenho robusto através de diferentes backbones de LLM (GPT-5-mini, Qwen3-Coder, DeepSeek-V3.2, GLM-4.6), com taxas médias de FP variando de 50,43% a 64,37%, indicando que a eficácia é impulsionada pelo design do framework e não por um único modelo.
• Impacto Subsequente: Quando integrado com frameworks de reparo existentes (SWE-agent e Agentless), os testes gerados pelo ReProAgent melhoraram o número de problemas resolvidos com sucesso (ex: aumentando a taxa de sucesso do SWE-agent no SWT-bench-lite de 143 para 153).
• Custo: O custo médio por instância foi de $0,14 (usando GPT-5-mini), o que é competitivo com outras linhas de base e acessível para aplicação prática.

Significância

O artigo afirma que o ReProAgent aborda a lacuna crítica na engenharia de software automatizada onde os relatórios de problemas carecem de especificações executáveis. Ao mimetizar o raciocínio estruturado de múltiplas etapas de desenvolvedores humanos e integrar o contexto de escala de repositório com a verificação em tempo de execução, o ReProAgent permite a geração confiável de testes de reprodução. Essa capacidade não apenas valida a correção de patches, mas também serve como um poderoso sinal de feedback para fluxos de trabalho de reparo automatizado iterativo, reduzindo assim o custo de depuração e manutenção de software. Os autores enfatizam que o sucesso do framework reside em sua capacidade de lidar com dependências complexas entre arquivos e em seu rigoroso processo de revisão triádica, que garante que os testes gerados reproduzam fielmente os problemas relatados, em vez de meramente gerar código sintaticamente correto.