AgentProofBench: pesquisadores da CMU testam se verificadores de agentes web podem ser reaproveitados

Pesquisadores da Carnegie Mellon University, liderados por Jingjie Ning, apresentaram o AgentProofBench, um benchmark para verificadores de agentes web. Ele responde a uma pergunta prática: é possível escrever uma só vez a regra de aceitação de um resultado e depois usá-la quando os requisitos mudam e na execução real? O recurso abrange 97 tarefas, 79 famílias de tarefas e quatro serviços web. Os verificadores, na forma de programas, foram gerados por DeepSeek Flash e DeepSeek Pro.

A ideia do benchmark é que avaliar um verificador apenas pela precisão dos veredictos não basta. O agente trabalha em cadeia: recebe uma instrução, age no site, passa pela verificação e só então o resultado é entregue ao usuário. Por isso, o AgentProofBench une testes pareados de uma regra de aceitação "congelada" à execução do agente a partir dos mesmos estados iniciais salvos. Cada erro de teste pode ser rastreado até suas consequências na execução.

Reaproveitar ou refazer

A primeira dimensão trata da robustez diante de mudanças nos requisitos. Em 48 famílias de tarefas, foram aplicados dois testes: complete-panel e decision-replay. Eles mostram se o programa verificador original continua válido quando o requisito muda ou se precisa ser reescrito do zero.

• Flash: 82 de 96 programas originais foram mantidos (cerca de 85%).
• Pro: 79 de 96 foram mantidos (cerca de 82%).
• A diferença entre reaproveitar e refazer, na métrica BA, fica entre −5,47 e 1,57 ponto percentual para o Flash.
• Para o Pro, o mesmo intervalo vai de −10,16 a 0,00 p.p.

O intervalo do Flash inclui o zero, ou seja, nesses dados não há perda perceptível ao reaproveitar. No Pro, o limite superior chega a zero, enquanto o inferior desce a quase 10 pontos. No pior caso, o reaproveitamento sai bem mais caro, e o benchmark torna esse custo mensurável.

Erros no painel como indicador de entrega

A segunda dimensão se refere à execução e se baseia em 22 famílias. Os autores analisaram as atribuições de programas em que os dois estados iniciais salvos são entregues corretamente e buscaram o que distingue esses casos dos demais. O fator de diferença é a correção do painel no estado de implantação.

• Das 33 atribuições com painel sem erros, 32 resultaram em entrega correta nos dois estados.
• Das 11 atribuições em que o painel tinha erros, isso ocorreu em apenas uma.
• Todas as regressões de program-gate em relação às regras de referência e todos os casos de entrega retida ficaram no grupo com erros no painel.

A diferença de 97% contra 9%, numa amostra pequena de 44 atribuições, não pode ser considerada definitiva. Mesmo assim, ela indica que validar o verificador num painel de testes antes do lançamento fornece um sinal prático sobre se o programa pode entrar em produção.

Linha de base para os gates

Os autores compararam estratégias de feedback para o agente. Entre as variantes universais testadas, a maior taxa de entrega correta veio da continuação neutra, em que o agente simplesmente segue trabalhando, sem intervenção do gate. Isso estabelece um piso: qualquer gate verificador colocado antes da entrega precisa superá-lo, ou apenas acrescenta complexidade e risco de recusas falsas. Até agora, não havia esse piso para agentes web, e as equipes muitas vezes avaliavam os gates a olho.

O que vem no lançamento e como usar

Junto com o benchmark foram publicados instruções, estados do ambiente, programas verificadores, regras de referência e trajetórias dos agentes. O código e a página do projeto estão disponíveis no GitHub e em ethanning.github.io/AgentProofBench. O preprint está registrado como arXiv 2610.34634 e apareceu na seleção diária do Hugging Face Daily Papers.

Para equipes que constroem agentes web com verificação automática de resultados, o benchmark oferece três passos concretos. Primeiro: medir quantos verificadores gerados sobrevivem a mudanças de requisitos e não refazê-los sem necessidade. Segundo: checar o painel de testes em busca de erros antes da implantação, já que foram eles que coincidiram com todas as regressões e com as entregas retidas. Terceiro: sempre comparar o gate com a variante "sem intervenção" antes de concluir que ele melhora o resultado. As limitações também são evidentes: quatro serviços web e dois modelos da mesma linha dão um retrato restrito. Ainda assim, como metodologia de avaliação no nível do requisito e da política de execução, o trabalho oferece um referencial claro.