AgentProofBench: pesquisadores da CMU testam se é possível reaproveitar verificadores de agentes web

Pesquisadores da Carnegie Mellon University, liderados por Jingjie Ning, apresentam o AgentProofBench, um benchmark para verificadores de agentes web. Ele responde a uma pergunta prática: é possível escrever uma regra de aceitação uma única vez e depois reutilizá-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 programas verificadores foram gerados pelos modelos DeepSeek Flash e DeepSeek Pro.

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

Reaproveitar ou reconstruir

A primeira dimensão trata da resistência a mudanças de 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 um requisito muda, ou se precisa ser reescrito do zero.

• Flash: 82 de 96 programas originais se mantiveram válidos (cerca de 85%).
• Pro: 79 de 96 se mantiveram válidos (cerca de 82%).
• A diferença entre reaproveitamento e reconstrução pela métrica BA para a Flash varia de -5,47 a 1,57 ponto percentual.
• Para a Pro, a mesma faixa vai de -10,16 a 0,00 p.p.

O intervalo da Flash inclui o zero, ou seja, não há perda significativa com o reaproveitamento nesses dados. Na Pro, o limite superior fica em zero, enquanto o inferior cai quase 10 pontos. No piso caso, o reaproveitamento custa visivelmente mais, 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 de tarefas. Os autores analisaram as atribuições de programas em que ambos os estados iniciais salvos são entregues corretamente, e buscaram o que distingue esses casos dos demais. O que diferencia é a correção do painel no estado de implantação.

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

Uma diferença de 97% contra 9% em uma amostra pequena de 44 atribuições não pode ser considerada definitiva. Mas mostra que verificar o verificador contra um painel de testes antes da implantação dá um sinal prático sobre se o programa pode entrar em produção.

Uma linha de base para os controles

Os autores compararam estratégias de feedback para o agente. Entre as opções universais testadas, a maior proporção de entregas corretas veio da continuação neutra, em que o agente simplesmente continua trabalhando sem intervenção do controle. Isso estabelece um piso: qualquer verificador-controle colocado antes da entrega precisa superá-lo, ou só adiciona complexidade e risco de rejeições falsas. Até agora, essa linha de base não existia para agentes web, e as equipes costumavam avaliar os controles no olho.

O que está no lançamento e como usar

Junto com o benchmark, foram publicados as instruções, os estados do ambiente, os programas verificadores, as regras de referência e as 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 uma mudança de requisitos, e não reconstruí-los sem necessidade. Segundo: verificar o painel de testes em busca de erros antes da implantação, já que esses erros coincidiram com todas as regressões e entregas retidas. Terceiro: sempre comparar o controle com a opção "sem intervenção" antes de assumir que ele melhora o resultado. As limitações também são claras: quatro serviços web e dois modelos da mesma família oferecem um retrato restrito. Mas, como metodologia de avaliação no nível de requisitos e política de execução, o trabalho estabelece um quadro claro.