A equipe de pesquisa do Google publicou um artigo no arXiv em 1º de outubro, apresentando um framework de verificação de agentes chamado VeriHarness, com o código também disponibilizado no GitHub sob licença Apache 2.0. O problema que ele busca resolver é bem concreto: quando um agente de IA executa uma tarefa com dezenas de etapas e entrega uma tabela, um relatório ou um arquivo editado, quem decide se esse resultado está correto.
A abordagem do VeriHarness é fazer com que o próprio modelo que gerou a resposta atue como revisor. A mesma pergunta é executada várias vezes de forma independente pelo modelo, gerando vários resultados, que depois são comparados lado a lado e tratados separadamente como "divergência" e "consenso".
Dois caminhos de revisão
O primeiro caminho trata a divergência. Quando os resultados discordam sobre determinada conclusão, o revisor volta ao ambiente da tarefa para buscar evidências — por exemplo, reabrindo o arquivo original ou verificando uma célula específica de uma planilha — e usa o que encontra no ambiente para descartar a afirmação errada.
O segundo caminho trata o consenso. Quando os resultados concordam entre si, o framework também não os aprova de imediato: ele vai ativamente procurar falhas, buscando evidências que possam refutar essa conclusão, e ao mesmo tempo verifica se todos os resultados deixaram passar algum requisito da tarefa. O ponto de partida do artigo é que múltiplas execuções chegarem à mesma resposta não garante que ela esteja correta — o modelo pode perfeitamente cometer o mesmo erro todas as vezes.
Depois de concluídos os dois caminhos, entra-se na etapa de veredito: escolhe-se o resultado com a melhor base como ponto de partida, propõem-se correções conforme as evidências encontradas, refaz-se tudo por completo se necessário, e os pontos que permanecem sem esclarecimento são registrados separadamente. O framework equipa o revisor com um espaço de trabalho, ferramentas de coleta de evidências e um conjunto de "habilidades de verificação" reutilizáveis; segundo o artigo, essas habilidades também conseguem se aprimorar a partir do retorno de falhas.
O que foi testado e quanto subiu
A avaliação cobre cinco benchmarks de espaços de trabalho de longo horizonte: APEX-Agents, Workspace-Bench Lite, WorkBuddy Bench, SpreadsheetBench 2 e JobBench, em grande parte tarefas que exigem entregar arquivos, como documentos de escritório, planilhas e materiais de candidatura a emprego. A geração e a revisão usam o mesmo modelo, e dois foram testados: Gemini 3.5 Flash e Claude Opus 4.8, ambos acessados via Vertex AI.
Segundo o artigo e o README, o VeriHarness ficou em primeiro lugar na "pontuação de seleção" nos cinco benchmarks, com grupos de comparação que incluem execução única e métodos anteriores de LLM-as-a-Verifier. Somando a correção guiada por evidências, em comparação com a geração única, o Gemini 3.5 Flash sobe em média 6,2 pontos, e o Claude Opus 4.8, 6,4 pontos.
A equipe também publicou cerca de 26 mil trajetórias de execução no Hugging Face, com os dois modelos executando cada pergunta 10 vezes nos cinco benchmarks, acompanhadas do processo de execução renderizado, dos arquivos entregues e das notas. As entradas e os gabaritos dos benchmarks não foram divulgados. O artigo menciona que produzir esse conjunto de dados custou mais de 100 mil dólares.
Qual é a diferença em relação a "executar várias vezes e tirar a maioria"
Fazer o modelo executar várias vezes e depois votar é uma forma comum na indústria de elevar pontuação, com custo baixo e fácil implementação, com efeito claro em perguntas curtas. Em tarefas longas, porém, há dois problemas: a entrega é um arquivo, o que impede uma votação simples; e quando os resultados coincidem, a votação preserva o erro comum tal como está. Os dois caminhos do VeriHarness atacam exatamente esses dois problemas.
Outra abordagem comum é usar um modelo como juiz, que lê alguns resultados e atribui uma nota diretamente. Essa abordagem depende do julgamento de leitura do juiz e não retorna ao ambiente para verificar. O VeriHarness coloca no centro a possibilidade de encontrar evidências no ambiente, ao custo de a própria revisão se tornar uma tarefa de agente que precisa chamar ferramentas e consumir tokens. O artigo não apresenta a proporção de custo extra da revisão em relação à geração; empresas que queiram calcular esse custo, por ora, só podem testar por conta própria.
O site já havia noticiado o benchmark ThinkingBox, da Microsoft, que exige repetir a avaliação da mesma tarefa 20 vezes para observar se os resultados do agente são estáveis. Colocando os dois trabalhos lado a lado, a direção é a mesma: em tarefas longas, a pontuação de uma única execução tem valor de referência limitado, e a diferença entre várias execuções é, em si, um sinal — um usa isso para medir estabilidade, o outro para corrigir erros.
Já pode ser usado diretamente
O README especifica que o ambiente de execução é Linux, exigindo Python 3.10 ou superior, Node.js 22.19 ou superior, Docker e namespaces de usuário sem privilégios; na camada inferior, roda sobre o runtime de código aberto pi, de modo que qualquer provedor de modelo suportado pelo pi pode ser conectado. A página do projeto também traz uma frase:
"This is not an officially supported Google product." (Este não é um produto oficialmente suportado pelo Google.)
Ou seja, por ora trata-se apenas de código de pesquisa, e o Google não se compromete a mantê-lo. Os dois modelos testados no artigo não são a geração mais recente de cada fornecedor; quanto da melhoria restaria ao trocar para o Gemini 4 ou o Opus 5.5, os autores não testaram — isso só poderá ser respondido por reproduções de terceiros.
Fontes: artigo no arXiv "VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks", página do projeto do Google Research no GitHub, CocoLoop, página do conjunto de dados no Hugging Face; o artigo e o README confirmam os nomes dos cinco benchmarks, os ganhos médios de pontuação dos dois modelos, as cerca de 26 mil trajetórias e os requisitos de ambiente.