Arquitectura de agentes
Deep Agents agrupa acciones del navegador para reducir llamadas al modelo
LangChain explica cómo usa Stagehand para ejecutar pasos juntos y devolver menos contexto. Dónde detener el lote, observar de nuevo y comprobar el resultado.
Menos viajes entre el modelo y la página
Un agente que navega puede gastar buena parte del recorrido leyendo estados intermedios y esperando otra respuesta del modelo para cada clic. LangChain explicó el 3 de noviembre cómo ha ajustado las herramientas de Deep Agents con Stagehand: ejecutar varios pasos juntos y devolver al modelo el resultado que necesita para continuar.
La decisión interesante está en dónde cortar esa secuencia. Agrupar pasos conocidos reduce idas y vueltas; encadenar decisiones que dependen de una pantalla todavía no observada puede ejecutar correctamente una intención equivocada. El lote necesita un límite claro y una comprobación al terminar.
Una llamada puede contener varias acciones
La integración ofrece snapshot para observar los elementos de la página, run para actuar y screenshot para capturar su aspecto. run admite acciones agrupadas o JavaScript con una interfaz de estilo Playwright. Así, el código puede conservar estados intermedios en variables y devolver solo la información útil al agente.
En un ejemplo propuesto de búsqueda de documentación, un lote podría rellenar una consulta, abrir los resultados y devolver sus títulos y enlaces. El modelo decidiría entonces qué documento consultar. Esa decisión merece una nueva observación: todavía no sabemos qué resultados aparecerán.
No agruparía en ese mismo bloque la búsqueda y el envío de un formulario elegido entre los resultados. Ahorrar una llamada no compensa perder el punto donde comprobar destinatario, contenido y autorización. La unidad útil es una secuencia que podamos explicar y verificar, no el mayor número posible de clics.
| Situación | Cómo dividiría el recorrido |
|---|---|
| Campos conocidos del mismo formulario | Rellenarlos juntos y comprobar sus valores. |
| Resultados todavía desconocidos | Terminar el lote, observar y elegir el siguiente destino. |
| Envío con efectos externos | Revisar contenido y autorización antes de ejecutarlo. |
Recortar información exige conservar lo que permite actuar
Stagehand v4 lleva buena parte de la gestión del navegador a una extensión próxima a la página. Browserbase presentó esa arquitectura en agosto; la novedad de noviembre es el trabajo de integración y optimización explicado por LangChain, no el lanzamiento de v4.
El árbol de accesibilidad permite localizar controles sin devolver todo el HTML. Una captura sigue aportando información cuando importa el aspecto visual. Son observaciones complementarias: un botón identificable no demuestra que el diseño se vea bien.
Los identificadores de snapshot cambian en cada lectura. La documentación exige usar los de la observación más reciente y renovarlos tras navegar o cuando quedan obsoletos. Reducir contexto no justifica actuar con referencias antiguas.
También revisaría qué se devuelve al terminar. Para una descarga, pediría el archivo esperado y su contenido comprobable; para una búsqueda, los resultados realmente visibles. Un mensaje genérico de éxito dificulta detectar que el agente llegó a otra página.
La sesión y los permisos siguen siendo responsabilidad de la aplicación
La integración actual requiere Python 3.11, LangChain 1.4.7 y Stagehand 4.3.0 como mínimos. La aplicación aporta y mantiene el navegador; el middleware no implementa almacenamiento de sesión ni checkpoints del navegador. La documentación permite interrumpir run para revisar sus argumentos antes de ejecutarlo.
El código de run puede utilizar las cuentas abiertas y los destinos accesibles de esa sesión. Una API con apariencia de Playwright no es una sandbox de seguridad. Separaría usuarios y tareas con navegadores propios, además de mantener credenciales fuera del contenido que recibe el modelo.
Empezaría por un recorrido de consulta sin efectos externos. Compararía tareas completadas, llamadas, tiempo y coste, conservando ejemplos fallidos. Si el ahorro obliga a repetir búsquedas o dificulta verificar el resultado, el lote está mal dividido. Mejorar la herramienta consiste en quitar pasos redundantes sin quitar las decisiones que requieren contexto nuevo.