browser-harness, Playwright y Puppeteer: cómo elegir una herramienta de automatización de navegador

En automatización de navegadores y pruebas automatizadas, Playwright y Puppeteer son dos de las herramientas que más se comparan. Ambas pueden controlar navegadores, hacer clic en páginas, extraer contenido, generar capturas o PDFs, y ambas están muy relacionadas con Chrome DevTools Protocol.

Al añadir browser-use/browser-harness, la pregunta deja de ser solo “qué framework de pruebas es más potente”. Pasa a ser una comparación entre dos tipos de herramientas:

• Playwright / Puppeteer: herramientas para que ingenieros escriban scripts deterministas.
• browser-harness: una herramienta para que AI Agent operen navegadores reales.

El primer grupo encaja con pruebas, scraping y automatización de ingeniería. El segundo se parece más a una capa de control de navegador para agentes como Claude Code, Codex CLI y Gemini.

Relación entre Playwright y Puppeteer

Puppeteer nació en el equipo de Google Chrome y se orienta de forma natural a Chromium y Chrome. Su API es concisa, el ecosistema es maduro y resulta muy cómodo para capturas, PDFs, extracción de páginas y automatización ligera alrededor de Chrome.

Playwright es mantenido por Microsoft, y su equipo tiene vínculos históricos profundos con el trabajo temprano de Puppeteer. Tomó muchas lecciones de Puppeteer y añadió mejor soporte cross-browser, auto-waiting, aislamiento de contextos, reportes de pruebas y herramientas de depuración.

En resumen:

• Si solo necesitas tareas ligeras alrededor de Chrome, Puppeteer sigue siendo muy cómodo.
• Si haces pruebas E2E cross-browser, automatización de SPA complejas o ingeniería de pruebas en equipo, Playwright suele encajar mejor.

Diferencias principales

Soporte de navegadores

Puppeteer destaca en Chrome. Se integra estrechamente con Chromium. Si tu objetivo es controlar Chrome, generar PDFs, tomar capturas o hacer scraping sencillo, Puppeteer tiene poca carga mental.

Playwright destaca en trabajo cross-browser. Soporta de forma nativa Chromium, Firefox y WebKit. WebKit es importante porque muchos problemas relacionados con Safari no se detectan usando solo Chrome. Para aplicaciones que deben cubrir escritorio, móvil y distintos motores, Playwright es una mejor herramienta principal.

Esta es la primera frontera de decisión: si solo importa Chrome, Puppeteer está bien. Si necesitas pruebas cross-browser serias, elige primero Playwright.

Auto-waiting y estabilidad

Lo más molesto de la automatización de navegador no suele ser “cómo hacer clic”, sino si la página está lista. Un elemento puede no estar en el DOM, estar cubierto, seguir animándose o continuar deshabilitado.

En Puppeteer se suele escribir:

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

Funciona, pero el ingeniero debe pensar la lógica de espera. Cuanto más compleja es la página, más aparecen waitForSelector, waitForTimeout y reintentos manuales.

El mecanismo de Locator y auto-waiting de Playwright es más completo:

1

await page.locator('#submit-btn').click();

Antes de hacer clic, Playwright comprueba si el elemento es visible, accionable, estable y no está cubierto, y reintenta durante un tiempo razonable. Esto importa mucho en aplicaciones modernas con React, Vue o Next.js, donde hay mucho renderizado asíncrono y flaky tests.

Múltiples cuentas y aislamiento de contextos

Si necesitas simular varios usuarios, o permitir que varias tareas compartan un proceso de navegador pero separen Cookie, LocalStorage y Session, BrowserContext es importante.

Puppeteer también soporta aislamiento de contextos, pero Playwright lo convierte en capacidad central. Puedes crear varios contextos independientes dentro de una misma instancia de navegador. Cada contexto se comporta como un navegador limpio sin iniciar procesos completos una y otra vez.

Esto es útil para:

• Pruebas concurrentes con múltiples cuentas.
• Pruebas de flujos con varios roles.
• Ecommerce, mensajería y documentos colaborativos.
• Tareas de extracción que necesitan aislar Cookie y estado de login.

Diferencias de herramientas

Playwright es la opción más orientada a ingeniería. Incluye herramientas usadas en desarrollo de pruebas:

• codegen: operar en una página y generar scripts automáticamente.
• Trace Viewer: revisar capturas, DOM, red y console logs tras un fallo.
• Test Runner: assertions, paralelismo, reintentos, reportes y matrices de proyectos.
• Locator: selección por texto, role, label, test id y CSS.

Puppeteer se parece más a una biblioteca ligera de control de navegador. No es pesada, su API es directa y se integra bien en scripts, tareas de servidor y flujos personalizados.

Si construyes un sistema de pruebas empresarial, las herramientas de Playwright ahorran mucho trabajo. Si solo necesitas un script Node.js para convertir páginas a PDF o hacer capturas programadas, Puppeteer puede ser más directo.

Dónde encaja browser-harness

browser-harness no es el mismo tipo de herramienta que Playwright o Puppeteer.

Playwright y Puppeteer asumen sobre todo que humanos escriben scripts. Los ingenieros deciden selectores, condiciones de espera, assertions y manejo de excepciones. Buscan determinismo: el mismo script debería producir el mismo resultado bajo el mismo estado de página.

browser-harness asume sobre todo que un AI Agent opera el navegador. Su objetivo no es ofrecer una enorme API de alto nivel, sino conectarse a Chrome real mediante CDP y exponer capturas, clics por coordenadas, DOM, solicitudes de red y helpers al agente. El agente puede observar la página, decidir el siguiente paso, añadir helpers cuando falta capacidad y convertir experiencia del sitio en skills.

Por eso encaja mejor con tareas abiertas:

• Iniciar sesión en un backend y descargar facturas.
• Rellenar formularios en un sistema interno.
• Manejar páginas OA o SaaS que cambian con frecuencia.
• Explorar una página según un objetivo del usuario, no ejecutar un script fijo.
• Dar capacidad de navegador a Claude Code, Codex CLI y herramientas similares.

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-debugging para 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.

Qué son los domain skills

Puedes entender domain skills como manuales de operación de sitios para agentes.

No son documentación de usuario normal ni scripts de una sola vez. Son más bien conocimiento de sitio probado en campo:

• Si el sitio es adecuado para usar navegador.
• Qué API debe usarse primero si existe.
• Qué URL conviene usar cuando el navegador es necesario.
• Qué estructuras DOM, aria-labels y comportamientos de botones fueron verificados.
• Qué enfoques comunes fallan.
• En qué escenarios se debe detener y pedir intervención humana.

Este contenido puede ser revisado por humanos y leído por agentes durante tareas. Convierte la exploración improvisada en experiencia mantenible.

No es para que el agente haga clic a ciegas

Un buen browser agent no debería convertir todos los problemas en abrir una web, mirar capturas y pulsar botones.

Una parte importante de domain skills consiste precisamente en decirle al agente cuándo no usar el navegador.

En sitios como ArXiv, la búsqueda de papers, metadatos y resúmenes pueden obtenerse mediante Atom API o etiquetas meta HTML. Las solicitudes HTTP suelen ser más rápidas, estables y fáciles de analizar que abrir un navegador.

GitHub sigue una lógica parecida. Repositorios, usuarios y releases deberían usar primero la REST API. El contenido de archivos debería leerse desde raw.githubusercontent.com. Solo páginas como GitHub Trending, sin API equivalente, requieren navegador.

Esto muestra que browser-harness no parte de “el navegador lo resuelve todo”. Coloca el navegador en su lugar correcto: cuando API, HTTP y páginas estáticas no resuelven el problema, el agente opera una página real.

Guardan conocimiento por sitio

Los scripts tradicionales de automatización suelen escribirse alrededor de una tarea:

1

Abrir página -> escribir palabra clave -> pulsar botón -> descargar archivo

Ese script puede completar la tarea, pero la experiencia queda dispersa en el código. Si el sitio cambia, el script falla. Si cambia la tarea, gran parte de la experiencia no se reutiliza.

domain skills tiene una granularidad más cercana a una base de conocimiento por sitio. Se preocupa por:

• Qué selector de contenedor es estable en resultados de Amazon.
• Qué datos de GitHub deberían ir por REST API.
• Cómo difieren los aria-label de botones en LinkedIn invitations.
• Qué páginas de Shopify Admin son embedded apps.
• Por qué los inputs de Shopify Polaris no siempre aceptan asignación JS normal de value.
• Cómo crear, listar y limpiar instancias de navegador en Browser Use Cloud.

Estas experiencias no son pasos de una sola tarea. Son criterios que muchas tareas futuras pueden reutilizar.

Ejemplo: búsqueda de productos en Amazon

En Amazon, lo importante no es solo cómo buscar productos, sino qué ruta es más estable.

Un enfoque fiable es usar una URL de búsqueda directa en lugar de abrir siempre la portada y simular escritura. Los resultados pueden extraerse de un contenedor como [data-component-type="s-search-result"]. La extracción de campos también tiene matices: título, precio, rating, número de reseñas y si es patrocinado tienen fuentes DOM más estables.

Esto es valioso para un agente. Sin esa experiencia, el agente podría adivinar botones desde capturas y probar selectores una y otra vez. Con ella, puede ir directamente a una ruta de extracción más estable.

Además, un skill puede registrar trampas. Algunos selectores que parecen válidos pueden leer mal resultados patrocinados o áreas de recomendación cruzada. Eso solo se aprende probando.

Ejemplo: gestión de invitaciones en LinkedIn

LinkedIn se acerca más a flujos con cuentas reales, y por eso tiene más riesgo.

En la página de gestión de invitaciones, los botones Accept e Ignore tienen formatos de aria-label distintos. No se puede derivar uno del otro. Algunas tarjetas incluso renderizan Accept como <a> en lugar de <button>, y un clic CDP normal puede no disparar la acción.

Esto muestra que la automatización web real no termina al localizar un elemento. Etiquetas, eventos, soft navigation e implementación de componentes afectan si la acción realmente ocurre.

Para un agente, esta experiencia también tiene una implicación de seguridad. Las acciones relacionadas con cuentas sociales, invitaciones, mensajes y publicaciones no deberían delegarse por completo. El skill puede registrar rutas y trampas, pero aceptar invitaciones en lote, enviar contenido externo o cambiar datos de cuenta debería conservar confirmación humana.

Ejemplo: Shopify Admin

Shopify Admin muestra otro problema: un backend no siempre es una página única, sino una combinación de embedded apps y componentes complejos.

Muchas apps de Shopify corren dentro de iframes. Los inputs Polaris React, Web Components y embedded apps tienen comportamientos distintos. Algunos inputs no se pueden llenar solo con element.value = ...; requieren CDP keystrokes más parecidos a entrada real de teclado.

El valor de este tipo de skill es que permite al agente identificar primero qué tipo de UI está viendo y luego elegir el método correcto.

La experiencia de Shopify también enfatiza “no uses navegador si no hace falta”:

• Para datos de producto e inventario de solo lectura, usar primero Storefront API.
• Si hay un token de Admin API, usar primero Admin API.
• Para editar código de tema, usar primero Shopify CLI.
• Usar navegador solo cuando no hay API, el cambio es puntual o se está explorando el admin.

Esa es una lógica madura de elección de herramientas para agentes.

Ejemplo: Browser Use Cloud

domain skills no solo sirve para clics en páginas. También puede registrar experiencia de API alrededor del runtime del navegador.

La experiencia de Browser Use Cloud puede registrar cómo crear cloud browsers por REST API, listar navegadores activos, limpiar zombie browsers y obtener liveUrl y cdpUrl.

Esto significa que un skill no se limita a “cómo pulsar un botón”. Cualquier tarea recurrente con un método estable puede convertirse en skill:

• Forma de llamar la API.
• Formato de cabeceras de autenticación.
• Estructura de request y response.
• Códigos de estado verificados.
• Modos de fallo frecuentes.
• Limpieza y reciclaje de recursos.

Para agentes, todo eso son capacidades reutilizables.

Por qué es más fiable que razonar sobre la marcha

Muchas personas esperan que un modelo grande entienda la página por sí mismo cada vez. En tareas reales, depender solo del razonamiento improvisado no es estable.

Las razones son simples:

• La UI web cambia con frecuencia.
• El mismo botón puede tener varias implementaciones.
• Visible no significa clicable.
• Clicable no significa que la acción haya tenido efecto.
• Algunas tareas deberían usar API, no navegador.
• Algunas acciones requieren confirmación humana y no deberían decidirse solo por el modelo.

Al escribir estas experiencias en archivos, se obtienen varias ventajas:

• Los humanos pueden revisarlas.
• Las experiencias erróneas pueden corregirse.
• El conocimiento del mismo sitio puede acumularse.
• Nuevos agentes pueden heredar experiencias anteriores.
• Descubrimientos temporales pueden convertirse en conocimiento duradero.

Esto es más estable que ponerlo todo en un prompt o en el contexto de chat.

Cómo puede usarlo un equipo

En un equipo, domain skills puede convertirse en una base ligera de conocimiento de automatización.

Conviene registrar cosas como:

• Rutas tras login en sistemas internos.
• Flujos de exportación de reportes.
• Manejo de popups frecuentes.
• Qué botones requieren confirmación humana.
• Qué páginas tienen alternativa por API.
• Qué selectores fueron probados y son fiables.
• Qué tareas el agente no debe ejecutar automáticamente.

No hace falta que todo esté completo desde el inicio. Lo práctico es empezar por flujos de bajo riesgo, frecuentes y reversibles: lectura, descarga, organización y comprobación. Cuando el flujo sea estable, convertir la experiencia en skill.

Para gestores de equipo, los archivos skill hacen visible el límite de automatización. Permiten revisar qué sabe el agente, qué puede hacer y dónde debe detenerse.

Límites importantes

domain skills puede mejorar la tasa de éxito del agente, pero no debería automatizar por completo operaciones de alto riesgo.

Hay límites que conviene mantener:

• No registrar contraseñas, Cookie, token, datos de clientes ni URLs internas sensibles.
• Mantener confirmación humana para pagos, borrados, envíos masivos, cambios de cuenta y publicaciones externas.
• Escribir fecha de verificación y alcance del skill.
• Permitir que el skill caduque tras cambios del sitio y se vuelva a validar.
• No usar skills para evadir controles de riesgo o límites de plataforma.

En otras palabras, domain skill hace al agente más estable, no le da permiso ilimitado.

Comparación de los tres

Sensación de código

Puppeteer se siente más cercano al control directo de Chrome:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

Playwright enfatiza Locator y auto-waiting:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harness se siente completamente distinto. Normalmente no escribes un script completo. Das un objetivo dentro de un entorno de agente:

1

Abre el panel de administración, descarga la factura del mes pasado y organízala para reembolso.

El agente usa browser-harness repetidamente para:

• Tomar capturas y entender la página actual.
• Hacer clic en una coordenada o localizar un elemento.
• Escribir texto, subir archivos y descargar archivos.
• Decidir cómo cerrar popups.
• Añadir código helper cuando falta algo.
• Convertir flujos reutilizables en domain skills.

Ese no es el estilo de un script de pruebas tradicional. Es el flujo de trabajo de un browser agent.

Cómo elegir

Elige Puppeteer cuando:

• El proyecto corre principalmente en Node.js.
• Solo necesitas Chrome o Chromium.
• La tarea es captura, PDF, scraping simple o automatización ligera.
• Quieres una API simple, pocas dependencias y más control manual.
• Dependendes mucho de Chrome DevTools Protocol.

Elige Playwright cuando:

• Construyes automatización UI estándar o pruebas E2E.
• Necesitas cubrir Chromium, Firefox y WebKit.
• El lenguaje principal del equipo puede ser Python, Java o C#.
• La página es una SPA compleja con muchos estados asíncronos y riesgo de flaky tests.
• Necesitas codegen, Trace Viewer, reportes y pruebas paralelas.

Elige browser-harness cuando:

• Desarrollas o usas AI Agent.
• Quieres que el modelo opere un navegador real como una persona.
• Los pasos de la tarea no son fijos y requieren juicio página por página.
• El sitio cambia a menudo o tiene muchos popups, iframes y shadow DOM.
• Quieres que flujos web reales sean manejados por Claude Code, Codex CLI u otras herramientas similares.

Conclusión

Playwright y Puppeteer son herramientas de automatización de navegador cuyo objetivo central es permitir que humanos escriban scripts fiables. Puppeteer es más ligero y cercano a Chrome. Playwright es más completo y encaja mejor con pruebas cross-browser y aplicaciones frontend complejas.

browser-harness apunta en otra dirección. No está pensado para reemplazar a Playwright o Puppeteer en pruebas. Está pensado para permitir que AI Agent controlen navegadores reales. Sacrifica parte del determinismo de los scripts tradicionales a cambio de más adaptación en tareas abiertas.

Así que no se trata de elegir solo uno. Conviene separar por capa de tarea:

• Ingeniería de pruebas: Playwright primero.
• Scripts ligeros de Chrome: Puppeteer encaja bien.
• AI Agent trabajando en la web: mira browser-harness.

Referencias:

• browser-use/browser-harness: https://github.com/browser-use/browser-harness
• Documentación de Playwright: https://playwright.dev/
• Documentación de Puppeteer: https://pptr.dev/
• Chrome DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/