Agentes de IA que navegam na web: arquitetura, gargalos e prática de implementação

Introdução: por que os agentes web se tornaram o grande tema de 2026

Há três anos, a expressão «agente de IA» soava como jargão de marketing. Hoje é uma ferramenta de trabalho que abre o navegador, lê a página, clica em botões, preenche formulários e devolve o resultado. Ele verifica os preços dos concorrentes em um marketplace, compara os resultados de busca em dez regiões, testa uma landing page antes do lançamento de uma campanha de anúncios e coleta dados onde não existe — e nunca vai existir — uma API pública.

Por que justamente agora? Três fatores convergiram. Os modelos aprenderam a devolver comandos estruturados de forma confiável, em vez de texto livre. Surgiram runtimes de navegador projetados para serem controlados por máquinas, não por pessoas. E, por fim, o mercado amadureceu: a rotina no navegador custa dinheiro, e as equipes se cansaram de escrever scripts frágeis que quebram a cada mudança de layout.

Mas o que surpreende logo na primeira implementação séria é isto: o agente que passa brilhantemente numa demonstração, em produção, conclui a tarefa com sucesso em apenas metade dos casos. Ele se perde em páginas dinâmicas, gasta vários minutos e dezenas de milhares de tokens em um roteiro de dez passos, tropeça nas proteções contra automação e, às vezes, faz algo completamente diferente do que você pediu. É sobre esses gargalos e sobre como projetá-los antecipadamente que trata este artigo.

Mantemos deliberadamente uma fronteira: falamos de agentes como classe de sistemas. Não vamos explicar como funcionam os protocolos de conexão de ferramentas ou a busca em bases vetoriais de conhecimento, pois há materiais específicos no blog sobre isso. Aqui nos interessa outra coisa: como um agente de IA percebe a web, toma decisões, age e por que, em cada uma dessas etapas, surgem perdas.

O que você vai levar depois da leitura:

• Compreensão da arquitetura de sete camadas de um agente web e de onde nela estão os pontos «finos».
• Quatro métodos práticos: design da percepção da página, gestão do planejamento, construção da camada de rede com proxies móveis, observabilidade e economia.
• Checklists, frameworks de avaliação e análise de cenários reais com números.
• Respostas às perguntas que geralmente surgem na segunda semana após o lançamento do piloto.

O material é voltado a profissionais de marketing, de arbitragem de tráfego, desenvolvedores e donos de negócio, ou seja, a quem já trabalha com automação e proxies móveis e quer entender para onde esse ferramental caminha. Haverá detalhes técnicos, mas vamos explicar cada um deles com analogias acessíveis.

Fundamentos: o que é um agente web e como ele difere de um script

Definição sem mágica

Agente de IA, no contexto da web, é um sistema de software que recebe um objetivo em linguagem natural, decompõe esse objetivo em passos por conta própria, observa o estado do navegador, escolhe a próxima ação e repete o ciclo até que o objetivo seja atingido ou até esgotar o limite de tentativas. A palavra-chave é ciclo. Um chatbot responde uma vez e fica em silêncio. Um script de scraping executa uma sequência predefinida e falha se a realidade se afastar do plano. O agente, por sua vez, vive em um loop de «observação, raciocínio, ação», e é esse loop que lhe confere flexibilidade e gera a maior parte dos problemas.

Uma boa analogia é a de um estagiário no escritório. O script é uma instrução no papel: «abra o site, clique no terceiro botão de cima, copie o número». Basta o designer mover o botão para que a instrução se torne inútil. Já o estagiário entende a tarefa «descubra o preço do produto» e encontra o preço mesmo que o botão tenha se deslocado. Mas o estagiário é mais lento, mais caro, às vezes erra e precisa ser supervisionado. Tudo isso se aplica exatamente da mesma forma a um agente de IA.

Três famílias de agentes web

• Agentes orientados a API. Para eles, a web é um conjunto de endpoints. Não abrem o navegador, chamam os serviços diretamente. Rápidos, baratos, mas funcionam só onde a API existe e cujos termos permitem esse uso.
• Agentes de DOM. Controlam um navegador real por meio de ferramentas de automação, leem a estrutura da página (árvore de elementos, árvore de acessibilidade) e clicam por seletores. É o cavalo de batalha da maioria das tarefas de negócio.
• Agentes visuais (computer use). Olham para o screenshot, como uma pessoa, e agem por coordenadas do mouse. São universais, funcionam até com canvas e widgets fora do padrão, mas são os mais caros e lentos.

Na prática, sistemas maduros são híbridos: o agente lê a árvore de elementos e recorre ao screenshot só quando a representação textual não é suficiente.

Níveis de autonomia

Vale pensar em uma escada parecida com os níveis de piloto automático nos carros:

1. Assistido. A pessoa conduz, o agente sugere o próximo passo.
2. Semiautônomo. O agente executa uma cadeia, mas para diante de ações irreversíveis: pagamento, envio de formulário, exclusão.
3. Autônomo dentro do cenário. O agente trabalha sem intervenção dentro de limites definidos e de uma lista de domínios permitidos.
4. Autônomo com delegação. O agente cria subtarefas e subagentes por conta própria. Nível em que hoje vivem, principalmente, sistemas de pesquisa e equipes muito maduras.

Dica prática para começar: a maioria das tarefas de negócio em marketing e análise se resolve confortavelmente no segundo e no terceiro nível. Não é preciso buscar o quarto nível por estética — cada nível acima dobra a complexidade do controle.

Por que a web é um ambiente ruim para agentes

A web foi criada para pessoas. As páginas são redundantes: um único card de produto em um marketplace pode pesar centenas de kilobytes de marcação, com dados úteis em poucas linhas. As interfaces são dinâmicas: o conteúdo carrega depois da rolagem, janelas modais cobrem botões, o estado muda sem recarregar a página. E a web também é hostil à automação: os sites se protegem contra carga excessiva e abuso, estabelecem limites e verificam se o cliente se parece com um usuário comum. Cada um desses fatores vira um gargalo, e vamos analisá-los por camadas a seguir.

Mergulho profundo: as sete camadas da arquitetura e onde estão seus gargalos

Vamos decompor um agente de IA de navegador típico em camadas. Não é o único esquema possível, mas é conveniente porque cada camada corresponde a uma classe de problemas e a um conjunto de soluções.

Camada 1. Definição da tarefa e contrato do resultado

Aqui, o objetivo humano se transforma em especificação: o que conta como sucesso, em que formato devolver os dados, quais domínios são permitidos, quais ações são proibidas. O gargalo é a formulação vaga. «Colete os preços dos concorrentes» não é uma tarefa. «Para 40 SKUs de uma planilha, obter o preço atual e a disponibilidade em duas plataformas indicadas, retornar um JSON com os campos e o timestamp e, na ausência do produto, retornar um status explícito» é uma tarefa.

Camada 2. Planejador e orquestrador

O planejador divide o objetivo em subobjetivos, acompanha o estado da execução, decide quando repetir um passo, quando voltar atrás e quando chamar uma pessoa. Aqui há dois polos arquitetônicos. O agente reativo pergunta ao modelo, a cada passo, «o que fazer agora», olhando para o estado atual. É flexível, mas caro e propenso a entrar em loop. O agente de planejar-e-executar primeiro monta um plano e depois o executa de forma determinística, recorrendo ao modelo só em caso de desvios. É mais barato e previsível, mas o plano pode ficar obsoleto no terceiro passo. Sistemas maduros combinam os dois: o plano como esqueleto, com inserções reativas em caso de falha.

Camada 3. Modelo

O modelo de linguagem ou multimodal é o cérebro do sistema. Os gargalos são óbvios: janela de contexto, custo dos tokens, latência da resposta, alucinações. Menos óbvio é o seguinte: passos diferentes exigem modelos diferentes. Extrair um número de um texto limpo é tarefa para um modelo pequeno e rápido. Entender por que o formulário não é enviado é tarefa para o modelo de ponta. Roteamento de requisições entre modelos conforme a complexidade do passo gera economia de várias vezes, e voltaremos a isso.

Camada 4. Percepção

Essa camada responde à pergunta «o que o agente vê». As opções: HTML bruto, HTML limpo, árvore de acessibilidade, screenshot, híbrido. É aqui que se queima a maior parte dos tokens. Uma página de loja virtual em estado bruto tem de 100 a 300 mil tokens, o que ou não cabe no contexto, ou custa como um almoço nada barato. A compressão de qualidade da percepção é a principal alavanca de otimização, e há uma seção específica sobre isso mais adiante.

Camada 5. Ações e ferramentas

O conjunto de primitivas: navegar até um endereço, clicar, digitar texto, rolar, aguardar um elemento, extrair dados, retornar o resultado. Quanto menor e mais limpo o conjunto, menos o modelo erra na escolha. O gargalo é a «generosidade» dos desenvolvedores: eles dão quarenta ferramentas ao agente, e ele começa a se confundir. O segundo gargalo é a semântica da espera. Clicar é fácil; entender que a página realmente atualizou, e não está mostrando o conteúdo antigo com um indicador de carregamento girando, é mais difícil.

Camada 6. Runtime do navegador

Onde vive o próprio navegador: máquina local, contêiner, serviço em nuvem de navegadores remotos. Aqui se resolvem questões de isolamento de sessões, persistência de cookies e armazenamento local entre passos, paralelismo, consumo de memória. Uma instância de navegador com abas abertas consome facilmente um gigabyte de memória; cem agentes em paralelo exigem planejamento sério de infraestrutura.

Camada 7. Camada de rede e identidade da sessão

De qual endereço o agente sai para a rede, de qual região, com que frequência e com quais cabeçalhos. Para profissionais de marketing e de arbitragem, essa é a camada mais importante na prática: resultados regionais, preços locais, exibição de anúncios, versões regionais dos sites — tudo depende do ponto de saída. É aqui também que vivem os limites de requisições e os sistemas de proteção contra automação. É nesse nível que os proxies móveis se tornam um componente de infraestrutura, e não uma opção, e haverá uma seção prática específica sobre isso.

Componentes transversais: memória e observabilidade

Sobre as camadas repousam dois serviços transversais. A memória armazena o contexto da tarefa, os resultados intermediários, o histórico de ações e as particularidades aprendidas dos sites («neste domínio, os filtros só se aplicam depois de pressionar o botão»). A observabilidade são os logs, os rastros de cada passo, os screenshots nos momentos de decisão, as métricas de custo e tempo. Sem observabilidade, o agente é uma caixa-preta, e a depuração vira adivinhação.

Mapa dos gargalos

Vamos consolidar onde exatamente se perdem dinheiro, tempo e confiabilidade:

• Tokens e contexto — percepção excessiva das páginas, histórico de passos inflado.
• Latência — cada passo é rede mais modelo mais renderização; dez passos viram facilmente dois minutos.
• Não determinismo — o mesmo cenário se comporta de forma diferente a cada execução.
• Fragilidade — mudança de layout, janelas pop-up, diferenças regionais de interface.
• Proteção contra automação e limites — os sites restringem a frequência e verificam o cliente.
• Segurança — a página pode conter instruções que o modelo confunde com comandos (injeção via conteúdo).
• Custo — a soma de tudo o que foi listado acima, multiplicada pela quantidade de tarefas.

Cada uma das próximas quatro seções práticas cobre uma ou mais linhas dessa lista.

Método 1. Design da percepção: o que exatamente o agente deve ver

Comecemos pela camada mais cara. Imagine que você pede a um colega para descobrir o preço em um site e, em vez do link, envia a ele uma impressão do código-fonte da página em 200 folhas. É mais ou menos assim que o modelo se sente ao receber HTML bruto. O objetivo do método é transformar a página em uma representação compacta, mas suficiente.

Três formatos e seu custo

• HTML limpo. Removemos scripts, estilos, elementos invisíveis, atributos de serviço. Compressão de 5 a 10 vezes. Mantém a estrutura, mas continua verboso.
• Árvore de acessibilidade. O navegador constrói por conta própria uma árvore semântica para leitores de tela: papel do elemento (botão, link, campo), nome, estado. Compressão de 20 a 50 vezes em relação ao HTML. É nesse formato que os frameworks modernos costumam mostrar a página ao agente. A cada elemento interativo se atribui um identificador numérico curto, e o modelo diz «clique no 17», em vez de «clique no botão com a classe btn-primary dentro do terceiro div».
• Screenshot. Um quadro custa aproximadamente o mesmo que mil a dois mil tokens de texto, mas carrega contexto visual: posição, cor, o que está coberto por uma janela modal. É indispensável para interfaces em canvas e widgets temperamentais.

Regra prática: o modo principal é a árvore de acessibilidade com identificadores, e o screenshot entra por gatilho (a ação não produziu o resultado esperado duas vezes seguidas, ou o elemento não foi encontrado).

Configuração passo a passo da camada de percepção

1. Defina as entidades-alvo. Para cada tipo de tarefa, liste os campos que o agente realmente precisa: preço, disponibilidade, título, data. Todo o resto é ruído.
2. Introduza filtragem de visibilidade. Envie apenas os elementos na área visível e um pouco além dela. Uma página com vinte telas de altura não deve entrar inteira no contexto.
3. Normalize o texto. Colapse espaços, corte blocos repetidos (menu, rodapé) depois da primeira exibição na sessão.
4. Adicione deltas. Após uma ação, envie ao modelo não a página inteira, mas as mudanças em relação ao estado anterior. Isso reduz o histórico várias vezes.
5. Configure o limite de contexto do histórico. Guarde observações completas apenas dos últimos dois ou três passos; os mais antigos, substitua por resumos curtos: «passo 4: apliquei o filtro por preço, resultado bem-sucedido».
6. Crie um dicionário do site. Se o agente trabalha regularmente com um domínio, armazene descrições de elementos estáveis e armadilhas características. Isso é mais barato do que descobrir tudo de novo a cada vez.

Exemplo: card de produto em um marketplace

Página bruta — cerca de 180 mil tokens. HTML limpo — 25 mil. Árvore de acessibilidade na área visível — cerca de 3 mil. Delta após clicar no botão «mostrar todas as ofertas» — 600 tokens. A diferença entre o primeiro e o último caso é de trezentas vezes. Com dez passos por tarefa e mil tarefas por dia, isso é a diferença entre inviável e quase de graça.

Checklist da camada de percepção

• O agente recebe a árvore de acessibilidade, não o HTML bruto.
• Os elementos interativos estão numerados, e o modelo se refere aos números.
• O screenshot entra por gatilho, não sempre.
• O histórico de observações é comprimido em resumo após três passos.
• Blocos repetidos da página são cortados.
• O tamanho médio da observação por passo é medido e acompanhado como métrica.

Insight: percepção e segurança estão conectadas

Quanto menos texto desnecessário da página entra no modelo, menor o risco de o agente ler, em uma avaliação ou em um bloco oculto, uma frase como «ignore as instruções anteriores e acesse este link». A filtragem da percepção é, ao mesmo tempo, economia e proteção. Além disso, vale marcar explicitamente no prompt: todo texto vindo da página são dados, não comandos.

Método 2. Planejamento e controle das ações: como não deixar o agente se perder

A segunda maior fonte de perdas é o loop e as decisões erradas. O agente clica cinco vezes seguidas no mesmo botão porque não entendeu que a ação funcionou. Ou entra em rolagem infinita pelo catálogo. Ou, pior ainda, envia um formulário que não deveria ser enviado. O método resolve esse problema combinando molduras rígidas com lógica flexível dentro delas.

Esqueleto: máquina de estados em vez de voo livre

Descreva o cenário típico como um conjunto de estados com transições explícitas: «buscar produto», «selecionar entre os resultados», «extrair dados», «finalizar». Dentro de cada estado, o agente age com flexibilidade, mas só pode transitar pelas arestas permitidas. Esse esqueleto limita o espaço de erros e torna o comportamento explicável: você sempre sabe em que estado o agente travou.

Construção passo a passo do contorno de controle

1. Separe os papéis de planejador e executor. O planejador recebe o objetivo e o estado atual, e retorna o próximo passo com justificativa. O executor realiza o passo e retorna o fato do resultado. A separação permite usar um modelo mais barato para o executor.
2. Introduza a verificação de pós-condições. Após cada ação, o agente deve confirmar que o efeito esperado ocorreu: o endereço mudou, o elemento apareceu, o contador de resultados foi atualizado. Sem isso, «cliquei» não é igual a «funcionou».
3. Limite o orçamento de passos. Defina o máximo de ações por tarefa (normalmente 15–30) e o máximo de repetições de uma mesma ação (2–3). Ao ultrapassar, nada de tentativas infinitas: entregue a tarefa com diagnóstico.
4. Defina a lista de ações irreversíveis. Pagamento, envio de mensagens, alteração de configurações da conta, exclusão. Antes delas, pausa obrigatória e confirmação humana, ou proibição total no cenário em questão.
5. Crie uma lista branca de domínios. O agente não deve sair dos sites permitidos, mesmo que haja um link tentador na página.
6. Adicione um mecanismo de reflexão em caso de falha. Se duas ações seguidas não deram resultado, o agente entra em modo de diagnóstico: tira um screenshot, descreve o que vê e replaneja. Isso é mais caro do que um passo comum, mas mais barato do que dez cliques sem sentido.
7. Pense em pontos de retomada. Cenários longos devem poder continuar após uma falha do navegador ou da rede, a partir do estado salvo, e não do zero.

Exemplo: comparação de resultados de busca em várias regiões

Tarefa do profissional de marketing: verificar como aparece o topo dos resultados para dez consultas em cinco regiões. O agente ingênuo abre o buscador e verifica tudo em sequência — cinquenta ciclos, cada um com erros. A abordagem com esqueleto: estado «definir contexto regional» (por meio do proxy correspondente e das configurações), estado «executar a consulta», estado «extrair posições», estado «validar» (dez posições, cada uma com endereço e título). Em caso de resultado inválido, uma repetição e depois a marcação «requer verificação manual». O planejamento se resume a percorrer a matriz, e o modelo entra apenas na extração e na validação. O custo cai uma ordem de grandeza, e a previsibilidade aumenta.

Framework de avaliação da prontidão do contorno de controle

• Existe uma lista explícita de estados e transições?
• O resultado de cada ação é verificado?
• O orçamento de passos e repetições está definido?
• As ações irreversíveis estão listadas e protegidas?
• Existe uma lista branca de domínios?
• O que o agente faz quando não entende o que está acontecendo?
• É possível retomar a tarefa do meio?

Se ao menos duas respostas forem «não», o agente ainda não está pronto para trabalhar sem supervisão.

Insight: o melhor agente é o que pensa pouco

Parece paradoxal, mas a maturidade do sistema se mede por quanto pouco ele recorre ao modelo. Tudo o que puder ser feito de forma determinística — transições, esperas, validação por esquema — deve ser feito por código. O modelo é necessário onde a realidade é imprevisível: interpretação de uma página fora do padrão, escolha entre elementos parecidos, recuperação após falha. Esse agente de IA é mais barato, mais rápido e, mais importante, mais explicável.

Método 3. Camada de rede e identidade da sessão: o papel dos proxies móveis

Agora, sobre a camada que os desenvolvedores mais subestimam e os profissionais de marketing mais superestimam. O desenvolvedor pensa: «conectei o proxy, pronto». O profissional de marketing pensa: «o proxy vai resolver todos os problemas». A verdade está no meio: a camada de rede define o que o agente vai ver e por quanto tempo conseguirá trabalhar, mas exige o mesmo rigor de engenharia que as demais.

Por que um agente precisa de uma camada de rede gerenciada

• Contexto regional. Preços, sortimento, idioma da interface, resultados de buscadores, anúncios exibidos — tudo depende do ponto de saída. Um agente que verifica criativos de arbitragem ou preços locais precisa sair da região correta, senão os dados são inúteis.
• Distribuição de carga. Cem agentes paralelos saindo de um único endereço parecem uma anomalia e criam carga anormal no site. A distribuição por um pool de endereços é, ao mesmo tempo, um comportamento correto em relação ao recurso e a estabilidade do seu trabalho.
• Isolamento de sessões. Tarefas diferentes e contas diferentes, com as quais você trabalha legalmente, não devem se cruzar no contexto de rede.
• Resiliência. Falhas de rede e degradação de um canal não devem parar toda a esteira.

Por que justamente proxies móveis

Proxies móveis direcionam o tráfego por redes de operadoras celulares. Eles têm uma propriedade que os torna a escolha natural para agentes: os endereços das operadoras são usados simultaneamente por um número enorme de assinantes reais e mudam constantemente na reconexão. Para o site, esse tráfego é indistinguível do tráfego de usuários comuns de internet móvel naquela região, e é exatamente isso que se precisa quando o objetivo do agente é ver o site pelos olhos de um visitante comum. Endereços de data center, ao contrário, raramente são associados a pessoas reais, e os sistemas de proteção os tratam com mais rigor, aplicando limites de frequência de requisições mais rígidos.

Há também uma segunda vantagem, específica do público móvel: uma parcela enorme das compras e dos cliques em anúncios é feita por smartphones. Um agente que verifica a versão mobile de uma landing page, os resultados de busca no celular ou o aplicativo móvel de um marketplace pela interface web precisa também parecer, na rede, um cliente móvel. Proxy móvel mais perfil de navegador móvel dão uma imagem coerente.

O princípio da coerência de identidade

O principal erro da camada de rede é a incoerência. O agente sai de uma região pela rede, mas o fuso horário do navegador corresponde a outra, o idioma da interface a uma terceira, e a resolução de tela é de um monitor desktop com um endereço móvel. Essas contradições os sites notam e respondem com atenção redobrada: mostram verificações com mais frequência, restringem funcionalidades, entregam uma versão reduzida. A tarefa do arquiteto é construir um perfil de sessão em que todos os parâmetros sejam coerentes: região do endereço, fuso horário, idioma, tipo de dispositivo, tamanho de tela. E esse perfil deve ser estável ao longo de uma tarefa.

Configuração passo a passo da camada de rede

1. Defina a matriz de regiões. Para quais países e cidades você precisa de dados. Para cada ponto, um canal separado de proxy móvel.
2. Vincule o canal ao perfil do navegador. Um contexto de navegador, um canal, uma tarefa. Não misture.
3. Configure a política de rotação de endereço. Há dois modos: manter o endereço durante a tarefa (necessário para sessões com autenticação e cenários de vários passos) e trocar o endereço entre tarefas (necessário para coleta de dados públicos com distribuição de carga). Um bom serviço de proxies móveis oferece controle de rotação via API e por agendamento.
4. Defina limites de frequência. O agente deve respeitar o site: pausas entre requisições compatíveis com o comportamento humano, limite de sessões paralelas por domínio. Isso não é só ética, é praticidade — os sites que você sobrecarrega começam a retornar erros justamente para você.
5. Respeite as regras dos recursos. Verifique o arquivo robots e os termos de uso dos sites com que trabalha. Informação pública para monitoramento de preços e resultados é uma coisa; ações dentro de contas são outra, e devem ser executadas apenas dentro dos seus direitos sobre essas contas.
6. Construa uma verificação de saúde do canal. Antes da tarefa, o agente faz uma requisição de controle: o endereço responde, a região está correta, a latência é aceitável. Um canal não saudável é excluído do pool automaticamente.
7. Registre em log o contexto de rede de cada tarefa. Qual canal, qual endereço, qual região, quais respostas do servidor. Sem isso, você não distingue um erro do modelo de um erro de rede.

Exemplo de configuração de perfil de sessão

{ "task_id": "price-monitor-ru-msk-042", "proxy_channel": "mobile-ru-msk-03", "rotation": "hold_until_task_end", "browser_profile": { "device": "mobile", "locale": "ru-RU", "timezone": "Europe/Moscow", "viewport": "390x844" }, "rate_limit": { "min_delay_ms": 1800, "max_parallel_per_domain": 2 } }

Observe: região do canal, locale, fuso horário e tipo de dispositivo estão coerentes. É exatamente essa a identidade sem contradições.

Gargalo: o custo do tráfego

O tráfego móvel é mais caro que o de data center, e o navegador carrega imagens, fontes, scripts de analytics. O agente não precisa da maior parte disso. Bloqueie o carregamento de mídia e de rastreadores de terceiros no nível do navegador, se isso não afetar a funcionalidade da página. Uma economia de tráfego de 60 a 80 por cento é um resultado típico. A exceção são os agentes visuais, que precisam da imagem completa; para eles, escolha quais tarefas realmente exigem screenshots.

Checklist da camada de rede

• Cada tarefa sai por um canal de proxy móvel da região necessária.
• Os parâmetros do navegador são coerentes com a região e o tipo de dispositivo do canal.
• A política de rotação foi escolhida conscientemente para o tipo de tarefa.
• Há limites de frequência e de paralelismo por domínio.
• As regras de uso dos recursos-alvo foram consideradas.
• O canal é verificado antes da tarefa e excluído em caso de degradação.
• O tráfego de mídia desnecessário está desativado.
• O contexto de rede é registrado no log de cada tarefa.

Método 4. Observabilidade e economia: como medir e baratear

Um agente sem métricas é como uma campanha de anúncios sem analytics: o dinheiro sai, mas para onde, não se sabe. Este método trata do que medir, como depurar e onde buscar economia.

Cinco métricas-chave de um agente web

• Taxa de tarefas bem-sucedidas. E «sucesso» deve ser verificado automaticamente pelo esquema do resultado, não pelo auto-relato do agente. Agentes tendem a declarar sucesso de forma otimista.
• Número de passos por tarefa. Se cresce, o agente começou a vagar; compare com a trajetória de referência.
• Custo da tarefa. Tokens do modelo mais tráfego mais tempo de runtime. Calcule em dinheiro, não em tokens — assim fica mais claro para o negócio.
• Tempo da tarefa. Mediana e percentil 95. A cauda da distribuição geralmente indica loops.
• Causas de insucesso por categoria. Rede, proteção do site, erro do modelo, mudança de layout, timeout. Sem categorização, você não sabe qual camada tratar.

O rastro da tarefa como unidade de depuração

Cada tarefa deve deixar um rastro: a sequência de passos, e para cada um — a observação (de forma comprimida), a decisão do modelo com justificativa, a ação, o resultado da verificação de pós-condição, o screenshot no momento da decisão. Esse rastro permite entender em um minuto onde exatamente tudo deu errado. Armazenar rastros de todas as tarefas é caro; guarde integralmente os das malsucedidas e seletivamente os das bem-sucedidas.

Construção passo a passo de um agente econômico

1. Meça o custo-base. Rode cem tarefas típicas e calcule o custo médio e a distribuição. Sem base, não há otimização.
2. Encontre a camada mais cara. Normalmente é a percepção (60 a 80 por cento dos tokens). Aplique o método 1.
3. Introduza roteamento de modelos. Extração de dados por esquema, verificação de pós-condições, escolhas simples — modelo barato. Planejamento, recuperação após falha — modelo caro. A distribuição típica em um sistema maduro: 70 a 85 por cento das chamadas vão para o modelo barato.
4. Faça cache do que é estável. Instruções de sistema, descrição de ferramentas, dicionários de sites — tudo isso pode ser cacheado do lado do provedor do modelo, economizando no reprocessamento.
5. Substitua o modelo por código onde a trajetória se estabilizou. Se o agente passou cem vezes pelo mesmo site pelo mesmo caminho, fixe esse caminho como cenário determinístico com verificações e deixe o modelo apenas para tratar desvios. Isso se chama compilação de trajetória, e é a fonte mais poderosa de economia em cenários maduros.
6. Introduza orçamentos. Limite de custo por tarefa e por dia com parada automática. Agentes que entraram em loop são capazes de queimar o orçamento semanal em uma hora.

Referências numéricas

Segundo nossas observações em tarefas típicas de monitoramento e verificação, um agente ingênuo com modelo de ponta e HTML bruto gasta, em uma tarefa de dez passos, uma quantia equivalente ao preço de vários cafés, e leva dois a três minutos. Depois de aplicar os quatro métodos, a mesma tarefa custa de 20 a 50 vezes menos e é executada em 20 a 40 segundos, enquanto a taxa de sucesso sobe de 50–60 para 85–95 por cento. A variação é grande porque depende dos sites, mas a ordem de grandeza se mantém. Benchmarks públicos de agentes web autônomos mostram um quadro parecido: os melhores sistemas resolvem cerca de dois terços das tarefas, os medianos, metade, e a diferença é determinada menos pelo modelo e mais pela engenharia em volta dele.

Checklist de observabilidade

• O sucesso da tarefa é verificado automaticamente pelo esquema.
• As cinco métricas são coletadas e visíveis em um painel.
• Os insucessos estão categorizados por camada.
• Os rastros das tarefas malsucedidas são armazenados integralmente.
• Há orçamentos por tarefa e por dia.
• Há um conjunto de regressão de tarefas que é executado a cada mudança de prompts, modelos ou ferramentas.

Erros comuns na construção de agentes web

Vamos reunir as pedras em que quase toda equipe tropeça. Algumas já mencionamos, mas repeti-las aqui se justifica: são esses erros que consomem meses.

Erro 1. Começar pela autonomia total

A equipe constrói logo um agente de quarto nível, que cria subtarefas por conta própria. O resultado é comportamento imprevisível e impossibilidade de depuração. Comece com o modo semiautônomo, com uma pessoa no circuito, colete rastros, estabilize e só então aumente a autonomia.

Erro 2. Confiar no auto-relato do agente

O agente retorna «tarefa concluída com sucesso», mas os dados do resultado estão vazios ou desatualizados. A verificação de sucesso deve ser externa e formal: esquema do resultado, faixas de valores, campos obrigatórios.

Erro 3. Alimentar o modelo com a página bruta

O erro mais caro, literalmente. Ele também reduz a qualidade: no meio do ruído, o modelo encontra o que precisa com mais dificuldade.

Erro 4. Um único endereço para todas as tarefas

Cem sessões paralelas a partir de um único endereço de data center são garantia de restrições por parte dos sites e de dados distorcidos. A camada de rede precisa ser projetada, não conectada de última hora.

Erro 5. Identidade de sessão incoerente

Endereço móvel da região A, navegador desktop com fuso horário da região B e idioma da região C. Essas sessões recebem uma experiência reduzida e verificações frequentes.

Erro 6. Ferramentas em excesso

Quarenta ações disponíveis em vez de oito. O modelo pensa mais, erra mais na escolha e o prompt incha. O conjunto mínimo de primitivas mais algumas ações compostas para um cenário específico é o ótimo.

Erro 7. Ausência de orçamentos

Um agente que entrou em loop à noite queima, até a manhã, o limite mensal de modelo e tráfego. Orçamentos rígidos não são uma opção.

Erro 8. Ignorar as regras dos recursos

O trabalho com os sites deve permanecer dentro de seus termos de uso e da legislação. O agente é o seu representante na rede, e o comportamento dele é sua responsabilidade. Dados públicos para análise, ações em contas próprias, respeito aos limites — sim. Todo o resto — não.

Erro 9. Não distinguir os tipos de insucesso

«Não deu certo» não é diagnóstico. Um erro de rede se trata em uma camada, uma mudança de layout em outra, uma alucinação em uma terceira. Sem categorização, a equipe conserta a coisa errada.

Erro 10. Não se proteger contra injeções via conteúdo

A página é uma fonte não confiável. O texto nela pode conter instruções que o modelo interpretará como comandos. Filtragem da percepção, separação explícita entre dados e comandos no prompt, lista branca de domínios e proibição de ações irreversíveis sem confirmação — o mínimo obrigatório.

Erro 11. Ausência de conjunto de regressão

Mudaram o prompt — ficou melhor em um site e pior em cinco outros, mas só descobriram uma semana depois. Um conjunto de 30 a 50 tarefas de referência com verificação automática do resultado, executado a cada mudança, evita isso.

Ferramentas e recursos para construir agentes web

O ecossistema muda rápido, então, em vez de versões específicas, daremos um mapa de categorias e o que observar na escolha.

Controle do navegador

• Playwright — padrão de fato para projetos novos: suporte a todos os navegadores principais, isolamento de contextos, espera embutida por elementos, acesso à árvore de acessibilidade. A maioria dos frameworks de agentes é construída sobre ele.
• Puppeteer — predecessor histórico para uma família de navegadores, ainda amplamente usado.
• Selenium — veterano, relevante onde já existe uma grande infraestrutura de testes.

Frameworks de agentes para navegador

• Bibliotecas que transformam o navegador em um conjunto de ferramentas para o modelo e implementam o ciclo de observação e ação: projetos abertos da família browser-use, Stagehand e similares. Elas já fazem a compressão da página em árvore com identificadores, então o método 1, na sua forma básica, vem pronto.
• Orquestradores de propósito geral com suporte a grafos de estado: LangGraph e semelhantes. Úteis para implementar o esqueleto do método 2.
• Kits oficiais de desenvolvimento de agentes dos provedores de modelos com modo de controle do computador. Entregam um agente visual «chave na mão», mas exigem atenção especial ao custo.

Runtimes de navegador

• Serviços em nuvem de navegadores remotos com persistência de sessões, gravação e paralelismo. Tiram a dor de cabeça da infraestrutura, mas verifique se permitem conectar seus proxies no nível do contexto do navegador — isso é crítico para o método 3.
• Implantação própria em contêineres — mais controle, mais trabalho. Justifica-se em grandes volumes.

Camada de rede

• Proxies móveis com gerenciamento via API. Critérios-chave: escolha de região até o nível de cidade e operadora, controle de rotação de endereço sob demanda e por agendamento, estabilidade do canal, suporte aos protocolos com que sua stack de navegador trabalha e tarifação transparente de tráfego. Um ponto positivo adicional é a possibilidade de fixar o canal a um perfil específico por um período longo.
• Gerenciador de perfis de navegador. Para a identidade coerente das sessões: fuso horário, idioma, tamanho de tela, tipo de dispositivo. Pode ser tanto um produto separado quanto um módulo do seu sistema.

Observabilidade

• Plataformas de rastreamento de chamadas a modelos e passos de agentes, com armazenamento de screenshots e cálculo de custo.
• Sistemas comuns de logging e métricas — não os despreze; as métricas de rede e de infraestrutura do agente não diferem em nada das métricas de qualquer serviço.

Avaliação de qualidade

• Benchmarks públicos de agentes web (conjuntos de tarefas em sites reais ou recriados) — úteis para entender o teto dos modelos atuais.
• Seu próprio conjunto de regressão — insubstituível, porque seus sites e tarefas são únicos.

O que ler e o que acompanhar

Acompanhe três direções. A primeira são os modelos com controle nativo de computador: eles estão ficando rapidamente mais baratos e mais rápidos. A segunda são os padrões para tráfego de agentes: o setor discute formas pelas quais um agente pode se apresentar abertamente ao site por meio de requisições assinadas e arquivos-descrição com que o site explica aos agentes como trabalhar com ele corretamente. A terceira são os navegadores com agentes para usuários finais: eles formam expectativas e mudam a forma como os sites encaram visitantes automatizados.

Cases e resultados: como isso funciona na prática

Abaixo, quatro cenários generalizados da prática de equipes que trabalham com automação e proxies móveis. Os números estão arredondados e servem como referência, não como garantia.

Case 1. Monitoramento de preços em marketplaces para um vendedor

Tarefa. Um vendedor com um sortimento de 600 itens queria saber diariamente os preços e a disponibilidade de oito concorrentes em duas plataformas. Antes, isso era feito por um script com seletores, que quebrava a cada duas semanas e exigia dois dias para consertar.

Solução. Agente de DOM sobre a árvore de acessibilidade, esqueleto de estados «buscar, selecionar o card, extrair, validar», roteamento: modelo barato para extração, modelo caro só em caso de falha. Camada de rede — pool de proxies móveis da região necessária, retenção do endereço durante a tarefa por concorrente, limite de duas requisições paralelas por domínio, pausas de 2 a 4 segundos.

Resultado. A taxa de extrações bem-sucedidas no primeiro mês foi de 93 por cento, contra 71 do script antigo nas «boas» semanas. O tempo de conserto após mudança de layout foi zero: o agente se adaptou sozinho em 9 de 10 casos. O custo por card, depois da compilação de trajetórias, ficou comparável ao custo de uma requisição a uma API de dados paga, mas com controle total sobre o frescor dos dados.

Case 2. Verificação de criativos de anúncios e landing pages por região

Tarefa. A equipe de arbitragem lançava campanhas em seis regiões e queria verificar automaticamente que as landing pages abriam corretamente em dispositivos móveis em cada região, que os redirecionamentos levavam ao lugar certo e que as ofertas correspondiam ao idioma local.

Solução. Agente híbrido: árvore de acessibilidade mais screenshot obrigatório da página final. Perfis de sessão estritamente coerentes: canal de proxy móvel da região, tamanho de tela móvel, idioma e fuso horário correspondentes. O resultado da tarefa é um relatório estruturado com os campos «abriu, tempo de carregamento, endereço final, idioma do conteúdo, screenshot».

Resultado. A verificação manual consumia cerca de três horas por dia de um especialista. O agente faz a rodada completa em 12 minutos e é executado a cada duas horas. No primeiro mês, foram identificados 14 incidentes de redirecionamento para região errada, que antes só eram descobertos pela queda de conversão um ou dois dias depois. A economia de orçamento de anúncios é estimada pela equipe em dezenas de por cento do valor que antes se perdia com combinações que não funcionavam.

Case 3. Auditoria de resultados de busca regionais para uma agência de SEO

Tarefa. A agência atendia clientes em doze cidades e queria ver os resultados reais de busca e os blocos do buscador para 300 consultas em cada cidade, semanalmente.

Solução. Agente de planejar-e-executar: a matriz «cidade por consulta» é percorrida por código, e o modelo entra apenas para extrair e classificar os elementos dos resultados (orgânico, mapas, blocos de produtos, vídeo). Camada de rede — proxies móveis com canal vinculado à cidade, rotação de endereço entre consultas, pausas rigorosas.

Resultado. O custo de uma consulta verificada ficou várias vezes menor que a assinatura de um serviço especializado, com completude comparável e, o mais importante, surgiu a possibilidade de extrair elementos arbitrários dos resultados que o serviço não tinha. A taxa de resultados vazios ou inválidos ficou abaixo de 3 por cento, e todos eles são automaticamente enviados para reverificação.

Case 4. Testes de aceitação do site antes do lançamento

Tarefa. Uma pequena equipe de e-commerce, sem testador dedicado, queria rodar cenários de usuário (busca, carrinho, checkout até a etapa de pagamento) antes de cada release, em perfis móveis e desktop.

Solução. Agente semiautônomo com proibição de ações irreversíveis (o pagamento foi excluído no nível da lista de ações proibidas). Os cenários são descritos em linguagem natural, o que permitiu ao gerente de produto adicionar novos sem programador. Os perfis móveis são executados por proxies móveis, para que as condições fiquem o mais próximas possível das de usuários reais.

Resultado. A rodada de regressão de 40 cenários passou a levar 25 minutos, em vez de meio dia de trabalho manual. Em um trimestre, o agente detectou 9 regressões antes de irem para produção. Um efeito colateral interessante: os rastros do agente viraram documentação dos caminhos de usuário, que antes não existia.

O que os cases bem-sucedidos têm em comum

• A tarefa tinha um contrato formal de resultado.
• A autonomia era limitada por um esqueleto de estados.
• A camada de rede foi projetada como parte da arquitetura, não conectada no final.
• Custo e sucesso eram medidos desde o primeiro dia.
• O modelo era usado com parcimônia, e o código determinístico, em tudo o que era possível.

FAQ: perguntas que surgem na segunda semana do piloto

O que um agente de IA tem de fundamentalmente diferente de um scraper avançado?

O scraper executa uma sequência predefinida e extrai dados por regras fixas. O agente recebe um objetivo, monta o plano por conta própria, observa o resultado de cada ação e se adapta. O scraper é determinístico e barato, mas frágil. O agente é flexível, mas mais caro e exige controle. Na prática, o ótimo é o híbrido: o agente faz o reconhecimento e se recupera de falhas, e as trajetórias estáveis são compiladas em código determinístico.

Qual modelo escolher para um agente web?

Não um, mas no mínimo dois. Barato e rápido — para extrair dados por esquema, verificações e decisões simples. De ponta — para planejamento e recuperação após falhas. Um modelo multimodal é necessário se você usar screenshots. O critério de escolha não é o ranking abstrato, mas o resultado no seu conjunto de regressão de tarefas com o orçamento definido.

Por que o agente passa na demonstração, mas em produção a taxa de sucesso cai pela metade?

As demonstrações são feitas em sites conhecidos, em um momento favorável. Em produção, aparecem janelas pop-up, versões regionais de interface, carregamento lento, limites de frequência, mudanças de layout. Cada fator tira alguns por cento de sucesso. Isso se trata com os métodos do artigo: compressão da percepção, esqueleto de estados com verificação de pós-condições, camada de rede coerente e categorização dos insucessos, para corrigir a camada certa.

Por que o agente precisa de proxies móveis, se ele não faz nada de proibido?

Justamente porque faz o que é permitido, para ele é importante ver o site como o vê um usuário comum da região necessária e do tipo de dispositivo necessário. Endereços de data center não oferecem essa experiência: os sites os tratam com mais rigor, mostram verificações e versões reduzidas com mais frequência, e o contexto regional não corresponde. Os proxies móveis oferecem tráfego indistinguível do de assinantes reais, mudança natural de endereços e geografia precisa. Além disso, há a distribuição de carga, que é igualmente útil para você e para os sites com que trabalha.

Com que frequência trocar o endereço do proxy durante o trabalho do agente?

Depende do tipo de tarefa. Cenários de vários passos dentro de uma mesma sessão, especialmente com autenticação em suas contas, exigem retenção do endereço até o fim da tarefa: trocar o endereço no meio da sessão parece anormal para o site. A coleta de dados públicos em um grande número de páginas se beneficia da rotação entre tarefas. Regra universal: o endereço muda nas fronteiras das tarefas, não dentro delas.

Como se proteger do fato de a página «reprogramar» o agente?

Quatro medidas. Filtragem da percepção: só a estrutura e o texto relevante entram no modelo. Separação explícita no prompt: todo o conteúdo da página são dados, não comandos. Lista branca de domínios: o agente fisicamente não pode ir para um site externo. Proteção das ações irreversíveis: pagamento, envio, exclusão exigem confirmação humana ou estão proibidos no cenário. Nenhuma medida é absoluta, mas juntas reduzem o risco a um nível aceitável.

Quanto custa uma tarefa de agente web?

A variação é enorme: de frações de centavo a alguns dólares por uma tarefa de dez passos. Os fatores determinantes são o formato da percepção (HTML bruto contra árvore de acessibilidade dá uma diferença de dezenas de vezes), a escolha do modelo, o número de passos e o tráfego. Uma implementação ingênua custa caro; depois de aplicar os quatro métodos, a economia típica é de 20 a 50 vezes. Calcule o custo em dinheiro por tarefa desde o primeiro dia e defina orçamentos.

É possível dispensar o navegador e trabalhar só com APIs dos sites?

Onde a API existe e seus termos permitem — sim, e é sempre mais barato e confiável. Mas uma parte enorme dos dados importantes para marketing e e-commerce só está disponível pela interface: resultados regionais, exibição de anúncios, preço real com personalização, aparência da landing page. Para isso, é preciso um navegador. A estratégia razoável é API onde for possível, agente de navegador onde for necessário.

Como saber que o agente está pronto para trabalhar sem supervisão?

Quando, em um conjunto de regressão de 30 a 50 tarefas, a taxa de sucesso fica consistentemente acima do seu limite (normalmente 90 por cento), os insucessos estão categorizados e não contêm «causa desconhecida», as ações irreversíveis estão protegidas, há orçamentos e alertas, e os rastros permitem analisar qualquer incidente em minutos. Até lá — uma pessoa no circuito, ao menos na verificação por amostragem dos resultados.

O que vai mudar nos agentes web nos próximos um ou dois anos?

Três tendências. Os modelos com controle nativo de computador vão ficar mais baratos e mais rápidos, deslocando o equilíbrio na direção dos agentes visuais. Vão surgir formas consensuais pelas quais o agente se apresenta abertamente ao site, e o site explica aos agentes as regras de interação — isso tornará a relação entre clientes automatizados e recursos mais transparente. E os navegadores com agentes para usuários comuns vão acostumar os sites ao fato de que uma parte significativa dos visitantes age por meio de um intermediário. Para quem trabalha com automação, isso significa: a engenharia em torno do modelo, incluindo a camada de rede, continuará sendo a principal vantagem competitiva, porque os modelos em si se equalizam rapidamente.

Conclusão: o agente é um sistema, não um modelo

Se for para levar uma única ideia deste artigo, é esta: a qualidade de um agente web não é determinada pelo modelo que ele tem dentro, mas por como as camadas ao redor dele são projetadas. A percepção decide quanto você paga e quão bem o agente entende a página. O contorno de controle decide se ele vai se perder. A camada de rede decide o que ele vai ver e se conseguirá trabalhar de forma estável. A observabilidade decide se você vai saber dos problemas antes que eles fiquem caros.

Analisamos a arquitetura de sete camadas e o mapa dos gargalos, quatro métodos práticos com checklists, onze erros comuns, o mapa de ferramentas e quatro cenários em que tudo isso funcionou. O que fazer agora?

1. Escolha uma tarefa com valor claro e critério formal de sucesso. Monitoramento de preços, verificação de landing pages por região, auditoria de resultados — qualquer coisa que hoje você faça à mão ou com um script frágil.
2. Construa um agente semiautônomo sobre a árvore de acessibilidade, com esqueleto de estados e orçamento de passos. Não corra atrás de autonomia.
3. Projete a camada de rede desde o início. Proxies móveis da região necessária, perfil de sessão coerente, limites de frequência, respeito às regras dos recursos.
4. Ative as métricas desde a primeira execução. Sucesso, passos, custo, tempo, categorias de insucesso.
5. Junte cem rastros, monte um conjunto de regressão e só depois otimize: roteamento de modelos, compressão do histórico, compilação de trajetórias.

A web foi construída para pessoas, e para os agentes não é fácil nela. Mas é justamente por isso que um agente de IA bem projetado oferece uma vantagem tão grande: ele faz o que antes só pessoas faziam, com a velocidade e a escala de uma máquina. A tarefa do engenheiro é fazer com que essa máquina veja com clareza, pense com economia, aja com cuidado e saia para a rede como um visitante bem-comportado. Assim, os gargalos se transformam em tarefas de engenharia compreensíveis, e o agente, em um colaborador confiável que nunca se cansa.