Evals para agent skills: sistematizando testes de agentes

TL;DR

Quando falamos em agent skills, não basta demonstrar que um agente “funciona” em uma demo. O ponto passa a ser medir, de forma repetível, se uma habilidade modular realmente melhora a execução em tarefas reais, com rastros, artefatos e verificadores estáveis.

O recorte prático é direto: trate evals como testes end-to-end com critérios claros, compare contra um baseline sem skills e acompanhe a evolução ao longo do tempo. Isso reduz discussão subjetiva e ajuda a decidir quando vale colocar a skill em produção.

Por que “skills” mudam o jogo nos evals

O material de OpenAI e o benchmark SkillsBench apontam para a mesma direção: avaliar agentes por “resultado final” é insuficiente quando a solução depende de ações intermediárias, uso de ferramentas e estado acumulado. Nesse cenário, a skill vira uma unidade observável — algo que pode ser exercitado, medido e regressado como qualquer parte crítica de software.

A implicação prática é que o eval deixa de ser uma nota genérica e passa a ser um conjunto de testes com entradas, saídas esperadas e artefatos capturados da execução. Em vez de perguntar “o modelo respondeu bem?”, a pergunta vira “a habilidade resolveu a tarefa com consistência suficiente para eu confiar nela?”.

Do prompt ao harness

No padrão descrito pela OpenAI, a execução precisa ser capturada com trace e artefatos, e depois pontuada por um pequeno conjunto de checks. Isso aproxima o processo de um harness de teste: cada caso tem um comportamento esperado, e o score permite comparar versões ao longo do tempo.

Esse formato é útil porque reduz a dependência de juízo difuso. Se a skill é, por exemplo, “navegar até um dado arquivo, extrair uma informação e registrar o resultado”, o eval pode verificar presença do arquivo, integridade da extração e formatação correta da saída. O foco sai da conversa e vai para evidência observável.

Como estruturar evals para agent skills

Uma forma simples de pensar é dividir o eval em três camadas: cenário, execução e verificação. O cenário define a tarefa e o ambiente; a execução gera o trace; e a verificação pontua com regras reprodutíveis. Quanto mais clara essa separação, mais fácil fica depurar regressões quando algo quebra.

Na prática, isso ajuda especialmente quando a skill encapsula comportamento recorrente, como leitura de documentos, chamada de ferramentas, manipulação de arquivos ou automação de fluxos. O eval precisa validar o que a skill promete entregar, não só a resposta textual final.

Baseline contra skill habilitada

O SkillsBench adiciona uma camada importante: comparar as mesmas tarefas em condições controladas, como sem skills, skills curadas e skills geradas pelo próprio agente. Esse desenho melhora a leitura causal, porque o ganho observado fica mais atribuível à presença da skill.

Sem esse contraste, é fácil confundir melhora real com variação aleatória do modelo, do prompt ou do ambiente. Com esse desenho, você consegue ver se uma skill traz ganho consistente em uma família de tarefas ou se só ajuda em casos isolados.

Verificadores determinísticos

Outro ponto central do SkillsBench é o uso de deterministic verifiers. Em vez de depender de um “LLM judge” para tudo, o benchmark privilegia checks programáticos sempre que possível. Isso reduz variação, facilita comparação entre execuções e torna o resultado mais auditável.

Esse detalhe é importante para equipes que precisam justificar decisões técnicas. Quando o verificador é determinístico, fica mais fácil explicar por que uma versão passou e outra falhou — e isso encurta a distância entre avaliação experimental e rotina de engenharia.

O que muda quando o agente é multi-etapas

Anthropic chama atenção para um problema conhecido de agentes: o que importa não é apenas o fim, mas a trajetória. Em tarefas com várias rodadas, uso de ferramentas e alterações de estado, uma resposta final aparentemente correta pode esconder caminhos frágeis, custos excessivos ou comportamentos inconsistentes.

Por isso, o desenho do eval precisa olhar para a sequência inteira. Um agente pode completar a tarefa, mas gastar passos demais, se perder em uma ferramenta, ou produzir um estado intermediário difícil de recuperar. Em produção, isso pesa tanto quanto acerto bruto.

Trajetória como unidade de análise

Capturar traços permite observar onde a execução saiu do trilho. Isso é especialmente valioso quando a skill depende de decisões intermediárias, como escolher a ferramenta certa, recuperar um contexto específico ou respeitar uma política de uso.

Na prática, isso transforma o eval em instrumento de diagnóstico, não só de aprovação. Se a skill piorar, você não sabe apenas que piorou; você enxerga em que etapa a degradação apareceu.

Como montar um harness que aguenta evolução

Se o objetivo é manter evals úteis ao longo do tempo, o harness precisa ser estável. Isso significa congelar cenários quando possível, versionar os casos de teste e registrar métricas com a mesma estrutura a cada rodada. Sem essa disciplina, a leitura histórica vira ruído.

Também vale separar casos fáceis de casos de borda. Os primeiros ajudam a detectar regressão grosseira; os segundos mostram se a skill está pronta para situações mais realistas, com mais ambiguidade e mais estado.

Rubricas e checks: quando usar cada um

Rubricas são úteis quando há nuance e classificação qualitativa, mas elas precisam de calibragem. Checks determinísticos entram onde a verificação é objetiva: um arquivo foi criado, um campo foi preenchido, um JSON respeitou o schema, uma ação ocorreu na ordem esperada.

Na prática, um bom eval mistura os dois. Você usa checks objetivos para estabilidade e rubricas apenas nos pontos em que a avaliação realmente depende de interpretação.

Um exemplo de pipeline de avaliação

Para uma skill de agente voltada a automação de tarefas, o pipeline pode seguir esta ordem: definir a tarefa, executar o agente com telemetria ligada, capturar traces e artefatos, aplicar verificadores e salvar o score. Depois, repita a mesma bateria nas versões seguintes da skill.

undefined

O valor desse desenho não está no formato em si, mas na repetibilidade. Quando a equipe consegue rodar a mesma bateria e comparar score com pouca variância, a conversa sobre qualidade deixa de ser opinativa.

Por que isso importa pro dev brasileiro

No Brasil, o custo de iteração pesa mais do que em mercados com orçamento mais folgado. Times pequenos, contratos em real e pressão por ROI rápido fazem com que “testar agente em produção” sem harness vire aposta cara. Se a skill falha depois de algumas semanas, o retrabalho consome tempo de engenharia que já é escasso.

Há também um ponto regulatório concreto: quando o agente lida com dados pessoais, a LGPD exige cuidado com finalidade, necessidade e rastreabilidade. Evals com traces e artefatos ajudam a mostrar o que o agente fez, onde tocou dados e se a execução respeitou o escopo esperado.

Outro fator local é operacional. Muitos times no Brasil ainda dependem de infra e integrações hospedadas fora do país, o que amplia latência e aumenta variabilidade em fluxos com múltiplas chamadas. Nesse cenário, avaliar trajetória, custo de passos e resiliência deixa de ser luxo e vira requisito de engenharia.

Limites e cuidados na adoção

Evals bem desenhados não eliminam revisão humana. Eles reduzem incerteza, mas continuam dependentes da qualidade dos casos de teste, da cobertura de bordas e da forma como a skill foi especificada. Se a skill estiver mal definida, o harness só vai medir com precisão uma promessa mal recortada.

Vale também evitar métricas isoladas. Um score alto pode mascarar custo excessivo, dependência de poucos cenários ou degradação em tarefas menos frequentes. O ideal é olhar taxa de sucesso, estabilidade, custo por execução e falhas por categoria.

Conclusão

O principal recado dos materiais de OpenAI, Anthropic e SkillsBench é que agent skills precisam ser tratadas como componentes testáveis, não como “mágica” acoplada ao prompt. Quando você captura trajetórias, usa verificadores determinísticos e compara contra baseline, a avaliação fica mais próxima da prática de engenharia que já existe em testes de software.

Se você precisa começar ainda hoje, pegue uma skill simples do seu agente, defina três casos de teste objetivos e rode a mesma bateria com e sem a skill habilitada. Em menos de uma hora, você já terá um primeiro sinal sobre consistência, regressão e custo real.

Esta análise se apoia em evals e harnesses que podem mudar rápido com novas versões de SDKs e plataformas. Antes de levar qualquer fluxo para produção, confira a documentação oficial e o changelog das ferramentas que você estiver usando.

Conteúdos da DIO para quem quer aprofundar

• Aceleração Microsoft AI Agents — evento prático para entender agentes de IA, automação e ferramentas aplicadas ao desenvolvimento.
• Formação Automação de Testes com Cypress — jornada de qualidade de software com foco em automação, útil para pensar harnesses e verificações reproduzíveis.
• Aceleração Automação de Testes #TQI — conteúdo voltado a testes e automação, com contexto de mercado e prática distribuída pelo Brasil.