Resumen Técnico: ¿Valen siempre la pena los módulos de habilidades y memoria en línea?

Declaración del Problema

Los agentes web en línea frecuentemente aumentan un modelo "actor" base con módulos para la memoria, la inducción de flujos de trabajo o la síntesis de habilidades (por ejemplo, Agent Workflow Memory, Agent Skill Induction, ReasoningBank). Si bien estos módulos tienen como objetivo mejorar el éxito de las tareas mediante la reutilización del conocimiento de trayectorias previas, incurren en un costo significativo de tokens durante el tiempo de ejecución (test-time). Este costo rara vez se reporta junto con el costo de inferencia del actor, lo que crea un "problema de asignación simple": los tokens gastados en inducir, recuperar o inyectar conocimiento reutilizable son tokens que no están disponibles para la ejecución directa de la tarea (observar, razonar, actuar).

La pregunta central abordada es si, bajo un presupuesto de inferencia total fijo, es más efectivo asignar tokens a módulos de aumento en línea o a un actor vanilla que utilice el mismo presupuesto para pasos de interacción adicionales. Esto es particularmente relevante a medida que los modelos de frontera (por ejemplo, Gemini 3, GPT-5.4) han mejorado en el razonamiento de múltiples pasos, reduciendo potencialmente la necesidad de andamiaje externo.

Metodología

El estudio realiza una evaluación con restricciones de presupuesto a través de tres dominios de WebArena (Shopping, Reddit, Admin) y un dominio de WorkArena-L1 (trabajo de conocimiento empresarial).

Sistemas Comparados

Los autores comparan tres métodos de aumento en línea contra un baseline vanilla con presupuesto igualado:

1. AWM (Agent Workflow Memory): Induce flujos de trabajo en lenguaje natural a partir de trayectorias exitosas.
2. ASI (Agent Skill Induction): Sintetiza y reutiliza funciones de habilidad de Python ejecutables.
3. ReasoningBank: Destila estrategias de razonamiento de éxitos y fallos en un banco de memoria.
4. Vanilla-IB (Vanilla-Increased-Budget): Un actor vanilla sin módulos auxiliares. Para asegurar una comparación de presupuesto justa, su horizonte de interacción se extiende de los 10 pasos estándar a 15 pasos. También emplea un mecanismo de poda del árbol de accesibilidad basado en reglas para reducir la longitud del contexto sin llamadas al LLM.

Configuración Experimental

• Modelos: Gemini 3 Flash, GPT-5.4-mini y Qwen 3.6-27B.
• Contabilidad del Presupuesto: El uso total de tokens se agrega a través de todos los componentes del sistema (actor + módulos auxiliares).
• Rigor de la Evaluación: A diferencia del trabajo previo que a menudo reporta métricas de una sola ejecución, este estudio reporta resultados sobre tres ejecuciones independientes para capturar la varianza de ejecución a ejecución. Las métricas incluyen la tasa de éxito agregada (SR), el total de tokens por tarea y los límites de la estabilidad a nivel de tarea (Any-of-3 y All-of-3).
• Dominios: WebArena (Shopping, Reddit, Admin) y WorkArena-L1 (tareas de ServiceNow).

Resultados Clave

1. Superioridad del Baseline Vanilla en el Rendimiento Agregado

En los tres dominios de WebArena y en los tres modelos, el baseline Vanilla-IB igualó o superó consistentemente la tasa de éxito agregada de los métodos aumentados (AWM, ASI, ReasoningBank).

• Eficiencia de Tokens: Vanilla-IB a menudo logró estos resultados utilizando menos tokens totales que los métodos aumentados.
• Dependencia del Modelo: La brecha de rendimiento fue más pronunciada con GPT-5.4-mini, lo que sugiere que los modelos más débiles pueden generar flujos de trabajo o habilidades ruidosas que degradan el rendimiento. Incluso con modelos más fuertes, los métodos aumentados no lograron superar al actor vanilla con presupuesto igualado.
• WorkArena-L1: La tendencia se mantuvo en entornos empresariales, donde Vanilla-IB se mantuvo competitivo con los mejores métodos aumentados utilizando menos tokens.

2. La Ilusión de la "Asimetría de Presupuesto"

El estudio revela que las ganancias aparentes del aumento suelen provenir de una asimetría de presupuesto. Por ejemplo, en el dominio de Reddit con Gemini 3 Flash, AWM y Vanilla-IB tuvieron tasas de éxito idénticas a 10 pasos. Sin embargo, AWM consumió significativamente más tokens. Cuando el horizonte de Vanilla-IB se extendió (hasta 25 pasos), superó a AWM en tasa de éxito, utilizando aún menos tokens que la configuración estándar de 10 pasos de AWM. Esto indica que el "beneficio" del módulo fue en gran medida un artefacto de que el método aumentado tenía un mayor presupuesto de tokens, no una ventaja arquitectónica superior.

3. Fuentes de Sobrecarga de Tokens

El análisis de descomposición de tokens (Tabla 3) identifica dos fuentes de sobrecarga para los métodos aumentados:

1. Costos Explícitos del Módulo: Tokens consumidos por las llamadas de inducción, recuperación y verificación.
2. Inflación de Contexto Implícita: Los flujos de trabajo, memorias o habilidades recuperadas se inyectan en el prompt del actor en cada paso, aumentando el tamaño del prompt y, por lo tanto, el costo de cada llamada subsecuente del actor.

4. Varianza de Ejecución a Ejecución y Estabilidad

Se encontró que las tasas de éxito de una sola ejecución son inestables. El estudio reporta las métricas Any-of-3 (éxito en al menos una ejecución) y All-of-3 (éxito en las tres ejecuciones). Las brechas entre estos límites son significativas, lo que indica que las evaluaciones de una sola ejecución ocultan un ruido sustancial a nivel de tarea. Esta varianza se ve exacerbada por factores ambientales (tiempos de espera, cargas de página) y la naturaleza estocástica del muestreo de LLM.

5. Fragilidad Estructural del Aumento

• Habilidades Programáticas (ASI): Las habilidades sintetizadas dependen de IDs dinámicos del árbol de accesibilidad (BIDs). Si el estado de la página cambia (por ejemplo, una recarga), estos IDs se vuelven inválidos, causando fallos silenciosos o errores. Los agentes vanilla, que consultan al LLM en cada paso, se adaptan naturalmente a los cambios de estado.
• Confundidos de Verificación: En ASI, las funciones a menudo se almacenan incluso si fallan inicialmente pero el agente se recupera mediante acciones primitivas, lo que genera una librería de habilidades "rotas".
• Contaminación: AWM y ReasoningBank a menudo inducen conocimiento de trayectorias fallidas porque el "juez" (evaluador) solo ve el resultado final, no los pasos intermedios. Esto lleva a la inyección de estrategias incorrectas en el contexto del agente.

Significancia y Reclamaciones

El artículo aboga por un cambio en la higiene de la evaluación para los agentes web en línea:

1. Reporte de Costo Total: Las comparaciones deben reportar el uso total de tokens en todos los módulos, no solo del actor.
2. Baselines con Presupuesto Igualado: Los métodos aumentados deben compararse contra actores vanilla que utilicen el mismo presupuesto de inferencia total (por ejemplo, mediante horizontes extendidos) en lugar de conteos de pasos fijos.
3. Reporte de Multi-ejecución: Las evaluaciones deben reportar la varianza de multi-ejecución (por ejemplo, Any-of-3/All-of-3) como un criterio central, ya que las métricas de una sola ejecución son insuficientes para capturar la fiabilidad de los agentes en línea.

Los autores concluyen que, si bien las habilidades y la memoria de flujo de trabajo pueden ofrecer ganancias en dominios muy repetitivos, sus beneficios aparentes a menudo desaparecen cuando se contabiliza la sobrecarga frente a un actor con presupuesto igualado. La rápida mejora de los modelos base sugiere que el andamiaje externo puede ya no ser necesario para muchas tareas, y que "más pasos de interacción" es a menudo un uso más eficiente de los tokens que "un andamiaje más complejo".

Limitaciones

Los autores reconocen que sus conclusiones están restringidas a los dominios específicos (Shopping, Reddit, Admin) y los modelos probados. Señalan que los entornos con distribuciones de tareas altamente homogéneas o APIs de alto nivel estables (donde el descubrimiento de habilidades offline se amortiza) podrían presentar diferentes compensaciones que favorezcan el aumento. Además, el emparejamiento de presupuesto es una aproximación basada en el conteo de pasos, ya que el emparejamiento exacto de tokens es difícil en entornos web dinámicos.