Computer use, browser use o Playwright en pruebas de UI

¿De cuántas maneras puede un agente ver una interfaz?

Cuando un agente de programación cambia una interfaz, el trabajo no termina ahí: tiene que ver que el cambio funciona de verdad. Este ciclo, en el que el agente comprueba su propio trabajo, lo contamos en el artículo sobre harness engineering. En una interfaz hay tres maneras de hacer esa comprobación, y las tres vienen ya listas en las herramientas de programación:

Con computer use, el agente ve la pantalla como una imagen y trabaja con el ratón y el teclado. La herramienta de Anthropic ofrece capturas de pantalla y control del ratón y del teclado. La documentación de Google también dice que el modelo «ve» la pantalla a través de imágenes y genera acciones como clics y pulsaciones de teclas. Esta vía llega a todo lo que hay en pantalla: la herramienta de Google funciona en el navegador, en el móvil y en el escritorio.

Con browser use, el agente no mira la imagen de la página, sino su estructura. La herramienta de browser use de Anthropic lee la página del árbol de accesibilidad: cada elemento llega con su rol, su nombre y una referencia como [ref_2], y al hacer clic el agente pasa esa referencia en lugar de coordenadas. Donde el árbol no ve nada, por ejemplo en un canvas, vuelve a las capturas y a las coordenadas. Playwright MCP también lee la página de este árbol en lugar de capturas de pantalla. La biblioteca de código abierto Browser Use que aparece en los resultados de búsqueda es un proyecto aparte; en este artículo, «browser use» es este método.

En la vía de código y tests, el agente maneja el navegador a través de una biblioteca: escribe un test de Playwright o llama a la CLI de Playwright. Playwright CLI no carga los datos de la página en el modelo; el agente solo lee la salida del comando. La guía de computer use de OpenAI también recomienda la vía del código para GPT-6 Astra: el modelo escribe código de Playwright o PyAutoGUI que maneja la interfaz, y la herramienta estructurada computer queda como alternativa. Lo que de verdad distingue al código es que, una vez escrito, puede volver a ejecutarse sin modelo.

¿Cuánto cuesta cada vía y qué fiabilidad tiene?

Comparamos las tres vías con tres preguntas: cuántos tokens cuesta un paso, cuánto dura una tarea y con qué frecuencia se completa una tarea de principio a fin. La mayoría de las cifras vienen de la documentación de los proveedores; en los resultados de benchmarks indicamos quién los publicó.

Un agente que trabaja desde la pantalla lee una captura en cada paso, y las imágenes se cobran como tokens. Los tres proveedores lo calculan de forma distinta: Anthropic divide la imagen en cuadrados de 28 píxeles y OpenAI en cuadrados de 32 píxeles, mientras que Google usa en Gemini 4 y 3 un número fijo, sea cual sea el tamaño. Con la resolución de 1280×800 que Anthropic recomienda para aplicaciones web, una sola captura cuesta:

Lo que el gráfico no muestra es cómo se acumula. El agente toma una captura nueva en cada paso, y las anteriores se quedan en el contexto. Según Anthropic, una ventana de contexto de 200K tokens se llena mucho antes de llegar a 100 capturas. Cuando una petición lleva más de 20 imágenes, cada imagen queda sujeta a un límite de tamaño más estricto. Por eso Anthropic recomienda, en sus modelos más nuevos, reducir las capturas a 2000 píxeles por lado como máximo y borrar las antiguas en el servidor. Qué olvida el agente cuando se llena el contexto lo contamos en el artículo sobre auto compact.

El conjunto de herramientas también tiene su propio coste. En Anthropic, el conjunto de herramientas de computer use añade unos 4.500 tokens de entrada a cada petición, y el conjunto de browser use, unos 6.600. Como esta carga es la misma en cada petición, aquí el prompt caching resulta útil. Para el árbol de accesibilidad no hay una cifra única: depende de la página. La documentación de Anthropic dice que, en una página normal, leer el árbol suele costar menos tokens de entrada que una captura. El árbol también puede crecer: el equipo de Playwright recomienda a los agentes de programación la CLI en lugar de MCP, porque la CLI no carga en el contexto del modelo grandes esquemas de herramientas ni árboles de accesibilidad largos.

Para el tiempo, los proveedores no dan una cifra por paso; ninguna de las documentaciones que leímos indica segundos por acción. Anthropic escribe que computer use puede ser lento comparado con una persona que hace las mismas operaciones a mano, y lo recomienda para tareas en las que la velocidad no importa, como las pruebas de software automatizadas. El tiempo por tarea lo publica OpenAI: según su propia medición, GPT-6 Astra terminó una tarea de OSWorld 2.0 en unos 40 minutos, y GPT-5.6 Sol en unos 75 minutos. Son tareas largas: según la página de OSWorld 2.0, una persona tarda unas 1,6 horas en terminar una (mediana), y Claude Opus 4.7 hace de media 318 llamadas a herramientas por tarea; en el OSWorld antiguo, esa cifra era de unas 30.

Para la fiabilidad, la medida más seguida es OSWorld. Los tres proveedores midieron sus modelos nuevos con una versión reciente de OSWorld y anunciaron los resultados, pero cada uno en una versión o un subconjunto distinto, y todos dan puntuaciones parciales:

Fuente: los anuncios y las model cards de los propios proveedores, 20 de octubre de 2026; todos los resultados son los que publicó el proveedor. Como la versión y el subconjunto cambian, las filas no se pueden comparar entre sí. Las model cards de Google dan un mes, no un día.

La puntuación parcial mide qué parte de los puntos de control de una tarea se cumple; OSWorld 2.0 puntúa cada tarea con 27,25 puntos de control de media. La medida principal del benchmark, en cambio, es si la tarea se completa de principio a fin. La distancia entre las dos es grande. En la tabla de OSWorld 2.0 (actualización del 15 de octubre, versión v2.1), el mejor resultado entre las ejecuciones en las que el modelo trabaja solo es el de Claude Opus 5 con el effort más alto: una puntuación parcial del 77,67 % y un 44,33 % de tareas completadas de principio a fin. Con el effort más bajo, el mismo modelo completa el 18,81 %.

En la versión actual, la tabla no tiene ningún modelo de OpenAI; en el subconjunto offline de la versión anterior, GPT-5.6 Sol con el effort más alto obtuvo un 64,13 % de puntuación parcial y un 28,1 % de tareas completadas de principio a fin. Los modelos Gemini no aparecen en la tabla en absoluto. Así que las cifras que anuncian los proveedores dicen que el agente hace la mayor parte del trabajo; no dicen que lo termine. Cómo leer una puntuación lo contamos en el artículo sobre SWE-bench.

Por qué trabajar desde la pantalla no da siempre el mismo resultado lo escriben los propios proveedores. Según GitHub, un cambio en los tiempos o en el estado de una ventana puede dar otro resultado y hacer que el agente repita una acción o se quede atascado. Anthropic escribe que el modelo puede equivocarse al generar coordenadas, y Google, que las ventanas emergentes inesperadas y los cambios de diseño pueden confundir al modelo. El árbol de accesibilidad resuelve parte del problema: según Anthropic, una referencia a un elemento no se ve afectada por los desplazamientos del diseño que estropean las coordenadas en píxeles. En un test de Playwright, el elemento se encuentra por su rol y su nombre, Playwright espera hasta que se da el estado esperado y el test da los mismos pasos en el mismo orden en cada ejecución.

Fuente: la documentación enlazada en esta sección, 20 de octubre de 2026.

¿Qué ofrecen los tres proveedores para computer use y browser use?

Si construyes tu propio agente sobre la API, los tres proveedores tienen una herramienta lista. El ciclo es el mismo en todos: el modelo pide una acción, y tu código la ejecuta en tu propio navegador o máquina virtual y devuelve el resultado. A 20 de octubre de 2026:

Fuente: la documentación de computer use, browser use y precios de los tres proveedores, 20 de octubre de 2026. «Su documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo describa.

En Anthropic hubo un cambio hace poco. Según las notas de la versión, computer use salió de la beta el 19 de agosto, y la herramienta de browser use llegó ese mismo día. En Opus 5.5, publicado el 22 de septiembre, la antigua herramienta computer_20251124 devuelve un error 400 en la Claude API y Google Cloud; Sonnet 5.5 y Haiku 5.5 tampoco aceptan las herramientas antiguas. El nuevo conjunto de herramientas puede devolver varias acciones juntas en un mismo turno; tu código debe ejecutarlas en orden y detenerse en el primer error.

OpenAI tiene dos vías. La guía explica tanto la herramienta computer, con la que el modelo devuelve acciones como clics y escritura, como la vía en la que el modelo escribe código de Playwright o PyAutoGUI. En la vía del código, el modelo puede combinar varias acciones, un bucle o una condición en una sola llamada. La guía también pide comprobar el resultado real al final en lugar de fiarse de la respuesta del modelo. Desde el 29 de septiembre, la Agents API también ofrece computer use en un navegador alojado por OpenAI.

La herramienta de Google está en vista previa, y Google recomienda una supervisión estrecha en las tareas importantes. El modelo da las coordenadas en una cuadrícula de 1000×1000; tu código las convierte al tamaño de la pantalla. Si una acción es arriesgada, la respuesta trae require_confirmation y tienes que preguntar al usuario. El análisis de capturas en busca de prompt injection es opcional y está desactivado por defecto.

Al elegir modelo, los tres proveedores recomiendan cosas distintas. Google recomienda Gemini 3.8 Flash para computer use. Anthropic considera Haiku 5.5 adecuado para tareas de browser use en las que importa la velocidad. La documentación de Codex recomienda GPT-6 Astra para tareas difíciles que dependen de capturas de pantalla o de juicio visual. Las diferencias generales entre modelos las contamos en el artículo sobre la elección de modelo.

¿Cómo prueban una interfaz los agentes de programación?

Las cinco herramientas de programación le dan al agente una forma de usar el navegador o la pantalla, pero cambian dónde se ejecuta y qué viene activado por defecto. Leímos la tabla en la documentación de cada herramienta el 20 de octubre de 2026:

Fuente: la documentación y las notas de versión de cada herramienta, 20 de octubre de 2026. «Su documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo describa. En Copilot, computer use pasó a vista previa el 1 de octubre y está desactivado por defecto.

Si todavía usas Gemini CLI, su agente de navegador está desactivado por defecto; cuando lo activas, trabaja con la página a través del árbol de accesibilidad. Para los usuarios del nivel gratuito y de Google One, Google sustituyó Gemini CLI por Antigravity CLI el 18 de junio de 2026; con claves de API de pago, Gemini CLI se puede seguir usando.

La documentación de tres de estas herramientas recomienda el mismo orden. Claude Code considera el control de la pantalla la vía más amplia y más lenta: primero prueba un servidor MCP, luego Bash, luego Claude in Chrome, y solo usa la pantalla si nada de eso basta. Según GitHub, si una API, un servidor MCP, un comando de terminal o una herramienta de navegador pueden hacer el trabajo, esas herramientas dan información más estructurada y resultados más previsibles. La documentación de Codex también recomienda primero el navegador integrado para una app web local, y un servidor MCP para tareas repetidas.

Otra diferencia está en la sesión. Claude in Chrome comparte el estado de inicio de sesión de tu navegador y puede entrar en cualquier sitio en el que tengas la sesión iniciada; ante una página de inicio de sesión o un CAPTCHA, se detiene y te pregunta. En VS Code, las páginas que abre el agente se abren en una sesión aparte y temporal. El navegador integrado de Codex y Antigravity IDE usan un perfil distinto del tuyo.

¿Por qué suele ser mejor que el agente escriba un test de Playwright?

La comprobación que hace el agente en el navegador se pierde al terminar la sesión. Si conviertes esa misma comprobación en un test de Playwright, se queda en el repositorio y vuelve a ejecutarse sin modelo en cada pull request: no gasta tokens, no acumula capturas de pantalla y da los mismos pasos cada vez. La documentación de VS Code recomienda lo mismo: las herramientas de navegador sirven para comprobar dentro de una sesión; las comprobaciones que tienen que ejecutarse en CI cada vez, o detectar que vuelve un error antiguo, deben quedarse en el repositorio como tests de Playwright u otros tests automáticos.

En la práctica, funciona bien un método en dos pasos. Primero, el agente recorre la página con una herramienta de navegador o con Playwright MCP y ve cómo son realmente los selectores y los textos. Después, escribe ese flujo en un test, lo ejecuta y muestra que pasa. Playwright también ofrece agentes listos para esto: los Playwright Test Agents son un planner que recorre la app y saca un plan de pruebas, un generator que escribe tests a partir del plan y un healer que arregla los tests rotos. npx playwright init-agents --loop=claude añade estas definiciones para Claude Code; también existen las opciones codex y vscode. El generator comprueba los selectores y las aserciones en vivo mientras ejecuta el escenario. Así podría ser un test que un agente escribe para un formulario de registro:

// Ejemplo: test escrito por el agente; CI lo vuelve a ejecutar en cada pull request.
import { test, expect } from '@playwright/test';

test('el formulario de registro rechaza un correo no válido', async ({ page }) => {
  await page.goto('/signup');
  await page.getByLabel('Correo electrónico').fill('direccion-no-valida');
  await page.getByRole('button', { name: 'Registrarse' }).click();
  await expect(page.getByText('Introduce un correo electrónico válido')).toBeVisible();
  await expect(page).toHaveScreenshot('signup-error.png');
});

El test hace dos tipos de comprobación. toBeVisible mira el comportamiento: ¿aparece el mensaje de error? toHaveScreenshot mira el aspecto: la página se compara píxel a píxel con la imagen de referencia del repositorio. Según Playwright, el sistema operativo, la versión del navegador e incluso el hardware pueden cambiar la imagen; por eso, genera la imagen de referencia en el entorno en el que se ejecutará el test. Si quieres comparar la estructura de la página con el árbol de accesibilidad en lugar de con una imagen, tienes toMatchAriaSnapshot.

Cuando un test falle, deja evidencias al agente para que vea por qué. La configuración de abajo guarda una captura de pantalla en cada test fallido y un trace en el primer reintento en CI; en el trace puedes avanzar y retroceder para ver qué pasó en cada paso del test. Los archivos van a la carpeta de salida de los tests, normalmente test-results; dile al agente que mire ahí primero cuando corrija el fallo.

// Ejemplo: configuración que deja evidencias de un test fallido.
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: 'http://localhost:3000',
    screenshot: 'only-on-failure',
    trace: 'on-first-retry',
  },
});

Las comprobaciones basadas en capturas de pantalla siguen haciendo falta en estos casos: desplazamientos del diseño, errores de color o de alineación, un gráfico o un mapa dibujados en un canvas. La documentación de Anthropic también incluye el canvas, el vídeo incrustado y las superficies de escritorio remoto entre los sitios que el árbol no ve. Para encontrar un error así, basta con que el agente mire una vez una captura; para que no vuelva, haz que escriba un test con toHaveScreenshot.

¿Qué vía elegir para cada trabajo?

Todos los datos apuntan al mismo orden: si puedes hacer el trabajo con código, con código; si la página está en un navegador, con el árbol; si no hay otra puerta, con la pantalla. Para los trabajos habituales:

Las razones de las tarjetas están arriba. Un test para comprobar una interfaz web, porque el test se ejecuta en CI sin modelo y con los mismos pasos cada vez. Una herramienta de navegador para una comprobación puntual, porque leer el árbol suele costar menos que una captura y una referencia no se ve afectada por los desplazamientos del diseño. Guarda computer use para las apps que no tienen API, CLI ni servidor MCP; GitHub también lo presenta para ese tipo de apps.

En tareas como pagos, contraseñas y cambios de cuenta, los tres proveedores dicen lo mismo: que una persona apruebe el último paso. Anthropic recomienda la aprobación humana en decisiones como aceptar cookies, hacer transacciones financieras o aceptar condiciones de uso. OpenAI considera incluso escribir información sensible en un formulario como un envío de datos. Las instrucciones de ejemplo de Google le piden al modelo que nunca intente resolver un CAPTCHA. Ejecuta el agente en una máquina virtual aparte o con un perfil de navegador aparte, y limita los sitios que puede visitar con una lista de permitidos. Cómo un texto de la página puede dirigir al agente lo contamos en el artículo sobre seguridad en MCP.

diffox, una herramienta de revisión de código con IA, lee el pull request con git; no abre la interfaz ni toma capturas de pantalla. Por eso, el test que escribe el agente para la interfaz cumple dos funciones en el pull request: CI muestra que la interfaz funciona, y en la revisión se puede leer en el diff qué comprueba el test. Por qué un test que pasa no siempre comprueba algo lo contamos en el artículo sobre cómo revisar código generado por IA.