Proxies para agentes de IA browser-use e computer-use (guia 2026)

2026 é o ano em que os agentes de IA deixaram de ser demonstrações. O browser-use, os agentes estilo Operator da OpenAI, o computer use da Anthropic e uma dúzia de frameworks construídos sobre o Playwright agora controlam navegadores reais contra sites reais — reservando, comprando, pesquisando, monitorando. E todos eles batem na mesma parede: os sites em que operam os tratam como bots, porque eles são bots.

Este guia trata especificamente da camada de proxy para agentes de IA que controlam navegadores. Se o seu agente usa bibliotecas HTTP em vez de um navegador (ferramentas do LangChain, scrapers dentro do CrewAI), veja Proxies para Agentes de IA: LangChain, AutoGPT & CrewAI — este artigo é sobre agentes que controlam um navegador completo.

Por Que Agentes de Navegador São Bloqueados Mais Rápido que Scrapers

Contraintuitivo, mas verdadeiro: um agente LLM controlando um navegador Chrome real costuma ser bloqueado mais rápido que um scraper Python simples. Três motivos:

1. IP de datacenter + navegador perfeito = incompatibilidade. A impressão digital do navegador diz "Chrome real em hardware real", mas o IP pertence à AWS ou à GCP — onde a maioria dos agentes roda. Fornecedores de antibot dão muito peso ao ASN do IP; uma impressão digital de qualidade residencial sobre um ASN de datacenter é uma assinatura de automação de manual.
2. Agentes repetem como máquinas. Quando uma ação falha, o loop do LLM tenta de novo imediatamente, a partir do mesmo IP, com timing quase idêntico. Três repetições rápidas e idênticas são o básico da detecção comportamental.
3. O CDP deixa rastros. A maioria dos frameworks de agente controla o navegador via Chrome DevTools Protocol. Os sites sondam por navigator.webdriver, artefatos de timing específicos do CDP e sinais de modo headless. Combinado com um IP marcado, a pontuação cruza o limiar de bloqueio instantaneamente.

O IP é o mais barato dos três para corrigir, e corrigi-lo sozinho resolve a maioria dos bloqueios: roteie o agente por proxies residenciais para que a história do IP combine com a história do navegador.

Configuração: browser-use com Proxies Residenciais

O browser-use roda sobre o Playwright, então o suporte a proxy é nativo. O padrão: uma sessão fixa (sticky) por tarefa do agente, para que o IP permaneça estável enquanto o agente trabalha, e um IP novo para a próxima tarefa.

from browser_use import Agent, Browser, BrowserConfig
from langchain_openai import ChatOpenAI
import uuid

task_id = uuid.uuid4().hex[:8]

browser = Browser(config=BrowserConfig(
    proxy={
        "server": "http://us.jibaoproxy.com:913",
        "username": f"USERNAME-session-{task_id}",   # sticky: same IP for this task
        "password": "PASSWORD",
    },
))

agent = Agent(
    task="Find the current price of the Sony WH-1000XM6 on the three largest US retailers.",
    llm=ChatOpenAI(model="gpt-4o"),
    browser=browser,
)
result = await agent.run()

Detalhe importante: o sufixo session-{task_id}. Sem ele, um gateway rotativo pode entregar ao agente um novo IP no meio da tarefa — o conteúdo do carrinho desaparece, os logins caem e o agente desperdiça chamadas de LLM refazendo etapas. Com ele, a tarefa roda em um único IP do início ao fim, e a próxima tarefa recebe um IP limpo.

Configuração: Loops Playwright Cru / Computer-Use

Se você construiu seu próprio loop de agente sobre o Playwright (o padrão por trás da maioria das implementações estilo Operator e computer-use), o proxy vai no contexto do navegador:

from playwright.async_api import async_playwright

async with async_playwright() as p:
    browser = await p.chromium.launch(headless=False)
    context = await browser.new_context(
        proxy={
            "server": "http://us.jibaoproxy.com:913",
            "username": "USERNAME-session-agent42",
            "password": "PASSWORD",
        },
        viewport={"width": 1366, "height": 768},
        locale="en-US",
        timezone_id="America/Chicago",   # match the proxy country
    )
    page = await context.new_page()
    # ... agent loop: screenshot -> LLM -> action -> repeat

Defina locale e timezone_id para combinar com o país do proxy. Um agente navegando a partir de um IP dos EUA com um relógio em UTC+8 é uma inconsistência que os sistemas comportamentais pontuam contra você.

Proxies por contexto também oferecem um navegador, muitos agentes: cada new_context() pode carregar seu próprio sufixo de sessão, de modo que dez tarefas de agente simultâneas rodam em dez IPs residenciais diferentes sem dez processos do Chrome.

Estratégia de Sessão para Cargas de Trabalho de Agente

Carga de trabalho do agente	Estratégia de sessão	Por quê
Pesquisa / checagem de preços (sem login)	Fixa, 10 min, nova sessão por tarefa	Estável dentro da tarefa, IP novo entre tarefas
Operação em conta logada	Fixa 30 min, mesmo ID de sessão a cada execução	Sites marcam contas que pulam de país entre logins
Fluxos de checkout / reserva	Fixa 30 min	Mudança de IP no meio do checkout encerra a sessão e dispara revisão de fraude
Monitoramento de alto volume (centenas de páginas)	Rotativa, sem fixação de sessão	Maximiza a diversidade de IPs, sem estado a preservar

Controle de Custos: Agentes Queimam Banda

O tráfego residencial é cobrado por GB, e um agente de navegador puxa páginas completas — imagens, fontes, rastreadores — ao contrário de um scraper HTTP. Sem gestão, uma tarefa de agente pode consumir 20–50 MB. Três correções, em ordem de impacto:

1. Bloqueie recursos pesados que o LLM não precisa:

   await context.route("**/*.{png,jpg,jpeg,webp,gif,woff,woff2,mp4}",
                       lambda route: route.abort())

   Se o seu agente lê capturas de tela, mantenha as imagens na página alvo, mas ainda bloqueie vídeo e fontes. Se ele lê o DOM/árvore de acessibilidade, bloqueie as imagens também — corta o tráfego em 60–80%.
2. Roteie apenas o que precisa ser roteado. Chamadas de API de LLM (OpenAI/Anthropic) NÃO devem passar pelo proxy residencial — isso é puro GB desperdiçado e latência adicional. Use proxy no contexto do navegador, não no processo host.
3. Limite as repetições no nível do framework. No máximo duas repetições, com backoff e um ID de sessão novo na segunda — um IP novo resolve mais bloqueios que uma terceira tentativa idêntica.

Com bloqueio de imagens e roteamento delimitado, tarefas típicas de agente de navegador ficam na faixa de 2–8 MB — a $6,8/GB, isso é alguns centavos por cem tarefas.

O Que os Proxies Não Resolvem

Seção de honestidade. Um IP residencial corrige a incompatibilidade de ASN e a reputação do IP, que é o sinal isolado mais pesado na pontuação antibot de 2026. Ele não corrige:

• Detecção de CDP/headless — use as opções stealth do seu framework (o browser-use já vem com flags de lançamento corrigidas; para Playwright cru, veja os patches estilo rebrowser) e prefira o modo headed para fluxos de alto valor.
• TLS fingerprinting — não é um problema para agentes de navegador real (o TLS do navegador é genuíno), mas é por isso que você não pode "simplesmente reproduzir" as requisições do agente com requests depois. Veja JA3/JA4 explicado.
• Pontuação comportamental no fluxo de ações — adicione pequenos atrasos aleatórios entre as ações e evite coordenadas de clique idênticas pixel a pixel entre execuções.

Empilhe os três sobre um IP residencial e os agentes de navegador passam pelas mesmas verificações que usuários reais passam. Para os alvos mais difíceis (DataDome, PerimeterX), veja nosso guia de DataDome/PerimeterX.

Resumo

• Agentes em IPs de datacenter se autoidentificam; IPs residenciais fazem a história do IP combinar com a história do navegador.
• Uma sessão fixa por tarefa do agente; o mesmo ID de sessão para sempre em contas logadas; rotativa para monitoramento sem estado.
• Combine timezone_id/locale com o país do proxy.
• Bloqueie imagens/fontes/vídeo e nunca roteie chamadas de API de LLM pela banda residencial.
• Repita com um ID de sessão novo, não com o mesmo IP.