Resumo Técnico: AEVAL – Da Avaliação Anecdótica à Testagem Determinística para Fluxos de Trabalho de Habilidades Agênticas

1. Declaração do Problema

Os sistemas agênticos modernos dependem cada vez mais de habilidades (skills): pacotes instaláveis que contêm especificações em linguagem natural (ex: SKILL.md), scripts e configurações que ensinam agentes de Large Language Model (LLM) como realizar tarefas de domínio. À medida que os repositórios de habilidades se expandem, o paradigma de avaliação atual é anedótico: desenvolvedores acionam manualmente uma habilidade, observam uma execução de demonstração e formam uma impressão subjetiva de seu sucesso.

Esta abordagem sofre de três deficiências críticas:

1. Falta de Reprodutibilidade: Duas execuções consecutivas podem exercitar caminhos de código diferentes ou produzir saídas distintas, levando a julgamentos inconsistentes dos desenvolvedores.
2. Falta de Comparabilidade: Impressões subjetivas não podem ser comparadas entre versões ou solicitações de fusão (MRs).
3. Problemas de Escalabilidade: Em marketplaces de múltiplas habilidades, uma única regressão pode quebrar silenciosamente dezenas de fluxos de trabalho subsequentes.

Além disso, um modo de falha técnica específico assola a avaliação agêntica ingênua: o Viés de Autocorreção (Self-Correction Bias). Quando o mesmo agente tanto executa quanto avalia uma habilidade, ele frequentemente corrige silenciosamente a habilidade ou sua configuração durante a execução para recuperar erros. O agente então avalia sua própria saída corrigida como um sucesso. Isso resulta em um sinal sistematicamente otimista que mede a capacidade de depuração do agente, em vez da qualidade intrínseca do artefato da habilidade.

2. Metodologia: O Framework AEVAL

O AEVAL (Avaliação Agêntica) é um framework integrado ao CI, projetado para substituir o teste anedótico por um pipeline de teste determinístico, acionado por mudanças, que trata cada modificação de habilidade como um evento de teste, executando um fluxo de cinco fases:

2.1. Contrato de Avaliação Definido pela Habilidade

Cada habilidade acompanha um arquivo eval.config localizado junto à sua especificação. Este contrato declara:

• Prompts de linguagem natural para casos de teste.
• Resultados esperados.
• Credenciais necessárias.
• Um mecanismo de fallback de três níveis garante a testabilidade mesmo sem configuração explícita.

2.2. O Pipeline de Cinco Fases

1. Examinar (Examine): O sistema detecta habilidades alteradas via git diff.
2. Instalar (Install): A habilidade modificada é instalada em uma sessão limpa.
3. Usar (Execução/Use): Um executor automatizado executa a habilidade contra o contrato.
   • Restrição: Uma regra rígida proíbe saídas simuladas. Se um comando falhar ou um serviço estiver inacessível, a falha é registrada como um resultado de teste real. Agentes não podem fabricar logs ou sintetizar resultados para passar em asserções.
4. Avaliar (Grading/Evaluate): Uma separação estrutural é aplicada entre o executor e o avaliador (grader).
   • Executor: Executa a habilidade e gera um transcrito ($\tau$) e saídas ($O$).
   • Avaliador (Grader): Um subagente separado, restrito a um conjunto de informações de leitura: o prompt de teste ($x$), o transcrito de execução ($\tau$), as saídas ($O$) e as asserções pré-execução ($A$).
   • Regra de Avaliação de Primeira Tentativa: O avaliador analisa as asserções contra a trajetória da primeira tentativa. Se o executor aplicou qualquer edição de autocorreção ($\Delta(\tau) \neq \emptyset$) que foi causalmente necessária para que uma asserção tivesse sucesso, essa asserção é marcada como FALHA (FAIL), independentemente do estado final.
5. Sugerir (Suggest): O sistema gera sugestões de correção baseadas nos resultados da avaliação.

2.3. Sugestões de Correção Niveladas e Fundamentadas

Para evitar o churn especulativo de "desejável, mas não essencial", as sugestões são estritamente fundamentadas em evidências:

• Fundamentação (Grounding): Toda sugestão deve citar uma asserção específica que falhou ou uma entrada de autocorreção rastreada.
• Nivelamento (Tiering):
  • LV1 (Causal): Correções causalmente implicadas na falha da primeira tentativa. Estas bloqueiam a solicitação de fusão (merge request).
  • LV2 (Consultivo/Advisory): Melhorias de qualidade ou robustez identificadas pelo avaliador que não causaram uma falha crítica.
• Entrega: As sugestões são postadas como comentários de linha (inline) no GitLab MR com diffs de "Aplicar sugestão", permitindo que os desenvolvedores apliquem patches empiricamente validados com um único clique.

3. Principais Contribuições

O artigo descreve quatro contribuições primárias:

1. Protocolo de Teste de Habilidade Determinístico: Um sistema de avaliação acionado por mudança com contratos por habilidade e esquemas de artefatos por execução, substituindo a avaliação manual por um pipeline de CI reproduzível.
2. Formalização do Viés de Autocorreção: A identificação e formalização do viés de autocorreção como um modo de falha distinto que surge do acoplamento estrutural entre execução e avaliação, em vez de escolhas específicas de modelos.
3. Separação Estrutural e Avaliação de Primeira Tentativa: Um protocolo que isola o avaliador do loop de execução e impõe uma regra de avaliação de primeira tentativa. Isso garante que o sinal de qualidade reflita a habilidade conforme entregue, e não a habilidade conforme corrigida pelo agente.
4. Sugestões Niveladas e Fundamentadas: Um mecanismo para entregar sugestões de correção como commits de um clique no MR, estritamente vinculados a evidências causais (LV1) ou feedback consultivo (LV2).

4. Resultados Empíricos

O framework foi validado contra uma stack agêntica de produção e múltiplos SDKs de agentes populares (incluindo agentes das famílias Claude e GPT).

• Eliminação de Viés: Em um estudo de caso envolvendo uma habilidade de segmentação deliberadamente degradada, um avaliador ingênuo relatou uma taxa de sucesso de 100% após o agente corrigir silenciosamente os nomes das ações. O AEVAL registrou a autocorreção, marcou as asserções relevantes como FALHA e reportou uma taxa de sucesso de primeira tentativa estritamente menor para o CI.
• Estabilidade: Antes da regra de "fundamentação em evidência", execuções repetidas do mesmo MR produziam conjuntos de sugestões distintos. Com a regra, as execuções repetidas convergiram para o mesmo conjunto LV1 causalmente fundamentado.
• Proibição de Simulação: Quando um cluster de GPU a jusante estava inacessível, versões anteriores produziam logs sintéticos. Sob o AEVAL, o agente registrou a falha de conectividade, permitindo que o CI a jusante distinguisse defeitos da habilidade de falhas ambientais.
• Calibração Cross-Runtime: O framework executou com sucesso a mesma habilidade através de diferentes backends de agentes. Embora as taxas de sucesso brutas tenham variado, a parcela causal (a fração de sugestões marcadas como bloqueio de fusão) forneceu uma métrica escalar reproduzível para comparar a severidade do avaliador. O Backend A (família Claude) teve uma parcela causal média de 0,41, enquanto o Backend B (família GPT) teve 0,82, revelando diferenças sistemáticas na forma como diferentes agentes interpretam a severidade.
• Eficiência de Custo: Com taxas de acerto de cache de prompt de 95–97%, o custo marginal de tokens para reexecutar o protocolo a cada push é baixo o suficiente para suportar a integração contínua.

5. Significância e Alegações

O artigo afirma que o AEVAL fornece uma garantia estrutural de que o sinal de avaliação é uma função da execução de primeira tentativa, e não do estado pós-correção.

• Bloco Fundamental: Os autores posicionam o teste de habilidade determinístico não como uma garantia de cobertura probabilística (como a predição conformal), mas como um componente upstream necessário que produz rótulos de verdade fundamental (ground-truth) binários e confiáveis. Esses rótulos são pré-requisitos para que métodos estatísticos a jusante (ex: predição conformal, quantificação de incerteza) funcionem corretamente.
• Mudança de Prática: O framework facilita a transição do "teste manual anedótico" para "pipelines de teste determinísticos acionados por mudança", espelhando a evolução da engenharia de software tradicional.
• Loop de Automação: Ao converter sinais de 100% de sucesso autorrealizáveis em sinais de falha de primeira tentativa auditáveis e fornecer patches de um clique, o AEVAL fecha o loop de teste-falha-correção, permitindo roteamento e decisões de parada confiáveis em fluxos de trabalho agênticos a jusante.

Os autores mantêm-se modestos quanto às limitações, reconhecendo que a proibição de saídas simuladas é aplicada por instrução (não por sandboxing) e que autocorreções complexas de múltiplos passos ainda podem ser mal atribuídas pelo avaliador. No entanto, eles afirmam que a separação estrutural entre executor e avaliador é o ingrediente central de confiabilidade necessário para o monitoramento estatisticamente rigoroso de fluxos de trabalho agênticos.