simframe propone que los agentes no parpadeen: percepción continua en vez de capturas

El autor de simframe, un proyecto open source alojado en GitHub, ha publicado sus notas de campo sobre un problema que arrastran los agentes que operan interfaces gráficas: mirar la pantalla les sale carísimo. Su propuesta es sacar la percepción del bucle de razonamiento y convertirla en un proceso que observa de forma continua, con memoria de lo que ya ha visto.

El patrón que critica es el que usan casi todos los frameworks de computer use, incluidos los que publican los laboratorios de modelos: captura de pantalla, razonamiento sobre la imagen, acción, y vuelta a empezar. Así, el componente más caro del sistema, el modelo de lenguaje, se ocupa de la tarea más barata: darse cuenta de que un spinner sigue girando o de que la barra de pestañas es la misma que vio hace un minuto. Y el coste se acumula. El estudio OSWorld-Human (Abhyankar, Qi y Zhang, MLSys 2026) midió dónde se va el tiempo: las llamadas al modelo para planificar y reflexionar consumen entre el 75% y el 94% del tiempo total de la tarea, cada paso arrastra el historial completo de observaciones y por eso los últimos corren hasta tres veces más lentos que los primeros, y los agentes líderes necesitan entre 1,4 y 2,7 veces más pasos que una persona para lo mismo. Cada mirada de más no es una llamada perdida: es una imagen más viajando por todas las llamadas siguientes.

Ojos, mano y memoria

La alternativa que describe tiene tres piezas. Los ojos son un demonio que mantiene siempre el fotograma actual en memoria; mirar es una lectura, no una espera. La primera versión capturaba en bucle con simctl io screenshot, de modo que pedir una mirada pasó de ser una captura bloqueante de unos 130 ms a una lectura de fichero de unos 20 ms. La versión reescrita lee directamente el framebuffer del simulador, y la diferencia es mayor de lo que esperaba: 210 ms de mediana para capturar y reescalar con el comando de simctl, frente a 6,74 ms por la vía del framebuffer haciendo lo mismo y calculando además dos hashes. El framebuffer solo tarda 0,13 ms. Casi todo el tiempo restante se va en el reescalado.

El demonio no tiene tasa de refresco. Captura cuando el simulador avisa de que la pantalla ha cambiado —una señal de daño, unas 52 por segundo mientras algo se mueve y ninguna cuando la imagen está quieta—. El autor cuenta que persiguió los 60 fps y acabó con una comprobación de integración continua que exigía que un contador de fotogramas avanzara en una pantalla inactiva. Falló tres veces antes de entender por qué.

La mano ejecuta acciones, pero recuerda dónde estaba cada control: cada pantalla vista se indexa por un hash de su disposición y se guarda el mapa de etiqueta a coordenada. La primera visita cuesta unos 305 ms, porque construye el árbol de accesibilidad y pasa OCR en el dispositivo a la vez. Las siguientes rondan 1 ms. En un flujo de cuatro pestañas repetido tres veces, la primera pasada tarda 10,2 s con la memoria vacía; la segunda, 3,6 s; la tercera, 3,7 s.

Hay una parte que conviene leer con atención: el autor retira cifras de un borrador anterior (7370, 5160 y 3304 ms) porque medían dos fallos. La entrada caía en silencio a una ruta más lenta y el demonio de captura se reiniciaba con cada comando por una constante de versión desincronizada entre la parte Swift y la de JavaScript. Novecientos noventa y tres reinicios en una sesión y todos los tiempos del proyecto mal. Lo detectó otra persona al ejecutar la herramienta.

Lo interesante no es el caso concreto del simulador, sino el reparto de responsabilidades. Si percibir deja de ser una función que el modelo invoca y pasa a ser un servicio con su propio contrato, el razonamiento se reserva para lo que de verdad lo necesita: lo inesperado. Las tablas de rendimiento del repositorio están publicadas, aunque el texto original llega truncado y no cubre todas las mediciones que anuncia.