Kontekstfordeling i standardharnessen

Standardharnessen fordeler kontekst på tværs af de komponenter, der håndterer en forespørgsel. Hver komponent arbejder ud fra sin egen kontekst, og harnesset forener ikke automatisk konteksten på øverste niveau. Denne adskillelse giver fleksibilitet, men kan forårsage dublerede beskeder eller missede svar, hvis informationen ikke returneres eksplicit af uafhængige komponenter.

Denne artikel forklarer, hvorfor kontekst er distribueret, hvordan GitHub Copilot-værktøjet adskiller sig, hvordan kontekst bevæger sig mellem agentens orkestreringslag og en komponent, og hvad hver komponent kan se og returnere. Brug denne information til at identificere konteksthuller og designe agenter, der bevidst håndterer konteksten.

Følgende diagram illustrerer, hvordan kontekst og kommunikation flyder mellem orkestreringslaget, de enkelte komponenter og brugeren i standardharnesset.

Diagram, der viser kontekst og kommunikation, der overføres mellem orkestreringslaget, hver komponent og brugeren i en standard harness-agent.

Bemærkning

Denne artikel beskriver egenskaber og adfærd ved standardselen. Lær, hvordan du får adgang til standardfunktioner i Access standardagenter og agentflows.

En sele driver alt, der er bygget i Copilot Studio, og den valgte model giver ræsonnement og generering. Harnesset er en runtime, der eksisterer mellem de to: det bestemmer, hvornår modellen skal kaldes, hvilke komponenter der skal sendes den, fortolker det, der kommer tilbage, og kalder de rigtige værktøjer. Lær mere om, hvordan Copilot Studio udnytter.

Hvorfor standardharnesset distribuerer kontekst

Standardselen er bygget til fleksibilitet:

  • Den orkestrerer opgaver og understøtter transaktionelle anvendelsestilfælde.
  • Den balancerer deterministisk kontrol og AI gennem variabler, triggere og specialiserede funktioner.
  • Den fordeler kontrollen på tværs af komponenter som emner, viden, børneagenter, forbundne agenter og værktøjer.
  • Den understøtter flere autentificerings-, kanal- og integrationsmuligheder.

Fordeling af arbejdet på tværs af uafhængige komponenter giver fleksibilitet, men kan skabe huller i konteksten:

  • agentorkestreringslaget overdrager styringen ved visse komponentkald.
  • Mens en komponent kører, kan orkestreringslaget ikke se de beskeder, komponenten sender til brugeren.
  • Orkestreringslaget forener ikke konteksten på det øverste niveau.

Hvis designet ikke håndterer agentens kontekst, opstår der huller, og forespørgsler kan virke ubesvarede. Disse huller kan føre til dubletter eller missede svar.

Hvordan GitHub Copilot-harnesset adskiller sig

Orkestreringslaget i GitHub Copilot-harnesset undgår kontekstmismatch ved at være den eneste kommunikator med brugeren. Den lader aldrig en forbundet agent overtage kommunikationen:

  • Ræsonnement- og kommunikationsloopet fungerer uden bevidst kontekststyring.
  • Forbundne agentbeskeder passerer gennem moderens AI-lag ved hvert sving.

Orkestreringslaget i GitHub Copilot-harnesset behandler også kontekststørrelsen anderledes, hvilket gør kontekstens størrelsesordener større end standardharnesset:

  • Den har direkte adgang til modelkonteksten.
  • Den kan bruge kompaktering.
  • Den kan skrive data og filer til sin Bash sandbox-container.

Hvordan kontekst sendes til komponenter og vender tilbage til orkestreringslaget

For effektivt at håndtere konteksten i standardharnesset, skal man overveje både, hvad orkestreringslaget sender til en komponent, og hvad komponenten returnerer.

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

  • Eksplicitte input og anmodninger: Orkestreringslaget udfylder hver komponents input fra dens aktive kontekst og sender en anmodning som designet.

  • Implicit samtalekontekst: Orkestreringslaget sender også en længere samtalekontekst til komponenter som viden og subagenter uden eksplicit konfiguration. Bemærk, at en barneagent altid modtager konteksten for forældresamtalen. En forbundet agent har en indstilling, der inkluderer eller udelukker den. Et værktøj eller flow modtager kun sine input.

En komponent sender information tilbage til orkestreringslaget på to måder:

  • Eksplicitte output og respons som designet.
  • Implicit kontekst fra visse komponenter.

Hvad en komponent kun viser brugeren, eller kun beholder sine egne variable, når måske aldrig orkestreringslaget, medmindre det kommer tilbage gennem en af de to kanaler.

Implicit overførsel af information forårsager omkring halvdelen af sagerne med duplikerede eller missede svar, fordi en komponent kan handle på en anmodning, der aldrig eksplicit blev videregivet til den.

Hvordan konteksten adskiller sig mellem komponenter

Den brugersynlige samtale og orkestreringslagets kontekst overlapper, men de er ikke det samme. Følgende principper gælder for det, der når orkestreringslagets kontekst fra et komponentkald:

  • Det, en komponent holder for sig selv, forbliver skjult. Emnevariabler og samtaler med flere ture i subagenter findes i komponenten. Orkestreringslaget ser dem kun, hvis de returneres som output.

  • Kun to typer oplysninger returneres. Orkestreringslaget modtager de eksplicitte output, der er designet og implicit kontekst fra en komponent. En komponent, der virker, men returnerer intet, kan efterlade orkestreringslaget uvidende om, hvad der skete.

Hver komponent har sin egen kontekst eller synspunkt. Orkestreringslaget bruger sin aktive kontekst til at vælge trin og generere input. En forbundet agent har sit eget orkestreringslag, sine egne instruktioner og sit eget interne værktøj og videnskald.

Brug følgende tabel til at stille et præcist spørgsmål: Hvilken komponent har et givent faktum i sin aktive kontekst?

Synspunkt Har i sin aktive kontekst Kan skrive til chatpanelet Kan returnere som kontekst
Orkestreringslag Brugerforespørgsel, samtalekontekst, komponentbeskrivelser, inputbeskrivelser, outputbeskrivelser, planstatus, implicitte svar (men ikke om den implicitte information er blevet vist til brugeren) Ja. Dens egne spørgsmål og svar. Dens egne spørgsmål, svar, ræsonnement og plan.
Emne Emnevariable, nuværende nodetilstand Ja. Gennem beskednoder, spørgsmålsnoder og Ask med adaptivt kort. Emneudbytter og implicitte beskedudvekslinger, som stadig kan forårsage duplikation.
Værktøj eller flow Input genereret af orkestreringslaget Nej. Værktøjs- eller flowoutput.
Videntrin Brugeranmodning samt agentens aktive kontekst Nej. Den skriver til sin egen agent, ikke chatpanelet. Dens svar.
Generativ svarnode (indenfor et emne) Hvad der sendes i dens input plus agentens kontekst Ja. Direkte eller til en emnevariabel. Ikke eksplicit, kan gentages.
Subagent (underordnet eller tilsluttet agent) Dens oprindelige anmodning, plus input fra forældre og eventuel inkluderet forældrekontekst, inden for dens egen orkestreringslagskontekst Ja, hvis den er konfigureret eller instrueret til at svare direkte. Et svar og dets output.

Important

Emner: Implicit kontekst, som emnerne returnerer, inkluderer kun almindelig tekstinformation, men ikke om brugeren så den. Almindelig tekstinformation kan komme fra beskednoder, spørgsmålsnoder, indhold på Adaptive Card og brugerens indtastede svar. Dog når Adaptive Card-handlingsknapper og brugerinteraktioner med dem ikke den standard harness-kontekst. Adaptiv korthåndtering forårsager de fleste kontekstuoverensstemmelser. Stol ikke på kortindholdet som kontekst. Returner i stedet alle de oplysninger, som et senere trin skal bruge, som et emneoutput, og angiv et output for besvaret tilstand. Lær mere i Design-emner som mini-agenter, der undgår duplikerede beskeder.

Subagenter: Når forældrekontekst sendes til en forbundet agent, kan det påvirke ethvert værktøj, emne og videnskald, som agenten foretager. Hvis den inkluderede kontekst stadig indeholder en anmodning, der ser ud til ikke at være blevet besvaret, kan den tilknyttede agent forsøge at kompensere og svare igen. En børneagent har samme risiko med mindre kontrol. Den kører inde i forælderen og modtager altid forælderens samtalekontekst, uden nogen indstilling til at udelukke den. Lær mere i Design subagents, der undgår dublerede beskeder.

Næste trin

Med denne kontekstmodel i tankerne forklarer den næste artikel i serien, hvorfor denne model forårsager duplikerede beskeder og foreslår designmønstre for at forhindre dem.

Design bedste praksis for at undgå dublerede beskeder

  • Last updated on