Distribuzione contestuale nell'imbracatura standard

Il harness standard distribuisce il contesto tra i componenti che gestiscono una richiesta. Ogni componente funziona dal proprio contesto, e l'harness non riconcilia automaticamente il contesto al livello superiore. Questa separazione offre flessibilità, ma può causare messaggi duplicati o risposte mancate se le informazioni non vengono restituite esplicitamente da componenti indipendenti.

Questo articolo spiega perché il contesto è distribuito, come differisce il GitHub Copilot harness, come il contesto si sposta tra il livello di orchestrazione degli agenti e un componente, e cosa ogni componente può vedere e restituire. Usa queste informazioni per identificare lacune contestuali e progettare agenti che gestiscono il contesto in modo deliberato.

Il diagramma seguente illustra come il contesto e la comunicazione fluiscano tra il livello di orchestrazione, i singoli componenti e l'utente nell'imbracatura standard.

Diagramma che mostra il contesto e le comunicazioni trasmesse tra il livello di orchestrazione, ogni componente e l'utente in un agente di harness standard.

Note

Questo articolo descrive le caratteristiche e il comportamento dell'imbracatura standard. Impara come accedere alle funzionalità standard negli agenti standard Access e nei flussi degli agenti.

Un imbracatore alimenta tutto ciò che è costruito in Copilot Studio, e il modello selezionato fornisce ragionamento e generazione. Il harness è un runtime che esiste tra i due: determina quando chiamare il modello, quali componenti inviarlo, interpreta ciò che torna e chiama gli strumenti giusti. Scopri di più sulle imbracature Copilot Studio.

Perché l'harness standard distribuisce il contesto

L'imbracatura standard è progettata per la flessibilità:

  • Orchestra i compiti e supporta casi d'uso transazionali.
  • Bilancia il controllo deterministico e l'intelligenza artificiale tramite variabili, trigger e funzionalità specializzate.
  • Distribuisce il controllo tra componenti come argomenti, la base di conoscenza, agenti figli, agenti connessi e strumenti.
  • Supporta molteplici opzioni di autenticazione, canale e integrazione.

Distribuire il lavoro tra componenti indipendenti offre flessibilità ma può creare lacune nel contesto:

  • Il livello di orchestrazione dell'agente cede il controllo in determinate chiamate ai componenti.
  • Mentre un componente è in esecuzione, il livello di orchestrazione non può vedere i messaggi che il componente invia all'utente.
  • Il livello di orchestrazione non riconcilia il contesto a livello superiore.

Se il design non gestisce il contesto dell'agente, si formano lacune e le richieste possono apparire senza risposta. Queste lacune possono causare risposte duplicate o mancanti.

In che modo differisce il GitHub Copilot harness

Il livello di orchestrazione del GitHub Copilot harness evita il disallineamento di contesto essendo l'unico comunicatore con l'utente. Non permette mai a un agente connesso di prendere il controllo della comunicazione:

  • Il ragionamento e il ciclo di comunicazione funzionano senza una gestione deliberata del contesto.
  • I messaggi dell'agente connesso passano attraverso il livello AI del genitore a ogni momento.

Il livello di orchestrazione dell'harness di GitHub Copilot gestisce anche la dimensione del contesto in modo diverso, il che rende il suo contesto di diversi ordini di grandezza superiore rispetto all'harness standard:

  • Ha accesso diretto al contesto del modello.
  • Può utilizzare la compattazione.
  • Può scrivere dati e file nel suo contenitore sandbox Bash.

Come il contesto passa ai componenti e ritorna al livello di orchestrazione

Per gestire efficacemente il contesto nell'imbracatura standard, considera sia ciò che il livello di orchestrazione passa a un componente sia ciò che il componente restituisce.

Il contesto passa ai componenti in due modi:

  • Input espliciti e richieste: Il livello di orchestrazione riempie gli input di ogni componente dal suo contesto attivo e trasmette una richiesta come progettato.

  • Contesto implicito della conversazione: Il livello di orchestrazione passa anche un contesto di conversazione più lungo a componenti come la conoscenza e ai sottoagenti senza una configurazione esplicita. Si noti che un agente figlio riceve sempre il contesto della conversazione genitoriale. Un agente connesso ha un'impostazione che lo include o lo esclude. Uno strumento o un flusso riceve solo i suoi input.

Un componente invia informazioni al livello di orchestrazione in due modi:

  • Output e risposta espliciti come previsto.
  • Contesto implicito da certi componenti.

Ciò che un componente mostra solo all'utente, o mantiene solo nelle sue variabili, potrebbe non raggiungere mai il livello di orchestrazione a meno che non torni attraverso uno di questi due canali.

Il passaggio implicito di informazioni causa circa la metà dei casi con risposte duplicate o mancate perché un componente può agire su una richiesta che non gli è mai stata esplicitamente passata.

Come il contesto differisce tra i componenti

La conversazione visibile dall'utente e il contesto del livello di orchestrazione si sovrappongono, ma non sono la stessa cosa. I seguenti principi si applicano a ciò che raggiunge il contesto del livello di orchestrazione da una chiamata a componente:

  • Ciò che un componente tiene per sé rimane nascosto. Variabili tematiche e conversazioni multi-turn all'interno dei sottoagenti esistono all'interno del componente. Il livello di orchestrazione li vede solo se vengono restituiti come output.

  • Solo due tipi di informazioni restituite. Il livello di orchestrazione riceve gli output espliciti che sono progettati e il contesto implicito da un componente. Un componente che funziona ma non restituisce nulla può lasciare il livello di orchestrazione ignaro di ciò che è successo.

Ogni componente ha il proprio contesto, o punto di vista. Il livello di orchestrazione utilizza il suo contesto attivo per selezionare i passaggi e generare input. Un agente connesso ha il proprio livello di orchestrazione, le proprie istruzioni e i propri strumenti e chiamate di conoscenza interne.

Usa la seguente tabella per porre una domanda precisa: quale componente ha un dato fatto nel suo contesto attivo?

Punto di vista È presente nel contesto attivo Può scrivere nel pannello della chat Può essere restituito come contesto
Livello di orchestrazione Richiesta dell'utente, contesto della conversazione, descrizioni dei componenti, descrizioni degli input, descrizioni di output, stato del piano, risposte implicite (ma non se l'informazione implicita sia stata mostrata all'utente) Sì. Le proprie domande e risposte. Le sue domande, risposte, ragionamenti e piani propri.
Topic Variabili topic, stato attuale del nodo Sì. Tramite nodi di messaggio, nodi di domanda e Richiedi con scheda adattiva. Output di argomenti e scambi di messaggi impliciti che possono comunque causare duplicazioni.
Strumento o flusso Input generati dal livello di orchestrazione No. Strumento o output del flusso.
Fase della conoscenza Richiesta dell'utente più il contesto attivo del suo agente No. Scrive al proprio agente, non al pannello di chat. La risposta.
Nodo delle risposte generative (all'interno di un argomento) Cosa viene inviato nell'input insieme al contesto del suo agente Sì. Direttamente, o a una variabile tematica. Non in modo esplicito, potrebbe essere ripetuto.
Sottoagente (figlio o agente collegato) La sua richiesta iniziale, più gli input forniti dai genitori e qualsiasi contesto genitore incluso, all'interno del proprio contesto di livello di orchestrazione Sì, se è configurato o istruito per rispondere direttamente. Una risposta e i relativi output.

Importante

Argomenti: Il contesto implicito restituito dagli argomenti include solo informazioni in testo semplice, ma non se l'utente le abbia viste. Le informazioni in testo semplice possono provenire da nodi di messaggi, nodi di domanda, contenuti di Adaptive Card e risposte digitate dall'utente. Tuttavia, i pulsanti d'azione della Adaptive Card e le interazioni dell'utente con essi non raggiungono il contesto standard dell'imbracatura. La gestione adattiva delle schede causa la maggior parte delle discrepanze di contesto. Non affidarti al contenuto delle carte come contesto. Invece, restituisci qualsiasi informazione richiesta in un passaggio successivo come output di argomento e imposta un output a stato risposto. Scopri di più sugli argomenti di Design come mini-agenti che evitano messaggi duplicati.

Sottoagenti: Quando il contesto genitore viene passato a un agente connesso, può influenzare ogni strumento, argomento e chiamata di conoscenza che l'agente effettua. Se il contesto incluso contiene ancora una richiesta che sembra non essere stata risposta, l'agente collegato potrebbe cercare di compensare e rispondere di nuovo. Un agente minore ha lo stesso rischio con meno controllo. Viene eseguito all'interno del genitore e riceve sempre il contesto della conversazione del genitore, senza alcuna impostazione che lo escluda. Scopri di più su Sottoagenti di Progettazione che evitano messaggi duplicati.

Passo successivo

Tenendo conto di questo modello contestuale, il prossimo articolo di questa serie spiega perché questo modello causa messaggi duplicati e suggerisce schemi di progettazione per prevenirli.

Migliori pratiche di progettazione per evitare messaggi duplicati

  • Last updated on