Cómo hacer que la IA opere páginas web con Page-Agent: GUI Agent integrado, automatización de formularios y límites de permisos

Sun, 12 Jul 2026 12:14:00 +0800

Page-Agent no equivale a dar a un Agent el control de todo el navegador: inserta JavaScript en tu página para que la página tenga su propio GUI Agent. Según la documentación, usa principalmente operaciones DOM textualizadas y no depende de capturas, modelos multimodales, Python ni headless browser. Para tareas multipágina ofrece una extensión de Chrome y un MCP Server Beta. README del proyecto

Es útil para añadir asistencia de «completar una secuencia con una frase» a ERP, CRM, formularios administrativos y herramientas internas, pero no evita permisos del producto. Cada acción sigue sometida a autorización existente, validación del servidor y confirmación humana.

Cuándo elegir Page-Agent o automatización de navegador

Objetivo	Opción más adecuada
Integrar un asistente de lenguaje natural en tu producto Web	Page-Agent
Pruebas de regresión, scraping entre sitios, scripts deterministas	Playwright o Puppeteer
Hacer que un coding agent revise red, consola y rendimiento	Chrome DevTools MCP
Controlar el Chrome real del usuario conservando su sesión	Herramientas como browser-harness

Consulta también la comparativa de browser-harness, Playwright y Puppeteer. Page-Agent no sustituye un framework de pruebas: convierte la capacidad de operar en una función de producto.

Configura una instancia mínima desde NPM

Instala primero el paquete:

`1`	`npm install page-agent`

Crea la instancia en el punto de entrada del frontend. El endpoint del modelo, la clave y las operaciones permitidas deben gestionarse en el servidor o en configuración de seguridad; no escribas una clave de producción en código del navegador.

import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://your-compatible-api.example/v1',
  apiKey: 'USE_A_SCOPED_KEY',
  language: 'zh-CN',
})

await agent.execute('在当前页面找到“新建客户”按钮，但不要提交表单')

El ejemplo solo comprueba reconocimiento DOM y ubicación del botón. En un entorno real, apiKey debe ser temporal, limitado y revocable. No entregues secretos universales, tokens de usuario ni credenciales administrativas al script de la página.

Orden recomendado: lectura, borrador y envío

Empieza por una página con pocos campos y pocos permisos, como un filtro de clientes o un borrador de ticket. En la primera fase permite solo localizar elementos, leer texto visible y sugerir operaciones. Usa datos de prueba para confirmar que el Agent distingue registros homónimos y estados. No permitas guardar, subir adjuntos ni navegar a dominios externos.

En la segunda fase permite rellenar formularios. Limita la entrada a parámetros estructurados, como ID de cliente, porcentaje de descuento y fecha de vigencia, en vez de una petición vaga. Muestra los campos que el Agent va a escribir; el servidor vuelve a validar si el rol puede editarlos y si el valor está dentro del rango. Solo tras confirmar la página llama al API de negocio existente, sin una vía trasera para el Agent.

Considera el envío solo en la tercera fase. Debe pasar por el mismo API, registro de auditoría y doble confirmación que el botón humano. Tras completarse, lee y muestra el ID, la versión y los errores devueltos. Así un malentendido del modelo queda detenido por la vista previa, permisos o validación del servidor.

Divide las tareas en etapas auditables

En la automatización de formularios, el problema suele ser el objeto o el efecto lateral, no el clic. Divide el proceso:

Buscar: leer únicamente campos visibles y registros candidatos.
Rellenar un borrador: escribir solo en el formulario local, sin enviar ni subir adjuntos.
Mostrar diferencias: presentar al usuario los campos y valores que se escribirán.
Enviar: ejecutar solo tras confirmación del usuario y autorización del servidor.

No entregues directamente al Agent «crea un descuento del 20% para el cliente A». Haz que cree el borrador, muestre ID, regla y vigencia, y permite que una persona autorizada lo envíe.

Reduce capacidades a una lista permitida de acciones

No trates cada elemento DOM como una herramienta invocable. Define acciones de negocio como searchCustomer, fillDiscountDraft, previewDiscount y submitDiscount, indicando si son de lectura, reversibles o con efectos. El Agent elige la acción y el frontend realiza la interacción. No registres acciones de alto riesgo—borrar, reembolsar, invitar miembros o exportar datos—o exige siempre confirmación manual.

Registra usuario, página, acción, resumen de entrada, resultado y motivo de fallo. Los registros deben estar redactados y no guardar claves completas, cookies ni campos sensibles. Ante un error, deben responder qué vio y propuso el Agent y quién confirmó al final.

Límites de inicio de sesión, multipágina y MCP

Page-Agent puede usar la sesión existente de la página, pero eso no justifica ampliar permisos. Evita:

Permitir que extraiga o muestre cookies, contraseñas o códigos de verificación desde lenguaje natural.
Enviar datos autenticados a un endpoint de modelo no revisado.
Saltar doble confirmación, confirmación de pago o aprobación de roles con «automatización».
Abrir capacidades multipágina para todos los usuarios por defecto.

Al usar la extensión oficial de Chrome o MCP Server para multipágina o control por Agent externo, establece listas permitidas de dominios y acciones y registros de auditoría. Prueba las capacidades Beta antes de conectarlas a administración de producción.

Valida con tareas reales antes del lanzamiento

Elige de tres a cinco tareas de bajo riesgo de soporte u operaciones, como filtrar clientes pendientes, completar campos de un ticket o ir de un pedido a su cliente. Para cada una prepara casos de éxito, ambigüedad y falta de permisos: el éxito llega a vista previa; la ambigüedad pregunta o se detiene; la falta de permisos la rechaza el backend sin filtrar datos adicionales.

No compruebes solo si pulsó el botón correcto. Comprueba tiempo de primera respuesta, explicabilidad del fallo, corrección del borrador tras recargar y conservación de datos no enviados ante cortes o timeout del modelo. Amplía el alcance solo después de superarlo.

Lista de solución de problemas

Problema	Qué hacer
No encuentra botón o campo	Revisa renderizado dinámico, iframe o capas superpuestas, y estabilidad del texto.
El Agent eligió el registro equivocado	Añade ID único, vista previa de solo lectura y eco de resultado; no coincidas solo por nombre.
Falló la llamada al modelo	Revisa API compatible, cuota, CORS y punto de inyección de clave; nunca registres secretos en frontend.
El formulario está lleno pero el resultado es incorrecto	Separa rellenar de enviar y lee la respuesta del servidor tras enviar.

Resumen

El objetivo de Page-Agent no es que una página entienda una frase, sino limitar las acciones en lenguaje natural a flujos observables, reversibles y aprobables. Valida primero consultas de solo lectura y borradores, y abre efectos laterales gradualmente.

Page-Agent on KnightLi Blog