Creación de agentes de IA que utilizan navegador en Python

En este artículo, aprenderá cómo crear agentes de IA que puedan navegar e interactuar con sitios web reales utilizando Playwright, el uso del navegador y LangGraph.

Los temas que cubriremos incluyen:

Por qué Playwright es la base adecuada para la automatización del navegador en 2026 y en qué se diferencia de Selenium. Cómo extraer páginas dinámicas renderizadas en JavaScript y completar formularios de varios pasos de manera confiable. Cómo conectar las acciones del navegador a LangGraph y a los agentes de uso del navegador, manejar la detección anti-bot, administrar la espera y la persistencia de la sesión e implementar el resultado en Docker.

Creación de agentes de IA que utilizan navegador en Python

Introducción

La mayoría de los tutoriales de agentes de IA comienzan con una API. Le muestran cómo llamar a OpenWeather, acceder al punto final de Stripe y extraer datos de GitHub. Ese es un buen punto de partida hasta que intentas construir algo real y te das cuenta de que la tarea que realmente necesitas realizar no tiene una API.

Piense en lo que los humanos hacen con los navegadores todos los días: presentar formularios gubernamentales, leer los precios de la competencia, extraer investigaciones de sitios que protegen sus datos detrás del procesamiento de JavaScript, iniciar sesión en portales que nunca han oído hablar de OAuth. Hay aproximadamente 1.100 millones de sitios web en Internet. Una fracción cada vez más pequeña de ellos tiene API públicas. El resto sólo habla navegador.

Un agente que está limitado a llamadas API maneja quizás el 5% de las tareas que realiza un trabajador humano diariamente. Dale a ese agente un navegador y la cobertura cubrirá todo. Ésa es la brecha que cierra este artículo.

El mercado mundial de agentes de IA asciende a 10.910 millones de dólares en 2026 y se prevé que alcance los 50.310 millones de dólares en 2030, con los agentes con capacidad de navegador en el centro de ese crecimiento. El 27,7% de las empresas ya utilizan navegadores agentes en producción, frente a prácticamente ninguna dos años antes. Las herramientas han madurado rápidamente y los patrones están lo suficientemente establecidos para enseñar correctamente.

Al final de este artículo, tendrá un agente de navegador funcional que navega por sitios web reales, completa formularios, extrae datos estructurados y se conecta a un LLM que decide qué hacer a continuación, todo en Python.

Por qué dramaturgo y no selenio

Si creó la automatización del navegador hace cinco años, la creó con Selenium. El selenio todavía está ampliamente implementado, todavía funciona y no irá a ninguna parte. Pero para cualquier proyecto nuevo en 2026, Playwright es el predeterminado. Las razones son prácticas, no teóricas.

Selenium se comunica con el navegador enviando solicitudes HTTP individuales a un WebDriver. Cada acción, hacer clic, escribir, desplazarse, es una solicitud separada. Playwright utiliza una conexión WebSocket persistente durante toda la sesión. Los comandos fluyen a través de ese canal sin costo de ida y vuelta por acción. Los puntos de referencia independientes muestran consistentemente que Playwright corre entre un 30% y un 50% más rápido que Selenium en el nivel del conjunto de pruebas y con un promedio de ~290 ms por acción frente a los ~536 ms de Selenium. Para un agente de navegador que podría ejecutar cientos de acciones, esa brecha se agrava.

Playwright también incluye sus propios archivos binarios de navegador. Cuando lo instalas, obtienes versiones preconfiguradas de Chromium, Firefox y WebKit que están garantizadas para funcionar con tu versión de Playwright. No hay discrepancias en las versiones del controlador ni tuberías de CI rotas porque alguien actualizó Chrome. Tiene una espera automática incorporada antes de hacer clic en un elemento; verifica que el elemento esté visible, habilitado y no animado. No es necesario escribir time.sleep(2) y esperar lo mejor.

Específicamente para los agentes de IA, Playwright activa eventos reales de mouse y teclado que reflejan cómo los humanos interactúan con los navegadores. Los sitios diseñados para detectar la automatización buscan clics DOM sintéticos. El modelo de interacción del dramaturgo es más difícil de distinguir del aporte humano genuino.

También está la biblioteca de uso del navegador, que se encuentra un nivel más arriba. El uso del navegador es una biblioteca de Python que le brinda a un LLM un navegador que funciona. En el fondo, utiliza Playwright para controlar el navegador, pero el LLM lee el estado de la página y decide en qué hacer clic, escribir y extraer, sin necesidad de selectores de CSS. Le asignas una tarea en inglés sencillo y él se da cuenta del resto. En este artículo cubriremos tanto el uso de Playwright como el del navegador, porque satisfacen diferentes necesidades: Playwright cuando desea un control preciso y predecible; uso del navegador cuando desee que el agente maneje las decisiones de navegación de forma autónoma.

Configurar el entorno

Necesita Python 3.10 o superior, una clave API de OpenAI y unos cinco minutos.

Paso 1: crear un entorno virtual

Paso 2: instalar dependencias

Paso 3: instale los archivos binarios del navegador
Este es el paso que la mayoría de la gente pasa por alto. Playwright necesita descargar Chromium, Firefox y WebKit por separado del paquete Python. Ejecute esto una vez después de la instalación:

Si desea los tres motores de navegador: instale dramaturgo. Chromium por sí solo es suficiente para la mayoría del trabajo del agente y es más pequeño para descargar.

Paso 4: almacene su clave API
Cree un archivo .env en el directorio de su proyecto:

Agregue .env a su .gitignore inmediatamente. No confirme claves API.

Paso 5: Verifica que todo funcione
Aquí hay una primera secuencia de comandos que navega a una URL, lee el encabezado y guarda una captura de pantalla. Utilice example.com, un dominio de prueba disponible públicamente mantenido por la IANA que no lo bloqueará.

Cómo ejecutar: guarde como first_run.py y ejecute python first_run.py

Qué hace esto: async_playwright() es el punto de entrada para toda la sesión de Playwright. Browser_context equivale a abrir una nueva ventana de incógnito; las cookies, el almacenamiento local y el caché están aislados de todo lo demás. wait_until=”networkidle” le dice a Playwright que espere hasta que la página haya finalizado toda su actividad de red antes de que su código continúe, que es la estrategia de espera más segura para páginas dinámicas.

Si esto se ejecuta y guarda una captura de pantalla, su entorno está funcionando correctamente.

Navegación web y scraping

La razón por la que necesita Playwright en lugar de solicitudes + BeautifulSoup es la representación de JavaScript. Los sitios web modernos ofrecen un esqueleto de HTML y luego crean el contenido real dinámicamente después de que se carga la página: React, Vue, Angular, Next.js. Una solicitud HTTP simple recupera el esqueleto. Playwright ejecuta un navegador real, por lo que ve exactamente lo que ve un humano después de que se haya ejecutado todo JavaScript.

El siguiente objetivo es books.toscrape.com, un entorno de pruebas de scraping legal creado para la práctica. Pagina resultados, utiliza nombres de clases dinámicos para las calificaciones y refleja fielmente la estructura de las páginas reales de productos de comercio electrónico.

Cómo ejecutar: guarde como scrape_books.py y ejecute python scrape_books.py

Qué hace esto: wait_for_selector() es la llamada clave aquí. En lugar de dormir durante un tiempo fijo y esperar que el contenido se haya cargado, observa el DOM y continúa en el momento en que aparece el elemento de destino, o genera un TimeoutError si no aparece dentro de la ventana de tiempo de espera. Ese es el comportamiento correcto: fallar rápida y explícitamente en lugar de extraer silenciosamente de una página vacía.

La extracción de calificaciones merece atención. La calificación de estrellas está codificada como una clase CSS (calificación de tres estrellas), no como un número. El código elimina la "calificación de estrellas" de la cadena de clase para obtener el valor del texto. Este es el tipo de cosas que sólo sabes inspeccionando el HTML real. Cuando entregas esta tarea a un LLM sin formato sin navegador, no tiene forma de saber cómo se ve la estructura de clases. Con Playwright, puedes inspeccionarlo directamente y extraerlo exactamente.

Finalización de formularios y flujos de varios pasos

Completar formularios es donde los agentes del navegador se ganan la vida y donde fallan la mayoría de los scripts de automatización. La razón es que los formularios web no son sólo entradas y botones. Activan eventos de enfoque, entrada, cambio y desenfoque en secuencia. La validación de JavaScript escucha esos eventos. Si inyecta un valor en un campo de entrada estableciendo directamente el valor en el DOM (como suelen hacer las herramientas de automatización más antiguas), los oyentes de validación nunca se activan y el formulario se rompe.

Los métodos fill() y click() de Playwright activan eventos reales del navegador en el orden correcto, por lo que funcionan en la validación de formularios que bloquearían los enfoques de nivel inferior.

El objetivo a continuación es the-internet.herokuapp.com/login, un sitio de prueba público mantenido específicamente para la práctica de la automatización. ¡Acepta Tomsmith/SuperSecretPassword! como credenciales válidas y devuelve mensajes claros de éxito/fracaso.

Cómo ejecutar: guarde como form_submit.py y ejecute python form_submit.py

Qué hace esto: El patrón aquí, fill() → click() → wait_for_load_state() → verificar el elemento de resultado, es la plantilla para casi cualquier interacción de formulario. El wait_for_load_state(“networkidle”) después del envío es importante: sin él, consulta el DOM antes de que la página se haya actualizado y obtiene el estado previo al envío, no el resultado.

Para formularios más complejos con carga de archivos, menús desplegables y casillas de verificación:

Orquestación de herramientas con LangChain y LangGraph

Los guiones de Raw Playwright son potentes pero fijos. Hacen exactamente lo que codificaste, nada más. En el momento en que una página cambia su estructura, o la tarea requiere una decisión que el guión no anticipó, se rompe.

Conectar a Playwright con un LLM cambia esto. Las acciones del navegador se convierten en herramientas que el agente puede utilizar cuando decide que son necesarias. El agente lee la tarea, razona qué hacer, llama a una herramienta, lee el resultado y decide qué hacer a continuación. Ese bucle maneja variaciones que un guión fijo no puede.

Este es el puente entre el "script de automatización del navegador" y el "agente de IA".

Cómo ejecutar: guarde como agent_tools.py, asegúrese de que OPENAI_API_KEY esté en su .env, luego ejecute python agent_tools.py

Qué hace esto: Las tres funciones @tool-decorated se registran con el agente. Cada cadena de documentación es lo que lee el LLM para comprender qué hace la herramienta y cuándo usarla. Escríbalos como descripciones de trabajo, no como comentarios de código. Los globales _browser y _page compartidos significan que el navegador permanece abierto en múltiples llamadas a herramientas, lo cual es esencial para tareas que abarcan varias páginas en la misma sesión. Debido a que las herramientas se definen con async def, el agente se invoca con ainvoke() en lugar de invoke(), por lo que las llamadas a la herramienta se ejecutan en el mismo bucle de eventos que main() ya está usando.

Un diagrama de flujo vertical que muestra cómo fluye una solicitud de tarea a través del agente.

Un diagrama de flujo vertical que muestra cómo fluye una solicitud de tarea a través del agente (haga clic para ampliar)
Imagen del editor

La decisión de diseño clave en este fragmento es la instancia del navegador compartido. Si cada llamada de herramienta iniciara y cerrara su propio navegador, perdería todo el estado de la sesión entre llamadas, como las cookies, el historial de navegación y cualquier estado de formulario que el agente ya haya creado. Mantener el navegador activo durante la sesión completa del agente preserva ese contexto.

Uso del navegador para tareas de agentes de alto nivel

Raw Playwright con funciones @tool te brinda un control preciso. La desventaja es que todavía estás escribiendo selectores, todavía pensando en la estructura de la página y aún manejando cada caso extremo manualmente. Si el sitio cambia su HTML, sus selectores se rompen.

El uso del navegador adopta un enfoque diferente. En lugar de escribir selectores, le asigna al agente una tarea en inglés sencillo. El uso del navegador utiliza Playwright bajo el capó, pero el LLM lee el estado actual de la página en cada paso y decide qué hacer a continuación: en qué elemento hacer clic, qué escribir y cuándo se completa la tarea. La estructura de la página no está codificada en su código. El agente lo descubre en tiempo de ejecución.

uso del navegador es una biblioteca de Python que le brinda a un LLM un navegador que funciona. El LLM lee cada página y decide en qué hacer clic, escribir y extraer. Esto lo hace resistente a los cambios del sitio que romperían un script basado en selectores.

Cuándo utilizar el uso del navegador en Playwright sin formato:

Si la tarea es exploratoria y la estructura de la página es impredecible, utilice el navegador. Si está ejecutando un flujo de trabajo fijo y repetible donde cada selector es conocido y estable, Playwright sin formato es más confiable y más económico por ejecución. Un agente que utiliza el navegador realiza varias llamadas de LLM por paso de la tarea; una ejecución de Dramaturgo con guión no genera ninguno.

Cómo ejecutar: guarde como browser_use_agent.py, asegúrese de que OPENAI_API_KEY esté en su .env, luego ejecute python browser_use_agent.py

Qué hace esto: toda la tarea, navegar al sitio, leer la página, identificar los tres precios más altos y extraerlos, la maneja el agente sin un solo selector de CSS en su código. Si books.toscrape.com rediseña su visualización de precios mañana, el guión seguirá funcionando. Con un raspador basado en selector, se rompería silenciosamente.

Vale la pena explicar el parámetro max_actions_per_step=5. En cada paso, el agente lee la página y puede decidir realizar hasta cinco acciones (hacer clic, escribir, desplazarse, navegar) antes de volver a leer la página. Mantener este valor bajo obliga al agente a comprobar su trabajo con más frecuencia, lo que detecta los errores antes.

Manejando las partes duras

Tres cosas rompen la mayoría de los agentes de navegador en producción. Cada uno tiene una solución, pero ninguna es obvia hasta que ya estás quemado.

1. Detección antibots
Los sitios web que no quieren ser automatizados detectan la automatización de varias maneras, como verificando la propiedad navigator.webdriver (que Playwright establece en verdadero de forma predeterminada), buscando huellas digitales del navegador sin cabeza en el entorno JavaScript y analizando patrones de interacción que son demasiado rápidos o demasiado uniformes para ser humanos.

La mitigación más importante es eliminar la marca webdriver. Más allá de eso, una cadena de agente de usuario realista, un tamaño de ventana gráfica estándar y una ubicación y zona horaria realistas cubren la mayoría de los métodos de detección, excepto el análisis sofisticado de huellas dactilares.

Qué hace esto: La llamada add_init_script() se ejecuta antes de que se ejecute cualquier página JavaScript, lo que significa que la anulación de navigator.webdriver está implementada antes de que el código de detección del sitio pueda verificarlo. El argumento de inicio –disable-blink-features=AutomationControlled elimina un indicador de automatización independiente en el nivel del motor del navegador. Juntos, estos dos cambios manejan los métodos de detección más comunes.

Para sitios con sistemas agresivos de huellas dactilares y CAPTCHA, estas mitigaciones no serán suficientes. Servicios como Browserbase, Spidra y Scraping Browser de Brightdata manejan la resolución de CAPTCHA, la rotación de IP residencial y la administración de huellas digitales del navegador como infraestructura administrada.

2. Espera inteligente

El segundo modo de falla es el tiempo. El reflejo es agregar llamadas time.sleep() y aumentarlas cuando las cosas fallan. Esto es incorrecto en ambas direcciones: demasiado corto en conexiones lentas, demasiado largo en conexiones rápidas y completamente opaco al depurar.

Dramaturgo tiene cuatro estrategias de espera adecuadas. Utilice el que coincida con lo que realmente está esperando:

Qué hace esto: cada estrategia está vinculada a un evento observable específico en lugar de a un retraso de tiempo arbitrario. wait_for_selector observa el DOM. expect_response se conecta a la capa de red. wait_for_url monitorea la navegación. wait_for_function evalúa JavaScript en el contexto del navegador. Utilice el que indique más directamente "lo que necesito ya está listo".

3. Persistencia de sesión y cookies
El tercer modo de falla es la pérdida del estado de sesión. Si su agente inicia sesión en un sitio durante el paso uno y luego se destruye el contexto del navegador, el paso dos no tiene autenticación. Volver a crear el inicio de sesión en cada ejecución es lento y puede provocar una limitación o bloqueo de la velocidad.

La solución es guardar las cookies en el disco después de iniciar sesión y cargarlas al inicio de cada ejecución posterior:

Qué hace esto: context.cookies() devuelve todas las cookies para el contexto actual del navegador, incluidos los tokens de sesión y las cookies de autenticación. Escribirlos en JSON y recargarlos en la siguiente ejecución significa que el navegador se inicia en un estado autenticado. Tenga en cuenta que las sesiones caducan; agregue una verificación que recurra a un nuevo inicio de sesión si la sesión guardada devuelve una redirección a la página de inicio de sesión.

Implementación de agentes de navegador

Hacer que un agente de navegador funcione localmente es una cosa. Ejecutarlo de manera confiable en un entorno de nube es otra.

La principal diferencia entre un script de Python que funciona en su computadora portátil y uno que falla en CI son las dependencias del sistema. El navegador Chromium de Playwright requiere un conjunto de bibliotecas compartidas que están presentes en la mayoría de las máquinas de desarrollo, pero que no se encuentran en las imágenes mínimas de la nube. La solución más limpia es Docker.

Dockerfile: cree un contenedor que envíe todo lo que Playwright necesita:

Para cargas de trabajo simultáneas que ejecutan varias sesiones de navegador en paralelo, utilice la API asíncrona de Playwright con asyncio.gather():

Qué hace esto: asyncio.Semaphore(max_concurrent) limita la cantidad de contextos del navegador que se ejecutan al mismo tiempo. Sin él, el inicio de 50 contextos de navegador simultáneos agotará la memoria. Un proceso de navegador se comparte en todos los contextos; un contexto es barato; una instancia de navegador completa no lo es.

En el lado de la infraestructura administrada, Amazon Nova Act se lanzó en marzo de 2025 como un SDK dedicado para crear agentes de navegador en AWS, integrándose de forma nativa con Playwright para el control del navegador. El propio servidor MCP de Playwright brinda a los asistentes de IA control total del navegador a través del protocolo de contexto modelo, utilizando instantáneas de accesibilidad estructuradas en lugar de capturas de pantalla, lo que significa que los costos de los tokens se mantienen bajos mientras que la comprensión de la página por parte del agente se mantiene alta.

Poniéndolo todo junto

Aquí hay un agente completo de extremo a extremo que responde una pregunta de investigación, navega a una fuente de datos pública, extrae resultados estructurados y devuelve un resumen limpio. Utiliza las herramientas del navegador de la Sección 5 orquestadas por un agente de LangGraph.

Cómo ejecutar: guarde como reference_agent.py, asegúrese de que OPENAI_API_KEY esté en su .env y ejecute python reference_agent.py

Qué hace esto: este agente tiene tres herramientas limpias: navegar, extraer_estructurado y obtener_actual_url, además de un mensaje del sistema que le indica exactamente cuándo usar cada una. El agente llama a navegar para cargar la página, a extract_structured para extraer los títulos y precios de los libros mediante el selector CSS y sintetiza una lista estructurada en la respuesta final. La llamada a Teardown() después de que el agente finaliza cierra el navegador limpiamente para que no queden ejecutándose procesos zombies de Chromium.

Conclusión

El navegador no es una herramienta especializada para ingenieros de automatización. Es la interfaz universal para la web, y la web es donde se realiza la mayor parte del trabajo real del mundo. Un agente de IA que puede utilizar un navegador no necesita un equipo de socios que mantenga las integraciones de API. Puede alcanzar cualquier cosa que un humano pueda alcanzar.

Lo que hace que esto sea práctico ahora, y no sólo teóricamente interesante, es la madurez de las herramientas. Playwright maneja las partes difíciles de la interacción del navegador. El uso del navegador elimina la necesidad de escribir selectores para tareas exploratorias. LangGraph le brinda al LLM herramientas limpias y un bucle de razonamiento que maneja estructuras de página variables. Los patrones de este artículo no son demostraciones. Son los mismos patrones que el 51% de las empresas que ahora utilizan agentes de IA en producción están construyendo.

Comience con el ejemplo de raspado. Ejecútelo en un sitio del que realmente necesite datos. Agregue la capa de agente cuando necesite decisiones que el script no pueda anticipar. Agregue el uso del navegador cuando la estructura de la página sea demasiado dinámica para los selectores. Implemente en Docker cuando necesite que se ejecute en otro lugar que no sea su computadora portátil.

La parte difícil no es el código. Es saber qué herramienta alcanzar en cada capa. Esperemos que este artículo lo haya dejado más claro.