Distribution du contexte dans le harnais standard

Le harnais standard distribue le contexte entre les composants qui gèrent une requête. Chaque composant fonctionne à partir de son propre contexte, et le harnais ne réconcilie pas automatiquement le contexte au niveau supérieur. Cette séparation offre de la flexibilité, mais elle peut entraîner des messages en double ou des réponses manquées si les informations ne sont pas explicitement retournées par des composants indépendants.

Cet article explique pourquoi le contexte est distribué, comment le harnais GitHub Copilot diffère, comment le contexte se déplace entre la couche d’orchestration de l’agent et un composant, et ce que chaque composant peut voir et retourner. Utilisez ces informations pour identifier les écarts de contexte et concevoir des agents qui gèrent le contexte de manière délibérée.

Le diagramme suivant illustre comment le contexte et la communication circulent entre la couche d’orchestration, les composants individuels et l’utilisateur dans le harnais standard.

Diagramme montrant le contexte et les communications transmises entre la couche d’orchestration, chaque composant et l’utilisateur dans un agent de harnais standard.

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.

Un harnais alimente tout ce qui est intégré dans Copilot Studio, et le modèle sélectionné fournit le raisonnement et la génération. Le harnais est un temps d’exécution qui existe entre les deux : il détermine quand appeler le modèle, quels composants l’envoyer, interprète ce qui revient et appelle les bons outils. En savoir plus sur les harnais Copilot Studio.

Pourquoi le harnais standard distribue le contexte

Le harnais standard est conçu pour la flexibilité :

  • Il orchestre les tâches et prend en charge les cas d’usage transactionnels.
  • Il équilibre contrôle déterministe et IA grâce à des variables, des déclencheurs et des fonctionnalités spécialisées.
  • Il répartit le contrôle entre des composants tels que les sujets, les connaissances, les agents enfants, les agents connectés et les outils.
  • Il prend en charge plusieurs options d’authentification, de canal et d’intégration.

Répartir le travail entre des composants indépendants offre de la flexibilité mais peut créer des lacunes dans le contexte :

  • La couche d’orchestration des agents cède le contrôle lors de certains appels à des composants.
  • Pendant qu’un composant s’exécute, la couche d’orchestration ne peut pas voir les messages que le composant envoie à l’utilisateur.
  • La couche d’orchestration ne réconcilie pas le contexte au niveau supérieur.

Si la conception ne gère pas le contexte de l’agent, des lacunes apparaissent, et les requêtes peuvent sembler sans réponse. Ces lacunes peuvent entraîner des réponses en double ou oubliées.

En quoi le harnais GitHub Copilot diffère

La couche d’orchestration du harnais GitHub Copilot évite ce décalage de contexte en étant le seul communicateur avec l’utilisateur. Il ne laisse jamais un agent connecté prendre le contrôle de la communication :

  • La boucle de raisonnement et de communication fonctionne sans gestion délibérée du contexte.
  • Les messages des agents connectés passent à chaque étape par la couche IA du parent.

La couche d’orchestration de l’environnement GitHub Copilot gère également différemment la taille du contexte, ce qui fait que son contexte est de plusieurs ordres de grandeur plus grand que celui du cadre d’exécution standard :

  • Il a un accès direct au contexte du modèle.
  • Il peut bénéficier de la compactation.
  • Il peut écrire des données et des fichiers dans son conteneur bac à sable Bash.

Comment le contexte passe aux composants et revient à la couche d’orchestration

Pour gérer efficacement le contexte dans le harnais standard, considérez à la fois ce que la couche d’orchestration transmet à un composant et ce que ce composant retourne.

Le contexte passe aux composants de deux manières :

  • Entrées explicites et requêtes : La couche d’orchestration remplit les entrées de chaque composant à partir de son contexte actif et transmet une requête telle que prévue.

  • Contexte de conversation implicite : La couche d’orchestration transmet également un contexte de conversation plus long à des composants tels que la connaissance et aux sous-agents sans configuration explicite. Notez qu’un agent enfant reçoit toujours le contexte de la conversation parente. Un agent connecté a un paramètre qui l’inclut ou l’exclut. Un outil ou un flux ne reçoit que ses entrées.

Un composant renvoie l’information à la couche d’orchestration de deux manières :

  • Résultats explicites et réponses telles que conçues.
  • Contexte implicite provenant de certains composants.

Ce qu’un composant ne montre qu’à l’utilisateur, ou ne conserve que ses propres variables, n’atteint peut-être jamais la couche d’orchestration à moins de revenir par l’un de ces deux canaux.

Le transfert implicite d’informations provoque environ la moitié des cas avec des réponses dupliquées ou manquées car un composant peut agir sur une requête qui ne lui a jamais été explicitement transmise.

Comment le contexte diffère entre les composants

La conversation visible pour l’utilisateur et le contexte de la couche d’orchestration se recoupent, mais ce ne sont pas les mêmes. Les principes suivants s’appliquent à ce qui parvient au contexte de la couche d’orchestration à partir d’un appel de composant :

  • Ce qu’un composant garde pour lui-même reste caché. Les variables de sujet et les conversations à plusieurs tours au sein des sous-agents se trouvent dans le composant. La couche d’orchestration ne les voit que s’ils sont renvoyés comme résultats de sortie.

  • Seulement deux types de retour d’information. La couche d’orchestration reçoit les sorties explicites qui sont conçues et un contexte implicite provenant d’un composant. Un composant qui fonctionne mais ne retourne rien peut laisser la couche d’orchestration inconsciente de ce qui s’est passé.

Chaque composant a son propre contexte ou point de vue. La couche d’orchestration utilise son contexte actif pour sélectionner les étapes et générer des entrées. Un agent connecté possède sa propre couche d’orchestration, ses propres instructions, ainsi que ses propres outils et appels de connaissances internes.

Utilisez le tableau suivant pour poser une question précise : Quel composant possède un fait donné dans son contexte actif ?

Point de vue A dans son contexte actif Peut écrire dans le panneau de discussion Peut revenir en contexte
Couche d’orchestration Demande de l’utilisateur, contexte de conversation, descriptions de composants, descriptions d’entrée, descriptions de sortie, état du plan, réponses implicites (mais pas si l’information implicite a été montrée à l’utilisateur) Oui. Ses propres questions et réponses. Ses propres questions, réponses, raisonnement et plan.
Sujet Variables thématiques, état actuel du nœud Oui. À travers les nœuds de message, les nœuds de question et l’option Poser une question avec une carte adaptative. Les sorties de sujets et les échanges de messages implicites peuvent tout de même provoquer des duplications.
Outil ou flux Entrées générées par la couche d’orchestration Non. Sorties de l’outil ou du flux.
Étape de connaissance Demande utilisateur plus le contexte actif de l’agent Non. Il écrit à son propre agent, pas au panneau de discussion. Sa réponse.
Nœud de réponses génératives (à l’intérieur d’un sujet) Ce qui est envoyé en entrée ainsi que celui de son agent Oui. Directement, ou à une variable thématique. Pas explicitement, cela peut être répété.
Sous-agent (enfant ou agent connecté) Sa demande initiale, plus les entrées fournies par les parents et tout contexte parent inclus, dans son propre contexte de couche d’orchestration Oui, si elle est configurée ou instruite pour répondre directement. Une réponse et ses résultats.

Important

Sujets : Le contexte implicite retourné par les sujets n’inclut que les informations en texte brut, mais pas si l’utilisateur les a vues. Les informations en texte clair peuvent provenir des nœuds de messages, des nœuds de questions, du contenu de la carte adaptative et des réponses saisies de l’utilisateur. Cependant, les boutons d’action de la carte adaptative et les interactions de l’utilisateur avec eux n’atteignent pas le contexte standard du harnais. La gestion adaptative des cartes cause la plupart des incompatibilités contextuelles. Ne vous fiez pas au contenu des cartes comme contexte. À la place, retournez toute information dont une étape ultérieure a besoin comme sortie de sujet et définissez une sortie à état de réponse. En savoir plus sur les rubriques de conception sous forme de mini-agents qui évitent les messages en double.

Sous-agents : Lorsque le contexte parent est transmis à un agent connecté, il peut influencer chaque outil, sujet et appel de connaissances que l’agent fait. Si le contexte inclus contient toujours une requête qui semble ne pas avoir été répondue, l’agent connecté peut essayer de compenser et d’y répondre à nouveau. Un agent enfant présente le même risque avec moins de contrôle. Il s’exécute à l’intérieur du parent et reçoit toujours le contexte de conversation du parent, sans aucun réglage pour l’exclure. En savoir plus sur les sous-agents de conception qui évitent les messages en doublon.

Étape suivante

Avec ce modèle de contexte en tête, l’article suivant de cette série explique pourquoi ce modèle provoque des messages dupliqués et suggère des motifs de conception pour les prévenir.

Meilleures pratiques de conception pour éviter les messages en double

  • Last updated on