o problema
Testar um LLM de turno único é quase trivial: entra um prompt, sai um texto, um grader compara com o esperado. Foi assim que a área mediu qualidade por anos. Agente quebra esse formato. Ele roda muitos turnos, chama ferramentas, altera estado no ambiente e adapta o plano conforme os resultados intermediários aparecem. As mesmas três propriedades que fazem o agente valer a pena — autonomia, inteligência, flexibilidade — são as que tornam a medição difícil: erro no turno três se propaga e composta até o fim, e a saída final pode não ter relação nenhuma com o que de fato aconteceu.
O resultado prático, segundo o post, é um time preso em loop reativo. Alguém reporta que “o agente ficou pior depois da última mudança” e não há como verificar exceto reproduzir na mão, corrigir e torcer para nada mais ter regredido. Sem eval, o time não distingue regressão real de ruído, não testa uma mudança contra centenas de cenários antes de subir, e não consegue medir melhoria. Também não consegue adotar modelo novo rápido: quem tem eval troca de modelo em dias, quem não tem gasta semanas testando na mão.
a ideia
Um eval é uma tarefa com critério de sucesso definido, executada várias vezes (cada execução é um trial, porque a saída varia entre runs) e pontuada por graders. A virada em relação ao eval de turno único é onde se olha: não no transcript — o registro completo de mensagens, tool calls e raciocínio — mas no outcome, o estado final do ambiente. Um agente de passagens aéreas pode terminar dizendo “seu voo foi reservado”; o que interessa é se existe uma linha no banco SQL do ambiente.
A segunda virada é aceitar que o eval é software com bug. O post trata tarefa ambígua e grader mal configurado como a hipótese principal quando o número vem baixo, não como exceção. Opus 4.5 tirou 42% no CORE-Bench até um pesquisador da Anthropic achar grading rígido que penalizava “96,12” quando esperava “96,124991…”, specs ambíguas e tarefas estocásticas impossíveis de reproduzir; com os bugs corrigidos e scaffold menos restrito, o score foi para 95%. A METR encontrou tarefas que mandavam o agente atingir um limiar mas exigiam superá-lo na hora de corrigir — quem seguia a instrução perdia ponto.
como funciona
Três famílias de grader se combinam. Os de código (teste unitário fail-to-pass, análise estática, verificação de estado, contagem de turnos e tokens) são rápidos, baratos e reprodutíveis, e quebram diante de variação válida que não bate no padrão. Os baseados em modelo (rubrica, asserção em linguagem natural, comparação par a par, consenso entre juízes) cobrem o que é aberto e subjetivo, custam mais e precisam de calibração contra humano. Os humanos são o padrão-ouro e servem sobretudo para calibrar os outros. A pontuação por tarefa pode ser binária, ponderada com limiar, ou híbrida — e o post insiste em crédito parcial: um agente de suporte que identifica o problema e verifica o cliente mas erra o reembolso é melhor que um que falha de cara.
As suítes se dividem em duas intenções opostas. Capability evals começam com taxa de acerto baixa de propósito, para dar ao time uma ladeira para subir. Regression evals ficam perto de 100% e existem para gritar quando algo quebra. Capability eval que satura vira suíte de regressão.
Por tipo de agente, a receita muda. Coding agent aceita grader determinístico porque software se verifica sozinho. Agente conversacional exige um segundo LLM simulando o usuário e rubrica que julgue tom e resolução. Agente de pesquisa precisa de checagem de groundedness, de cobertura e de qualidade de fonte, porque “abrangente” depende do contexto. Agente de uso de computador precisa de ambiente real ou sandbox e verificação de estado no backend — confirmar que o pedido entrou, não que a página de confirmação apareceu.
Para lidar com não determinismo, duas métricas: pass@k, a chance de acertar ao menos uma vez em k tentativas, e pass^k, a chance de acertar todas as k. A escolha é de produto: pass@1 quando o agente precisa acertar de primeira, pass^k quando o usuário espera consistência sempre.
o que isso custou
O custo do eval é visível na frente e o benefício chega depois — é por isso que ele fica para depois e nunca é feito. Automatizado, ele exige investimento inicial, manutenção contínua para não driftar do produto, e pode gerar falsa confiança quando não bate com o uso real. Grader de modelo é não determinístico e caro. Grader humano é caro e lento, e em domínio complexo depende de especialista disponível.
Há um limite mais incômodo: modelo de fronteira acha solução que o eval estático não previu. Opus 4.5 resolveu uma tarefa de reserva de voo do 𝜏2-bench descobrindo uma brecha na política — “falhou” o eval como escrito e entregou resultado melhor para o usuário. Saturação corrói o sinal na outra ponta: com a suíte perto do teto, ganho grande de capacidade aparece como aumento pequeno. A Qodo achou Opus 4.5 pouco impressionante porque seus evals de uma tacada não capturavam ganho em tarefa longa. E ambiente compartilhado entre trials contamina tudo: em evals internos, Claude ganhou vantagem indevida lendo o histórico do git deixado por trials anteriores.
O próprio texto fecha admitindo que o campo é nascente e que as técnicas vão precisar mudar conforme agentes assumem tarefas mais longas, colaboram entre si e lidam com trabalho mais subjetivo.
onde isso aparece hoje
O post é a continuação prática de Building effective agents, que definiu o loop de agente que aqui se tenta medir. A infraestrutura descrita é a mesma que a Anthropic usa: o Claude Code começou com dogfooding e ganhou evals depois, primeiro para concisão e edição de arquivo, depois para comportamentos como over-engineering — a base está em Claude Code overview e no Claude Agent SDK, usado para montar o harness de agentes longos descrito em Effective harnesses for long-running agents.
Nos benchmarks públicos citados, o SWE-bench Verified é o caso exemplar do ciclo inteiro: saiu de 40% para mais de 80% em um ano e agora se aproxima da saturação. Terminal-Bench, 𝜏-Bench e 𝜏2-Bench, WebArena, OSWorld, BrowseComp e CORE-Bench cobrem terminal, conversa, navegador, sistema operacional e pesquisa. Do lado de ferramenta, Harbor, Braintrust, LangSmith, Langfuse e Phoenix; o post lembra que framework só vale o que valem as tarefas rodadas nele.
A recomendação final é eval-driven development: escrever o eval antes de o agente conseguir passar, o que também serve como teste de se o requisito de produto é concreto o bastante para começar — o mesmo movimento de Define your success criteria.