Serie TrueFoundry Accelerator: Creación de una automatización web resiliente cuando las API no existen

‍

La brecha de API

Es un escenario conocido a las 10 de la mañana para los equipos de operaciones: es necesario automatizar un flujo de trabajo crítico (verificar el inventario de los proveedores, realizar análisis de precios competitivos o garantizar las reservas), pero la plataforma de destino no ofrece acceso programático.

Si bien vivimos en una era de conectividad, muchas plataformas de alto valor bloquean sus datos detrás de «fosos digitales». Carecen de API públicas, lo que obliga a los desarrolladores a confiar en la alternativa del web scraping. Sin embargo, el scraping tradicional es notoriamente frágil. Se basa en «selectores frágiles», es decir, rutas CSS o XPaths codificadas (por ejemplo, div.btn-primary) que se interrumpen en el momento en que un desarrollador de frontend cambia el nombre de una clase a btn-submit.

Para hacer frente a esto, construimos el Acelerador de automatización de reservas para restaurantes. Es una implementación de referencia para una nueva clase de automatización: agentes resilientes que no solo «rastrean» la web, sino que la operan.

El cambio: de los selectores a la intención semántica

La innovación principal de este acelerador es pasar del modelo de objetos del documento (DOM) al Modelo de objetos de accesibilidad (AOM).

En un script tradicional, si un botón se mueve de una barra lateral a un encabezado, la automatización falla. En este sistema de agencia, proporcionamos al motor de inferencia una instantánea del árbol de accesibilidad. Se trata de una representación semántica de la página diseñada para lectores de pantalla, en la que se eliminan las divisiones de estilo para revelar la utilidad principal de la interfaz.

Esto permite que el sistema razone basándose en la intención en lugar de en las coordenadas: «Veo un widget de calendario; haré clic en la fecha 15 porque coincide con la solicitud del usuario». Si el sitio se rediseña pero la función semántica del botón sigue siendo «Confirmar reserva», el agente se cura automáticamente y el flujo de trabajo se ejecuta correctamente.

Arquitectura: el patrón controlador-trabajador

Estructuramos la aplicación utilizando una herramienta especializada Controlador/trabajador patrón. En lugar de un guion monolítico, tenemos distintos agentes que utilizan Dramaturgo para su ejecución y LLM para la toma de decisiones.

Figura 1: Arquitectura de alto nivel

Como se muestra en el diagrama de arquitectura, el controlador de flujo de trabajo administra el estado, delegando tareas a dos componentes especializados:

1. El agente de búsqueda (Discovery): Este agente gestiona la fase de «compra» no lineal.
   
   • Construcción dinámica de URL: En lugar de hacer clic en cinco páginas de destino, construye parámetros de consulta (por ejemplo,? cuisine=italian&party_size=4) para acceder directamente a los resultados.
   • Extracción contextual: Identifica las «tarjetas» en la interfaz de usuario para extraer valoraciones, precios y franjas horarias sin necesidad de etiquetas HTML específicas.
   • Navegación adaptativa: Trata las ventanas emergentes y los banners de galletas como «obstáculos» que deben descartarse, en lugar de como errores que bloquean el guion.
2. El agente de reservas (transacción): Una vez que se selecciona un objetivo, este agente gestiona la interacción con estado y de alta precisión.
   
   • Mapeo de formas semánticas: Mapea los datos del usuario a los campos de entrada basándose en etiquetas (nombre) en lugar de identificadores arbitrarios (input #user_fname).
   • Razonamiento temporal: Navega por los selectores de hora y gestiona los estados de «entradas agotadas», con una lógica similar a la de seleccionar un intervalo a las 19:15 si el horario solicitado a las 7:00 p. m., no está disponible.

Infraestructura: TrueFoundry y el protocolo de contexto modelo (MCP)

La ejecución de estos agentes en producción requiere un plano de control sólido. Utilizamos el Plataforma TrueFoundry para administrar la infraestructura y la Protocolo de contexto modelo (MCP) para estandarizar la integración del navegador.

Figura 2: Cómo apoya TrueFoundry el ciclo de vida de las aplicaciones

• Puerta de enlace de IA de TrueFoundry: Esto proporciona la gestión unificada y la observabilidad necesarias. Podemos supervisar de forma centralizada cada «idea» que tenga el agente, registrando las instantáneas y los árboles de decisión de AOM. Fundamentalmente, impone la limitación de velocidad, garantizando que nuestros agentes actúen como buenos ciudadanos y no abrumen los servidores de destino.
• MCP y aislamiento: MCP resume las capacidades del navegador en herramientas estandarizadas. La plataforma garantiza que cada sesión de usuario se ejecute en un contenedor aislado. Esto significa que las cookies de sesión y el almacenamiento local del usuario A están separados físicamente de los del usuario B, lo que elimina el riesgo de contaminación cruzada de los datos.

Experiencia de usuario: autonomía supervisada

Para los flujos de trabajo transaccionales, implementamos un «Verificar y luego ejecutar» patrón. El agente lleva a cabo la pesada tarea del descubrimiento, pero requiere la confirmación humana antes de la ejecución final.

Paso 1: Intención y descubrimiento

El sistema acepta entradas en lenguaje natural y las normaliza en JSON estructurado (ubicación, hora, tamaño del grupo) para el agente de búsqueda.

Paso 2: La puerta de confirmación

Al encontrar un espacio, el agente de reservas hace una pausa. Presenta los detalles al usuario y entra en un estado de ESPERA, procediendo solo después de recibir una señal clara.

Ingeniería para casos extremos: el problema del WAF

La prueba más crítica de un agente web es su capacidad para gestionar escenarios de «Human-in-the-Loop» (HITL). Los sitios modernos suelen utilizar firewalls de aplicaciones web (WAF) que activan los CAPTCHA o códigos de verificación de correo electrónico cuando detectan la automatización.

Aquí se produce un error en un script estándar. Nuestro sistema usa un Máquina de estados de pausa y reanudación.

Figura 3: Lógica de estado de manejo de excepciones

Como se detalla en el diagrama anterior (pasos 7 a 11), cuando el agente detecta un aviso de desafío:

1. Detiene la ejecución y notifica al usuario a través de la interfaz de chat.
2. La sesión del navegador permanece activa (se mantiene dentro del TTL del contenedor).
3. Una vez que el usuario proporciona el código, el agente reanuda la sesión sin problemas para completar la reserva.

Conclusión: funcionamiento web

Estamos pasando del «Web Scraping» al «Web Operating». Al utilizar Playwright para las «manos» y la inferencia semántica para los «ojos», podemos tratar la web orientada al ser humano como una interfaz programática.

Este acelerador lo demuestra con la arquitectura adecuada: interpretación semántica, orquestación basada en estados e infraestructura segura como True Foundry—podemos crear automatizaciones resilientes que reduzcan la brecha de API.

Explore los aceleradores TrueFoundry