Kontekstfordeling i standardharnessen

Standardharnessen fordeler kontekst over komponentene som håndterer en forespørsel. Hver komponent fungerer ut fra sin egen kontekst, og harnessen forener ikke automatisk konteksten på toppnivå. Denne separasjonen gir fleksibilitet, men kan føre til dupliserte meldinger eller tapte svar hvis informasjonen ikke returneres eksplisitt av uavhengige komponenter.

Denne artikkelen forklarer hvorfor kontekst er distribuert, hvordan GitHub Copilot-verktøyet skiller seg ut, hvordan kontekst beveger seg mellom agentens orkestreringslag og en komponent, og hva hver komponent kan se og returnere. Bruk denne informasjonen til å identifisere konteksthull og designe agenter som håndterer kontekst bevisst.

Følgende diagram illustrerer hvordan kontekst og kommunikasjon flyter mellom orkestreringslaget, individuelle komponenter og brukeren i standardharnessen.

Diagram som viser kontekst og kommunikasjon som sendes mellom orkestreringslaget, hver komponent og brukeren i en standard harness-agent.

Note

Denne artikkelen beskriver egenskapene og oppførselen til standardselen. Lær hvordan du får tilgang til standardfunksjoner i Access standardagenter og agentflyter.

En sele driver alt som bygges i Copilot Studio, og den valgte modellen gir resonnement og generering. Harnessen er en kjøretid som eksisterer mellom de to: den bestemmer når modellen skal kalles opp, hvilke komponenter som skal sendes den, tolker det som kommer tilbake, og kaller de riktige verktøyene. Lær mer om Copilot Studio-seler.

Hvorfor standardharnessen distribuerer kontekst

Standardselen er laget for fleksibilitet:

  • Den orkestrerer oppgaver og støtter transaksjonelle brukstilfeller.
  • Den balanserer deterministisk kontroll og AI gjennom variabler, triggere og spesialiserte funksjoner.
  • Den fordeler kontrollen over komponenter som temaer, kunnskap, barneagenter, tilknyttede agenter og verktøy.
  • Den støtter flere autentiserings-, kanal- og integrasjonsalternativer.

Å fordele arbeidet på uavhengige komponenter gir fleksibilitet, men kan skape hull i konteksten:

  • Agentens orkestreringslag overfører kontrollen ved enkelte komponentkall.
  • Mens en komponent kjører, kan ikke orkestreringslaget se meldingene komponenten sender til brukeren.
  • Orkestreringslaget forener ikke konteksten på toppnivå.

Hvis designet ikke håndterer agentens kontekst, oppstår det hull, og forespørsler kan virke ubesvarte. Disse hullene kan føre til dupliserte eller manglende svar.

Hvordan GitHub Copilot-selen skiller seg ut

Orkestreringslaget i GitHub Copilot-harnessen unngår kontekstmismatch ved å være den eneste kommunikatøren med brukeren. Den lar aldri en tilkoblet agent overta kommunikasjonen:

  • Resonnement- og kommunikasjonssløyfen fungerer uten bevisst kontekststyring.
  • Tilkoblede agentmeldinger passerer gjennom forelderens AI-lag ved hver sving.

Orkestreringslaget i GitHub Copilot-harnessen behandler også kontekststørrelsen annerledes, noe som gjør konteksten flere størrelsesordener større enn standardharnessen:

  • Den har direkte tilgang til modellkonteksten.
  • Den kan bruke komprimering.
  • Den kan skrive data og filer til sin Bash sandbox-container.

Hvordan kontekst sendes til komponentene og returnerer til orkestreringslaget

For å håndtere kontekst effektivt i standardharnessen, vurder både hva orkestreringslaget sender til en komponent og hva komponenten returnerer.

Kontekst overføres til komponenter på to måter:

  • Eksplisitte input og forespørsel: Orkestreringslaget fyller hver komponents input fra sin aktive kontekst og sender en forespørsel som planlagt.

  • Implisitt samtalekontekst: Orkestreringslaget gir også en lengre samtalekontekst til komponenter som kunnskap og underagenter uten eksplisitt konfigurasjon. Merk at en barneagent alltid mottar konteksten for foreldresamtalen. En tilkoblet agent har en innstilling som inkluderer eller ekskluderer den. Et verktøy eller en flyt mottar kun sine input.

En komponent sender informasjon tilbake til orkestreringslaget på to måter:

  • Eksplisitte resultater og respons som designet.
  • Implisitt kontekst fra visse komponenter.

Det en komponent bare viser brukeren, eller bare beholder sine egne variabler, kan aldri nå orkestreringslaget med mindre det kommer tilbake gjennom en av de to kanalene.

Implisitt overføring av informasjon fører til omtrent halvparten av tilfellene med dupliserte eller manglende svar fordi en komponent kan handle på en forespørsel som aldri eksplisitt ble sendt til den.

Hvordan kontekst varierer mellom komponenter

Den brukersynlige samtalen og orkestreringslagets kontekst overlapper, men de er ikke det samme. Følgende prinsipper gjelder for det som når orkestreringslagets kontekst fra et komponentkall:

  • Det en komponent holder for seg selv, forblir skjult. Temavariabler og samtaler med flere omganger inne i underagenter finnes inne i komponenten. Orkestreringslaget ser dem bare hvis de returneres som utganger.

  • Bare to typer informasjon returneres. Orkestreringslaget mottar de eksplisitte utgangene som er designet og implisitt kontekst fra en komponent. En komponent som fungerer, men returnerer ingenting, kan la orkestreringslaget være uvitende om hva som skjedde.

Hver komponent har sin egen kontekst, eller sitt eget synspunkt. Orkestreringslaget bruker sin aktive kontekst til å velge steg og generere input. En tilkoblet agent har sitt eget orkestreringslag, sine egne instruksjoner, og sitt eget interne verktøy og kunnskapskall.

Bruk følgende tabell for å stille et presist spørsmål: Hvilken komponent har et gitt faktum i sin aktive kontekst?

Synspunkt Har i sin aktive kontekst Kan skrive til chatpanelet Kan returnere som kontekst
Orkestreringslag Brukerforespørsel, samtalekontekst, komponentbeskrivelser, inndatabeskrivelser, utdatabeskrivelser, planstatus, implisitte svar (men ikke om den implisitte informasjonen er vist til brukeren) Ja. Det er egne spørsmål og svar. Dens egne spørsmål, svar, resonnement og plan.
Emne Emnevariabler, nåværende nodetilstand Ja. Gjennom meldingsnoder, spørsmålsnoder og Spør med adaptivt kort. Temautdata og implisitte meldingsutvekslinger som fortsatt kan føre til duplisering.
Verktøy eller arbeidsflyt Input generert av orkestreringslaget Nei. Verktøy- eller flytutganger.
Kunnskapssteg Brukerforespørsel pluss den aktive konteksten til dens agent Nei. Den skriver til sin egen agent, ikke chatpanelet. Svaret deres.
Generative svar-node (inne i et emne) Hva som sendes inn i inputen pluss agentens kontekst Ja. Direkte, eller til en temavariabel. Ikke eksplisitt, kan gjentas.
Subagent (barn eller tilknyttet agent) Den opprinnelige forespørselen, pluss innganger fra foreldrene og eventuell inkludert foreldrekontekst, innenfor sin egen orkestreringslagskontekst Ja, hvis det er konfigurert eller instruert til å svare direkte. Et svar og dets resultater.

Important

Emner: Implisitt kontekst returnert av emner inkluderer kun ren tekstinformasjon, men ikke om brukeren så det. Klartekstinformasjon kan komme fra meldingsnoder, spørsmålsnoder, innhold fra Adaptive Card og brukerens innskrevne svar. Imidlertid når ikke handlingsknappene for Adaptive Card og brukerinteraksjoner med dem den standard harness-konteksten. Adaptiv korthåndtering forårsaker de fleste kontekstuoverensstemmelser. Ikke stol på kortinnholdet som kontekst. I stedet returnerer du all informasjon som et senere steg trenger som temautgang og sett en svartilstandsutdata. Lær mer i Design-temaer som mini-agenter som unngår dupliserte meldinger.

Subagenter: Når foreldrekontekst sendes til en tilkoblet agent, kan det påvirke hvert verktøy, tema og kunnskapskall agenten foretar. Hvis den inkluderte konteksten fortsatt inneholder en forespørsel som virker som den ikke ble besvart, kan den tilknyttede agenten prøve å kompensere og svare på den igjen. En barneagent har samme risiko med mindre kontroll. Den kjører inne i forelderen og mottar alltid forelderens samtalekontekst, uten noen innstilling for å utelate den. Lær mer i Design underagenter som unngår dupliserte meldinger.

Neste trinn:

Med denne kontekstmodellen i tankene forklarer neste artikkel i serien hvorfor denne modellen forårsaker dupliserte meldinger og foreslår designmønstre for å forhindre dem.

Design beste praksis for å unngå dupliserte meldinger

  • Last updated on