Agentes web que viven en la terminal: del navegador al código sin salir de la línea de comandos
Agentes web que escriben código: el enfoque terminal de Webwright
La mayoría de los agentes de automatización web funcionan de una forma muy concreta: controlan un navegador, hacen clic, escriben y se desplazan por las páginas. Es el método más intuitivo, pero también puede ser su mayor limitación.
Por qué las sesiones de navegador complican todo
Cuando un agente depende de una única sesión de navegador, cada acción está ligada a la anterior. Si algo falla, resulta difícil aislar el problema o repetir solo una parte del proceso. Además, las sesiones largas acumulan estado y generan comportamientos impredecibles.
Esto se traduce en tres dificultades habituales:
- El contexto se vuelve inmanejable con el paso de los pasos
- Depurar requiere revisar toda la secuencia de interacciones
- Cada tarea se resuelve desde cero, aunque el problema sea similar a uno ya resuelto
Webwright: navegadores desechables y código persistente
Webwright invierte esa lógica. En lugar de mantener un navegador abierto durante todo el proceso, el agente crea instancias nuevas cuando las necesita. Las usa para explorar, extraer información y las descarta después. Lo que queda no es el estado del navegador, sino el código, los logs y los archivos generados en el espacio de trabajo local.
El navegador se convierte en una herramienta temporal. El producto real es el código que permite reutilizar esa tarea.
Tres principios del enfoque
1. Código en lugar de acciones básicas
En lugar de encadenar clics y esperas, Webwright permite crear funciones reutilizables. Seleccionar fechas, completar formularios o extraer datos se convierten en funciones y bucles que se pueden mantener y modificar con facilidad.
2. Artefactos que permanecen
Cada ejecución genera salidas concretas: scripts de exploración, capturas de pantalla, logs y, al final, un programa reutilizable. Ese material queda guardado y puede servir de base para nuevas tareas.
3. Arquitectura mínima
El sistema se compone de tres elementos: un runner, un endpoint del modelo y un entorno de terminal. Apenas mil líneas de código. Sin capas complejas de orquestación, solo un bucle simple entre el modelo y el entorno.
Cómo funciona el bucle
El proceso es directo:
- El runner envía al modelo la tarea, el estado actual del workspace y las últimas observaciones
- El modelo responde con un comando de shell, normalmente un script de Playwright
- El entorno ejecuta el comando y devuelve los resultados, logs o errores
- El ciclo se repite hasta que el agente genera un script final, lo ejecuta en un entorno limpio y supera sus propias comprobaciones
Resultados en tareas reales
Las pruebas con sitios web en producción muestran números sólidos:
- 60.8 % de precisión en el benchmark Odyssey de navegación de largo alcance
- 86.7 % en Online-Mind2Web, con 300 tareas en 136 sitios distintos
- 66.2 % incluso usando modelos más pequeños como Qwen 3.5-9B, siempre que cuenten con herramientas reutilizables
Controlar el acceso al terminal
Dar acceso completo al terminal es potente, pero también arriesgado. Webwright añade varias salvaguardas:
- El agente no puede declarar la tarea completada hasta que genera un script final, lo ejecuta en un entorno limpio y pasa una revisión interna
- Los historiales largos se comprimen periódicamente para no saturar el contexto
- Los scripts que ya funcionan se pueden convertir en herramientas de línea de comandos y reutilizar
Lecciones para quien desarrolla automatizaciones
El enfoque de Webwright sugiere varias prácticas útiles:
- Separar la inteligencia del agente del entorno de ejecución
- Usar sesiones desechables y conservar solo el resultado
- Crear funciones reutilizables en lugar de secuencias de acciones básicas
- Verificar que la solución funciona antes de darla por válida
El navegador es temporal. El terminal y el código que genera son lo que permanece.
Una forma distinta de pensar la automatización
En lugar de construir máquinas de estado cada vez más complejas, Webwright propone que el agente escriba código. El navegador se usa y se descarta; el workspace es lo que queda.
La idea es sencilla: un terminal bien aprovechado puede ser suficiente para construir automatizaciones más fiables y mantenibles.