Agentes de Fronteira Atingem 65% em Verificação de Estado em Fluxos de Produção

Todo grande benchmark de uso de computador agora mede o sucesso da tarefa final. Desktop-Delta Bench (DDB) mede algo mais restrito e, para fluxos de produção, mais consequente: se um agente consegue dizer que sua última ação realmente funcionou.

Publicado em 28 de julho por Abhishek Pillai, Samir Kumar Nayak e Yuan Chen, DDB é um benchmark offline em nível de passo com 2.013 instâncias verificadas por humanos de trajetórias multi-app Linux em 15 aplicações e 50 domínios de tarefas. O benchmark isola três modos de falha — verificação de estado, rastreamento de origem e controle ciente de contexto — através de 463 instâncias de ordenação temporal de três quadros (105 com decoys entre trajetórias) e 1.550 pares antes-depois rotulados em cinco tipos de ação.

O problema raiz é direto, mas subestimado em stacks de produção. Inferência, entrada remota, renderização de aplicativo e captura de screenshot são todas assíncronas. Uma observação que chega após uma ação pode estar atrasada, obscurecida, transitória ou retirada de um quadro não relacionado. Um agente que não consegue distinguir um screenshot desatualizado de uma transição de estado bem-sucedida tratará o quadro antigo como confirmação, carregará a crença incorreta para frente e planejará etapas subsequentes em uma premissa quebrada.

Os resultados do benchmark mostram que o campo não resolveu isso. Em 8 famílias de modelos em 32 configurações de ordenação e 16 configurações de ação única, a melhor taxa de correspondência exata de ordenação temporal sem decoy é 65,1% e a melhor taxa com decoy é 65,7%. Adicionar contexto de tarefa melhora a identificação de decoy em 6,9 pontos percentuais, mas reduz a correspondência exata sem decoy em 2,2 pontos — um tradeoff que revela ajuste heurístico em vez de raciocínio causal. Modelos expostos a uma sequência apresentada a reproduzem em vez de reconstruir a transição real. Click atinge F1 de 0,96, mas drag cai para 0,76. Inferir a família de ação é mais difícil do que localizar onde a ação ocorreu.

Os riscos são mais claros quando contrastados com onde os benchmarks de tarefa final chegaram. OSWorld, a referência de controle de desktop principal do campo, viu modelos de fronteira atingirem 85,4% em OSWorld-Verified em meados de 2026, acima da linha de base humana de 72%. XLANG Lab reconheceu que o score não mede mais o problema subjacente. OSWorld 2.0 foi introduzido para estender a fronteira, mas ele mede o resultado final, não se o agente interpretou corretamente cada transição de estado intermediária. Até agentes fortes levam 1,4–2,7× mais passos do que humanos em tarefas equivalentes — um sintoma de repetir ações que não conseguem confirmar que tiveram sucesso em vez de detectar e se recuperar de comandos ignorados.

Para times que entregam automação multi-passo contra ERPs de cadeia de suprimentos, plataformas SaaS financeiras ou consoles de infraestrutura de nuvem, o problema de assincronicidade não é acadêmico. Esses sistemas introduzem atrasos entre comando e confirmação visível. Um envio de formulário levando três segundos para processar, uma escrita de arquivo ainda não descartada na UI, um modal aparecendo e desaparecendo mais rápido do que a cadência de screenshot — qualquer um produz a falha exata que DDB visa: um agente procedendo como se sua ação tivesse funcionado quando não funcionou. O pipeline não falha. Ele continua. Pesquisas da indústria colocam a parcela de líderes de engenharia reportando problemas significativos de visibilidade de agente em produção em 97%. Uma taxa de falha silenciosa de 20% em um fluxo de trabalho cobrado em $200 por mês sobe para aproximadamente $335 por mês uma vez que o tempo de correção humana downstream é incluído.

O dataset e código de avaliação de DDB estão disponíveis no HuggingFace. Validação pré-implantação é o caso de uso imediato: execute agentes candidatos através das tarefas de ordenação temporal e antes-depois antes de confiar neles em qualquer fluxo de trabalho onde ações devem ser confirmadas antes que a próxima etapa seja executada. O benchmark preenche a camada diagnóstica entre fundamentação de GUI e sucesso de tarefa final que métricas de tarefa final não conseguem ver.