Sous-agents de conception qui évitent les messages en double

Note

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

Les messages en double proviennent de trous contextuels. La conception de l’agent doit tenir compte du contexte à chaque étape.

Un sous-agent, qu’il s’agisse d’un agent enfant ou d’un agent connecté, s’exécute sur sa propre couche d’orchestration au sein du plan d’un agent parent. Il reçoit une demande du parent et accomplit la tâche. Le sous-agent produit trois types de sorties : le contenu qu’il montre à l’utilisateur, les valeurs qu’il retourne via des sorties définies, et une réponse implicite qu’il envoie à l’agent appelant. Le parent ne peut pas voir l’échange du sous-agent avec l’utilisateur et n’apprend le résultat qu’à travers les sorties définies et la réponse implicite. Cette visibilité limitée entraîne fréquemment des messages en double et des réponses manquées.

Tip

Pour savoir quand répartir le travail entre plusieurs agents et connaître les bonnes pratiques générales en contexte multi-agent, consultez Schémas d’orchestration multi-agent et bonnes pratiques et Schémas multi-agent. Cet article explique comment les entrées et sorties alignent la réponse d’un sous-agent avec le contexte de l’agent parent.

Cet article s’appuie sur le modèle de contexte décrit dans la distribution contextuelle dans le harnais standard et sur les décisions de conception dans les meilleures pratiques de conception pour éviter les messages en double.

Désactiver le contexte parent pour un agent connecté

Un sous-agent qui reçoit le contexte de la conversation du parent peut agir en conséquence. Si ce contexte contient une requête à laquelle le parent n’a pas encore répondu, le sous-agent peut y répondre, répéter quelque chose que le parent a déjà traité, ou prendre le mauvais rôle. Ces actions génèrent fréquemment des messages en double.

Un agent connecté a un paramètre : Transmets l’historique des conversations à cet agent, qui contrôle s’il reçoit le contexte de conversation du parent. Ce paramètre est activé par défaut. Désélectionne-le pour que l’agent connecté ne fonctionne qu’à partir des entrées envoyées par le parent, pas de la conversation complète.

Capture d’écran de l’option « Passer l’historique des conversations à cet agent » activée, notant que la désélection empêche le partage d’historique entre agents.

Un agent enfant n’a pas de réglage équivalent. Il s’exécute au sein du parent et reçoit toujours le contexte de la conversation du parent.

Pour les agents connectés qui doivent conserver le contexte de la tâche qui leur est attribuée, et pour les agents enfants qui disposent par défaut d’un contexte, utilisez un paramètre de cadrage pour protéger la portée du sous-agent.

Utiliser une entrée de délimitation

Parfois, un sous-agent a besoin du contexte de l’agent parent pour accomplir ses tâches. Lorsque vous transmettez ce contexte, incluez un paramètre de cadrage : il indique au sous-agent exactement sur quoi travailler, afin que les requêtes en suspens restées sans réponse dans le contexte ne le détournent pas de sa tâche. Si vous ne transmettez pas le contexte, vous n’avez pas besoin d’une entrée de portée, car le sous-agent ne dispose que de la requête que le parent lui a transmise.

Pour protéger la portée du sous-agent, ajoutez une entrée appelée scopedRequest avec une description telle que : The specific request this agent should fulfill. La couche d’orchestration remplit l’entrée lorsqu’elle appelle le sous-agent. L’agent parent identifie la partie pertinente de la requête et ne transmet que cette partie, même si son contexte contient une autre requête sans réponse.

Une entrée de cadrage constitue une conception robuste, même si vous ne préservez pas le contexte parent. L’entrée donne au créateur davantage de contrôle sur le contenu de la requête envoyée au sous-agent.

Associez les instructions du sous-agent à cette entrée afin qu’il s’appuie sur la requête délimitée et ignore tout ce qui ressemble à une requête initiale.

Exemples d’instructions pour les sous-agents :

Fulfill the request in the scopedRequest input. 
Treat it as your initial request and ignore any other initial requests in the conversation.

Configurer les entrées et sorties

Les entrées et sorties sont le contrat entre le parent et le sous-agent. L’entrée définit ce sur quoi travaille le sous-agent, et les sorties indiquent au parent ce qui s’est passé afin qu’il puisse orchestrer le reste de la conversation. Le parent ne peut pas voir l’échange du sous-agent avec l’utilisateur, donc ce contrat est le seul signal fiable qu’il a.

Important

Un sous-agent qui ne retourne aucune sortie est un signal d’alarme. Sans résultats, le parent n’a aucune trace de la réponse du sous-agent ni de ce qu’il reste à faire. Il peut répéter une réponse déjà donnée par le sous-agent, ou supprimer la partie de la requête que le sous-agent n’a pas traitée.

Configurez les entrées et sorties suivantes, et écrivez la description de chacune pour que la couche d’orchestration parent puisse lire :

Entrée ou sortie Description Guide pratique pour utiliser
scopedRequest (entrée) La demande spécifique que cet agent doit satisfaire. Le parent ne remplit que la partie pertinente de la requête de l’utilisateur. Elle protège le sous-agent de répondre à la mauvaise question lorsque le contexte du parent contient encore d’autres demandes sans réponse. Ancrer les instructions du sous-agent à cette entrée.
answered (sortie) C’est vrai lorsque l’utilisateur a déjà reçu une réponse à la requête scoped. Mettez-le sur chaque sous-agent, qu’il envoie un message à l’utilisateur ou reste silencieux. L’instruction de premier niveau, montrée ci-dessous, la lit pour que le parent ne réponde pas à la même demande.
scopedRequest (sortie) La demande sur laquelle cet agent a travaillé. Répétez la requête à portée limitée afin qu’elle atteigne la couche d’orchestration de niveau supérieur, qui ne conserve pas de façon fiable les données d’entrée qu’elle crée dans son propre contexte. Dans les virages multi-intentions nécessitant plus d’un sous-agent, cette capacité permet au haut niveau de planifier correctement et d’éviter de diriger le mauvais sous-agent vers la mauvaise question.
interactionSummary (sortie) Un bref résumé de la réponse donnée à l’utilisateur. Retournez-le lorsque le sous-agent envoie un message direct à l’utilisateur, pour que le parent sache ce qui a été communiqué et ne le répète pas.
findings (sortie) La réponse à la scopedRequest, que le parent doit transmettre à l’utilisateur. Renvoyez-le lorsque le sous-agent reste silencieux, afin que l’agent parent dispose du contenu à transmettre.
openQuestions (sortie) Toute partie de la demande de l’utilisateur qui reste sans réponse. Renvoyez-le par tout sous-agent qui ne peut traiter qu’une partie de la requête, ou si une nouvelle requête est apparue dans la conversation du sous-agent, afin que l’agent parent puisse prendre en charge le reste et poursuivre l’enchaînement d’outils. Le sous-agent ne devrait pas deviner lequel gère le reste.

Choisissez quel composant communique avec l’utilisateur

Décidez si l’agent parent ou le sous-agent communique avec l’utilisateur. Dans la plupart des cas, laissez l’agent parent communiquer avec l’utilisateur afin de pouvoir combiner les résultats en une seule réponse. Laissez le sous-agent communiquer directement lorsqu’il doit fournir une réponse longue ou mener une conversation en plusieurs échanges. Donnez assez d’informations pour que le parent puisse gérer le reste de la conversation avec du contexte.

Quel que soit le composant qui communique, ajoutez une instruction de niveau supérieur afin que la couche d’orchestration vérifie les sorties de chaque sous-agent avant de répondre.

Cet exemple d’instruction de premier niveau fonctionne dans tous les cas, qu’un sous-agent envoie un message direct à l’utilisateur ou reste silencieux. 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.

Écrivez la description du sous-agent pour la couche d’orchestration parente, afin qu’il sache quand utiliser le sous-agent et comment lire ses sorties. Par exemple:

Handles payroll questions. 
If its answered output is true, the user has already received their response and it should not be answered again.

Définissez, pour chaque sous-agent, les sorties « état de réponse » et « valeur », qu’il envoie un message à l’utilisateur ou qu’il reste silencieux, et fournissez au parent une instruction lui permettant de les lire. Avec cette approche, un agent peut mélanger des sous-agents silencieux et des sous-agents qui envoient un message direct à l’utilisateur, distingués uniquement par leurs sorties. En savoir plus dans Concevoir une instruction de premier niveau robuste pour éviter les messages répétés.

Déléguer la communication utilisateur au parent

Envisagez de router toute la communication utilisateur via l’agent parent plutôt que par un sous-agent. Collectez ce dont le sous-agent a besoin en entrées avant de commencer, lisez ce qu’il a produit en sorties une fois terminé, et indiquez-lui de ne pas envoyer de message direct à l’utilisateur. Un sous-agent qui n’écrit jamais à l’utilisateur ne peut pas répondre à quelque chose que le parent a déjà répondu.

Dites au sous-agent de garder le silence et de retourner ses conclusions. Par exemple:

Do NOT reply or communicate with the user directly. 
Only fulfill the scopedRequest provided in the input and respond with the result.

Un sous-agent silencieux retourne findings et openQuestions, tous deux décrits dans Configure inputs et outputs, pour remettre sa réponse au parent et signaler tout travail restant.

Renvoyez un résultat openQuestions. Cela permet à la couche d’orchestration de terminer le reste de la requête de l’utilisateur et de continuer à enchaîner des outils lorsqu’un sous-agent ne peut satisfaire qu’une partie de ce qui a été demandé.

Garder le sous-agent silencieux nécessite une instruction explicite. Par défaut, un sous-agent peut envoyer un message à l’utilisateur de lui-même pendant son exécution. Le paramètre Après exécution ne bloque pas ces messages car il ne dit au parent que ce qu’il doit faire lorsque le sous-agent est terminé.

Note

Dire à l’agent parent « Vous êtes le seul agent qui parle à l’utilisateur » ne fonctionne pas. L’agent parent ne peut pas arrêter un sous-agent en cours, et le sous-agent peut toujours envoyer un message à l’utilisateur de lui-même. À la place, ordonnez au sous-agent de garder le silence, puis testez pour confirmer.

Certains sous-agents doivent communiquer directement

Un sous-agent qui s’adresse directement à l’utilisateur constitue un choix valable, et non une violation d’une règle, mais cela nécessite une conception réfléchie afin d’éviter les messages répétés de l’agent parent.

Certains cas d’usage exigent que le sous-agent réponde directement à l’utilisateur, soit pour fournir une réponse longue sans la copier dans le contexte parent, soit pour tenir une conversation. Pour éviter la répétition des messages et la perte de contexte, il faut passer le contexte au parent dans les sorties.

Faites en sorte que le sous-agent donne une réponse longue et retournez un résumé

Le sous-agent fournit sa réponse complète directement à l’utilisateur et ne retourne qu’un bref résumé ou une note indiquant qu’il a donné la réponse. Utilisez cette approche pour des réponses longues, comme des analyses détaillées, et limitez les informations renvoyées au contexte du parent. L’objectif est de garder le contexte parent restreint mais informé.

Return answered et interactionSummary, tous deux décrits dans Configurer les entrées et sorties.

Faites en sorte que le sous-agent engage une conversation avec l’utilisateur

Le sous-agent échange plusieurs messages avec l’utilisateur en plusieurs étapes afin de traiter la requête définie. Le principal risque est que le parent ignore les étapes intermédiaires de la conversation, le travail du sous-agent et les réponses données, ni les nouvelles demandes qui apparaissent. En conséquence, le parent ne peut pas répondre correctement aux nouvelles demandes ou répondre correctement dans les étapes suivantes.

Retourner answered, scopedRequest, et interactionSummary, comme décrit dans Configurer les entrées et sorties.

L’instruction de premier niveau couvre également ce cas d’usage.

  • Last updated on