Playwright on KnightLi Blog

ai-goofish-monitor: sistema open-source para vigilar anuncios de Goofish con IA

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor es un sistema open-source de Usagi-org para monitorizar productos en Goofish.

Su objetivo es claro: automatizar búsqueda, filtrado, análisis de productos, registro de resultados y notificaciones en Goofish, para ayudar a encontrar antes los artículos de segunda mano que cumplen ciertas condiciones. El proyecto usa Playwright para automatización de páginas y se conecta a modelos de IA con entrada de imágenes para evaluar mejor la información del producto.

Proyecto: https://github.com/Usagi-org/ai-goofish-monitor

Resumen rápido

ai-goofish-monitor se parece más a un “panel de inteligencia de compras para Goofish” que a un simple script de alertas por palabras clave.

Tiene varias características claras:

Interfaz web completa para gestionar tareas, cuentas, criterios de IA, logs y resultados.
Monitoreo concurrente de múltiples tareas; cada tarea puede configurar palabras clave, precio, filtros y AI Prompt.
Uso de Playwright para capturar páginas de Goofish, útil cuando se necesita estado de login e interacción con la página.
Evaluación con IA para decidir si un producto cumple los requisitos, no solo coincidencia por palabras clave.
Soporte para ntfy.sh, WeCom, Bark, Telegram, Webhook y otros canales.
Cron, gestión de múltiples cuentas, rotación de proxies, reintentos y despliegue con Docker.

Es útil para quienes buscan a menudo productos concretos en Goofish: electrónica de segunda mano, cámaras, GPU, discos, consolas, instrumentos, electrodomésticos o coleccionables. Pero no es una “máquina automática de chollos”. Los resultados de Goofish cambian, el estado de login puede caducar y los controles de riesgo de la plataforma afectan la estabilidad. Conviene usarlo como herramienta auxiliar de filtrado, no como sustituto del juicio humano.

Qué problema resuelve

Buscar productos de segunda mano en Goofish suele tener varios problemas:

Hay demasiados anuncios para revisarlos manualmente.
Títulos y descripciones no son uniformes, así que las palabras clave fallan o generan falsos positivos.
Los buenos precios duran poco y se descubren tarde.
Un mismo producto puede variar por región, precio, estado y vendedor.
Entre productos baratos se mezclan accesorios, dañados, reacondicionados y títulos engañosos.
Vigilar muchas palabras clave de forma continua es difícil manualmente.

Las alertas básicas por palabra clave solo resuelven una parte. Si buscas “ThinkPad X1”, pueden aparecer accesorios, pantallas rotas, cajas vacías o piezas desmontadas. Si buscas “Sony A7C”, puedes encontrar kits con lentes, alquileres, títulos llamativos o precios anómalos.

La idea de ai-goofish-monitor es recoger candidatos con automatización, dejar que la IA aplique tus criterios y finalmente enviar los resultados que merecen atención.

Funciones principales

El README del proyecto lista capacidades bastante completas:

Gestión visual web: tareas, cuentas, criterios de IA, logs de ejecución y resultados.
Flujo impulsado por IA: creación de tareas con lenguaje natural y análisis con modelos multimodales.
Tareas concurrentes: cada tarea puede configurar palabras clave, precio, filtros y AI Prompt por separado.
Filtros avanzados: envío gratis, rango de publicación reciente y filtro por provincia / ciudad / distrito.
Notificaciones instantáneas: ntfy.sh, WeCom, Bark, Telegram, Webhook y más.
Programación: tareas periódicas con Cron.
Rotación de cuentas y proxies: múltiples cuentas, asociación de tareas, pool de proxies y reintentos.
Docker: despliegue en contenedores.

Juntas, estas funciones cubren el flujo completo desde crear una tarea hasta recibir una alerta.

Flujo de trabajo

Un flujo típico sería:

Desplegar el servicio y abrir la Web UI.
Importar el estado de login de una cuenta Goofish.
Crear una tarea de monitoreo.
Configurar palabras clave, rango de precio, región, ventana de publicación reciente y otros filtros.
Escribir criterios o dejar que la IA los genere.
Ejecutar la tarea en tiempo real o de forma programada.
Playwright abre páginas y extrae información de productos.
La IA evalúa título, descripción, imágenes y Prompt según tus necesidades.
Los resultados que coinciden se guardan en SQLite.
El sistema envía notificaciones por los canales configurados.
El usuario revisa resultados, logs e historial de precios en la Web UI.

El valor de la IA está sobre todo en el paso 8. Puede entender condiciones en lenguaje natural como “buen estado, precio razonable, sin accesorios, no reparado, idealmente recogida local”, algo más flexible que reglas simples de palabras clave.

Despliegue con Docker

El proyecto recomienda Docker:

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

La dirección por defecto de la Web UI es:

`1`	`http://127.0.0.1:8000`

La imagen oficial es:

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

Si descargar la imagen es lento, el README también muestra un ejemplo con mirror:

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

La imagen Docker ya incluye Chromium, por lo que no hace falta instalar un navegador adicional en el host. Los directorios persistentes por defecto incluyen:

data/: almacenamiento principal SQLite para tareas, resultados e historial de precios.
state/: archivos cookie de estado de login.
prompts/: prompts de tareas.
logs/: logs de ejecución.
images/: imágenes de productos y directorios temporales.

Si cambias SERVER_PORT en .env, también debes ajustar el mapeo de puertos en docker-compose.yaml.

Configuración mínima

La configuración mínima gira alrededor del modelo de IA y el login de la Web UI:

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

Los tres primeros son obligatorios para conectar el modelo:

OPENAI_API_KEY: API Key del modelo.
OPENAI_BASE_URL: endpoint compatible con OpenAI.
OPENAI_MODEL_NAME: nombre de un modelo con entrada de imágenes.

WEB_USERNAME y WEB_PASSWORD se usan para acceder a la Web UI. El README menciona las credenciales por defecto admin/admin123; en producción hay que cambiarlas.

Primer uso

El flujo inicial es aproximadamente:

Abrir http://127.0.0.1:8000.
Iniciar sesión en la Web UI.
Ir a gestión de cuentas de Goofish.
Usar la extensión de Chrome del proyecto para exportar el estado de login de Goofish en JSON.
Pegar ese estado en el sistema.
El archivo se guarda en state/, por ejemplo state/acc_1.json.
Volver a gestión de tareas, crear una tarea y asociar una cuenta.
Ejecutar la tarea y revisar resultados.

El punto clave es el estado de login. Goofish no ofrece una API estándar abierta para scraping de terceros, así que el proyecto usa el estado de login del navegador para simular acceso normal a páginas. Caducidad del login, controles de riesgo, captchas o anomalías de cuenta pueden afectar la ejecución.

Tareas de IA y tareas por palabra clave

El proyecto soporta dos formas de crear tareas.

La primera es AI判断.

Puedes escribir requisitos detallados y el sistema genera criterios de análisis de forma asíncrona. Encaja con necesidades complejas, por ejemplo:

Solo la unidad principal, sin accesorios.
Alertar solo si el precio está claramente por debajo del mercado.
Buen estado, sin agua, reparación ni defectos ocultos en la descripción.
Preferir la misma ciudad y recogida en persona.
Las imágenes deben mostrar número de serie, caja o accesorios clave.

La segunda es 关键词判断.

Se parece más al monitoreo tradicional por reglas: crea tareas directamente según palabras clave, precio, región y otras condiciones, sin pasar por generación con IA. Sirve para reglas simples donde se aceptan falsos positivos.

En la práctica se pueden combinar: palabras clave para el primer filtro, IA para reducir falsos positivos.

Qué permite la Web UI

La Web UI es una diferencia importante frente a scripts normales.

La página de tareas permite configurar:

Tareas creadas con IA.
Reglas por palabras clave.
Rangos de precio.
Ventana de publicación reciente.
Filtros de región.
Asociación de cuenta.
Reglas de programación.

La página de cuentas permite:

Importar estado de login de Goofish.
Actualizar estado de login.
Eliminar cuentas.
Asignar cuentas a tareas.
Permitir que el sistema elija cuenta automáticamente.

Las páginas de resultados y logs permiten:

Ver productos coincidentes.
Exportar resultados.
Consultar historial.
Ver el proceso de ejecución.
Diagnosticar caducidad de login, controles de riesgo y problemas de llamadas a IA.

La página de ajustes permite:

Ver estado del sistema.
Editar Prompt.
Ajustar proxies y rotación.

Para monitoreo a largo plazo, la Web UI es esencial. Si no, al aumentar tareas, configuración, logs, resultados y notificaciones se vuelven difíciles de mantener.

Almacenamiento de datos

El almacenamiento principal actual usa SQLite, con ruta por defecto:

`1`	`data/app.sqlite3`

Docker monta por defecto la base SQLite así:

`1`	`./data:/app/data`

Al arrancar, la aplicación crea base y tablas automáticamente, e intenta importar una vez datos históricos desde config.json, jsonl/ y price_history/.

Hay que tener en cuenta que state/, prompts/, logs/ e images/ siguen siendo directorios del sistema de archivos y no están dentro de SQLite. Las imágenes de productos se guardan temporalmente en rutas como:

`1`	`images/task_images_<task_name>/`

Al terminar la tarea, por defecto se limpian.

Esta estructura encaja bien con despliegues personales o de equipos pequeños: SQLite es ligero y fácil de migrar; los directorios conservan login, imágenes y logs de forma fácil de inspeccionar.

Canales de notificación

El proyecto soporta varios canales de notificación. Configuraciones habituales:

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

Las notificaciones son el centro de la experiencia. Si el monitor solo escribe resultados en el backend, el usuario debe seguir entrando a revisar. Con push, los productos que coinciden llegan inmediatamente.

Una configuración práctica es separar por valor del producto:

Coincidencias normales por palabra clave solo al backend.
Resultados de alta confianza de IA al móvil.
Productos de alto valor a WeCom o Telegram.
Más logs durante depuración, menos ruido cuando ya sea estable.

Ejecución para desarrolladores

Sin Docker, el desarrollo local requiere:

Python 3.10+
Node.js + npm
Playwright CLI
Chromium o Chrome / Edge

Comandos básicos:

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

Arranque con un comando:

1
2

chmod +x start.sh
./start.sh

start.sh revisa Playwright CLI y navegador, instala dependencias, construye el frontend, copia artefactos y arranca el backend.

Arranque manual del backend:

`1`	`python -m src.app`

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

Desarrollo frontend:

1
2
3

cd web-ui
npm install
npm run dev

Pruebas y build:

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

Para quién sirve

ai-goofish-monitor sirve para usuarios que:

Vigilan modelos concretos en Goofish con frecuencia.
Quieren monitorizar electrónica de segunda mano, cámaras, videojuegos o hardware.
Quieren automatizar “búsqueda por palabras clave + filtrado manual”.
Tienen una API compatible con OpenAI y aceptan pagar el coste de juicio con IA.
Conocen Docker o despliegue básico por línea de comandos.
Necesitan recibir resultados en móvil, WeCom o Telegram.

No encaja tanto si:

No sabes desplegar nada y quieres una App lista para usar.
No quieres manejar estado de login, captchas o controles de cuenta.
Necesitas APIs oficiales y muy conformes a regulación.
Quieres capturar datos de plataforma a gran escala y alta frecuencia.
Esperas que la IA juzgue riesgo de transacción y compre por ti.

Riesgos y límites

Estas herramientas requieren límites claros.

Primero, respeta las reglas de la plataforma.

Goofish tiene sus propios términos, controles de riesgo y mecanismos de seguridad de cuenta. La automatización puede activar restricciones. No hagas scraping de alta frecuencia, no intentes saltarte controles, no acoses vendedores, no recolectes privacidad en masa y no alteres el orden de la plataforma.

Segundo, protege el estado de login.

Los archivos de state/ son cookies de sesión. En la práctica equivalen a credenciales de acceso. No los subas a Git y no los pongas en servidores no confiables. Si el servidor queda expuesto a internet, cambia la contraseña por defecto de la Web UI y colócalo detrás de VPN, autenticación de proxy inverso o red interna.

Tercero, el juicio de IA no garantiza hechos.

La IA puede reducir falsos positivos, pero no garantiza autenticidad del producto, fiabilidad del vendedor, precio razonable o seguridad de la transacción. Aún debes revisar detalles, reputación del vendedor, historial de chat, envío y pago.

Cuarto, vigila costes.

Si cada candidato pasa por un modelo multimodal, el coste puede subir rápido. Filtra primero por palabra clave, precio y región, y solo envía pocos candidatos a IA.

Quinto, cuida la privacidad.

Capturas de producto, contenido relacionado con chats, estado de cuenta y notificaciones pueden contener información sensible. Protege Webhooks, logs y bases de datos.

Diferencia con scripts comunes

Un script normal de monitoreo de Goofish suele hacer tres cosas:

Buscar palabras clave.
Revisar precio.
Enviar notificación.

ai-goofish-monitor va más allá:

Gestiona tareas y cuentas con Web UI.
Expresa criterios de compra complejos con AI Prompt.
Usa modelos multimodales para mirar imágenes y descripciones.
Guarda resultados e historial de precios en SQLite.
Usa páginas de logs para diagnosticar fallos.
Mejora estabilidad con rotación de proxies y múltiples cuentas.
Soporta ejecución a largo plazo con Cron.

Precisamente por tener más funciones, también cuesta más desplegarlo y mantenerlo. Para usuarios normales, Docker es lo más sencillo. Para desarrolladores, la estructura Web UI, FastAPI, Playwright y SQLite es razonable para desarrollo secundario.

Cómo usarlo

Lo más práctico es empezar con tareas pequeñas.

Por ejemplo, si buscas una cámara de segunda mano, puedes crear una tarea:

Palabras clave: A7C, 索尼 A7C
Rango de precio: límite superior según precio de mercado
Región: misma provincia o ciudad
Ventana de publicación: último día o últimas horas
Criterios de IA: excluir lentes sueltas, unidades reparadas y accesorios obvios; fijarse en disparos y estado
Notificación: solo resultados aprobados por IA

Cuando funcione estable, aumenta tareas gradualmente. No empieces con decenas de palabras clave, varias cuentas y Cron de alta frecuencia. Primero observa estabilidad de login, falsos positivos, coste de IA y ruido de notificaciones.

Resumen

ai-goofish-monitor lleva el monitoreo de Goofish desde un “script por palabras clave” a un sistema de monitoreo con IA gestionable. Usa Playwright para automatizar páginas, IA para juicios complejos, Web UI para tareas y resultados, SQLite para datos y varios canales para notificaciones.

Encaja mejor con personas o equipos pequeños que vigilan productos concretos, especialmente electrónica, hardware y cámaras de segunda mano, donde el precio cambia mucho, el tiempo importa y las descripciones son ruidosas.

Pero hay que usarlo con cuidado: proteger el login, cambiar contraseñas por defecto, limitar frecuencia, revisar manualmente resultados de IA y respetar reglas de plataforma y privacidad. Como herramienta auxiliar de filtrado puede ser valiosa; como sistema de compra totalmente automático, es fácil sobreestimarla.

Referencias:

Grabación de video en Playwright CLI: grabación, capítulos, overlays y compromisos de depuración

Wed, 15 Apr 2026 08:22:45 +0800

Si quieres grabar sesiones de automatización de navegador como video para depuración, documentación o prueba de trabajo, Playwright CLI ya ofrece un flujo bastante directo. Produce video WebM usando el códec VP8/VP9.

Este artículo sigue la referencia oficial video-recording y se centra en las partes más importantes en la práctica: flujo básico de grabación, marcadores de capítulo, grabación completa de hero scripts, Overlay API y la diferencia entre video y tracing. Se conservan las líneas de comando, snippets de código y detalles de parámetros de la referencia.

01 Flujo básico de grabación

El patrón básico es simple: abrir el navegador, iniciar grabación, realizar acciones y luego detener y guardar.

# Open browser first
playwright-cli open

# Start recording
playwright-cli video-start demo.webm

# Add a chapter marker for section transitions
playwright-cli video-chapter "Getting Started" --description="Opening the homepage" --duration=2000

# Navigate and perform actions
playwright-cli goto https://example.com
playwright-cli snapshot
playwright-cli click e1
# Add another chapter
playwright-cli video-chapter "Filling Form" --description="Entering test data" --duration=2000
playwright-cli fill e2 "test input"

# Stop and save
playwright-cli video-stop

Estos comandos ya cubren el flujo de grabación más común. video-chapter es útil para insertar tarjetas de capítulo entre etapas, de modo que el video final sea más fácil de seguir.

02 Buenas prácticas

1. Usar nombres de archivo descriptivos

Si el video es para otras personas o para revisarlo más tarde, el nombre del archivo debería incluir suficiente contexto para entenderlo de un vistazo.

1
2
3

# Include context in filename
playwright-cli video-start recordings/login-flow-2024-01-15.webm
playwright-cli video-start recordings/checkout-test-run-42.webm

2. Grabar hero scripts completos

La recomendación oficial es que, cuando un video sea para un usuario o sirva como prueba de trabajo, lo mejor es convertir el escenario en un snippet de código y ejecutarlo con run-code. Eso da mejor control sobre ritmo, pausas y anotaciones en el video. La referencia también señala que Playwright ahora incluye APIs diseñadas específicamente para este tipo de flujo de grabación.

El proceso sugerido es:

Primero realiza el escenario con la CLI y anota todos los locators y acciones. Necesitarás esos locators más tarde si quieres sus bounding boxes para overlays de resaltado.
Crea un archivo de script dedicado para el video y escríbelo con el estilo mostrado abajo. Usa pressSequentially con delay para una escritura más suave, y añade pausas donde resulten naturales.
Usa playwright-cli run-code --filename your-script.js.

Importante: los overlays son pointer-events: none, así que no interfieren con las interacciones de la página. Puedes mantener overlays adhesivos visibles mientras haces clic, rellenas campos o realizas cualquier acción.

async page => {
  await page.screencast.start({ path: 'video.webm', size: { width: 1280, height: 800 } });
  await page.goto('https://demo.playwright.dev/todomvc');
  // Show a chapter card - blurs the page and shows a dialog.
  // Blocks until duration expires, then auto-removes.
  // Use this for simple use cases, but always feel free to hand-craft your own beautiful
  // overlay via await page.screencast.showOverlay().
  await page.screencast.showChapter('Adding Todo Items', {
    description: 'We will add several items to the todo list.',
    duration: 2000,
  });
  // Perform action
  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Walk the dog', { delay: 60 });
  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
  await page.waitForTimeout(1000);

  // Show next chapter
  await page.screencast.showChapter('Verifying Results', {
    description: 'Checking the item appeared in the list.',
    duration: 2000,
  });
  // Add a sticky annotation that stays while you perform actions.
  // Overlays are pointer-events: none, so they won't block clicks.
  const annotation = await page.screencast.showOverlay(`
    <div style="position: absolute; top: 8px; right: 8px;
      padding: 6px 12px; background: rgba(0,0,0,0.7);
      border-radius: 8px; font-size: 13px; color: white;">
      Item added successfully
    </div>
  `);
  // Perform more actions while the annotation is visible
  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Buy groceries', { delay: 60 });
  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
  await page.waitForTimeout(1500);

  // Remove the annotation when done
  await annotation.dispose();
  // You can also highlight relevant locators and provide contextual annotations.
  const bounds = await page.getByText('Walk the dog').boundingBox();
  await page.screencast.showOverlay(`
    <div style="position: absolute;
      top: ${bounds.y}px;
      left: ${bounds.x}px;
      width: ${bounds.width}px;
      height: ${bounds.height}px;
      border: 1px solid red;">
    </div>
    <div style="position: absolute;
      top: ${bounds.y + bounds.height + 5}px;
      left: ${bounds.x + bounds.width / 2}px;
      transform: translateX(-50%);
      padding: 6px;
      background: #808080;
      border-radius: 10px;
      font-size: 14px;
      color: white;">Check it out, it is right above this text
    </div>
  `, { duration: 2000 });
  await page.screencast.stop();
}

El valor de este script no está solo en que graba el flujo, sino en que vuelve el video más fácil de entender: las tarjetas de capítulo gestionan transiciones, pressSequentially hace que la escritura se vea natural y showOverlay añade explicación, resaltado y contexto.

La referencia cierra esta sección con un recordatorio breve: abraza la creatividad; los overlays son potentes.

03 Resumen de Overlay API

Al grabar video, la Overlay API es especialmente útil para transiciones de sección, llamadas locales y anotaciones adhesivas. El resumen oficial es:

Method	Use Case
`page.screencast.showChapter(title, { description?, duration?, styleSheet? })`	Tarjeta de capítulo a pantalla completa con fondo desenfocado, ideal para transiciones de sección
`page.screencast.showOverlay(html, { duration? })`	Overlay HTML personalizado, útil para callouts, etiquetas y resaltados
`disposable.dispose()`	Elimina un overlay adhesivo añadido sin duración
`page.screencast.hideOverlays()` / `page.screencast.showOverlays()`	Oculta o muestra temporalmente todos los overlays

Si tu objetivo es convertir la automatización en un video cómodo de ver, este conjunto de APIs es una de las partes más valiosas que aprender primero.

04 Tracing vs video

La documentación oficial deja muy clara la diferencia entre ambos:

Feature	Video	Tracing
Output	WebM file	Trace file (viewable in Trace Viewer)
Shows	Visual recording	DOM snapshots, network, console, actions
Use case	Demos, documentation	Debugging, analysis
Size	Larger	Smaller

Una forma simple de pensarlo:

video es mejor para demos, entregas y revisar lo que vería un usuario
tracing es mejor para depurar, inspeccionar detalles de acciones y analizar contexto de ejecución

No se reemplazan entre sí. Cada uno sirve a un propósito diferente.

05 Limitaciones

La referencia también señala dos limitaciones prácticas:

La grabación añade una ligera sobrecarga a la automatización
Las grabaciones largas pueden consumir bastante espacio en disco

Así que, aunque la grabación de video es muy útil, añade cierta sobrecarga de runtime y las grabaciones largas pueden crecer mucho en disco.

06 Resumen rápido

Si solo quieres lo esencial, recuerda estos puntos:

video-start / video-stop son los comandos principales para grabar
video-chapter añade transiciones de sección y facilita seguir las demos
Los escenarios de grabación más avanzados se escriben mejor como scripts y se ejecutan con run-code
showOverlay y showChapter pueden mejorar mucho la legibilidad del video
video es mejor para demos, mientras tracing es mejor para depuración

Si tu flujo ya incluye demos de automatización, evidencia de aceptación o grabaciones de prueba de trabajo, video recording es una parte de Playwright CLI que vale mucho la pena añadir.

Referencias

Referencia video-recording de Playwright CLI: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/video-recording.md
Página principal de Playwright CLI: https://github.com/microsoft/playwright-cli

Gestión de sesiones en Playwright CLI: múltiples sesiones de navegador, aislamiento, persistencia y limpieza

Wed, 15 Apr 2026 08:15:12 +0800

Si usas Playwright CLI para automatización, pronto aparece una pregunta práctica: ¿puedes abrir varias sesiones de navegador al mismo tiempo sin que interfieran entre sí? La respuesta es sí, y Playwright CLI ya hace que este mecanismo sea bastante directo.

Siguiendo la referencia oficial session-management, este artículo se centra en sus piezas más prácticas: sesiones nombradas, aislamiento de sesiones, perfiles persistentes, patrones concurrentes y comandos comunes de limpieza. Se conservan las líneas de comando y las explicaciones de bloques de comandos de la referencia.

01 Sesiones de navegador nombradas

La recomendación oficial es usar el parámetro -s para aislar diferentes contextos de navegador:

# Browser 1: Authentication flow
playwright-cli -s=auth open https://app.example.com/login

# Browser 2: Public browsing (separate cookies, storage)
playwright-cli -s=public open https://example.com

# Commands are isolated by browser session
playwright-cli -s=auth fill e1 "user@example.com"
playwright-cli -s=public snapshot

El punto clave es que distintos nombres de session se asignan a distintos contextos de navegador. Puedes usar auth para el flujo de login y public para navegación anónima, y no compartirán cookies ni estado local.

02 Qué separa el aislamiento de sesiones

Cada sesión de navegador mantiene de forma independiente:

Cookies
LocalStorage / SessionStorage
IndexedDB
Caché
Historial de navegación
Pestañas abiertas

Eso significa que si inicias sesión en un sitio dentro de la sesión auth, no afectará automáticamente a la sesión public. Esto es especialmente importante para pruebas multi-cuenta, verificación de estado de login y comparaciones entre navegación anónima y autenticada.

03 Comandos relacionados con sesiones de navegador

La documentación oficial agrupa los comandos de gestión de sesiones más usados:

# List all browser sessions
playwright-cli list

# Stop a browser session (close the browser)
playwright-cli close                 # stop the default browser
playwright-cli -s=mysession close   # stop a named browser

# Stop all browser sessions
playwright-cli close-all

# Forcefully kill all daemon processes (for stale/zombie processes)
playwright-cli kill-all

# Delete browser session user data (profile directory)
playwright-cli delete-data              # delete default browser data
playwright-cli -s=mysession delete-data # delete named browser data

Puedes pensarlos como tres tipos de operaciones:

list: ver qué sesiones existen actualmente
close / close-all / kill-all: detener sesiones o limpiar procesos de navegador atascados
delete-data: eliminar el directorio de datos de usuario de una sesión concreta

Si solo quieres cerrar un navegador, close suele ser la primera opción. Si ya quedaron procesos residuales, kill-all encaja mejor.

04 Definir una sesión predeterminada con variable de entorno

Si no quieres repetir -s=mysession en cada comando, la documentación oficial también ofrece un enfoque con variable de entorno:

1
2

export PLAYWRIGHT_CLI_SESSION="mysession"
playwright-cli open example.com  # Uses "mysession" automatically

Después de eso, cuando no especifiques -s, el comando usará mysession como sesión de navegador predeterminada.

05 Patrón común: scraping concurrente

La referencia da un ejemplo muy típico de scraping concurrente:

#!/bin/bash
# Scrape multiple sites concurrently

# Start all browsers
playwright-cli -s=site1 open https://site1.com &
playwright-cli -s=site2 open https://site2.com &
playwright-cli -s=site3 open https://site3.com &
wait

# Take snapshots from each
playwright-cli -s=site1 snapshot
playwright-cli -s=site2 snapshot
playwright-cli -s=site3 snapshot

# Cleanup
playwright-cli close-all

Este patrón funciona bien cuando quieres abrir varios sitios a la vez, capturar el estado de cada página y luego limpiarlo todo junto. Como cada sitio corre en una sesión independiente, no contaminan el estado local de los demás.

06 Patrón común: sesiones de A/B testing

Otro escenario común es comparar distintas variantes de experimento al mismo tiempo:

# Test different user experiences
playwright-cli -s=variant-a open "https://app.com?variant=a"
playwright-cli -s=variant-b open "https://app.com?variant=b"

# Compare
playwright-cli -s=variant-a screenshot
playwright-cli -s=variant-b screenshot

Este estilo es muy útil para comparaciones A/B de páginas porque las dos variantes se ejecutan en sesiones separadas, haciendo más fácil gestionar capturas y comprobaciones de estado de forma independiente.

07 Persistencia de perfiles de navegador

La documentación oficial señala específicamente que, por defecto, los perfiles de navegador se almacenan solo en memoria.

Si quieres persistir un perfil en disco, añade --persistent al ejecutar open:

# Use persistent profile (auto-generated location)
playwright-cli open https://example.com --persistent

# Use persistent profile with custom directory
playwright-cli open https://example.com --profile=/path/to/profile

Esta capacidad es útil cuando necesitas reutilizar estado de login, caché local o un entorno de depuración con extensiones durante más tiempo. Al depurar repetidamente el mismo sitio, un perfil persistente suele ser mucho más eficiente que empezar desde cero cada vez.

08 La sesión de navegador predeterminada

Si no se proporciona -s explícitamente, el comando usa la sesión de navegador predeterminada:

# These use the same default browser session
playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli close  # Stops default browser

En otras palabras, los comandos sin -s se ejecutan de forma continua dentro de la misma sesión predeterminada.

09 Configuración de arranque relacionada con sesiones

Además del nombre de sesión, la documentación oficial muestra varios patrones comunes de configuración de arranque:

# Open with config file
playwright-cli open https://example.com --config=.playwright/my-cli.json

# Open with specific browser
playwright-cli open https://example.com --browser=firefox

# Open in headed mode
playwright-cli open https://example.com --headed

# Open with persistent profile
playwright-cli open https://example.com --persistent

Estos parámetros pueden combinarse con la gestión de sesiones. Por ejemplo, puedes hacer que una sesión nombrada siempre use firefox, o que una sesión concreta arranque siempre en modo headed para inspección manual más cómoda.

10 Buenas prácticas de la documentación oficial

La referencia enumera tres buenas prácticas.

1. Usar nombres de sesión significativos

# GOOD: Clear purpose
playwright-cli -s=github-auth open https://github.com
playwright-cli -s=docs-scrape open https://docs.example.com

# AVOID: Generic names
playwright-cli -s=s1 open https://github.com

Los nombres de sesión deberían comunicar directamente su propósito. Nombres como github-auth y docs-scrape hacen mucho más claro el mantenimiento posterior de scripts.

2. Limpiar puntualmente después de usar

# Stop browsers when done
playwright-cli -s=auth close
playwright-cli -s=scrape close

# Or stop all at once
playwright-cli close-all

# If browsers become unresponsive or zombie processes remain
playwright-cli kill-all

Si no cierras el navegador al terminar una tarea, la sesión y los procesos en segundo plano permanecen. Puede no parecer grave al principio, pero cuando las tareas se acumulan, el entorno se vuelve desordenado rápidamente.

3. Eliminar datos de navegador obsoletos

1
2

# Remove old browser data to free disk space
playwright-cli -s=oldsession delete-data

Cuando algunas sesiones antiguas ya no hacen falta, borrar sus directorios de datos ahorra espacio y también ayuda a evitar reutilizar accidentalmente estado obsoleto.

11 Resumen rápido

Si solo quieres lo esencial, recuerda estos puntos:

-s=<name> crea y usa una sesión de navegador independiente
Distintas sesiones aíslan cookies, distintos tipos de storage, caché, historial y pestañas
close-all sirve para cierre unificado, mientras kill-all ayuda a limpiar procesos anormales
--persistent escribe el perfil en disco y es útil para reutilizar estado a largo plazo
Los nombres de sesión deberían ser significativos, y los datos antiguos deberían limpiarse regularmente

Si tu flujo ya incluye reutilización de estados de login, trabajo paralelo multi-cuenta, comparaciones A/B o scraping por lotes, entonces session management es una de las partes de Playwright CLI que más vale la pena aprender primero.

Referencias

Referencia session-management de Playwright CLI: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md
Página principal de Playwright CLI: https://github.com/microsoft/playwright-cli

Storage state en Playwright CLI: guardar sesiones de login, leer cookies y local storage

Tue, 14 Apr 2026 22:19:55 +0800

Si usas Playwright CLI para automatización de navegador, storage state es una de las funciones más útiles. Su tarea es simple: guardar la sesión de login actual y el estado local del navegador para reutilizarlos después en lugar de iniciar sesión cada vez.

01 Guardar el storage state actual

El flujo más común es iniciar sesión una vez y luego exportar el estado actual a un archivo.

`1`	`playwright-cli storage-state save auth.json`

Este comando guarda el estado del contexto de navegador actual en auth.json. Si quieres reutilizar una sesión iniciada más tarde, este suele ser el primer paso.

02 Cargar un storage state existente

Cuando ya tienes un archivo de estado, puedes cargarlo directamente al arrancar.

`1`	`playwright-cli --storage-state auth.json`

Inicia el contexto de navegador con el estado guardado en auth.json. El propósito habitual es evitar logins repetidos y entrar directamente en un entorno autenticado.

03 Ver cookies actuales

Si solo quieres revisar qué cookies existen en la sesión actual, puedes inspeccionarlas directamente.

`1`	`playwright-cli cookies`

Este comando lista las cookies del contexto actual. Es útil para comprobar si existe el estado de login o si las cookies se escribieron correctamente.

04 Configurar cookies

Si ya tienes datos de cookies, también puedes inyectarlos directamente.

`1`	`playwright-cli cookies set '[{"name":"session","value":"abc","domain":"example.com","path":"/"}]'`

Esto es útil para depuración de autenticación, reproducir una sesión específica o inyectar condiciones de cookies antes de ejecutar un script.

05 Leer localStorage

Algunos sitios guardan estado relacionado con login o frontend no solo en cookies, sino también en localStorage.

`1`	`playwright-cli local-storage`

Este comando muestra el contenido de localStorage de la página actual. Es especialmente útil cuando una página parece estar autenticada, pero sigue comportándose mal.

06 Escribir localStorage

Si necesitas simular un estado frontend específico, puedes configurarlo directamente.

`1`	`playwright-cli local-storage set token abc123`

Escribe la clave y el valor indicados en localStorage. Usos comunes incluyen inyectar un token, una preferencia o una bandera de frontend.

07 Leer sessionStorage

sessionStorage sirve para revisar estado temporal ligado a la sesión actual.

`1`	`playwright-cli session-storage`

Este comando muestra el sessionStorage de la página actual. Si un flujo depende de datos de sesión de un solo uso, este es un buen lugar para inspeccionarlo.

08 Escribir sessionStorage

Cuando haga falta, también puedes configurar sessionStorage manualmente.

`1`	`playwright-cli session-storage set key value`

Es útil para reproducir comportamiento de página que depende de estado temporal, o para completar campos requeridos por un paso de inicialización.

09 Ver IndexedDB

En aplicaciones web más pesadas, los datos locales más importantes pueden vivir realmente en IndexedDB.

`1`	`playwright-cli indexed-db`

Este comando permite inspeccionar los datos IndexedDB de la página actual. Conviene revisarlo primero cuando trabajas con SPAs complejas, caché offline o bases de datos locales tipo aplicación.

10 Un flujo práctico

Si tu objetivo es simplemente reutilizar de forma fiable una sesión de login, el flujo más práctico suele ser este:

Abre el sitio y completa el login manualmente.
Guarda el estado con este comando:

`1`	`playwright-cli storage-state save auth.json`

Cárgalo directamente en ejecuciones posteriores:

`1`	`playwright-cli --storage-state auth.json`

Si la página sigue comportándose mal después de cargarlo, continúa revisando:

playwright-cli cookies
playwright-cli local-storage
playwright-cli session-storage
playwright-cli indexed-db

Esa secuencia cubre la mayoría de casos donde el estado restaurado está incompleto.

11 Qué tener en cuenta

Tres puntos importan especialmente:

Un archivo de storage state contiene datos sensibles. Puede incluir cookies o tokens de login, así que no lo commitees casualmente.
Restaurar solo cookies puede no bastar. Muchos sitios modernos también dependen de localStorage, sessionStorage o IndexedDB.
Los archivos de estado no son válidos para siempre. Tras expiración de cookies, cambios de cuenta o cambios de entorno, normalmente hay que generarlos de nuevo.

12 Resumen rápido

Si solo recuerdas una frase:

storage state en Playwright CLI significa guardar el estado actual del navegador y reutilizarlo en tareas posteriores.

En la práctica, los comandos más útiles son:

playwright-cli storage-state save auth.json
playwright-cli --storage-state auth.json
playwright-cli cookies
playwright-cli local-storage
playwright-cli session-storage
playwright-cli indexed-db

Primero guarda y luego carga; si algo sigue viéndose mal, inspecciona cookies y las distintas capas de almacenamiento local una por una. Esa es la parte más práctica de esta referencia.

Referencias

Referencia storage-state de Playwright CLI: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/storage-state.md
Página del proyecto Playwright CLI: https://github.com/microsoft/playwright-cli

Primeros pasos con Playwright CLI: instalación, Skills, sesiones y comandos esenciales

Sun, 12 Apr 2026 14:36:58 +0800

Si has usado Claude Code, GitHub Copilot u otros agentes de programación para automatización de navegador, microsoft/playwright-cli es una herramienta que vale la pena observar. No es el ayudante de navegador tradicional pensado principalmente para humanos escribiendo comandos a mano. Es una CLI de Playwright diseñada para agentes de programación, con énfasis en menor sobrecarga de tokens, una interfaz de comandos más ligera e integración con flujos basados en Skills.

Según el README oficial, la idea central de Playwright CLI es clara: frente a MCP, que puede empujar grandes esquemas de herramientas y estructura de página al contexto del modelo, el enfoque CLI es más compacto y encaja mejor con flujos de agentes que alternan constantemente entre codebases grandes, pruebas y automatización de navegador.

01 Qué es Playwright CLI

playwright-cli es una herramienta open source de línea de comandos para Playwright creada por Microsoft. La descripción oficial es “CLI for common Playwright actions”. Se usa principalmente para tareas como:

Abrir páginas y controlar el navegador
Grabar y generar código Playwright
Capturar snapshots de página para obtener referencias de elementos
Tomar capturas de pantalla y exportar PDFs
Trabajar con agentes de programación para automatización de pruebas e interacción web

El README actual de GitHub es muy explícito sobre su posicionamiento: si usas agentes de programación, la CLI suele encajar mejor que Playwright MCP; si necesitas estado persistente, introspección más rica y bucles agentic de larga duración, MCP sigue teniendo su lugar.

En otras palabras, Playwright CLI se siente más como una interfaz de automatización de navegador construida para asistentes AI de programación, no solo como una herramienta para que ingenieros hagan clic manualmente.

02 Dónde destaca

1. Encaja mejor con flujos de agentes

El README oficial enumera Token-efficient como una característica clave. No obliga a meter todos los datos de la página en el contexto del LLM. En su lugar, permite que el agente opere el navegador mediante comandos más cortos y enfocados.

Esto importa mucho para agentes de programación. En proyectos reales, un agente no solo controla el navegador. También tiene que leer código, editar archivos, ejecutar pruebas e inspeccionar logs. Si la interfaz del navegador consume demasiado contexto, todo el flujo se vuelve menos eficiente.

2. Funciona bien con Skills

El README destaca específicamente playwright-cli install --skills. Eso muestra que Microsoft no lo trata solo como otra utilidad de shell, sino como algo que Claude Code, GitHub Copilot y agentes similares pueden consumir directamente mediante un flujo basado en Skills.

Si tu configuración ya depende de Skills, Playwright CLI debería encajar de forma natural.

3. La gestión de sesiones es bastante completa

Playwright CLI soporta sesiones. De forma predeterminada, el perfil del navegador permanece en memoria, así que cookies y storage state se conservan entre varias llamadas CLI dentro de la misma sesión. Si añades --persistent, el perfil puede guardarse en disco y reutilizarse tras reiniciar el navegador.

Esto lo vuelve mucho más práctico que herramientas que abren un navegador para un solo comando y luego descartan todo. También encaja mejor con ciclos largos de depuración y flujos de agentes más extensos.

4. Incluye un panel visual de monitoreo

El README ofrece playwright-cli show, que abre un panel para observar y controlar todas las sesiones de navegador en ejecución. Esto es especialmente útil cuando un agente ejecuta automatización en segundo plano, porque puedes intervenir, inspeccionar el progreso y ayudar a depurar en lugar de trabajar a ciegas.

03 Instalación y requisitos

Según el README actual de GitHub, los requisitos básicos de Playwright CLI son:

Node.js 18 o más reciente
Claude Code, GitHub Copilot u otro agente de programación

Los comandos de instalación son:

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

Hay un error fácil que conviene destacar:

El paquete recomendado oficialmente ahora es @playwright/cli
No lo confundas con el antiguo paquete npm deprecado playwright-cli

Así que el paquete correcto es el scoped package, no el paquete histórico antiguo.

04 Cómo empezar a usarlo

1. Instalar skills

Si quieres que un agente de programación use Playwright CLI directamente, la recomendación oficial es instalar primero las skills:

`1`	`playwright-cli install --skills`

El README dice explícitamente que Claude Code, GitHub Copilot y herramientas similares usarán las skills instaladas localmente.

2. Dejar que el agente llame directamente a la CLI

Si no quieres manejar Skills primero, también puedes pedir al agente que lea la ayuda de la CLI directamente:

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

El README llama a esto “Skills-less operation”. La idea es que incluso sin skills preinstaladas, la CLI puede describirse lo bastante bien para que un agente la use.

3. Probar manualmente un flujo mínimo

El README incluye un ejemplo con TodoMVC que funciona muy bien como primera demostración práctica:

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

Esta secuencia es útil porque muestra rápidamente cómo trabaja Playwright CLI:

open abre la página
type y press gestionan entrada de texto
check usa una referencia de elemento para alternar checkboxes
screenshot guarda el resultado

05 `--headed`, sesiones y panel de monitoreo

`--headed`

Playwright CLI es headless por defecto. Si quieres ver directamente la ventana del navegador, debes pasar --headed al usar open:

`1`	`playwright-cli open https://playwright.dev --headed`

Esto es especialmente útil al depurar selectores, flujos de login o cualquier interacción que sea más fácil inspeccionar visualmente.

sesiones

El README oficial da mucha importancia a las sesiones. Puedes usar distintas sesiones para aislar diferentes proyectos o sitios:

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

Si dejas que un agente trabaje durante más tiempo, también puedes pasar la sesión mediante una variable de entorno:

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

Comandos útiles de gestión de sesiones:

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

En la práctica:

list muestra todas las sesiones
close-all cierra todos los navegadores de forma ordenada
kill-all termina forzosamente todos los procesos de navegador

Panel de monitoreo

Si quieres ver qué está haciendo realmente el agente en el navegador, puedes ejecutar:

`1`	`playwright-cli show`

Según el README, este panel tiene dos vistas principales:

Session grid: muestra sesiones activas por workspace, con vista previa en vivo, URL y título de página
Session detail: muestra una vista en vivo de una sesión seleccionada y permite tomar control del ratón y teclado

Eso significa que Playwright CLI no solo es usable desde la línea de comandos. También tiene una capa de observabilidad bastante madura.

06 Qué comandos conviene memorizar primero

Si es tu primera vez con Playwright CLI, no necesitas memorizar todos los comandos. Estos son los principales:

Páginas e interacción

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

Obtener estructura de página

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

snapshot es especialmente importante porque muchas operaciones posteriores dependen de referencias de elementos almacenadas como ref. En la práctica, normalmente capturas un snapshot primero y luego usas los identificadores devueltos para hacer clic, rellenar, marcar o tomar capturas.

Guardar salida

1
2

playwright-cli screenshot
playwright-cli pdf

Pestañas

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 Quién debería probarlo

Playwright CLI merece probarse especialmente en estos escenarios:

Usas Claude Code, Copilot u otro agente de programación para pruebas E2E
Quieres una interfaz de automatización de navegador más ligera sin empujar grandes estructuras de página al contexto del modelo
Quieres que una sesión de navegador persista entre múltiples comandos
Quieres monitorear tareas web impulsadas por agentes mediante un panel mientras se ejecutan

Si tu pregunta principal es cómo hacer que la automatización de navegador funcione de forma eficiente con agentes de programación, Playwright CLI probablemente se sentirá más natural que los flujos tradicionales de depuración manual.

Playwright on KnightLi Blog

ai-goofish-monitor: sistema open-source para vigilar anuncios de Goofish con IA

Resumen rápido

Qué problema resuelve

Funciones principales

Flujo de trabajo

Despliegue con Docker

Configuración mínima

Primer uso

Tareas de IA y tareas por palabra clave

Qué permite la Web UI

Almacenamiento de datos

Canales de notificación

Ejecución para desarrolladores

Para quién sirve

Riesgos y límites

Diferencia con scripts comunes

Cómo usarlo

Resumen

Grabación de video en Playwright CLI: grabación, capítulos, overlays y compromisos de depuración

01 Flujo básico de grabación

02 Buenas prácticas

1. Usar nombres de archivo descriptivos

2. Grabar hero scripts completos

03 Resumen de Overlay API

04 Tracing vs video

05 Limitaciones

06 Resumen rápido

Referencias

Gestión de sesiones en Playwright CLI: múltiples sesiones de navegador, aislamiento, persistencia y limpieza

01 Sesiones de navegador nombradas

02 Qué separa el aislamiento de sesiones

03 Comandos relacionados con sesiones de navegador

04 Definir una sesión predeterminada con variable de entorno

05 Patrón común: scraping concurrente

06 Patrón común: sesiones de A/B testing

07 Persistencia de perfiles de navegador

08 La sesión de navegador predeterminada

09 Configuración de arranque relacionada con sesiones

10 Buenas prácticas de la documentación oficial

1. Usar nombres de sesión significativos

2. Limpiar puntualmente después de usar

3. Eliminar datos de navegador obsoletos

11 Resumen rápido

Referencias

Storage state en Playwright CLI: guardar sesiones de login, leer cookies y local storage

01 Guardar el storage state actual

02 Cargar un storage state existente

03 Ver cookies actuales

04 Configurar cookies

05 Leer localStorage

06 Escribir localStorage

07 Leer sessionStorage

08 Escribir sessionStorage

09 Ver IndexedDB

10 Un flujo práctico

11 Qué tener en cuenta

12 Resumen rápido

Referencias

Primeros pasos con Playwright CLI: instalación, Skills, sesiones y comandos esenciales

01 Qué es Playwright CLI

02 Dónde destaca

1. Encaja mejor con flujos de agentes

2. Funciona bien con Skills

3. La gestión de sesiones es bastante completa

4. Incluye un panel visual de monitoreo

03 Instalación y requisitos

04 Cómo empezar a usarlo

1. Instalar skills

2. Dejar que el agente llame directamente a la CLI

3. Probar manualmente un flujo mínimo

05 --headed, sesiones y panel de monitoreo

--headed

sesiones

Panel de monitoreo

06 Qué comandos conviene memorizar primero

Páginas e interacción

Obtener estructura de página

Guardar salida

Pestañas

05 `--headed`, sesiones y panel de monitoreo

`--headed`