Planificación de agentes LLM: ¿La descomposición jerárquica mejora el éxito en tareas web?

Se espera que los agentes web LLM-based completen tareas de múltiples pasos, como llenar formularios, navegar por menús y completar compras. Las evaluaciones existentes de estos agentes se centran principalmente en el éxito de extremo a extremo, ofreciendo una visión limitada de dónde surgen los fallos [1]. Esto es importante porque un solo número de éxito o fracaso no puede decirle a un desarrollador si una tarea falló debido a una mala planificación, una mala ejecución o una falla para notar y corregir errores. Un equipo que decide si invertir esfuerzo de ingeniería en un planificador jerárquico necesita saber si esa capa es realmente donde se concentran los fallos, o si el esfuerzo se gastaría mejor en otro lugar.

Un análisis enmarca a los agentes web LLM-based como necesitados de tres capacidades centrales: planificación de alto nivel, ejecución de bajo nivel y replanificación [1]. Analiza a los agentes web a través de estas mismas tres capas: planificación de alto nivel, ejecución de bajo nivel y replanificación [1]. Este marco es útil porque separa decidir qué hacer de hacerlo correctamente y de notar que algo salió mal y ajustarlo. La pregunta de investigación anterior, si la descomposición jerárquica supera a la planificación plana, se encuentra dentro de este marco: la descomposición es una forma de estructurar la capa de planificación, pero el análisis sugiere que la capa de planificación puede no ser donde ocurren la mayoría de los fallos.

Varios otros sistemas descritos a continuación construyen agentes que descomponen tareas, observaciones o planes de diferentes maneras, y reportan mejoras con respecto a sus propias líneas de base anteriores. Ninguno de estos sistemas se propuso probar la descomposición frente a una condición de control de planificación plana; comparan un nuevo método descompuesto con un método anterior o con el estado del arte anterior. Esa distinción es central para leer correctamente los números en esta nota, y explica por qué la respuesta directa anterior es cautelosa en lugar de definitiva.

Debido a que el campo actualmente mide el éxito principalmente a nivel de extremo a extremo, cualquier afirmación de que la descomposición en sí misma, aislada de otros cambios como nuevas indicaciones, nueva recuperación o nuevas herramientas, causa una mejora dada es una inferencia a partir de evidencia indirecta, no un hecho demostrado. Esta nota mantiene visible esa distinción en todo momento, marcando qué números provienen de qué comparación y negándose a fusionarlos.

Las afirmaciones describen varias cosas diferentes bajo el paraguas de la descomposición, y no son el mismo mecanismo. CoAct transfiere los patrones de planificación jerárquica y colaboración en la sociedad humana a los sistemas LLM [2], y lo hace a través de un agente de planificación global y un agente de ejecución local [2]. Esto es descomposición de roles: un agente planifica, otro ejecuta, y los dos se coordinan en lugar de que un solo modelo haga ambos trabajos.

WebAgent, en cambio, planifica con antelación descomponiendo instrucciones en sub-instrucciones canónicas [5]. Esto es descomposición de la instrucción misma en pasos más pequeños y estandarizados, en lugar de una división entre agentes de planificación y ejecución separados. La instrucción se descompone antes de que se introduzca cualquier distinción de rol de agente, por lo que la descomposición ocurre más temprano en el pipeline que en el enfoque basado en roles de CoAct.

RaDA separa la planificación en dos etapas: Retrieval-augmented Task Decomposition y Retrieval-augmented Action Generation [8], y no requiere ejemplos manuales [8]. Esto es descomposición del proceso de planificación en dos etapas secuenciales, cada una ayudada por recuperación, por lo que la descomposición es interna a un solo pipeline de planificación en lugar de dividirse entre agentes separados o expresarse como sub-instrucciones canónicas.

Region4Web reorganiza el AXTree en regiones funcionales a través de descomposición jerárquica y abstracción semántica [3]. Esto es descomposición del espacio de observación, no del plan o los roles del agente; cambia lo que el agente ve, no cómo planifica. Los planes estructurados en PDDL (Structured Planning Domain Definition Language) producen estrategias más concisas y dirigidas a objetivos que los planes en lenguaje natural (NL) [1], que es otro tipo de estructuración diferente, utilizando un lenguaje de planificación formal en lugar de texto libre, en lugar de dividir una tarea, un rol o una observación en partes.

Debido a que estos son cuatro o cinco mecanismos distintos (división de roles, división de instrucciones, división de etapas, división de observaciones y formalización del lenguaje), las ganancias reportadas para uno no pueden asumirse transferibles a otro, y ninguna de las afirmaciones los prueba directamente entre sí. Un lector que quiera saber si la descomposición funciona primero debe preguntar cuál de estos mecanismos se quiere decir, ya que las afirmaciones nunca los tratan como intercambiables y nunca informan un punto de referencia compartido entre todos ellos.

Region4Web reorganiza el AXTree en regiones funcionales a través de descomposición jerárquica y abstracción semántica [3]. PageDigest, construido sobre esta reorganización, entrega una observación a nivel de región al agente actor como un resumen compacto por página que persiste a través de los pasos [3]. Este es un caso donde la descomposición se aplica a lo que el agente percibe en una página, en lugar del plan que el agente forma o los roles que los agentes juegan. Es un punto de intervención diferente en el pipeline de la división de roles de CoAct, la división de instrucciones de WebAgent o la división de etapas de RaDA, y vale la pena tratarlo por separado porque apunta al lado de entrada del agente en lugar del lado de razonamiento o ejecución.

PageDigest reduce sustancialmente la longitud de observación mientras mejora la tasa de éxito general de la tarea en diversos LLM backbone y métodos de agente establecidos en WebArena [3]. Esta única afirmación reporta dos efectos juntos: una observación más corta y una tasa de éxito más alta, medidos a través de múltiples LLM backbone y múltiples métodos de agente existentes, todos en WebArena. No se dan cifras porcentuales exactas en la afirmación, por lo que el tamaño de la mejora y el tamaño de la reducción de longitud no pueden citarse con precisión aquí; solo se conocen la dirección y el punto de referencia de la afirmación tal como se declara.

Este resultado amplía la imagen de dónde puede ayudar la descomposición: no se trata solo de dividir planes o roles, sino de dividir y comprimir lo que el agente observa en cada paso, lo que puede importar tanto como cómo razona sobre la próxima acción. Dado que la afirmación describe el efecto como válido a través de diversos LLM backbone y métodos de agente establecidos, sugiere que la descomposición a nivel de observación no está ligada a un modelo específico o un método de planificación específico, aunque la afirmación no menciona qué backbones o qué métodos establecidos se probaron, por lo que la amplitud de esa generalidad no puede verificarse más allá de lo declarado.

Debido a que esta descomposición ocurre en la capa de observación, es lógicamente separable de la pregunta de la capa de planificación en la que se centra esta nota. Un desarrollador podría, en principio, combinar la reorganización de observación de PageDigest con un planificador plano o uno jerárquico, y las afirmaciones no informan qué combinación se probó realmente, o si la mejora depende de emparejarla con un tipo particular de planificador.

La perspectiva de planificación jerárquica en la fuente de la reclamación [1] señala la ejecución de bajo nivel como el cuello de botella dominante en los agentes web LLM actuales [1]. Esto se afirma después de distinguir tres capas: planificación, ejecución, replanificación, y significa que incluso cuando el plan en sí mismo es sólido, los agentes aún fallan más a menudo mientras llevan a cabo pasos individuales que mientras deciden cuáles deberían ser esos pasos. Este es un hecho central para la pregunta de investigación, porque implica que los cambios realizados solo en la capa de planificación, incluida la descomposición jerárquica de esa capa, pueden no abordar la capa donde ocurren la mayoría de los fallos.

La misma fuente sostiene que mejorar el anclaje perceptivo y el control adaptativo, no solo el razonamiento de alto nivel, es crítico para lograr una fiabilidad a nivel humano [1]. Esto se conecta directamente con el hallazgo del cuello de botella de ejecución: si la ejecución es donde ocurren la mayoría de los fallos, entonces un mejor anclaje (identificar correctamente lo que hay en la página) y un mejor control (actuar correctamente sobre ello) abordan el cuello de botella real, mientras que refinar el plan de alto nivel no lo hace. El anclaje y el control se encuentran dentro de la capa de ejecución del marco de tres capas, por lo que esta declaración refuerza en lugar de agregar una nueva afirmación al hallazgo del cuello de botella.

Leídos juntos, estos dos hallazgos ponen peso en la idea de que la descomposición jerárquica de la capa de planificación, por sí misma, puede no ser la palanca que más mejore la tasa de éxito, porque la capa de planificación no es donde ocurren la mayoría de los fallos que la fuente identifica. Esto no significa que la descomposición sea inútil; significa que las afirmaciones de la fuente no muestran que la descomposición se dirija al modo de fallo dominante que identifican.

Ninguno de los sistemas de descomposición descritos en otras partes de esta nota mide directamente si sus ganancias provienen de una mejor ejecución, una mejor planificación o una mejor replanificación; solo reportan cambios en la tasa de éxito general. Esta es una brecha probatoria más que una contradicción: es posible que CoAct, WebAgent, RaDA, SkillWeaver o Region4Web mejoren el éxito en parte al mejorar la ejecución o la replanificación como efecto secundario de su diseño, pero las afirmaciones tal como se presentan no descomponen sus números reportados en estos componentes, por lo que no se puede hacer tal atribución aquí.

CoAct logra un rendimiento superior sobre los métodos de línea base en tareas web de largo horizonte en el punto de referencia WebArena [2]; la afirmación no da un margen numérico, por lo que solo se conocen la dirección del resultado (mejor que los métodos de línea base), el tipo de tarea (tareas web de largo horizonte) y el punto de referencia (WebArena). La receta modular de WebAgent mejora el éxito en sitios web reales en más del 50% [5], y por separado, HTML-T5, parte del mismo trabajo de WebAgent, logra una tasa de éxito 18.7% más alta que el método anterior en el punto de referencia de automatización web MiniWoB [5], y logra un rendimiento de última generación en Mind2Web [5]. Estos son tres números separados de tres puntos de referencia separados (sitios web reales, MiniWoB, Mind2Web) dentro del mismo artículo; no deben sumarse ni tratarse como una ganancia unificada del pipeline, ya que cada cifra describe un entorno de tarea diferente y una línea de base de comparación diferente. La cifra de más del 50% es un resultado de sitio web real vinculado específicamente a la receta modular, la cifra del 18.7% es un resultado de MiniWoB vinculado específicamente a HTML-T5 en comparación con un método anterior nombrado, y el resultado de Mind2Web se indica solo como última generación, sin un margen numérico dado.

SkillWeaver reporta mejoras relativas en la tasa de éxito del 31.8% en WebArena [6] y del 39.8% en sitios web reales [6], y reporta que las APIs sintetizadas por agentes fuertes mejoran a los agentes débiles, produciendo mejoras de hasta el 54.3% en WebArena [6]. Estos tres números de SkillWeaver provienen del mismo marco pero de tres comparaciones diferentes: su propia línea de base en WebArena, su propia línea de base en sitios web reales y un entorno de transferencia entre agentes también en WebArena donde un agente débil se beneficia de APIs hechas por un agente fuerte. La cifra del 54.3% se describe como un límite superior, "hasta 54.3%", por lo que no debe leerse como una mejora típica o promedio; es un máximo observado bajo la condición de transferencia entre agentes.

AdaPlanner supera a las líneas de base de última generación en un 4.11% en MiniWoB++ [7], y lo hace permitiendo que el agente LLM refine su plan autogenerado de forma adaptativa en respuesta a la retroalimentación ambiental [7], un mecanismo de replanificación, no un mecanismo de descomposición como se ha estado usando el término en esta nota. RaDA encuentra mejoras consistentes con respecto al SOTA anterior en CompWoB y Mind2Web [8], nuevamente sin un margen numérico declarado, solo se dan la dirección (mejora consistente) y los dos puntos de referencia (CompWoB y Mind2Web).

Ninguno de estos seis resultados comparte un punto de referencia y una línea de base comunes entre sí de una manera que permita a un lector construir una clasificación entre CoAct, WebAgent, SkillWeaver, AdaPlanner y RaDA solo a partir de estas afirmaciones. WebArena aparece en los resultados de CoAct, SkillWeaver y Region4Web, que es la superposición más cercana entre los trabajos citados, pero incluso dentro de WebArena, las líneas de base contra las que se comparan difieren entre estos tres sistemas, por lo que incluso los números del punto de referencia compartido no se pueden clasificar directamente entre sí sin saber si usaron el mismo agente de línea base, el mismo modelo backbone y el mismo subconjunto de tareas.

Para un desarrollador que elige entre estos sistemas, las entradas concretas difieren según el método, y cada uno requiere una infraestructura de soporte diferente. CoAct requiere que dos roles de agente operen juntos: un agente de planificación global y un agente de ejecución local [2], siguiendo la transferencia de patrones de planificación jerárquica y colaboración de la sociedad humana [2]. Esto significa que un desarrollador necesita una capa de orquestación que pase tareas del planificador al ejecutor y devuelva los resultados de ejecución al planificador, ya que las afirmaciones describen una colaboración de dos agentes en lugar de un solo agente monolítico.

WebAgent requiere un paso de descomposición de instrucciones que produce sub-instrucciones canónicas antes de que comience la ejecución [5]; un desarrollador necesita el mapeo o mecanismo de indicación que produce estas formas canónicas, y este paso se sitúa aguas arriba del módulo de ejecución que lleva a cabo cada sub-instrucción. Debido a que la afirmación indica que esta descomposición ocurre planificando con antelación, las sub-instrucciones se generan antes de que comience la ejecución, en lugar de producirse una a una a medida que avanza la ejecución.

RaDA requiere un componente de recuperación que alimente ambas etapas, Retrieval-augmented Task Decomposition y Retrieval-augmented Action Generation [8], y específicamente no requiere que el desarrollador escriba ejemplos a mano [8], lo que reduce el costo de configuración en comparación con métodos que necesitan ejemplos seleccionados de pocos disparos. Un desarrollador que implemente RaDA necesita un índice o corpus de recuperación que ambas etapas puedan consultar, ya que la recuperación se describe como aumentativa tanto de la etapa de descomposición como de la etapa de generación de acciones, no solo de una de ellas.

SkillWeaver requiere un mecanismo para que el agente sintetice de forma autónoma habilidades reutilizables como APIs [6], ya que se describe como un marco centrado en habilidades que permite a los agentes auto-mejorarse de esta manera [6]; un desarrollador necesita almacenamiento para estas APIs sintetizadas y una forma de hacerlas invocables tanto por el agente fuerte que las hizo como por agentes más débiles que las reutilizan [6], ya que el resultado de transferencia entre agentes depende de que las APIs hechas por un agente sean utilizables por otro. Region4Web y PageDigest requieren acceso al AXTree de cada página para que pueda reorganizarse en regiones funcionales [3], y un mecanismo para persistir el resumen por página resultante a través de los pasos para el agente actor [3], lo que significa que el desarrollador necesita una capa de persistencia que lleve el resumen hacia adelante de un paso al siguiente en lugar de recalcularlo desde cero en cada paso.

Ninguna de las afirmaciones especifica tamaños de modelo exactos, costos de tokens o latencia de reloj de pared para ninguno de estos sistemas, por lo que estos deben medirse directamente si un desarrollador implementa alguno de ellos. Esta es una brecha genuina en el material fuente para cualquiera que haga planificación de costos: un desarrollador no puede presupuestar el gasto de API o el tiempo de respuesta esperado solo a partir de las afirmaciones y debe instrumentar su propia implementación para obtener estas cifras.

Las tres capacidades centrales identificadas para los agentes web LLM-based (planificación de alto nivel, ejecución de bajo nivel y replanificación [1]) proporcionan una lista de verificación que un desarrollador puede usar al ensamblar cualquiera de los sistemas anteriores: cada sistema implementa la planificación de alguna forma, pero un desarrollador debe verificar por separado si el sistema descrito también aborda la calidad de ejecución y la replanificación, ya que las afirmaciones no indican que ninguno de CoAct, WebAgent, RaDA o Region4Web mejore explícitamente las capas de ejecución o replanificación según lo definido en [1], solo que AdaPlanner apunta explícitamente a la replanificación a través de retroalimentación adaptativa [7].

Ninguna afirmación en este conjunto reporta un experimento controlado que varíe solo la presencia o ausencia de descomposición jerárquica mientras mantiene fijos el punto de referencia, el modelo y la línea de base. Cada mejora reportada compara un nuevo método basado en descomposición con un método anterior diferente o un estado del arte anterior, por lo que el tamaño de la mejora refleja tanto el cambio de descomposición como cualquier otra cosa que difiera entre el sistema nuevo y el antiguo, como nuevos componentes de recuperación, nuevas indicaciones o nuevo acceso a herramientas.

La afirmación de que la ejecución de bajo nivel sigue siendo el cuello de botella dominante en los agentes web LLM [1] sugiere que las ganancias atribuidas a una mejor descomposición de la planificación pueden reflejar parcial o totalmente mejoras en otras partes del pipeline, como la ejecución o la replanificación; las afirmaciones de la fuente no descomponen las ganancias reportadas de SkillWeaver, WebAgent o CoAct en contribuciones de la capa de planificación versus la capa de ejecución. De manera similar, mejorar el anclaje perceptivo y el control adaptativo se describe como crítico para la fiabilidad [1], pero ninguno de los artículos centrados en la descomposición en este conjunto reporta si sus sistemas cambiaron el anclaje o el control en absoluto, por lo que sigue siendo desconocido a partir de estas afirmaciones si alguna de las ganancias reportadas en la tasa de éxito tocó la capa identificada como el cuello de botella dominante.

Las evaluaciones existentes se centran principalmente en el éxito de extremo a extremo, ofreciendo una visión limitada de dónde surgen los fallos [1], que es exactamente la brecha que impide sacar una conclusión firme sobre la descomposición jerárquica específicamente. Esta brecha también significa que incluso dentro de los números reportados de un solo artículo, como las mejoras del 31.8% y 39.8% de SkillWeaver [6], no hay desglose disponible en las afirmaciones que indique si la mejora provino de una mejor descomposición de tareas, una mejor síntesis de habilidades o alguna otra parte del sistema.

Otra pregunta abierta es si los diferentes mecanismos de descomposición descritos en esta nota (división de roles en CoAct, división de instrucciones en WebAgent, división de etapas en RaDA y división de observaciones en Region4Web) producirían ganancias similares o diferentes si se probaran en el mismo punto de referencia con el mismo modelo backbone. Las afirmaciones no proporcionan ninguna base para predecir esto, ya que cada mecanismo se reporta solo dentro de la configuración experimental de su propio artículo.

SkillWeaver es un marco centrado en habilidades que permite a los agentes auto-mejorarse sintetizando de forma autónoma habilidades reutilizables como APIs [6], y esto plantea otra pregunta abierta que no responden las otras afirmaciones: si las habilidades sintetizadas autónomamente interactúan bien o mal con la descomposición jerárquica de la capa de planificación, ya que la síntesis de habilidades y la descomposición del plan son dos opciones de diseño diferentes que en principio podrían combinarse, pero ninguna afirmación reporta que se haya probado tal combinación.

Hasta que un estudio varíe la descomposición sola frente a una línea de base de planificación plana emparejada en el mismo punto de referencia con el mismo modelo, la respuesta honesta a la pregunta de investigación sigue siendo: los sistemas basados en descomposición a menudo mejoran sus propias líneas de base anteriores, pero esto no es lo mismo que demostrar que la descomposición en sí misma, aislada de otras opciones de diseño, aumenta la tasa de éxito. Los lectores deben tratar cada cifra porcentual en esta nota como vinculada a su propia línea de base y punto de referencia del artículo, no como una medida general de cuánto ayuda la descomposición jerárquica.

Un ingeniero competente que quiera probar si la descomposición jerárquica ayuda al éxito de las tareas web, en lugar de simplemente reutilizar el número reportado de un artículo, debe construir una comparación controlada en lugar de un solo sistema. El siguiente procedimiento sigue los métodos descritos en las fuentes citadas sin inventar nuevos mecanismos, y está organizado para que cada paso produzca una medición que pueda verificarse contra una línea de base claramente establecida.

1. Elija un punto de referencia utilizado en las afirmaciones, por ejemplo WebArena, MiniWoB o MiniWoB++, Mind2Web, o CompWoB, y un LLM backbone, y mantenga ambos fijos para toda la comparación. Esto es necesario porque ninguno de los resultados citados comparte un punto de referencia y una línea de base común entre los artículos, por lo que cualquier nueva comparación debe fijarlos por sí misma.
2. Construya un agente de línea base de planificación plana: un solo agente que recibe la instrucción de la tarea y produce acciones directamente, sin un paso explícito de descomposición, siguiendo el marco de que las evaluaciones actuales miden principalmente solo el éxito de extremo a extremo [1]. Esta línea de base le da al ingeniero un punto de referencia que ninguno de los artículos citados proporciona directamente en una forma comparable entre sistemas.
3. Construya una variante descompuesta a la vez, emparejando el mecanismo con un método citado: (a) una división de roles global y local como en CoAct, con un agente de planificación global y un agente de ejecución local [2]; (b) descomposición de instrucciones en sub-instrucciones canónicas como en WebAgent [5]; (c) un planificador de dos etapas como en RaDA, con Retrieval-augmented Task Decomposition seguida de Retrieval-augmented Action Generation [8], y sin ejemplos escritos a mano [8]; o (d) descomposición del espacio de observación como en Region4Web y PageDigest, reorganizando el AXTree en regiones funcionales y pasando un resumen persistente por página al agente actor [3].
4. Mantenga el código de ejecución de acciones idéntico entre la línea base plana y cada variante descompuesta, de modo que cualquier diferencia en la tasa de éxito pueda atribuirse al paso de descomposición en lugar de a diferencias de ejecución. Esto es importante directamente porque la ejecución de bajo nivel se identifica como el cuello de botella dominante [1], por lo que cualquier diferencia no controlada en el código de ejecución confundiría la comparación.
5. Ejecute tanto la línea base como cada variante en el mismo conjunto de tareas del punto de referencia, utilizando los mismos criterios de evaluación que el punto de referencia define para el éxito.
6. Registre no solo la tasa de éxito de extremo a extremo, sino también, cuando sea posible, los errores de paso de ejecución por separado de los errores de planificación, abordando la brecha de que las evaluaciones existentes ofrecen una visión limitada de dónde surgen los fallos [1]. Este paso responde directamente a la pregunta abierta dejada por el material fuente: si la ganancia de una variante de descomposición, si la hay, proviene de la capa de planificación o de alguna otra capa.
7. Compare la tasa de éxito de cada variante descompuesta con la tasa de éxito de la línea base plana en el mismo conjunto de tareas; reporte la diferencia como un resultado controlado, distinto de las comparaciones de línea base de los propios artículos citados, como la comparación de CoAct con los métodos de línea base [2] o la comparación de SkillWeaver con su propia versión anterior [6].
8. Si se agrega replanificación, trátela como una condición separada de la descomposición; observe que el mecanismo de AdaPlanner (refinar adaptativamente un plan autogenerado a partir de la retroalimentación ambiental [7]) es una capacidad de replanificación, no una descomposición del plan inicial, por lo que no debe etiquetarse como evidencia de descomposición en el informe final.
9. Si se agrega síntesis de habilidades, trátela como una condición separada nuevamente; el mecanismo de SkillWeaver de sintetizar de forma autónoma habilidades reutilizables como APIs [6] es una capacidad de auto-mejora, distinta de cómo se estructura el plan inicial, y su efecto de transferencia entre agentes (mejoras de hasta el 54.3% en WebArena cuando agentes débiles usan APIs hechas por agentes fuertes [6]) debe probarse independientemente de cualquier variante de descomposición.

Puntos de fallo comunes a tener en cuenta: confundir un cambio de descomposición con un cambio simultáneo de modelo o indicación, que es exactamente lo que hace que los números publicados en la sección de resultados medidos sean incomparables entre artículos; atribuir una ganancia en la tasa de éxito a la planificación cuando el material fuente sostiene que la ejecución es el cuello de botella dominante [1]; y reutilizar el número de línea base publicado de un punto de referencia en lugar de volver a ejecutar la línea base de planificación plana en condiciones idénticas, ya que pequeñas diferencias en el subconjunto de tareas o el modelo backbone pueden cambiar la tasa de éxito de una línea base independientemente de cualquier cambio de descomposición.

for variant in [flat_baseline, coact_style, webagent_style, rada_style, region4web_style]:
    run(variant, benchmark, backbone_llm)
    record(success_rate, execution_error_count, planning_error_count)
compare(variant.success_rate, flat_baseline.success_rate)