Benchmark de avaliação de agentes: guia prático de AgentBench a DeepEval

Teste um agente de atendimento ao cliente. Você roda 100 casos de teste e obtém 78% de sucesso. Parece aceitável. Depois roda exatamente o mesmo teste de novo, e a taxa cai para 65%.

Avaliar agentes não é a mesma espécie de problema que avaliar perguntas e respostas comuns. Em um modelo de Q&A, você pergunta “qual é a capital da França”; se ele responde “Paris”, está certo, se responde “Marselha”, está errado. Preto no branco. Agentes são diferentes: eles pensam, planejam, chamam ferramentas e mudam de ideia no meio do caminho. Na mesma tarefa, hoje ele segue a rota A e dá certo; amanhã segue a rota B e falha; depois de amanhã segue a rota C e volta a funcionar.

Depois de ler vários papers e a documentação de benchmarks como AgentBench e WebArena, a sensação inicial foi mais confusão do que clareza. Só depois de tropeçar em alguns problemas no projeto é que a ficha caiu: avaliação de agentes não pode olhar apenas o ponto final. Precisa olhar a trajetória.

1. Por que avaliar agentes é mais difícil do que avaliar Q&A comum?

O problema central de um agente é a autonomia. A cada execução, ele pode escolher um caminho diferente.

Um exemplo concreto. Eu já testei um agente de reserva de viagens com a tarefa “reservar o voo mais barato de amanhã de Pequim para Xangai”. Na primeira execução, ele consultou o Ctrip, comparou três voos, escolheu o mais barato e fez a reserva para mim. Perfeito. Na segunda execução da mesma tarefa, ele consultou o Ctrip, depois foi consultar o Fliggy, entrou em loop por cinco minutos e terminou em timeout.

Mesmo input, trajetórias diferentes. A dificuldade central da avaliação de agentes está aqui: você não precisa de um simples rótulo de “certo/errado”, mas de um framework capaz de analisar todo o processo de execução.

Framework de avaliação em três camadas

Na formulação oficial da Anthropic, a avaliação de agentes deve ser vista em três camadas:

Camada de raciocínio (Reasoning Layer): o planejamento do agente está correto? Ele entendeu a tarefa? Criou um plano de execução razoável?

Camada de ação (Action Layer): a ferramenta escolhida está correta? Os parâmetros foram passados corretamente? A ordem das chamadas de ferramenta faz sentido?

Execução geral (Overall Execution): a tarefa foi concluída? Quantos passos foram usados? A eficiência foi boa?

Há um dado na documentação do DeepEval que me marcou: falhas de chamada de ferramenta são o problema mais comum em agentes. Cerca de 40% das falhas de agentes acontecem porque a ferramenta escolhida está errada ou os parâmetros foram passados de forma incorreta. O que isso mostra? A maior parte dos problemas de agentes aparece na camada de ação, não na camada de raciocínio.

Limites das métricas tradicionais

Na avaliação tradicional de perguntas e respostas, métricas como acurácia e F1 costumam bastar. Para agentes, não.

Imagine que a taxa de sucesso do seu agente seja 78%. O que esse número diz? Quase nada.

Por quê? Porque 78% pode significar:

• o planejamento estava certo, mas a chamada de ferramenta falhou, ou seja, problema na camada de ação;
• o planejamento estava errado desde o começo, e todo o resto foi trabalho perdido, ou seja, problema na camada de raciocínio;
• o planejamento estava certo, a ferramenta também, mas o último passo saiu do trilho, ou seja, problema na execução geral.

Causas diferentes pedem otimizações completamente diferentes. Se o planejamento está errado, você ajusta o prompt ou troca o modelo. Se a chamada de ferramenta está errada, você melhora a definição da ferramenta ou adiciona validação. Se o erro acontece no último passo, talvez falte tratar melhor uma condição de borda.

Por isso, o ponto central da avaliação de agentes não é “ele teve sucesso?”, mas “em que ponto ele falhou?“.

2. Comparação entre 5 benchmarks populares de avaliação

Há muitos benchmarks de avaliação de agentes no mercado. Separei 5 dos principais, todos que pesquisei ou rodei na prática.

AgentBench: benchmark de capacidade geral

AgentBench foi publicado pela Tsinghua no ICLR’24 e pode ser visto como o primeiro benchmark abrangente criado especificamente para LLM-as-Agent. Ele cobre 8 ambientes: consultas a banco de dados, navegação Web, chamadas de API, execução de código e assim por diante.

A sensação ao rodar: a cobertura é realmente ampla e funciona bem para escolher um agente de uso geral. Mas o ambiente dá trabalho para subir, exige Docker, e só o conjunto Dev já chama o LLM mais de 4.000 vezes. O custo não é baixo.

Cenário ideal: quando você precisa escolher um modelo entre várias opções para servir como backbone do agente, AgentBench oferece uma pontuação geral.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

WebArena: focado em navegação Web

WebArena é focado em ambientes Web. Ele monta um conjunto de sites reais, como e-commerce, fórum e mapa, e faz o agente completar tarefas de navegação nesses ambientes.

Por exemplo, uma tarefa como “encontrar um post no Reddit e comentar”. O benchmark testa a capacidade operacional do agente em um ambiente Web real.

Cenário ideal: se você está construindo um agente de navegador ou automação Web, WebArena é o benchmark mais alinhado.

τ-Bench: teste de conversas multi-turno

τ-Bench, pronunciado tau-bench, teve participação da Anthropic no desenvolvimento e foca cenários de interação multi-turno. Ele simula serviços reais, como atendimento de varejo e reserva aérea, e também simula o papel do usuário conversando com o agente.

Esse benchmark tem uma característica importante: ele testa o desempenho do agente em conversas de múltiplas rodadas, não apenas a conclusão de uma tarefa em turno único.

Cenário ideal: agentes de atendimento, reservas e outros serviços conversacionais.

SWE-Bench: benchmark de capacidade de código

SWE-Bench mede especificamente capacidade de programação. Ele usa issues e PRs reais do GitHub e pede que o agente corrija o código.

É um benchmark exigente. O agente não precisa apenas saber programar; ele também precisa entender a estrutura do projeto, localizar o problema e escrever código que passe nos testes.

Cenário ideal: assistentes de programação ou agentes de correção de código.

Claw-Eval / ACE-Bench: novo benchmark de 2026

Claw-Eval, depois renomeado para ACE-Bench, é um benchmark novo de 2026. Seu diferencial é a dificuldade configurável. Você pode ajustar a dificuldade das tarefas conforme o nível do seu agente.

A ideia é boa: avaliação não é algo pontual, mas um processo contínuo. Quando a capacidade do agente melhora, a dificuldade das tarefas também sobe.

Cenário ideal: avaliação personalizada dentro de empresas ou criação de um sistema de avaliação que possa evoluir continuamente.

Como escolher o benchmark

Não existe resposta padrão para escolher benchmark. Depende do seu cenário:

Minha recomendação: comece com AgentBench para criar uma linha de base e entender o desempenho geral do seu agente. Depois, conforme o cenário específico, use um benchmark especializado para testar mais fundo.

3. Sistema de métricas para avaliação de agentes

Depois dos benchmarks, vem a pergunta prática: quais métricas usar para medir o desempenho de um agente? Eu resumo isso em 6 tipos de métricas centrais, que cobrem praticamente todas as camadas da avaliação de agentes.

1. Taxa de sucesso da tarefa (Success Rate)

É a métrica mais direta: a tarefa foi concluída?

Mas há uma armadilha: o que significa “concluída”? O agente dizer que concluiu é suficiente ou é preciso uma condição objetiva?

Hoje eu prefiro definir critérios claros de aceite. Por exemplo, em uma tarefa de “reservar voo”, os critérios são:

• existe um número de pedido;
• as informações do voo estão corretas;
• o preço está dentro da faixa esperada.

Quanto mais claros forem os critérios de aceite, mais útil será a taxa de sucesso.

2. Precisão da chamada de ferramenta

Essa métrica tem duas partes: escolher a ferramenta certa e passar os parâmetros certos.

Escolher a ferramenta certa significa que, quando o agente precisa chamar uma ferramenta, ele seleciona a ferramenta correta. Passar os parâmetros certos significa que o formato e o conteúdo dos parâmetros estão corretos.

Em projetos reais, percebi que essa métrica expõe muito bem os pontos fracos do agente. Em um caso, o agente tinha 82% de taxa de sucesso, mas apenas 68% de precisão em chamadas de ferramenta. Ao investigar, ficou claro que ele frequentemente confundia as ferramentas de “consulta” e “reserva”.

3. Taxa de progresso (Progress Rate)

Em tarefas de múltiplos passos, a taxa de progresso mostra até que ponto o agente chegou.

Imagine uma tarefa com 5 passos. O agente falha no passo 4. A taxa de sucesso é 0%, mas a taxa de progresso é 80%. Olhando os dois números juntos, dá para entender que o agente está perto de concluir a tarefa e talvez só precise otimizar o último passo.

4. Métricas de qualidade do raciocínio

Esse grupo avalia a capacidade de planejamento do agente:

PlanQuality (qualidade do plano): o plano criado pelo agente faz sentido? A relação lógica entre os passos está correta?

PlanAdherence (aderência ao plano): durante a execução real, o agente se desviou do plano original?

Essas duas métricas precisam de um LLM para avaliar. O PlanQualityMetric do DeepEval faz exatamente isso: usa outro LLM para julgar a qualidade do planejamento do agente.

5. Métricas de eficiência

StepEfficiency (eficiência dos passos): quantos passos o agente usou para concluir a tarefa? Qual é o número mínimo teórico de passos?

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Se uma tarefa pode ser concluída em 3 passos, mas o agente usa 10, o StepEfficiency é 30%.

Também existe o consumo de token, que afeta diretamente o custo. Para concluir a mesma tarefa, se um agente usa 1.000 tokens e outro usa 5.000, o custo muda por um fator de 5.

6. Métricas de estabilidade

O desempenho do agente é estável? Se você roda a mesma tarefa 10 vezes, qual é o desvio padrão da taxa de sucesso?

Eu não dava tanta atenção a essa métrica até um incidente em produção: o agente funcionava bem no ambiente de teste, mas a taxa de sucesso oscilava muito em produção. Depois descobrimos que o timeout de requisição em produção era menor do que no ambiente de teste, o que fazia algumas tarefas serem interrompidas.

Relação entre métricas e o framework de três camadas

Mapeando essas métricas para o framework de três camadas:

Assim, quando uma métrica aparece baixa, você sabe em qual camada está o problema e qual direção de otimização seguir.

4. Comparação entre ferramentas open source: DeepEval vs LangSmith vs Arize Phoenix

Com as métricas definidas, qual ferramenta usar para medir? Comparei três ferramentas populares de avaliação open source.

DeepEval: primeira escolha para avaliação por componente

DeepEval é um framework Python open source criado pela Confident AI, voltado para avaliação de LLMs e agentes.

Seu principal diferencial é a avaliação em nível de componente. Você pode inserir avaliação em qualquer nó do agente, em vez de olhar apenas o resultado final.

Ele traz 6 métricas embutidas:

• TaskCompletionMetric, para conclusão da tarefa;
• StepEfficiencyMetric, para eficiência dos passos;
• ToolCorrectnessMetric, para correção da ferramenta;
• ArgumentCorrectnessMetric, para correção dos argumentos;
• PlanQualityMetric, para qualidade do plano;
• PlanAdherenceMetric, para aderência ao plano.

Usei DeepEval em um projeto de agente de reserva de viagens, e o resultado foi bom. Ele tem um decorador @observe, que rastreia automaticamente componentes como raciocínio e chamadas de ferramenta durante a execução do agente, depois avalia camada por camada.

DeepEval também tem a plataforma em nuvem Confident AI, que visualiza os resultados de avaliação e gerencia datasets. Mas a parte open source já é suficiente para muita coisa.

LangSmith: ferramenta oficial do LangChain

Se você desenvolve agentes com LangChain, LangSmith é a escolha mais conveniente. A integração com LangChain é direta e permite rastrear automaticamente toda a cadeia de execução.

O ponto forte do LangSmith é o rastreamento ponta a ponta. Você consegue ver cada chamada ao LLM, cada execução de ferramenta e a trajetória completa.

Mas é um produto comercial, com limites de preço. Para testes pequenos funciona bem; em avaliação de grande escala, o custo sobe.

Arize Phoenix: observabilidade em primeiro lugar

Arize Phoenix é baseado na arquitetura OpenTelemetry e foca observabilidade.

A ideia é tratar a execução do agente como um sistema distribuído. Chamadas de LLM e chamadas de ferramenta são Spans; a trajetória completa de execução é um Trace.

Phoenix é especialmente bom para monitoramento em produção. Ele tem detecção de anomalias e análise de desempenho, recursos úteis depois do deploy.

Como escolher a ferramenta

A escolha depende da sua situação:

Você usa LangChain?
  → Sim: priorize LangSmith, pela integração direta
  → Não: precisa de monitoramento em produção?
       → Sim: Arize Phoenix + DeepEval
       → Não: avaliação pura no desenvolvimento → DeepEval

Na prática, minha combinação é: DeepEval para avaliação durante o desenvolvimento e Arize Phoenix para monitoramento em produção. As duas ferramentas se complementam bem.

5. Código na prática: avaliando um agente de reserva de viagens com DeepEval

Depois de tanta teoria, vamos para algo concreto. Abaixo está um exemplo completo de avaliação com DeepEval, usado na prática em um projeto de agente de reserva de viagens.

Implementação do agente

Primeiro, definimos um agente simples de reserva de viagens e usamos o decorador @observe para rastrear cada componente:

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# Define a ferramenta
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """Busca voos"""
    # Em um projeto real, esta parte chamaria uma API real
    # O exemplo retorna dados simulados
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """Reserva um voo"""
    # Em um projeto real, esta parte chamaria uma API real de reserva
    return {"order_id": "ORD123456", "status": "confirmed"}

# Corpo principal do agente
@observe(type="agent")
def travel_agent(user_input: str):
    """
    Agente de reserva de viagens
    Entrada: solicitação de reserva do usuário
    Saída: resultado da reserva ou mensagem de falha
    """
    # Camada de raciocínio: analisa a tarefa e cria um plano
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # Aqui normalmente chamaríamos um LLM para analisar e planejar
        # O exemplo usa uma regra simples de parsing
        plan = {
            "task": "book_flight",
            "origin": "Pequim",
            "destination": "Xangai",
            "date": "amanhã",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # Camada de ação: executa chamadas de ferramenta
    # Passo 1: busca voos
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # Passo 2: seleciona o voo mais barato
    cheapest = min(flights, key=lambda x: x["price"])

    # Passo 3: reserva
    result = book_flight(
        cheapest["flight"],
        {"name": "Usuário de teste"}
    )

    return result

Configuração das métricas de avaliação

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# Define os dados de teste
test_cases = [
    LLMTestCase(
        input="Reserve o voo mais barato de amanhã de Pequim para Xangai",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="Consulte para mim os voos da próxima quarta-feira de Guangzhou para Shenzhen",
        expected_output={"flights": [...]}
    )
]

# Configura as métricas de avaliação
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # espera pelo menos 50% de eficiência
        minimum_steps=3  # pelo menos 3 passos são necessários
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

Execução da avaliação

# Método 1: avaliação individual
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# Método 2: avaliação em lote com dataset
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="Reserve o voo mais barato de amanhã de Pequim para Xangai"),
    Golden(input="Encontre informações de voos da próxima semana de Chengdu para Kunming")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # A avaliação registra e calcula os resultados automaticamente

Interpretação dos resultados

DeepEval retorna a pontuação e a aprovação de cada métrica. Imagine este resultado:

O que dá para concluir?

• A taxa de conclusão é alta, 85%, então a maioria das tarefas termina com sucesso.
• A eficiência dos passos é baixa, 45%, o que sugere que o agente está executando passos extras.
• A escolha de ferramentas é muito boa, 90%, mas a correção dos argumentos é fraca, 72%.

A direção de otimização fica clara: melhorar principalmente a lógica de construção de parâmetros e reduzir passos desnecessários.

6. Prática de avaliação em produção

Quando a avaliação da fase de desenvolvimento termina e o agente vai para produção, a avaliação acabou? Nem de perto.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

O desempenho de um agente em produção costuma ser diferente do ambiente de desenvolvimento. Os inputs dos usuários são mais aleatórios, há mais casos de borda e a pressão de concorrência é maior. Você precisa de um ciclo completo de avaliação, do desenvolvimento à produção.

Fase de desenvolvimento: criar uma linha de base

Na fase de desenvolvimento, o objetivo é estabelecer a capacidade de base do agente.

Primeiro, rode um benchmark abrangente como AgentBench para entender o nível do agente em capacidade geral. Depois, use um conjunto de dados próprio para testar cenários específicos. Esse dataset deve cobrir tarefas típicas, casos de borda e casos de falha.

O que fazer nessa fase:

• garantir cobertura do dataset de teste em ≥ 80% dos cenários de usuário;
• definir um valor de referência claro para cada métrica;
• registrar casos de falha e analisar a distribuição das causas.

Fase de deploy: rollout gradual e teste A/B

Quando o agente for para produção, não publique para 100% dos usuários de uma vez. Comece com rollout gradual.

O ponto central da avaliação no rollout é a comparação: diferença de desempenho entre grupo gradual e grupo de controle.

# Exemplo de avaliação em rollout gradual
def ab_test_evaluation():
    # Grupo de controle: versão antiga do agente
    control_results = evaluate_agent(old_agent, test_cases)

    # Grupo de tratamento: nova versão do agente
    treatment_results = evaluate_agent(new_agent, test_cases)

    # Compara métricas principais
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

Sugestão de proporção: comece com 1%, observe por 24 horas; se estiver tudo bem, vá para 5%, depois 10%, 20%, 50% e 100%. Em cada etapa, observe as métricas principais.

Fase de produção: monitoramento contínuo

Depois que o agente está em produção, avaliação vira monitoramento.

O foco do monitoramento é detectar anomalias: queda repentina na taxa de sucesso, aumento repentino do tempo de resposta, falha repentina em alguma chamada de ferramenta. Esses alertas precisam chegar a tempo para você detectar problemas antes de receber feedback em massa dos usuários.

Estratégia de amostragem: em produção, não dá para avaliar todas as requisições. Minha recomendação:

• tarefas comuns: amostrar 1%-5%;
• tarefas críticas, como pagamento e reserva: avaliar 100%;
• requisições anômalas, como falha ou timeout: enviar 100% para a fila de avaliação.

Controle de custo: a avaliação também tem custo, especialmente quando um LLM avalia a qualidade do raciocínio. Alguns truques:

• usar modelos menores para avaliação, como gpt-4o-mini;
• avaliar de forma assíncrona, sem bloquear o fluxo principal;
• configurar um circuit breaker de avaliação, com limite máximo de 100 a 1000 amostras.

Por que revisão humana ainda é necessária

Mesmo uma boa avaliação automática tem casos de borda que precisam de pessoas.

Hoje eu faço assim: casos marcados pela avaliação automática como “incertos” entram em uma fila de revisão humana. Toda semana, selecionamos 10 a 20 casos e verificamos manualmente a precisão da avaliação automática.

A revisão humana também ajuda a descobrir problemas que a avaliação automática não cobre. Por exemplo, o tom da resposta do agente pode ser ruim ou confundir o usuário. Isso é difícil de capturar automaticamente, mas prejudica muito a experiência.

Um ciclo completo de avaliação

Juntando o processo inteiro:

Fase de desenvolvimento
├── Benchmark AgentBench
├── Avaliação com dataset próprio
└── Análise de casos de falha
    ↓
Fase de deploy
├── Rollout gradual (1% → 5% → 10% → ...)
├── Comparação A/B
└── Mecanismo de rollback
    ↓
Fase de produção
├── Monitoramento por amostragem (1%-5%)
├── Detecção de anomalias e alertas
├── Fila de revisão humana
    ↓
Iteração de otimização
├── Atribuição das causas de falha
├── Ajuste de prompt/ferramentas
└── Reavaliação
    ↓ (ciclo)

É um processo contínuo, não uma tarefa única. A capacidade do agente pode degradar, os cenários de usuário mudam e novos problemas aparecem. A avaliação precisa evoluir junto.

Conclusão

Avaliação de agentes, resumindo, é isto: não olhe só o destino; olhe a trajetória.

Já caí em algumas armadilhas. Achei que 78% de sucesso bastava, mas depois do lançamento vi a mesma tarefa oscilar 30%. Achei que as chamadas de ferramenta estavam bem, mas 40% das falhas vinham de parâmetros errados. Achei que avaliação no desenvolvimento bastava, mas os problemas de produção eram completamente diferentes.

O framework de três camadas organizou o raciocínio: planejamento na camada de raciocínio, ferramentas na camada de ação e resultado na execução geral. Os 5 benchmarks ajudaram a construir uma linha de base: AgentBench para avaliação ampla, τ-Bench para multi-turno e SWE-Bench para código. DeepEval tornou a avaliação codificável: o decorador @observe rastreia componentes, e 6 métricas analisam camada por camada.

Próximos passos:

1. Rode AgentBench no seu agente para criar uma linha de base.
2. Use DeepEval para avaliação em nível de componente e encontre os pontos fracos.
3. Monte um monitoramento de produção com detecção de anomalias + revisão humana.

Avaliação não é o ponto final. É o ponto de partida. Quando a capacidade do agente evolui, a avaliação precisa evoluir junto.