Un agent choisit la prochaine branche : Dify 1.18 facilite le transfert et l'examen des parcours

Une démonstration d'agent peut convaincre après une seule requête réussie. Les questions difficiles arrivent quand une deuxième équipe veut la réutiliser : quelle branche l'agent choisira-t-il, quels fichiers accompagneront l'application et où pourra-t-on voir ce qui s'est passé dans un parcours imbriqué ?

Dify 1.18.0, publié le 23 octobre 2026, rapproche ces questions. La version introduit les Output Routes des agents, les paquets d'application .ifpkg et une meilleure visibilité sur les parcours. Il s'agit moins de donner à l'agent une réponse plus impressionnante que de rendre son rôle assez compréhensible pour être réutilisé dans une application. Publication officielle.

Dify est une plateforme de construction d'applications IA associant parcours visuels, modèles, connaissances et outils. Les équipes peuvent relier le jugement d'un modèle aux étapes de l'application au lieu de copier sans cesse le même prompt dans un chat. L'intérêt de cette version est de réunir trois préoccupations pratiques : décider de la suite, transférer l'application et examiner son exécution.

Interface de parcours par LangGenius / les contributeurs de la documentation Dify, CC BY 4.0. Redimensionnée et convertie en WebP sans recadrage. Cet écran illustre le constructeur visuel, pas chacun des nouveaux contrôles de la version.

Une branche est une décision qui mène quelque part

Dans un parcours traditionnel, les conditions examinent souvent une valeur connue : un statut approuvé, un champ vide ou un score au-delà d'un seuil. Les demandes en langage naturel sont moins nettes. Un client peut mélanger question, plainte et demande d'exception dans un même message.

Les nouvelles Output Routes permettent à l'agent de choisir entre des routes configurées afin que le parcours continue dans la branche correspondante. L'interprétation devient un choix à l'intérieur d'un processus, dont l'étape suivante est représentée dans le parcours plutôt que laissée entièrement dans le texte généré.

Cela peut faciliter la conception et l'examen d'une application. Le concepteur choisit les destinations existantes. L'agent sélectionne l'une d'elles pour une demande. Le parcours exécute ensuite les étapes reliées. Une route peut être utile même si l'explication en langage naturel de l'agent n'est pas le produit final.

La limite compte. Choisir une route « escalade » ne prouve pas qu'un dossier exige juridiquement ou financièrement cette escalade. Choisir « rédiger une réponse » ne donne pas la permission de l'envoyer. Le parcours doit toujours définir les opérations autorisées après chaque choix et le responsable des exceptions.

Premier exemple : un message client, trois chemins possibles

Prenons une équipe de support qui reçoit à la fois des questions produit et des demandes d'exception. Elle veut distinguer trois grandes voies : répondre à partir de contenus d'aide approuvés, préparer un brouillon pour une personne ou escalader un cas inhabituel.

Des routes explicites rendent ces destinations visibles dans le parcours. Une question de configuration simple peut aller vers une réponse fondée sur les connaissances. Une incertitude propre à un compte peut entrer dans une voie de vérification. Une demande de dérogation commerciale peut rejoindre l'équipe habilitée à décider.

Ce sont des choix d'application illustratifs, pas une politique de support prête à l'emploi fournie par Dify. L'équipe doit définir le contenu de chaque route, fournir des exemples appropriés et décider du traitement des entrées ambiguës. Une explication convaincante ne doit pas effacer une limite d'autorité.

Le bénéfice n'est pas de rendre chaque message facile à classer. Il permet d'évaluer une décision précise. Si l'agent envoie un message difficile vers la réponse ordinaire, l'échec du test est clair. S'il transmet tout à une personne, le parcours peut être sûr mais n'automatise pas grand-chose d'utile.

Conservez un ensemble de messages difficiles avec leurs destinations attendues. Incluez demandes mixtes, informations absentes et variantes linguistiques ressemblant au trafic réel. Un parcours qui ne réussit que les exemples les plus propres reste une démonstration, même si son schéma semble terminé.

Une route configurée transforme un jugement linguistique en destination visible du parcours. Chaque destination demande encore ses propres actions permises et règles de vérification.

Être portable signifie davantage que copier un prompt

Une application IA peut dépendre d'instructions, de définitions d'agents, de Skills, de fichiers et de références à des ressources de l'espace de travail. Copier le prompt le plus visible laisse une grande partie de l'application derrière soi.

Dify 1.18 introduit un paquet .ifpkg pouvant inclure des Agents intégrés, des Skills et leurs fichiers. À l'importation, la version décrit la recréation de ces ressources et le réadressage des références. Les importations par fichier et URL prennent en charge YAML et le format de paquet ; l'exportation YAML explicite reste disponible. Changements des paquets et importations.

C'est un changement important pour la réutilisation. L'équipe peut davantage transférer ensemble les éléments qui expliquent le fonctionnement de l'agent, au lieu de laisser un collègue les reconstruire à partir d'une liste d'instructions manuelles.

Cela ne prouve pas le transfert automatique de chaque dépendance externe. Accès aux modèles, identifiants, disponibilité des extensions, permissions réseau et ressources de connaissances peuvent dépendre de la destination. Une application importée peut rester structurellement intacte et demander une configuration avant de fonctionner correctement.

Traitez le paquet comme un objet applicatif utile soumis à un examen. Un fichier peut transporter des instructions et du contenu qu'une autre équipe n'a pas écrit. Avant l'importation dans un espace disposant d'accès importants, comprenez son origine et les actions attendues de ses agents et outils.

Deuxième exemple : un parcours de proposition rejoint une autre équipe

Imaginons une entreprise de services ayant construit un parcours pour préparer un premier brouillon de proposition. Il recueille la demande, applique une Skill de rédaction, vérifie les sections requises et transmet les conditions commerciales incertaines à une personne.

Une deuxième équipe veut utiliser la même approche avec un autre catalogue. Transmettre uniquement le prompt serait incomplet : instructions réutilisables, modèles de documents joints et références d'agents font partie du comportement. Le format de paquet aide à transférer davantage de ces éléments reliés ensemble.

L'équipe destinataire a encore du travail. Elle doit remplacer ou confirmer les informations de services, configurer modèles et outils autorisés et vérifier qui peut approuver une proposition. Si le parcours importé renvoie à une ressource sans place dans le nouvel espace, la réussite de l'importation ne justifie pas de conserver cette référence sans examen.

Exécutez un petit ensemble de demandes identiques avant et après le transfert. Comparez choix des routes, sections requises, accès aux outils et comportement de vérification. Une application portable doit préserver le processus voulu tout en permettant des adaptations délibérées aux informations de la destination.

C'est là que l'empaquetage devient une fonction opérationnelle. Il peut réduire la reconstruction, mais le résultat utile est une transmission répétable qu'une autre équipe sait comprendre et tester. Le nombre de clics économisés à l'importation n'en est qu'une partie.

Voir l'intérieur d'un parcours change le débogage

La version met aussi l'accent sur une meilleure visibilité des parcours, y compris les exécutions imbriquées. Cela compte parce qu'une application peut échouer plusieurs étapes avant l'endroit où l'utilisateur remarque le problème.

Un mauvais brouillon final peut venir d'un mauvais aiguillage, d'une source absente, d'un résultat d'outil incomplet ou d'instructions dans un parcours imbriqué. Si l'équipe ne voit que la réponse finale, elle peut réécrire sans cesse un prompt qui n'est pas responsable de l'échec.

Une exécution plus visible permet de poser une question plus étroite : quelle entrée est arrivée à cette étape, quel résultat en est sorti et quelle étape l'a utilisé ensuite ? La réponse permet une correction plus précise que la modification simultanée de plusieurs parties de l'application.

La visibilité n'est pas une explication complète du raisonnement interne du modèle. Les informations d'exécution peuvent montrer les événements et flux de données sans établir pourquoi chaque token ou route a été choisi. Elles ne décident pas non plus automatiquement du contenu de trace approprié à chaque lecteur.

Utilisez la visibilité disponible pour comprendre le comportement observable du parcours. Décidez séparément combien de temps conserver les traces, quelles données sensibles elles peuvent contenir et qui y accède. Une application traitant des demandes confidentielles ne doit pas transformer le confort de débogage en accès sans limite à leur contenu.

Disponibilité de la version et mise à niveau sont deux questions distinctes

La publication officielle GitHub est une sortie logicielle datée. Elle ne prouve pas, à elle seule, que chaque espace Dify hébergé active les mêmes fonctions au même instant. Les utilisateurs d'un service géré doivent vérifier leur espace réel et la documentation avant de planifier autour d'un contrôle précis.

Les installations auto-hébergées ont une autre responsabilité. Les notes de Dify 1.18 décrivent des changements coordonnés entre API, workers, Agent Backend et images d'exécution, dont un protocole d'exécution d'agent modifié. Mettre à jour un seul composant visible n'est pas une manière fiable d'adopter une version qui change la communication entre plusieurs composants.

Les notes mentionnent également des détails de configuration et de migration pour les environnements isolés locaux des agents et leurs outils. Ces détails doivent entrer dans un plan adapté à l'installation réelle. Ils ne doivent pas se réduire à une commande universelle copiée dans une présentation produit.

Avant une mise à niveau, préservez la configuration et les objets applicatifs actuels, identifiez les versions compatibles des composants et testez la migration dans un environnement approprié. Ne remplacez pas des paramètres persistants d'authentification ou de chiffrement simplement parce qu'une configuration d'exemple contient une valeur qui semble nouvelle. Suivez les consignes exactes de migration de la version.

Si le but immédiat est d'évaluer routes ou paquets, commencer par une application de test séparée peut être raisonnable. Cela permet d'apprendre le nouveau comportement sans faire de la première expérience une migration du parcours le plus important.

Une évaluation utile tient sur une page

Il n'est pas nécessaire d'avoir des dizaines d'agents pour savoir si ces fonctions aident. Une application comportant une vraie décision et un second environnement pour tester l'importation suffisent à révéler plusieurs propriétés importantes.

1. Choisissez une tâche délimitée. Retenez un processus aux entrées et résultats reconnaissables, comme préparer une réponse de support à vérifier. Nommez le responsable des exceptions.
2. Définissez quelques routes. Donnez à chacune un sens opérationnel et précisez les actions suivantes. Prévoyez un chemin pour les demandes qui ne s'intègrent pas sans risque.
3. Rassemblez des cas représentatifs. Utilisez des demandes ordinaires, des intentions mixtes et des informations manquantes. Écrivez la route attendue avant l'exécution.
4. Examinez l'exécution, pas seulement la réponse finale. Suivez les étapes imbriquées pertinentes et trouvez où apparaît d'abord une valeur ou un choix inattendu.
5. Exportez et importez l'application. Examinez les ressources incluses et vérifiez références, outils, modèles et secrets à destination. Ne supposez pas qu'un accès absent doit être automatiquement accordé.
6. Répétez les mêmes cas après le transfert. Comparez routes et résultats, puis notez les différences intentionnelles de configuration chez l'équipe destinataire.

Les mesures utiles sont concrètes : fréquence d'arrivée à la bonne destination, quantité de configuration nécessaire à la transmission et capacité d'un réviseur à localiser l'échec sans reconstruire toute l'exécution. Aucune n'exige de considérer le texte généré comme la preuve de sa propre exactitude.

Un paquet peut transférer la structure de l'application. La destination demande encore ses propres contrôles d'accès et la répétition des cas définissant la réussite.

Ce qui devient prometteur, et ce qui demande de l'attention

La direction encourageante est une unité applicative plus réutilisable. Un parcours peut contenir des destinations explicites, transporter davantage de ressources d'agents et exposer plus de son exécution en cas de problème. Cette combinaison aide les équipes qui ont dépassé le prompt isolé sans vouloir transformer chaque application en projet d'intégration sur mesure.

L'inquiétude correspondante est que la portabilité diffuse les erreurs aussi efficacement que les bonnes pratiques. Une définition de route floue ou un outil trop puissant ne devient pas approprié parce qu'il arrive dans un paquet soigné. Examinez le comportement importé, pas seulement la bonne ouverture du fichier.

Le prochain test significatif pour Dify est la capacité à entretenir ces applications malgré les changements : autre modèle, nouvelle Skill, politique métier révisée ou autre espace de travail. Une première importation réussie encourage. Une mise à jour contrôlée qui préserve le comportement voulu est un signe plus fort de maturité.

Dify 1.18 rend cette expérience plus intéressante en reliant les décisions d'agents à une structure visible. Commencez par un petit processus, gardez des routes compréhensibles et rendez la transmission répétable. C'est ainsi qu'une démonstration prometteuse commence à devenir un outil qu'une autre équipe peut utiliser de façon responsable.

Sources

• Notes de version Dify 1.18.0, publiées le 23 octobre 2026 à 06:33 UTC.
• Documentation officielle Dify, contexte produit ; la disponibilité doit être vérifiée dans l'espace réel.

Vous cherchez un espace interrogeable pour les notes de parcours, les exemples de demandes et les décisions derrière une révision ? Rassemblez vos références dans Telli.sh pour garder une transmission compréhensible.