Resumen Técnico: Pruebas de Flujos de Trabajo Agénticos con Criterios de Cobertura Estructural

Declaración del Problema

Los sistemas multiagente se despliegan cada vez más como flujos de trabajo estructurados donde los agentes, las herramientas, las reglas de acceso y las rutas de delegación están definidos explícitamente. Sin embargo, las prácticas actuales de evaluación dependen en gran medida del éxito de la tarea de extremo a extremo, las puntuaciones de referencia y la calidad de la respuesta final. Estas métricas proporcionan evidencia limitada de que la estructura de coordinación declarada haya sido realmente ejercitada. Un flujo de trabajo puede completar una tarea con éxito mientras deja herramientas específicas sin invocar, reglas de acceso restringido sin probar o rutas de delegación sin explorar. En consecuencia, es difícil evaluar la adecuación del conjunto de pruebas o detectar regresiones estructurales en el acceso a herramientas y la delegación entre agentes. El artículo argumenta que el éxito de extremo a extremo es un proxy poco fiable para la cobertura estructural en sistemas multiagente, particularmente a medida que los flujos de trabajo evolucionan y pequeños cambios en la definición pueden alterar las obligaciones estructurales sin provocar fallos inmediatos en la tarea.

Metodología

Los autores proponen un enfoque de pruebas estructurales que trata las especificaciones de flujos de trabajo multiagente como el artefacto principal testeable. La metodología sigue un pipeline de cinco pasos:

1. Extracción de Especificación: Se extrae una especificación normalizada de flujo de trabajo multiagente ($S$) del código fuente (específicamente flujos de trabajo al estilo del SDK de Agentes de OpenAI). Esta especificación define los agentes alcanzables, las aristas de herramientas permitidas, las aristas de herramientas restringidas y las aristas de delegación.
2. Construcción de Grafos: La especificación se convierte en un grafo de coordinación tipado $G(S)$, donde los nodos representan agentes y herramientas, y las aristas representan relaciones de acceso permitido, acceso restringido y delegación.
3. Derivación de Obligaciones: Las obligaciones estructurales se derivan del grafo, categorizadas en cuatro conjuntos:
   • Agentes alcanzables ($A_{reach}$)
   • Aristas de herramientas permitidas ($T_{allow}$)
   • Aristas de herramientas restringidas ($T_{restrict}$)
   • Aristas de delegación ($D$)
4. Generación Guiada por Cobertura: El sistema sintetiza "objetivos de testigo tipados" a partir de los conjuntos de obligaciones. Estos objetivos se realizan como escenarios de prueba en lenguaje natural utilizando DSPy, un marco declarativo para pipelines de modelos de lenguaje. Crucialmente, DSPy se utiliza únicamente para la realización del escenario, no para definir la cobertura. El generador emplea un bucle de refinamiento acotado (hasta $N=5$ intentos) donde los prompts candidatos se ejecutan contra un adaptador de tiempo de ejecución. El bucle termina solo cuando la ejecución produce la evidencia estructural específica requerida por el objetivo (por ejemplo, una llamada a herramienta específica o un traspaso de delegación).
5. Observación y Medición en Tiempo de Ejecución: Las pruebas se ejecutan mediante un adaptador de tiempo de ejecución que registra trazas estructurales. La cobertura se mide verificando si las trazas observadas satisfacen los predicados de testigo para cada obligación.

Criterios de Cobertura

El artículo define cuatro criterios de cobertura estructural:

• C1 (Cobertura de Agentes): Se observa cada agente alcanzable.
• C2 (Cobertura de Herramientas Permitidas): Se ejercita cada arista agente-herramienta permitida.
• C3 (Cobertura de Herramientas Restringidas): Se ejercita cada arista agente-herramienta restringida a través de una observación de acceso restringido explícita (por ejemplo, un evento de rechazo o denegación), en lugar de meramente la ausencia de una llamada. Esto se trata como una prueba adversaria.
• C4 (Cobertura de Delegación): Se observa cada arista de delegación alcanzable.

Contribuciones Clave

El artículo presenta cuatro contribuciones principales:

1. Formulación: Formula las pruebas de flujos de trabajo multiagente como un problema de adecuación estructural sobre grafos de coordinación tipados derivados del código fuente de marcos de agentes.
2. Modelo de Cobertura: Define criterios de cobertura derivados de grafos para agentes alcanzables, aristas de herramientas permitidas, aristas de herramientas restringidas y aristas de delegación. Notablemente, trata la cobertura de herramientas restringidas como una obligación de observación negativa explícita.
3. Pipeline de Generación: Presenta un pipeline de generación de pruebas guiado por cobertura que convierte manifiestos de flujo de trabajo en objetivos de testigo tipados y utiliza una realización basada en DSPy y fundamentada en tiempo de ejecución para producir escenarios de prueba en lenguaje natural.
4. Evaluación Empírica: Evalúa el enfoque en diez flujos de trabajo derivados del SDK de Agentes de OpenAI, con un total de 49 agentes alcanzables, 47 herramientas y 403 obligaciones estructurales, incluyendo un análisis detallado del flujo de trabajo oai_customer_service.

Resultados Experimentales

La evaluación se realizó en diez referencias con una configuración fija (utilizando gpt-4.1-mini tanto para el realizador como para el agente bajo prueba).

• Extracción (RQ1): El pipeline extrajo exitosamente grafos de coordinación bien formados y derivó obligaciones estructurales para los diez flujos de trabajo sin intervención manual.
• Testigos de Herramientas Permitidas y Delegación (RQ2):
  • Los escenarios generados testificaron 54/75 (72%) de las obligaciones de herramientas permitidas (agregadas a través de las referencias; el artículo nota 45/65 en la Tabla II, pero el resumen afirma 54/75; el texto aclara 45/65 en la sección de resultados).
  • Los escenarios generados testificaron 36/48 (75%) de las obligaciones de delegación (agregadas; la Tabla II muestra 31/41).
  • Los objetivos de un solo salto superaron uniformemente. Los fallos ocurrieron principalmente en flujos de trabajo de múltiples saltos o donde la superposición semántica provocó que el coordinador enrutara a un especialista diferente.
• Testigos Adversarios de Herramientas Restringidas (RQ3):
  • La sondeo adversario elicito 23/248 (9.3%) de violaciones de llamadas restringidas.
  • Cuatro referencias no produjeron violaciones dirigidas, mientras que seis produjeron fallos concretos de enrutamiento incorrecto. Esto demuestra la capacidad del criterio para distinguir flujos de trabajo con restricciones robustas de aquellos con límites explotables.
• Inyección de Fallos (RQ4): En la referencia oai_customer_service, el arnés estructural probó exitosamente la robustez bajo fallos de herramientas inyectados (errores y cargas útiles malformadas), confirmando que el agente intentó la herramienta y no se bloqueó ni filtró cargas útiles de error crudas, aunque no verificó la corrección semántica.

Significado y Afirmaciones

El artículo afirma que la cobertura estructural proporciona una útil capa de adecuación para las pruebas de flujos de trabajo multiagente. No reemplaza la evaluación semántica ni las referencias de extremo a extremo, pero ofrece evidencia explícita de que los agentes declarados, las reglas de acceso a herramientas, las restricciones y las rutas de delegación han sido ejercitados.

• Valor Diagnóstico: El enfoque revela "estructura no probada". Las obligaciones fallidas identifican rutas de coordinación específicas que son difíciles de ejercitar, guiando a los desarrolladores a mejorar los prompts de enrutamiento o el endurecimiento del flujo de trabajo.
• Obligaciones Negativas: Al probar explícitamente las aristas de herramientas restringidas, el método descubre vulnerabilidades (prompts concretos que eluden las restricciones) que permanecerían invisibles en evaluaciones basadas únicamente en listas de permitidos.
• Limitaciones: Los autores son modestos en sus afirmaciones, señalando que los resultados son evidencia empírica de una sola ejecución y no estimaciones con poder estadístico. Reconocen que una alta cobertura estructural no garantiza la corrección semántica, la satisfacción del usuario ni la precisión factual. El método es actualmente específico para flujos de trabajo al estilo del SDK de Agentes de OpenAI, y el bucle de refinamiento acotado a veces falla en testificar obligaciones complejas de múltiples saltos dentro del presupuesto de intentos.

El artículo concluye que las pruebas estructurales complementan las evaluaciones de agentes existentes al cambiar el enfoque de "¿tuvo éxito la tarea?" a "¿qué partes del flujo de trabajo declarado fueron realmente probadas?".