Estudo de caso: criando um crawler de carreiras com apoio do navegador para o Beyond Tabs
O Beyond Tabs não tenta indexar todas as vagas da internet.
Ele é intencionalmente mais estreito que isso: um site curado para trabalho com linguagens de programação de nicho e comunidades técnicas adjacentes. Isso torna o problema de crawling mais interessante. Um resultado útil não é apenas “esta empresa tem vagas”. É “esta fonte pode conter vagas relevantes para o tipo de pessoa que acessa o Beyond Tabs”.
O desafio atual é o pipeline de carreiras. Centenas de empresas têm portais de carreira. Algumas usam sistemas de recrutamento conhecidos. Algumas expõem uma página com marca própria sobre uma plataforma compartilhada. Algumas são sites customizados com poucos links. Algumas são agregadores que devem ser ignorados. Algumas só revelam a estrutura real depois que o JavaScript roda, um banner de consentimento é fechado, uma verificação de idade é vencida ou um redirecionamento específico por país termina.
Esse é o tipo de trabalho para o qual o Guida foi criado.
O problema não era apenas raspar dados
Se todas as empresas usassem o mesmo ATS, a solução seria direta. Detectar a plataforma, chamar a API dela, normalizar os resultados e seguir em frente.
A web real não é assim.
Em uma rodada de triagem, um relatório de carreiras continha centenas de portais divididos em categorias amplas: cobertura de ATS conhecidos, fluxos dedicados por empresa, sites genéricos desconhecidos e agregadores a ignorar. O grupo “genérico desconhecido” era o incômodo. Ele continha desde pequenas páginas estáticas de carreira até plataformas globais de recrutamento empresarial escondidas atrás de URLs com marca própria.
Uma URL sozinha não bastava. Alguns exemplos anonimizados do trabalho de triagem:
- Uma marca de consumo parecia ter uma URL própria de carreiras, mas depois de uma verificação de idade renderizava um quadro SuccessFactors/jobs2web.
- Uma empresa de tecnologia industrial renderizava um site de carreiras Oracle HCM sob um domínio de carreiras com marca própria.
- Uma organização de pesquisa mostrava uma página corporativa bem acabada, mas os links de vagas iam para o Lever.
- Uma empresa de inteligência de mercado incorporava um widget de vagas do BambooHR.
- Uma empresa de trading de energia listava vagas na própria página, mas os links de detalhe iam para o HR-ON.
- Uma grande empresa expunha uma busca de carreiras customizada com milhares de resultados e páginas de detalhe específicas por produto.
Essas distinções importam porque definem que tipo de crawler deve ser escrito. Uma plataforma compartilhada deve virar infraestrutura reutilizável. Um site customizado de primeira parte precisa de um worker específico da empresa. Um agregador deve ser ignorado. Um problema nos dados de origem deve ser corrigido antes de alguém escrever código.
Por que o WebView2 mudou o fluxo de trabalho
O atalho tentador é classificar tudo com solicitações HTTP e heurísticas de URL.
Isso teria sido mais rápido. Também teria errado com frequência suficiente para desperdiçar tempo depois.
O Guida usa o WebView2 como superfície de automação, então o agente e o usuário inspecionam a mesma realidade do navegador. As páginas são renderizadas com um motor de navegador normal. O JavaScript roda. Banners de cookies aparecem. Redirecionamentos acontecem. O usuário pode permitir domínios conforme necessário. O agente pode inspecionar o DOM renderizado, os links visíveis, scripts e a URL final da guia ativa em vez de adivinhar a partir do HTML bruto.
Neste estudo de caso, o ciclo de trabalho se tornou:
- Começar pelo relatório de lacunas do crawler.
- Escolher os próximos portais não classificados no armazenamento do espaço de trabalho.
- Reutilizar quatro guias do navegador.
- Aplicar layout em grade e viewports Full HD.
- Navegar cada guia até uma página real de carreiras.
- Inspecionar conteúdo renderizado, links, scripts, iframes e indícios de plataforma.
- Armazenar uma constatação estruturada indexada pela chave do portal.
- Continuar com o próximo lote.
O ponto não era autonomia total. O ponto era automação supervisionada. O usuário podia ver exatamente quais páginas estavam abertas, onde a navegação travava e se o agente estava classificando a coisa certa.
O armazenamento virou a memória de trabalho
A primeira versão das notas de triagem ficava em arquivos de texto. Isso não durou.
Assim que o trabalho passou a abranger centenas de portais e várias sessões, as notas precisaram virar estado consultável. O armazenamento do espaço de trabalho do Guida virou a memória de trabalho do processo.
O relatório do crawler foi importado para uma coleção indexada por um identificador estável de portal. As constatações apoiadas pelo navegador foram armazenadas em uma coleção separada, usando o mesmo identificador e um esquema consistente. Isso facilitou responder:
- Quais portais ainda não foram triados?
- Quais são plataformas compartilhadas?
- Quais precisam de crawlers customizados?
- Quais constatações vieram de evidências do navegador ativo?
- O que o agente viu quando tomou a decisão?
Isso mudou o caráter do trabalho. Em vez de pedir ao agente para lembrar onde parou, o processo podia ser retomado a partir dos dados.
O registro importa porque crawling é trabalho operacional
Crawling de carreiras não é um script de execução única. É um fluxo de trabalho.
Portais enfileiram URLs de vagas. Workers de busca visitam páginas. Workers de análise extraem e indexam anúncios. Alguns itens concluem. Alguns são ignorados porque um resultado conhecido já existe. Alguns falham temporariamente. Alguns viram dead letters. Alguns leases expiram e precisam de recuperação.
É por isso que o registro de rastreabilidade dos fluxos de trabalho se tornou importante. Um pipeline de crawler sem visibilidade operacional deixa usuários no escuro. O registro dá ao Guida um lugar para explicar o que aconteceu: execuções, itens, estados, etapas, eventos, novas tentativas, falhas e saídas vinculadas.
Essa pressão depois levou ao trabalho dedicado no Workflow Ledger Console. Para o Beyond Tabs, o usuário não deveria precisar adivinhar se o crawler terminou, travou, está tentando de novo ou quebrou silenciosamente. O aplicativo deve mostrar isso diretamente.
O que o Guida fez bem
O Guida tornou o trabalho inspecionável.
O layout em quatro painéis permitiu que o usuário acompanhasse quatro sites reais ao mesmo tempo. O painel de histórico do MCP mostrava chamadas de ferramentas. O painel Store mostrava constatações estruturadas. As guias do navegador mostravam as páginas renderizadas de fato. Essa combinação é mais útil do que um fluxo de logs headless porque o usuário pode intervir quando a web se comporta como a web.
O Guida também tornou o trabalho retomável. Depois que as constatações passaram para o armazenamento do espaço de trabalho, os lotes puderam continuar entre sessões sem depender de memória conversacional nem de notas editadas manualmente.
Mais importante: o Guida manteve o agente ancorado. O agente não classificava páginas por impressão vaga ou premissas antigas. Ele olhava para evidências renderizadas e registrava por que a classificação foi feita.
O que ainda precisa melhorar
Isso não foi sem atrito.
A navegação ainda pode informar falha mesmo quando a página realmente carregou, então o fluxo de trabalho precisa de verificações posteriores com a URL atual e o DOM. O ciclo de triagem com quatro guias também merece um controle de nível mais alto: “prepare este lote, mantenha estas guias em visualização em grade e preserve o layout” deveria ser uma operação de primeira classe, não uma sequência de chamadas de guia e layout de baixo nível.
Prompts de consentimento e listas de permissões seguem o ritmo humano, o que é correto, mas a UI precisa deixar claras as aprovações pendentes e as páginas bloqueadas. Essa lição de produto já começou a aparecer no Guida: o MCP Approval Center torna solicitações de aprovação pendentes visíveis, e os consoles dedicados de fluxo de trabalho e fila tiram a recuperação operacional de painéis laterais apertados.
Esses são problemas de produto, não razões para abandonar a abordagem. A aposta central ainda parece correta: um navegador real, estado visível, dados estruturados no espaço de trabalho e uso auditável de ferramentas de IA.
A lição
O crawler do Beyond Tabs é exatamente o tipo de problema que fica entre navegação manual e raspagem industrial.
Ele precisa de automação, mas não de automação cega. Precisa de assistência de IA, mas não de um agente invisível circulando pela web. Precisa de pipelines de dados, mas também de julgamento humano. Precisa escalar, mas só depois que as classificações forem confiáveis.
O papel do Guida é tornar esse meio-termo prático.
Para o Beyond Tabs, isso significa usar um fluxo de trabalho apoiado pelo navegador para decidir quais crawlers criar, quais plataformas compartilhadas apoiar, quais fontes ignorar e quais falhas exigem atenção. Para o Guida, é um estudo de caso real sobre por que automação de navegador visível, local e supervisionada é diferente de mais um scraper headless.
O objetivo de longo prazo é simples: usuários não devem se sentir perdidos enquanto a automação roda. Eles devem poder ver o navegador, inspecionar as evidências, confiar no estado armazenado e entender o pipeline.
Essa é a direção de produto que este estudo de caso está ajudando a validar.