Roteamento de modelos para agentes no celular: Kimi, DeepSeek, GLM e FoneClaw

Escolha uma rota, não um vencedor permanente

Roteamento de modelos para agentes no celular é a decisão de escolher qual modelo, endpoint ou rota local deve cuidar de uma tarefa específica antes que ela vire ação Android. A pergunta certa não é qual modelo vence para sempre. A pergunta útil é: qual rota entende este pedido, produz chamadas de ferramenta estáveis, responde rápido o bastante, cabe no orçamento e respeita o nível de privacidade necessário?

Um phone agent trabalha em camadas. O modelo interpreta linguagem, raciocina e prepara uma intenção estruturada. A camada de capacidades decide se existe uma ferramenta, Skill, Workflow, Plugin ou fallback aplicável. O Android decide permissões, telas, apps e estado do dispositivo. A aprovação do usuário decide se uma etapa sensível pode seguir. Por isso, um ranking de texto ou código não prova sucesso em mensagens, chamadas, lembretes, configurações ou navegação.

Essa é a razão para tratar Kimi, DeepSeek, GLM e outros modelos como rotas possíveis, não como troféus fixos. Um modelo pode ser ótimo para contexto longo, outro pode responder com menor latência, outro pode ser mais econômico em tarefas repetitivas, e outro pode funcionar melhor para chamadas de ferramenta em português. Quando a tarefa termina no telefone, a prova precisa acontecer no telefone.

Para configurar a parte de endpoint sem misturar isso com decisão editorial de modelo, mantemos o passo a passo em Como conectar uma API de modelo de IA a um agente Android na FoneClaw. Aqui, o foco é a política: quando usar, trocar ou manter uma rota.

Roteie por confiabilidade, latência, custo, contexto e privacidade

O primeiro sinal é confiabilidade. Em agentes Android, isso significa mais do que responder corretamente em linguagem natural. O modelo precisa seguir o esquema esperado, escolher argumentos consistentes, não inventar ferramentas, não pular confirmações e saber quando pedir mais contexto. A confiabilidade de chamadas de ferramenta aparece quando o mesmo pedido gera uma estrutura válida várias vezes, com contato, app, data, texto ou destino resolvidos de forma verificável.

O segundo sinal é latência. Uma tarefa no celular vive no ritmo da mão do usuário. Se o agente demora demais para preparar uma mensagem simples, abrir uma rota ou verificar o status do dispositivo, a experiência deixa de parecer assistida e vira interrupção. Latência pesa ainda mais em fluxos de voz, assistente flutuante e tarefas curtas, em que o ganho de um modelo maior pode não compensar a espera.

O terceiro sinal é custo. Custo de LLM não deve ser avaliado apenas por token isolado; ele precisa incluir tentativas, falhas, reprocessamento, contexto enviado, chamadas extras e suporte operacional. Um modelo barato pode sair caro se erra argumentos e força recuperação. Um modelo premium pode valer a pena se reduz falhas em tarefas complexas. Para aprofundar esse cálculo, o guia Custo por tokens em agentes de IA: por que agir no Android pode economizar mostra como custo muda quando parte do trabalho vira ação no dispositivo.

O quarto sinal é contexto. Janelas longas ajudam quando a tarefa realmente exige histórico, documentos, instruções extensas ou várias etapas. Elas não substituem precisão. Em um pedido curto como preparar uma mensagem para um contato, contexto demais pode aumentar custo e latência sem melhorar a ação. Contexto deve ser roteado por necessidade, não por fascínio técnico.

O quinto sinal é privacidade e implantação. Rotas online, modelos locais e endpoints personalizados têm restrições diferentes. Dados sensíveis, tarefas empresariais, anexos e conteúdo de tela exigem uma política clara sobre o que é enviado, para onde vai e como o usuário aprova. Em phone agents, privacidade também inclui visibilidade: o usuário precisa entender quando o modelo ajuda a planejar e quando a FoneClaw prepara uma ação Android.

Kimi, DeepSeek e GLM como candidatos atuais de roteamento

Kimi, DeepSeek e GLM entram neste guia como exemplos atuais de rotas a validar, não como um pódio fixo. O sinal recente de Kimi é disponibilidade em um seletor de modelo mainstream: o anúncio do GitHub sobre Kimi K3 no Copilot mostra que modelos antes vistos como opções de nicho estão chegando a fluxos de trabalho amplos. Isso é evidência de disponibilidade em produto de desenvolvimento, não prova automática de confiabilidade para ações Android.

DeepSeek continua relevante quando a política busca custo, acesso e boa relação entre qualidade e orçamento. Em um agente no celular, essa hipótese precisa ser testada em pedidos concretos: criar lembrete, preparar SMS, consultar informação do aparelho, resumir uma tela anexada ou escolher uma rota de navegação. O modelo barato só ajuda quando mantém argumentos corretos, baixa latência e recuperação aceitável.

GLM é um candidato interessante quando abertura, contexto e velocidade entram na conversa. Ainda assim, o mesmo limite vale: capacidade geral não garante chamadas de ferramenta estáveis em português, nem prova que a execução Android será confiável. A avaliação precisa medir comportamento dentro do contrato do agente.

Qwen, Hy3 e outros modelos ampliam o mapa porque mostram a variedade de ecossistemas, APIs e plataformas. A tendência de infraestrutura também é clara. O Google Developers descreveu uma API unificada para roteamento de modelos em preview público, sinal de que equipes querem alternar provedores por política, disponibilidade e custo sem reconstruir toda a aplicação. Para FoneClaw, esse tipo de sinal reforça uma direção de produto que já seguimos: separar modelo de raciocínio, roteamento de capacidade e execução Android.

Como reagir a mudanças de preço e disponibilidade sem quebrar tarefas

Preço, limite de uso, disponibilidade regional e comportamento de modelo mudam. Uma política durável de roteamento precisa aceitar essa realidade sem transformar cada mudança em quebra de fluxo. O primeiro passo é classificar tarefas por risco e custo: consulta simples, preparação de conteúdo, ação reversível, ação sensível e fluxo longo. Cada classe deve ter uma rota principal, uma rota de fallback e um critério de revalidação.

Quando o custo de LLM sobe, o agente não deve trocar silenciosamente uma tarefa sensível para qualquer modelo disponível. O usuário pode não perceber que o raciocínio mudou, mas a qualidade de argumentos, o idioma e a recuperação podem mudar junto. Para fluxos com comunicação, dados pessoais, arquivos ou decisões importantes, a troca de modelo precisa preservar aprovação e resultado visível.

Quando a rota principal fica lenta ou indisponível, o fallback deve ser limitado pelo tipo de tarefa. Uma mensagem simples pode ir para um modelo rápido se ele passar nos testes de contato, texto e confirmação. Uma tarefa com contexto longo pode esperar, reduzir contexto ou pedir escolha ao usuário. Uma ação sensível pode parar com uma explicação clara em vez de seguir por uma rota não validada.

A revalidação deve medir falhas reais. Quantas vezes o modelo inventa campo? Quantas vezes escolhe uma ferramenta inexistente? Quantas vezes pede permissão errada? Quantas vezes o usuário cancela porque o conteúdo preparado não bate com a intenção? Esses dados valem mais do que um preço isolado ou uma nota de benchmark.

Meça qualidade do modelo dentro do ciclo de ação Android

Um modelo pode dar uma resposta excelente e ainda falhar no telefone. Por isso, avaliamos o modelo dentro do ciclo Android completo: intenção, plano, argumentos, estado do aparelho, aprovação, execução, resultado e recuperação. O mesmo teste deve rodar no mesmo dispositivo, com a mesma conta, o mesmo idioma e o mesmo conjunto de permissões. Só assim a comparação entre rotas é justa.

Comece por uma tarefa reversível. Peça para criar uma nota, preparar uma mensagem sem enviar, abrir uma tela de configurações ou listar eventos de calendário. Observe se o modelo entende o pedido em português natural, se escolhe a capacidade correta e se preenche campos sem inventar dados. Depois, veja se a FoneClaw consegue preparar a ação no Android e mostrar o resultado antes de qualquer etapa sensível.

Em seguida, teste falhas controladas. Remova uma permissão, use um contato ambíguo, deixe o app de destino deslogado ou peça uma ação fora do suporte. Um bom modelo ajuda a explicar o bloqueio e escolher fallback. Um bom runtime impede que a ação avance sem base. Essa combinação é mais importante do que resposta bonita em ambiente isolado.

Para comparar agentes pelo fluxo inteiro, o guia Benchmark de agentes Android: como avaliar phone agents em 2026 detalha como medir sucesso, falha, recuperação e confiança em tarefas reais. O ponto central é simples: benchmark de texto não é benchmark de execução.

Configure o raciocínio do modelo enquanto a FoneClaw governa a execução

Na FoneClaw, o usuário pode começar com o modelo padrão gratuito ou configurar uma rota compatível, incluindo modelos online e rotas no dispositivo quando suportadas. O modelo orienta compreensão, raciocínio e planejamento. A FoneClaw governa a execução Android: seleciona capacidades suportadas, usa ferramentas com escopo definido, mostra resultados, pede aprovação em etapas sensíveis, permite parar o fluxo e orienta recuperação quando uma permissão ou estado do aparelho bloqueia a tarefa.

Essa separação evita dois erros. O primeiro é achar que trocar de modelo dá autoridade para controlar qualquer app. Não dá. O Android continua exigindo permissões, tela visível, apps disponíveis e ações suportadas. O segundo erro é tratar o runtime como se fosse apenas uma janela de chat. A FoneClaw foi construída para conectar o raciocínio do modelo a 100+ ferramentas integradas e a fluxos governados no telefone.

O roteamento de capacidade também é separado da aprovação. Recursos como anexar a tela atual, sugerir uma capacidade ou cair para fallback ajudam o agente a escolher o caminho, mas não pulam a confirmação quando a ação envolve comunicação, dados ou alteração sensível. Para nós, isso é parte da confiabilidade: um agente útil não é aquele que age escondido, e sim aquele que prepara o passo certo e deixa o usuário aprovar no momento certo.

Um teste prático é comparar duas rotas no mesmo aparelho. Peça a mesma tarefa curta, como criar uma nota a partir de uma tela anexada ou preparar uma mensagem para revisão. Meça entendimento, latência, correção dos argumentos, clareza do resultado e comportamento quando a permissão falta. Para entender a camada de ação Android que recebe esse planejamento, veja Controle do celular por agente de IA: como funciona no Android.

Monte uma política prática de roteamento para phone agents

Uma boa política de roteamento começa com classes de tarefa. Para perguntas simples e ações reversíveis, use uma rota rápida e econômica que passe no mínimo de confiabilidade. Para tarefas com documentos, múltiplas etapas ou ambiguidade, suba para um modelo com melhor contexto e raciocínio. Para fluxos sensíveis, mantenha aprovação explícita e evite troca silenciosa para rotas não validadas.

1. Classifique a tarefa: informação, preparação, ação reversível, ação sensível ou fluxo longo.
2. Defina o piso de qualidade: esquema válido, argumentos corretos, idioma adequado e baixa taxa de alucinação de ferramenta.
3. Defina o teto de custo: inclua tentativas, contexto enviado, recuperação e fallback.
4. Escolha o fallback: rota alternativa, redução de contexto, pausa com explicação ou pedido de confirmação.
5. Teste no aparelho real: use as mesmas permissões, conta, idioma e app de destino.
6. Registre modos de falha: contato errado, permissão ausente, app deslogado, latência alta, campo inválido ou usuário cancelando.

A conclusão deliberada é não escolher um campeão universal. Kimi, DeepSeek, GLM, Qwen e outros modelos podem ser bons em rotas diferentes. O valor para um agente no celular aparece quando essa escolha vira política: modelo certo para a tarefa certa, execução Android governada e resultado que o usuário consegue revisar.