browser-use/browser-harness es una herramienta de control de navegador para AI Agent. Su objetivo no es crear otra capa pesada de automatización, sino conectar modelos de lenguaje directamente a Chrome real mediante CDP, para navegar, hacer clic, tomar capturas, descargar, subir archivos y completar formularios.
El README lo define como un CDP harness delgado y editable para conectar LLMs a un navegador real. Cuando falta un helper para una tarea, el agente puede añadir código durante la ejecución y convertir la experiencia reutilizable en domain skills.
Este tipo de herramienta merece atención porque el navegador sigue siendo la entrada de muchos flujos reales: paneles administrativos, SaaS, ecommerce, sitios de reclutamiento, CRM, sistemas de reembolso, consolas cloud y plataformas de documentos. Muchas veces no hay una API estable, o los permisos de API son más difíciles de obtener que el acceso a la página web. Dar al agente control fiable del navegador completa la última parte de la automatización.
Qué es browser-harness
Por estructura, browser-harness se parece más a un runtime de navegador para agentes que a una extensión de navegador para uso manual.
Sus ideas centrales son:
- Conectarse directamente a Chrome o Chromium.
- Controlar páginas mediante un WebSocket CDP.
- Permitir que el agente combine capturas, clics por coordenadas, DOM, solicitudes de red y CDP nativo.
- Guardar helpers de tarea en
agent-workspace/agent_helpers.py. - Guardar experiencia específica de sitios en
agent-workspace/domain-skills/. - Mantener un núcleo pequeño en lugar de construir una gran plataforma de automatización.
Según el README, la arquitectura central tiene unos cuatro archivos principales y alrededor de 1.000 líneas de código, incluyendo install.md, SKILL.md, src/browser_harness/, agent-workspace/agent_helpers.py y agent-workspace/domain-skills/.
El foco no es incluir capacidades para todos los sitios. Es dar al agente una capa de operación lo bastante cercana a un navegador real para que pueda completar capacidades faltantes durante una tarea concreta.
En qué se diferencia de la automatización tradicional
La automatización tradicional de navegador suele girar alrededor de frameworks de prueba como Playwright, Selenium o Puppeteer. Son buenos para scripts deterministas: abrir una página, localizar un elemento, hacer clic y verificar el resultado.
browser-harness apunta a otra clase de trabajo. El usuario da un objetivo, y el agente explora la página, juzga el estado, maneja ventanas emergentes, añade helpers y reutiliza conocimiento del sitio. Lo importante es la adaptación durante la interacción.
La diferencia puede resumirse así:
- Playwright encaja mejor cuando humanos escriben scripts y agentes los ejecutan.
- browser-harness encaja mejor cuando el agente mira la página y actúa paso a paso.
- La automatización tradicional favorece flujos fijos.
- browser-harness favorece tareas abiertas.
- Los scripts tradicionales dependen con frecuencia de selectores.
- browser-harness prioriza capturas, acciones sobre la interfaz visible y, cuando hace falta, DOM o CDP.
Esto no significa que reemplace a Playwright. Para pruebas estables, Playwright sigue siendo más maduro. El valor de browser-harness está en convertir páginas reales en un entorno operable por un agente, sobre todo cuando la estructura es compleja, los pasos no son fijos y hace falta juicio contextual.
Por qué importa Chrome real
Muchas herramientas de agentes de navegador usan navegadores headless aislados. Eso facilita el despliegue y sirve para tareas por lotes, pero no siempre reutiliza el entorno real del usuario: sesiones iniciadas, extensiones, historial, marcadores y configuración diaria.
browser-harness soporta Chrome local y Browser Use cloud browser. Para navegadores locales ofrece dos enfoques:
- Usar
chrome://inspect/#remote-debuggingpara permitir conexión a la instancia actual de Chrome. - Iniciar un profile aislado con
--remote-debugging-port=9222 --user-data-dir=....
Si quieres que el agente ayude con tareas dentro de cuentas reales, la documentación se inclina por el primer enfoque, porque reutiliza el estado de login, extensiones y marcadores del Chrome diario. Para automatización desatendida, o si no quieres que los popups interrumpan el trabajo, conviene más un profile aislado o un navegador cloud.
La decisión es clara: Chrome real se acerca más al flujo de trabajo del usuario, pero el límite de seguridad es más sensible. Un navegador aislado es más controlable, pero requiere volver a manejar login y entorno.
Helpers editables y domain skills
Lo más interesante de browser-harness es que incorpora en la estructura del proyecto lo que el agente aprende.
agent-workspace/agent_helpers.py guarda helpers creados durante tareas. Por ejemplo, si el agente necesita subir un archivo y las herramientas existentes no bastan, puede añadir un helper de subida estable. La próxima vez que vea una página similar, no empieza desde cero.
agent-workspace/domain-skills/ guarda experiencia por sitio. El README menciona LinkedIn outreach, pedidos en Amazon y sistemas de reembolso. El proyecto recomienda no escribir esas skills a mano, sino dejar que el agente las genere a partir de tareas reales, porque así reflejan mejor el comportamiento real de las páginas.
Este enfoque encaja bien con la automatización web. Lo difícil no suele ser “cómo hacer clic en un botón”, sino:
- Cómo redirige un sitio después de iniciar sesión.
- Qué popups bloquean el flujo principal.
- Qué selectores son estables y cuáles son clases temporales.
- Cómo manejar subidas, descargas, iframes, shadow DOM y componentes cross-origin.
- Qué esperas ocultas y estados asíncronos existen en un backend concreto.
Si ese conocimiento solo queda en un log de ejecución, se pierde rápido. Convertirlo en domain skills permite que el agente mejore con el uso.
Escenarios adecuados
browser-harness encaja mejor en tareas como:
- Operar paneles web reales para usuarios.
- Completar flujos repetidos en sistemas sin API.
- Tareas personales o empresariales que dependen mucho del estado de login.
- Interacciones complejas donde una captura ayuda a juzgar el estado.
- Agentes que necesitan añadir herramientas y conocimiento del sitio durante la ejecución.
- Varios subagentes usando navegadores aislados.
- Investigación sobre runtimes de browser agents.
Ejemplos concretos: organizar tablas web, enviar formularios internos, descargar facturas, subir archivos, manejar reembolsos, revisar estados de pedidos, configurar recursos en SaaS y extraer información de páginas con sesión iniciada.
Si la tarea solo consiste en obtener páginas estáticas, quizá no hace falta un navegador. El propio SKILL.md del proyecto señala que las páginas estáticas a menudo pueden obtenerse por HTTP en lote. El navegador debe reservarse para tareas que realmente necesitan estado de página, login e interacción.
Riesgos a considerar
Permitir que un AI Agent controle Chrome real es potente, pero también arriesgado.
Primero, el límite de permisos debe estar claro. Chrome real puede contener correo, paneles de pago, consolas cloud, sistemas corporativos y cuentas personales. Si un agente puede operar el navegador, tiene acceso a parte de esos permisos web.
Segundo, no entregues credenciales al modelo. En login, verificación de pago o confirmaciones sensibles, el usuario debe completar el paso. El agente puede esperar a que termine el login, pero no debería leer ni introducir contraseñas, códigos o datos de pago desde capturas.
Tercero, automatización no equivale a delegación total. Muchas tareas web parecen simples, pero pueden incluir controles de riesgo, clics erróneos, eliminación de datos, envíos masivos u operaciones irreversibles. Empieza con flujos de solo lectura, bajo riesgo y reversibles.
Cuarto, las domain skills no deben filtrar privacidad. Puede compartirse conocimiento del sitio, pero no cuentas, URLs internas, datos de clientes, registros de coordenadas ni detalles de tareas únicas.
Quinto, el modo de conexión al navegador debe elegirse con cuidado. Reutilizar el Chrome diario es cómodo cuando importa el login. Para automatización larga, un profile aislado o navegador cloud es más controlable.
Qué significa para las herramientas de AI Agent
browser-harness representa una línea pragmática para herramientas de agentes: menos plataforma y más interfaz directa hacia el entorno real.
Muchos agentes fallan en dos extremos. Por un lado, el modelo razona pero no puede tocar la página real. Por otro, los frameworks de automatización son potentes pero requieren que humanos escriban el flujo rígido. browser-harness intenta conectar ambos lados: el navegador mantiene el estado real, y el agente observa, decide y añade herramientas.
Ese es también el sentido de un self-improving harness. No significa que el agente se vuelva mágicamente inteligente. Significa que la experiencia operativa reutilizable queda dentro de la estructura del proyecto, reduciendo rodeos en la siguiente tarea.
Para desarrolladores, su valor principal está en tres áreas:
- Capa de control de navegador para agentes personales.
- Referencia para estudiar automatización de navegador y flujos de agentes.
- Marco experimental para convertir flujos web en skills reutilizables.
No es la respuesta a todos los problemas de automatización de navegador, pero apunta a una dirección clara: cuando los agentes realmente ayudan a trabajar, la capa de herramientas no solo debe llamar APIs. También debe entender y operar las interfaces web que las personas usan a diario.
Conclusión
browser-use/browser-harness es interesante no porque envuelva muchas funciones avanzadas, sino porque pone sobre la mesa varios problemas clave de los browser agents: Chrome real, CDP, control basado en capturas, helpers editables, acumulación de skills por sitio y límites de permisos del usuario.
Si escribes pruebas E2E estables, Playwright o Selenium siguen encajando mejor. Si quieres que agentes como Codex o Claude Code manejen tareas web reales, browser-harness ofrece una entrada más cercana a la forma de trabajar de los agentes.
En la práctica, empieza con tareas de bajo riesgo: leer páginas, tomar capturas y extraer información. Luego prueba clics y envíos de forma gradual. Cuando confirme de forma estable el estado de la página, puedes considerar flujos más largos.
Referencias:
- Proyecto en GitHub: https://github.com/browser-use/browser-harness
- README: https://github.com/browser-use/browser-harness/blob/main/README.md
- Guía de instalación: https://github.com/browser-use/browser-harness/blob/main/install.md
- Guía de uso: https://github.com/browser-use/browser-harness/blob/main/SKILL.md