Evals para agent skills: como testar agentes sem achismo

TL;DR

Em vez de avaliar agentes só pela resposta final, o recorte de agent skills trata cada habilidade como um teste observável: entrada, execução rastreável, artefatos e verificações. Isso importa porque agentes acumulam erros ao longo de vários passos, então medir apenas o “resultado bonito” esconde regressões importantes.

Na prática, a mudança é sair de avaliações ad hoc e montar uma suíte com rubricas claras, checks determinísticos e, quando necessário, judges. Para times no Brasil, isso ajuda a proteger orçamento e tempo de experimentação, especialmente quando o custo de reexecutar fluxos com APIs pagas pesa em BRL e quando latência em regiões fora do país afeta jornada e confiabilidade.

O que muda quando o objeto de teste vira a habilidade do agente

O ponto central do material da OpenAI e da Anthropic é simples: agente não deve ser avaliado como se fosse apenas um gerador de texto. Ele interage com ferramentas, altera estado, toma decisões sequenciais e pode falhar em pontos intermediários mesmo quando a saída final parece aceitável.

Por isso, o foco sai de “qual foi a resposta?” e vai para “como a tarefa foi executada?”. Uma eval de habilidade pode verificar se o agente seguiu instruções, chamou a tool certa, respeitou limites de contexto, manteve o estado consistente e concluiu a tarefa sem quebrar contratos.

Essa mudança também melhora a comparabilidade. Quando o time grava traces e artefatos de execução, fica mais fácil responder se uma alteração de prompt, modelo ou orquestração melhorou o fluxo ou apenas mudou o estilo da resposta.

Da tarefa à suíte: como estruturar evals de agent skills

O desenho útil é parecido com o de testes de software, mas adaptado ao comportamento probabilístico. Cada habilidade vira uma unidade testável com um conjunto pequeno de casos.

Defina a habilidade: por exemplo, “seguir instruções em um ticket”, “chamar a ferramenta de busca corretamente” ou “resumir uma conversa sem perder restrições”.
Crie entradas representativas: casos simples, casos ambíguos e casos com restrições explícitas.
Capture a execução: trace, chamadas de ferramenta, artefatos gerados e estado intermediário.
Escreva checks: validações determinísticas quando possível e rubricas para o que depende de julgamento semântico.
Guarde scores por versão: isso permite comparar regressões ao longo do tempo.

O valor aparece quando a suíte deixa de ser uma coleção de testes soltos e passa a medir capacidades específicas. Assim, você consegue dizer que o agente piorou em “seguir instruções de formato”, mas melhorou em “selecionar ferramentas”.

undefined

Esse exemplo não pretende ser um framework pronto. Ele mostra a ideia operacional: transformar cada habilidade em critérios observáveis e reduzir a dependência de interpretação manual a cada execução.

Checks determinísticos e judges: quando usar cada um

O material da Anthropic destaca uma separação útil entre quatro coisas: o que medir, como medir, quais fontes de evidência usar e quais julgamentos precisam de um modelo avaliador. Na prática, isso vira um arranjo híbrido.

Checks determinísticos funcionam bem para contratos objetivos: presença de um campo, ordem de passos, uso correto de uma API, ausência de comportamento proibido, conformidade com schema. Já judges ajudam quando a métrica envolve intenção, aderência a instruções abertas ou qualidade de um resumo em linguagem natural.

O erro comum é usar LLM judge para tudo. Isso torna a avaliação opaca e pode esconder falhas em passos anteriores. O caminho mais robusto é deixar o judge para o que realmente exige interpretação, e manter o restante em regras simples e auditáveis.

Esta seção descreve a prática de avaliação dos materiais citados em 2025/2026. APIs e frameworks de agentes mudam rápido — confira o changelog oficial da ferramenta antes de adotar o fluxo em produção.

Rubrica curta é melhor do que critério genérico

Uma rubrica funciona melhor quando descreve sinais concretos. Em vez de “respondeu bem”, prefira critérios como “citou a ferramenta correta antes de agir”, “preservou a restrição de privacidade” ou “não executou ação fora do escopo pedido”.

Isso é especialmente útil em agentes com múltiplos passos, porque o erro costuma se propagar. Um pequeno desvio no início pode contaminar o restante do fluxo, então a avaliação precisa olhar trajetória, não só o desfecho.

Por que traces e artefatos valem ouro na regressão

Sem evidência de execução, a discussão vira opinião. Com trace e artefatos, a equipe consegue comparar versões do agente no tempo e entender onde o comportamento mudou.

Esse ponto é importante em qualquer stack, mas pesa mais quando o agente conversa com várias APIs ou executa ações externas. Se uma mudança de prompt melhora a taxa de sucesso, mas aumenta chamadas desnecessárias ou viola instruções com mais frequência, o score agregado pode mascarar um custo operacional maior.

Em times brasileiros isso aparece rápido no orçamento. Rodar muitas execuções contra APIs pagas, somado a variação cambial e limites de orçamento em BRL, faz diferença quando a suíte precisa ser repetida sempre que há alteração de prompt, modelo ou tool routing.

Outra dimensão local é latência. Em empresas que servem usuários no Brasil, depender só de infraestrutura fora da região pode tornar o avaliador menos fiel ao ambiente real, porque a experiência do agente muda conforme o tempo de resposta das ferramentas. Avaliar com traces ajuda a separar “erro de raciocínio” de “efeito de infraestrutura”.

Benchmarks mais ambientados e o que eles ensinam

O survey citado no brief e o próprio AgentBench apontam para uma evolução dos benchmarks: sair de tarefas muito estáticas e aproximar a avaliação de contextos com múltiplos ambientes. Isso faz sentido porque agentes não vivem só numa única resposta isolada.

Na prática, a lição é que uma suíte de evals precisa refletir o domínio real. Se o seu agente atende suporte, o benchmark deve incluir tickets com contexto quebrado, anexos faltando e instruções contraditórias. Se ele opera dados, precisa lidar com schema, permissões e estado parcial.

Quando o benchmark é réalista demais sem organização, ele fica caro e difícil de manter. Quando é simples demais, ele mede habilidade de prompt, não de agente. O equilíbrio está em definir o mínimo de ambiente necessário para capturar o comportamento que importa.

Um fluxo de trabalho enxuto para começar

Para sair da teoria sem montar uma operação pesada logo de início, vale seguir um recorte curto.

Escolha três habilidades críticas do seu agente.
Escreva cinco casos por habilidade, cobrindo caminho feliz, borda e restrição.
Registre traces e artefatos de cada run.
Crie checks objetivos primeiro e só depois adicione judges onde houver ambiguidade real.
Compare uma versão nova contra uma linha de base antes de liberar mudanças maiores.

Esse fluxo serve bem para startups, squads de plataforma e times internos em empresas brasileiras que precisam justificar custo antes de ampliar o uso de agentes. É uma forma de transformar discussão de “parece melhor” em “passou ou não passou”.

Por que importa pro dev brasileiro

No Brasil, construir e manter agentes costuma disputar orçamento com outras prioridades de produto e infraestrutura. Como muitos times pagam modelos e ferramentas em moeda forte, um conjunto de evals reduz o risco de testar mudança em produção só para descobrir depois que a regressão era previsível.

Há também um componente regulatório concreto. Se o agente toca dados pessoais, a LGPD exige cuidado com coleta, retenção e finalidade; isso torna importante medir não só qualidade, mas também vazamento de contexto, exposição indevida de informação e comportamento fora de política. Uma eval bem desenhada pode incluir checks para não transitar dados sensíveis sem necessidade.

Por fim, a realidade operacional brasileira inclui dependência frequente de regiões como us-east-1 e integrações externas com resposta variável. Evals com trace ajudam a separar falha do modelo, falha da tool e falha da infraestrutura, o que acelera diagnóstico em equipes enxutas.

Conclusão

Evals para agent skills são uma forma de deixar o comportamento de agentes testável, comparável e auditável. Em vez de confiar em avaliações pontuais, você passa a medir habilidades específicas com evidências de execução, checks objetivos e rubricas claras para os casos sem resposta binária.

Se o seu agente já integra ferramentas, manipula estado ou executa passos encadeados, vale tratar cada habilidade como uma experiência reproduzível. O próximo passo prático é pegar uma habilidade crítica do seu fluxo, escrever cinco casos e definir um score mínimo de aprovação antes da próxima mudança de prompt ou modelo.

Ação para a próxima hora: abra a documentação do Testing Agent Skills Systematically with Evals e escolha uma habilidade do seu agente para transformar em suíte de cinco casos com trace, checks e pontuação.

Conteúdos da DIO para quem quer aprofundar

Aceleração Microsoft AI Agents — trilha voltada a construção e uso de agentes de IA, útil para entender componentes que depois precisam ser avaliados com mais rigor.
Aceleração Automação de Testes #TQI — aborda automação de testes e princípios que ajudam a organizar checks repetíveis, inclusive para fluxos com agentes.
Formação Automação de Testes com Cypress — trilha prática sobre testes automatizados, boa referência para pensar em suíte, regressão e evidência de execução.
TestComplete X SGH — conteúdo relacionado a automação e qualidade, útil para quem quer comparar testes tradicionais com avaliação de comportamento de agentes.
TestComplete e banco de dados ágil — mostra uma visão de testes conectados a estado e dados, um paralelo importante para agentes que alteram contexto ao longo do fluxo.
Trilha de Conhecimento - Analista de Teste — cobre fundamentos de qualidade e análise de cenários, base útil para desenhar rubricas e casos representativos.