Concevoir les rubriques comme des mini-agents qui évitent les messages dupliqués

Note

Cet article décrit les caractéristiques et le comportement des sujets ayant un déclencheur conversationnel dans le harnais standard. Apprenez comment accéder aux fonctionnalités standard dans Access Standard Agents et Flux d’agents.

Cet article porte sur les meilleures pratiques de conception pour éviter les messages en double. Les messages dupliqués proviennent de lacunes contextuelles, donc la conception commence par comprendre comment le contexte s’écoule. Référez-vous au diagramme dans Distribution de contexte dans le harnais standard pour comprendre comment la couche d’orchestration partage le contexte avec chaque composant.

Dans le harnais standard, le planificateur appelle les sujets de la même manière qu’il appelle les outils et les agents. Il lit la description de chaque sujet pour décider quand utiliser le sujet, génère les entrées du sujet à partir de son contexte actif et de l’utilisateur, et lit les sorties du sujet lorsque celui-ci est terminé. Un sujet avec une description claire, des entrées bien définies et des sorties bien définies se comporte comme un mini-agent dans le plan : la couche d’orchestration recueille ce dont le sujet a besoin, le sujet exécute sa logique, elle retourne ce qu’il a produit, et la couche d’orchestration forme et communique la réponse à l’utilisateur.

Pour l’utilisateur, un mini-agent semble conversationnel. L’utilisateur peut parler naturellement pendant que le sujet recueille les informations nécessaires, poser des questions de suivi et obtenir des réponses riches de l’agent.

Tip

Dans le harnais standard, gardez la logique déterministe à l’intérieur du sujet et laissez la communication utilisateur à la couche d’orchestration. Collectez les valeurs dont le sujet a besoin en entrées avant qu’il ne s’exécute, puis retournez ce qu’il a produit en sorties après son exécution.

Nommez et décrivez le sujet afin que la couche d’orchestration puisse y router

La couche d’orchestration utilise le nom et la description du sujet pour acheminer les requêtes vers le sujet. Écrivez les deux pour la couche d’orchestration. Donnez au sujet un nom clair et précis qui décrit ce qu’il fait.

Rédigez la description en deux parties. D’abord, expliquez quand utiliser le sujet. Deuxièmement, expliquez brièvement ce qu’il faut faire en fonction des sorties du sujet, y compris comment la couche d’orchestration doit router les requêtes et gérer les résultats après l’exécution du sujet. Ne décrivez pas les écrans internes ou les étapes du sujet.

Par exemple, utilisez la description suivante pour une rubrique qui répond aux demandes de solde de compte et renvoie une sortie answered :

This topic handles account balance requests. 
If its answered output is true, the user has already received their response and it should not be answered again.

Collectez les entrées avant que le sujet ne soit lancé

Donnez au sujet une entrée pour chaque valeur dont il a besoin. La couche d’orchestration peut collecter ces valeurs dans son contexte actif et auprès de l’utilisateur, de façon conversationnelle, avant que le sujet ne soit exécuté. Une entrée est transmise dans une variable que la logique du sujet utilise ensuite.

Utilisez le nom de l’entrée, la description, l’entité et les paramètres de validation pour aider la couche d’orchestration à remplir une entrée avec précision :

  • Le nom d’entrée indique à la couche d’orchestration ce qui est collecté, et sert à poser la question si la couche d’orchestration doit demander la valeur à l’utilisateur. Nommez-le pour la valeur, pas pour le mécanisme. Par exemple, nommer une entrée The user's request about... plutôt que OData filter, afin que la couche d’orchestration ne demande pas à un utilisateur d’écrire une requête.

  • La description d’entrée est une invite vers la couche d’orchestration, pas une étiquette pour l’utilisateur. Utilisez-le pour indiquer à la couche d’orchestration comment interpréter, contraindre ou transformer la valeur avant que le sujet ne la reçoive. La couche d’orchestration peut remplir une entrée provenant de la conversation, d’une sortie antérieure ou des données de profil utilisateur. Il peut choisir parmi un ensemble de valeurs, appliquer certaines contraintes et écrire des requêtes basées sur les informations du schéma.

    Les descriptions d’entrée peuvent même demander à la couche d’orchestration de construire une valeur dans un format spécifique. Par exemple, un sujet qui filtre une liste peut recevoir une entrée dont la description indique à la couche d’orchestration comment construire le filtre à partir de la demande de l’utilisateur, incluant les champs disponibles, la syntaxe de requête, et quelques exemples.

  • Les entités définissent le type et la plage autorisés pour une entrée, donc seules les valeurs valides atteignent la logique du sujet.

  • La validation avancée et la logique conditionnelle, y compris Power Fx, agissent comme des vérifications déterministes. Ils peuvent empêcher qu’une entrée soit remplie, ou empêcher le sujet d’agir lorsque la condition n’est pas remplie.

Les contrôles d’entrée déterministes sont aussi fiables que le code, donc les règles métier et les contraintes de conformité sont respectées même lorsque le reste du plan est généré.

Conservez la logique et les garde-fous dans le sujet

Gardez le travail déterministe du sujet à l’intérieur du sujet : les étapes qu’il exécute, les calculs qu’il effectue, et les règles qu’il applique. Le créateur exerce le contrôle et applique une logique métier cruciale qui fonctionne toujours de la même façon, comme un outil.

Retournez les résultats en sorties, et non en messages à l’utilisateur

Lorsque le topic est terminé, renvoyez ce qu’il a produit sous forme de sorties afin que la couche d’orchestration puisse les utiliser et décider comment répondre. Préfère cette approche à ce que le sujet envoie un message direct à l’utilisateur. Un topic qui envoie des messages à l’utilisateur tandis que la couche d’orchestration répond elle aussi est une source fréquente de messages en double : la couche d’orchestration ne sait pas que le topic a déjà envoyé une réponse.

Important

Un sujet qui ne renvoie aucune sortie est un signal d’alarme. Si un sujet a répondu à l’utilisateur, collecté une valeur ou montré une carte mais ne retourne rien, la couche d’orchestration ne peut pas voir ce qui s’est passé et peut répondre à la même demande. Ce comportement est la cause la plus fréquente des messages en double issus de rubriques.

Les résultats testés suivants sont fortement recommandés comme modèles fiables pour le contexte et la communication. Ils s’appliquent tant que le sujet répond directement à l’utilisateur ou que toutes les informations soient rendues à la couche d’orchestration pour y répondre.

Output Description Guide pratique pour utiliser
answered C’est vrai si l’utilisateur a déjà reçu une réponse satisfaisante à sa demande dans ce sujet. Définissez-la sur « true » dans la rubrique une fois qu’une réponse est fournie ou que le résultat s’affiche. Référez-vous à l’exemple d’instruction de premier niveau qui suit, qui garantit que la couche d’orchestration traite cette partie de la requête comme répondue et ne la répète pas.
choiceReceived C’est vrai si l’utilisateur a déjà fait son choix dans ce sujet. Définissez-le sur `true` dès que l’utilisateur effectue une sélection, par exemple en sélectionnant le bouton d’une carte. La couche d’orchestration ne pose pas la question à nouveau.
balanceValue La valeur que la rubrique a récupérée et a déjà fournie à l’utilisateur. Définissez-la aux données importantes récupérées par le sujet, et nommez la sortie de ces données. La couche d’orchestration la réutilise depuis le contexte au lieu de la récupérer à nouveau.
messageSummary Un bref résumé de ce qui a déjà été montré à l’utilisateur, pour garder en contexte. Régle-la quand un message contient des informations dont le plan aura besoin plus tard. La couche d’orchestration reste consciente de ce qu’on a dit à l’utilisateur et ne le répète ni ne le contredit pas.

Les sorties seules suffisent pour les anciens modèles. Les modèles plus récents nécessitent aussi une instruction de haut niveau qui indique à la couche d’orchestration de vérifier les sorties avant de répondre.

Cet exemple d’instruction de haut niveau est un exemple opérationnel testé. Modifiez-le et personnalisez-le selon les besoins.

Chaque fois qu’une rubrique ou un agent est invoqué, recherchez toujours le booléen de sortie « answered » avant de décider de la réponse à apporter. Les sujets et les agents ont leur propre canal de communication avec l’utilisateur. Si « répondu » est vrai, supposez toujours que la demande a été répondue correctement en utilisant au moins une des variables de sortie, et vérifiez lesquelles en fonction de la description de sortie. Ne donnez pas de reconnaissance gênante du contenu répondu. Ne fournir que les résultats non répondus, et poursuivre la conversation naturellement avec l’étape suivante.

Le terme canal ne fait pas référence à un canal d’intégration. C’est un dispositif d’invitation qui indique à la couche d’orchestration que l’utilisateur a peut-être déjà vu la réponse via un autre composant. Selon le modèle de l’agent, il peut être plus efficace de placer une instruction similaire dans les instructions de l’agent. En savoir plus dans Concevoir une instruction de premier niveau robuste pour éviter les messages répétés.

Si la rubrique doit afficher un élément que la couche d’orchestration ne peut pas reproduire, comme une Carte adaptative, laissez-la l’afficher et renvoyez une sortie avec l’état « répondu ».

Tip

En savoir plus sur les messages dupliqués et les sorties de l’état « répondu » dans Bonnes pratiques de conception pour éviter les messages dupliqués. Apprenez comment le contexte se déplace entre la couche d’orchestration et un sujet dans la distribution de contexte dans le harnais standard.

Rassembler les réponses lorsqu’un sujet nécessite encore une intervention utilisateur

Certaines rubriques doivent poser une question ou afficher une carte, par exemple pour recueillir une réponse à l’aide de boutons. Cette approche de conception est valable. Gardez à l’esprit qu’une question ou une carte ouverte doit être résolue lorsque l’utilisateur change de cap avant de répondre.

Avant d’ajouter un nœud question, considérez si la valeur peut être collectée en entrée. Lorsque vous gardez un nœud de question, gérez le cas où l’utilisateur demande autre chose alors que la question est encore ouverte. En savoir plus dans Une question ouverte ou les retours de cartes après qu’une autre demande ait été traitée.

Exemple : Empêcher qu’une sélection de carte adaptative ne soit redemandée

Un sujet demande à l’utilisateur de choisir une catégorie avec une carte adaptative :

Quelle catégorie est votre problème ?

[Facturation] [Technique] [Compte]

La couche d’orchestration reçoit le texte de la question via l’historique de la conversation, mais pas le fait que la carte ait été affichée ou qu’un bouton ait été sélectionné par l’utilisateur. Après avoir sélectionné un bouton, la couche d’orchestration peut reposer la même question en texte clair.

Concevez le sujet pour qu’il rapporte ses actions afin d’éviter ce problème :

Output Type Sur quel réglage le définir
answered Vrai/Faux C’est vrai lorsque le sujet a déjà montré la réponse ou le prompt à l’utilisateur.
choiceReceived Vrai/Faux C’est vrai lorsque l’utilisateur a déjà fait un choix de choix.
selectedCategory Texto Chaque fois qu’un choix est reçu, cette sortie contient la catégorie choisie par l’utilisateur.

Ajoutez une instruction à la description du sujet afin que la couche d’orchestration sache ce que signifie une exécution réussie. Comptez sur l’instruction de premier niveau dans les résultats de retour comme sorties, et non sur des messages à l’utilisateur , afin qu’un modèle plus récent vérifie ces sorties avant de redemander.

Bonnes pratiques pour les rubriques du harnais standard

  • Donnez au sujet un nom clair et précis ainsi qu’une description indiquant quand l’utiliser (et éventuellement quoi faire après sa publication).
  • Ajoutez une entrée pour chaque valeur dont le sujet a besoin, et écrivez la description de l’entrée comme une invite à la couche d’orchestration.
  • Nommez les entrées pour la valeur qu’elles détiennent, puisque le nom constitue la question au cas où la couche d’orchestration devrait poser la question à l’utilisateur.
  • Conservez la logique déterministe et les garde-fous, tels que les entités, la validation et Power Fx, au sein de la rubrique.
  • Évitez de contacter directement l’utilisateur dans le sujet. Utilisez un nœud message, un nœud question ou une carte adaptative uniquement lorsque cela est nécessaire.
  • Retourner les résultats en tant que sorties, y compris une sortie en état de réponse.
  • Last updated on