🤖 AI

XFlow: An Executable Protocol Programming System for Reliable Multi-Agent Workflows

Cet article présente XFlow, un système de programmation de protocoles exécutables doté de son propre langage spécifique au domaine, le XPF, qui améliore la fiabilité des flux de travail multi-agents basés sur les LLM en déplaçant les engagements critiques des prompts sous-spécifiés vers un harnais structuré et exécutoire qui hiérarchise l'incertitude via des cellules d'état typées et assure la médiation des sorties d'acteurs.

Auteurs originaux : Hanqi Li, Jing Peng, Zijian Wang, Lu Chen, Kai Yu

Publié 2026-06-16

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Hanqi Li, Jing Peng, Zijian Wang, Lu Chen, Kai Yu

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 êtes le metteur en scène d'une pièce de théâtre où les acteurs sont des modèles de langage étendus (LLM). Dans la manière actuelle de faire, vous donnez à ces acteurs un script (un prompt) et vous espérez qu'ils se souviendront des règles, qu'ils resteront dans leur personnage et qu'ils n'inventeront pas de faits.

Le problème est que si un acteur oublie une règle ou hallucine un fait, cette erreur ne reste pas seulement dans sa tête. Elle se propage à l'acteur suivant, corrompt toute la scène et gâche la pièce. C'est parce que le « script » (le prompt) et les « règles du régisseur » (la structure du système) sont mélangés de manière désordonnée.

XFlow est un nouveau système conçu pour corriger ce désordre. Considérez cela comme un carnet de règles intelligent et exécutable qui se situe entre les acteurs et la scène.

Voici comment cela fonctionne, en utilisant des analogies simples :

1. Le « Script » vs Le « Régisseur »

Actuellement, la plupart des systèmes d'IA reposent entièrement sur le « script » (le prompt). Vous devez écrire : « Rappelez-vous, ne mentez pas sur le prix », à l'intérieur du prompt. Si l'acteur est distrait, il peut oublier.

XFlow sépare le travail :

Les Acteurs (LLM) : Ils continuent de faire la réflexion créative et floue. Ils écrivent l'histoire, raisonnent sur des problèmes et utilisent des outils. Ils sont libres d'être créatifs.
Le Régisseur (Le Harnais) : C'est la nouvelle partie. Il détient les règles strictes, les faits et les contraintes. Il ne se soucie pas de l'écriture créative ; il se soucie uniquement de vérifier si les règles ont été respectées.

L'analogie : Imaginez une banque. Le guichetier (l'Acteur) parle au client et note la transaction. Mais le guichetier ne décide pas si l'argent est réel ou si le compte est suffisamment approvisionné. Ce travail appartient au Système de Coffre-fort (le Harnais). Le Système de Coffre-fort vérifie les chiffres avant que l'argent ne soit libéré. XFlow est ce Système de Coffre-fort pour les agents d'IA.

2. La « Boîte Magique » (Symboles)

Dans les anciens systèmes, si un acteur dit : « Je pense que le total est de 50 $ », cette phrase flotte dans l'historique de la conversation. L'acteur suivant pourrait la lire et la traiter comme un fait, même s'il ne s'agissait que d'une supposition.

XFlow introduit les Symboles. Considérez un Symbole comme une boîte étiquetée et verrouillée sur un tapis roulant.

Proposé : Un acteur place une valeur dans la boîte et l'étiquette « Proposé ». C'est juste une suggestion.
Validé : Le Régisseur vérifie la boîte. A-t-elle la bonne forme ? Est-ce un nombre ? Respecte-t-elle les règles ? Si oui, l'étiquette change pour « Validé ».
Engagé : Ce n'est qu'après avoir passé tous les contrôles que la boîte reçoit un tampon « Engagé ». Désormais, et seulement maintenant, le reste du système traite cela comme un fait établi.

L'analogie : C'est comme un chantier de construction. Un ouvrier peut dire : « Je pense que cette poutre est solide. » C'est juste de la discussion. Mais avant que le bâtiment ne soit construit, un ingénieur (le Harnais) doit inspecter la poutre, la tester et la tamponner « Approuvé ». Tant que ce tampon n'est pas présent, la poutre ne peut pas être utilisée pour soutenir le toit. XFlow garantit qu'aucune « poutre » n'est utilisée tant qu'elle n'est pas tamponnée.

3. Le « Protocole » (XPF)

Pour faire fonctionner cela, les auteurs ont créé un langage spécial appelé XPF.

Il ressemble à un document lisible (comme une histoire ou un manuel), afin que les humains puissent l'écrire facilement.
Mais c'est aussi un programme informatique. Lorsque vous l'exécutez, l'ordinateur le compile en règles strictes.

L'analogie : Pensez à une fiche de recette qui est aussi un manuel d'instructions pour robot.

Pour un humain, elle lit : « Mélanger la farine et les œufs. »
Pour le robot, elle lit : « SI le poids de la farine < 500g, ARRÊTER. SI les œufs sont cassés, REJETER. »
L'humain écrit la recette, mais le robot applique automatiquement les contrôles de sécurité.

4. Qu'ont-ils testé ?

Les auteurs ont testé XFlow dans trois domaines spécifiques pour voir si cela fonctionne réellement :

Règles Strictes (Interaction Contrainte) : Comme un bot de service client qui doit suivre des politiques de remboursement strictes. XFlow a permis de s'assurer que le bot suivait les règles 100 % du temps, alors que sans cela, le bot enfreignait parfois les règles même s'il donnait la bonne réponse.
Histoires Longues (Raisonnement à Long Contexte) : Comme lire un énorme rapport financier et répondre à des questions. XFlow a aidé l'IA à garder une trace de chiffres et de règles spécifiques sans se laisser confondre par la longueur du texte.
Codage (Génie Logiciel) : Comme une IA essayant de corriger un bug dans un programme informatique. XFlow a agi comme une barrière de sécurité, garantissant que l'IA ne soumette pas un « correctif » à moins d'avoir réellement exécuté les tests et confirmé que le code fonctionnait.

L'essentiel

XFlow ne cherche pas à rendre l'IA plus intelligente ou à l'empêcher de commettre des erreurs. Au lieu de cela, il construit un filet de sécurité autour de l'IA.

Il dit : « Vous (l'IA) pouvez penser et parler librement, mais vous ne pouvez pas modifier le registre officiel tant que vous n'avez pas passé nos contrôles. »

Cela rend les systèmes multi-agents (où de nombreuses IA travaillent ensemble) beaucoup plus fiables car cela empêche la « supposition » d'un agent de devenir accidentellement un « fait » pour un autre agent. Cela transforme la conversation désordonnée entre les IA en un flux de travail structuré et vérifiable.

Résumé Technique : XFlow – Un système de programmation de protocoles exécutables pour des flux de travail multi-agents fiables

1. Énoncé du problème

Les systèmes multi-agents basés sur les grands modèles de langage (LLM) ont évolué, passant d'un simple prompting d'agent unique à des flux de travail coordonnés impliquant la planification, le raisonnement, l'utilisation d'outils et l'interaction humaine. Cependant, leur fiabilité reste limitée. Le document identifie une source centrale de cette limitation : la frontière sous-spécifiée entre le prompt et le harnais (harness).

Dans les systèmes actuels, il n'existe aucun mécanisme de principe pour décider quels engagements de flux de travail (contraintes, interfaces d'état, politiques, obligations de processus) doivent rester dans les prompts en langage naturel (travail sémantique informel) et lesquels doivent être élevés au niveau de la structure du harnais (engagements formels et gouvernables). Par conséquent :

État Implicite : Les connaissances et contraintes gouvernables restent ancrées dans les prompts, forçant les acteurs à les interpréter et à les appliquer de manière répétée plutôt que de les laisser inspectées ou préservées par le système.
Propagation d'Erreurs : Dans les pipelines multi-agents, les erreurs telles que les faits hallucinés ou les sorties malformées peuvent devenir un état partagé, déclenchant des actions en aval et corrompant des décisions ultérieures.
Absence de Juste Milieu : Les cadres existants tendent vers deux extrêmes : les systèmes rigides basés sur le balisage/la configuration (vérifiables mais faibles sur l'état sémantique) et l'orchestration par prompt uniquement (flexible mais laissant l'état et les engagements implicites). Il manque un langage pour tracer, tester et ajuster la frontière entre ces deux approches.

2. Méthodologie : Le système XFlow

Les auteurs présentent XFlow, un système de programmation de protocoles exécutables, et le XPF (XFlow Protocol Format), son langage de programmation de protocoles dédié. XFlow occupe un juste milieu semi-formel où les protocoles sont lisibles comme une documentation « lettrée » (literate) mais compilés et exécutés comme des programmes.

2.1 Philosophie de Conception

XFlow repose sur trois principes fondamentaux :

Régime Intermédiaire : Il comble le fossé entre le balisage rigide et le contrôle par prompt uniquement, en fournissant une surface de protocole stable.
Frontières Explicites : Il rend explicite la frontière entre le formel et l'informel (prompt/harnais). Le travail sémantique informel reste avec les acteurs, tandis que les engagements gouvernables sont externalisés dans la structure du harnais.
Gouvernance de l'Incertitude : La fiabilité est obtenue non pas en éliminant l'incertitude, mais en la gouvernant. Les sorties des acteurs sont absorbées dans des symboles typés dotés d'états de cycle de vie avant d'influencer les décisions en aval.

2.2 Architecture

XFlow se compose de trois phases distinctes :

A. Phase de Spécification (XPF)

Les auteurs rédigent un document de protocole utilisant le XPF, qui abstrait le flux de travail en cinq composants ( $P = (\Sigma, \Delta, \Lambda, F, H)$ ) :

Espace des Symboles ( $\Sigma$ ) : Définit l'état partagé du flux de travail. Les symboles sont des cellules d'état typées avec des rôles (entrée, travail, sortie de juge), des politiques de source (qui peut proposer) et des politiques d'engagement (quand ils deviennent engagés).
Dérivations ( $\Delta$ ) : Encapsulent la logique déterministe (ex: calculer la disponibilité, la fraîcheur ou la couverture) pour sortir la gestion comptable des prompts des acteurs.
Interfaces d'Acteurs ( $\Lambda$ ) : Lie des acteurs (LLM ou humains) à des étapes, définissant des entrées lisibles et des sorties scriptibles. Les acteurs conservent leur flexibilité sémantique mais opèrent dans des limites d'I/O strictes.
Flux de Contrôle ( $F$ ) : Déclare les transitions d'étapes valides et les appels de protocole basés sur des prédicats sur les symboles, empêchant les étapes d'être déduites de texte libre.
Transfert de Responsabilité ( $H$ ) : Définit explicitement les passages de relais (ex: approbation, revue, escalade) basés sur des conditions, faisant des changements de propriété une partie de l'état auditable.

B. Phase de Compilation

Le compilateur transforme le document XPF lettré en une Représentation Intermédiaire (IR) typée et en objets d'exécution :

Analyse (Parsing) : Sépare la prose (contexte) des blocs sémantiques (logique exécutable).
Résolution et Vérification : Valide les noms de symboles, les cibles d'étapes et les liaisons d'acteurs. Il effectue des vérifications statiques pour s'assurer que les interfaces sont légales et que les politiques ne sont pas violées avant le début de l'exécution.
Réduction (Lowering) : Convertit les déclarations en objets typés (ex: IRSymbol, IRStage) que le runtime peut exécuter sans reparser le texte source.

C. Phase d'Exécution

Le runtime impose le contrat compilé :

Action Médiée par l'Interface : Les acteurs sont invoqués comme des unités de type fonction avec des entrées et sorties typées. Leur raisonnement interne reste informel, mais le franchissement de la frontière est gouverné.
Symboles Gouvernés par le Cycle de Vie : Les sorties des acteurs entrent en tant que valeurs PROPOSÉES. Elles deviennent VALIDÉES après des vérifications de schéma/contrat et ne sont ENGAGÉES qu'après satisfaction des politiques d'engagement (ex: approbation humaine).
État Réactif : Si un symbole engagé change, les symboles dérivés dépendants sont invalidés ou recalculés.
Récupération de Session : Le contexte d'exécution (cadres, sorties en attente, journaux d'événements) est préservé pour permettre la reprise ou l'audit sans reconstruire le contexte à partir des transcriptions.

3. Contributions Clés

Système XFlow : Un système de programmation de protocoles exécutables qui traite la frontière prompt–harnais comme un objet de conception de premier ordre, permettant aux auteurs de décider explicitement quels engagements restent avec les acteurs et lesquels deviennent des structures de flux de travail exécutoires.
Langage XPF : Un format de protocole semi-formel avec support de compilation et de runtime qui transforme les symboles, les interfaces d'acteurs, les règles de flux et les politiques de cycle de vie en structures vérifiables, préservables et exécutoires.
Évaluation Empirique : Une évaluation complète à travers trois classes de benchmarks distinctes démontrant que l'externalisation du protocole améliore la fiabilité tout en préservant la flexibilité des acteurs.

4. Résultats Expérimentaux

Les auteurs ont évalué XFlow en utilisant Qwen3.5-9B et DeepSeek-V4-Flash comme modèles de base à travers trois contextes :

Interaction Contrainte ( $\tau^3$ -bench) :
- Objectif : Tester la correction des agents sous des contraintes de domaine explicites (ex: règles d'éligibilité, exigences de divulgation).
- Résultat : XFlow a considérablement amélioré la Conformité (ex: de 96,5 % à 100,0 % dans le secteur Retail, de 77,2 % à 82,5 % dans le Télécom) tout en maintenant des taux de succès de tâche ( $pass_1$ ) comparables.
- Insight : Les agents de référence atteignaient souvent l'état final correct via des chemins invalides (violant les contraintes de processus). XFlow a imposé le bon chemin d'exécution (ex: exigeant une confirmation explicite avant toute mutation).
Raisonnement sur Long Contexte (CorpusQA) :
- Objectif : Évaluer la visibilité des preuves et l'engagement de réponse sur de longs documents.
- Résultat : La combinaison de XFlow avec XpandA (une ligne de base de récupération/agrégation) a amélioré la précision (ex: de 59,3 % à 61,7 % avec Qwen3.5-9B).
- Insight : XFlow a permis d'encoder des règles de traitement spécifiques au domaine (ex: conventions de signes dans les données financières) sous forme de dérivations déterministes, empêchant le modèle de mal interpréter les valeurs récupérées.
Ingénierie Logicielle Agentique (SWE-bench Verified) :
- Objectif : Tester la fiabilité lors d'interactions étendues avec des outils et l'édition de code.
- Résultat : XFlow a amélioré les taux de réussite (ex: de 77,4 % à 79,8 % pour mini-SWE-agent avec DeepSeek-V4-Flash).
- Insight : Les barrières de protocole ont empêché les agents de soumettre des correctifs après des échecs de validations locales, forçant des tentatives ciblées et garantissant le respect des normes de processus.

5. Signification et Revendications

Le papier affirme que XFlow fournit un mécanisme pour tracer et gouverner la frontière prompt–harnais. En externalisant les contraintes, les faits et les flux de travail réutilisables de la mémoire des acteurs vers des structures gouvernées par le protocole, XFlow rend les systèmes d'agents plus fiables sans sacrifier la flexibilité des acteurs LLM.

Mécanisme Opérationnel : Il déplace la fiabilité de l'amélioration pure du côté du modèle (ex: meilleur prompting) vers la gouvernance du côté du flux de travail (ex: transitions d'état explicites, barrières d'engagement et cadres de récupération).
Applicabilité Cloud–Edge : Le document démontre l'utilité de XFlow dans les systèmes cloud–edge, où il contraint les modèles edge à des actions étroites et vérifiables, et empêche les sorties locales incertaines de se propager silencieusement à l'état global.
Auditabilité : Puisque les engagements sont des structures de protocole explicites, ils sont inspectables, préservables et exécutoires à travers des flux de travail hétérogènes.

Les auteurs concluent que XFlow plaide pour le traitement de la frontière prompt–harnais comme une abstraction de premier ordre, permettant la construction de systèmes multi-agents plus faciles à inspecter, à récupérer en cas d'erreur et à rendre fiables. Ils reconnaissent des limites, telles que la courbe d'apprentissage pour l'auteur de protocoles et l'absence de garanties formelles sur la qualité sémantique des sorties des acteurs, suggérant des travaux futurs dans l'échafaudage assisté par l'IA et la validation basée sur les contrats.