Três gerações de automação de navegador: simulação de entrada, controle por protocolo e decisões do modelo

A automação de navegador existe há mais de vinte anos e já mudou de rota três vezes. O ponto interessante é que cada geração resolve uma classe diferente de problemas e, depois disso, o gargalo volta a surgir em outro lugar.

Primeira geração: fingir, no nível do sistema operacional, que alguém está movendo o mouse

As primeiras automações nem aconteciam dentro do navegador, mas no sistema operacional. O script movia o mouse e pressionava teclas, enquanto o navegador apenas recebia essas entradas de forma passiva.

A vantagem era a generalidade: qualquer coisa exibida na tela podia ser manipulada, seja uma página web, um aplicativo cliente ou um software de desktop antigo, sem que o navegador precisasse expor qualquer interface. O custo também era direto. O script reconhecia coordenadas da tela; bastava mudar a resolução, ajustar a escala do sistema ou mover a janela para que a mesma ação clicasse no lugar errado. Ele também não sabia se a página realmente havia terminado de carregar e precisava depender de esperas fixas. O paralelismo era ainda mais complicado: uma máquina tem apenas um mouse e um teclado, então dez ambientes exigiam dez máquinas.

O problema deixado por essa geração era simples: ela não conseguia ver a página.

Segunda geração: contornar a tela e falar diretamente com o navegador

O surgimento do WebDriver levou a automação do nível dos pixels ao nível dos elementos: em vez da posição do pixel 800 na tela, buscava-se um elemento específico da página. O mesmo código podia controlar navegadores diferentes e ser escrito em linguagens diferentes, o que também explica por que acabou se tornando um padrão na área de testes.

Mais tarde, soluções baseadas em protocolos de depuração do navegador aprofundaram esse caminho. A família de Puppeteer e Playwright se comunica diretamente com o mecanismo e consegue acessar o estado interno da página: esperar automaticamente que elementos fiquem prontos, interceptar e reescrever requisições, conectar-se a uma instância de navegador já aberta, executar sem interface e abrir vários contextos em paralelo. Grande parte das capacidades que hoje parecem normais foi completada nessa fase.

Isso resolveu controle e estabilidade, mas deixou outros dois problemas. Primeiro, os scripts ainda eram rigidamente definidos por pessoas. Quando a estrutura da página mudava ou um seletor deixava de funcionar, era preciso voltar ao código, e o custo de manutenção crescia com o tamanho do projeto. O segundo problema era mais fundamental: essa abordagem cuida de como operar, não de como o ator parece. A conexão direta por protocolo torna o controle mais preciso, mas mudar a forma de comunicação não faz desaparecer os rastros da automação. Mesmo um script muito estável pode continuar parecendo um script para quem observa.

Terceira geração: os passos deixam de ser escritos um a um, e o problema muda de lugar novamente

A mudança da terceira geração não está na forma de controle, mas na forma de decisão. Nas duas primeiras, as pessoas precisavam descrever cada passo: qual botão clicar, qual campo preencher e em que ordem. Na geração orientada por modelos, você fornece o objetivo, o modelo planeja o caminho e pode encontrar uma nova entrada quando a página é redesenhada.

Com isso, antigos detalhes trabalhosos, como escrever seletores ou definir o tempo de espera, passam a ser menos decisivos. Mas novos problemas aparecem imediatamente.

O ponto central é que o próprio modelo não acessa a página web. Quem continua abrindo a página, carregando recursos e mantendo o estado de login é o navegador. Por isso, quando uma tarefa começa a ficar instável, a causa muitas vezes não é uma decisão errada do modelo, mas o ambiente de execução embaixo dele: várias tarefas compartilham o mesmo navegador e contaminam cookies e cache entre si; as características de fingerprint são muito parecidas, fazendo a plataforma enxergar essas tarefas como vindas da mesma máquina; contas são reutilizadas entre tarefas e uma anomalia acaba afetando várias; ambientes precisam ser criados temporariamente e recuperados após o uso, mas não existe uma programação unificada. O modelo resolve como fazer e transforma onde fazer no novo gargalo.

A camada extra que aparece na arquitetura

Ao colocar as três gerações lado a lado, a diferença não é qual delas é mais avançada, mas o fato de cada uma precisar assumir o que a anterior não resolveu. Nas duas primeiras, o ambiente não era um problema porque a automação operava o navegador da própria máquina. Na fase dos Agents, as tarefas são em lote, concorrentes e sem supervisão, então o ambiente precisa ser gerenciado explicitamente: cada tarefa roda em um ambiente independente, sem misturar fingerprints e sessões; o estado de login é mantido entre tarefas, evitando novos logins a cada vez; IP, fuso horário e idioma são combinados de forma coerente; e ambientes são criados e recuperados sob demanda como recursos computacionais.

É nessa camada que a PurpleMark atua, transformando ambientes de navegador em recursos programáveis para que o Agent possa se concentrar na lógica da tarefa.

A escolha também fica mais fácil de enquadrar. Pilhas de testes corporativas e scripts existentes podem continuar na rota atual; aplicações web complexas que precisam de controle no nível das requisições se encaixam na geração orientada por protocolo; para tarefas planejadas por modelos que também precisam rodar com estabilidade no longo prazo, as tecnologias das duas primeiras gerações continuam úteis, mas a camada de ambiente precisa ser resolvida separadamente. Se o cenário exige que a operação pareça feita por um usuário real, isso não é algo que um framework de automação consiga oferecer sozinho, independentemente da geração.

Além da rota técnica existe outro limite: as operações automatizadas precisam seguir as regras da plataforma de destino e as leis locais. O fato de algo funcionar tecnicamente não significa que seja adequado para o negócio.