Resumen Técnico: SLBench – Evaluando cómo los agentes de LLM siguen relaciones lógicas en las habilidades (skills)

1. Planteamiento del problema

Los agentes de Modelos de Lenguaje Extensos (LLM) dependen cada vez más de habilidades externas: documentos procedimentales reutilizables (por ejemplo, archivos SKILL.md) que empaquetan conocimiento de dominio, flujos de trabajo y restricciones operativas. A diferencia de las instrucciones simples, las habilidades están compuestas por múltiples cláusulas instructivas que interactúan lógicamente. Estas interacciones incluyen precondiciones (que controlan la ejecución de acciones), restricciones (que limitan el alcance de la ejecución), poscondiciones (que requieren limpieza o seguimiento), fallbacks (mecanismos de respaldo), excepciones y sobreescrituras (overrides).

El problema central identificado es que los agentes a menudo satisfacen la cláusula de acción principal y saliente de una habilidad, pero fallan al resolver las relaciones lógicas que gobiernan las cláusulas. Esto conduce a fallos de composición donde el agente parece completar una tarea, pero produce resultados inseguros, como dejar archivos sensibles en el disco después de un procesamiento, eludir puertas de seguridad o no realizar un rollback tras un error. Los benchmarks existentes evalúan mayoritariamente si los agentes completan tareas o siguen políticas generales, pero no logran caracterizar la estructura lógica interna de los documentos de habilidades ni probar si los agentes satisfacen el comportamiento compuesto implícito en la interacción de las cláusulas.

2. Metodología

2.1 Marco de trabajo SkillLogic

Los autores introducen SkillLogic, un marco para analizar las relaciones lógicas en los archivos de habilidades y construir pruebas ejecutables.

• Taxonomía: El marco define ocho tipos de relaciones lógicas entre cláusulas procedimentales:
  1. Precondición (Precondition): La cláusula $c_j$ debe cumplirse antes de que la acción de $c_i$ sea válida.
  2. Poscondición (Postcondition): La cláusula $c_i$ está incompleta a menos que ocurra el seguimiento $c_j$.
  3. Restricción (Constraint): $c_i$ solo está permitida dentro del límite $c_j$.
  4. Conjunción (Conjunction): Todas las obligaciones ($c_i \land c_j$) deben cumplirse conjuntamente.
  5. Respaldo (Fallback): $c_j$ se aplica solo después de que $c_i$ falle.
  6. Excepción (Exception): $c_j$ anula la configuración por defecto de $c_i$ bajo una condición específica.
  7. Sobreescritura (Override): Una $c_j$ más fuerte gobierna cuando ambas se aplican.
  8. Conflicto (Conflict): $c_i$ y $c_j$ no pueden satisfacerse simultáneamente.
• Pipeline de análisis: SkillLogic extrae cláusulas del texto de la habilidad, selecciona un flujo de trabajo primario e identifica relaciones fundamentadas. Prioriza las relaciones que están fundamentadas en la fuente, que tienen un alto impacto y que son localmente testeables.

2.2 Construcción de SLBench

Utilizando SkillLogic, los autores construyeron SLBench, un benchmark ejecutable de 86 casos auditados por humanos.

• Fuente de datos: El pipeline muestreó 5,224 habilidades únicas de SkillsMP. Tras la deduplicación y el análisis, 3,751 habilidades contenían relaciones lógicas válidas.
• Selección: Los casos se filtraron por alto impacto (por ejemplo, filtraciones de privacidad, configuraciones inseguras) y capacidad de graduación determinista. El conjunto final incluye 47 casos de violación y 39 casos de control.
• Diseño de calificación: El benchmark utiliza un enfoque de calificación determinista basado en artefactos. En lugar de evaluar la respuesta de lenguaje natural del agente, el calificador verifica los artefactos de ejecución (estados de archivos, trazas de comandos, cambios en el repositorio).
  • Precedencia de lo inseguro primero (Unsafe-First Precedence): Si se dispara cualquier señal de violación (por ejemplo, un comando prohibido, falta de limpieza), la ejecución se etiqueta como insegura, incluso si también están presentes señales de seguridad (por ejemplo, la existencia del archivo de salida correcto). Esto aborda la asimetría donde el comportamiento inseguro suele ser nítido y observable, mientras que el comportamiento seguro puede adoptar muchas formas válidas.

2.3 Mitigación: SLGuard

Los autores proponen SLGuard, un scaffold ligero en tiempo de inferencia. Antes de la ejecución, SLGuard analiza la habilidad objetivo y genera una lista de verificación de relaciones (por ejemplo, "verificar precondiciones", "asegurar que se cumplan las poscondiciones"). Se instruye al agente para que verifique explícitamente estas relaciones antes de finalizar el flujo de trabajo. Esto permite probar si la exposición de la estructura lógica mejora el comportamiento del agente sin modificar los archivos de habilidad subyacentes.

3. Resultados clave

3.1 Prevalencia de relaciones lógicas

Un análisis de más de 5,000 habilidades públicas reveló que el 70% contiene al menos una relación lógica. Los tipos más comunes encontrados fueron las restricciones y las precondiciones, seguidas de las poscondiciones y los fallbacks.

3.2 Rendimiento de los agentes en SLBench

Los autores evaluaron agentes de codificación convencionales (Codex y Claude Code) a través de seis backbones de LLM en SLBench:

• Altas tasas de violación: Las tasas de inseguridad oscilaron entre el 35.1% y el 70.2%.
  • Codex con GPT-5.5 mostró la tasa de violación más alta (70.2%).
  • Claude Code con Opus 4.7 tuvo la tasa de violación más baja (35.1%) pero la tasa de inconclusos más alta (35.1%), lo que sugiere un compromiso entre la cautela y la finalización de la tarea.
• Modos de fallo: Los agentes fallaron frecuentemente al resolver precondiciones (actuar antes de las puertas de aprobación), conflictos (no resolver cláusulas incompatibles) y sobreescrituras (ignorar bloqueadores más fuertes). Los fallos de poscondición también fueron comunes, donde los agentes completaron la tarea principal pero omitieron pasos de limpieza o reporte requeridos.
• Auditoría humana: Una auditoría humana de 12 casos de violación de alta calidad confirmó que los textos de las habilidades eran generalmente claros (baja ambigüedad). Los humanos pudieron resolver el comportamiento seguro a partir del texto original, indicando que los fallos derivan de brechas de capacidad del agente en la resolución de relaciones lógicas, y no solo de la ambigüedad de la habilidad. Sin embargo, aclarar el texto de la habilidad redujo las violaciones a la mitad, lo que sugiere que un texto de habilidad de baja saliencia también contribuye al modo de fallo.

3.3 Efectividad de SLGuard

La aplicación de SLGuard a casos específicos redujo las violaciones en un 63%.

• La mitigación fue más efectiva para las relaciones que involucran puertas concretas o límites de alcance (por ejemplo, conflictos, sobreescrituras, poscondiciones).
• Fue menos efectiva para las precondiciones y las excepciones, donde el éxito requiere un seguimiento de estado más profundo o razonamiento de dominio, lo que sugiere que el prompting por sí solo no es una defensa completa para todos los tipos de relación.

4. Significado y Reivindicaciones

El artículo establece el seguimiento de relaciones lógicas como un modo de fallo distinto y relevante para la seguridad en agentes guiados por habilidades.

• Desafío distintivo: Los resultados demuestran que un agente puede ser "servicial" al completar la tarea principal y, simultáneamente, violar las restricciones de seguridad debido a un fallo en la composición de las relaciones lógicas entre las cláusulas.
• Brecha de evaluación: Los benchmarks existentes no logran capturar estos fallos de composición internos. SLBench proporciona una herramienta necesaria para evaluar si los agentes satisfacen el comportamiento compuesto implícito en las cláusulas de las habilidades interactivas.
• Implicaciones de diseño: Los hallazgos motivan la necesidad de un diseño de habilidades consciente de las relaciones (hacer que las estructuras lógicas sean más salientes) y una evaluación más rigurosa de las habilidades procedimentales. El éxito de SLGuard sugiere que el scaffolding explícito de las relaciones lógicas puede mitigar una parte significativa de estos fallos.

Los autores concluyen que el uso fiable de las habilidades requiere más que un seguimiento ordinario de instrucciones; los agentes deben satisfacer el comportamiento compuesto implícito en las cláusas de las habilidades para garantizar la seguridad y la corrección.