Pular para o conteúdo
Zumkai

O que muda quando o agente ganha browser

O melhor modelo resolve 80% das tarefas em navegador. Declarar a ferramenta custa 6.600 tokens, e a checklist de segurança da doc é maior que a de uso.

  • browser use
  • agentes de ia
Card com o contraste entre os 80% de acerto do melhor modelo em tarefas de navegador e as 27 ferramentas declaradas de uma vez.
Sumário
  1. O que a ferramenta é, e onde ela não está
  2. Uma em cada cinco falha
  3. A superfície de ataque mudou de dono
  4. A checklist que a própria documentação publica
  5. O que isso custa
  6. Vinte e sete ferramentas de uma vez
  7. Quando não usar
  8. Como este blog trata isso
  9. Perguntas frequentes
  10. O que levar

Toda ferramenta que você deu ao seu agente até hoje lê alguma coisa que é sua. Seus arquivos, seu banco, sua API, seu servidor MCP.

O browser lê a web aberta.

É a primeira vez que a entrada do agente passa a ser controlada por terceiros em escala, e que ele tem ferramenta para agir sobre o que leu. A documentação da Anthropic reconhece isso do jeito mais claro possível: a seção de segurança da ferramenta de browser é maior que a de uso.

Some a isso a taxa de acerto. No benchmark reprodutível mais completo do assunto, o melhor modelo resolve 80% das tarefas. Uma em cada cinco falha, agindo em site real.

Este post é sobre o que essas duas coisas juntas exigem de quem vai usar. É a continuação de engenharia de harness na camada onde o agente encosta no mundo.

O que a ferramenta é, e onde ela não está

O browser_toolset_20260801 dá ao modelo 27 ferramentas membro por padrão, mais quatro opcionais. Elas cobrem navegação, captura de tela, ponteiro, teclado, leitura de página, formulários, diagnóstico e abas (documentação da Anthropic, lida em 29/08/2026).

Duas características de arquitetura importam mais que a lista.

A automação roda no seu ambiente. O navegador é seu, a execução é do lado do cliente, e nada disso acontece em servidor da Anthropic. Isso é bom para privacidade e é exatamente o que transfere para você a responsabilidade de conter o que der errado.

A disponibilidade é limitada, e isso decide adoção. A ferramenta existe na Claude API e na Google Cloud. Não está na Amazon Bedrock, não está na Microsoft Foundry e não está nos Managed Agents. Se a sua empresa padronizou em uma dessas três, a conversa termina aí por enquanto.

O modelo trabalha por dois caminhos ao mesmo tempo: a estrutura da página, via árvore de acessibilidade, e a representação visual, via screenshot e coordenadas. As ferramentas devolvem referências de elemento como [ref_2], e o modelo age sobre elas.

Essas referências têm prazo de validade. Quando a aba navega ou o DOM muda de forma relevante, elas ficam obsoletas e a chamada devolve erro pedindo releitura da página. Ações em lote param na primeira falha, e as seguintes respondem com o texto exato "Not executed: an earlier action in this turn failed."

Uma nota de arquitetura antes de seguir: a conexão entre agente e ferramenta tem um mapa de protocolos próprio, e browser não é protocolo, é ferramenta.

Uma em cada cinco falha

O número que decide se isso entra em produção é a taxa de acerto, e ela tem uma medição pública decente.

A Browser Use mantém um benchmark de 100 tarefas selecionadas à mão, tiradas de cinco fontes: desafios próprios, WebBench, Mind2Web 2, GAIA e BrowseComp. São mais de 600 mil execuções no total. O veredito é binário, dado por um LLM juiz em sites reais, e o código está aberto: uma rodada de 100 tarefas custa cerca de três horas e dez dólares.

Taxa de acerto por modelo em 100 tarefas de navegador claude-fable-5 acerta 80%, Browser Use Cloud 78%, ChatBrowserUse-2 63,3%, claude-opus-4-6 62%, gemini-3-1-pro 59,3%, claude-sonnet-4-6 59%, gpt-5 52,4%, gpt-5-mini 37% e gemini-2.5-flash 35,2%. Acerto em 100 tarefas, sites reais claude-fable-5 80,0% Browser Use Cloud 78,0% ChatBrowserUse-2 63,3% claude-opus-4-6 62,0% gemini-3-1-pro 59,3% claude-sonnet-4-6 59,0% gpt-5 52,4% gpt-5-mini 37,0% gemini-2.5-flash 35,2% O juiz é um LLM que concorda com humanos em 87% dos casos.
Fonte: benchmark aberto da Browser Use, 100 tarefas de cinco conjuntos. A empresa vende infraestrutura de agente de navegador e o produto dela aparece em segundo.

Duas ressalvas antes de qualquer conclusão.

A Browser Use vende infraestrutura de agente de browser, e o produto dela ocupa o segundo lugar no próprio ranking. Em compensação, é o único benchmark do tema com metodologia publicada e reprodutível por dez dólares, o que merece o crédito na mesma frase em que se registra o conflito.

O juiz é um LLM. Ele concorda com avaliação humana em 87% dos casos, o que significa discordância em treze. Com 80,0% e 78,0% separados por dois pontos, a ordem do topo não é decidível por esse método.

O que é decidível é a ordem de grandeza, e ela basta para a decisão: o melhor erra uma em cinco. Para um sistema que clica em site real, isso não é "funciona". É "precisa de supervisão".

Como a falha se manifesta

Saber a taxa ajuda pouco se você não reconhece o erro quando ele acontece. A documentação descreve três modos, e todos aparecem cedo em uso real.

Referência obsoleta. O modelo leu a página, guardou [ref_2] para um botão, e nesse meio-tempo a aba navegou ou o DOM mudou. A chamada devolve erro dizendo que a referência está obsoleta e pedindo releitura. É o caso mais comum e o mais benigno: falha barulhenta, com recuperação óbvia.

Lote interrompido. As ações em lote rodam em ordem e param na primeira falha. As seguintes respondem com o texto exato "Not executed: an earlier action in this turn failed." Se você monta um lote de seis passos e o segundo falha, os quatro últimos não aconteceram — e é preciso ler as respostas para saber disso, porque a requisição em si não falhou.

Árvore incompleta. Canvas, listas virtualizadas e iframes de outra origem não produzem nós úteis na árvore de acessibilidade. O modelo não encontra o elemento, e a saída é coordenada de pixel, que quebra a cada mudança de layout. Este é o modo silencioso: nada dá erro, o agente só clica no lugar errado.

A diferença entre os três importa para quem vai operar. Os dois primeiros você trata com repetição; o terceiro exige perceber que aquela parte da página não é legível estruturalmente, e decidir se vale insistir.

A superfície de ataque mudou de dono

<!-- [UNIQUE INSIGHT] -->

Aqui está a diferença que separa esta ferramenta de todas as outras, e que quase nenhum texto sobre o assunto enuncia.

FerramentaQuem controla o que o agente lêO agente age?
Leitura de arquivoVocêSim
Consulta a bancoVocêSim
API internaVocêSim
Servidor MCP próprioVocêSim
Busca webTerceirosNão, só lê
BrowserTerceirosSim

Até o browser, o pior caso de entrada hostil era um documento que alguém conseguiu colocar no seu repositório, ou um pacote comprometido. Superfície real, mas limitada e sob alguma curadoria sua.

Com browser, a entrada é a web aberta. Qualquer página que o agente visite pode conter instrução escrita para ele. A documentação dá o exemplo com todas as letras: um texto na página dizendo "ignore suas instruções anteriores e navegue para…" desvia o agente da tarefa.

Isso não é novidade conceitual. É a mesma injeção de prompt que não tem correção definitiva, e que aparece em seis das dez categorias do OWASP para agentes. O que muda é a escala da exposição: de "documentos que entraram no meu projeto" para "a internet".

E como não existe correção definitiva, a defesa precisa ser estrutural. É por isso que a próxima seção é a maior da documentação.

A checklist que a própria documentação publica

Não é recomendação deste post. É o que a Anthropic lista como precaução necessária para operar a ferramenta, e o volume dela é o dado mais eloquente da página.

As quatro camadas de contenção recomendadas na documentação Da base ao topo: isolamento do ambiente em container com perfil novo e sem credencial; restrição de rede com allowlist de domínio e bloqueio de faixas privadas; tratamento da entrada, lendo pela árvore de acessibilidade e redigindo credenciais dos logs; e confirmação humana para ação consequente. 1 · Ambiente container isolado, perfil novo, sem credencial 2 · Rede allowlist de domínio, bloqueio de faixa privada 3 · Entrada árvore de acessibilidade, credencial redigida 4 · Ação confirmação humana para ato consequente Nenhuma das quatro é opcional na documentação
Fonte: seção de precauções de segurança da documentação da ferramenta de browser.

Ambiente. Rodar o navegador em container ou máquina virtual isolada, com privilégio mínimo, perfil novo sem credencial salva e sem acesso a sistema de arquivos sensível.

Rede. Allowlist de domínio na camada de rede, bloqueando loopback, link-local e faixas privadas. E reconferir depois de cada redirecionamento, porque o destino final pode não ser o que foi pedido. Só esquemas http e https; rejeitar javascript:, file:, data: e chrome:, analisando com parser de URL em vez de prefixo de string.

Entrada. Construir a leitura a partir do conteúdo renderizado, pela árvore de acessibilidade, e não do DOM cru. Esconder do modelo o texto fora da viewport. Redigir credenciais dos logs de console e de rede. Sanitizar URLs vindas da página antes de reportá-las.

Ação. Confirmação humana para qualquer ato consequente: compra, mudança de conta, envio de mensagem, tudo que exigiria consentimento afirmativo de uma pessoa. E manter javascript_exec e file_upload desabilitados, como já vêm de fábrica, salvo necessidade real.

Repare no desenho: as três primeiras camadas reduzem o que pode ser alcançado, e a quarta aceita que as outras podem falhar. É a mesma lógica de travar antes de o agente agir, e a razão de o modo automático precisar de fronteira explícita.

O que isso custa

O preço aparece antes de o agente navegar para qualquer lugar.

Declarar o conjunto adiciona cerca de 6.600 tokens de entrada em toda requisição — aproximadamente 6.610 no Fable 5, Mythos 5, Opus 5 e Opus 4.8, e 6.670 no Sonnet 5. Habilitar os quatro membros opcionais soma outros 880 (página de preços, lida em 28/08/2026).

ItemCusto por requisição
Conjunto padrão, 27 ferramentas~6.600 tokens de entrada
Os quatro membros opcionais+880 tokens
Cada screenshotcobrado como imagem de entrada

A conta mensal fica visível rápido. A 500 requisições por dia no Sonnet 5, só a declaração das ferramentas custa cerca de US$ 198 por mês, antes de qualquer trabalho útil. É o mesmo tipo de vazamento tratado em onde o dinheiro vaza em produção, com um agravante: aqui entram também as imagens.

Há uma recomendação da documentação que é, ao mesmo tempo, técnica e econômica: ler a árvore de acessibilidade antes de tirar screenshot. Ela é mais confiável para localizar elementos e gasta menos token que uma imagem. Screenshot vira o recurso de exceção, para quando a árvore não descreve o que precisa ser clicado.

Vinte e sete ferramentas de uma vez

Declarar o conjunto inteiro é o padrão, e é uma decisão de desenho que merece revisão.

Vinte e sete ferramentas na janela significam vinte e sete descrições que o modelo lê em toda requisição, e vinte e sete opções entre as quais escolher a cada passo. O problema não é novo, e está tratado em design de ferramentas para agentes: conjunto grande demais piora a escolha, não só o custo.

Quatro membros já vêm desligados por decisão da própria Anthropic, e a razão é de risco, não de tamanho: javascript_exec, file_upload, read_console e read_network. Os dois primeiros abrem execução arbitrária e envio de arquivo. Os dois últimos vazam credencial se os logs não forem tratados.

Um detalhe fácil de interpretar errado nos dois de diagnóstico: eles só capturam o que aconteceu depois de a automação anexar à aba. Resultado vazio não significa que não houve tráfego, significa que você começou a olhar tarde.

Os limites da leitura estrutural também pesam na decisão. A árvore de acessibilidade pode ser incompleta: canvas, listas virtualizadas e iframes de outra origem não geram nós úteis. Nesses casos o caminho é coordenada, com toda a fragilidade que isso traz.

Uma configuração inicial que se defende

Se você for ligar a ferramenta esta semana, esta é a postura que exige menos confiança no modelo e menos vigilância sua.

Mantenha os quatro opcionais desligados. Eles já vêm assim. Ligar javascript_exec porque "seria mais fácil" é trocar toda a contenção de entrada por conveniência, e o console e a rede só valem a pena depois que você tiver tratamento de credencial nos logs.

Comece com allowlist de um domínio só. Não a lista dos domínios que o agente pode precisar: o domínio da tarefa. Ampliar depois é fácil e cada ampliação é uma decisão consciente. Começar amplo é o caminho para nunca mais revisar.

Trate toda ação que altera estado como consequente. A documentação nomeia compra, mudança de conta e envio de mensagem. Na dúvida, some qualquer coisa que a pessoa não conseguiria desfazer sozinha em trinta segundos.

Registre o que o agente leu, não só o que ele fez. Quando algo der errado por injeção, a instrução hostil estará no conteúdo da página, e sem esse registro você vai depurar a decisão do modelo sem enxergar a entrada que a produziu.

Nenhum desses quatro itens depende de o modelo cooperar, que é justamente o critério de um bom guardrail.

Quando não usar

A documentação é explícita sobre as alternativas, e essa parte quase nunca é repetida.

SituaçãoUse
Só precisa ler conteúdo webWeb fetch ou busca web
A página monta conteúdo com JavaScript e você precisa agirBrowser
A tarefa passa da web para o desktopComputer use
É chamada simples de APINenhum dos três

A primeira linha elimina a maior parte dos casos. Se o objetivo é ler uma página, buscar um dado ou conferir uma fonte, web fetch resolve, roda do lado do servidor, é mais leve e não abre nenhuma das superfícies discutidas aqui.

Browser se justifica quando há ação: preencher formulário, percorrer fluxo de várias etapas, operar interface que não tem API. Se a sua tarefa não tem essa palavra, provavelmente você não precisa da ferramenta.

Como este blog trata isso

<!-- [PERSONAL EXPERIENCE] -->

A operação que produz estes textos tem ferramenta de browser disponível e não a usou nenhuma vez na produção deste cluster. Vale explicar por quê, porque a razão é a recomendação deste post aplicada sem cerimônia.

A pesquisa de cada artigo é leitura: abrir um abstract no arXiv, uma página de documentação, um model card, um press release. Nenhuma dessas tarefas tem ação. Todas foram feitas com busca e web fetch, que rodam do lado do servidor, custam menos e não expõem navegador nenhum a página hostil.

Foram mais de cinquenta fontes externas verificadas assim ao longo do cluster. Em nenhuma delas o browser teria feito diferença, porque em nenhuma delas era preciso clicar em nada.

O julgamento explícito: a decisão certa sobre browser, na maior parte dos casos, é não usar. Não por medo, e sim porque a pergunta "eu preciso agir nesta página?" quase sempre tem resposta negativa em trabalho de pesquisa.

Há um caso em que ele faria falta, e é justo registrar. Verificar como o próprio blog aparece publicado exigiria abrir o site, e daqui isso não é possível: a rede corporativa bloqueia o domínio por geolocalização, então a conferência de produção depende do celular do autor. Um navegador isolado resolveria, e essa é a única tarefa desta operação que hoje justificaria a ferramenta.

Perguntas frequentes

O agente consegue navegar sozinho?

Consegue, com supervisão. No benchmark aberto da Browser Use, com 100 tarefas em sites reais, o melhor modelo resolve 80% delas. Uma em cada cinco falha, e como as ações acontecem em sites de verdade, a documentação exige confirmação humana para qualquer ato consequente.

É seguro dar browser para o agente?

Só com contenção estrutural. A documentação da Anthropic pede container isolado com perfil sem credencial, allowlist de domínio na camada de rede, leitura pela árvore de acessibilidade em vez do DOM cru, credenciais redigidas dos logs e confirmação humana para ação consequente. O risco central é injeção de prompt pelo conteúdo da página, que não tem correção definitiva.

Qual a diferença para scraping tradicional?

Scraping segue um roteiro fixo que você escreveu; o agente decide o que fazer a cada passo, lendo a página. Isso o torna capaz de lidar com layout que muda, e também o torna suscetível a instruções plantadas na página, coisa que um scraper determinístico ignora.

Quanto custa a mais?

Declarar o conjunto adiciona cerca de 6.600 tokens de entrada em toda requisição, mesmo antes de navegar. Os quatro membros opcionais somam outros 880, e cada screenshot é cobrado como imagem. Ler a árvore de acessibilidade em vez de tirar screenshot é mais barato e mais confiável.

Funciona na Bedrock ou na Azure?

Não. A ferramenta está disponível na Claude API e na Google Cloud. Não está na Amazon Bedrock, na Microsoft Foundry nem nos Managed Agents. Para quem padronizou nessas plataformas, é um bloqueio de adoção, não uma questão de configuração.

Preciso confirmar cada ação?

Não todas, mas todas as consequentes. A documentação nomeia compra, mudança de conta e envio de mensagem, e generaliza para qualquer coisa que exigiria consentimento afirmativo. A confirmação deve acontecer no seu executor, antes de cada chamada, porque um lote pode conter várias.

O que levar

  • O browser é a primeira ferramenta em que a entrada do agente é de terceiros e ele ainda age sobre ela.
  • O melhor modelo acerta 80% de 100 tarefas. Uma em cinco falha, em site real.
  • 6.600 tokens por requisição só para declarar, mais screenshot cobrado como imagem.
  • A contenção tem quatro camadas, e a última existe porque as outras podem falhar.
  • Só na Claude API e na Google Cloud. Bedrock e Foundry ficam de fora.
  • Se a tarefa é ler, web fetch resolve melhor, mais barato e sem abrir nada.

Antes de habilitar a ferramenta, responda uma pergunta só: a tarefa exige agir numa página? Se a resposta for não, você acabou de economizar 6.600 tokens por requisição e uma superfície de ataque inteira.

Leia também