Caso práctico: crear para Beyond Tabs un rastreador de portales de empleo respaldado por navegador
Beyond Tabs no intenta indexar todos los empleos de Internet.
Su alcance es intencionadamente más estrecho: un sitio curado para trabajos relacionados con lenguajes de programación de nicho y comunidades técnicas cercanas. Eso hace que el problema de rastreo sea más interesante. Un resultado útil no es simplemente “esta empresa tiene empleos”. Es “esta fuente podría contener empleos relevantes para el tipo de personas que visitan Beyond Tabs”.
El reto actual es la canalización de portales de empleo. Cientos de empresas tienen portales de empleo. Algunas usan sistemas ATS conocidos. Algunas exponen una página con marca propia sobre una plataforma compartida. Algunas son sitios personalizados con solo unos pocos enlaces. Algunas son agregadores que deben omitirse. Algunas solo revelan su estructura real después de que se ejecute JavaScript, se cierre un banner de consentimiento, se supere una comprobación de edad o termine una redirección específica de país.
Ese es el tipo de trabajo para el que se construyó Guida.
El problema no era solo extraer datos
Si todas las empresas usaran el mismo ATS, la solución sería directa. Detectar la plataforma, llamar a su API, normalizar los resultados y seguir adelante.
La web real no funciona así.
En una pasada de triage, un informe de portales contenía cientos de sitios divididos en categorías amplias: cobertura de ATS conocidos, flujos dedicados por empresa, sitios genéricos desconocidos y agregadores que debían ignorarse. El grupo “genérico desconocido” era el incómodo. Incluía desde pequeñas páginas estáticas de empleo hasta plataformas globales de selección ocultas detrás de URL con marca propia.
Una URL por sí sola no bastaba. Algunos ejemplos anonimizados del trabajo de triage:
- Una marca de consumo parecía tener una URL de empleo propia, pero después de una comprobación de edad renderizaba un panel SuccessFactors/jobs2web.
- Una empresa de tecnología industrial renderizaba un sitio de empleo Oracle HCM bajo un dominio de empleo con marca propia.
- Una organización de investigación mostraba una página corporativa pulida, pero los enlaces de empleo llevaban a Lever.
- Una empresa de inteligencia de mercado incrustaba un widget de empleos de BambooHR.
- Una empresa de compraventa de energía listaba empleos en su propia página, pero los enlaces de detalle llevaban a HR-ON.
- Una gran empresa exponía una búsqueda de empleo personalizada con miles de resultados y páginas de detalle específicas por producto.
Esas distinciones importan porque determinan qué tipo de rastreador se debe escribir. Una plataforma compartida debe convertirse en infraestructura reutilizable. Un sitio personalizado de primera parte necesita un proceso de trabajo específico para esa empresa. Un agregador debe ignorarse. Un problema de datos fuente debe corregirse antes de que alguien escriba código.
Por qué WebView2 cambió el flujo de trabajo
El atajo tentador es clasificarlo todo con solicitudes HTTP y heurísticas de URL.
Habría sido más rápido. También habría fallado lo bastante a menudo como para perder tiempo después.
Guida usa WebView2 como superficie de automatización, de modo que el agente y el usuario inspeccionan la misma realidad del navegador. Las páginas se renderizan con un motor de navegador normal. JavaScript se ejecuta. Aparecen banners de cookies. Las redirecciones ocurren. El usuario puede autorizar dominios según haga falta. El agente puede inspeccionar el DOM renderizado, los enlaces visibles, los scripts y la URL final desde la pestaña viva, en lugar de adivinar a partir de HTML sin procesar.
Para este caso práctico, el bucle de trabajo pasó a ser:
- Partir del informe de huecos del rastreador.
- Elegir los siguientes portales sin clasificar desde el almacén del espacio de trabajo.
- Reutilizar cuatro pestañas de navegador.
- Aplicar diseño en cuadrícula y viewports Full HD.
- Navegar cada pestaña a una página real de empleo.
- Inspeccionar contenido renderizado, enlaces, scripts, iframes e indicios de plataforma.
- Guardar un hallazgo estructurado identificado por la clave del portal.
- Continuar con el siguiente lote.
El objetivo no era autonomía total. El objetivo era automatización supervisada. El usuario podía ver exactamente qué páginas estaban abiertas, dónde se detenía la navegación y si el agente estaba clasificando lo correcto.
El almacén se convirtió en la memoria de trabajo
La primera versión de las notas de triage vivía en archivos de texto. Eso no duró.
En cuanto el trabajo abarcó cientos de portales y varias sesiones, las notas tuvieron que convertirse en estado consultable. El almacén del espacio de trabajo de Guida se convirtió en la memoria de trabajo del proceso.
El informe del rastreador se importó a una colección identificada por un ID estable de portal. Los hallazgos respaldados por navegador se guardaron en una colección separada, usando el mismo identificador y un esquema coherente. Eso facilitó responder:
- ¿Qué portales siguen sin triage?
- ¿Cuáles son plataformas compartidas?
- ¿Cuáles necesitan rastreadores personalizados?
- ¿Qué hallazgos vienen de datos de trazabilidad del navegador en vivo?
- ¿Qué vio el agente cuando tomó la decisión?
Esto cambió el carácter del trabajo. En lugar de pedir al agente que recordara dónde se había quedado, el proceso podía reanudarse desde datos.
El registro importa porque rastrear es trabajo operativo
El rastreo de portales de empleo no es un script de una sola ejecución. Es un flujo de trabajo.
Los portales encolan URL de empleo. Los procesos de captura visitan páginas. Los procesos de análisis extraen e indexan ofertas. Algunos elementos se completan. Algunos se omiten porque ya existe un resultado conocido. Algunos fallan de forma transitoria. Algunos acaban en la cola de rechazos. Algunas reservas caducan y necesitan recuperación.
Por eso el registro de trazabilidad de flujos de trabajo se volvió importante. Una canalización de rastreo sin visibilidad operativa deja al usuario adivinando. El registro da a Guida un lugar donde explicar qué ocurrió: ejecuciones, elementos, estados, fases, eventos, reintentos, fallos y resultados vinculados.
Esa presión impulsó después el trabajo dedicado en Workflow Ledger Console. Para Beyond Tabs, el usuario no debería tener que preguntarse si el rastreador terminó, se quedó bloqueado, está reintentando o se rompió en silencio. La aplicación debería mostrarlo directamente.
Lo que Guida hizo bien
Guida hizo que el trabajo fuera inspeccionable.
El diseño en cuatro paneles permitía al usuario observar cuatro sitios reales a la vez. El panel de historial MCP mostraba las llamadas a herramientas. El panel Store mostraba hallazgos estructurados. Las pestañas del navegador mostraban las páginas renderizadas reales. Esa combinación es más útil que un flujo de logs headless porque el usuario puede intervenir cuando la web se comporta como la web.
Guida también hizo que el trabajo fuera reanudable. Una vez que los hallazgos pasaron al almacén del espacio de trabajo, los lotes pudieron continuar entre sesiones sin depender de memoria conversacional ni de notas editadas manualmente.
Más importante aún, Guida mantuvo al agente anclado a hechos. El agente no clasificaba páginas por intuición ni por supuestos obsoletos. Miraba datos renderizados y escribía por qué se había tomado la clasificación.
Lo que aún necesita trabajo
Esto no estuvo libre de fricción.
La navegación todavía puede informar de un fallo aunque la página se haya cargado realmente, así que el flujo de trabajo necesita comprobaciones posteriores con la URL actual y el DOM. El bucle de triage de cuatro pestañas también merece un control de nivel superior: “prepara este lote, mantén estas pestañas en vista de cuadrícula y conserva estable el diseño” debería ser una operación de primera clase, no una secuencia de llamadas de pestaña y diseño de menor nivel.
Las solicitudes de consentimiento y los dominios autorizados avanzan al ritmo humano, y eso es correcto, pero la interfaz debe hacer visibles las autorizaciones pendientes y las páginas bloqueadas. Esa lección de producto ya empezó a aparecer en Guida: MCP Approval Center hace visibles las solicitudes de autorización pendientes, y las consolas dedicadas de flujos de trabajo y colas sacan la recuperación operativa de paneles laterales estrechos.
Son problemas de producto, no razones para abandonar el enfoque. La apuesta central sigue pareciendo correcta: un navegador real, estado visible, datos estructurados en el espacio de trabajo y uso auditable de herramientas de IA.
La lección
El rastreador de Beyond Tabs es exactamente el tipo de problema que queda entre la navegación manual y el scraping industrial.
Necesita automatización, pero no automatización ciega. Necesita ayuda de IA, pero no un agente invisible recorriendo la web. Necesita canalizaciones de datos, pero también criterio humano. Necesita escalar, pero solo después de que las clasificaciones sean fiables.
El papel de Guida es hacer práctico ese terreno intermedio.
Para Beyond Tabs, eso significa usar un flujo de trabajo respaldado por navegador para decidir qué rastreadores construir, qué plataformas compartidas soportar, qué fuentes omitir y qué fallos requieren atención. Para Guida, es un caso práctico real de por qué la automatización de navegador visible, local y supervisada es distinta de otro scraper headless.
El objetivo a largo plazo es simple: los usuarios no deberían sentirse a oscuras mientras se ejecuta la automatización. Deberían poder ver el navegador, inspeccionar los datos de trazabilidad, confiar en el estado guardado y entender la canalización.
Esa es la dirección de producto que este caso práctico está ayudando a validar.