O Amazon Nova Act pode raciocinar sobre uma página da web e agir sobre ela. Em 2026, a parte difícil de um agente web em produção não é o modelo. É o acesso à web: alcançar a web ao vivo de forma confiável, com o geo-targeting correto e mantendo a conformidade. Este artigo combina o Nova Act com a camada de acesso à web da Bright Data para agentes de IA, e as medições aqui são provenientes de execuções reais.
TL;DR
O gargalo de um agente web de IA em produção é o acesso à web, não o modelo. A solução é uma divisão: o Amazon Nova Act toma as decisões de múltiplas etapas no navegador, e a camada de acesso à web da Bright Data cuida do acesso, conformidade e escala. O relatório Dados para IA 2026 da Bright Data revela que 97% das organizações de IA dependem de dados da web em tempo real, e 90% afirmam que as restrições de acesso estão limitando suas iniciativas de IA.
O script executável completo, com todas as importações, schemas e helpers, está no repositório complementar. Clone-o se quiser executá-lo, não copie e cole daqui.
Para acompanhar, você precisa do Python 3.10+, pip install nova-act e uma chave de API do Nova Act em nova.amazon.com/act. Você também precisa de uma conta Bright Data com uma Zona de Browser API, além de uma chave de API para as chamadas da camada de dados. O Node.js é necessário apenas para a seção Web MCP.
Por que o padrão de agente de navegador é insuficiente
A abordagem óbvia com um agente de navegador é deixá-lo fazer tudo. Abrir uma página, fechar o banner de cookies, rolar, extrair. Parece bom em uma demonstração, mas para a maioria dos trabalhos com dados é o padrão errado.
- É pesado. Uma única página real de consumidor (uma busca no eBay) transferiu cerca de 3,4 MB pelo navegador. Multiplique isso por milhões de páginas e você paga para mover toda a web renderizada, incluindo cada imagem, para extrair três campos.
- É frágil ao agir. Apontado para booking.com, o Nova Act lançou
ActActuationErrorao lidar com popups e conteúdo carregado de forma lazy, mesmo que a página tenha carregado corretamente. Leituras simples geralmente são confiáveis. A atuação pesada de múltiplas etapas falha ali. - É não-determinístico. A confiabilidade cai rapidamente. Dez etapas com 90% de confiabilidade resultam em algo próximo a
0,9¹⁰ ≈ 35%, a menos que você planeje para isso.
Nada disso torna os agentes de navegador inúteis. Portanto, use-os para o que só eles conseguem fazer (as ações e decisões de múltiplas etapas), e delegue todo o resto para a infraestrutura.
O que o Amazon Nova Act é, e o que não é
O Nova Act é um SDK da AWS, versão 3.4.x em meados de 2026, em transição de prévia de pesquisa para produção, para construir agentes de navegador em Python. Sua ideia de design é o oposto de um único prompt gigante. Você divide um fluxo de trabalho em comandos pequenos, atômicos e confiáveis e os conecta com Python comum. Os dois comandos são uma ação e uma leitura tipada:
from nova_act import NovaAct
from pydantic import BaseModel
class Product(BaseModel):
title: str | None = None
price: str | None = None
availability: str | None = None
with NovaAct(starting_page="https://example.com/product/123") as nova:
nova.act("search for wireless headphones") # an action
data = nova.act_get( # a typed read
"Return the product title, price, and availability.",
schema=Product.model_json_schema(),
)Com um schema Pydantic, o act_get pode transformar uma página em dados tipados sem seletores frágeis. O Nova Act controla um Chromium real através do Playwright por baixo, um detalhe que importa para a conexão. O Nova Act oferece raciocínio, navegação e extração estruturada. Ele não fornece nenhuma resposta à hostilidade da web aberta. Não tem alcance geográfico, sem desbloqueio em escala, sem conformidade integrada. Esse não é o seu trabalho. É o trabalho da camada de infraestrutura.
Bright Data, a camada de acesso à web
A camada é construída em torno de uma ideia: desbloquear a web para sua IA. O Web MCP, um servidor de Model Context Protocol, fornece ao agente ferramentas web estruturadas que ele chama diretamente. O Web Unlocker e a API SERP retornam páginas limpas e resultados de pesquisa. As APIs de Web Scraper e os Conjuntos de dados fazem a recuperação estruturada em massa. A Browser API é um Chrome na nuvem que você controla remotamente, para os casos em que um agente precisa agir. Por baixo há uma rede de mais de 400 milhões de IPs residenciais em 195 países, com desafios comuns de CAPTCHA, gerenciamento de fingerprint e geo-targeting gerenciados.
Na pesquisa Dados para IA 2026 da Bright Data, 87% das organizações concordam que uma “internet de dois níveis” está emergindo, uma web agêntica de tráfego automatizado funcionando ao lado da humana. E 65% já dependem de um provedor dedicado de infraestrutura de dados da web em vez de construir o acesso internamente.
Isso é uma camada, não uma ferramenta. Sua pilha de agentes muda. A camada de acesso à web abaixo dela não muda. Portanto, a questão de engenharia nunca é navegador versus API em abstrato. Você divide o trabalho em dois: o agente lida com as decisões, a infraestrutura lida com o acesso.
A arquitetura, cérebro no topo e infraestrutura embaixo
O Nova Act envia ações para baixo, e dados estruturados retornam.
O Nova Act toma as decisões e ações. A camada de acesso à web da Bright Data gerencia o acesso, conformidade, geografia e escala, e então alcança a web ao vivo.
Para o modo de ação, o Nova Act se conecta à Browser API da Bright Data através do Chrome DevTools Protocol (CDP), o mesmo protocolo que o Playwright (e portanto o Nova Act) já utiliza. Você troca o navegador e mantém o agente.
Configurando a conexão e os erros de setup a esperar
Crie uma Zona de Browser API (seu solver de CAPTCHA está ativado por padrão) e o dashboard fornece uma URL:
wss://brd-customer-<id>-zone-<name>:<password>@brd.superproxy.io:9222Essa string vem da aba Overview da zona, em Detalhes de acesso.
Os detalhes de acesso da Zona de Browser API. O dashboard fornece a string wss:// com credenciais inline, o formulário auth+@host mostrado no topo do painel. O Playwright moderno rejeita esse formulário inline, então split_cdp() move as credenciais para um header Authorization: Basic. A Lista de IPs permitidos à esquerda é a outra armadilha. Se seu IP não estiver listado, a chamada retorna um corpo vazio e o motivo chega nos headers de resposta em vez do código de status.
O erro Invalid URL: o Playwright rejeita credenciais inline em wss://
Cole isso diretamente no Nova Act e ele falha:
playwright._impl._errors.Error: BrowserType.connect_over_cdp:
Invalid URL: wss://brd-customer-...:[email protected]:9222Esta é uma falha comum na primeira execução. O Playwright moderno, versão 1.56, incluído com o Nova Act 3.4, rejeita credenciais incorporadas em uma URL WebSocket. O dashboard mostra o formulário inline porque funciona com clientes mais antigos, não com o Playwright dentro do Nova Act. A solução é remover as credenciais e passá-las como um header Authorization: Basic através de cdp_headers.
import os
import base64
def split_cdp(raw_url: str) -> tuple[str, dict | None]:
"""Bright Data gives an inline-credential wss URL; Playwright rejects that.
Move credentials into a Basic auth header. (Parsed manually because
Python 3.14's urlsplit also rejects the multi-colon netloc.)"""
scheme, sep, rest = raw_url.partition("://")
if not sep or "@" not in rest:
return raw_url, None
creds, _, hostport = rest.rpartition("@")
user, _, pwd = creds.partition(":")
token = base64.b64encode(f"{user}:{pwd}".encode()).decode()
return f"{scheme}://{hostport}", {"Authorization": f"Basic {token}"}
endpoint, headers = split_cdp(os.environ["BRIGHTDATA_CDP_URL"])
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
logs_directory="runs/demo") as nova: # NOTE: logs dir must already exist
...A armadilha intermitente do InvalidScreenResolution
A outra grande armadilha é o viewport. O navegador remoto da Bright Data fornece ao Nova Act uma janela de cerca de 1280×585, que é menor do que os aproximadamente 1600×900 que o Nova Act espera. O Nova Act não degrada graciosamente. Ele lança um InvalidScreenResolution ActError intermitente e grave. É intermitente porque cada sessão na nuvem recebe um tamanho ligeiramente diferente. Isso dificulta o diagnóstico e é fácil de confundir com um agente instável que precisa de nova tentativa. Force um tamanho suportado na página conectada:
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
screen_width=1600, screen_height=900, logs_directory="runs/demo") as nova:
nova.page.set_viewport_size({"width": 1600, "height": 900}) # force a supported size to stop InvalidScreenResolution
...Duas armadilhas menores: StartFailed e um logs_directory ausente
Não passe headless=True com cdp_endpoint_url, porque o navegador remoto já é headless e você receberá StartFailed. E logs_directory deve existir antes de iniciar, porque o Nova Act valida o caminho e não o criará.
Para que serve o agente
Com a conexão configurada, a questão é o que fazer o agente fazer. Uma leitura simples é a coisa menos distintiva que ele oferece, e as APIs de Web Scraper da Bright Data fazem isso melhor e mais barato. Um agente vale mais do que um Scraper porque pode agir.
Sua ação mais útil é alcançar dados por trás de um formulário. Não há URL estática para saber de antemão e nenhuma API disponível, então um Scraper não tem onde bater. Um agente pode preencher o formulário e ler o resultado. Então apontamos o Nova Act para o Drugs@FDA, o banco de dados autoritativo de aprovação de medicamentos dos EUA, e pedimos que ele recuperasse um registro de medicamento:
nova.act("Search for the drug named ibuprofen") # fill the form, submit
drug = nova.act_get("Return the brand name, active ingredient, application number, "
"and marketing status of the first result.", schema=Drug.model_json_schema())Seu próprio rastreamento mostra um fluxo de quatro etapas que nenhuma URL captura. Ele digitou na caixa de pesquisa e pressionou Enter, encontrou o primeiro resultado recolhido e clicou para expandir, navegou até a página de detalhes e então leu os campos:
{'drug_name': 'ACETAMINOPHEN AND IBUPROFEN', 'active_ingredient': 'ACETAMINOPHEN; IBUPROFEN',
'application_number': '214836', 'marketing_status': 'Over-the-counter'} # all 4 DOM-groundedEssas quatro etapas, no navegador:
Uma gravação real da execução, quadro a quadro. O Nova Act pesquisa “ibuprofen” no Drugs@FDA, abre o primeiro resultado e lê ANDA #214836, o mesmo número de aplicação que a execução retornou.
Executamos em diferentes medicamentos para confirmar a consistência: aspirin retornou 8-HOUR BAYER (#016030), e metformin retornou ACTOPLUS MET (#021842). Com ibuprofen, isso é 3/3, todos os campos fundamentados. É aqui que o agente justifica seu custo. O agente preenche o formulário e navega até dados públicos autoritativos, protegidos por formulário, que um Scraper não consegue alcançar. Fundamentar IA em dados públicos da web profunda é um problema real. Em um site cooperativo e bem estruturado, é confiável.
A longa cauda
A mesma abordagem cobre a longa cauda, os sites de nicho sem Scraper pré-construído. As APIs de Web Scraper da Bright Data já cobrem mais de 100 dos mais valiosos. Apontado para o BoardGameGeek, o Nova Act retornou um registro limpo de seis campos, Catan / 1995 / 3,4 jogadores / 60,120 min / avaliação 7,1 / menor preço. Você o verifica em relação ao DOM ao vivo através de nova.page, o handle do Playwright, na mesma sessão:
assert game.parsed_response["bgg_rating"] in nova.page.inner_text("body") # 7.1 -> presentDuas lições de fundamentação emergiram. Normalize antes de comparar, porque o travessão longo da página 3,4 contra o hífen do agente 3-4 é uma incompatibilidade falsa, não uma alucinação. E verifique na sessão, nunca depois, porque um preço de marketplace ao vivo foi fundamentado no momento da extração e desapareceu ao recarregar, então uma verificação de segunda passagem de dados voláteis pode estar errada. Com isso, todos os seis campos foram fundamentados. Manteve-se estável em uma execução simultânea de cinco sessões também.
O limite é sobre o terreno, não a tarefa. O Nova Act tem dificuldades em sites hostis de consumidores como eBay e booking.com: eCommerce com defesa contra bots com muros de cookies, widgets de variação personalizados e conteúdo carregado de forma lazy. Nesses sites, as ações de múltiplas etapas ficam lentas e instáveis, e cadeias pesadas atingem timeout. É confiável em sites cooperativos e estruturados: bancos de dados públicos, aplicativos internos e formulários bem construídos. É frágil nos hostis de consumidores. Mantenha as ações poucas, verifique cada campo com nova.page, faça novas tentativas e deixe a camada de dados da Bright Data lidar com os casos hostis e de alto volume.
O que o roteamento geográfico realmente muda
Nenhum navegador local faz isso sem a mesma infraestrutura de roteamento por baixo. Executamos a mesma busca de hotel em um grande site de reservas, roteado por três países adicionando -country-XX ao nome de usuário da Bright Data:
| Roteado por | Moeda | Tarifas noturnas de exemplo |
|---|---|---|
| Estados Unidos | US$ | US$30, US$128, US$171 |
| Reino Unido | £ | £30, £167, £194 |
| Alemanha | € | €40, €194, €225 |
A moeda muda claramente e os preços refletem diferenças reais de mercado, não conversão. Lemos estes três com um navegador bruto, porque a geografia é trabalho da infraestrutura, não do agente. O agente extrai qualquer mercado para o qual é apontado, o mesmo que a execução do eBay roteada pelos EUA. Isso importa para monitoramento competitivo de preços, agregação de tarifas ou qualquer caso onde você precisa ver como um cliente local vê.
O que importa para uma execução é por qual IP você sai, então verificamos cada sessão roteada. Os IPs de saída retornaram como ISPs reais de consumidores, não intervalos de datacenter: um grande provedor de cabo dos EUA, uma operadora de banda larga do Reino Unido, uma rede móvel alemã, uma operadora japonesa e um ISP regional brasileiro.
Essa é a diferença entre parecer local e ser local. A solicitação chega como um usuário residencial real naquele país. Portanto, os preços, inventário e tratamento anti-bot estão muito mais próximos do que um cliente local vê do que o que um intervalo de datacenter sinalizado recebe.
Conformidade, o problema dos 90%
É aqui que as restrições de acesso importam, o próprio problema dos 90%: a maioria das organizações de IA afirma que essas restrições estão limitando suas iniciativas de IA. Aqui a Bright Data atua como guarda-rails. Apontado para um site de metabusca de voos, o agente foi recusado:
Page.navigate: Requested URL (kayak.com/flights/...) is restricted in accordance
with robots.txt. Ask your account manager to get full access (brob)Um navegador local bruto raspou o mesmo site sem problemas momentos antes. A Bright Data recusou. Recusar é o comportamento mais capaz, não o mais fraco. A Bright Data aplica robots.txt e protege alvos sensíveis por trás de verificações KYC por padrão, a abordagem que uma equipe jurídica empresarial pode aprovar.
Para a maioria dos alvos empresariais você está bem. Em nossas verificações, booking.com, Expedia, Hotels.com, Airbnb, eBay, Best Buy e Tripadvisor todos passaram. Os restritos são uma conversa com o Gerente de conta, não uma solução alternativa. A infraestrutura lida com a conformidade do lado do acesso para que seu código não precise.
O orçamento de custo e confiabilidade
Um revisor de aquisições faz duas perguntas: qual é a confiabilidade e quanto custa.
Confiabilidade
A confiabilidade tem uma alavanca principal e um teto fixo. A alavanca é a correção do viewport. Antes de configurá-la, cerca de metade de todas as execuções falhavam em InvalidScreenResolution, e esse único bug era a maior parte do que parecia ser um agente instável.
Após a correção, medimos em um site real, não em uma sandbox. Uma leitura simultânea de cinco sessões no eBay retornou 5/5, cada valor confirmado no DOM ao vivo através de nova.page, em 47s contra cerca de 198s sequencial, 4,2×. Cada sessão rodou em um IP fresco da Bright Data, o que evita concentrar solicitações em um único IP.
Isso não é escalonamento linear gratuito. Aumentamos para 12 simultâneos e 8 de 12 retornaram limpos. Esse é o teto de simultaneidade nos planos gratuito e pay-as-you-go, não o agente quebrando. Volume empresarial real significa aumentar o limite de simultaneidade da zona e orçar novas tentativas, não assumir que cinco sessões escalam para cinco mil sem custo.
O ganho com simultaneidade é real, mas não linear. Além do teto de simultaneidade do plano, 8 de 12 leituras simultâneas retornaram limpas.
Uma única ação leve (ordenar, depois ler) precisou de novas tentativas ocasionais, e as falhas restantes foram StartFaileds transitórios no início da sessão. Portanto, divida o trabalho em etapas idempotentes pequenas, envolva-as em novas tentativas, orçe cerca de 1,2 a 1,5× e verifique cada saída com nova.page.
O limite restante é o terreno. No lado estruturado permanece confiável. Três consultas no Drugs@FDA executaram o mesmo fluxo: preencher, enviar, clicar para expandir, navegar, extrair. Todas as três retornaram 3/3, todos os campos fundamentados, embora lentas com cerca de 50 a 90 segundos cada. No lado do consumidor, as cadeias de múltiplas etapas ainda ficam lentas e atingem timeout.
Os números de confiabilidade em uma visão:
| Cenário | Resultado | O que significa |
|---|---|---|
| Antes da correção do viewport | ~metade das execuções falhou | InvalidScreenResolution, a falha dominante |
| Leitura simultânea de 5 sessões, pós-correção (eBay) | 5/5 fundamentados | 47s vs ~198s sequencial, 4,2×, IP fresco por sessão |
| Aumentado para 12 simultâneos (bruto) | 8/12 | o teto de simultaneidade do pay-as-you-go, não o agente |
| Ação leve única (ordenar, depois ler) | nova tentativa ocasional | as falhas são StartFaileds com nova tentativa |
| Formulário FDA de múltiplas etapas, 3 medicamentos | 3/3 fundamentados | site cooperativo, mas lento com ~50,90s cada |
Custo
O custo de largura de banda é mensurável, e o custo do modelo é a questão aberta. A Browser API cobra por GB, cerca de $8/GB no pay-as-you-go (todos os preços aqui são de meados de 2026). Medimos o peso real das páginas através dela:
| Tipo de página | Peso | Browser API @ $8/GB |
|---|---|---|
| Página pesada de consumidor (busca no eBay) | ~3,4 MB | ~$0,027/página → ~$27 / 1.000 páginas |
| Página leve (produto sandbox) | ~0,2 MB | ~$0,0016/página → ~$1,60 / 1.000 páginas |
Adicione o multiplicador de novas tentativas, depois adicione o custo de inferência do Nova Act, que não tem preço público hoje. O plano gratuito mede quanto você coleta, e as execuções em produção passam pela AWS sem preço publicado. Portanto, o orçamento se resume a duas linhas. A largura de banda da Browser API é um item de linha conhecido e previsível. A inferência do agente é o custo que você deve confirmar com a AWS antes de escalar.
Mover 3,4 MB para extrair três campos também é a razão pela qual, para trabalho em massa, você não usa um navegador. A camada de dados cobra por solicitação em vez de por gigabyte. A API SERP e o Web Unlocker custam cerca de $1,50 por 1.000, contra ~$27 por 1.000 páginas pesadas pelo navegador.
Quando usar o agente e quando usar a camada de dados
A Bright Data oferece Web MCP e APIs de Web Scraper para que você não precise usar um navegador para tudo. A linha divisória é a complexidade da decisão:
- Extração fixa com schema conhecido, como preço e estoque para 100.000 SKUs. Não use um agente. Uma API de Web Scraper retorna apenas o registro, sem página de 3,4 MB, sem custo de inferência e com muito menos falhas transitórias. É mais barato e mais confiável.
- Raciocínio que o Scraping de dados não consegue capturar: navegação de múltiplas etapas, lógica condicional (por exemplo, a tarifa reembolsável mais barata que atende às suas restrições), envio de formulário, QA de aplicativo web ou um portal desconhecido sem Scraper pré-construído. É aí que o Nova Act e a Browser API justificam seu custo.
A regra: se você consegue expressá-lo como um Scraping de dados fixo ou uma chamada de API, faça isso. Em sistemas reais os dois se compõem. O Nova Act conduz o fluxo de decisões e passa a recuperação em massa para as APIs estruturadas da Bright Data.
A camada de dados na prática
“Use a camada de dados para massa” é o conselho usual. Aqui está, executado na mesma conta Bright Data, três chamadas, sem navegador, sem agente.
Busca estruturada em uma chamada (API SERP), resultados de pesquisa recém-analisados para fundamentar uma IA, retornados como JSON:
requests.post("https://api.brightdata.com/request",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json={"zone": "serp_api2", "format": "raw", # gl/hl pin the locale so results are stable
"url": "https://www.google.com/search?q=amazon+nova+act+sdk&brd_json=1&gl=us&hl=en"})9 organic results → 1. github.com/aws/nova-act · 2. nova.amazon.com/act · 3. docs.aws.amazon.com/nova-act …Qualquer URL para markdown limpo pronto para LLM (Web Unlocker), o mesmo registro de medicamento da FDA que nosso agente alcançou preenchendo um formulário, buscado diretamente:
json={"zone": "web_unlocker", "format": "raw", "data_format": "markdown",
"url": "https://www.accessdata.fda.gov/.../ApplNo=214836"}→ 8,4 KB de markdown limpo, uma chamada, sem navegador, sem tratamento de CAPTCHA, sem Parsing.Uma fonte conhecida para apenas o registro estruturado (API de Web Scraper), acione um coletor pré-construído e obtenha campos limpos, nunca a página. Executamos o Scraper do Crunchbase para uma empresa:
requests.post("https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l1vijqt9jfj7olije",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json=[{"url": "https://www.crunchbase.com/organization/anthropic"}]) # -> snapshot_id, then poll→ 89 campos estruturados (funcionários, sede, ranking CB, status, financiamento…),
prontos em ~70s, sem navegador, sem agente, sem página de 3,4 MB, sem Parsing.O contraste é a arquitetura. O agente foi a ferramenta certa aqui porque você precisava agir para alcançar os dados. Nenhuma URL existia, então ele pesquisou o formulário e navegou até a aplicação 214836. Uma vez que uma URL existe, ou você precisa de resultados de pesquisa ou registros em massa com schema conhecido, você não usa um navegador. Você chama a camada de dados. É mais determinístico, mais rápido e mais barato, com muito menos do orçamento de confiabilidade do agente. O Nova Act descobre e age. A camada de dados da Bright Data recupera em escala.
O agente chama as ferramentas da Bright Data diretamente
As integrações até agora são orquestradas manualmente. Chamamos SERP e Web Unlocker, depois entregamos ao agente um navegador. Há uma integração mais estreita. Você fornece ao Nova Act o servidor Web MCP da Bright Data como ferramentas, e o próprio agente decide quando pesquisar, raspar ou descobrir. O Nova Act roda no framework Strands da AWS, então aceita ferramentas MCP diretamente:
from strands.tools.mcp import MCPClient
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
bd_mcp = MCPClient(lambda: stdio_client(StdioServerParameters(
command="npx", args=["-y", "@brightdata/mcp"], env={"API_TOKEN": BRIGHTDATA_TOKEN})))
with bd_mcp:
tools = bd_mcp.list_tools_sync() # search_engine, scrape_as_markdown, discover, batch…
with NovaAct(starting_page="https://example.com", tools=tools,
cdp_endpoint_url=endpoint, cdp_headers=headers) as nova:
nova.act_get("Use the search_engine tool to find 'Amazon Nova Act SDK'; "
"return the top result's URL.", schema=Out.model_json_schema())Executamos e o próprio rastreamento do agente mostra. “A chamada de ferramenta foi bem-sucedida e retornou informações da pesquisa. O principal resultado orgânico é ‘https://github.com/aws/nova-act’…” e retornou {'top_result_url': 'https://github.com/aws/nova-act'}. O agente escolheu a ferramenta search_engine da Bright Data por conta própria, a Bright Data executou a pesquisa e o agente usou o resultado. Levou uma chamada act, cerca de 32s, sem Scraping de dados de uma página de pesquisa em que um agente de navegador provavelmente seria bloqueado de qualquer forma.
Essa é a diferença entre usar duas ferramentas juntas e um agente que chama o outro por conta própria. O agente obtém cinco ferramentas diretamente nesta execução: search_engine, scrape_as_markdown, search_engine_batch, scrape_batch e discover. Esse é um caminho limpo e em conformidade para os trabalhos que um agente de navegador faz pior: busca e busca em massa.
O pipeline combinado, amplitude e profundidade
Cada componente até agora funciona sozinho. Combinados, eles constroem um registro de inteligência fundamentado e estruturado sobre um tópico. Você extrai amplitude da web aberta e profundidade de uma fonte autoritativa protegida por formulário. Executamos em medicamentos GLP-1, uma categoria farmacêutica de alto perfil:
# 1. BREADTH , Bright Data SERP API discovers authoritative sources (no browser)
sources = serp_api("Ozempic semaglutide")[:3]
# 2. FETCH , Bright Data Web Unlocker pulls the top source as markdown (no browser)
context = web_unlocker(sources[0])
# 3. DEPTH , Nova Act fills the Drugs@FDA form for the authoritative record (agent)
fda = nova_act_fda("semaglutide") # verified against the live DOMSaída real, de ponta a ponta:
{
"web_sources": ["ozempic.com", "mayoclinic.org/…semaglutide…", "accessdata.fda.gov/…/209637lbl.pdf"],
"web_context_chars": 59270,
"fda_authoritative": {"drug_name": "OZEMPIC", "active_ingredient": "SEMAGLUTIDE",
"application_number": "209637", "marketing_status": "Discontinued"},
"fda_grounded": true
}Cada metade fez algo que a outra não conseguia. A camada de dados pesquisou a web aberta em duas chamadas de API e retornou três fontes autoritativas e 59 KB de contexto limpo pronto para LLM, sem navegador e sem agente. O agente foi onde a camada de dados não conseguia alcançar por conta própria. Ele preencheu o formulário de pesquisa da FDA e navegou até o registro regulatório autoritativo, aplicação 209637, status Discontinued para aquela linha de produto, dados por trás de um formulário sem URL.
E os dois se confirmam mutuamente. A camada de dados retornou independentemente o rótulo FDA 209637lbl.pdf para o mesmo número de aplicação que o agente alcançou agindo. Amplitude confirma profundidade.
Esta execução também mostra uma falha para a qual você planeja. A etapa FDA do agente falhou no nome da marca “Ozempic”, com ActAgentFailed três vezes, e teve sucesso no ingrediente ativo “semaglutide”. Esse é o custo de confiabilidade do terreno. É por isso que você verifica com fda_grounded: true e orça novas tentativas.
O mesmo pipeline, um setor diferente
Isso funciona além de farmacêuticos, e verificamos. Executamos o pipeline idêntico em um setor diferente, conformidade financeira. O SERP encontrou a presença web da empresa, seu próprio site e um perfil de dados financeiros. O agente navegou no BrokerCheck da FINRA (um aplicativo Angular mais difícil do que o formulário da FDA) até o registro regulatório autoritativo de um broker-dealer: nome da empresa, número CRD, regulador e contagem de divulgações. Fundamentou em uma nova tentativa.
De farma a finanças, o mesmo pipeline funcionou sem alterações de código além da consulta e do schema. Deve se estender da mesma forma para preços competitivos, Pesquisa de mercado e monitoramento de segurança de produtos. A camada de dados lida com amplitude e escala, o agente lida com profundidade protegida e os campos do agente são fundamentados em relação à página ao vivo.
De um registro a um mercado
Também escala de um registro para um mercado. Executamos o pipeline idêntico no mercado de medicamentos GLP-1 e obtivemos um conjunto de dados competitivo estruturado. A camada de dados lidou com a amplitude enquanto o agente forneceu o registro autoritativo da FDA de cada medicamento:
| Ingrediente ativo | Marca FDA | Aplicação # | Status | Principal fonte (SERP) |
|---|---|---|---|---|
| semaglutide | OZEMPIC | 209637 | Prescription | drugs.com |
| tirzepatide | MOUNJARO | 215866 | Prescription | ncbi.nlm.nih.gov |
| liraglutide | LIRAGLUTIDE | 212552 | Prescription | drugs.com |
A execução de mercado até revelou uma discrepância ao vivo. A aplicação 209637 leu Discontinued na execução de registro único acima e Prescription nesta tabela. Uma aplicação FDA pode conter vários registros de produtos com status diferentes, então cada leitura do agente é um snapshot de uma linha. É exatamente por isso que você verifica cada leitura.
O reCAPTCHA não roteirizado
Um momento que não havíamos roteirizado defendeu a arquitetura por conta própria. Em duas das três consultas, o site da FDA apresentou um reCAPTCHA ao agente.
O reCAPTCHA real que o agente encontrou no Drugs@FDA, capturado durante a execução. O guarda-rail do Nova Act recusou-se a resolvê-lo. A sessão ainda alcançou o registro, porque roda na Browser API da Bright Data.
O guarda-rail do Nova Act recusou-se a tratá-lo como um quebra-cabeça a resolver. De seu rastreamento, palavra por palavra, “I should not impersonate a human, or mis-direct being one by solving captchas or any other challenge.” Esse é o comportamento que você quer de um agente autônomo.
Ele ainda conseguiu passar, porque a sessão roda na Browser API da Bright Data. Um navegador local simples nem conseguia carregar o site da FDA. Esse navegador atingiu timeout duas vezes em 90 segundos, embora tenha alcançado example.com normalmente na mesma execução. Não alcançou nem o CAPTCHA nem os dados. A sessão Bright Data alcançou o registro.
Portanto, a divisão de trabalho é real e verificada. O agente não resolve CAPTCHAs. Não vai, e não deve. A camada de dados não consegue navegar pelo formulário. Apenas o agente na Bright Data termina o trabalho.
O CAPTCHA é intermitente, e uma execução bruta posterior não teve nenhum. Essas duas consultas do agente com CAPTCHA levaram cerca de 1m50s e 2m37s de fricção real. O conjunto de dados tem três linhas, mas o padrão se aplica a um mercado inteiro.
Isso é Nova Act e Bright Data combinados. Nenhuma ferramenta resolve sozinha.
Limitações
- O Nova Act ainda é inicial. Em meados de 2026 é uma prévia de pesquisa, apenas em inglês, com um plano gratuito que limita suas interações. Ele imprime “Amazon collects data on interactions on this version” em cada execução. A produção é acoplada à AWS, com IAM, S3 e Bedrock AgentCore. Confirme os termos e preços do plano de produção com a AWS antes de construir qualquer coisa crítica nele.
- O agente é frágil em sites de consumidores com muitos popups. No booking.com, o
ActActuationErrorfoi o agente lutando com a página, não a Bright Data falhando em servi-la. Prefira URLs de resultado direto, descarte popups explicitamente, confie no orçamento de novas tentativas ou delegue para a camada de dados. - A conformidade tem dois lados. É o guarda-rail que você quer, mas alvos restritos significam uma etapa de Gerente de conta ou Verificação KYC, então planeje o prazo. E a legalidade de Scraping de dados para IA é contestada em 2026, com decisões importantes sobre dados públicos, o AI Act da UE e processos de direitos autorais ainda em andamento. Dados públicos não são permissão automática, então mantenha sua equipe jurídica envolvida.
- A detecção é uma corrida armamentista. O fingerprinting de agentes e o pay-per-crawl continuam escalando. Ficar à frente é um trabalho contínuo, que é exatamente por que a camada é uma dependência gerenciada em vez de uma correção única.
- Um navegador autônomo é uma superfície de ataque. Páginas podem conter injeção de prompt que direciona o agente, e a própria documentação do Nova Act o sinaliza. Limite-o. Use listas de permissão e bloqueio de URLs e mantenha-o longe de páginas que não precisa. Insira entradas sensíveis como credenciais e pagamento diretamente pelo Playwright com
nova.page, em vez de deixar o modelo digitá-las.
Próximos passos
Troque o Nova Act pelo agente do próximo ano e a divisão ainda se aplica: a camada de baixo é a parte durável. Então comece classificando o trabalho, não a ferramenta. Se o alvo tem uma URL estável ou um coletor pré-construído, envie-o para a camada de dados e pule o navegador. Reserve o Nova Act para o que precisa de uma ação: um formulário para preencher, um caminho de múltiplas etapas, um portal sem Scraper por trás.
Para qualquer coisa que você planeja executar mais de uma vez, configure isso desde a primeira sessão:
- Mova as credenciais inline da zona para um header
Authorization: Basice adicione seu IP à lista de permissão da zona. Pule qualquer um e você recebeInvalid URLou um corpo vazio com o motivo nos headers de resposta. - Force um viewport de 1600×900 na página conectada e crie
logs_directoryantes de iniciar a execução. - Fundamente cada campo extraído em relação a
nova.pagena mesma sessão e orçe 1,2 a 1,5× para novas tentativas.
Quando uma zona parar de acompanhar, aumente seu limite de simultaneidade antes de culpar o agente. Mova a recuperação em massa para a API SERP, Web Unlocker ou uma API de Web Scraper. A Browser API e o Web MCP ambos têm um plano gratuito, então você pode testar a divisão antes de comprometer. Alvos restritos são uma conversa com o Gerente de conta, não uma solução alternativa.
O script executável para cada demonstração aqui está no repositório complementar. Clone-o, aponte-o para seu próprio alvo e veja qual metade da divisão seu trabalho realmente precisa.
Perguntas frequentes
O que é o Amazon Nova Act?
O Amazon Nova Act é um SDK da AWS para construir agentes de navegador em Python. Você divide um fluxo de trabalho em comandos pequenos e confiáveis: act() para ações e act_get() para extração tipada. Ele controla um Chromium real através do Playwright. Em meados de 2026 é uma prévia de pesquisa.
O Nova Act funciona com a Bright Data?
Sim, através do Chrome DevTools Protocol. O Nova Act se conecta à Browser API da Bright Data através de cdp_endpoint_url e cdp_headers. O detalhe de configuração é que o Playwright moderno rejeita a URL wss:// com credenciais inline, então mova as credenciais para um header Authorization: Basic e force um viewport de 1600×900.
Posso usar um Proxy com o Nova Act?
Não com o parâmetro nativo proxy ao conectar por CDP. O Nova Act lança ValidationFailed com a mensagem Cannot specify a proxy when connecting over CDP. Conecte-se à Browser API da Bright Data por CDP, onde desbloqueio, roteamento geográfico e tratamento de CAPTCHA acontecem no lado da Bright Data.
O Nova Act está pronto para produção?
Em meados de 2026 é uma prévia de pesquisa, apenas em inglês, com um plano gratuito medido. A produção roda na AWS com IAM, S3 e Bedrock AgentCore. Em nossas execuções foi confiável em sites cooperativos e estruturados e frágil em sites hostis de consumidores. Confirme os termos e preços de produção com a AWS antes de construir nele.
Quanto custa executar um agente de navegador dessa forma?
A Browser API da Bright Data cobra cerca de $8/GB no pay-as-you-go (meados de 2026). Uma página pesada moveu cerca de 3,4 MB: aproximadamente $27 por 1.000 páginas antes de novas tentativas. Orçe 1,2 a 1,5× a mais. Uma página leve fica mais próxima de $1,60 por 1.000. A inferência do Nova Act não tem preço público, então para trabalho em massa use a camada de dados, não um navegador.
Por que não usar meu próprio navegador headless e proxies?
Os modos de falha medidos são apenas metade da resposta. Usar um navegador é pesado, frágil em atuação de múltiplas etapas e não-determinístico. Mas a metade mais difícil de executar por conta própria é a geografia, conformidade e escala: uma corrida armamentista que nunca termina. Uma camada de infraestrutura cuida disso para que sua engenharia não precise.
Quando devo usar o agente, não a camada de dados?
Se o trabalho é uma extração fixa com schema conhecido, use uma API de Web Scraper, que retorna o registro sem página e sem custo de inferência. Se precisa de raciocínio que um Scraping de dados não consegue capturar (navegação de múltiplas etapas, envio de formulário, lógica condicional), use o agente. Em sistemas reais os dois se compõem.
