Vercel apresenta agent-browser, acesso leve ao navegador para agentes de IA sem MCP

A Vercel lançou o agent-browser, uma ferramenta que dá a agentes de IA acesso ao navegador sem as camadas pesadas do MCP. A ideia é simples: mostrar ao modelo não todo o DOM da página, mas uma lista curta de elementos interativos com os quais ele pode trabalhar de imediato.

Por que o MCP emperra

Playwright e Puppeteer não vão desaparecer: são ferramentas fortes para testes e2e, CI/CD e scraping previsível. Os problemas começam quando se tenta entregar o controle do navegador a um LLM por meio do MCP.

Para saber onde clicar, o modelo precisa enxergar a página. Em geral, envia-se ao contexto HTML bruto ou uma árvore de acessibilidade. Em SPAs modernas, isso rapidamente vira milhares de tokens extras a cada passo e consome a memória do agente antes mesmo de ele chegar ao objetivo.

Segundo dados citados pelo autor da análise, um único clique e um snapshot de uma página complexa podem custar de 15 a 200 mil tokens por passo. Isso não é só caro, também é instável: o modelo gasta contexto lendo a árvore da página, se confunde com seletores CSS e erra com mais frequência os botões certos. Em cenários determinísticos essa abordagem ainda é tolerável, mas para um agente autônomo que precisa se orientar rápido na web, é pesada demais.

O que a Vercel fez

O problema da Vercel era prático: se um agente escreve a interface, ele precisa conseguir abrir a página, verificar um componente e executar ações básicas no navegador. Para isso, a equipe simplificou o agent-browser e eliminou a antiga dependência de um daemon Node.

A versão atual é uma CLI leve em Rust que trabalha diretamente com o Chrome DevTools Protocol. Com isso, a ferramenta é mais fácil de rodar localmente, mais prática de colocar em contêineres e dispensa arrastar infraestrutura Node adicional.

• um único binário em Rust
• comunicação direta com o CDP, sem camadas intermediárias
• zero dependências para Docker e ambientes locais
• referências curtas no lugar do DOM completo

A ideia central é o snapshot de elementos interativos. Em vez de uma árvore gigantesca, o agente recebe uma lista compacta como button "Sign In" [ref=e1] ou textbox "Email" [ref=e2] e depois trabalha com comandos curtos: abrir a página, clicar em @e1, preencher o campo @e2. Esse formato ocupa centenas de tokens, e não dezenas de milhares. Para o LLM, a carga cai de forma notável e diminui a chance de a ação falhar por causa de um seletor frágil.

Uma nova interface para agentes

A diferença aparece bem num cenário simples: abrir um site e clicar no primeiro artigo. No esquema clássico com MCP, o agente primeiro recebe uma enorme árvore de acessibilidade, depois procura nela o título certo e tenta montar um seletor CSS exato. Qualquer mudança no layout, um modal de cookies ou um contêiner extra deixa esse clique frágil.

No agent-browser o caminho é mais curto: open, depois snapshot, depois click em uma ref curta. O modelo não se apoia em suposições sobre a estrutura do DOM, mas em um mapa pronto de elementos interativos.

“Não use MCP para o navegador: poupe suas janelas de contexto e seu

dinheiro de API.”

Vale notar que a Microsoft já defende uma ideia parecida com o @playwright/cli. Lá o agente também trabalha com comandos curtos, e o estado do navegador fica fora do contexto do modelo. É uma mudança importante para toda a categoria de agentic tooling: o mercado se afasta da ideia de despejar as entranhas do navegador direto no LLM e passa a um esquema em que a ferramenta local mantém o estado e entrega ao modelo apenas a camada mínima de controle. A diferença entre as soluções agora está mais no ecossistema: o Playwright continua mais pesado, e a abordagem em Rust da Vercel é mais minimalista.

O que isso significa

A automação de navegador para agentes de IA começa a se dividir em duas classes. Playwright e Puppeteer clássicos seguem como base para testes complexos e scraping, mas, para programação com agentes e validação rápida de interfaces, cresce a demanda por wrappers CLI leves.

A conclusão principal é simples: para o LLM compensa receber não o navegador inteiro, mas uma camada compacta de comandos e referências a elementos. É mais barato, mais estável e mais prático no trabalho real.