Resumen Técnico: StructAgent

Planteamiento del Problema

Los avances recientes en los Modelos de Lenguaje Grande (LLM) y Modelos de Lenguaje-Visión (VLM) han permitido que los agentes digitales realicen tareas de uso de computadora. Sin embargo, las tareas del mundo real suelen ser de largo horizonte, involucrando flujos de trabajo complejos con contextos en evolución. A medida que los agentes ejecutan estas tareas, acumulan un historial de interacción bruto que contiene información fáctica, ediciones intermedias, intentos fallidos y ejecuciones parcialmente completadas.

El desafío central identificado es que los agentes existentes operan típicamente sobre este historial bruto y no estructurado. A medida que el contexto crece, la información crítica queda enterrada y el estado actual de la tarea se vuelve ambiguo. Esta falta de estructura dificulta que los agentes puedan:

• Mantener una comprensión causal clara del progreso de la tarea.
• Detectar prontamente estados anormales o errores intermedios.
• Realizar una planificación y ejecución precisas.
• Recuperarse de fallos sin tener que reproducir todo el historial.

Consecuentemente, la ejecución fiable de largo horizonte se ve limitada porque los agentes tienen dificultades para distinguir el progreso válido del ruido o de las afirmaciones de finalización autoinformadas pero no verificadas.

Metodología: StructAgent

Para abordar estos desafíos, los autores proponen StructAgent, un marco centrado en el estado que estructura explícitamente tanto el estado del agente como el flujo de trabajo alrededor de una representación causal unificada del progreso de la tarea. El marco consta de dos componentes complementarios:

1. Estado Unificado del Agente

En lugar de inferir el progreso a partir de trayectorias brutas, StructAgent mantiene un estado compacto, tipado y auditable $s_t$ que sirve como una interfaz compartida para todos los módulos. El estado se define como:
$$s_t = (s_t^{req}, s_t^{val}, s_t^{ver})$$

• $s_t^{req}$ (Requerimientos): Almacena los requerimientos del subobjetivo actual, especificando qué debe lograrse y qué debe verificar el verificador.
• $s_t^{val}$ (Valores Útiles): Almacena valores persistentes y útiles descubiertos durante la ejecución (por ejemplo, rutas de archivos, URLs, entidades seleccionadas).
• $s_t^{ver}$ (Evidencias Verificadas): Almacena la evidencia recolectada por el verificador durante el proceso de sondeo, permitiendo la auditoría y la reutilización.

Transiciones Orientadas a la Causalidad: Las transiciones de estado están estrictamente controladas. El estado de un requerimiento ($\sigma_{i,t}$) solo puede cambiar a VERIFICADO o INVALIDADO basándose en una decisión respaldada por el verificador. Esto asegura que las actualizaciones de progreso estén fundamentadas en evidencia verificable en lugar de en el autoinforme del agente.

2. Flujo de Trabajo Estructurado

El marco opera en un bucle de ejecución fijo: Planificador $\rightarrow$ Actor $\rightarrow$ Verificador $\rightarrow$ Actualización de Estado.

• Planificador: Lee el estado actual para seleccionar el siguiente subobjetivo ($g_t$). No necesita reconstruir el progreso a partir del historial bruto.
• Actor: Intenta ejecutar el subobjetivo en el entorno, produciendo una traza de acción ($\tau_t$).
• Verificador: Comprueba si el subobjetivo intentado produjo un progreso válido utilizando sondeos estructurados y agénticos (por ejemplo, comprobando archivos, salidas de shell, estados de aplicaciones). Emite una decisión ($d_t$) para verificar, invalidar o dejar el estado sin cambios.
• Memoria: Proporciona soporte condicionado al estado, sugiriendo subobjetivos o patrones de acción basados en experiencias reutilizables.

Capacidades Clave Habilitadas

• Puntos de Control de Progreso (Checkpointing): El historial de estado sirve como una instantánea autocontenida y legible por humanos, permitiendo que los agentes reanuden la ejecución sin reproducir todo el historial de interacción.
• Recuperación de Fallos Dirigida: Cuando el progreso se estanca, el sistema diagnostica el problema utilizando evidencias verificadas (por ejemplo, falta de evidencia, requerimientos conflictivos) y selecciona intervenciones específicas (replanificación, reintento o intervención humana) en lugar de reintentos genéricos.
• Ejecución con Soporte de Herramientas: Los patrones recurrentes se resumen en procedimientos reutilizables. El actor puede invocar estas herramientas, pero los resultados solo se comprometen en el estado si son verificados.

Principales Contribuciones

1. Estado Unificado: Introducción de una representación de estado compacta, tipada y auditable que proporciona planificación, actuación y verificación con una visión compartida del progreso de la tarea.
2. Flujo de Trabajo Estructurado: Diseño de un bucle de planificación-actuación-verificación donde solo las decisiones respaldadas por el verificador pueden comprometer, preservar o invalidar el progreso.
3. Validación Empírica Amplia: Demostración de que el marco mejora diversos backbones de LLM y VLM en tareas de uso de computadora de largo horizonte y se generaliza a través de dominios (escritorio, web y Minecraft).

Resultados Experimentales

OSWorld-Verified (Escritorio)

El marco fue evaluado en OSWorld-Verified, un benchmark para el uso de computadora de largo horizonte. StructAgent mejoró consistentemente el rendimiento a través de varios backbones:

• Qwen3.5-9B: Mejoró la tasa de éxito del 27.0% (modelo único) al 46.9%.
• Qwen3.5-27B: Mejoró la tasa de éxito del 31.6% al 62.2%.
• MiniMax-M3: Alcanzó un nuevo estado del arte de código abierto del 78.9%, superando la línea base de modelo único de 75.2%.
• Rendimiento por Dominio: Las ganancias fueron más pronunciadas en tareas de "Oficina" (hojas de cálculo, documentos) donde hay estados intermedios duraderos y comprobaciones basadas en archivos disponibles. Las tareas de aplicaciones cruzadas siguieron siendo desafiantes pero mostraron mejoras con backbones más fuertes.

Generalización

• Web (Mind2Web): StructAgent se generalizó a entornos web, logrando un 47.3% (Qwen3.5-9B) y un 52.3% (Qwen3.5-27B), superando las líneas base reproducidas. Las ganancias fueron más fuertes en tareas de búsqueda de información donde el progreso puede rastrearse mediante URLs y estados de página.
• Minecraft: El marco se instanció en Minecraft reemplazando las fuentes de evidencia de escritorio por verificación basada en inventario. Logró una tasa de éxito promedio ponderada por tarea del 76% (frente al 59% de Optimus-1), demostrando que la disciplina de actualización de estado es agnóstica al dominio.

Análisis

• Calidad de la Verificación: La verificación estructurada mejoró la recuperación (recall) de 0.67 a 0.81 en comparación con la verificación puramente visual, principalmente al recuperar finalizaciones reales que eran invisibles en las capturas de pantalla finales (por ejemplo, existencia de archivos, salidas de comandos).
• Modos de Fallo: El análisis de las trayectorias fallidas reveló que los errores se distribuyen entre el Planificador (30%), el Verificador (30%) y el Actor (33%), lo que indica que la fiabilidad de largo horizonte requiere mejoras en todo el sistema y no solo en el escalado del actor.

Significado y Reivindicaciones

El artículo argumenta que el propósito de la abstracción es crear un nivel semántico donde uno pueda ser "absolutamente preciso" (citando a Edsger W. Dijkstra). StructAgent logra esto alejándose de la generación continua sobre historiales ruidosos hacia una estructura causal explícita.

Los autores afirman que:

1. Transparencia y Control: Al imponer transiciones de estado respaldadas por el verificador, el progreso del agente se vuelve transparente, auditable y controlable.
2. Robustez: El marco permite una recuperación de fallos dirigida y una finalización de tareas basada en evidencia, reduando la dependencia de las frágiles afirmaciones de "HECHO" autoinformadas.
3. Generalidad: El paradigma centrado en el estado no está ligado a escalas de modelos específicos o entornos de escritorio; se generaliza efectivamente a navegadores web y entornos de juego (Minecraft) adaptando la fuente de evidencia mientras mantiene el mismo flujo de trabajo estructural.

El trabajo se posiciona como una solución a nivel de sistemas para la fiabilidad de largo horizonte, sugiriendo que estructurar el progreso de la tarea misma es tan crítico como mejorar los modelos de lenguaje subyacentes.