Por que agentes de IA são lentos no celular: latência, permissões e recuperação

Por que agentes de IA parecem mais lentos que chatbots

A resposta curta para “por que agentes de IA são lentos?” é que um agente não está apenas gerando uma resposta. Um chatbot pode receber texto, consultar o modelo e devolver outro texto. Um agente de celular precisa observar o estado do Android, entender a intenção, escolher uma ferramenta, pedir permissão quando necessário, executar uma ação suportada, verificar se deu certo e recuperar quando o estado mudou no meio do caminho.

Isso muda a métrica. Em um chatbot, o usuário mede tempo até a primeira resposta. Em um phone agent, existem pelo menos duas medidas: tempo até o primeiro feedback e tempo até o resultado verificado. A primeira diz se o sistema parece vivo. A segunda diz se a tarefa realmente terminou. Um agente rápido no primeiro texto ainda pode ser lento no resultado final se errar a ferramenta, encontrar uma permissão ausente ou precisar refazer uma etapa.

Também é um erro culpar apenas o LLM. O modelo pode ser uma parte relevante da latência, mas não é a única. Rede, estado de tela, app de destino, permissões Android, aprovação humana, chamadas de ferramenta e recuperação de falhas podem pesar tanto quanto a inferência. Para entender a arquitetura de execução por trás dessas etapas, veja Controle do celular por agente de IA: como funciona no Android.

De onde vem a latência de agentes de IA

A latência de agentes de IA deve ser medida como uma cadeia, não como um único cronômetro. A cadeia começa no pedido do usuário e termina no resultado observado. Entre esses dois pontos há etapas que podem ser rápidas isoladamente, mas lentas quando ficam em série. Quando o agente precisa esperar o modelo, depois esperar uma ferramenta, depois esperar uma tela, depois esperar aprovação, a soma aparece como demora.

O primeiro conceito útil é tempo até feedback inicial. Ele inclui captação de voz ou texto, normalização do pedido, primeira resposta do modelo e uma mensagem curta de progresso. O segundo é tempo até resultado concluído. Ele inclui seleção de ferramenta, execução, permissões, estado do Android, resposta do app de destino, verificação e recuperação quando algo falha. Melhorar a experiência exige olhar para os dois.

Chamadas de ferramenta e rede podem ser paralelas em alguns fluxos, mas muitas ações no telefone precisam ser sequenciais: observar, decidir, agir e conferir. A pergunta prática não é “como remover etapas?”, e sim “qual etapa está atrasando esta tarefa específica?”.

Por que ações Android adicionam atraso

Um telefone real muda o tempo todo. A tela bloqueia, o app fecha, uma notificação cobre um botão, a rede oscila, o teclado aparece, uma permissão foi negada, a conta mudou, o modo de bateria limita atividade em segundo plano ou o app de destino mostra uma tela promocional. Um agente Android precisa lidar com esse estado vivo. Essa é uma das principais causas do tempo de resposta de agente no celular.

O atraso aparece quando o plano foi feito para um estado, mas a execução encontra outro. O modelo pode decidir “abrir calendário e criar evento”, mas o telefone pode estar em outra conta, sem permissão, com conflito de horário ou com o app pedindo atualização. Se o agente tentar forçar a ação sem verificar, pode errar. Se verificar, leva mais tempo. A verificação visível é justamente o que evita execução silenciosa no estado errado.

Também há ambiguidade de alvo. “Responda para João” pode apontar para contato pessoal, colega de trabalho, conversa em grupo ou e-mail antigo. “Abra o documento certo” pode depender de app, pasta, data, conta e extensão. Em uma conversa textual, o agente pode pedir esclarecimento. No Android, ele também precisa garantir que a ação preparada toca o alvo correto antes de enviar, abrir, apagar ou alterar.

Para acelerar agente Android, reduza ambiguidade. Diga o app, o alvo e o resultado desejado quando a tarefa importa. “Abra o WhatsApp e prepare uma resposta para João Silva dizendo que chego em 10 minutos” é mais rápido e seguro do que “responda para João”. O agente ainda pode ajudar, mas começa com menos incerteza.

Permissões e aprovações versus velocidade

Permissões e aprovações são pausas intencionais. O Android protege dados e ações restritas com permissões, como explica a visão geral oficial de permissões do Android. Um phone agent não deve contornar esse sistema. Quando uma tarefa precisa de câmera, localização, notificações, calendário, armazenamento ou outra capacidade protegida, o pedido precisa aparecer no contexto certo.

Existe também uma diferença entre permissão do sistema e aprovação de ação. Permissão permite acesso técnico. Aprovação confirma uma consequência. Um app pode ter permissão para acessar contatos, mas isso não significa que o agente deve enviar mensagem para qualquer contato sem revisão. Um agente pode preparar um e-mail, mas enviar é outra etapa. Essa distinção protege o usuário, mesmo quando adiciona alguns segundos.

O ganho de velocidade vem de política, não de remover segurança. A base atualmente disponível da FoneClaw adiciona gerenciamento por ferramenta, substituições de aprovação, recuperação de permissões e tratamento de falhas mais forte. Isso ajuda a reduzir atrito repetido: ferramentas de baixo risco podem seguir política mais leve, enquanto ações sensíveis continuam exigindo revisão próxima da execução.

Para aprofundar a parte de identidade, permissões e histórico, consulte Identidade de agentes de IA: permissões, aprovação por ferramenta e auditoria no Android. A conclusão de desempenho é simples: controles bem desenhados aceleram o caminho seguro; controles removidos apenas tornam o erro mais rápido.

Self-Harness e recuperação de falhas

Uma parte da latência vem de falhas repetidas. O agente tenta uma ferramenta, encontra estado inesperado, corrige o plano, tenta de novo, pede contexto, reabre app e finalmente conclui. Em tarefas reais, recuperar bem pode ser mais importante do que acertar sempre na primeira tentativa. A pesquisa externa Self-Harness: Autonomous Agentic Harness Optimization estuda agentes que melhoram seu harness a partir de trajetórias de execução, mostrando que a qualidade do harness influencia o desempenho além do modelo base.

A lição de engenharia que tiramos desse trabalho é direta: rastros de execução bons ajudam a entender por que um agente ficou lento. Quando sabemos qual ferramenta foi escolhida, que permissão faltou, qual estado do Android apareceu, onde a tentativa falhou e qual etapa recuperou o fluxo, conseguimos melhorar versões futuras com menos adivinhação. Esse aprendizado é diferente de deixar um agente reescrever a si mesmo no telefone; é uma disciplina de produto baseada em causa de falha, teste e resultado visível.

Na FoneClaw atual, aplicamos essa filosofia nos limites que já importam para o usuário: recuperação de permissões, tratamento de falhas, controles por ferramenta e encerramento claro quando uma ação não é suportada. Se uma chamada já falhou pelo mesmo motivo, o caminho melhor é explicar a próxima ação necessária. Se a conta está errada, peça escolha. Se a permissão falta, solicite em contexto. Se a ferramenta não cobre o caso, pare com uma alternativa compreensível.

Para evoluir nessa direção, autoaprimoramento precisa ter versão, testes de regressão, rollback, fronteiras de ferramenta e resultados verificáveis. É assim que uma equipe melhora o harness sem perder governança. Para aprofundar esse tema, veja Phone agent autoaprimorável: versões, testes e reversão. Velocidade real vem de aprender com falhas sem apagar controle.

Como medir e acelerar um agente Android

Para medir latência de agentes de IA, não use apenas “quanto tempo demorou?”. Separe o fluxo em etapas. Meça tempo até o primeiro feedback, tempo até o plano, tempo até a primeira ação, tempo parado em permissão, tempo parado em aprovação, número de retries, tempo até o resultado verificado e taxa de sucesso. Um agente que responde rápido mas falha duas vezes pode ser pior que um agente um pouco mais cauteloso que conclui na primeira.

A experiência percebida melhora quando o usuário sabe o que está acontecendo. Mensagens curtas como “vou verificar a tela”, “preciso de permissão de calendário” ou “rascunho pronto para revisar” reduzem a sensação de espera. Isso não acelera o relógio físico, mas melhora confiança. Em paralelo, o produto deve reduzir etapas repetidas, lembrar preferências por ferramenta quando apropriado e evitar pedir confirmação genérica demais.

Escolha de modelo também entra na conta. Um modelo mais rápido pode melhorar resposta inicial, mas não garante execução final mais rápida se escolher ferramentas ruins. Um modelo mais forte pode reduzir retries, mas aumentar inferência. Para analisar roteamento de modelos em phone agents, consulte Melhor modelo para agente de telefone: Kimi K3, DeepSeek V4 e GLM-5.2.

Como a FoneClaw encurta o caminho de ação governada

Na FoneClaw, nossa meta não é vencer um benchmark abstrato de chat. O objetivo é reduzir atraso evitável em ações Android suportadas sem esconder permissão, aprovação ou recuperação. O usuário pode começar com o modelo padrão gratuito ou configurar um modelo compatível usando API Base URL e API Key. O modelo ajuda no raciocínio; a FoneClaw governa ferramentas, permissões, aprovação e resultado no telefone.

As ferramentas da FoneClaw incluem mais de 100 ferramentas integradas para ações Android suportadas. Isso reduz improviso visual quando uma tarefa pode usar uma ferramenta governada. Ao mesmo tempo, não prometemos controle universal de todos os apps. Quando uma ação não é suportada, a resposta correta é explicar, pedir alternativa ou parar com segurança.

Para testar velocidade de forma útil, escolha uma tarefa de baixo risco: abrir um app, consultar estado visível, criar um lembrete simples ou preparar uma mensagem sem enviar. Observe o tempo até o primeiro feedback, a necessidade de permissão, a clareza da aprovação e a verificação final. Depois ajuste modelo, ferramenta e política onde fizer sentido.

A melhor forma de acelerar agente Android não é remover controles. É encurtar o caminho governado: intenção clara, modelo adequado, ferramenta correta, permissão no momento certo, aprovação compacta e resultado verificável. Esse é o padrão que torna um phone agent mais rápido sem transformá-lo em uma automação opaca.