¿Y si el modelo pudiera usar una computadora como tú?

En los artículos anteriores, dimos a los modelos la capacidad de llamar funciones, razonar sobre planes de múltiples pasos y descubrir herramientas dinámicamente a través de MCP. Pero todos esos mecanismos comparten una suposición común: que el sistema objetivo expone una interfaz programática — un endpoint de API, una firma de función, un protocolo estructurado. El modelo produce JSON y un runtime ejecuta la llamada. Eso funciona maravillosamente cuando existen APIs. Pero la mayor parte del trabajo que los humanos hacen en computadoras no ocurre a través de APIs. Ocurre a través de interfaces gráficas de usuario : navegadores web, aplicaciones de escritorio, formularios, menús desplegables, casillas de verificación y botones.

Considera cuánto del mundo digital es solo GUI. Sistemas empresariales heredados — software de nóminas de 2005, portales de registros hospitalarios, sitios web gubernamentales — no tienen API y nunca la tendrán. Herramientas internas construidas con constructores de formularios de arrastrar y soltar no exponen endpoints. Muchos productos SaaS ofrecen un panel web pero no una API para el flujo de trabajo específico que necesitas. Incluso cuando existe una API, a menudo cubre solo una fracción de lo que la GUI puede hacer. Si alguna vez has tenido que hacer clic manualmente a través de un portal web para hacer algo que debería haber sido automatizado, has sentido este dolor.

El uso de computadora resuelve esto dándole al modelo la misma interfaz que tiene un humano: una pantalla para mirar y un teclado y ratón para interactuar. El modelo ve una captura de pantalla del estado actual de la pantalla, decide qué hacer clic o escribir, y la acción se ejecuta en su nombre. Luego ve la nueva captura de pantalla resultante y continúa. No se necesita API. No se necesita protocolo estructurado. Si un humano puede realizar una tarea mirando una pantalla y moviendo un ratón, el modelo también puede intentarlo.

Esta es la forma más general de uso de herramientas. La llamada a funciones requiere que alguien haya escrito una API. MCP requiere que alguien haya construido un servidor. La ejecución de código requiere un runtime y las bibliotecas correctas. Pero el uso de computadora solo requiere lo que toda aplicación ya proporciona: una interfaz visual. Es, en cierto sentido, la herramienta universal — la que funciona con todo, porque todo tiene una pantalla.

💡 El uso de computadora es al uso de herramientas lo que el lenguaje natural es a la programación: una interfaz menos precisa pero mucho más universal. Intercambias velocidad y confiabilidad por la capacidad de interactuar con cualquier cosa que tenga una GUI, incluyendo sistemas que nunca fueron diseñados para la automatización.

El bucle captura de pantalla-acción

La arquitectura de un agente de uso de computadora sigue un bucle que debería resultar familiar del bucle de agente que introdujimos en el artículo 1, pero con una diferencia crucial: la observación es visual en lugar de textual. En vez de leer respuestas de API o salida de herramientas como datos estructurados, el modelo mira una imagen de la pantalla y debe comprender lo que ve.

El bucle funciona de la siguiente manera:

  • 1. Captura de pantalla: capturar el estado actual de la pantalla como una imagen (típicamente un PNG a la resolución de la pantalla).
  • 2. Observar + Razonar: enviar la captura de pantalla junto con la descripción de la tarea (y el historial de acciones previas) a un modelo de visión-lenguaje . El modelo debe comprender el diseño visual — dónde están los botones, qué contienen los campos de texto, qué pestaña está activa — y decidir qué acción tomar a continuación.
  • 3. Actuar: el modelo produce una acción estructurada: click(x, y) , type("hello") , scroll(down) , key_press("Enter") , o similar.
  • 4. Ejecutar: un runtime (que controla una máquina real o virtual) ejecuta la acción — moviendo realmente el cursor del ratón y haciendo clic, o inyectando pulsaciones de teclas.
  • 5. Repetir: tomar una nueva captura de pantalla del estado resultante de la pantalla y volver al paso 2. Continuar hasta que la tarea esté completa o se alcance una condición de parada. 
def computer_use_agent(task: str, environment: VirtualDesktop):
    """Run a task by seeing and interacting with a screen."""
    action_history = []

    while not task_complete(action_history):
        # 1. Observe: capture what's on screen
        screenshot = environment.take_screenshot()

        # 2. Reason: ask the vision-language model what to do
        action = vlm.generate_action(
            task=task,
            screenshot=screenshot,       # image input
            history=action_history        # what we've done so far
        )

        # 3. Act: execute the action in the environment
        environment.execute(action)       # click, type, scroll, etc.
        action_history.append(action)

    return action_history

Observa cómo esto refleja el bucle observar-razonar-actuar del artículo 1, excepto que la observación es una captura de pantalla (una imagen) en lugar de texto. Esto significa que el modelo necesita tanto capacidades de visión fuertes (para analizar el diseño visual de una GUI — reconocer botones, leer texto renderizado en fuentes arbitrarias, comprender relaciones espaciales entre elementos) como capacidades de razonamiento fuertes (para planificar interacciones de múltiples pasos y recuperarse de estados inesperados). Por eso el uso de computadora se volvió práctico solo después de la aparición de potentes modelos de visión-lenguaje (VLMs) que combinan comprensión visual con razonamiento basado en lenguaje.

El componente de comprensión visual se basa en gran medida en la misma arquitectura de vision transformer (ViT) utilizada en otras tareas multimodales: la captura de pantalla se divide en parches, cada parche se codifica como un token, y el modelo atiende tanto los tokens de imagen como los tokens de texto que describen la tarea. La diferencia es que aquí, el modelo debe producir no solo una respuesta de texto sino una coordenada espacial precisa (dónde hacer clic) o una secuencia de pulsaciones de teclas (qué escribir).

Una consecuencia práctica de esta arquitectura es la latencia . Cada iteración del bucle implica tomar una captura de pantalla, codificarla, enviarla al modelo, esperar la inferencia (que procesa una imagen grande junto con el historial de conversación), y luego ejecutar la acción. Un solo paso típicamente toma de 1 a 5 segundos. Una tarea compleja como llenar un formulario de múltiples páginas o navegar por varias páginas web puede requerir 20-50 pasos, lo que significa que el tiempo total se mide en minutos en lugar de segundos. Esto es dramáticamente más lento que el uso de herramientas basado en API, donde cada llamada se completa en milisegundos.

💡 El costo de latencia es real pero a menudo aceptable. Las tareas que le toman minutos a un modelo completar mediante el uso de computadora podrían tomarle a un humano 10-15 minutos de clics tediosos. La comparación no es uso de computadora vs. llamadas a API — es uso de computadora vs. un humano haciendo la misma tarea de GUI manualmente.

Uso de computadora con Claude

La capacidad de uso de computadora de Anthropic (Anthropic, 2024) permite a Claude ver capturas de pantalla y producir acciones de computadora estructuradas. En lugar de añadir el uso de computadora como un sistema separado, Anthropic lo integró directamente en el framework de uso de herramientas de Claude: el modelo recibe una captura de pantalla como una imagen en su contexto de conversación y produce llamadas a herramientas que representan acciones de ratón y teclado.

Las acciones disponibles forman un conjunto compacto pero completo para interactuar con un entorno de escritorio:

  • mouse_move(x, y) — mover el cursor a las coordenadas de píxel (x, y)
  • left_click(x, y) — hacer clic en la posición especificada
  • right_click(x, y) — abrir un menú contextual
  • double_click(x, y) — doble clic (por ejemplo, para seleccionar una palabra o abrir un archivo)
  • type("text") — escribir una cadena de texto
  • key("Enter") — presionar una tecla específica o combinación de teclas (Enter, Ctrl+C, Alt+Tab, etc.)
  • screenshot() — solicitar una nueva captura de pantalla del estado actual de la pantalla

En cada paso, el modelo examina la captura de pantalla, razona sobre el estado actual de la interfaz ("Veo un formulario de inicio de sesión con un campo de usuario y un campo de contraseña; el campo de usuario ya está lleno; necesito hacer clic en el campo de contraseña y escribir la contraseña"), y produce la acción apropiada como una llamada a herramienta. El runtime ejecuta la acción, captura una nueva captura de pantalla, y la retroalimenta para el siguiente paso. 

import anthropic

client = anthropic.Anthropic()

# The model receives a screenshot and outputs computer actions
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    tools=[
        {
            "type": "computer_20250124",  # computer use tool
            "name": "computer",
            "display_width_px": 1920,
            "display_height_px": 1080,
        }
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Open Firefox and search for 'MCP protocol specification'"
                },
                {
                    "type": "image",    # current screenshot
                    "source": {
                        "type": "base64",
                        "media_type": "image/png",
                        "data": screenshot_base64
                    }
                }
            ]
        }
    ]
)

# The model responds with a tool call like:
# {
#     "type": "tool_use",
#     "name": "computer",
#     "input": {
#         "action": "left_click",
#         "coordinate": [512, 738]   # Firefox icon position
#     }
# }

El uso de computadora típicamente se ejecuta en un entorno aislado — un contenedor Docker con un escritorio virtual (por ejemplo, un escritorio Linux con un servidor VNC). Este aislamiento es crítico para la seguridad: las acciones del modelo están confinadas al sandbox, por lo que un clic equivocado no puede borrar accidentalmente archivos en tu máquina real ni enviar correos desde tu cuenta real. La desventaja es que el entorno aislado puede no tener acceso a todas las aplicaciones y cuentas necesarias para una tarea, requiriendo configuración.

Los casos de uso prácticos incluyen llenar formularios en sitios web que carecen de APIs, navegar portales web (reclamos de seguros, trámites gubernamentales, reservas de viaje), pruebas de software (hacer clic a través de flujos de UI para verificar el comportamiento), y entrada de datos desde fuentes no estructuradas (leer un PDF y escribir su contenido en un formulario). Todas estas son tareas donde un humano se sentaría frente a una computadora y haría clic a través de una GUI — y donde no existe un atajo de API.

Las limitaciones son igualmente importantes de entender. Cada acción toma 1-5 segundos, por lo que los flujos de trabajo complejos son lentos. El modelo puede hacer clic en el elemento equivocado — especialmente cuando los botones son pequeños, están muy juntos o tienen etiquetas ambiguas. Tiene dificultades con el contenido dinámico : animaciones, indicadores de carga, menús desplegables con autocompletado e interfaces de arrastrar y soltar son todos difíciles porque la pantalla cambia entre el momento en que el modelo procesa la captura de pantalla y el momento en que se ejecuta la acción. Y puede quedarse atrapado en bucles : si hace clic en el botón equivocado y la pantalla resultante parece desconocida, puede no saber cómo recuperarse.

OpenAI Operator y Google Mariner

Anthropic no estuvo sola en la búsqueda del uso de computadora. Múltiples laboratorios importantes lanzaron productos de agentes GUI a finales de 2024 y principios de 2025, todos convergiendo en la misma arquitectura central: captura de pantalla de entrada, acción de salida, repetir.

OpenAI Operator (enero 2025) es un agente basado en navegador que puede navegar sitios web de forma autónoma. Construido sobre las capacidades de visión de GPT-4o, Operator se ejecuta en un entorno de navegador aislado alojado por OpenAI. Los usuarios describen una tarea en lenguaje natural ("Reserva el vuelo de ida y vuelta más barato de Nueva York a Londres para el próximo fin de semana"), y Operator navega la web para realizarla: abriendo sitios de viajes, ingresando criterios de búsqueda, comparando precios y completando el flujo de reserva. Como se ejecuta en un navegador aislado (no en la máquina del usuario), está aislado de los datos locales del usuario, pero esto también significa que puede necesitar que el usuario inicie sesión en sus cuentas dentro del sandbox.

Google Project Mariner (diciembre 2024) toma un enfoque arquitectónico diferente. Mariner opera como una extensión de Chrome que se ejecuta directamente en el navegador del usuario, usando modelos Gemini para comprensión visual y planificación de acciones. Como opera dentro de la sesión de navegador existente del usuario, tiene acceso a las cookies, inicios de sesión y contexto de navegación del usuario — sin necesidad de re-autenticarse en un sandbox. Esto lo hace más poderoso para tareas que requieren las cuentas existentes del usuario, pero también requiere un mayor grado de confianza, ya que el agente actúa con la identidad del usuario y puede ver todo en su navegador.

Estos productos, junto con el uso de computadora de Claude, comparten el mismo paradigma subyacente: el patrón de Agente que Usa Computadora (CUA) . Las diferencias entre ellos se encuentran a lo largo de tres ejes:

  • Calidad de comprensión visual: qué tan precisamente el modelo analiza la pantalla. ¿Puede distinguir un botón clicable de una imagen decorativa? ¿Puede leer texto pequeño? ¿Comprende diseños complejos como tablas anidadas o formularios de múltiples columnas?
  • Precisión de acción: qué tan precisamente hace clic el modelo. Unos pocos píxeles de diferencia pueden significar hacer clic en "Cancelar" en lugar de "Confirmar", o seleccionar el elemento equivocado en un menú desplegable.
  • Enfoque de aislamiento: los entornos aislados (uso de computadora de Claude, OpenAI Operator) son más seguros pero menos convenientes (acceso limitado a cuentas de usuario y estado local). Los enfoques de navegador del usuario (Google Mariner) son más capaces pero requieren confiar al agente el contexto completo de navegación del usuario.

La convergencia de los tres laboratorios principales en la misma arquitectura de captura de pantalla-acción es significativa. Sugiere que este patrón — no alguna alternativa como el análisis del DOM o la lectura del árbol de accesibilidad — es el camino principal hacia la automatización general de GUI. La captura de pantalla es la interfaz universal: toda aplicación renderiza una, y un modelo de visión suficientemente capaz puede analizarla.

💡 Algunos sistemas complementan las capturas de pantalla con datos estructurados del DOM (el árbol HTML subyacente a una página web) o el árbol de accesibilidad del sistema operativo (que etiqueta los elementos de UI para lectores de pantalla). Estos datos estructurados pueden mejorar la precisión — es más fácil hacer clic en un botón si conoces su cuadro delimitador exacto del DOM en lugar de estimarlo a partir de píxeles. Pero las capturas de pantalla siguen siendo la entrada principal porque funcionan universalmente, incluyendo en escritorios remotos, imágenes de pantallas y aplicaciones que no exponen un DOM.

Cómo los modelos aprenden a usar interfaces gráficas

Un modelo no sale del pre-entrenamiento sabiendo cómo hacer clic en botones. El uso de computadora es una habilidad aprendida que requiere datos de entrenamiento especializados y aborda desafíos que no surgen en tareas estándar de lenguaje o visión.

Los datos de entrenamiento principales consisten en pares (captura de pantalla, acción) recopilados de demostraciones humanas. Un humano realiza una tarea en una computadora — digamos, reservar un vuelo o configurar un ajuste de software — mientras el sistema graba la pantalla en cada paso y la acción que tomó el humano (clic en la posición (x, y), escribir "salida: 15 de marzo", presionar Enter). Esto produce un conjunto de datos supervisado: dado este estado visual, la acción correcta es esta. El modelo aprende a imitar el proceso de toma de decisiones del humano.

Pero entrenar un modelo para usar GUIs es más difícil de lo que podría parecer. Tres desafíos dominan:

Grounding es el problema de localizar elementos específicos de UI en el espacio de píxeles. Cuando el modelo decide "Necesito hacer clic en el botón Enviar", debe encontrar las coordenadas exactas de ese botón en la captura de pantalla. Esto requiere comprender el diseño, no solo el contenido — el modelo debe distinguir el botón Enviar de otros botones, leer su etiqueta renderizada en cualquier fuente que use la aplicación, y estimar la coordenada (x, y) correcta para hacer clic. Si una página tiene tres botones de estilo similar en una fila, el modelo necesita comprensión espacial precisa para acertar en el correcto. El grounding es especialmente difícil cuando los elementos son pequeños, cuando el texto se renderiza en tamaños o ángulos inusuales, o cuando la UI usa íconos en lugar de etiquetas de texto.

Seguimiento de estado es el problema de mantener la consciencia a lo largo de múltiples pasos. Una tarea de múltiples pasos requiere recordar lo que ya se ha hecho: qué campos de formulario se han llenado, qué pestañas se han visitado, qué resultados de búsqueda ya se han revisado. El modelo ve una nueva captura de pantalla en cada paso, pero debe conectar esa instantánea con el historial completo de sus acciones para comprender el estado actual de la tarea. Si el modelo llena los tres primeros campos de un formulario y luego hace scroll hacia abajo, la siguiente captura de pantalla ya no mostrará esos campos — el modelo debe recordar que ya están llenos en lugar de volver a hacer scroll hacia arriba para llenarlos de nuevo.

Recuperación de errores es el problema de adaptarse cuando algo sale mal. Si un clic falla su objetivo y abre el menú equivocado, el modelo necesita reconocer el estado inesperado y tomar acciones correctivas (cerrar el menú, volver atrás, intentar de nuevo). Si una página carga un banner de consentimiento de cookies que oscurece el formulario, el modelo debe descartarlo antes de continuar. Si un sitio web ha cambiado su diseño desde que se recopilaron los datos de entrenamiento, el modelo debe generalizar. La recuperación de errores es lo que separa un script de automatización frágil de un agente robusto — los scripts se rompen cuando la UI cambia; los agentes (idealmente) se adaptan.

¿Qué tan bien lo están haciendo los modelos actuales? Dos benchmarks estandarizados proporcionan mediciones concretas:

OSWorld (Xie et al., 2024) evalúa agentes de uso de computadora a través de sistemas operativos de escritorio completos (Ubuntu, Windows, macOS). El benchmark incluye tareas del mundo real como instalar software, configurar ajustes del sistema, editar documentos en LibreOffice y gestionar archivos. Cada tarea se ejecuta en una máquina virtual real, y el éxito se mide verificando si el estado final del sistema coincide con el resultado esperado. Los mejores modelos actuales logran tasas de éxito de aproximadamente 30-40% en estas tareas — lejos del rendimiento humano, que está por encima del 90%. La brecha es mayor en tareas que requieren muchos pasos, interacción espacial precisa o recuperación de estados intermedios inesperados.

WebArena (Zhou et al., 2023) se enfoca específicamente en tareas basadas en web. Configura aplicaciones web auto-alojadas realistas — un sitio de comercio electrónico, un foro, un sistema de gestión de contenido, un rastreador de proyectos — y pide a los agentes que realicen tareas dentro de ellos: encontrar un producto y añadirlo al carrito, publicar una respuesta en un hilo del foro, actualizar una página del CMS. WebArena es particularmente desafiante porque las aplicaciones web son réplicas completamente funcionales con complejidad realista, no versiones simplificadas de juguete.

Estos benchmarks revelan que aunque el uso de computadora es funcional, está lejos de estar resuelto. Los modos de fallo más comunes son errores de grounding (hacer clic en el elemento equivocado), quedarse atascado (repetir la misma acción inefectiva), y no poder recuperarse de páginas inesperadas o ventanas emergentes. Mejorar estos modos de fallo es un área activa de investigación.

El espectro del uso de herramientas

Ahora que hemos visto el rango completo — desde llamadas a funciones estructuradas en el artículo 2, pasando por MCP en el artículo 4, hasta el uso de computadora en este artículo — vale la pena colocar estos enfoques en un espectro. Forman una progresión clara desde lo más estructurado y confiable hasta lo más general y flexible:

  • API / llamada a funciones: el modelo produce JSON estructurado que se mapea directamente a una firma de función. Rápido (milisegundos por llamada), confiable (entradas y salidas bien definidas) y determinista (la misma entrada siempre llama a la misma función). Pero requiere que alguien haya construido una API para la operación específica que necesitas.
  • Herramientas MCP: el mismo enfoque estructurado, pero las herramientas se descubren dinámicamente a través de un protocolo estándar. Esto resuelve el problema de integración (un protocolo para gobernarlos a todos) pero sigue siendo fundamentalmente basado en API: cada capacidad debe implementarse explícitamente como un servidor MCP.
  • Ejecución de código: el modelo escribe y ejecuta código. Mucho más flexible que las funciones predefinidas, porque el modelo puede componer lógica arbitraria. Pero requiere un entorno de ejecución, y el modelo debe generar código sintáctica y semánticamente correcto.
  • Uso de computadora: el modelo ve una pantalla e interactúa mediante ratón y teclado. El enfoque más general — cualquier cosa con una GUI es accesible. Pero es el más lento (segundos por acción), menos confiable (la precisión a nivel de píxel es difícil) y más frágil (el mismo sitio web puede verse diferente en diferentes días). 
More structured                              More general
More reliable                                Less reliable
Faster                                       Slower
────────────────────────────────────────────────────────────

  Function       MCP          Code          Computer
  Calling       Tools       Execution         Use

  JSON →        JSON →      code →         screenshot →
  function      server      runtime        click/type

  ~100ms        ~100ms      ~1-10s         ~1-5s/step
  per call      per call    per run        (minutes total)

────────────────────────────────────────────────────────────
Requires API    Requires    Requires       Requires only
to exist        MCP server  runtime        a screen

La elección correcta depende de lo que esté disponible. Si el sistema con el que te estás integrando tiene una API bien documentada, usa llamada a funciones o MCP — será más rápido, más confiable y más fácil de depurar. Si necesitas lógica personalizada que ninguna llamada de API individual puede expresar, la ejecución de código permite al modelo componer soluciones arbitrarias. Y si la única interfaz es una GUI, el uso de computadora es tu única opción.

Pero los sistemas de producción más capaces no eligen solo uno. Combinan múltiples niveles . Un agente podría usar llamadas de API para operaciones bien soportadas (enviar un correo a través de la API de Gmail), ejecución de código para procesamiento de datos (analizar un CSV y calcular estadísticas), y uso de computadora para el único paso que no tiene interfaz programática (navegar un portal interno de recursos humanos para enviar una solicitud de vacaciones). El modelo selecciona dinámicamente el tipo de herramienta más apropiado para cada subtarea, prefiriendo métodos estructurados cuando están disponibles y recurriendo al uso de computadora solo cuando es necesario.

La frontera de este trabajo son modelos que hacen esta transición de forma fluida : dentro de una sola tarea, el modelo podría llamar una API, escribir algo de código para procesar los resultados, y luego cambiar al uso de computadora para pegar la salida en un formulario GUI — todo sin que el usuario necesite configurar qué enfoque usar para cada paso. El modelo mismo decide, basándose en qué herramientas están disponibles y qué requiere la tarea.

💡 Piénsalo como el enfoque de un trabajador humano: usarías una herramienta de línea de comandos si existe una, escribirías un script rápido para procesamiento de datos, y solo abrirías el navegador para tareas que requieren una GUI. Los agentes más efectivos reflejan este pragmatismo, usando la interfaz más eficiente disponible para cada subtarea.

Quiz

Pon a prueba tu comprensión del uso de computadora y agentes GUI.

¿Cuál es el tipo de observación fundamental que distingue el uso de computadora de otras formas de uso de herramientas?

¿Qué es el 'grounding' en el contexto de agentes GUI?

¿Por qué el uso de computadora es significativamente más lento que el uso de herramientas basado en API?

¿Cuándo debería un agente preferir el uso de computadora sobre las llamadas a herramientas basadas en API?