Resumen Técnico: Habilidad-Como-Pseudocódigo (SaP)

Enunciado del Problema

Los agentes modernos basados en LLM dependen de bibliotecas de habilidades—colecciones de documentos procedimentales (típicamente en Markdown) que los agentes recuperan y siguen durante la ejecución de tareas. Sin embargo, estas bibliotecas se redactan actualmente como prosa libre. Esta representación crea un cuello de botella significativo: el agente debe volver a derivar tanto el esquema de entrada (qué hace la habilidad) como la sintaxis concreta de invocación (cómo llamarla) en cada recuperación.

Los autores observan que este formato rico en prosa induce un bucle de "confundido → volver a recuperar → aún confundido". Cuando un agente emite una acción parcialmente correcta basada en una descripción en prosa, el entorno a menudo devuelve retroalimentación poco informativa (por ejemplo, "No sucede nada"). El agente vuelve a recuperar la misma prosa, falla al extraer el detalle faltante y repite el ciclo. Este bucle impulsa tanto los fallos en las tareas como el aumento de los costos de llamadas a LLM. Aunque existen catálogos tipificados como OpenAPI, no son la superficie de despliegue estándar para las habilidades de los agentes, las cuales permanecen en Markdown.

Metodología: Habilidad-Como-Pseudocódigo (SaP)

Los autores proponen Habilidad-Como-Pseudocódigo (SaP), un pipeline automático que convierte bibliotecas de habilidades en Markdown en pseudocódigo tipificado con control de calidad determinista. La idea central es que dos señales específicas acortan el bucle de recuperación-acción:

1. Un Contrato Tipificado: Una firma estructurada que expone el disparador, los esquemas de entrada/salida y las condiciones previas/posteriores.
2. Plantillas de Acción Concretas: Las secuencias exactas de tokens que el entorno acepta (por ejemplo, move {obj} to {target}), distintas del contrato abstracto.

El Pipeline

El pipeline de SaP procesa una biblioteca de habilidades padre (documentos en Markdown) a través de cinco etapas más dos pasadas de verificación posteriores conscientes de LLM:

1. Analizador: Divide los documentos en Markdown en unidades procedimentales (secciones bajo encabezados).
2. Propositor de Candidatos: Agrupa unidades de uno o más padres en clústeres candidatos basados en verbos, objetos y enlaces de código compartidos, utilizando agrupación basada en incrustaciones (embeddings).
3. Extractor de Contratos (LLM): Para cada clúster, una sola llamada a LLM redacta un contrato tipificado JSON estricto ($\kappa$).
4. Verificador (Determinista): Un verificador determinista de cuatro comprobaciones evalúa el contrato borrador. Un contrato solo se promueve si pasa:
   • Cobertura: Los strings de disparador y E/S del contrato deben estar presentes en el texto de la unidad padre.
   • Vinculación: Cada entrada requerida en el contrato debe tener un segmento correspondiente en el texto padre.
   • Sustitución: La unidad padre debe ser reemplazable sintácticamente por un marcador de posición invoke(κ, args) sin romper el flujo de control.
   • Riesgo: El contrato no debe contener efectos secundarios inseguros (por ejemplo, rm -rf, salida de red no declarada).
5. Refactorización: Los contratos validados se incrustan en las habilidades padre.
   • Extracción de Vinculación (BE): Una pasada de LLM que verifica si una unidad específica es una instancia genuina del contrato y extrae las vinculaciones de argumentos específicas. Las coincidencias espurias se descartan.
   • Limpieza de Reescritura (RC): Una pasada de LLM que detecta y reescribe conflictos residuales de prosa (por ejemplo, un bloque de ejemplo usando un verbo como put cuando el entorno requiere move) para alinearse con el contrato verificado.

Sustitución en Tiempo de Recuperación

En tiempo de inferencia, el agente recupera un paquete de habilidades sustituido en lugar de prosa cruda. Para una habilidad padre recuperada, el sistema reemplaza el contenido original con:

1. Plantillas de Acción: Secuencias de comandos concretas y ejecutables con vinculaciones extraídas (colocadas primero).
2. Esqueleto Reescrito: La estructura padre con marcadores de posición invoke(κ, args).
3. Contrato Incrustado: La firma tipificada y el esquema para la habilidad hija invocada.

Críticamente, el sistema emplea un pool de recuperación jerárquico únicamente. Los contratos hijos promovidos se almacenan internamente y son únicamente accesibles a través del marcador de posición invoke del padre. Evitar exponer a los hijos como resultados de nivel superior independientes es crucial, ya que privaría al agente del contexto necesario (las plantillas de acción del padre).

Contribuciones Clave

1. Reencuadre de la Mejora de Habilidades: El artículo reencuadra la optimización de bibliotecas de habilidades como un problema de conversión de prosa a pseudocódigo tipificado con control de calidad determinista, complementando el trabajo existente de enrutamiento tipificado que asume que los contratos ya existen.
2. El Pipeline SaP: Una arquitectura novedosa que presenta un verificador determinista de cuatro comprobaciones y dos pasadas posteriores al verificador conscientes de LLM (BE y RC), cada una protegida por comprobaciones posteriores deterministas para garantizar seguridad y consistencia.
3. Interfaz de Recuperación Jerárquica: Un mecanismo de recuperación que entrega un paquete estructurado (contrato tipificado + plantilla concreta) por invocación, separando el "qué" (contrato) del "cómo" (plantilla).
4. Validación Empírica: Demostración de que SaP mejora simultáneamente las tasas de éxito en tareas y reduce los costos de tokens/lamadas a LLM en comparación con la línea base Graph-of-Skills (GoS).

Resultados

Se realizaron experimentos en la partición no vista de ALFWorld (134 juegos) utilizando gpt-4o-mini y un subconjunto de SkillsBench (10 tareas) utilizando gpt-5-codex.

• Rendimiento en ALFWorld: A través de tres semillas (402 juegos emparejados), SaP ganó 82/402 juegos en comparación con 47/402 para la línea base GoS. Esto representa un aumento relativo de recompensa del 74% (McNemar $p = 8.2 \times 10^{-5}$).
• Ganancias de Eficiencia: SaP logró estas ganancias mientras reducía los tokens de entrada en un 22.8%, los tokens de salida en un 17.3% y las llamadas a LLM en un 14.5% por juego.
• Análisis del Mecanismo: La mejora se atribuye a romper el "bucle de recuperación-acción". Los agentes SaP emitieron significativamente menos errores de "No sucede nada" y solicitudes de recuperación repetida. La corrección de la acción post-recuperación mejoró del 20.5% (GoS) al 29.3% (SaP).
• Ablación: Eliminar la separación jerárquica (exponer a los hijos como resultados independientes) causó una caída del 27% en la recompensa, confirmando la necesidad de la estructura de paquete padre-hijo. Las pasadas BE y RC demostraron reparar modos de fallo distintos (membresía de clúster espuria y conflictos de sintaxis, respectivamente).

Significado y Afirmaciones

El artículo afirma que la propia representación en prosa, en lugar de una falta de factorización, es el cuello de botella dominante para los agentes LLM que consumen bibliotecas de habilidades. Al automatizar la conversión de prosa a pseudocódigo tipificado con verificación determinista, SaP proporciona a los agentes una señal de "qué" (contrato) y "cómo" (plantilla) en una sola respuesta.

Los autores posicionan a SaP como una solución del lado del productor para el problema del enrutamiento tipificado. Mientras que el trabajo existente asume que los contratos están escritos a mano, SaP los recupera de la prosa. La metodología se presenta como un enfoque disciplinado donde cada extracción de LLM es una hipótesis verificada por reglas deterministas, en lugar de una salida de caja negra.

El artículo nota modestamente que, aunque el pipeline está soportado arquitectónicamente para APIs tipificadas (OpenAPI), la evaluación empírica actual se limita a bibliotecas en Markdown. Además, el mecanismo de reemplazo es estático (sintáctico) en lugar de dinámico (expansión en tiempo de ejecución), dependiendo de la interfaz de recuperación para proporcionar contratos hijos bajo demanda. Los resultados sugieren que para bibliotecas de habilidades estáticas, el costo de la conversión de prosa a estructura puede pagarse en el momento de la indexación en lugar de en cada recuperación, mejorando significativamente la eficiencia y fiabilidad del agente.