Série Aceleradora: Construindo um Web Scraper Resiliente com LangGraph e TrueFoundry

A equipe de vendas está em pânico – há uma grande conferência de saúde na próxima semana. O site do evento lista 200 palestrantes – médicos, executivos e pesquisadores – espalhados por uma dúzia de subpáginas paginadas. Para construir uma lista de leads, alguém precisa abrir o site, clicar em um nome, copiar os detalhes para uma planilha, abrir uma nova aba, procurar essa pessoa no LinkedIn, copiar a URL do perfil e colá-la de volta.

Eles precisam fazer isso 200 vezes.

Para engenheiros, essa solicitação geralmente resulta em um script Python rápido usando Selenium ou BeautifulSoup. Você inspeciona o código-fonte da página, encontra a div com a classe speaker-name e extrai o texto. Funciona perfeitamente por cerca de uma semana. Então o site atualiza seu framework de frontend, as classes CSS mudam e o script falha.

Construímos o Profile Crawler acelerador para parar este ciclo. É um agente autônomo que navega em sites e extrai dados com base no que a página diz, não em como o HTML está estruturado.

Veja como arquitetamos a solução usando LangGraph para orquestração, Playwright para interação e TrueFoundry para gerenciar a infraestrutura.

A Mudança: De Seletores DOM para Extração Semântica

A principal razão pela qual os scripts de scraping falham é a sua dependência do Document Object Model (DOM). Se você instruir um script a procurar por div.content-wrapper > h2.title, ele falhará no momento em que um desenvolvedor mudar o nome de uma classe.

Adotamos uma abordagem agêntica. Não dizemos ao bot onde os dados estão localizados pixel a pixel. Em vez disso, alimentamos o HTML renderizado (convertido para Markdown) a um LLM. O modelo lê o texto como um humano faria. Ele entende que uma seção rotulada como "Keynote Speakers" contém os dados que queremos, independentemente das tags subjacentes.

• Abordagem Antiga (Frágil): Seletores CSS codificados que falham com atualizações de UI.
• Nova Abordagem (Resiliente): Compreensão semântica que se adapta a mudanças de layout.

Análise Aprofundada da Arquitetura

Precisávamos de um sistema capaz de tomar decisões, não apenas um script linear. A aplicação precisa decidir: Esta entrada é um URL ou apenas um nome de empresa? Encontramos um captcha? Esta página é uma lista de pessoas ou uma única biografia?

Escolhemos o LangGraph para modelar este fluxo de trabalho como uma máquina de estados, especialmente onde Langflow vs LangGraph decisões favorecem a orquestração com estado.

O Fluxo Lógico

O sistema opera em um loop em vez de uma linha reta:

1. Roteador de Entrada: O sistema verifica se o usuário forneceu um URL direto ou apenas um nome de empresa. Se for um nome, ele usa uma ferramenta de busca para encontrar o domínio correto primeiro.
2. Navegação Furtiva: Usamos uma instância modificada do Playwright para carregar a página. Ele lida com banners de consentimento de cookies e imagens de carregamento lento automaticamente.
3. Filtragem Vetorial (A Otimização): Uma única página de conferência pode ter 200 links de navegação. Alimentar todos eles para uma janela de contexto de LLM é lento e caro. Usamos FastEmbed para incorporar o texto do link e consultar uma instância local do Qdrant . Isso filtra a lista para os 10 principais links relevantes para "Equipe" ou "Palestrantes".
4. Extração: O LLM analisa o conteúdo filtrado e extrai entidades estruturadas (Nome, Cargo, Empresa).
5. Enriquecimento: Finalmente, percorremos os nomes extraídos e usamos uma ferramenta de busca (Tavily) para encontrar seus perfis específicos do LinkedIn.

Aqui está a arquitetura do sistema:

‍

Infraestrutura e Integração TrueFoundry

Executar navegadores headless e agentes LLM em produção cria dores de cabeça operacionais: vazamentos de memória do Chromium, limites de taxa nas APIs LLM e a necessidade de isolamento de processos.

Nós implementamos isso no TrueFoundry para lidar com essas restrições específicas.

1. O Gateway de IA (Observabilidade e Cache)

Esta aplicação faz uso intensivo de LLMs para decisões de navegação. Sem governança, os custos aumentam rapidamente. Nós roteamos todas as chamadas de modelo através do TrueFoundry AI Gateway.

• Cache: Se o agente raspar o mesmo site duas vezes, o Gateway serve respostas LLM em cache para as etapas de extração. Isso reduz significativamente a latência e o custo.
• Limitação de Taxa: Definimos limites rigorosos por usuário para evitar o esgotamento da cota da API durante grandes trabalhos em lote.
• Failover: Se o OpenAI tiver tempo de inatividade, o Gateway redireciona automaticamente as solicitações para o Anthropic ou Azure OpenAI sem falhar na varredura.

2. Protocolo de Contexto do Modelo (MCP)

Estruturamos a aplicação usando o Protocolo de Contexto do Modelo (MCP). O "Crawler" não é apenas uma função Python; é um Servidor MCP. Isso nos permite isolar o ambiente do navegador. Se o navegador travar (o que acontece frequentemente com sites com muito JavaScript), isso não derruba a lógica principal da aplicação.

Diagrama de Infraestrutura

Comparação: Script vs. Agente

Fizemos um benchmark da abordagem padrão de script Python em comparação com esta arquitetura.

Tratamento de Casos de Borda

Construir o caminho feliz é fácil. Torná-lo confiável exigiu a resolução de três problemas de engenharia específicos:

1. Dados Duplicados: Perfis frequentemente aparecem em várias páginas (por exemplo, tanto em "Liderança" quanto em "Sobre Nós"). Adicionamos um Nó de Deduplicação no final do grafo. Ele passa a lista completa para um LLM menor e mais barato para mesclar registros com base na similaridade de nomes antes do enriquecimento.
2. Detecção Anti-Bot: O Playwright padrão é facilmente detectado por WAFs modernos. Implementamos o undetected-playwright dentro do contêiner Docker, que modifica a impressão digital do navegador (objeto Navigator, fornecedor WebGL) para parecer um dispositivo de usuário padrão.
3. Limites de Token: Páginas grandes com políticas de privacidade e rodapés desperdiçam tokens. Usamos fragmentação baseada em cabeçalho para dividir o markdown. O LLM processa apenas os fragmentos relevantes para "Equipe" ou "Palestrantes", descartando o restante.

Conclusão

Esta arquitetura resolve a "Última Milha" da aquisição de dados, substituindo scripts frágeis por agentes adaptativos. Ao executá-lo no TrueFoundry, garantimos que o sistema seja observável, com custos controlados e escalável.

Você pode implantar esta arquitetura exata -- incluindo a configuração do Gateway e agentes Dockerizados -- da biblioteca de aplicativos TrueFoundry hoje mesmo.

‍