Frameworks de agentes móveis de código aberto: como escolher

Escolha pelo trabalho que o agente precisa fazer

Os melhores frameworks de agentes móveis de código aberto não formam um placar único. A escolha começa pelo tipo de trabalho: entender visualmente uma tela de telefone, executar ações por uma árvore de acessibilidade, inspecionar trajetórias, usar dispositivos locais ou pagar por uma rota gerenciada. Código aberto dá acesso ao framework, mas não torna chamadas de modelo, manutenção, dispositivos na nuvem, licenças de dependências ou depuração automaticamente gratuitos.

Além do encaixe inicial, confira como a configuração sobrevive às atualizações. No Mobilerun, mudanças de outubro afetam a seleção de dispositivo e os arquivos de configuração por plataforma. Esses detalhes operacionais importam antes de executar uma tarefa, sem transformar a comparação em uma promessa de sucesso universal.

FoneClaw entra em outra categoria. Nós oferecemos uma rota Android pronta, com modelo configurável e ferramentas governadas, para quem quer usar ações suportadas no telefone sem manter um framework, executor e infraestrutura de inferência.

Compare configuração, execução, modelos e licença

Antes de escolher, separe quatro camadas. O framework decide como o agente observa, planeja e registra o fluxo. A inferência pode estar em uma API hospedada, em um servidor próprio ou em outro provedor. A execução no telefone depende de ADB, acessibilidade, simulador, serviço auxiliar ou conexão de dispositivo. A operação diária inclui registros, rastros, custos e recuperação quando a tela muda.

Confirme a licença da revisão que pretende adotar. A licença do repositório não cobre automaticamente pesos de modelo, serviços de inferência, dispositivos hospedados ou dados de teste. Para aprofundar a escolha do modelo, veja Melhores modelos de IA para agentes: escolha pela tarefa no Android.

Quando Open-AutoGLM faz sentido

Open-AutoGLM é uma boa escolha quando o projeto precisa estudar agentes visuais de telefone e você aceita preparar um ambiente técnico em torno de ADB. O repositório documenta controle por ADB para Android, HDC para HarmonyOS e uma rota separada de iOS com WebDriverAgent. No Android, entram configurações como depuração USB e ADB Keyboard, além do agente Python e de um endpoint de modelo.

Esse encaixe favorece equipes que querem explorar uma pilha de pesquisa, adaptar inferência e observar como um agente visual decide ações. O projeto também descreve confirmação para operações sensíveis e tomada humana em login ou captcha, o que é importante para não tratar automação de tela como execução irrestrita.

O ponto de custo fica na operação: uma API hospedada pode cobrar por uso, e inferência própria exige infraestrutura. Usar Open-AutoGLM não significa que o modelo roda no próprio celular, nem que todo app terá sucesso. Avalie dispositivo, executor, modelo e recuperação de falhas como peças separadas.

Quando escolher Mobilerun Framework ou Cloud

Mobilerun, antigo DroidRun, é útil quando você quer um framework local com CLI ou Python, observação por árvore de acessibilidade, capturas de tela, seleção de provedor de modelo e resultados estruturados. A preparação Android usa ADB, depuração USB e Portal. Trajetórias salvas e rastreamento com Arize Phoenix ou Langfuse ajudam a investigar por que uma ação falhou.

Separe Framework de Cloud. No primeiro, o agente roda na sua máquina e depende do seu dispositivo, provedor e manutenção. A rota Cloud é gerenciada e pode trabalhar com telefones locais conectados ou dispositivos virtuais e físicos hospedados, com fluxos por API. Isso muda custo, privacidade operacional, disponibilidade e responsabilidade pela infraestrutura. O suporte a iOS também exige configuração própria, não paridade presumida.

A atualização de 14 de outubro de 2026, em UTC mudou a seleção em mobilerun run: primeiro vale -d, depois ANDROID_SERIAL e, na ausência dos dois, o único dispositivo online. Se houver vários sem seleção, a execução para com erro, em vez de escolher o primeiro. Confira a lista de aparelhos conectados antes de iniciar.

No FastAgent, somente o primeiro bloco function_calls da resposta é executado; os posteriores são ignorados. Se uma chamada falhar, o restante daquele bloco é pulado. Examine o que já ocorreu e corrija a causa antes de repetir: isso não oferece rollback automático nem torna uma tentativa parcial transacional.

A mudança de 5 de outubro nos app cards e no Portal exige arquivos por plataforma: app_cards_dir/android/app_cards.json e app_cards_dir/ios/app_cards.json. O arquivo diretamente na raiz de app_cards_dir é ignorado. Na migração, confira também os identificadores Android e iOS. A configuração instala o Portal indicado para a versão do framework e preserva um Portal mais recente.

Durante uma execução, o Portal pode restaurar o serviço de acessibilidade e seu teclado. Se você pretende revogar esse acesso, pare o agente e confira o estado real no aparelho; não desative proteções do Android para manter a execução. Compatibilidade da árvore de interface no SDK Cloud e operações de toque e digitação sem repetição automática também merecem revisão na manutenção, sem serem prova de sucesso em qualquer aplicativo.

Quando Minitap mobile-use encaixa melhor

Minitap mobile-use faz sentido quando você quer automação móvel por linguagem natural com extração estruturada e provedores de LLM configuráveis. O projeto documenta Android físico ou emulador por ADB, e o início rápido em Docker é voltado ao Android. Para iOS, o README lista simuladores no macOS e afirma que dispositivos físicos ainda não são suportados, mesmo que outras mensagens do ecossistema falem de forma mais ampla sobre plataformas.

Esse framework é atraente para tarefas estruturadas, como navegar por uma interface, extrair um resultado ou validar uma sequência simples. O próprio projeto nota limites quando jogos ou apps não expõem informação suficiente por árvore de acessibilidade. Isso não é um defeito isolado: em agentes móveis, a qualidade da observação condiciona a ação.

Antes de colocar mobile-use em uma esteira de teste, confirme a licença Apache-2.0 do repositório, o provedor de LLM, o tipo de dispositivo, a forma de inspeção e o custo operacional. Código aberto reduz bloqueio de fornecedor no framework, mas não remove a necessidade de manter o ambiente.

Teste uma tarefa reversível e inspecione falhas

Como avaliação proposta com base na documentação, use a mesma tarefa pequena em cada ambiente: abrir um aplicativo inofensivo escolhido por você em um telefone de teste próprio e confirmar sua tela inicial. Não apresentamos resultados de execução deste roteiro. Evite pagamentos, envio de mensagens, exclusão, login sensível ou alteração de conta.

1. Preparação: registre aparelho, sistema, conexão, permissões, serviço auxiliar, provedor de modelo e custo esperado.
2. Destino: inspecione a lista de dispositivos e confirme qual está autorizado para a tarefa. No Mobilerun, selecione com -d ou ANDROID_SERIAL quando necessário.
3. Configuração: confira a plataforma e os identificadores do aplicativo; em uma migração do Mobilerun, revise as pastas de app cards.
4. Entrada: peça apenas para abrir o aplicativo escolhido, sem operações adicionais.
5. Execução: observe qual aparelho recebe a ação. Pare se for o destino errado ou se uma etapa falhar.
6. Inspeção: preserve registros, capturas, trajetórias e respostas estruturadas quando disponíveis. Não repita sem saber quais ações já ocorreram.
7. Resultado: confirme a tela real no telefone, não apenas a resposta do modelo. Ao encerrar, revise serviços e permissões que devem permanecer desativados.

Se a observação estiver incompleta ou a tela mudar, repare essa causa antes de retomar. Uma chamada interrompida pode ter deixado efeitos anteriores, mesmo que o restante do fluxo não tenha executado.

Para transformar esse roteiro em avaliação mais completa, use Benchmark de agentes Android: como avaliar phone agents em 2026. Se a dúvida for como intenção, aprovação e ação aparecem no telefone, Controlar telefone Android com agente de IA: da intenção à ação aprofunda a camada de execução.

Escolha uma rota Android pronta

Nem todo leitor precisa manter um framework de código aberto. Se você quer usar um agente Android para tarefas suportadas sem montar ADB, servidor de inferência, serviço auxiliar, rastreamento e dispositivos de teste, FoneClaw é nosso app Android pronto para uso: uma rota diferente de desenvolver e manter essa infraestrutura.

Na FoneClaw, o modelo configurado interpreta e planeja; as ferramentas habilitadas executam ações Android suportadas conforme permissões reais e a política de aprovação aplicável. Isso não significa que toda ação sempre peça confirmação, nem que qualquer aplicativo possa ser controlado. O modelo padrão gratuito facilita começar, e rotas opcionais de provedor têm suas próprias condições.

Não apresentamos a FoneClaw como framework de código aberto ou integração nativa com os três projetos. Para conferir nosso escopo, veja os recursos da FoneClaw. Se você quer pesquisar, modificar e manter uma pilha de agente, compare os frameworks acima; se quer uma experiência Android pronta, avalie o produto pela tarefa suportada e pelo resultado que consegue verificar.