Mønstre og bedste praksis for multiagentorkestrering

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

Indbyggede agenter

Indbyggede agenter, også kendt som underordnede agenter, er små, genanvendelige arbejdsgange i samme agent. Det er ofte bare emner, som hovedagenten bruger som underrutiner. For eksempel kan hovedagenten kalde emnet "Oversæt tekst" som et trin i en større plan. Indbyggede agenter deler kontekst med hovedagenten, så det er nemt at overføre data mellem dem.

Bedste praksis: Hold indbyggede agenter fokuserede på ét 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 underordnet agent. For eksempel kontakter en it-agent en salgsagent for at få oplysninger om priser. Forbundne agenter muliggør modularitet og domæneadskillelse og kan omgå planbegrænsninger. De kan have forskellige rettigheder eller viden, så anvend styrings- og revisionskontroller.

Dog kræver brugen af forbundne agenter omhyggelig styring:

  • Orkestrering: Den overordnede organisator bør have klare kriterier for, hvornår der skal overleveres til en forbundet agent. Organisatoren overleverer typisk opgaven, når brugerens hensigt matcher den forbundne agents domæne. For at understøtte denne proces bør du tydeligt angive den forbundne agents formål i den overordnedes konfiguration. Behandl hele den forbundne agent som et agentbaseret "værktøj" med en beskrivelse, set fra den overordnedes perspektiv.

  • Dataoverlevering: Du skal håndtere dataoverlevering. Beslut, hvilken kontekst fra den overordnede agent der skal overleveres til den forbundne agent. Copilot Studio videregiver som standard samtalehistorikken, når en agent kalder en anden, så den forbundne agent forstår den tidligere kontekst af samtalen. Men du skal måske også overføre specifikke parametre. Hvis f.eks. hovedagenten allerede kender brugerens navn fra tidligere, kan den sende det til den forbundne agent for at undgå at spørge igen.

  • Sikkerhed: Den forbundne agent kan have adgang til ting, som den overordnede agent ikke har. Sørg for, at kald til den forbundne agent ikke utilsigtet omgår begrænsningerne. Hvis f.eks. den overordnede agent ikke må slette poster, men den forbundne agent kan, bør den overordnede agent ikke kalde den forbundne agent i situationer, hvor sletning kan ske uden korrekt godkendelse. Behandl et kald til en forbundet agent som enhver anden vigtig handling. Hvis den udfører en følsom handling, skal den underlægges de nødvendige kontroller eller indhentes brugerens samtykke.

  • Revision og overvågning: Log, hvornår en forbundet agent blev kaldt, og hvad den gjorde. Da det er en separat agent, har du separate afskrifter for den. Det er vigtigt for fejlfinding at korrelere sessioner for overordnede og forbundne agenter. Typisk forbinder identifikatorer i telemetrien de to.

Hvornår bør man adskille agenter

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 sin egen viden (et andet ekspertiseområde)
  • Kræver forskellige 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 opgaven godt, samtidig med at den er mere enkel end en fuldt forbundet agent. Separate agenter føjer belastning til systemet. Der er en lidt længere udførelsestid på grund af kontekstskift og kompleksitet ved at vedligeholde flere agenter. Så brug dem med omhu. For en praktisk tilgang, start med én agent. Opdel kun i flere agenter, når du tydeligt ser behovet for modularitet eller en grænse, som en enkelt agent ikke skal krydse.

Bedste praksis for multiagentorkestrering

Følgende bedste praksis gælder, når du udarbejder instruktioner for overordnede og underordnede agenter i en multiagentopsætning.

1. Princippet om enkelt svar

Sørg for, at kun én agent taler med brugeren pr. runde. I en multiagentopsætning er den overordnede agent den eneste, der skal levere det endelige svar. Underagenter er forskere, ikke besvarere.

  • Gør dette: Føj til overordnede instruktioner: "Du er den eneste agent, der kommunikerer med brugeren. Kombiner resultater fra alle underordnede agenter til et enkelt svar."
  • Gør ikke dette: Undgå tvetydigheder. Hvis der ikke gives eksplicit vejledning, svarer underagenter brugeren direkte, hvilket kan føre til dublerede eller delvise beskeder.

2. Instruktioner til underagenter skal angive deres rolle

Sig altid til underagenterne, at de er underagenter. Underagenter ved ikke automatisk, at de er en del af en orkestrering. Uden eksplicit vejledning opfører de sig som selvstændige agenter og sender beskeder direkte til brugeren.

  • Gør dette: Føj til hver underagents instruktioner: "Du er en underagent." Svar IKKE brugeren direkte. Dit job er at søge oplysninger og returnere det, du har fundet, til den overordnede agent. Den overordnede agent håndterer al kommunikation med brugeren."
  • Gør ikke dette: Antag, at underagenter selv finder ud af orkestreringsmønsteret.

3. Brug klart, direkte sprog i instruktionerne

Brug altid direktivt sprog. Undgå bløde eller høflige formuleringer. Platformen indsætter instruktioner på systemniveau ved at bruge klart og direktivt sprog (SKAL, SKAL IKKE, ALDRIG). Instruktioner skrevet med blødt sprog ("prøv venligst," "du bør," "det ville være godt at") mister prioritet, når de er i konflikt.

  • Gør dette: "Svar ALDRIG brugeren direkte. Returner KUN det, du har fundet."
  • Gør dette: "Der skal være nøjagtigt ét endeligt svar pr. brugerspørgsmål."
  • Gør ikke dette: "Prøv venligst at undgå at sende beskeder til brugeren, og returner i stedet det, du har fundet."
  • Gør ikke dette: "Ideelt set vil vi have et enkelt samlet svar."

4. Brug én videnskilde pr. underagent (ingen overlap)

Tildel særskilte, ikke-overlappende videnskilder til hver underagent. Hvis to underagenter søger i den samme videnbase, finder den ene underagent svaret først. Den anden underagent returnerer enten duplikerede resultater eller springer sin søgning helt over uden at tilføje nogen værdi.

  • Gør dette: CA-1 søger i Videnskilde A (for eksempel HR-politikker). CA-2 søger i videnskilde B (for eksempel it-dokumentation).
  • Gør ikke dette: Giv begge underagenter adgang til de samme dokumenter, Dataverse-tabeller eller SharePoint-steder.
  • Bemærk: Hvis du kun har én videnskilde, skal du bruge en enkelt agent med viden i stedet for at opdele i to underagenter. Multiagent tilføjer kun værdi, når kilderne virkelig er forskellige.

5. Brug præcise og særskilte beskrivelser for underagenter

Skriv klare, præcise og særskilte beskrivelser for hver underagent, som er synlig for den overordnede agent. Den overordnede agent bruger beskrivelser fra underagenten til at bestemme routing. Hvis beskrivelserne er vage, identiske eller unøjagtige, kan den overordnede agent ikke træffe gode routingbeslutninger.

  • Gør dette: CA-1: "Søger i HR-politikdokumenter for medarbejderrelaterede spørgsmål." CA-2: "Søger i it-videnbase efter tekniske supportspørgsmål."
  • Gør ikke dette: Giv begge agenter samme beskrivelse, når de betjener forskellige domæner.
  • Gør ikke dette: 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 den skal orkestrere. Sig ikke bare "brug underordnede agenter." De overordnede agenter har brug for eksplicitte instruktioner om mønsteret: kald agenter, vent på resultater, kombiner, og svar derefter.

  • Gør dette: "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 fund. 3. Kombiner resultaterne i ét samlet svar. 4. Giv præcis ét svar til brugeren. Underordnede agenter må ikke svare brugeren direkte."
  • Gør ikke dette: "Når brugeren stiller et spørgsmål, aktiveres underordnede agenter og indhenter svar fra begge kilder og giver et enkelt samlet svar." (For vagt. Instruktionen fortæller ikke underordnede agenter, at de skal være stille).

7. Inkluder direktivet "ingen direkte svar" i opgavedelegeringen

Selv med klare instruktioner til underagenter giver det ekstra sikkerhed at tilføje en forstærkende besked i den delegerede opgave.

  • Gør dette: Føj til den overordnede agents instruktioner: "Når du delegerer til en underordnet agent, skal du altid inkludere i opgaven: 'Returner kun dine fund. Svar ikke brugeren.'"
  • Gør ikke dette: Anvend udelukkende underagentens egne instruktioner. Opgavekonteksten giver underagenten flere signaler, der forstærker mønsteret.

8. Test med forespørgsler, der ikke matcher domæner

Test altid med spørgsmål, der falder uden for alle underagenters domæner. Denne test viser, om underagenter på en hensigtsmæssig måde returnerer "ingen oplysninger fundet", eller om de returnerer oplysninger, der kan være forkerte, går i stå eller sender forvirrende beskeder.

  • Gør dette: Test med forespørgsler uden for alle underagentens domæner (for eksempel, spørg om vejret, når agenterne 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.
  • Gør ikke dette: Test kun med de simpleste forespørgsler, der perfekt matcher én underagents domæne.

9. Foretræk at spørge frem for at informere, når du forventer opfølgning

Brug interaktioner med spørgsmål, når du forventer et svar fra brugeren. Brug kun oplysninger/afsendelse af svar ved endelige envejsbeskeder. Hvis agenten spørger brugeren om noget via en envejsbesked (oplysninger), går brugerens svar tilbage til den overordnede planlægger som en helt ny forespørgsel. I dette tilfælde er det bedre at fortsætte den samme samtale med underagenten.

  • Gør dette: Skriv instruktioner som: "Hvis du har brug for afklaring, så stil brugeren et spørgsmål, og vent på deres svar."
  • Gør ikke dette: Skriv instruktioner som: "Informer brugeren om mulighederne, og lad dem vælge." "Informer" signalerer en envejsbesked, mens "spørg" signalerer en tovejsudveksling.

Tjekliste til hurtig reference

# Check
1 Overordnede instruktioner angiver eksplicit "kun jeg svarer brugeren"
2 Alle underagentinstruktioner siger "svar ikke brugeren direkte"
3 Instruktioner anvender stærkt direktivt sprog (SKAL, ALDRIG, KUN)
4 Hver underagent har en entydige, ikke-overlappende videnskilde
5 Beskrivelser af underagenter er nøjagtige, særskilte og specifikke
6 Overordnede instruktioner definerer det fulde orkestreringsmønster (kald → vent → kombiner → svar)
7 Overordnet agent videregiver "ingen direkte svar" i forbindelse med en delegeret opgave
8 Testet med forespørgsler, der ikke matcher domæner
9 Skelnen mellem at spørge og at informere er korrekt i instruktionerne til underagenten
  • Last updated on