Orkestreringsmønstre med flere agenter og anbefalte fremgangsmåter

Generativ orkestrering støtter også systemer med flere agenter, der en agent ringer andre agenter. Når du deler problemer inn i flere spesialiserte agenter, gjør du programmet mer modulært, skalerbart og håndterbart.

Inlineagenter

Inline-agenter, også kjent som barneagenter, er små, gjenbrukbare arbeidsflyter innenfor samme agent. De er ofte bare temaer som hovedagenten bruker som underprogrammer. For eksempel kan hovedagenten kalle et «Oversett tekst»-tema som ett steg i en større plan. Inline-agenter deler kontekst med hovedagenten, så det er enkelt å sende data mellom dem.

Beste praksis: Hold innebygde agenter fokusert på ett enkelt ansvar og test dem godt.

Koblede agenter

Tilknyttede agenter er separate agenter med egen orkestrering, verktøy og kunnskap. Hovedagenten delegerer deler av en forespørsel til en barneagent. En IT-agent ringer for eksempel en salgsagent for å få informasjon om priser. Tilkoblede agenter aktiverer modularitet og domeneseparasjon, og kan omgå plangrenser. De kan ha andre privilegier eller kunnskap, så bruk styrings- og revisjonskontroller.

Å bruke tilkoblede agenter krever imidlertid nøye styring:

• Orkestrering: Hovedorkestratoren bør ha klare kriterier for når den skal overleveres til en tilknyttet agent. Orchestratoren avsender vanligvis når brukerens hensikt samsvarer med den tilkoblede agentens domene. For å støtte denne prosessen, beskriv den tilknyttede agentens formål tydelig i foreldrenes konfigurasjon. Behandle hele den tilkoblede agenten som et agentbasert «verktøy» med en beskrivelse, sett fra den overordnede agentens perspektiv.

• Dataoverlevering: Du må administrere dataoverlevering. Bestem hvilken kontekst fra forelderen som skal sendes til den tilknyttede agenten. Copilot Studio viderefører samtaleloggen som standard når én agent ringer en annen, slik at den tilkoblede agenten forstår den forrige konteksten til samtalen. Men du må kanskje også oppfylle spesifikke parametere. For eksempel, hvis hovedagenten allerede kjenner brukerens navn fra tidligere, kan den sende det til den tilknyttede agenten for å unngå å spørre igjen.

• Sikkerhet: Den tilkoblede agenten kan ha tilgang til ting som hovedagenten ikke har. Sørg for at det å ringe den tilkoblede agenten ikke utilsiktet omgår begrensninger. For eksempel, hvis foreldreagenten ikke har lov til å slette poster, men den tilkoblede agenten kan, bør ikke foreldreagenten ringe den tilkoblede agenten i situasjoner der sletting kan skje uten riktig godkjenning. Behandle en samtale med tilkoblet agent som en hvilken som helst annen kraftfull handling. Hvis den gjør noe sensitivt, underlegg den nødvendige kontroller eller brukersamtykke.

• Revisjon og overvåking: Logg når en tilkoblet agent ble kalt og hva den gjorde. Siden det er en separat agent, har du separate utskrifter for det. Det er viktig for feilsøking å korrelere overordnede og tilknyttede økter. Vanligvis kobler identifikatorene i telemetrien de to.

Når man skal separere agenter

Ikke lag en egen agent for hver deloppgave. Bruk separate agenter hvis deloppgaven:

• Er komplekst nok til å ha sitt eget verktøysett eller kunnskap (et annet fagområde)
• Krever andre styringsregler eller tilgangskontroller enn hovedagenten
• Kan brukes på nytt i mange forskjellige hovedagenter (slik at det er som en tjenesteagent)

Hvis ingen av disse betingelsene gjelder, kan en enkel innebygd agent håndtere jobben godt, samtidig som den er enklere enn en fullstendig tilkoblet agent. Separate agenter introduserer overhead til systemet. Det er litt lengre kjøringstid på grunn av kontekstbytte og kompleksitet i vedlikehold av flere agenter. Så bruk dem med omhu. For en praktisk tilnærming, start med en agent. Deretter bare delt inn i flere agenter når du tydelig ser et behov for modularitet eller en grense en enkelt agent ikke bør krysse.

Anbefalte fremgangsmåter for orkestrering med flere agenter

Følgende anbefalte fremgangsmåter gjelder når du redigerer instruksjoner for overordnede og underagenter i et oppsett med flere agenter.

1. Prinsippet om ett svar

Sørg for at bare én agent snakker med brukeren per sving. I et oppsett med flere agenter er den overordnede agenten den eneste som skal levere det endelige svaret. Underagenter er forskere, ikke respondere.

• Gjør følgende: Legg til i overordnede instruksjoner: «Du er den eneste agenten som kommuniserer med brukeren. Kombiner funn fra alle barneagenter til ett enkelt svar.»
• Ikke: La det forbli tvetydig. Uten eksplisitt veiledning svarer underagenter direkte til brukeren, noe som forårsaker dupliserte eller delvise meldinger.

2. Underagentinstruksjoner må deklarere sin rolle

Fortell alltid underagenter at de er underagenter. Underagenter vet ikke at de er en del av en orkestrering. Uten eksplisitt veiledning oppfører de seg som frittstående agenter og sender meldinger direkte til brukeren.

• Gjør følgende: Legg til i alle underagentinstruksjoner: "Du er en underagent. Ikke svar direkte til brukeren. Jobben din er å søke etter informasjon og returnere resultatene til den overordnede agenten. Den overordnede agenten håndterer all kommunikasjon med brukeren.»
• Ikke gjør det: Anta at underagenter finner ut av orkestreringsmønsteret på egen hånd.

3. Bruk klart, direkte språk i instruksjoner

Bruk alltid direktivspråk. Unngå myk eller høflig frasering. Plattformen setter inn instruksjoner på systemnivå ved hjelp av sterkt språk (MUST, DO NOT, NEVER). Instruksjoner skrevet med mykt språk ("prøv å" "du bør", "det ville være bra å") mister prioritet når de er i konflikt.

• Gjør følgende: «SVAR ALDRI direkte til brukeren. Kun oppgi funnene dine.
• Gjør følgende: «Det må være nøyaktig ett endelig svar per brukerspørsmål.»
• Ikke: «Prøv å unngå å sende meldinger til brukeren, og returner i stedet funnene dine.»
• Ikke: «Ideelt sett ønsker vi et enkelt kombinert svar.»

4. Bruk én kunnskapskilde per underagent (ingen overlapping)

Tilordne distinkte, ikke-overlappende kunnskapskilder til hver underagent. Hvis to underagenter søker i samme kunnskapsbase, finner én underagent svaret først. Den andre underagenten returnerer enten dupliserte resultater eller hopper over søket fullstendig, og legger ikke til noen verdi.

• Gjør følgende: CA-1 søker i Kunnskapskilde A (for eksempel HR-policyer). CA-2 søker i Kunnskapskilde B (for eksempel IT-dokumentasjon).
• Ikke: Gi begge underagentene tilgang til de samme dokumentene, dataverse tabellene eller SharePoint områder.
• Obs! Hvis du bare har én kunnskapskilde, kan du bruke én enkelt agent med kunnskap i stedet for å dele inn i to underagenter. Multiagenten legger bare til verdi når kilder er helt forskjellige.

5. Bruk nøyaktige og distinkte beskrivelser for underagenter

Skriv klare, distinkte beskrivelser for hver underagent som er synlig for den overordnede. Den overordnede agenten bruker underagentbeskrivelser til å bestemme ruting. Hvis beskrivelsene er vage, identiske eller unøyaktige, kan ikke forelderen ta gode rutingbeslutninger.

• Gjør følgende: CA-1: «Søker i HR-policydokumenter etter spørsmål relatert til ansatte.» CA-2: «Søker i IT-kunnskapsbasen etter spørsmål om teknisk støtte.»
• Ikke gjør det: Gi begge agentene samme beskrivelse når de betjener forskjellige domener.
• Ikke gjør det: Bruk generiske beskrivelser som «Denne agenten kan hjelpe med spørsmål».

6. Overordnede instruksjoner må definere orkestreringsmønsteret

Fortell den overordnede agenten hvordan du orkestrerer. Ikke bare si "bruk barneagenter." Forelderen trenger eksplisitte instruksjoner om mønsteret: aktiver agenter, vent på resultater, kombiner og svar.

• Gjør følgende: «Når brukeren stiller et spørsmål: 1. Kall opp begge underordnede agenter for å samle inn informasjon. 2. Vent til begge barneagentene returnerer sine funn. 3. Kombiner funnene til ett enkelt, enhetlig svar. 4. Gi nøyaktig ett svar til brukeren. Underordnede agenter kan ikke svare brukeren direkte.»
• Ikke: «Når brukeren stiller et spørsmål, kan du aktivere barneagenter og få svar fra begge kildene og gi et enkelt kombinert svar.» (For vag. Instruksjon forteller ikke underagenter å være stille.)

7. Inkluder direktivet «ingen direkte svar» i oppgavedelegeringen

Selv med klare underagentinstruksjoner gir det å legge til forsterkning i den delegerte oppgaven et sikkerhetsnett.

• Gjør følgende: Legg til i overordnede instruksjoner: «Når du delegerer til en underordnet agent, må du alltid ta med i oppgaven: «Returner bare resultatene dine. Ikke svar til brukeren.'"
• Ikke: Stol utelukkende på underagentens egne instruksjoner. Oppgavekonteksten gir underagenten flere signaler som forsterker mønsteret.

8. Test med spørringer om domenekonflikt

Test alltid med spørsmål som ikke samsvarer med domenet til en underagent. Denne testingen viser om underagenter på en grasiøst returnerer «ingen informasjon funnet» kontra å returnere informasjon som kan være feil, bli hengt opp eller sende forvirrende meldinger.

• Gjør følgende: Test med spørringer utenfor alle underagentdomener (spør for eksempel om været når agenter håndterer HR og IT).
• Gjør følgende: Bekreft at forelderen håndterer «begge agentene fant ingenting» på en grasiøs måte.
• Ikke gjør det: Bare test med enkleste tilfellesspørringer som passer perfekt til ett underagentdomene.

9. Foretrekker å spørre over informere når du forventer en oppfølging

Bruk samhandlinger i spørsmål/spør-stil når du forventer at brukeren skal svare. Bruk bare informer/send-stil for siste enveismeldinger. Hvis agenten spør brukeren om noe ved hjelp av en enveismelding (informer), går brukerens svar tilbake til den overordnede planleggeren som en helt ny spørring. I dette tilfellet er det bedre å fortsette den samme samtalen med underagenten.

• Gjør følgende: Skriv instruksjoner som: «Hvis du trenger en avklaring, kan du stille brukeren et spørsmål og vente på svaret.»
• Ikke gjør det: Skriv instruksjoner som: «Informer brukeren om alternativene og la dem velge.» "Informer" signaliserer en enveismelding, mens "spør" signaliserer en toveis utveksling.

Sjekkliste for hurtigreferanse

Relatert informasjon

• Legg til oversikt over andre agenter
• Legg til en barneagent
• Koble til en eksisterende Copilot Studio-agent
• Koble til en Microsoft Foundry-agent
• Koble til en Microsoft Fabric dataagent
• Koble til en SDK for Microsoft 365-agenter agent
• Koble til en agent tilgjengelig over Agent2Agent (A2A)-protokollen