Avaliação de Agente

Avalie o comportamento observável do agente em relação a casos específicos da tarefa. Modificado por mantenedores do AAS em 05/09/2026 para remover alegações de benchmark não suportadas, corrigir relatórios de incerteza/erro e separar esboços de arquitetura opcionais do procedimento operacional.

Quando Usar

Use ao comparar um agente, prompt ou configuração de ferramenta alterados, reproduzir uma falha observada ou estimar a confiabilidade em uma distribuição de tarefas declarada. Não infira a prontidão do produto a partir de uma porcentagem de benchmark público ou um limite de pontuação genérico.

Pré-requisitos

• Um conjunto de casos versionado com resultados observáveis esperados e limites de permissão.
• Uma linha de base conhecida e uma revisão candidata, incluindo modelo, prompt, ferramentas, configuração e versões de tempo de execução.
• Entradas sintéticas ou redigidas autorizadas, alvos isolados e um orçamento limitado de tokens, tempo e custo.
• Um verificador que distingue resultados incorretos, rejeições seguras esperadas, falhas do avaliador e interrupções de infraestrutura. O acesso ao provedor é necessário apenas se a avaliação declarada chamar esse provedor.

Procedimento de Avaliação

1. Congele o contrato. Registre os IDs dos casos e a revisão do conjunto de dados, identidades da linha de base/candidato, ambiente de destino, plano de repetição, orçamentos, regra de parada e critérios de decisão antes da execução. Mantenha falhas críticas de segurança e autorização separadas da qualidade média; elas não podem ser compensadas por uma pontuação mais alta.
2. Valide o harness. Execute um caso de passagem conhecida, um caso de falha conhecida e uma falha deliberada do verificador/infraestrutura. Confirme se cada um é classificado corretamente e se a retenção de rastreamento exclui credenciais e corpos de entrada privados. Se a classificação estiver incorreta, corrija o harness e repita essas verificações antes de medir o agente.
3. Execute os casos congelados. Use as mesmas definições de caso e orçamentos para a linha de base e o candidato, com estado de fixture independente e ordem de execução registrada. Retenha todas as tentativas e seu ID de execução, resultado, motivo, latência e totais de recursos. Uma exceção não é evidência de que uma solicitação insegura foi rejeitada com segurança.
4. Investigue a variação. Preserve a falha original. Classifique o desacordo como comportamento do agente, contaminação de estado compartilhado, ambiguidade do verificador ou uma interrupção. Use apenas o orçamento de repetição pré-declarado; não tente novamente até que esteja verde, descarte silenciosamente falhas ou altere o resultado esperado para se adequar ao candidato. Uma falha de harness não resolvida torna o resultado afetado inconclusivo.
5. Compare e decida. Relate os resultados por caso e incerteza, regressões, falhas críticas e casos incompletos. Repetições de um caso não são amostras independentes da distribuição da tarefa. Uma expectativa alterada requer uma revisão de contrato separadamente revisada e novas execuções da linha de base e do candidato; mantenha os resultados antigos.
6. Corrija e verifique. Faça uma correção limitada, execute novamente o caso com falha para verificar o mecanismo e, em seguida, execute novamente a suíte de regressão congelada aplicável a partir de um estado limpo. Pare no orçamento declarado se o desacordo persistir. Registre passagem, falha ou inconclusivo com a evidência exata; siga o limite de aprovação de publicação/implantação do projeto separadamente.

Exemplo: tratamento alterado de argumento de ferramenta

Um agente sintético altera a forma como escolhe um identificador de locatário para uma consulta somente leitura. Congele três casos: uma consulta autorizada deve retornar a fixture semeada, um locatário não autorizado deve ser rejeitado sem uma chamada de ferramenta e uma interrupção simulada da ferramenta deve ser classificada como falha de infraestrutura. Não forneça registros de clientes reais nem credenciais de produção.

Pré-declare cinco repetições por caso com estado novo, o mesmo orçamento para a linha de base e o candidato, e tolerância zero para uma chamada de ferramenta não autorizada. Suponha que o candidato retorne o resultado autorizado esperado em todas as cinco execuções, mas faça uma chamada não autorizada no segundo caso: o candidato falha no contrato de permissão, mesmo que sua taxa de sucesso agregada melhore. Retenha essa execução, corrija a autorização do argumento, verifique o caso negativo e execute novamente a suíte congelada. Se o detector de interrupção travar, marque esse caso como inconclusivo e repare o detector antes de comparar as versões. Estes são resultados ilustrativos, não resultados de agente medidos.

Saída esperada:

contrato: revisão do conjunto de casos, regras, plano de repetição e orçamento
versões: linha de base, candidato, modelo, prompt, ferramenta e tempo de execução
execuções: um registro por tentativa, resultado classificado e referência de evidência limitada
comparação: resultados por caso, incerteza, regressões e violações críticas

…