Ensinar um agente de telefone mostrando a tarefa: gravação, skills e segurança

O que significa ensinar mostrando a tarefa

Um agente pode aprender um fluxo apenas observando a tela? A demonstração pode fornecer um exemplo valioso, sobretudo quando vem acompanhada de uma explicação sobre o objetivo e as decisões tomadas. O aprendizado útil, porém, não consiste em decorar coordenadas ou reproduzir um vídeo. Ele precisa separar a lógica da tarefa dos detalhes acidentais daquela execução.

O sinal mais concreto veio do Claude Cowork. Segundo a reportagem da ITmedia publicada em 22 de julho de 2026, o recurso Record a Skill registra uma tarefa e a explicação falada do usuário para convertê-las em uma skill reutilizável. A experiência publicada pelo Android Authority em 21 de julho descreve a gravação da tela enquanto a pessoa explica o fluxo, com o objetivo de reduzir instruções repetidas em tarefas recorrentes.

Esse recurso torna a interação fácil de imaginar, mas não deve ser confundido com controle de um telefone Android. O Claude Cowork oferece o exemplo de gravação convertida em habilidade em seu próprio contexto. A pergunta deste guia é mais ampla: como aplicar o mesmo princípio a fluxos de aplicativos móveis que mudam de estado, solicitam permissões e podem chegar a ações importantes?

Uma boa demonstração ensina que determinado botão representa “adicionar o contato correto”, e não “tocar a 420 pixels da borda”. Essa diferença aproxima a gravação de uma especificação prática. Para entender como o telefone pode se tornar a interface de um agente sem confundir produtos distintos, consulte Claude Cowork no celular: por que o telefone vira a interface do agente de IA.

Da gravação a uma skill reutilizável

Como uma única execução se transforma em algo que possa ser chamado novamente? O caminho precisa passar por captura, explicação, extração de regras, definição de parâmetros, empacotamento e validação. Pular qualquer uma dessas etapas produz uma automação que parece funcionar no exemplo original, mas não sabe lidar com a próxima situação.

A captura registra os estados relevantes da interface e as ações realizadas. A explicação falada acrescenta o motivo: “escolho este contato porque pertence ao projeto”, “não envio se o anexo estiver ausente” ou “paro quando o valor ultrapassa o limite”. A combinação ajuda a distinguir objetivo, pré-condições, decisões e resultado. Sem essa narração, o sistema pode interpretar como regra uma escolha que foi apenas circunstancial.

Em seguida, a demonstração precisa ser convertida em uma estrutura reutilizável. Nomes, datas, destinatários, arquivos e quantidades viram parâmetros. Decisões recorrentes se tornam condições. Telas necessárias formam pré-condições, enquanto mensagens de sucesso, itens criados ou alterações visíveis definem o resultado esperado. Exceções também entram no pacote: conta desconectada, item inexistente, permissão ausente ou aplicativo em estado inesperado.

1. Capturar: registrar apenas a sequência necessária, com uma conta e dados preparados para demonstração.
2. Explicar: narrar o objetivo, o motivo de cada escolha e as situações em que o fluxo deve parar.
3. Extrair regras: separar decisões semânticas de toques, posições e textos incidentais.
4. Parametrizar: substituir valores do exemplo por entradas que possam mudar em cada uso.
5. Empacotar: definir nome, propósito, entradas, permissões, ações, confirmações e resultado.
6. Invocar: permitir que o usuário solicite a tarefa com novos parâmetros e veja o plano aplicável.

Uma skill bem formada não recebe autoridade geral sobre o aparelho. Ela descreve um trabalho delimitado e os recursos necessários para realizá-lo. Se o usuário demonstrou como enviar um relatório a um contato específico, a habilidade não deve inferir autorização para enviar qualquer arquivo a qualquer pessoa. A relação entre capacidade e permissão é aprofundada em Segurança de habilidades de agentes de IA no celular.

Esse processo também é diferente de treinar um agente com milhares de ambientes simulados. O artigo PhoneBuddy-4B e treinamento de agentes no celular: por que Mock-App RL importa no Android trata da preparação de modelos para lidar com interfaces. A demonstração descrita aqui empacota o conhecimento operacional de uma tarefa específica para uso controlado.

Por que uma repetição literal falha no Android

Por que não basta guardar todos os toques e executá-los novamente? Porque a tela do Android representa um estado dinâmico. Uma notificação pode deslocar conteúdo, uma lista pode mudar de ordem, um aplicativo pode abrir em outra aba e uma atualização pode renomear um controle. Até duas execuções consecutivas no mesmo aparelho podem apresentar caminhos diferentes.

Layouts responsivos se adaptam ao tamanho da tela, à orientação, à densidade e aos recursos do dispositivo. O idioma altera textos e comprimentos. O estado da conta decide quais opções aparecem, enquanto login expirado, perfil de trabalho ou assinatura diferente podem inserir etapas. Caixas de permissão também surgem de acordo com o histórico de uso: um aparelho pode mostrar a solicitação inicial; outro pode já ter concedido ou recusado o acesso.

Por isso, uma skill precisa procurar significado e estado, e não coordenadas fixas. A documentação de serviços de acessibilidade do Android mostra como a plataforma representa elementos e eventos da interface para serviços autorizados. Essa árvore pode oferecer informações mais estáveis do que pixels, mas também varia conforme a qualidade da implementação do aplicativo. Alguns controles têm rótulos claros; outros exigem interpretação visual ou uma alternativa.

Antes de agir, o fluxo reutilizável deve reconhecer onde está. Depois de agir, precisa verificar se ocorreu a mudança esperada. Se a tarefa pede a criação de um compromisso, por exemplo, não basta tocar em “Salvar”: a skill deve observar uma confirmação, a presença do novo item ou outro resultado verificável. Caso a interface permaneça igual, o fluxo não deve fingir que terminou.

Uma estratégia robusta combina três recursos. O modelo interpreta o objetivo e adapta o plano ao estado observado. A camada de ação utiliza controles Android suportados e permissões concedidas. A verificação compara o resultado real com o esperado. Quando a correspondência não é suficiente, o usuário recebe o estado visível e pode corrigir, confirmar outra opção ou assumir a tarefa.

A automação por comando também depende dessa leitura contextual. Em Como automatizar tarefas no Android com um comando de voz, mostramos como um pedido pode iniciar várias etapas; uma skill aprendida por demonstração acrescentaria uma forma de definir o procedimento, mas ainda precisaria da mesma adaptação aos estados do aparelho.

Como gravar uma demonstração limpa e útil

O que deve aparecer na gravação para que ela ensine sem expor informações pessoais? O melhor exemplo usa um ambiente preparado, dados fictícios e uma tarefa curta. O objetivo é capturar decisões e resultados, não produzir um arquivo completo da vida digital do usuário.

No Android, a documentação do MediaProjection exige consentimento do usuário para cada sessão de projeção e apresenta expectativas para o tratamento seguro do conteúdo capturado. Esse consentimento protege o início da captura, mas a pessoa ainda precisa preparar o que ficará visível. Notificações, preenchimento automático, miniaturas recentes e mensagens sobrepostas podem revelar dados que não pertencem à demonstração.

Nunca inclua senhas, números completos de cartões, códigos de autenticação, chaves de recuperação, documentos pessoais, conversas privadas, dados de saúde ou informações financeiras reais. Também não é adequado narrar esses valores. Para tarefas que normalmente exigem credenciais, inicie a gravação depois do acesso feito ou utilize uma conta de teste. Se houver uma etapa de pagamento, demonstre apenas até um ponto seguro anterior à autorização financeira.

Uma gravação limpa pode seguir este protocolo:

• Prepare o aparelho: feche aplicativos alheios, silencie notificações e use uma conta de demonstração.
• Defina o início: abra a tela conhecida a partir da qual a skill deverá funcionar.
• Declare o objetivo: explique em uma frase qual resultado deve existir no final.
• Narre decisões: diga por que escolheu um item e em quais condições faria outra escolha.
• Mostre uma exceção segura: explique o que fazer se um campo estiver vazio ou a opção correta não aparecer.
• Marque confirmações: indique quais ações podem avançar e quais devem voltar ao usuário.
• Verifique o resultado: mostre a evidência visual de que a tarefa foi concluída.
• Encerre a captura: pare antes de abrir telas sem relação com a demonstração.

A orientação de privacidade e segurança do Android trata permissões e acesso a dados sensíveis como capacidades delimitadas da plataforma. A skill deve seguir o mesmo princípio: solicitar apenas os recursos associados à tarefa e conservar o mínimo necessário para sua definição, teste e uso.

Como testar, controlar e atualizar a skill

Uma skill funcionou uma vez. Isso basta para reutilizá-la? O exemplo inicial comprova apenas o caminho demonstrado. Antes do uso recorrente, é preciso variar entradas e estados, fazer execuções sem consequências, mapear permissões e confirmar que falhas levam a uma interrupção compreensível.

O primeiro conjunto de testes deve trocar os parâmetros: outro contato, outra data, uma lista mais longa ou um arquivo com nome diferente. Depois vêm as variações de estado: aplicativo fechado, conta desconectada, permissão recusada, rede indisponível e item ausente. Também vale testar outro tamanho de tela, idioma compatível e uma versão atualizada do aplicativo. A finalidade não é prever cada pixel, mas descobrir quais condições a skill reconhece e onde precisa pedir ajuda.

Uma execução simulada apresenta o plano e identifica alvos sem concluir ações importantes. Ela permite conferir se o agente escolheu o aplicativo, o destinatário e os dados corretos. A execução real pode então reservar pontos de confirmação para envio de mensagens, publicação, exclusão, alteração de conta, compra ou qualquer ação difícil de desfazer.

Permissões devem ser mapeadas por etapa. Capturar a tela, acessar a interface, abrir um aplicativo e enviar conteúdo são capacidades diferentes. O usuário precisa saber qual delas será usada e em que momento. Se uma permissão não estiver disponível, a skill deve oferecer um caminho alternativo, como abrir a tela correta e entregar o controle à pessoa.

Logs e versões completam a governança. O registro deve mostrar qual versão da skill foi executada, quais parâmetros recebeu, quais confirmações ocorreram e qual resultado foi observado. Quando o aplicativo muda, uma nova versão pode ser testada antes de substituir a anterior. Se o comportamento piorar, a reversão restaura uma versão conhecida enquanto o fluxo é corrigido.

Falha também precisa de resultado explícito. “Não concluído porque a conta está desconectada” é melhor do que avançar por uma tela imprevista. Para aprofundar identidade, histórico e atribuição das ações, veja Identidade, permissões e trilhas de auditoria para agentes de IA no telefone.

Como esse conceito se encaixa no FoneClaw

Qual é a nossa visão para fluxos reutilizáveis no telefone? Uma skill útil precisa unir raciocínio adaptável a uma atuação Android delimitada. O modelo configurado no FoneClaw fornece compreensão de linguagem, raciocínio e planejamento. O FoneClaw realiza ações Android suportadas, mostra os resultados e aplica permissões, confirmação e alternativas práticas ao longo do percurso.

Hoje, o escopo do FoneClaw concentra-se nessa combinação entre planejamento e ações compatíveis no aparelho. A criação automática de uma skill a partir de uma gravação de tela não integra a capacidade atual do produto. O conceito de aprendizado por demonstração, no entanto, oferece um modelo claro para pensar em futuros fluxos reutilizáveis: observar um exemplo limpo, extrair regras, definir parâmetros, testar variações e vincular cada ação às permissões corretas.

Mesmo nesse desenho, a gravação seria apenas uma fonte de especificação. O usuário precisaria revisar a skill gerada: nome, objetivo, entradas, aplicativos, permissões e situações de parada. Uma demonstração de “enviar o relatório semanal” deveria permitir alterar semana e destinatário dentro do escopo aprovado, mas manter confirmação antes do envio e interromper se o arquivo esperado não estiver presente.

O estado visível continua sendo essencial. Durante a execução, o usuário acompanha o que o agente encontrou, quais dados serão usados e qual resultado apareceu. Para uma ação consequente, a confirmação ocorre no momento em que ainda é possível revisar. Quando o aplicativo não oferece o caminho previsto, o FoneClaw pode apresentar o ponto alcançado e permitir que a pessoa escolha uma alternativa ou assuma a interação.

Essa separação evita dois extremos: uma macro rígida que quebra diante de qualquer mudança e uma instrução ampla demais para controlar ações específicas. O objetivo é uma tarefa compreensível, parametrizada e testável, conduzida por um modelo capaz de planejar, mas executada dentro das capacidades e permissões do Android.

Para avaliar uma possível skill demonstrada, use cinco perguntas: o objetivo está claro, os dados variáveis viraram parâmetros, as permissões correspondem às ações, os pontos de confirmação estão definidos e o resultado pode ser verificado? Quando as cinco respostas são positivas, a demonstração começa a se transformar em um fluxo realmente reutilizável.