Mønstre for orkestrering med flere agenter og bedste praksis

Generativ orkestrering understøtter også multiagentsystemer, hvor en agent kalder andre agenter. Når du opdeler problemer i flere specialiserede agenter, gør du dit program mere modulært, skalerbart og håndterbart.

Inline-agenter

Inline-agenter, også kendt som child agents, er små, genanvendelige arbejdsgange inden for samme agent. De er ofte bare emner, som hovedagenten bruger som underprogrammer. For eksempel kan hovedagenten kalde et emne "Oversæt tekst" som et skridt i en større plan. Inline-agenter deler kontekst med hovedagenten, så det er nemt at overføre data mellem dem.

Bedste praksis: Hold indbyggede agenter fokuseret på et enkelt ansvar, og test dem godt.

Forbundne agenter

Forbundne agenter er separate agenter med deres egen orkestrering, værktøjer og viden. Hovedagenten delegerer en del af en anmodning til en børneagent. En it-agent kalder f.eks. en salgsagent for at få oplysninger om priser. Forbundne agenter muliggør modularitet og domæneadskillelse og kan tilsidesætte plangrænser. De kan have forskellige privilegier eller viden, så anvend styrings- og revisionskontroller.

Dog kræver brugen af forbundne agenter omhyggelig styring:

• Orkestrering: Moderorkestratøren bør have klare kriterier for, hvornår den skal overdrages til en tilknyttet agent. Orchestratoren afskærer normalt, når brugerens hensigt stemmer overens med den forbundne agents domæne. For at understøtte denne proces skal du klart beskrive den tilknyttede agents formål i forældres konfiguration. Behandl hele den forbundne agent som et agentisk "værktøj" med en beskrivelse set fra den overordnedes perspektiv.

• Dataoverlevering: Du skal styre dataoverdragelsen. Beslut hvilken kontekst fra forælderen der skal gives videre til den tilknyttede agent. Copilot Studio overfører som standard samtaleoversigten, når én agent kalder en anden, så den forbundne agent forstår den tidligere kontekst for samtalen. Men du skal måske også opfylde specifikke parametre. For eksempel, hvis hovedagenten allerede kender brugerens navn fra tidligere, kan den sende det til den tilknyttede agent for at undgå at spørge igen.

• Sikkerhed: Den tilknyttede agent kan have adgang til ting, som moderagenten ikke har. Sørg for, at det at ringe til den tilknyttede agent ikke utilsigtet omgår begrænsningerne. For eksempel, hvis forældreagenten ikke må slette poster, men den tilknyttede agent kan, bør moderagenten ikke kalde den tilknyttede agent i situationer, hvor sletning kan ske uden korrekt godkendelse. Behandl et opkald til en tilknyttet agent som enhver anden effektiv handling. Hvis den laver noget følsomt, så udsæt den for nødvendige kontroller eller brugerens samtykke.

• Audit og overvågning: Log hvornår en tilsluttet agent blev kaldt, og hvad den gjorde. Da det er en separat agent, har du separate udskrifter til det. Det er vigtigt for fejlfinding at korrelere forældre- og tilknyttede sessioner. Typisk forbinder identitegnerne i telemetrien de to.

Hvornår skal agenter adskilles

Opret ikke en separat agent for hver delopgave. Brug separate agenter, hvis delopgaven:

• Er kompleks nok til at have sit eget værktøjssæt eller viden (et andet ekspertiseområde)
• Kræver andre styringsregler eller adgangskontroller end hovedagenten
• Kan genbruges i mange forskellige hovedagenter (så det er som en serviceagent)

Hvis ingen af disse betingelser gælder, kan en simpel indbygget agent håndtere jobbet godt og samtidig være enklere end en fuld tilsluttet agent. Separate agenter introducerer overhead til systemet. Der er en lidt længere udførelsestid på grund af kontekstskift og kompleksitet i vedligeholdelsen af flere agenter. Så brug dem med omhu. Start med én agent for at få en praktisk tilgang. Derefter kun opdelt i flere agenter, når du tydeligt se et behov for modularitet eller en grænse en enkelt agent ikke bør krydse.

Bedste praksis for orkestrering med flere agenter

Følgende bedste fremgangsmåder gælder, når du opretter instruktioner til overordnede og underagenter i en konfiguration med flere agenter.

1. Enkelt svarprincip

Sørg for, at kun én agent taler med brugeren pr. tur. I en konfiguration med flere agenter er den overordnede agent den eneste, der skal levere det endelige svar. Subagenter er forskere, ikke respondere.

• Do: Føj til overordnede instruktioner: "Du er den eneste agent, der kommunikerer med brugeren. Kombiner resultater fra alle underordnede agenter til et enkelt svar."
• Lad være: Lad det være tvetydigt. Uden eksplicit vejledning svarer underagenter direkte til brugeren, hvilket medfører dublerede eller delvise meddelelser.

2. Underagentinstruktioner skal deklarere deres rolle

Fortæl altid underagenter, at de er subagenter. Subagenter ved ikke i sagens natur, at de er en del af en orkestrering. Uden eksplicit vejledning fungerer de som separate agenter og sender meddelelser direkte til brugeren.

• Do: Føj til hver subagents instruktioner: "Du er en subagent. Besvar IKKE brugeren direkte. Dit job er at søge efter oplysninger og returnere dine resultater til den overordnede agent. Den overordnede agent håndterer al kommunikation med brugeren."
• Må ikke: Antag, at underagenter selv finder ud af orkestreringsmønsteret.

3. Brug klart, direkte sprog i instruktioner

Brug altid direktivsprog. Undgå bløde eller høflige udtryk. Platformen indsætter instruktioner på systemniveau ved hjælp af et stærkt sprog (MUST, DO NOT, NEVER). Instruktioner, der er skrevet med et blødt sprog ("Prøv at," "du skal", "det ville være godt at") mister prioriteten, når de er i konflikt.

• Gør: "Svar ALDRIG direkte til brugeren. RETURNER KUN dine resultater."
• Do: "Der skal være præcis ét endeligt svar pr. bruger spørgsmål."
• Undlad at gøre følgende: "Prøv at undgå at sende meddelelser til brugeren og i stedet returnere dine resultater.".
• Må ikke: "Ideelt set ønsker vi et enkelt kombineret svar."

4. Brug én videnkilde pr. underagent (ingen overlapning)

Tildel særskilte, ikke-overlapping videnkilder til hver underagent. Hvis to underagenter søger i den samme vidensbase, finder en underagent svaret først. Den anden underagent returnerer enten duplikerede resultater eller springer søgningen helt over og tilføjer ingen værdi.

• Do: CA-1 søger i Knowledge Source A (f.eks. HR-politikker). CA-2 søger i Knowledge Source B (f.eks. it-dokumentation).
• Don't: Giv begge underagenter adgang til de samme dokumenter, Dataverse-tabeller eller SharePoint websteder.
• Bemærk! Hvis du kun har én videnkilde, skal du bruge en enkelt agent med viden i stedet for at opdele i to underagenter. Multiagenter tilføjer kun værdi, når kilderne virkelig er forskellige.

5. Brug præcise og entydige beskrivelser af underagenter

Skriv tydelige, entydige beskrivelser for hver underagent, der er synlig for den overordnede. Den overordnede agent bruger beskrivelser af underagenter til at bestemme routing. Hvis beskrivelser er vage, identiske eller unøjagtige, kan den overordnede ikke træffe gode routingbeslutninger.

• Do: CA-1: "Søger i HR-politikdokumenter efter medarbejderrelaterede spørgsmål". CA-2: "Søger i it-vidensbasen efter spørgsmål om teknisk support."
• Don't: Giv begge agenter den samme beskrivelse, når de tjener forskellige domæner.
• Må ikke: Brug generiske beskrivelser som "Denne agent kan hjælpe med spørgsmål".

6. Overordnede instruktioner skal definere orkestreringsmønsteret

Fortæl den overordnede agent, hvordan han skal orkestrere. Sig ikke bare "brug børneagenter". Den overordnede skal bruge eksplicitte instruktioner til mønsteret: aktivér agenter, vent på resultater, kombiner, og svar derefter.

• Do: "Når brugeren stiller et spørgsmål: 1. Aktivér begge underordnede agenter for at indsamle oplysninger. 2. Vent på, at begge underordnede agenter returnerer deres resultater. 3. Kombiner resultaterne i et enkelt samlet svar. 4. Levér præcis ét svar til brugeren. Underordnede agenter må ikke svare brugeren direkte."
• Undlad at gøre følgende: "Når brugeren stiller et spørgsmål, skal du aktivere underordnede agenter og få svar fra begge kilder og give et enkelt kombineret svar." (For vagt. Instruktionen fortæller ikke subagenter at forblive tavse.)

7. Medtag direktivet "intet direkte svar" i opgavedelegeringen

Selv med klare instruktioner om subagent giver tilføjelse af forstærkning i den delegerede opgave et sikkerhedsnet.

• Do: Føj til overordnede instruktioner: "Når du delegerer til en underordnet agent, skal du altid inkludere i opgaven: "Returner kun dine resultater. Besvar ikke brugeren.'"
• Må ikke: Brug udelukkende underagentens egne instruktioner. Opgavekonteksten giver underagenten flere signaler, der forstærker mønsteret.

8. Test med forespørgsler, der ikke stemmer overens med domænet

Test altid med spørgsmål, der ikke stemmer overens med nogen underagents domæne. Denne test viser, om subagenter på en elegant måde returnerer "ingen oplysninger fundet" i forhold til at returnere oplysninger, der kan være forkerte, blive hængt op eller sende forvirrende meddelelser.

• Do: Test med forespørgsler uden for alle underagentdomæner (spørg f.eks. om vejret, når agenter håndterer HR og IT).
• Foretag: Kontrollér, at den overordnede komponent håndterer "ingen af de to agenter fandt noget" på en hensigtsmæssig måde.
• Må ikke: Test kun med enkleste caseforespørgsler, der passer perfekt til én underagents domæne.

9. Foretrækker at spørge over informere, når der forventes en opfølgning

Brug interaktioner med spørgsmål/stil stil, når brugeren forventes at svare. Brug kun inform/send-style til endelige envejsmeddelelser. Hvis agenten spørger brugeren om noget ved hjælp af en envejsmeddelelse (informere), går brugerens svar tilbage til den overordnede planlægning som en helt ny forespørgsel. I dette tilfælde er det bedre at fortsætte den samme samtale med underagenten.

• Do: Skriv instruktioner som: "Hvis du har brug for afklaring, skal du stille brugeren et spørgsmål og vente på deres svar."
• Må ikke: Skriv instruktioner som f.eks.: "Giv brugeren besked om indstillingerne, og lad vedkommende vælge" "Inform" signalerer en envejsmeddelelse, mens "spørg" signalerer en tovejsudveksling.

Tjekliste til hurtig reference

Relaterede oplysninger

• Oversigt over at tilføje andre agenter
• Tilføj en børneagent
• Opret forbindelse til en eksisterende Copilot Studio-agent
• Forbind til en Microsoft Foundry-agent
• Opret forbindelse til en Microsoft Fabric Data agent
• Opret forbindelse til en SDK til Microsoft 365-agenter agent
• Forbind en agent, der er tilgængelig over Agent2Agent (A2A)-protokollen