Benchmark de agentes Android: como avaliar phone agents em 2026

O que um benchmark de agente Android deve medir

Um benchmark de agentes Android precisa medir duas coisas ao mesmo tempo: resultado verificado e processo controlado. O agente entendeu a intenção? Executou o efeito certo no telefone? Usou a autoridade mínima necessária? Pediu aprovação no momento correto? Verificou o estado final? Recuperou quando a tela, a permissão ou o app mudaram? Essas perguntas dizem mais sobre um phone agent do que uma sequência de toques plausíveis.

Quando construímos a FoneClaw, aprendemos que uma tarefa móvel pode parecer concluída na transcrição e ainda falhar no telefone real. O agente pode tocar no lugar errado, deixar uma mensagem como rascunho sem avisar, alterar um ajuste por tempo incorreto ou seguir após o usuário negar uma ação. Por isso, taxa de sucesso precisa vir acompanhada de evidência observável: estado antes, estado depois, aprovação usada, ferramenta chamada e recuperação oferecida.

O objetivo de uma avaliação prática não é encontrar um número mágico. É construir uma suíte que revele onde o agente é confiável, onde precisa de intervenção e onde deve parar. Para equipes que querem transformar testes em ciclo de melhoria, Phone agent autoaprimorável: versões, testes e reversão aprofunda governança, versões e reversão sem substituir este guia de benchmark.

O cenário de benchmarks móveis em 2026

Os benchmarks móveis de 2026 cobrem lacunas diferentes. Eles ajudam a montar uma avaliação melhor, mas seus resultados pertencem ao ambiente, às tarefas e ao método de cada estudo. Uma tabela única de liderança entre todos eles simplificaria demais o problema.

Esses trabalhos também reforçam uma lição para descoberta de capacidades. Antes de testar uma ação, o agente precisa saber quais ferramentas, apps, funções ou recursos existem e quais permissões acompanham cada um. A página Agentic Resource Discovery: catálogo confiável sem confundir descoberta com autorização aprofunda esse ponto.

Seis dimensões para uma suíte real de testes Android

Uma suíte real de teste de agentes GUI Android deve variar dimensões de forma independente. Mais passos nem sempre significam mais dificuldade; às vezes a parte difícil é uma permissão, um contato ambíguo, uma tela em idioma diferente ou uma ação que precisa parar.

1. Configuração: versão do Android, fabricante, idioma, tamanho de tela, tema, permissões iniciais, app padrão e estado de login.
2. Horizonte: tarefa de um passo, sequência curta, workflow longo, interrupção no meio e retomada depois de troca de app.
3. Apps envolvidos: tarefa dentro de um app, tarefa multi-app, app ausente, app em tela inesperada e app com conta diferente.
4. Intenção do usuário: pedido claro, pedido ambíguo, preferência oculta, instrução contraditória e correção durante execução.
5. Superfície de ação: GUI visível, ferramenta estruturada, host-side tool, atalho do sistema, workflow salvo e combinação entre elas.
6. Efeito colateral: leitura sem alteração, ação reversível, mudança temporária, envio externo, alteração sensível e ação com necessidade de aprovação.

Ao variar uma dimensão por vez, a equipe descobre a causa da falha. Um agente pode ser bom em GUI simples e fraco em personalização; bom em tarefas curtas e fraco em recuperação; rápido em leitura e perigoso em ações externas. O benchmark deve revelar esses perfis.

Na FoneClaw, essa forma de pensar ajuda a separar um problema de modelo de um problema de host Android. Se a intenção foi interpretada corretamente, mas o estado de tela estava desatualizado, a correção está na observação e verificação. Se o plano pulou aprovação, o problema está na política da tarefa.

Métricas além da taxa de sucesso

Taxa de sucesso é necessária, mas sozinha esconde o que um phone agent fez para chegar ao resultado. Uma avaliação de agentes móveis deve fixar denominador, política de retry, tempo máximo, número de intervenções humanas e critério de side effect antes da execução. Depois disso, vale registrar várias métricas.

• Pass verificado: o estado final bate com o esperado e foi observado por mecanismo independente.
• Checkpoints parciais: o agente chegou ao app certo, preparou o texto, pediu permissão ou deixou rascunho correto.
• Efeito errado: ação externa enviada, configuração alterada, contato incorreto ou app errado.
• Recuperação: falha explicada, permissão recuperada, tarefa retomada ou fallback oferecido.
• Intervenção humana: quantas vezes o usuário precisou tocar, corrigir, escolher ou cancelar.
• Latência e custo: tempo até primeira ação, tempo até resultado, chamadas de modelo, energia e uso de rede.
• Qualidade de trace: se o histórico permite entender ferramenta, entrada, aprovação, estado e resultado.

PhoneHarness é útil aqui porque pontua efeitos colaterais observáveis e registra execução auditável. Para uma arquitetura de telefone, isso conversa diretamente com identidade, permissão e auditoria. O guia Identidade de agentes de IA: permissões, aprovação por ferramenta e auditoria no Android detalha como registrar autoridade, aprovação e resultado sem tratar tudo como uma conversa solta.

Teste aprovações, permissões, contenção e parada

Segurança precisa entrar no placar, não ficar como observação final. Um benchmark de agentes de IA 2026 deve testar se o agente pede a menor autoridade necessária, se apresenta aprovação antes de efeito externo, se esclarece ambiguidade, se respeita rejeição e se para quando o usuário manda parar.

KnowU-Bench é relevante porque inclui personalização, consentimento proativo e contenção após rejeição. Esse tipo de teste evita uma métrica pobre de segurança. Uma alta taxa de recusa pode esconder baixa utilidade; uma alta taxa de conclusão pode esconder comportamento invasivo. O que queremos medir é calibração: agir quando há autoridade e contexto, perguntar quando falta informação, e conter execução quando a pessoa rejeita.

Em um telefone, aprovações precisam ser concretas. Enviar uma mensagem pede destinatário e corpo. Alterar Não Perturbe pede duração e estado final. Tirar screenshot pede contexto visível e uso pretendido. Iniciar chamada pede contato e app. A página UX de aprovação de agentes de IA no celular: confiança, contexto e recuperação aprofunda esse desenho de alvo, consequência e recuperação.

Também pontue parada. Se o usuário diz parar, o agente precisa interromper execução, preservar estado seguro e registrar onde ficou. Em tarefas sensíveis, uma parada correta vale tanto quanto uma conclusão bem-sucedida.

Como avaliaríamos tarefas atuais da FoneClaw

Na FoneClaw, usamos benchmarks como forma de projetar melhor, não como decoração de marketing. Este guia define uma matriz de avaliação; ele não publica uma pontuação da FoneClaw. A base atual da FoneClaw inclui assistente flutuante, anexação da tela atual, continuidade de tarefa, aprovações, parada, recuperação de permissões, melhorias em DND, volume, modo reunião, screenshot e ações rápidas. Essa base está disponível pela página de download da FoneClaw.

Uma matriz prática para FoneClaw deve cobrir cinco classes. A primeira é leitura de estado: verificar Bluetooth, volume, DND, permissões ou tela atual sem alterar nada. A segunda é controle reversível: ativar Não Perturbe por tempo definido, ajustar volume ou abrir app. A terceira é efeito externo com aprovação: preparar SMS, iniciar chamada ou compartilhar informação. A quarta é recuperação: remover permissão, mudar a tela, derrubar rede ou trocar app durante a tarefa. A quinta é interrupção: pedir parada enquanto o agente executa.

A página de recursos da FoneClaw descreve o escopo atual de capacidades e 100+ built-in tools. Para um caso de auditoria de permissões que pode virar teste concreto, Verificação de saúde do Android com IA: permissões, apps ocultos e acessos especiais oferece uma tarefa útil e observável.

Como montar um protocolo repetível de benchmark

Um protocolo repetível começa antes da primeira tarefa. Congele ambiente, aparelho, versão do Android, idioma, app padrão, estado de login, permissões iniciais, rede, modelo, prompt, política de retry e tempo máximo. Defina o estado inicial e o estado esperado de cada tarefa. Depois, varie apenas uma dimensão importante por rodada.

1. Escolha tarefas por classe: leitura, reversível, efeito externo, recuperação e interrupção.
2. Registre estado inicial com screenshot, log ou leitura estruturada.
3. Defina sucesso, parcial, falha segura e falha com efeito errado.
4. Execute com id de tarefa, versão, dispositivo, locale e política de retry fixos.
5. Grave aprovações, permissões, ferramentas chamadas, intervenções e tempo.
6. Verifique o side effect por observação independente.
7. Classifique recuperação e publique limitações do ambiente.

O primeiro teste deve ser reversível. Por exemplo: ativar Não Perturbe por 15 minutos, confirmar estado e voltar ao normal. Depois avance para mensagens preparadas sem envio, leitura de tela, Bluetooth, tarefas e Workflows. A boa avaliação de agentes Android nasce desse rigor pequeno: estado conhecido, ação observável, aprovação clara, recuperação documentada e comparação honesta dentro do mesmo ambiente.