Evals para agent skills: como testar agentes com método

TL;DR

Testar “agent skills” deixou de ser uma tarefa informal de prompt review e passou a exigir algo mais próximo de engenharia de software: casos representativos, replay determinístico, métricas objetivas e evidência da execução. Na prática, isso ajuda a separar se o problema está na habilidade do agente, no uso de ferramentas ou no custo/latência da solução.

O ecossistema atual converge em frameworks como OpenAI Evals, promptfoo e DeepEval, quase sempre combinados com tracing para auditoria e comparação entre versões. Para times no Brasil, isso faz diferença quando o orçamento é em BRL, a latência para regiões externas pesa na experiência e a LGPD exige mais cuidado com dados usados nos testes.

O que muda quando a unidade de teste vira a “skill”

O ponto central do brief é simples: não faz sentido avaliar apenas o agente inteiro como uma caixa-preta se você quer evoluir com consistência. Uma “skill” pode ser algo como planejar, extrair campos, chamar uma ferramenta, seguir um formato ou decidir quando pedir ajuda.

Essa mudança de granularidade é útil porque falhas diferentes pedem análises diferentes. Um agente pode acertar a resposta final e ainda assim gastar tokens demais, invocar a ferramenta errada ou deixar rastros insuficientes para auditoria.

Frameworks do ecossistema já apontam nessa direção. OpenAI Evals fala em registros de evals e custom evals; promptfoo documenta explicitamente testes de agent skills com métricas de invocação, qualidade da tarefa, custo, latência e evidência; DeepEval se posiciona como framework para avaliar aplicações LLM, incluindo agentes e RAG.

Exemplo prático de recorte

Se a habilidade que importa é “extrair um número de protocolo e devolver em JSON”, o teste não deveria medir só se a resposta “parece boa”. Ele precisa verificar se o JSON é válido, se o campo obrigatório existe, se o valor bate com a entrada e se o runtime ficou dentro de um limite aceitável.

Se a habilidade é “decidir quando usar ferramenta”, o teste deve inspecionar o trace: a ferramenta foi chamada? foi chamada no momento certo? a saída explica essa decisão? Isso reduz discussões subjetivas em revisão manual.

Como montar um harness de avaliação repetível

O padrão mais útil é montar um harness que rode sempre o mesmo conjunto de casos e produza um relatório comparável em CI. A lógica é parecida com testes unitários, mas adaptada ao comportamento probabilístico do agente.

O fluxo mais robusto tem quatro etapas:

1. Gerar entradas representativas do uso real, cobrindo casos fáceis, ambíguos e de borda.
2. Executar em modo de replay, com configuração fixa de modelo, instruções e ferramentas.
3. Avaliar com rubrica, juiz ou verificadores estruturados, dependendo do tipo de saída.
4. Registrar evidência para depuração: entradas, saídas, tool calls, latência e custo.

Esse desenho é consistente com o que o brief identifica como prática recorrente no ecossistema: frameworks de avaliação, métricas plug-and-play e integração com tracing. A diferença entre equipes está menos na ideia e mais na disciplina de manter o conjunto de testes vivo.

Se o harness depende de versão específica de SDK, API ou CLI, vale registrar isso no próprio eval. APIs de IA mudam rápido; confira o changelog oficial antes de adotar qualquer configuração em produção.

O que vale medir além de “passou ou falhou”

Para agent skills, qualidade sozinha costuma esconder problemas. Um teste mais útil mede também custo e latência, porque uma skill que “funciona” mas custa caro demais ou demora para responder pode inviabilizar uso em produção.

O briefing destaca isso com clareza no material do promptfoo: qualidade da tarefa, custo, latência e evidência de execução. Na prática, esse conjunto ajuda a detectar regressão mesmo quando a taxa de acerto permanece estável.

Outro ponto importante é estruturar o score de forma que ele seja comparável ao longo do tempo. Em vez de depender de uma opinião textual do juiz, transforme o resultado em um número ou categoria que o pipeline consiga acompanhar em gráficos e alertas.

Rubricas, juízes e verificadores estruturados

Há três formas comuns de transformar a saída do agente em algo testável. A primeira é a rubrica: um conjunto de critérios avaliados por um LLM-juiz ou por revisão humana. A segunda é o verificador estruturado, que usa regras como schema JSON, regex ou validação de campos. A terceira combina as duas abordagens.

A primeira é boa quando o problema é semântico, como avaliar se a explicação ficou coerente com o contexto. A segunda é melhor quando existe um contrato claro, como formato de resposta, presença de campos ou sequência de chamadas de ferramenta. A combinação é o que geralmente traz mais sinal.

Como o brief aponta, OpenAI Evals e DeepEval convergem nessa ideia de permitir dimensões customizadas e métricas próprias. Isso é relevante porque uma skill raramente cabe em um único número universal; cada caso de uso pede o seu próprio critério de sucesso.

Evite o teste que só “parece bom”

Uma armadilha comum em agentes é aceitar respostas plausíveis demais. O texto soa correto, mas não há prova de que a habilidade está funcionando de fato. Para evitar isso, crie verificadores objetivos sempre que possível.

Exemplo: se o agente precisa devolver um JSON, valide o schema. Se ele precisa acionar uma ferramenta, valide o evento no trace. Se ele precisa citar uma fonte, valide a presença do link ou do identificador esperado. Isso reduz falso positivo em avaliação.

Tracing como parte do eval, não como luxo

O brief chama atenção para um ponto importante: tracing não é só observabilidade de produção, mas parte do ciclo de avaliação. Quando você consegue ver a sequência de decisões do agente, fica mais fácil entender por que um caso passou ou falhou.

Isso importa ainda mais em agentes que usam várias ferramentas. Sem evidência de execução, a equipe acaba discutindo sintomas. Com traços, dá para comparar versões e achar onde a skill mudou de comportamento.

O ecossistema citado no brief inclui integrações que capturam inputs, outputs e feedback para depuração. Esse tipo de registro é especialmente valioso quando a skill depende de chamadas externas, porque o problema pode estar no raciocínio, na ferramenta ou no contrato entre ambos.

Como isso se encaixa num time de produto

Na prática, a avaliação de agent skills precisa entrar no mesmo ritual de qualidade que já existe para API, frontend e banco. Se a equipe tem versionamento de esquema e testes automatizados, faz sentido tratar habilidades de agente com a mesma seriedade.

Um modelo operacional simples é manter um conjunto de casos fixos no repositório, rodá-los em CI a cada alteração de prompt, ferramenta ou modelo e bloquear promoção quando os indicadores críticos piorarem. Isso reduz a tentação de “colar” em uma demo boa e só descobrir regressão depois.

Para times com múltiplos agentes, a seleção da skill certa para teste evita uma suíte inchada e cara. Teste o comportamento que de fato é arriscado ou caro; o restante pode ficar em amostragens menos frequentes.

Por que isso importa pro dev brasileiro

No Brasil, há três pressões concretas que tornam esse tema mais sensível. A primeira é custo em BRL: quando o orçamento vem comprimido pela cotação do dólar, cada rodada de eval mal desenhada vira gasto visível no mês. A segunda é latência: em muitos produtos, rodar tudo em regiões externas aumenta tempo de resposta e degrada a experiência. A terceira é LGPD, porque usar dados reais em testes exige cuidado com retenção, base legal e anonimização.

Além disso, boa parte dos times brasileiros mistura produtos digitais, integrações legadas e ciclos curtos de entrega. Isso faz com que o ganho de um harness repetível seja prático: menos tempo debatendo se o agente “está bom” e mais tempo olhando evidência de execução e regressão objetiva.

Em empresas com dados sensíveis, esse cuidado é ainda mais relevante. Testes com prompts reais, logs de usuário e históricos de atendimento podem expor informações pessoais se não houver política clara de amostragem e sanitização.

Um fluxo mínimo para começar sem virar projeto infinito

Se você quer começar de forma realista, não tente cobrir o universo inteiro do agente de uma vez. Escolha uma skill crítica, defina 10 a 30 casos representativos e crie três camadas de validação: estrutura, semântica e custo/latência.

Depois, conecte isso ao seu pipeline de CI para rodar em toda mudança relevante. A partir daí, o ganho vem da repetição: comparar versões, notar deriva e documentar o que mudou no comportamento do agente.

O ideal é que cada falha gere uma ação objetiva. Ou a skill precisa de regra estrutural mais rígida, ou a rubrica precisa de ajuste, ou o uso de ferramenta precisa ser separado em etapa explícita.

Esta seção descreve uma forma de trabalho, não uma receita fechada. O valor vem de manter o conjunto de testes pequeno o bastante para rodar sempre e rico o bastante para capturar as falhas que realmente importam.

Fechamento

Sistematizar evals para agent skills é, no fundo, tornar o comportamento do agente auditável, comparável e barato de repetir. Quando isso acontece, a equipe para de depender de impressões soltas e passa a enxergar regressão, custo e qualidade no mesmo painel.

Se você já tem um agente em produção, escolha uma habilidade crítica e transforme essa habilidade em 10 casos de teste com verificadores estruturados antes do fim do dia útil de uma sprint. Isso cabe em menos de uma hora de trabalho inicial e já cria uma base melhor do que depender de revisão manual ad hoc.

Conteúdos da DIO para quem quer aprofundar

• Aceleração Microsoft AI Agents — Evento prático sobre agentes de IA, com foco em construção e orquestração de soluções usando ferramentas do ecossistema Microsoft.
• Microsoft Certification Challenge #5 - AI 102 — Trilha voltada para projetar e implementar soluções de IA no Azure, útil para quem quer avaliar agentes em contexto de plataforma.
• Bradesco - GenAI & Dados — Conteúdo prático de IA generativa e dados, com Python, SQL e integração com ferramentas de produtividade.