O modelo Gemini 2.5 Computer Use, da Google, executa um ciclo de captura de ecrã para ação em agentes de browser

O ciclo: captura de ecrã à entrada, ação de UI à saída

O modelo é disponibilizado através de uma nova ferramenta `computer_use` na Gemini API, e a Google é explícita quanto ao facto de este se destinar a funcionar dentro de um ciclo, e não como uma chamada isolada. Cada turno fornece ao modelo três elementos: o pedido do utilizador, uma captura de ecrã do ambiente atual e um histórico das ações recentes.

O modelo responde com uma chamada de função que representa uma única ação de UI — clicar, escrever, percorrer. O código do lado do cliente executa essa ação, captura depois um novo screenshot e o URL atual, e envia-os de volta como resposta da função, reiniciando o ciclo. Isto repete-se até a tarefa terminar, ocorrer um erro, surgir uma resposta de segurança ou o utilizador interromper o processo.

Este desenho merece atenção por parte das equipas de frontend: o modelo não lê o DOM nem se liga aos elementos internos de uma aplicação. Funciona a partir de píxeis e de um URL, a mesma superfície que um humano vê. As implementações de referência refletem isso — a Google recomenda aos desenvolvedores que construam o ciclo do agente localmente com Playwright ou numa VM na cloud através do Browserbase.

Limitado ao browser, não ao desktop

A Google é precisa quanto ao âmbito de funcionamento do modelo. Este está principalmente otimizado para browsers web e mostra potencial no controlo de UI móvel, mas ainda não está explicitamente otimizado para controlo ao nível do sistema operativo de desktop.

As demonstrações mantêm-se dentro desse limite: extrair registos de animais de estimação de um formulário web e introduzi-los num CRM para agendar uma consulta, e arrastar notas adesivas para categorias numa aplicação web. Ambas são tarefas comuns de browser — preencher formulários, manipular menus pendentes e filtros, operar com sessões iniciadas — que a Google apresenta como a capacidade concreta que faltava quando os agentes só conseguiam comunicar com APIs estruturadas.

A segurança por passo é executada fora do modelo

A Google identifica três riscos específicos de agentes que controlam computadores: uso indevido intencional por parte dos utilizadores, comportamento inesperado do modelo, e injeções de prompt e esquemas fraudulentos no ambiente web. As funcionalidades de segurança são treinadas dentro do modelo, mas a parte mais interessante para os desenvolvedores é a verificação externa ao modelo.

Serviço de segurança por passo: um serviço de segurança externo ao modelo, em tempo de inferência, que avalia cada ação proposta pelo modelo antes de ser executada.Montana Labs

Além disso, os desenvolvedores podem usar instruções de sistema para fazer com que o agente recuse ou peça confirmação ao utilizador antes de ações de alto risco. O próprio modelo também pode sinalizar que é necessária confirmação por parte do utilizador final — por exemplo, antes de efetuar uma compra. A Google enumera ações concretas que considera de alto risco: comprometer a integridade do sistema, comprometer a segurança, contornar CAPTCHAs e controlar dispositivos médicos.

Os testes de UI são o primeiro caso de uso lançado pela Google

Entre as implementações iniciais, a Google destaca os testes de UI nas suas próprias equipas de produção, afirmando que estes podem tornar o desenvolvimento de software significativamente mais rápido. Versões do modelo já suportam o Project Mariner, o Firebase Testing Agent, e algumas capacidades agênticas do AI Mode na Search.

Este enquadramento é relevante. Um agente que controla um browser real a partir de screenshots é uma escolha natural para testes frontend de ponta a ponta — percorrer fluxos, submeter formulários, verificar o comportamento de elementos interativos — sem seletores escritos manualmente que se quebram quando a UI muda. O caminho de referência com Playwright alinha-se diretamente com a forma como muitas equipas já escrevem testes de browser.

O que um agente guiado por píxeis muda para o trabalho de frontend

Como o modelo opera sobre screenshots e URLs, e não sobre os elementos internos da aplicação, trata qualquer frontend web como uma superfície testável e automatizável tal como está. Não existe uma camada de integração a construir contra os seus componentes; o agente usa a interface da mesma forma que um utilizador a usaria.

A implicação prática é que a mesma UI renderizada passa a servir duas audiências — utilizadores humanos e um agente que a percorre visualmente. A ressalva da própria Google mantém-se válida: as salvaguardas reduzem o risco, mas não o eliminam, e a empresa insta os desenvolvedores a testarem exaustivamente os seus sistemas antes do lançamento. Para as equipas que estão a avaliar isto, o benefício a curto prazo está menos ligado a agentes autónomos para utilizadores finais e mais em transformar fluxos web existentes em execuções de teste rápidas e autónomas sobre a interface real.