O que os agentes de codificação precisam de uma camada de dados da web real

Você pede a um agente de codificação para comparar três páginas de preços, verificar um changelog ou puxar datas de conformidade atuais. Ele retorna algo plausível, mas uma fonte estava desatualizada, outra página foi renderizada em JavaScript e a terceira foi resumida de forma tão agressiva que a importante ressalva desapareceu.

Isso geralmente não é um problema de modelo. É um problema de acesso a dados.

Ferramentas web integradas são ferramentas de consulta

A maioria dos harnesses de agentes possui alguma forma de acesso à web agora. Claude Code tem WebSearch e WebFetch. Codex pode funcionar com pesquisa web em cache, ao vivo ou desativada. Cursor e outros agentes de IDE expõem primitivas semelhantes.

Essas ferramentas ajudam, mas não são a mesma coisa que uma camada de dados da web.

A pesquisa geralmente retorna títulos, URLs e talvez trechos curtos. Isso é suficiente para decidir o que buscar a seguir, mas não é suficiente para raciocinar sobre a fonte. As ferramentas de busca frequentemente retornam um resumo gerado por um modelo em vez do conteúdo original da página. Isso mantém o uso de tokens baixo, mas também significa que o agente raciocina sobre a interpretação de outro modelo.

Os modos de falha comuns são familiares:

Resultado da pesquisa: "Preços | Exemplo SaaS"
Conclusão do agente: "O plano Pro custa $49/mês"
Página real: preço alterado para $59/mês por trás da renderização do lado do cliente
HTML buscado: <div id="root"></div>

Ou isso:

HTTP 403
<title>Aguarde um momento...</title>
Página de desafio do Cloudflare retornada em vez do conteúdo do artigo

Se seu agente não consegue distinguir entre uma página real e uma página de desafio, muitas vezes continuará mesmo assim.

Trate o acesso à web como um pequeno pipeline de dados

Uma camada de dados da web útil tem três trabalhos separados:

1. Pesquisar e retornar texto suficiente para classificar fontes.
2. Buscar a página real, incluindo conteúdo renderizado em JavaScript quando necessário.
3. Converter conteúdo de página bagunçado em dados tipados que o agente pode validar.

Gosto de tornar essa fronteira explícita:

type SearchResult = {
  url: string;
  title: string;
  snippet: string;
  date?: string;
};

type FetchResult = {
  url: string;
  status: "completo" | "falhou" | "tempo limite";
  markdown?: string;
  html?: string;
  error?: string;
};

interface WebDataLayer {
  search(query: string, limit: number): Promise<SearchResult[]>;
  fetchPage(url: string, opts?: { renderJs?: boolean }): Promise<FetchResult>;
  extract<T>(input: string, schemaName: string): Promise<T>;
}

Essa estrutura é importante porque dá ao agente estados concretos para lidar. Uma busca falhada não é a mesma coisa que uma página vazia. Uma página renderizada não é a mesma coisa que HTML bruto. Um trecho não é conteúdo fonte.

O conector remoto MCP do Anakin segue essa divisão com pesquisa, raspagem, rastreamento e ações estruturadas do site, mas o padrão é útil mesmo que você construa as ferramentas você mesmo.

Raspagem assíncrona é geralmente o padrão certo

Buscar uma página HTML estática pode ser síncrono. Renderizar um SPA, esperar por chamadas de rede, rotacionar proxies ou tentar novamente após um desafio de bot não deve bloquear uma solicitação de agente para sempre.

Uma melhor API de raspagem retorna um ID de trabalho, então permite que o chamador faça polling:

curl -X POST https://example.internal/scrape \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com/pricing","renderJs":true}'

# 202 Aceito
# {"jobId":"job_abc123","status":"pendente"}

Então seu wrapper do lado do agente lida com conclusão, falha e tempo limite explicitamente:

async function waitForScrape(jobId: string, timeoutMs = 60_000) {
  const started = Date.now();

  while (Date.now() - started < timeoutMs) {
    const res = await fetch(`https://e