Resumo Técnico: Harness de Agentes Autoevolutivos via Diversidade-Qualidade Semântica com Portões (Gated)

1. Declaração do Problema

O desempenho de um agente de Large Language Model (LLM) em tarefas do mundo real é determinado não apenas pelos pesos do modelo, mas significativamente pelo seu "harness" — o andaime de tempo de execução circundante, incluindo prompts de sistema, conhecimento injetado, loops de controle, definições de ferramentas e configuração. Em implantação, os pesos do modelo são frequentemente congelados (devido a custo, licenciamento ou aluguel), deixando o harness como a única alavanca ajustável.

Abordagens atuais para a autoevolução de harnesses de agentes enfrentam dois desafios primários:

1. Feedback Não Confiável: O feedback autogerado é ruidoso. Ganhos aparentes podem ser artefatos de medição (ex: sandboxes instáveis, timeouts de verificadores) ou flutuações estatísticas em vez de melhorias genuínas.
2. Overfitting e Colapso: Sem uma busca estruturada, loops de otimização tendem a sofrer overfitting para tarefas de treinamento específicas ou colapsar em um conjunto estreito de edições "seguras" (tipicamente pequenos ajustes de prompt), falhando em abordar modos de falha mais profundos.

Métodos existentes frequentemente carecem de rigor estatístico, baseando-se em taxas de passagem de pico sobre rodadas ruidosas sem validação de teste (held-out), tornando os ganhos relatados não auditáveis e propensos ao overfitting.

2. Metodologia

O artigo propõe um framework que separa a proposta de mudanças da creditação dessas mudanças, utilizando um agente de tarefa congelado e um modelo "evolver" separado e mais forte.

2.1 Arquitetura do Sistema

• Agente de Tarefa Congelado: O modelo sendo otimizado ($M$) permanece congelado. Ele executa tarefas dentro de um harness mutável ($H$).
• Agente Evolver: Um modelo separado e mais forte ($D \neq M$) diagnostica falhas nas trajetórias do agente de tarefa e propõe patches semânticos.
• Camada de Medição Determinística: Todo o amostragem, pontuação e testes de significância são tratados por código determinístico, não pelo LLM, garantindo reprodutibilidade.

2.2 O Loop de Autoevolução

O processo segue uma estrutura de funil (Figura 1):

1. Diagnóstico: O evolver lê traços de falha e atribui uma coordenada de (onde $\times$ por que) a cada falha.
   • Onde: A superfície mutável tocada (Prompt, Conhecimento, Runtime, Config).
   • Por que: A patologia específica da falha (ex: "pensamento desenfreado", "finalização prematura").
2. Proposta: O evolver projeta patches (git commits) visando patologias específicas.
3. Poda de Preflight: Verificações de zero-inferência descartam candidatos que declaram nenhuma ativação ou que possuem gatilhos que nunca dispararam.
4. Triagem e Validação:
   • Tela de Âncora (Anchor Screen): Um subconjunto barato ($K=1$) filtra perdedores grosseiros.
   • Avaliação Completa: Os sobreviventes são executados no conjunto de treinamento completo ($K=3$).
5. Creditação de Três Portões (Three-Gate Crediting): Um patch só é creditado se passar por:
   • Portão de Validade: Garante que o ambiente esteja saudável (sem crashes de sandbox/timeouts). Falhas de infraestrutura são reexecutadas, não contadas como falhas do agente.
   • Portão de Ativação: O patch deve ter realmente disparado durante o teste.
   • Portão de Significância: Requer um teste pareado de 2$\sigma$ ($z \ge 1.96$) no mesmo conjunto de tarefas para distinguir ganhos reais de ruído.

2.3 MAP-Elites Semântico com Portões (GSME)

Para prevenir o overfitting e o colapso da busca, as edições são organizadas em um arquivo de Qualidade-Diversidade (QD) categórico:

• Indexação: As células são indexadas pela patologia (onde $\times$ por que), não pela tarefa específica. Isso atua como um viés indutivo contra o overfitting.
• Estrutura: Um "elito com portão" (melhor patch) é mantido por célula.
• Seleção e Variação: O sistema utiliza seleção enviesada por qualidade (expandindo o melhor global) combinada com recombinação entre células (empilhando elites de diferentes células de patologia). Isso permite que o sistema descubra combinações sinérgicas (ex: um fix de runtime + um fix de prompt) sem o custo de uma exploração uniforme.

2.4 Protocolo de Avaliação

• Teste Selado (Sealed Test): Um conjunto de teste retido é completamente isolado do evolver durante todo o processo. Ele é pontuado uma única vez após a terminação da evolução.
• Terminação: O loop para se nenhum candidato superar a linha de base vanilla no treinamento por $P$ rodadas ou se um limite de rodadas $R$ for atingido.
• Métrica: O desempenho é medido por Retenção (ganho no selado / ganho no treinamento) e Ganho Creditado (ganho no selado passando pelo limiar de 2$\sigma$).

3. Principais Contribuições

1. Loop de Autoevolução Auditável: Um sistema reprodutível onde o LLM detém a semântica (diagnóstico/patches) e o código determinístico detém o julgamento quantitativo (amostragem/significância). Isso garante que cada melhoria creditada seja atribuível e reprodutível.
2. MAP-Elites Semântico com Portões (GSME): Uma estrutura de arquivo inovadora indexada por patologias de falha, em vez de tarefas. O artigo fornece evidências de que esta estrutura permite a recombinação entre células, permitindo que o sistema aceite edições diversas (runtime, config, conhecimento) em vez de colapsar para apenas ajustes de prompt.
3. Evidência de Generalização: O framework demonstra que os ganhos generalizam em vez de sofrer overfitting. Em seis domínios, os ganhos no teste selado retiveram 86–147% dos ganhos de treinamento, com todos os ganhos ultrapassando a barra de significância de 2$\sigma$ pareada.
4. Correspondência de Patologia Específica do Modelo: A pesquisa mostra que o "patch vencedor" rastreia o modo de falha dominante do modelo específico (ex: "descuidado $\to$ enviar-verificar" para alguns modelos, "engajamento $\to$ verificar-finalizar" para outros), em vez de ser uma solução universal. A contribuição transferível é o loop de diagnóstico-e-creditação, não uma configuração de harness específica.

4. Resultados Experimentais

O framework foi avaliado em sete domínios de três fontes (Terminal-Bench-2, suíte EvoAgentBench, AppWorld) usando um modelo de pesos abertos congelado (Qwen3.6-27B).

• Ganhos de Desempenho: O harness selecionado no treino alcançou ganhos creditados de +9 a +15,5 pontos percentuais (pp) no teste selado.
• Generalização:
  • TB2: +9,3 pp (Retenção: 147%)
  • LiveCode: +13,7 pp (Retenção: 86%)
  • Omni-MATH: +11,7 pp (Retenção: 115%)
  • BrowseComp+: +13,9 pp (Retenção: 88%)
  • GDPval: +9,2 pp (Retenção: 109%)
  • AppWorld: +15,5 pp (Retenção: 87%)
  • SWE-bench: +5,1 pp (Não creditado devido ao baixo tamanho de amostra $n=26$ falhando na barra de 2$\sigma$, embora direcionalmente positivo).
• Diversidade de Edições: As edições aceitas abrangeram todas as quatro alavancas (Prompt, Conhecimento, Runtime, Config), evitando o colapso para edições apenas de prompt observado em trabalhos anteriores.
• Validação Cross-Model: Experimentos no AppWorld com Qwen3.5 e Gemini 3 Flash confirmaram que o loop se adapta a diferentes famílias de modelos ao identificar suas patologias dominantes específicas.

5. Significância e Alegações

O artigo alega que o principal gargalo para melhorar agentes de LLM congelados não é gerar mudanças, mas saber quais mudanças realmente ajudaram. Ao desacoplar a proposta da creditação e impor rigor estatístico estrito em um teste selado, os autores demonstram que:

• A autoevolução pode ser tornada confiável por construção, evitando o overfitting e a inflação de ruído comuns na literatura de auto-otimização anterior.
• A generalização é alcançável em um regime de pesos congelados, com harnesses evoluídos retendo a maioria de seus ganhos de treinamento em dados não vistos.
• O loop de diagnóstico-e-creditação é o mecanismo transferível. Os patches específicos encontrados são específicos do modelo, mas a metodologia para encontrá-los aplica-se a diferentes famílias de modelos e domínios de tarefas.

O trabalho redefine a autoevolução de harness não como a descoberta de um scaffold "universalmente bom", mas como o ajuste de patches corretivos para a distribuição de falhas de um modelo específico, com o próprio loop servindo como o motor robusto e generalizável para essa adaptação.