Del via

Udforsk mønstre for orkestrering af flere agenter

Generativ orkestrering understøtter også multi-agentsystemer, hvor én agent kalder en anden agent. At dele problemer op i flere specialiserede agenter kan forbedre modularitet, skalerbarhed og håndterbarhed.

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.

Best practice: Hold inline-agenter fokuserede på ét ansvar og velafprøvede.

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. For eksempel en IT-agent, der ringer til en salgsagent for at få en pris. Forbundne agenter muliggør modularitet, domæneseparation og kan omgå planbegrænsninger. 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. Denne overdragelse sker normalt, når brugerens hensigt matcher den tilknyttede 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 tilknyttede agent som et "værktøj" med en beskrivelse, set fra forælderens perspektiv.

  • Dataoverlevering: Du skal styre dataoverdragelsen. Beslut hvilken kontekst fra forælderen der skal gives videre til den tilknyttede agent. Copilot Studio videregiver samtalehistorikken som standard, når en agent ringer til en anden, så den tilknyttede agent ved, hvad der allerede er blevet diskuteret. 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
  • Du planlægger at genbruge den funktion i mange forskellige hovedagenter (så det er som en serviceagent)

Hvis ingen af disse betingelser gælder, kan et simpelt emne (inline) være tilstrækkeligt i stedet for en fuldt forbundet agent. Separate agenter medfører overhead – en lidt længere eksekveringstid på grund af kontekstskift og kompleksitet ved vedligeholdelse af flere bots. Så brug dem med omhu. En praktisk tilgang er at starte med én agent og kun dele op i flere agenter, når man tydeligt ser et behov for modularitet eller en grænse, som ikke bør krydses af én agent.

  • Last updated on