Kontextfördelning i standardharnessen

standardramverket fördelar kontext till de komponenter som hanterar en begäran. Varje komponent fungerar utifrån sitt eget sammanhang, och harnessen förenar inte automatiskt kontexten på högsta nivå. Denna separation ger flexibilitet, men kan orsaka dubbletter av meddelanden eller missade svar om information inte returneras explicit av oberoende komponenter.

Den här artikeln förklarar varför kontext är distribuerad, hur GitHub Copilot-verktyget skiljer sig åt, hur kontext rör sig mellan agentens orkestreringslager och en komponent, samt vad varje komponent kan se och returnera. Använd denna information för att identifiera kontextluckor och designa agenter som medvetet hanterar kontexten.

Följande diagram illustrerar hur kontext och kommunikation flyter mellan orkestreringslagret, individuella komponenter och användaren i standardharnessen.

Diagram som visar kontext och kommunikation som passerar mellan orkestreringslagret, varje komponent och användaren i en standard harness-agent.

Note

Den här artikeln beskriver egenskaper och beteende hos standardselen. Lär dig hur du får tillgång till standardfunktioner i Access standardagenter och agentflöden.

En sele driver allt som byggs i Copilot Studio, och den valda modellen ger resonemang och generering. Harnessen är en runtime som existerar mellan de två: den bestämmer när modellen ska anropas, vilka komponenter som ska skickas till den, tolkar det som kommer tillbaka och anropar rätt verktyg. Läs mer om hur Copilot Studio använder.

Varför standardharnessen distribuerar kontext

Standardselen är byggd för flexibilitet:

  • Den orkestrerar uppgifter och stödjer transaktionella användningsfall.
  • Den balanserar deterministisk kontroll och AI genom variabler, triggers och specialiserade funktioner.
  • Den fördelar kontrollen över komponenter såsom ämnen, kunskap, barnagenter, kopplade agenter och verktyg.
  • Den stöder flera autentiserings-, kanal- och integrationsalternativ.

Att fördela arbetet över oberoende komponenter ger flexibilitet men kan skapa luckor i sammanhanget:

  • Agentorkestreringslagret lämnar över kontrollen under vissa komponentsamtal.
  • Medan en komponent körs kan orkestreringslagret inte se de meddelanden som komponenten skickar till användaren.
  • Orkestreringslagret synkroniserar inte kontexten på den översta nivån.

Om designen inte hanterar agentens kontext uppstår luckor och förfrågningar kan verka obesvarade. Dessa luckor kan orsaka dubbla eller missade svar.

Hur GitHub Copilot-selen skiljer sig åt

Orkestreringslagret i GitHub Copilot-harnessen undviker kontextmismatchen genom att vara den enda kommunikatören med användaren. Den låter aldrig en ansluten agent ta över kommunikationen:

  • Resonemanget och kommunikationsslingan fungerar utan avsiktlig kontexthantering.
  • Meddelanden från den anslutna agenten passerar genom förälderns AI-lager vid varje sväng.

Orkestreringslagret i GitHub Copilot-harnessen behandlar också kontextstorleken annorlunda, vilket gör dess kontext flera storleksordningar större än standardharnessen:

  • Den har direkt tillgång till modellkontexten.
  • Den kan dra nytta av komprimering.
  • Den kan skriva data och filer till sin Bash sandbox-container.

Hur kontext går vidare till komponenter och återvänder till orkestreringslagret

För att effektivt hantera kontext i standardharnessen, överväg både vad orkestreringslagret skickar till en komponent och vad komponenten returnerar.

Kontexten överförs till komponenter på två sätt:

  • Explicita indata och förfrågningar: Orkestreringslagret fyller varje komponents indata från dess aktiva kontext och skickar en begäran enligt design.

  • Implicit konversationskontext: Orkestreringslagret skickar också en längre konversationskontext till komponenter som kunskap och subagenter utan explicit konfiguration. Observera att en barnagent alltid tar emot förälderkonversationskontexten. En ansluten agent har en inställning som inkluderar eller exkluderar den. Ett verktyg eller flöde tar endast emot sina indata.

En komponent skickar information tillbaka till orkestreringslagret på två sätt:

  • Explicita utdata och svar som avsett.
  • Implicit kontext från vissa komponenter.

Det som en komponent endast visar för användaren, eller endast lagrar i sina egna variabler, når kanske aldrig fram till orkestreringslagret om det inte kommer tillbaka via någon av de två kanalerna.

Implicit informationsöverföring orsakar ungefär hälften av fallen med dubbletter eller missade svar eftersom en komponent kan agera på en begäran som aldrig uttryckligen skickades till den.

Hur kontext skiljer sig mellan komponenter

Den användarsynliga konversationen och orkestreringslagerets kontext överlappar, men de är inte samma sak. Följande principer gäller för vad som når orkestreringslagrets kontext från ett komponentanrop:

  • Det en komponent håller för sig själv förblir dolt. Ämnesvariabler och fleromgångskonversationer i underagenter finns i komponenten. Orkestreringslagret ser dem endast om de returneras som utgångar.

  • Endast två typer av information ger avkastning. Orkestreringslagret tar emot de explicita utdata som är designade och implicita kontexter från en komponent. En komponent som fungerar men inte ger något kan lämna orkestreringslagret ovetande om vad som hände.

Varje komponent har sin egen kontext eller synvinkel. Orkestreringslagret använder sin aktiva kontext för att välja steg och generera indata. En ansluten agent har sitt eget orkestreringslager, egna instruktioner och sitt eget interna verktyg och kunskapsanrop.

Använd följande tabell för att ställa en exakt fråga: Vilken komponent har ett givet faktum i sitt aktiva sammanhang?

Perspektiv Har i sin aktiva kontext Kan skriva till chattpanelen Kan returnera som kontext
Orkestreringsskikt Användarförfrågan, konversationskontext, komponentbeskrivningar, inmatningsbeskrivningar, utdatabeskrivningar, planstatus, implicita svar (men inte om den implicita informationen har visats för användaren) Ja. Dess egna frågor och svar. Dess egna frågor, svar, resonemang och plan.
Topic Ämnesvariabler, nuvarande nodtillstånd Ja. Genom meddelandenoder, frågenoder och Ask med adaptivt kort. Ämnesutdata och implicita meddelandeutbyten som ändå kan orsaka duplicering.
Verktyg eller flöde Indata genererade av orkestreringslagret Nej. Utdata från verktyg eller flöden.
Kunskapssteg Användarens begäran och agentens aktiva kontext Nej. Den skriver till sin egen agent, inte till chattpanelen. Dess svar.
Nod för generativa svar (i ett ämne) Det som skickas in i dess indata och agentens kontext Ja. Direkt, eller till en ämnesvariabel. Inte uttryckligen, det kan upprepas.
Subagent (barn eller associerad agent) Dess initiala begäran, plus föräldertillhandahållna indata och eventuell inkluderad föräldrakontext, inom dess egen orkestreringslagerkontext Ja, om det är konfigurerat eller instruerat att svara direkt. Ett svar och dess resultat.

Viktigt!

Ämnen: Implicit kontext som återges av ämnen inkluderar endast ren textinformation, men inte om användaren såg den. Ren textinformation kan komma från meddelandenoder, frågenoder, innehåll på Adaptive Card och användarens skrivna svar. Dock når inte Adaptive Card-handlingsknappar och användarinteraktioner med dem den vanliga selekontexten. Adaptiv korthantering orsakar de flesta kontextmissanpassningar. Lita inte på kortets innehåll som kontext. Returnera istället all information som ett senare steg behöver som ämnesutdata och sätt en svarstillståndsutdata. Läs mer i Utforma ämnen som miniagenter för att undvika dubbla meddelanden.

Subagenter: När föräldrakontext skickas till en ansluten agent kan det påverka varje verktyg, ämne och kunskapsanrop som agenten gör. Om den inkluderade kontexten fortfarande innehåller en begäran som verkar obesvarad, kan den anslutna agenten försöka kompensera och svara igen. En barnagent har samma risk men med mindre kontroll. Den körs inuti föräldern och tar alltid emot förälderns konversationskontext, utan någon inställning för att utesluta den. Läs mer i Designa subagenter som undviker dubblettmeddelanden.

Nästa steg

Med denna kontextmodell i åtanke förklarar nästa artikel i denna serie varför denna modell orsakar dubbletter och föreslår designmönster för att förhindra dem.

Designa bästa praxis för att undvika dubblettmeddelanden

  • Last updated on