O grader da Google reprovou três execuções de agente que passaram. Ele lia o resumo, não o que o agente fez
A Google publicou quatro lições de avaliação de agentes: avaliar a trajetória, manter a estrutura de turnos, comparar execuções ao vivo e só de plano e usar golden sets como baseline.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Um agente recebe a tarefa de limpar serviços do Cloud Run. A tarefa exige que ele verifique a sintaxe do comando antes de executar qualquer coisa. O primeiro passo é exatamente esse: gcloud help run services list. A mensagem final, porém, se concentra em alertar o usuário sobre perda permanente de dados. O grader automatizado lê a mensagem final, não encontra a verificação de sintaxe e marca a execução como falha.
O agente passou. A avaliação falhou.
Essa é a primeira de quatro lições que Casey West, que lidera relações com desenvolvedores para infraestrutura de IA na Google Cloud, publicou em 16 de outubro a partir da construção do plugin Google Cloud Developer para agentes de programação. Na suíte inicial de 11 prompts, o juiz LLM marcou três execuções como falhas que os logs brutos de chamadas de ferramentas mostravam como aprovadas. Onze prompts é pouco demais para estimar uma taxa de erro, e o post não tenta. O valor está em nomear quatro formas como avaliações de agentes enganam, cada uma com um mecanismo concreto.
O resumo é a opinião do agente sobre o próprio trabalho
A mensagem final de um agente é um relatório escrito pela parte avaliada. Ela pode subestimar o trabalho que ele fez, como aqui, ou descrever um trabalho que ele nunca fez, que é o caso mais perigoso. Um juiz que avalia o resumo está avaliando as habilidades narrativas do agente.
A correção da Google é pontuar a trajetória: quais comandos rodaram, com quais argumentos, em qual ordem, se as verificações vieram antes das etapas destrutivas e se as ações ficaram dentro do escopo. Isso não é novo como ideia; o playbook de experiência com agentes da Microsoft também usou análise de trajetória. O que é novo é um exemplo limpo e documentado do juiz baseado no resumo produzindo falsas falhas em uma suíte pequena, que é exatamente onde os times tendem a confiar nele.
Chamadas em paralelo escondem bugs de ordenação
A segunda lição é mais sutil. O harness enviou uma chamada de carregamento de skill e duas buscas na documentação em um único lote de chamadas de ferramentas. As skills são carregadas em etapas, então as instruções da skill chegaram depois que as buscas já tinham rodado sem elas. A telemetria achatada em uma lista simples de eventos fez as chamadas parecerem sequenciais e escondeu o problema.
Para quem constrói pipelines de avaliação: mantenha a estrutura de turnos nos seus traces. Um agente que faz as coisas certas na ordem errada, ou em paralelo antes de sua orientação chegar, passa em um checklist e falha em produção.
Rode ao vivo, rode só de plano, compare
A terceira lição é a mais prática. Rode cada prompt de avaliação duas vezes: uma ao vivo, com credenciais reais mas em sandbox, em que o agente executa comandos, e uma só de plano, com as credenciais removidas, em que ele explica o que faria. Execuções ao vivo testam sintaxe, tratamento de parâmetros e contenção antes de ações destrutivas. Execuções só de plano expõem a intenção que erros de permissão esconderiam.
Em um prompt de onboarding, a execução ao vivo travou em uma listagem de projeto bloqueada; a execução só de plano produziu um plano de 8,000 caracteres que ignorava políticas de organização, aprovações de administradores e governança por completo. Segundo o post, cerca de metade dos achados mais importantes veio da diferença entre as duas condições.
| O que captura | O que deixa passar | |
|---|---|---|
| Mensagem final, avaliada por um juiz | Conclusões erradas na resposta | Trabalho feito mas mal descrito; trabalho descrito mas nunca feito |
| Trajetória de execução | Comandos errados, verificações puladas, desvio de escopo | Se a ação cabia à situação de negócio |
| Execução ao vivo, credenciais em sandbox | Sintaxe, parâmetros, contenção antes de etapas destrutivas | Intenção escondida atrás de erros de permissão |
| Execução só de plano, sem credenciais | Lacunas de raciocínio, políticas e aprovações ignoradas | Qualquer coisa que só quebra na execução |
| Golden set de especialistas | Regressões quando o modelo ou o harness muda | Casos que ninguém escreveu ainda |
Golden sets testam o sistema, não o modelo
A quarta lição trata a avaliação como integração contínua para um sistema não determinístico. As execuções são pontuadas contra golden sets curados por especialistas humanos que capturam o que o agente deveria pensar, quais comandos deveria rodar e se resolveu o problema sem quebrar nada. O baseline é a stack inteira, harness, modelo e plugins, porque qualquer um deles pode mudar.
O que isso deixa para os times enterprise
O relato da AWS sobre seus agentes de vendas, publicado no mesmo dia, chegou a uma conclusão compatível por outra direção: verificações determinísticas para respostas conhecidas, juízes só para o resto, avaliação embutida em cada release. A Google acrescenta o lado da execução: para um agente que age, o registro do que ele fez é a evidência primária e o relato dele mesmo sobre o que fez é secundário.
Vale ter em mente um limite. Uma trajetória prova o que aconteceu, não que era a coisa certa a fazer. Um agente pode rodar todos os comandos corretamente contra o recurso errado. A avaliação de trajetória responde “ele fez o que especificamos?”; a pergunta “essa era a ação certa aqui?” ainda precisa de casos de referência escritos por pessoas que conhecem o negócio e, para ações com consequências, alguém que aprove antes da execução.