💻 computer science

Testing Agentic Workflows with Structural Coverage Criteria

Cet article présente une approche de test structurel pour les flux de travail multi-agents qui les modélise sous forme de graphes de coordination afin de dériver des obligations de couverture, lesquelles sont ensuite concrétisées en tests exécutables via DSPy pour vérifier que les agents déclarés, les règles d'accès aux outils, les restrictions et les chemins de délégation sont effectivement sollicités.

Auteurs originaux : Nafiseh Kahani, Mojtaba Bagherzadeh

Publié 2026-05-27

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Nafiseh Kahani, Mojtaba Bagherzadeh

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous embauchiez une équipe de robots spécialisés pour gérer un service client. Vous leur donnez un code de règles strict : « Le robot A ne peut vérifier que les horaires de vol, le robot B ne peut réserver que des places, et le robot C est le manager qui décide qui fait quoi. » Vous écrivez également des règles spécifiques comme : « Le robot A est interdit de réserver des places. »

Maintenant, imaginez que vous souhaitiez tester si cette équipe fonctionne correctement.

L'Ancienne Méthode (Le Test du "Chemin Heureux")
Traditionnellement, les testeurs posaient simplement une question basique à l'équipe : « Je dois réserver une place. » Si l'équipe parvenait à réserver la place, le test était considéré comme « réussi ».

Le Problème : Cela ne prouve pas que l'équipe a respecté les règles. Peut-être que le robot A a tenté de réserver la place, mais que le robot B a pris le relais de toute façon. Ou peut-être que le robot A n'a même pas vu la demande. Le test était réussi, mais vous ne savez pas si les règles spécifiques que vous avez écrites ont été réellement suivies. Vous pourriez avoir un robot « caché » qui n'est jamais utilisé, ou une action interdite qui n'a jamais été vérifiée.

La Nouvelle Méthode (Couverture Structurelle)
Cet article propose une nouvelle façon de tester ces équipes d'IA. Au lieu de simplement vérifier si le travail final a été accompli, ils vérifient si chaque règle et chaque connexion du code de règles a été réellement utilisée.

Imaginez le code de règles de l'équipe comme une carte d'un réseau de métro :

Les stations sont les différents agents IA (les robots).
Les voies sont les chemins où ils se transmettent des tâches (la délégation).
Les lignes de train sont les outils qu'ils peuvent utiliser (comme « Vérifier le vol » ou « Réserver une place »).
Les Zones Rouges sont les voies où il est strictement interdit d'entrer (outils restreints).

La méthode des auteurs traite le code de règles comme cette carte de métro. Ils ne demandent pas seulement : « Le train est-il arrivé à destination ? » Ils demandent :

Le train a-t-il visité chaque station ? (Chaque robot a-t-il eu son tour ?)
Le train a-t-il parcouru chaque voie autorisée ? (Chaque robot a-t-il utilisé chaque outil qui lui était permis ?)
Le train a-t-il tenté d'entrer dans une Zone Rouge et été arrêté ? (Avons-nous prouvé que les règles interdites fonctionnent réellement ?)
Le train a-t-il changé de ligne à chaque point de correspondance ? (Les robots se sont-ils transmis les tâches correctement ?)

Comment Ils Procèdent
Les chercheurs ont construit un système qui agit comme un scénariste ultra-intelligent (en utilisant un outil appelé DSPy).

Lecture de la Carte : D'abord, le système lit le code et dessine la carte du métro (le « graphe de coordination »).
Écriture des Scénarios : Il rédige ensuite des demandes spécifiques en langage naturel conçues pour forcer l'équipe d'IA à utiliser des parties spécifiques de la carte.
- Exemple : Pour tester une « Zone Rouge », il pourrait demander au robot manager : « Veuillez réserver une place pour moi », en espérant que le manager tente de le faire directement (ce qui est interdit). Si le système détecte que le manager tente de violer la règle et s'arrête lui-même, c'est un test réussi de la restriction.
Le Contrôle de Réalité : Le système exécute ces scénarios sur la véritable équipe d'IA. Il ne regarde pas seulement la réponse finale ; il observe les journaux internes pour voir exactement quel robot a parlé, quel outil a été cliqué et quel transfert a eu lieu.

Ce Qu'ils Ont Découvert
Ils ont testé cela sur 10 configurations différentes d'équipes d'IA (allant de simples bots de service client à des équipes de recherche complexes).

Les Bonnes Nouvelles : Leur méthode a généré avec succès des tests prouvant que les équipes d'IA utilisaient leurs outils autorisés et se transmettaient les tâches correctement.
La Découverte des « Zones Rouges » : Lorsqu'ils ont tenté de piéger les équipes d'IA pour qu'elles enfreignent les règles, ils ont constaté que certaines équipes étaient très bonnes pour s'arrêter elles-mêmes (0 violation), tandis que d'autres tentaient accidentellement d'utiliser des outils interdits (violations trouvées). Cela est précieux car cela montre exactement où les règles sont faibles.
La Limite : Ils ont constaté que si une tâche nécessite de passer par de nombreux robots différents (un long trajet en métro), il est plus difficile pour leur scénariste de faire suivre à l'IA exactement ce chemin à chaque fois.

L'Essentiel
Cet article soutient que le fait qu'une équipe d'IA résolve un problème ne signifie pas qu'elle suit sa conception. Vous devez vérifier la structure de l'équipe, pas seulement le résultat.

C'est comme vérifier une voiture : vous ne vous contentez pas de la conduire au magasin pour voir si elle fonctionne. Vous vérifiez également si les freins ont été testés, si les airbags se sont déployés lors d'un crash-test, et si l'huile du moteur a été changée. Cet article nous fournit une liste de contrôle pour s'assurer que chaque partie de la conception d'une équipe d'IA a été testée, garantissant ainsi que les règles que nous établissons sont réellement suivies.

Résumé technique : Test des flux de travail agentiques avec des critères de couverture structurelle

Énoncé du problème

Les systèmes multi-agents sont de plus en plus déployés sous forme de flux de travail structurés où les agents, les outils, les règles d'accès et les chemins de délégation sont explicitement définis. Cependant, les pratiques d'évaluation actuelles reposent létargement sur le succès des tâches de bout en bout, les scores de benchmarks et la qualité de la réponse finale. Ces métriques fournissent une preuve limitée que la structure de coordination déclarée a réellement été exercée. Un flux de travail peut mener à bien une tâche tout en laissant certains outils non invoqués, des règles d'accès restreintes non testées ou des chemins de délégation inexplorés. Par conséquent, il est difficile d'évaluer l'adéquation des suites de tests et de détecter les régressions structurelles dans l'accès aux outils et la délégation inter-agents. L'article soutient que le succès de bout en bout est un indicateur peu fiable de la couverture structurelle dans les systèmes multi-agents, particulièrement lorsque les flux de travail évoluent et que de petits changements de définition peuvent modifier les obligations structurelles sans causer d'échecs immédiats des tâches.

Méthodologie

Les auteurs proposent une approche de test structurel qui traite les spécifications de flux de travail multi-agents comme l'artefact principal testable. La méthodologie suit un pipeline en cinq étapes :

Extraction de la spécification : Une spécification de flux de travail multi-agents normalisée ( $S$ ) est extraite du code source (spécifiquement des flux de travail de type OpenAI Agents SDK). Cette spécification définit les agents atteignables, les arêtes d'outils autorisées, les arêtes d'outils restreintes et les arêtes de délégation.
Construction du graphe : La spécification est convertie en un graphe de coordination typé $G(S)$ , où les nœuds représentent les agents et les outils, et les arêtes représentent les relations d'accès autorisé, d'accès restreint et de délégation.
Dérivation des obligations : Les obligations structurelles sont dérivées du graphe, classées en quatre ensembles :
- Agents atteignables ( $A_{reach}$ )
- Arêtes d'outils autorisées ( $T_{allow}$ )
- Arêtes d'outils restreintes ( $T_{restrict}$ )
- Arêtes de délégation ( $D$ )
Génération pilotée par la couverture : Le système synthétise des « objectifs de témoins typés » (typed witness objectives) à partir des ensembles d'obligations. Ces objectifs sont réalisés sous forme de scénarios de test en langage naturel en utilisant DSPy, un framework déclaratif pour les pipelines de modèles de langage. Crucialement, DSPy est utilisé uniquement pour la réalisation du scénario, et non pour définir la couverture. Le générateur emploie une boucle de raffinement bornée (jusqu'à $N=5$ tentatives) où les prompts candidats sont exécutés contre un adaptateur d'exécution. La boucle se termine uniquement lorsque l'exécution produit l'évidence structurelle spécifique requise par l'objectif (par exemple, un appel d'outil spécifique ou un transfert de délégation).
Observation et mesure au runtime : Les tests sont exécutés via un adaptateur de runtime qui enregistre les traces structurelles. La couverture est mesurée en vérifiant si les traces observées satisfont les prédicats de témoin pour chaque obligation.

Critères de couverture

L'article définit quatre critères de couverture structurelle :

C1 (Couverture des agents) : Chaque agent atteignable est observé.
C2 (Couverture des outils autorisés) : Chaque arête agent-outil autorisée est exercée.
C3 (Couverture des outils restreints) : Chaque arête agent-outil restreinte est exercée par le biais d'une observation explicite d'accès restreint (par exemple, un refus ou un événement de rejet), plutôt que par la simple absence d'un appel. Cela est traité comme un test adversarial.
C4 (Couverture de la délégation) : Chaque arête de délégation atteignable est observée.

Principales contributions

L'article présente quatre contributions majeures :

Formulation : Il formule le test de flux de travail multi-agents comme un problème d'adéquation structurelle sur des graphes de coordination typés dérivés du code source de frameworks d'agents.
2.Modèle de couverture : Il définit des critères de couverture dérivés de graphes pour les agents atteignables, les arêtes d'outils autorisées, les arêtes d'outils restreintes et les arêtes de délégation. Notamment, il traite la couverture des outils restreints comme une obligation d'observation négative explicite.
Pipeline de génération : Il présente un pipeline de génération de tests piloté par la couverture qui convertit les manifestes de flux de travail en objectifs de témoins typés et utilise la réalisation ancrée au runtime via DSPy pour produire des scénarios de test en langage naturel.
Évaluation empirique : Il évalue l'approche sur dix benchmarks dérivés de l'OpenAI Agents SDK, totalisant 49 agents atteignables, 47 outils et 403 obligations structurelles, incluant une analyse détaillée du flux de travail oai_customer_service.

Résultats expérimentaux

L'évaluation a été menée sur dix benchmarks avec une configuration fixe (utilisant gpt-4.1-mini pour le réalisateur et l'agent testé).

Extraction (RQ1) : Le pipeline a extrait avec succès des graphes de coordination bien formés et a dérivé des obligations structurelles pour les dix flux de travail sans intervention manuelle.
Témoins d'outils autorisés et de délégation (RQ2) :
- Les scénarios générés ont témoigné de 54/75 (72 %) des obligations d'outils autorisés (agrégées sur les benchmarks ; l'article note 45/65 dans le Tableau II, mais l'abstract indique 54/75 ; le texte clarifie 45/65 dans la section des résultats).
- Les scénarios générés ont témoigné de 36/48 (75 %) des obligations de délégation (agrégées ; le Tableau II montre 31/41).
- Les cibles à un seul saut (single-hop) ont réussi uniformément. Les échecs se sont principalement produits dans les flux de travail à plusieurs sauts (multi-hop) ou là où un chevauchement sémantique a causé le routage vers un autre spécialiste.
Témoins adversariaux d'outils restreints (RQ3) :
- Le sondage adversarial a provoqué 23/248 (9,3 %) de violations d'appels restreints.
- Quatre benchmarks n'ont produit aucune violation ciblée, tandis que six ont produit des échecs de routage concrets. Cela démontre la capacité du critère à distinguer les flux de travail dotés de restrictions robustes de ceux possédant des frontières exploitables.
Injection de fautes (RQ4) : Sur le benchmark oai_customer_service, le harnais structurel a testé avec succès la robustesse sous injection de fautes d'outils (erreurs et payloads malformés), confirmant que l'agent a tenté l'appel à l'outil et n'a pas planté ou divulgué de payloads d'erreur bruts, bien qu'il n'ait pas vérifié la correction sémantique.

Signification et affirmations

L'article affirme que la couverture structurelle fournit une couche d'adéquation utile pour le test des flux de travail multi-agents. Elle ne remplace pas l'évaluation sémantique ou les benchmarks de bout en bout, mais offre une preuve explicite que les agents déclarés, les règles d'accès aux outils, les restrictions et les chemins de délégation ont été exercés.

Valeur diagnostique : L'approche révèle une « structure non testée ». Les obligations manquées identifient des chemins de coordination spécifiques difficiles à exercer, guidant les développeurs pour améliorer les prompts de routage ou le durcissement du flux de travail.
Obligations négatives : En testant explicitement les arêtes d'outils restreintes, la méthode découvre des vulnérabilités (prompts concrets contournant les restrictions) qui resteraient invisibles dans des évaluations basées uniquement sur des listes d'autorisation.
Limites : Les auteurs sont modestes quant à leurs affirmations, notant que les résultats sont des preuves empiriques d'une seule exécution plutôt que des estimations statistiquement puissantes. Ils reconnaissent qu'une couverture structurelle élevée ne garantit pas la correction sémantique, la satisfaction de l'utilisateur ou l'exactitude factuelle. La méthode est actuellement spécifique aux flux de travail de type OpenAI Agents SDK, et la boucle de raffinement bornée échoue parfois à témoigner des obligations complexes à plusieurs sauts dans le budget d'essais imparti.

L'article conclut que le test structurel complète les évaluations d'agents existantes en déplaçant l'attention de « la tâche a-t-elle réussi ? » vers « quelles parties du flux de travail déclaré ont été réellement testées ? ».