Contextverdeling in het standaardharnas

Het standaardraamwerk verdeelt de context over de componenten die een verzoek afhandelen. Elke component werkt vanuit zijn eigen context, en het harnas verzoent de context niet automatisch op het hoogste niveau. Deze scheiding biedt flexibiliteit, maar kan leiden tot dubbele berichten of gemiste antwoorden als informatie niet expliciet wordt teruggegeven door onafhankelijke componenten.

Dit artikel legt uit waarom context wordt verdeeld, hoe het GitHub Copilot-harnas verschilt, hoe context beweegt tussen de agent-orkestratielaag en een component, en wat elke component kan zien en teruggeven. Gebruik deze informatie om contextgaten te identificeren en agenten te ontwerpen die context doelbewust beheren.

Het volgende diagram laat zien hoe context en communicatie verlopen tussen de orkestratielaag, de afzonderlijke componenten en de gebruiker in de standaard-harness.

Note

Dit artikel beschrijft de kenmerken en het gedrag van het standaardharnas. Lees hoe je toegang krijgt tot standaardfuncties in Standaardagenten en agentstromen openen.

Een harnas voedt alles wat in Copilot Studio wordt gebouwd, en het gekozen model levert redenering en generatie. De kabelboom is een runtime die tussen de twee bestaat: deze bepaalt wanneer het model wordt aangeroepen, welke componenten het verzonden moet worden, interpreteert wat terugkomt en roept de juiste tools aan. Lees meer over Copilot Studio-harnassen.

Waarom de standaard-harnas context verdeelt

Het standaardharnas is ontworpen voor flexibiliteit:

Het orkestreert taken en ondersteunt transactionele gebruikssituaties.
Het balanceert deterministische controle en AI via variabelen, triggers en gespecialiseerde kenmerken.
Het verdeelt de controle over componenten zoals onderwerpen, kennis, kindagenten, verbonden agenten en tools.
Het ondersteunt meerdere authenticatie-, kanaal- en integratieopties.

Het verdelen van werk over onafhankelijke componenten biedt flexibiliteit, maar kan gaten in de context creëren:

De agentorchestratielaag draagt de controle over tijdens bepaalde componentaanroepen.
Terwijl een component draait, kan de orkestratielaag de berichten die de component naar de gebruiker stuurt niet zien.
De orkestratielaag verzoent de context niet op het hoogste niveau.

Als het ontwerp de context van de agent niet beheert, ontstaan er hiaten en kunnen verzoeken onbeantwoord lijken. Deze hiaten kunnen leiden tot dubbele of gemiste antwoorden.

Hoe het GitHub Copilot-harnas verschilt

De orkestratielaag van het GitHub Copilot-harnas voorkomt contextmismatch door de enige communicator met de gebruiker te zijn. Het laat nooit een verbonden agent de communicatie overnemen:

De redeneer- en communicatieloop werkt zonder bewust contextbeheer.
Berichten van verbonden agenten passeren bij elke stap de AI-laag van de ouder.

De orkestratielaag van het GitHub Copilot-harnas behandelt ook de contextgrootte anders, waardoor de context ervan ordes van grootte groter is dan die van het standaardharnas:

Het heeft directe toegang tot de modelcontext.
Het kan baat hebben bij compactie.
Het kan data en bestanden schrijven naar zijn Bash sandboxcontainer.

Hoe context doorgaat naar componenten en terugkeert naar de orkestratielaag

Om context effectief te beheren in het standaard harness, moet je zowel overwegen wat de orkestratielaag aan een component doorgeeft als wat de component teruggeeft.

Context wordt op twee manieren naar componenten overgedragen:

Expliciete invoer en verzoek: De orkestratielaag vult de input van elke component uit zijn actieve context en geeft een verzoek door zoals ontworpen.
Impliciete conversatiecontext: De orkestratielaag geeft ook een langere conversatiecontext door aan componenten zoals kennis en subagenten zonder expliciete configuratie. Let op dat een kindagent altijd de context van het oudergesprek ontvangt. Een verbonden agent heeft een instelling die deze omvat of uitsluit. Een tool of flow ontvangt alleen zijn input.

Een component stuurt informatie op twee manieren terug naar de orkestratielaag:

Expliciete output en respons zoals bedoeld.
Impliciete context van bepaalde componenten.

Wat een component alleen aan de gebruiker laat zien, of alleen in zijn eigen variabelen behoudt, bereikt misschien nooit de orkestratielaag tenzij het via een van die twee kanalen terugkomt.

Impliciete doorgeven van informatie veroorzaakt ongeveer de helft van de gevallen met dubbele of gemiste antwoorden, omdat een component kan handelen op een verzoek dat nooit expliciet aan hem is doorgegeven.

Hoe context verschilt tussen componenten

De door de gebruiker zichtbare conversatie en de context van de orkestratielaag overlappen, maar ze zijn niet hetzelfde. De volgende principes zijn van toepassing op wat vanuit een componentaanroep de context van de orchestratielaag bereikt:

Wat een component voor zichzelf bewaart, blijft verborgen. Onderwerpvariabelen en multi-turngesprekken binnen subagenten bevinden zich in de component. De orkestratielaag ziet ze alleen als ze als output worden teruggegeven.
Er zijn slechts twee soorten informatie die terugkomen. De orkestratielaag ontvangt de ontworpen expliciete uitvoer en impliciete context van een component. Een component die wel werkt maar niets teruggeeft, kan de orkestratielaag onwetend laten wat er is gebeurd.

Elke component heeft zijn eigen context of perspectief. De orkestratielaag gebruikt zijn actieve context om stappen te selecteren en invoer te genereren. Een verbonden agent heeft een eigen orkestratielaag, eigen instructies en eigen interne hulpmiddel- en kennisaanroepen.

Gebruik de volgende tabel om een precieze vraag te stellen: Welke component heeft een gegeven feit in zijn actieve context?

Standpunt	Heeft in zijn actieve context	Kan naar het chatpaneel schrijven	Kan terugkeren als context
Indelingslaag	Gebruikersverzoek, conversatiecontext, componentbeschrijvingen, invoerbeschrijvingen, uitvoerbeschrijvingen, planstatus, impliciete antwoorden (maar niet of de impliciete informatie aan de gebruiker is getoond)	Ja. De eigen vragen en antwoorden.	De eigen vragen, antwoorden, redenering en het plan.
Onderwerp	Onderwerpvariabelen, huidige knooptoestand	Ja. Via berichtknopen, vraagknooppunten en Vraag met Adaptieve Kaart.	Onderwerp-uitingen en impliciete berichtuitwisselingen die nog steeds duplicatie kunnen veroorzaken.
Hulpmiddel of werkstroom	Invoer gegenereerd door de orkestratielaag	Nee.	Tool- of flow-uitvoer
Kennisstap	Het verzoek van de gebruiker samen met de actieve context van de agent	Nee. Het schrijft naar zijn eigen agent, niet naar het chatpaneel.	Het antwoord.
Generatieve antwoorden-knoop (binnen een onderwerp)	Wat er in zijn invoer wordt verzonden plus de context van zijn agent	Ja. Direct, of naar een onderwerpvariabele.	Niet expliciet, mag worden herhaald.
Subagent (onderliggende of verbonden agent)	Het initiële verzoek, plus door ouders geleverde invoer en eventuele inbegrepen oudercontext, binnen de eigen context van de orkestratielaag	Ja, als het geconfigureerd is of direct geïnstrueerd is om te reageren.	Een reactie en de uitslagen ervan.

Important

Onderwerpen: Impliciete context die door onderwerpen wordt teruggegeven bevat alleen platte tekstinformatie, maar niet of de gebruiker deze heeft gezien. Platte tekstinformatie kan afkomstig zijn van berichtknopen, vraagknooppunten, Adaptive Card-inhoud en door de gebruiker getypte antwoorden. Adaptieve kaart-actieknoppen en gebruikersinteracties daarmee bereiken echter niet de standaard harnas context. Adaptieve kaartverwerking veroorzaakt de meeste contextmismatches. Vertrouw niet op de inhoud van de kaart als context. Geef in plaats daarvan alle informatie terug die een latere stap nodig heeft als onderwerpuitvoer en stel een antwoordtoestand-uitvoer in. Lees meer in Ontwerponderwerpen als mini-agenten die dubbele berichten voorkomen.

Subagenten: Wanneer oudercontext wordt doorgegeven aan een verbonden agent, kan dit elk gereedschap, onderwerp en elke kennisoproep die de agent uitvoert, beïnvloeden. Als de bijgevoegde context nog steeds een verzoek bevat dat lijkt alsof het niet is beantwoord, kan de verbonden agent proberen te compenseren en het opnieuw beantwoorden. Een kindagent loopt hetzelfde risico met minder controle. Het draait binnen de ouder en ontvangt altijd de context van het gesprek van de ouder, zonder instelling om het uit te sluiten. Lees meer in Design subagents die dubbele berichten vermijden.

Volgende stap

Met dit contextmodel in gedachten legt het volgende artikel in deze serie uit waarom dit model dubbele berichten veroorzaakt en stelt het ontwerppatronen voor om deze te voorkomen.

Ontwerp best practices om dubbele berichten te vermijden

Feedback

Is deze pagina nuttig?

Last updated on 2026-08-28