Resumen Técnico: PreAct – Agentes de uso de computadora que se vuelven más rápidos en tareas repetidas

1. Planteamiento del Problema

Los agentes de uso de computadora (CUA, por sus siglas en inglés) operan software observando pantallas y emitiendo clics o pulsaciones de teclas. Aunque son efectivos para resolver tareas, son inherentemente ineficientes para el trabajo repetitivo. Los agentes actuales tratan cada instancia de una tarea como un problema nuevo: vuelven a leer la pantalla, vuelven a razonar cada paso y contraen el costo total de la inferencia de visión y lenguaje para cada ejecución, incluso si la tarea es idéntica a una resuelta previamente. Esta "re-derivación" impide que los agentes adquieran la fluidez que los humanos desarrollan mediante la práctica, donde el razonamiento deliberado inicial se internaliza en rutinas automáticas. Además, las mejoras de eficiencia existentes —como las bibliotecas de habilidades o los sistemas de registro y reproducción— a menudo no logran equilibrar la velocidad con la fiabilidad. Las bibliotecas de habilidades suelen requerir todavía un modelo de lenguaje (LLM) para ejecutar los comportamientos almacenados en tiempo de ejecución, mientras que los sistemas ingenuos de registro y reproducción carecen de verificación, lo que conduce a una ejecución "ciega" que falla cuando el entorno cambia o cuando el rastro almacenado es defectuoso.

2. Metodología: Arquitectura PreAct

PreAct introduce un sistema que compila ejecuciones exitosas de agentes en programas de máquinas de estado directamente ejecutables. La innovación central es una disciplina de "verificación antes del almacenamiento" aplicada en dos escalas temporales: la verificación en tiempo de ejecución durante la reproducción y la verificación previa al almacenamiento antes de guardar un programa.

2.1 El Artefacto: Programas de Máquina de Estados

En lugar de almacenar guiones planos o fragmentos de código parametrizados, PreAct compila una ejecución de tarea exitosa en una pequeña máquina de estados ($P = (S, T, M, V)$):

• Estados ($S$): Cada estado contiene un predicado de verificación (por ejemplo, un patrón XPath o una comprobación del árbol de accesibilidad) que debe coincidir con la pantalla en vivo antes de que el agente proceda.
• Transiciones ($T$): Acciones (clics, tipeo, navegaciones) que mueven al agente de un estado a otro.
• Parámetros ($M$): Los valores concretos escritos durante el rastro (por ejemplo, un nombre específico o un número de teléfono) se elevan a parámetros, lo que permite que el mismo programa se generalice a través de diferentes instancias de la misma familia de tareas.
• Ejecución: Durante una ejecución "cálida" (warm run), el Reproductor recorre el grafo. Antes de disparar una transición, comprueba la pantalla en vivo contra el predicado del estado. Si la comprobación es correcta, la acción se ejecuta inmediatamente sin una llamada al LLM. Si falla (por ejemplo, apareció un diálogo inesperado), el sistema se detiene y recurre al CUA completo.

2.2 El Bucle: Selección, Reproducción, Retroceso, Verificación

El sistema opera mediante un bucle de compilar-extender-reemplazar:

1. Selección: Un Selector de Programas consulta el corpus buscando un programa que coincida con el objetivo actual.
2. Reproducción: Si se encuentra uno, el Reproductor ejecuta la máquina de estados con verificación paso a paso.
3. Retroceso (Fall Back): Si un predicado falla o una acción da error, el control se transfiere al CUA completo, que resuelve la tarea desde el estado actual de la pantalla y registra un nuevo rastro.
4. Verificar y Almacenar: Tras el éxito, el nuevo rastro se compila en un programa candidato $P'$. Crucialmente, $P'$ no se almacena inmediatamente. Se somete a una Puerta de Verificación antes del Almacenamiento.

2.3 La Puerta de Verificación antes del Almacenamiento

Esta es la principal mecánica del sistema para asegurar una mejora monotónica. Antes de que un programa entre en el corpus:

1. El entorno se reinicia a un estado inicial limpio.
2. El programa candidato $P'$ se vuelve a ejecutar desde cero.
3. Un evaluador independiente comprueba si la tarea fue realmente resuelta.
4. El programa se almacena (o reemplaza una versión anterior con la misma firma de deduplicación) solo si la reproducción se completa con éxito y el evaluador confirma que la tarea está resuelta.

Esta puerta detecta específicamente programas "con pérdida" (lossy) que se reproducen al 100% de cobertura (todas las acciones se ejecutan) pero fallan en alcanzar el objetivo (por ejemplo, se rellena un formulario de contacto y se guarda, pero un campo desactualizado impide la creación del contacto).

2.4 Mecanismo de Retroceso (Fallback)

Cuando la puerta rechaza todos los programas candidatos para una tarea (dejando el corpus vacío para esa tarea), PreAct emplea un retroceso: activa una nueva exploración de CUA para la segunda ejecución. Esto asegura que, incluso si el sistema no puede encontrar un programa verificado, no se rinda simplemente, manteniendo la paridad de rendimiento con bases sólales de registro y reproducción como Muscle-Mem.

3. Contribuciones Clave

• Ejecución Directa de Máquinas de Estados Verificadas: PreAct cambia el paradigma de ejecución de razonamiento impulsado por LLM a la ejecución determinista de grafos para tareas repetidas, eliminando las llamadas a LLM por paso.
• Verificación de Dos Escalas Temporales: El sistema aplica la misma disciplina de "observar primero, luego actuar" en tiempo de ejecución (por paso) y en el momento de almacenamiento (pre-almacenamiento). Esto evita la acumulación de programas defectuosos que de otro modo degradarían el rendimiento con el tiempo.
• Corpus de Auto-extensión: A diferencia de los cachés de solo adición, el corpus de PreAct es mutable. Nuevos programas pueden reemplazar a los anteriores si pasan la puerta de verificación, permitiendo al sistema refinar su representación de las tareas con el tiempo.
• Validación Empírica de la Eficiencia: El artículo establece la "eficiencia de tarea repetida" como una métrica de primera clase, midiendo no solo las tasas de éxito sino también la reducción en el tiempo de ejecución (wall-clock time) y los costos de tokens del LLM.

4. Resultados Experimentales

Los autores evaluaron PreAct en tres entornos de prueba: AndroidWorld (móvil), OSWorld (escritorio) y WebArena (web).

• Velocidad y Costo: Las ejecuciones cálidas (reproducción de programas almacenados) son de 8.5 a 13 veces más rápidas en tiempo de ejecución que las ejecuciones frías (re-derivación desde cero) y conllevan cero costos de LLM por paso. La sobrecarga de una sola vez de compilar y verificar un programa es aproximadamente equivalente a una resolución adicional (+162% en Android, +217% en OSWorld), pero esto se amortiza en ejecuciones posteriores.
• Mejora Monotónica: Con la puerta de verificación habilitada, las ejecuciones repetidas mejoran o mantienen la tasa de éxito de forma constante.
  • AndroidWorld: Mejora media de +1.33 tareas (de 15) de frío a cálido.
  • OSWorld: Mejora media de +0.2 tareas (de 6).
  • WebArena: Aunque la puerta causa una regresión en la tasa de éxito bruta de la ejecución cálida (deb due a la alta tasa de rechazo de selectores web frágiles), el valor marginal de la puerta es positivo. Sin la puerta, el rendimiento se degrada significativamente (ej. -5.8 tareas en WebArena). Con la puerta, la degradación se reduce (-4.0 tareas).
• La Necesidad de la Puerta: Los estudios de ablación muestran que deshabilitar la puerta de verificación provoca un colapso del rendimiento en todas las plataformas. La puerta evita el modo de fallo "se ejecuta pero no funciona", donde un programa ejecuta todos los pasos pero falla en la lógica de la tarea.
• Eficacia del Retroceso (Fallback): En WebArena, donde la puerta rechaza muchos programas, añadir un retroceso de "fallo de caché hacia CUA" permite a PreAct igualar el rendimiento de la base sólida Muscle-Mem (estadísticamente indistinguible, $p \approx 0.84$), cerrando la brecha creada por la verificación agresiva.
• Robustez: Los resultados son robustos tanto para la elección del LLM para la compilación (Claude vs. Gemini) como para la elección del selector (recuperador basado en embeddings vs. LLM). El mecanismo central, no el modelo específico, es lo que impulera los resultados.

5. Significado y Reivindicaciones

El artículo sostiene que PreAct demuestra que los agentes de uso de computadora pueden adquirir capacidades de aprendizaje continuo similares a las humanas: volviéndose más rápidos y económicos en tareas repetidas sin sacrificar la fiabilidad.

• Fluidez vs. Ceguera: PreAct logra la fluidez no mediante la repetición ciega, sino mediante la "predicción con verificación". El agente actúa automáticamente cuando la pantalla coincide con las expectativas, pero revierte inmediatamente a la deliberación cuando no es así.
• Diseño sobre Ajuste (Tuning): Los autores enfatizan que las ganancias de rendimiento son impulsadas por la arquitectura del sistema (almacenar el programa que ejecutas, verificar antes de almacenar) más que por el ingeniería de prompts, las salvaguardas en tiempo de ejecución o las elecciones de modelos específicos.
• Una Nueva Dimensión de Evaluación: El artículo argumenta que la evaluación debe ir más allá de las simples tasas de éxito para incluir el costo de la ejecución repetida. Un agente que re-deriva cada tarea es menos eficiente que uno que ha aprendido a saltarse la deliberación, incluso si ambos logran la misma tasa de éxito.

En resumen, PreAct proporciona un marco donde los agentes construyen una biblioteca de programas verificados y directamente ejecutables, permitiéndoles resolver tareas familiares con la velocidad de una macro y la fiabilidad de un agente verificado, resolviendo eficazmente el "impuesto de re-derivación" de los actuales agentes de uso de computadora.