Evals para agent skills: como testar agentes de forma sistemática

TL;DR

Testar agent skills não é só checar se a resposta final “bateu”. O ganho real vem quando você transforma habilidades do agente em casos de teste com métricas de trajetória, uso de ferramentas e critérios observáveis ao longo da execução.

Isso importa porque agentes falham de forma silenciosa: às vezes entregam uma saída aceitável, mas por um caminho errado, frágil ou caro. Um processo sistemático de evals ajuda a detectar regressões, comparar versões e refinar o comportamento antes que o problema chegue à produção.

O que muda quando o alvo é uma habilidade de agente

Em aplicações com LLM tradicional, um teste muitas vezes olha apenas para a resposta final. Em agentes, isso é insuficiente porque a execução inclui mensagens intermediárias, chamadas de ferramentas, ordenação de passos e decisões de recuperação.

O briefing aponta uma mudança importante: avaliar agentes como execução, e não só como texto final. Isso aparece tanto no guia da OpenAI sobre testing agent skills como no material da Anthropic sobre evals para agentes, que separa avaliação de outcome da avaliação da trajetória.

Outcome e trajetória precisam de métricas diferentes

Se a skill do agente é “buscar um dado, validar a fonte e compor um resumo”, a nota final pode estar correta mesmo quando o agente faz consultas desnecessárias, ignora uma ferramenta obrigatória ou segue uma ordem ruim de passos. Para capturar isso, você precisa de sinais por etapa.

Na prática, vale pensar em dois eixos:

• Outcome: o resultado final está correto, completo e aderente ao objetivo?
• Trajectory: o agente escolheu as ferramentas certas, na ordem certa, com argumentos coerentes?

Esse recorte melhora o diagnóstico. Em vez de “falhou”, você passa a saber se o erro foi de planejamento, de tool-use, de instrução ou de composição da resposta.

Como sistematizar testes de agent skills

O fluxo descrito no briefing é consistente: definir a skill, instrumentar a execução, registrar traces, rodar um conjunto de evals e comparar versões. Isso transforma avaliação em rotina de engenharia, não em um ritual manual raro.

Esse padrão é útil especialmente quando o agente muda de modelo, prompt, ferramenta ou política de segurança. Sem uma suíte fixa, fica difícil distinguir progresso real de regressão mascarada por exemplos isolados.

1. Defina a skill como contrato testável

Uma skill precisa ser recortada como unidade verificável. Em vez de “o agente responde bem”, prefira algo como “o agente cria um plano, consulta a ferramenta X, valida o retorno e só então responde”.

Esse contrato mínimo ajuda a construir casos de teste com entrada, estado esperado e critérios observáveis. O projeto evals-skills citado no material vai nessa linha: tratar skills como componentes que podem ser exercitados e refinados de forma repetível.

2. Registre traces e saídas intermediárias

Sem trace, você tende a avaliar no escuro. Com trace, você enxerga mensagens, tool calls, parâmetros usados e ordem de execução. Isso é crucial para agent skills, porque o erro pode estar em um passo intermediário aparentemente pequeno.

Na prática, vale persistir a sequência de eventos da sessão. Assim você consegue comparar execuções entre versões do agente e identificar se uma mudança melhorou a robustez ou só “escondeu” o problema na superfície.

3. Rode suites por cenário, não por amostra solta

O ponto forte de evals úteis é cobrir famílias de casos: invocação correta de tool, recuperação após erro, aderência a instrução, checagem de segurança e variações de contexto. Isso é mais confiável do que uma coleção de prompts soltos.

A recomendação do briefing é clara: automatize um suite e compare antes/depois. Assim, cada alteração de prompt, política ou modelo passa por um conjunto estável de testes, reduzindo regressão silenciosa.

Trajectory match: quando a execução esperada importa

Para skills mais determinísticas, o briefing destaca o uso de trajectory match. A ideia é comparar a sequência executada com uma trajetória esperada, levando em conta mensagens e tool calls.

Esse tipo de avaliação é útil quando a skill tem um caminho bem definido. Exemplo típico: o agente deve consultar uma fonte específica antes de responder ou precisa executar etapas em ordem fixa. Nesse caso, acertar o texto final sem cumprir o processo não é suficiente.

Onde esse tipo de teste ajuda

• Verificar se a tool obrigatória foi chamada.
• Checar se a ordem dos passos segue o contrato da skill.
• Detectar uso incorreto de argumentos em chamadas de ferramenta.
• Encontrar regressões de planejamento que o output final não revela.

A biblioteca agentevals citada no briefing trabalha justamente com avaliadores de trajetória, incluindo modos de comparação que ajudam a adaptar o rigor ao tipo de skill.

LLM-as-judge: quando não há trajetória exata

Nem toda skill tem uma sequência fixa. Em tarefas mais heurísticas, o caminho pode variar sem que isso seja erro. Nesses casos, o briefing aponta o uso de LLM-as-judge para avaliar critérios qualitativos.

O papel do juiz aqui não é “achar bonito”, e sim aplicar uma rubrica. Você define critérios como aderência à instrução, completude, segurança, uso correto de fontes ou qualidade da decisão, e o juiz avalia a execução com base nisso.

Rubricas funcionam melhor do que notas vagas

Uma rubrica boa evita avaliações difusas. Em vez de “resposta boa”, use itens objetivos: “citou a ferramenta adequada”, “explicou a limitação”, “não vazou informação sensível”, “seguiu a política de escalonamento”.

Isso também facilita comparação entre versões. Se a skill muda de comportamento, você consegue ver qual critério melhorou e qual piorou, sem depender de intuição do revisor.

Métricas por etapa: o que observar além da nota final

O ponto mais útil para times de produto é monitorar falhas antes do fechamento da resposta. O briefing destaca métricas que detectam cedo seleção errada de ferramentas, argumentos incorretos e erros de ordem.

Esse modelo é importante porque agentes podem parecer consistentes até o momento em que uma pequena mudança de prompt, modelo ou contexto altera o caminho da execução. Quando você mede por etapa, essas diferenças ficam visíveis.

Exemplos de sinais úteis

• Taxa de tool call obrigatória executada.
• Erros de parâmetro em chamadas de ferramenta.
• Desvios da ordem esperada de etapas.
• Recuperação correta após falha de tool.
• Conformidade com uma rubrica de segurança ou política.

Esses sinais fazem diferença principalmente em agentes que operam com múltiplas dependências. Um score final alto pode esconder custo maior, mais latência ou comportamento instável em cenários reais.

Por que isso importa pro dev brasileiro

No Brasil, esse tipo de disciplina pesa ainda mais porque muitos times precisam fazer mais com menos: budgets em reais pressionados pelo câmbio, prazos curtos e latência sensível quando a infraestrutura está fora do país ou em regiões mais distantes. Um agente que “funciona no demo” mas erra tool calls ou repete passos vira custo direto em ambiente de produção.

Há também um ponto regulatório concreto. Se o agente processa dados pessoais, a LGPD exige cuidado com finalidade, minimização e tratamento adequado. Evals que observam trajetória ajudam a provar, na prática, que o agente seguiu o fluxo esperado e não expôs dados ou tomou atalhos inseguros.

Em empresas brasileiras com operação multicanal — como atendimento, fintech, varejo ou setor público — a diferença entre resposta correta e execução correta costuma aparecer em auditoria, rastreabilidade e custo operacional. Por isso, medir apenas o texto final é uma aposta fraca para times que precisam escalar com governança.

Um desenho de pipeline de evals para começar

Sem tentar sofisticar demais, um pipeline inicial pode seguir esta sequência: definir a skill, criar casos de teste, capturar traces, executar a suíte e comparar resultados entre versões. O importante é manter o processo repetível.

1. Escolha uma skill crítica e escreva o contrato esperado.
2. Monte 10 a 20 casos cobrindo caminho feliz, erro de tool, variação de contexto e recuperação.
3. Defina o tipo de avaliação: trajectory match, rubrica por juiz ou combo dos dois.
4. Registre os traces para diagnóstico e comparação entre versões.
5. Rode a suíte sempre que houver mudança de prompt, modelo ou ferramenta.

Se a skill tiver uma sequência fixa, comece com trajectory match. Se houver muita variação aceitável, complemente com juiz guiado por rubrica. Na maior parte dos times, o melhor resultado vem da combinação das duas abordagens.

Limites e boas práticas

Avaliar agentes com LLM judge não elimina subjetividade; ele apenas organiza a subjetividade em critérios repetíveis. Já trajectory match não serve para tudo, porque algumas skills corretas têm trajetórias distintas entre si.

Por isso, vale manter a avaliação alinhada ao tipo de habilidade. Skills determinísticas pedem mais rigor de trajetória; skills exploratórias ou analíticas pedem rubricas mais flexíveis. Misturar os dois sem critério costuma gerar falso positivo e falso negativo ao mesmo tempo.

Outro ponto prático é não confundir cobertura com volume. Ter muitos testes sem boa instrumentação não resolve; é melhor um conjunto menor, mas que capture os pontos de falha mais caros para o produto.

Esta discussão é conceitual e depende da forma como sua stack registra eventos e executa ferramentas. APIs e frameworks de agentes mudam rápido, então vale conferir a documentação oficial antes de cristalizar qualquer fluxo em produção.

Conclusão

Sistematizar evals para agent skills significa sair do teste de resposta final e passar a observar o comportamento do agente como execução. Quando você mede trajetória, uso de tools e rubricas por etapa, enxerga regressões que um score único não mostra.

Para equipes brasileiras, isso ajuda a reduzir custo, melhorar rastreabilidade e lidar melhor com LGPD, latência e budget em BRL. Se você já tem um agente em produção, o próximo passo prático é escolher uma skill crítica, registrar os traces e montar uma suíte inicial de 10 casos para comparar duas versões do fluxo.

CTA: abra a documentação oficial do guia da OpenAI sobre testing agent skills e adapte hoje mesmo um caso da sua plataforma para avaliar trajetória, não só resposta final.

Conteúdos da DIO para quem quer aprofundar

• Aceleração Microsoft AI Agents — trilha focada em construção de agentes de IA e aplicações práticas com esse padrão de arquitetura.
• Formação AI-102 Certification — base para quem quer entender serviços, componentes e requisitos comuns de soluções de IA em produção.
• Microsoft AI for Tech - OpenAI Services — trata do uso de serviços OpenAI no ecossistema Azure, útil para quem integra LLMs em aplicações reais.
• Microsoft AI for Tech - Copilot Studio — aborda criação de experiências com copilots e fluxos de automação orientados a negócio.
• Microsoft AI for Tech – Criando Prompts Inteligentes — ajuda a estruturar instruções e interações que influenciam diretamente o comportamento de agentes.