Falha do modelo do assistente de IA no Android: nova tentativa, modelo alternativo e retomada segura
Aprenda a diagnosticar falhas de modelo no Android, preservar o estado da tarefa, repetir com segurança, trocar para modelo compatível e retomar sem duplicar ações.
- Classifique a falha antes de repetir: indisponibilidade, limite de uso, credenciais, rede, tempo esgotado e modelo desativado pedem respostas diferentes.
- Preserve o estado da tarefa no telefone antes de qualquer nova tentativa, separando resposta do modelo, ação Android concluída e etapa ainda sem confirmação.
- Trocar para um modelo alternativo deve ser uma decisão manual, compatível e baseada no próximo passo seguro, não uma repetição cega do pedido inteiro.
- Na FoneClaw, mantemos progresso, nova tentativa, feedback contextual e configuração de modelo visíveis para recuperar raciocínio sem duplicar ações Android.
Identifique se a falha é queda, limite, credencial, rede ou modelo desativado
Quando aparece uma falha do modelo do assistente de IA no Android, a primeira decisão não é repetir. É classificar. Um assistente pode parar de responder porque o provedor está instável, porque sua conta atingiu limite, porque a chave de API expirou, porque a rede do telefone caiu, porque a resposta demorou demais ou porque o modelo escolhido saiu do ciclo de suporte. O mesmo texto genérico na tela pode esconder causas bem diferentes.
Comece por sinais observáveis. Se vários pedidos simples falham ao mesmo tempo, uma queda do provedor entra como hipótese. Se só tarefas longas falham, pode haver tempo esgotado, contexto grande demais ou instabilidade de rede. Se tudo que usa um provedor específico falha, mas outro modelo responde, olhe credencial, cota e modelo configurado. Se a resposta chega, mas a ação Android não termina, o problema saiu da camada do modelo e entrou no estado do telefone, na permissão, no app ou na ferramenta.
Fontes oficiais de provedores ajudam a separar essas classes. Um relatório de erros elevados e latência na OpenAI mostra como uma alteração de configuração pode aumentar falhas e depois ser mitigada. O status da xAI também registrou uma indisponibilidade de modelos Grok no Android já resolvida. Esses exemplos mostram falhas transitórias reais, mas não transformam todo erro em queda global.
Na FoneClaw, separamos raciocínio do modelo e execução Android porque a recuperação depende dessa fronteira. Uma falha de LLM pode impedir a próxima resposta, enquanto uma ação no telefone pode já ter sido concluída, estar aguardando aprovação ou ter parado por falta de permissão. Diagnosticar a camada certa evita repetir uma tarefa que já mexeu no telefone.
Preserve o estado da tarefa antes de repetir
Antes de qualquer nova tentativa, registre o estado real da tarefa. O que o usuário pediu? Qual modelo estava em uso? Qual foi a última resposta completa? Alguma ação Android foi aprovada? O app abriu? A mensagem foi apenas preparada ou enviada? O evento foi criado? A configuração mudou? Uma recuperação segura começa pelo que foi verificado, não pela ansiedade de reenviar o comando original.
Divida a tarefa em três colunas: planejado, concluído e incerto. Planejado é o que o assistente pretendia fazer. Concluído é o que você consegue provar na tela, no app ou no estado do Android. Incerto é tudo que ficou entre resposta cortada, ferramenta em andamento, permissão pendente, tela inesperada ou app sem confirmação. A repetição só deve continuar a partir da primeira etapa incerta.
Esse cuidado é essencial em ações consequentes. Repetir “envie a mensagem para Carla e crie um lembrete” pode mandar duas mensagens ou criar dois lembretes se a primeira tentativa já executou parte do trabalho. A alternativa correta é perguntar: a mensagem já foi enviada? O lembrete existe? O destinatário estava certo? A aprovação foi confirmada? Só depois disso o assistente pode retomar.
Para falhas que vão além do modelo, como permissão quebrada, app travado, tela que mudou ou ação incompleta, o guia Como depurar e recuperar falhas de agentes de IA no celular Android aprofunda a recuperação do lado do telefone. Neste guia, o foco é manter a fronteira clara: a resposta do modelo pode falhar sem que o estado do Android volte automaticamente ao início.
| Campo | O que registrar | Por que importa |
|---|---|---|
| Último estado confirmado | Tela aberta, app ativo, item criado ou configuração visível | Impede repetir uma ação já concluída |
| Última aprovação | Quem aprovou, qual alvo e qual efeito | Define se uma nova confirmação é necessária |
| Etapa incerta | Resposta cortada, tempo esgotado, ferramenta pendente ou erro | Marca o ponto correto de retomada |
| Risco de duplicação | Mensagem, pagamento, agenda, contato, e-mail ou exclusão | Exige verificação antes de novo envio |
Repita falhas transitórias sem sobrecarregar o serviço
Repetir é útil quando a falha é transitória: tempo esgotado, resposta incompleta, erro temporário do servidor, instabilidade de rede ou sobrecarga do provedor. Torna-se perigoso quando acontece rápido demais, muitas vezes seguidas ou sobre um erro permanente. Um relatório de interrupção do ChatGPT e da plataforma OpenAI descreveu tráfego de novas tentativas ampliando a carga durante a falha. A lição prática é direta: insistência sem limite pode piorar a recuperação.
Use um padrão simples. Faça uma tentativa curta depois de verificar rede e estado da tarefa. Se falhar de novo, espere mais. Se houver outra falha, pare e consulte status, cota, credencial e modelo. Para erros de servidor, a documentação de erros da API Claude da Anthropic distingue autenticação, limite de taxa, erro interno, tempo esgotado e sobrecarga, e recomenda espera progressiva para erros de servidor recuperáveis.
Nem todo 429 merece a mesma reação. Um limite temporário de taxa pode melhorar depois de aguardar. Um limite de gasto, plano ou cota pode persistir até que a conta seja ajustada. Um erro 401 não melhora com repetição; ele pede credencial correta. Um modelo desativado também não volta por insistência. Classificar antes de repetir economiza tempo e protege o telefone.
Em tarefas Android, a nova tentativa deve ser ainda mais conservadora. Repetir uma resposta é diferente de repetir uma ferramenta que envia, cria, altera ou apaga. Se a falha aconteceu antes da ação, tentar de novo pode ser seguro. Se aconteceu depois de uma aprovação, primeiro leia o estado do app. Para ações de alto risco, pare e retome manualmente. Quando for necessário conter uma tarefa em andamento, Como parar um agente de IA no Android e conter ações explica o caminho de interrupção e controle.
Troque de modelo só depois de checar compatibilidade e estado
Trocar modelo sem repetir ações começa com uma regra: a troca muda o serviço de raciocínio, não muda automaticamente o que já aconteceu no telefone. Se um modelo falhou ao resumir, planejar ou decidir o próximo passo, outro modelo compatível pode ajudar. Se uma ação Android já foi aprovada ou executada, o novo modelo precisa receber um resumo do estado confirmado antes de continuar.
Escolha o modelo alternativo deliberadamente. Verifique se ele aceita o tipo de entrada necessário, como texto longo, imagem, tela, ferramentas, idioma ou formato de resposta. Alguns modelos respondem bem a raciocínio curto, outros lidam melhor com contexto extenso, multimodalidade ou instruções estruturadas. Parâmetros, limites e formatos também variam. A compatibilidade deve ser testada com uma solicitação pequena antes de retomar uma tarefa com efeito no telefone.
Na FoneClaw, o usuário pode começar pelo caminho de modelo padrão e configurar um modelo online compatível quando tem endpoint, chave e formato adequados. A área dedicada de modelos personalizados facilita revisar e editar essa configuração sem esconder a troca do usuário. Para comparar rotas de modelo em agentes de telefone, Roteamento de modelos para agentes no celular: Kimi, DeepSeek, GLM e FoneClaw aprofunda seleção e roteamento sem misturar esse diagnóstico com benchmark.
Ao trocar, leve só o contexto necessário: objetivo original, passos concluídos, última tela confirmada, itens já enviados ou criados, permissões concedidas e primeiro passo incerto. Peça ao novo modelo para continuar a partir desse ponto, não para refazer tudo. Se o próximo passo envolve mensagem, e-mail, contato, calendário, arquivo, compra ou configuração sensível, gere uma nova aprovação com alvo e efeito claros.
Retome pelo primeiro passo sem confirmação e verifique o resultado
A retomada segura começa no primeiro passo sem confirmação. Se o assistente gerou o texto de uma mensagem e falhou antes de abrir o app, retome pela abertura ou preparação. Se abriu o app e falhou antes do envio, confira destinatário e texto. Se enviou e a resposta do modelo caiu depois, não envie de novo; verifique o histórico da conversa. A resposta pode ser recuperada enquanto a ação Android já está completa.
Use leituras idempotentes antes de escritas. Ler uma tela, consultar um estado, listar eventos, verificar contatos, abrir um item ou conferir se uma configuração mudou reduz risco. Escrever, enviar, apagar, criar e atualizar devem vir depois da verificação. Essa ordem evita duplicação e dá ao usuário uma prova do estado real antes da próxima aprovação.
Uma boa retomada deve dizer explicitamente: “estas etapas já foram confirmadas; esta etapa ficou incerta; o próximo passo seguro é este”. Esse padrão ajuda tanto o usuário quanto o modelo alternativo. Ele também reduz a tentação de pedir “faça de novo”, que é uma frase curta e perigosa quando o telefone pode executar ações reais.
Depois da retomada, verifique o resultado no local de destino. Um lembrete precisa aparecer no app de tarefas ou calendário. Uma mensagem precisa aparecer no chat certo. Um e-mail precisa estar em rascunho, enviado ou cancelado conforme a aprovação. Uma configuração precisa mostrar o novo estado. Na FoneClaw, estamos construindo a experiência para deixar esses pontos mais visíveis, porque a conclusão de uma tarefa de telefone precisa ser observável, não apenas narrada.
- Identifique a última etapa confirmada.
- Leia o estado atual antes de qualquer nova escrita.
- Retome pelo primeiro passo incerto.
- Peça nova aprovação quando alvo ou efeito mudarem.
- Verifique o resultado no app, tela ou configuração final.
Trate cotas, credenciais vencidas e modelos desativados como configuração
Algumas falhas parecem indisponibilidade, mas são configuração. Um 401 aponta para autenticação, chave inválida, token vencido ou conta sem acesso. Um 429 pode ser limite temporário, mas também pode indicar cota, plano ou limite de gasto. Tempo esgotado pode vir de rede, prompt longo, ferramenta lenta ou provedor sobrecarregado. Modelo desativado exige troca para um modelo atual, não repetição infinita.
A documentação de erros da Anthropic separa autenticação, limite de taxa, tempo esgotado, erro interno e sobrecarga. A página de desativações de modelos Claude mostra outro tipo de falha: quando um modelo sai de uso, a correção é migrar para substituto indicado pelo provedor. Cada fornecedor tem calendário e nomes próprios, então a manutenção precisa seguir a documentação oficial de quem fornece o modelo.
Ao corrigir credenciais, não cole chaves em chats, tickets públicos ou capturas de tela. Atualize a chave no local de configuração, teste com uma chamada pequena e depois retome a tarefa pelo estado preservado. Se o problema é cota, espere a janela de reset, ajuste plano ou escolha outra rota compatível. Se é modelo desativado, selecione um modelo atual e revise diferenças de contexto, custo, velocidade e formato.
Na FoneClaw, tratamos configuração de modelo como parte do controle do usuário. O guia Como conectar uma API de modelo de IA a um agente Android na FoneClaw mostra como pensar em endpoint, chave, modelo compatível e teste inicial. O objetivo é manter a troca compreensível: o usuário sabe qual modelo está usando, que tarefa vai retomar e qual ação Android ainda precisa de verificação.
Use o fluxo visível da FoneClaw sem duplicar ações no telefone
Na FoneClaw, construímos recuperação de falha com uma separação clara: estado da resposta, estado da tarefa e estado da ação Android. O usuário pode revisar progresso, reler uma resposta longa, tentar novamente quando a etapa é segura e enviar feedback com o contexto relevante quando algo não ficou correto. Essa visibilidade reduz o impulso de reiniciar tudo e ajuda a preservar o que já foi concluído.
Quando o modelo falha antes de qualquer ação no telefone, repetir a resposta costuma ser o caminho mais simples. Quando a falha acontece depois de uma ferramenta, o próximo passo é verificar o efeito. Se a ação abriu um app, confira a tela. Se preparou um rascunho, revise o conteúdo. Se alterou uma configuração, leia o estado atual. Se ficou aguardando permissão, recupere a permissão antes de pedir ao modelo para continuar.
Também damos espaço para escolha manual de modelo. O usuário pode seguir com o modelo padrão ou configurar um modelo online compatível para tarefas que pedem outra capacidade. A troca deve carregar um resumo do estado, não uma repetição do comando inteiro. Esse é o ponto que aprendemos repetidamente ao construir agentes de telefone: recuperação boa preserva intenção e evidência, enquanto recuperação ruim duplica efeito.
As capacidades atuais de ação, configuração e recuperação ficam na página de recursos da FoneClaw, incluindo 100+ built-in tools para tarefas Android suportadas. A instalação atual está em download da FoneClaw. Estamos avançando a coordenação de tarefas complexas, o feedback contextual, a revisão de respostas, a edição de modelos personalizados e a retomada para que falhas de modelo deixem de ser pontos cegos e virem etapas recuperáveis.
O primeiro teste recomendado é simples: peça uma tarefa reversível, interrompa a resposta ou simule uma falha de rede, depois retome pelo primeiro passo incerto. Se a FoneClaw mostra o estado, evita duplicar ação e confirma o resultado, o fluxo está pronto para tarefas mais longas. Para tarefas de risco, mantenha a regra final: parar, verificar e aprovar antes de continuar.