Arquiteturas de Agentes de Navegador: Três Abordagens

Toda equipe que está construindo um agente de IA para o navegador está fazendo uma escolha arquitetônica — quer percebam isso ou não. Elas estão escolhendo como o LLM percebe a página. Essa escolha se desdobra em tudo mais: custo por ação, confiabilidade em aplicativos do mundo real, o que é banido por sistemas anti-bot, que tipos de tarefas são viáveis.

A escolha atualmente se divide em três abordagens. Elas são frequentemente discutidas como se fossem tecnologias concorrentes. Não são. Elas operam em diferentes camadas de abstração, com diferentes trade-offs, adequadas para diferentes trabalhos. Misturá-las é a fonte de muita decepção recente com "agentes de navegador que não funcionam".

Este post apresenta as três de forma clara: o que cada uma realmente vê, onde cada uma brilha, onde cada uma colapsa.

Abordagem 1: Percepção Baseada em Visão

O agente recebe uma captura de tela da área de visualização do navegador. Um LLM capaz de visão identifica elementos visualmente e responde com coordenadas. Um controlador move o mouse e clica, digita em campos focados, rola.

O uso de computador da Anthropic é a implementação mais proeminente dessa abordagem. O operador da OpenAI funciona de forma semelhante. Ambos são gerais — eles não sabem que estão operando um navegador especificamente; estão operando uma tela.

O que o LLM vê:

{
  "image": "<base64 screenshot, 1280x720>",
  "task": "Encontre o botão cancelar assinatura"
}

Onde funciona bem:

Em qualquer lugar. Cobertura universal literal — se um humano pode ver, o LLM pode tentar. Funciona sem qualquer instalação do lado do usuário; o agente executa o navegador. Robusto a interfaces personalizadas estranhas: aplicativos renderizados em canvas, aplicativos Electron, videogames, relíquias do Flash, interfaces pesadas em imagens. Não se importa com o framework ou a marcação. Pixels são pixels.

Onde falha:

• Custo. Tokens de visão são caros. Uma única captura de tela pode ser 1000+ tokens, e os agentes raramente resolvem tarefas em uma única captura de tela. Em nossos testes, tarefas de navegação em várias etapas facilmente chegam a dezenas de milhares de tokens de visão por sessão — uma ordem de magnitude maior do que alternativas de representação estruturada. Em escala, isso é uma verdadeira restrição econômica.
• Sensibilidade à resolução. Um botão a 1280×720 não é o mesmo botão a 1920×1080. A ação baseada em coordenadas requer renderização consistente, o que significa controlar todo o ambiente do navegador.
• Opacidade do estado. A visão vê a superfície renderizada, não o estado subjacente. Formulários com campos ocultos, conteúdo dinâmico, elementos apenas ARIA — o modelo infere tudo a partir de pixels.
• Sem contexto autenticado. O agente executa um navegador novo. Ele não tem suas sessões, senhas salvas ou cookies de dispositivo confiável. Cada tarefa começa do estado deslogado, o que é uma restrição significativa para qualquer coisa que envolva contas pessoais.
• Perfil de detecção. Um navegador controlado é detectável. A maioria dos sites de consumo usa impressão digital comportamental (Cloudflare, DataDome, PerimeterX) que sinaliza automação independentemente da perfeição visual. O agente parece humano visualmente, mas o navegador subjacente não se move como um humano.

Agentes baseados em visão são mais adequados para tarefas computacionais arbitrárias onde a abrangência importa mais do que a economia — onde o usuário pode dedicar computação e onde a autenticação não é necessária (ou é configurada manualmente no início da sessão).

Abordagem 2: Percepção da Árvore de Acessibilidade

O agente lê a árvore de acessibilidade do navegador — a mesma estrutura de dados que leitores de tela usam para usuários cegos. Funções ARIA, nomes acessíveis, elementos focáveis. O LLM recebe uma representação estruturada da interface do usuário, não uma captura de tela.

Este é o caminho que a maioria dos atuais projetos "MCP de navegador" convergiu. Uso de navegador, MultiOn e a onda de servidores MCP enviados até 2025, em sua maioria, lêem AXTree (a árvore de acessibilidade do Chrome, exposta via Protocolo DevTools).

O que o LLM vê:

[1] botão "Enviar"
[2] caixa de texto "Email", obrigatório
[3] link "Esqueceu a senha?", url="/reset"
[4] cabeçalho "Entrar"
[5] imagem "Logo"

Mais limpo do que uma captura de tela, muito mais barato em tokens, estruturado. O LLM raciocina sobre elementos por índice; o controlador despacha ações para esses índices.

Onde funciona bem:

• Barato. Uma página que custa 5.000 tokens de visão pode custar 500 tokens de árvore de acessibilidade. Diferença de ordem de magnitude.
• Ciclo de agente simples. "Clique no elemento [3]" é muito mais fácil de raciocinar do que "clique na coordenada (847, 432)".
• Excelente para sites acessíveis. Portais governamentais construídos para padrões de acessibilidade (sites federais dos EUA, serviços públicos da UE feitos corretamente), aplicativos modernos em React com ARIA adequada, sites de conteúdo — esses funcionam de forma limpa.
• Independente de resolução. Mesma árvore em qualquer viewport.

Onde falha:

• A árvore de acessibilidade não foi projetada para agentes de IA. Foi projetada na década de 1990 para leitores de tela operando em páginas da web muito mais simples. Aplicativos web modernos frequentemente têm uma conformidade A11Y terrível — elementos interativos sem funções, <div>s que deveriam ser botões, controles personalizados que não expõem estado. A árvore sub-representa a página de forma ruim em uma grande fração dos sites do mundo real.
• UI empresarial legada é invisível. ASP.NET WebForms com postbacks, painéis administrativos da era jQuery, interfaces bancárias, sistemas de CRM, portais governamentais não construídos para padrões modernos — esses frequentemente renderizam bem visualmente, mas têm uma árvore de acessibilidade quase vazia. O LLM não vê nada onde o usuário vê tudo.
• Vazamento de estado. Árvores de acessibilidade são instantâneas de metadados declarados, não do estado em tempo de execução. Um aplicativo de várias abas, um modal que acabou de abrir, um valor que foi digitado — a árvore pode ou não refletir isso dependendo do framework. Condições de corrida são comuns.
• Detecção. Agentes de árvore de acessibilidade normalmente rodam via Puppeteer, Playwright ou uma instância acionada pelo Chromium. Sistemas anti-bot detectam esse perfil de forma confiável. Principais sites de consumo (produtos do Google, plataformas sociais, e-commerce) estão bloqueando cada vez mais essas sessões.
• Autenticação. Mesmo problema que a visão: geralmente um navegador novo, sem sessão real.

Agentes de árvore de acessibilidade são mais adequados para sites modernos e compatíveis com A11Y onde o usuário não precisa ser autenticado como ele mesmo — o que é uma fatia menor de trabalho útil do que o marketing implica.

Abordagem 3: Percepção Estrutural em Tempo de Execução

O agente lê o DOM ao vivo diretamente — a estrutura renderizada real como existe no momento da percepção, incluindo estilos computados, manipuladores de eventos, estado de formulários e semântica inferida a partir da marcação em si, em vez de metadados de acessibilidade declarados.

Essa abordagem normalmente é executada como uma extensão do navegador na sessão autenticada normal do usuário. O DOM é capturado em processo, comprimido estruturalmente e enviado ao LLM como uma representação que é mais densa do que AXTree, mas muito mais barata do que visão.

O que o LLM vê: