Utform emner som mini-agenter som unngår dupliserte meldinger

Note

Denne artikkelen beskriver egenskaper og atferd hos temaer med en samtaleutløser i standardselen. Lær hvordan du får tilgang til standardfunksjoner i Access standardagenter og agentflyter.

Denne artikkelen fokuserer på beste designpraksis for å unngå dupliserte meldinger. Dupliserte meldinger kommer fra konteksthull, så design starter med å forstå hvordan konteksten flyter. Se diagrammet i Context Distribution i standard harness for å forstå hvordan orkestreringslaget deler kontekst med hver komponent.

I standardharnessen kaller planleggeren temaer på samme måte som den kaller verktøy og agenter. Den leser hvert emnes beskrivelse for å avgjøre når det skal brukes, genererer temaets input fra sin aktive kontekst og fra brukeren, og leser temaets utdata når emnet avsluttes. Et tema med en klar beskrivelse, veldefinerte input og veldefinerte output oppfører seg som en mini-agent i planen: orkestreringslaget samler det temaet trenger, temaet kjører sin logikk, returnerer det det produserte, og orkestreringslaget formaterer og kommuniserer svaret til brukeren.

For brukeren føles en mini-agent samtalepreget. Brukeren kan snakke naturlig mens temaet samler inn de innspillene det trenger, stille oppfølgingsspørsmål og få rike svar tilbake fra agenten.

Tips

I standard harness, hold deterministisk logikk inne i temaet og overlat brukerkommunikasjonen til orkestreringslaget. Samle inn verdiene emnet trenger som input før det kjører, og returner det det produserte som output etter at det kjører.

Navngi og beskriv temaet slik at orkestreringslaget kan rute til det

Orkestreringslaget bruker emnenavnet og beskrivelsen for å rute forespørsler til emnet. Skriv begge deler for orkestreringslaget. Gi temaet et klart, spesifikt navn som beskriver hva det gjør.

Skriv beskrivelsen i to deler. Forklar først når du bør bruke temaet. For det andre, forklar kort hva man skal gjøre basert på temaets output, inkludert hvordan orkestreringslaget skal rute forespørsler og håndtere resultater etter at temaet er kjørt. Ikke beskriv temaets interne skjermer eller steg.

For eksempel, bruk følgende beskrivelse for et emne som svarer på forespørsler om kontosaldo og rapporterer tilbake med en answered utdata:

This topic handles account balance requests. 
If its answered output is true, the user has already received their response and it should not be answered again.

Samle inn input før temaet sendes

Gi temaet en tilbakemelding for hver verdi det trenger. Orkestreringslaget kan samle disse verdiene fra sin aktive kontekst, og fra brukeren på en samtalemessig måte, før temaet kjøres. En input leveres til en variabel som temaets logikk deretter bruker.

Bruk innstillingene for inndatanavn, beskrivelse, entitet og validering for å hjelpe orkestreringslaget med å fylle en inndata nøyaktig:

  • Inndatanavnet forteller orkestreringslaget hva som samles inn, og brukes til å danne spørsmålet om orkestreringslaget må spørre brukeren om verdi. Navngi det etter verdi, ikke mekanismen. For eksempel, navngi en input The user's request about... i stedet for OData filter, slik at orkestreringslaget ikke ber en bruker om å skrive en spørring.

  • Inndatabeskrivelsen er en prompt til orkestreringslaget, ikke en etikett for brukeren. Bruk den til å fortelle orkestreringslaget hvordan det skal tolke, begrense eller transformere verdien før temaet mottar den. Orkestreringslaget kan fylle en input fra samtalen, fra en tidligere output, eller fra brukerprofildata. Den kan velge fra et sett med verdier, anvende noen begrensninger og skrive forespørsler basert på skjemainformasjon.

    Inndatabeskrivelser kan til og med instruere orkestreringslaget til å bygge en verdi i et spesifikt format. For eksempel kan et emne som filtrerer en liste ta en input hvis beskrivelse forteller orkestreringslaget hvordan filteret skal bygges ut fra brukerens forespørsel, inkludert tilgjengelige felt, spørringssyntaks og noen få eksempler.

  • Entiteter setter tillatt type og område for en input, slik at kun gyldige verdier når emnets logikk.

  • Avansert validering og betinget logikk, inkludert Power Fx, fungerer som deterministiske kontroller. De kan hindre at et innlegg blir fylt ut, eller hindre temaet i å handle, når en betingelse ikke er oppfylt.

Deterministiske inputkontroller er like pålitelige som kode, så forretningsregler og compliance-begrensninger respekteres selv når resten av planen er generert.

Hold logikken og sikkerhetsrutene i temaet

Hold temaets deterministiske arbeid inne i emnet: trinnene det kjører, beregningene det gjør, og reglene det håndhever. Skaperen utøver kontroll og anvender avgjørende forretningslogikk som fungerer på samme måte hver gang, som et verktøy.

Returnerer resultater som utganger, ikke meldinger til brukeren

Når temaet er ferdig, returner det det produserte som utganger slik at orkestreringslaget kan bruke det og bestemme hvordan det skal svare. Foretrekk denne tilnærmingen fremfor å la emnet sende direkte melding til brukeren. Et tema som skriver til brukeren mens orkestreringslaget også svarer, er en vanlig kilde til dupliserte meldinger – orkestreringslaget vet ikke at temaet allerede har svart.

Important

Et tema som ikke gir noen resultater er et rødt flagg. Hvis et emne svarte brukeren, samlet inn en verdi, eller viste et kort, men ikke gir noe tilbake, kan ikke orkestreringslaget se hva som skjedde og kan svare på samme forespørsel igjen. Denne oppførselen er den vanligste årsaken til dupliserte meldinger fra emner.

Følgende testede resultater anbefales sterkt som pålitelige mønstre for kontekst og kommunikasjon. De gjelder enten temaet svarer brukeren direkte eller returnerer all informasjon til orkestreringslaget for å svare.

Utdata Beskrivelse Slik brukes den
answered Sant hvis brukeren allerede har mottatt et tilfredsstillende svar på forespørselen sin innenfor dette emnet. Sett det til true i emnet når det svarer eller viser resultatet. Se eksempelet på toppnivåinstruksjonen som følger, som sikrer at orkestreringslaget behandler den delen av forespørselen som besvart og ikke gjentar den.
choiceReceived Sant hvis brukeren allerede har gjort sitt valg innenfor dette emnet. Sett det til true når brukeren har gjort et valg, for eksempel ved å velge en kortknapp. Orkestreringslaget stiller ikke spørsmålet på nytt.
balanceValue Verdien emnet hentet og allerede gitt til brukeren. Sett den til de viktige dataene temaet hentet, og navngi utdataene for de dataene. Orkestreringslaget gjenbruker det fra kontekst i stedet for å hente det på nytt.
messageSummary En kort oppsummering av det som allerede var vist brukeren, for å holde det i kontekst. Sett det når en melding inneholder informasjon planen trenger senere. Orkestreringslaget er bevisst på hva brukeren ble fortalt og gjentar eller motsier det ikke.

Utgangene alene er tilstrekkelige for eldre modeller. Nyere modeller trenger også en toppnivåinstruksjon som forteller orkestreringslaget å sjekke utgangene før svar.

Denne eksempelinstruksjonen på toppnivå er et testet fungerende eksempel. Rediger og tilpass det etter behov.

Når et tema eller en agent blir kalt, se alltid etter det 'besvarte' boolske utgangspunktet før du bestemmer deg for hva du skal svare. Emner og agenter har sin egen kommunikasjonskanal med brukeren. Hvis 'besvart' er sant, anta alltid at forespørselen er besvart riktig ved bruk av minst én av utdatavariablene, og sjekk hvilke basert på utdatabeskrivelsen. Ikke gi en klønete bekreftelse på det besvarte innholdet. Gi kun de ubesvarte resultatene, og fortsett samtalen naturlig med neste steg.

Begrepet kanal refererer ikke til en integrasjonskanal. Det er en prompting-enhet som forteller orkestreringslaget at brukeren kanskje allerede har sett svaret gjennom en annen komponent. Avhengig av agentens modell kan det være mer effektivt å plassere en lignende instruksjon i agentens egne instruksjoner. Les mer i Design en robust toppnivåinstruksjon for å unngå gjentatte meldinger.

Hvis temaet må vise noe orkestreringslaget ikke kan gjenskape, for eksempel et Adaptive Card, la temaet vise det og returnere utdata som angir at tilstanden er besvart.

Tips

Lær mer om dupliserte meldinger og svartilstandsutdata i Design beste praksis for å unngå dupliserte meldinger. Lær hvordan kontekst beveger seg mellom orkestreringslaget og et tema i kontekstdistribusjon i standardharnessen.

Samle svar når et tema fortsatt trenger brukerinnspill

Noen emner må stille et spørsmål eller vise et kort, for eksempel for å samle et valg med knapper. Denne designtilnærmingen er gyldig. Husk at et åpent spørsmål eller kort må løses når brukeren endrer kurs før du svarer.

Før du legger til en spørsmålsnode, vurder om verdien kan samles inn som input i stedet. Når du har en spørsmålsnode, håndter tilfellet der brukeren ber om noe annet mens spørsmålet fortsatt er åpent. Lær mer i Et åpent spørsmål eller kortretur etter at en annen forespørsel ble håndtert.

Eksempel: Forhindre at et adaptivt kortvalg blir spurt om på nytt

Et tema ber brukeren velge en kategori med et adaptivt kort:

Hvilken kategori er problemet ditt?

[Fakturering] [Teknisk] [Konto]

Orkestreringslaget mottar spørsmålsteksten gjennom samtalehistorikken, men ikke det faktum at kortet ble vist eller at en knapp ble valgt av brukeren. Etter at brukeren har valgt en knapp, kan orkestreringslaget stille det samme spørsmålet på nytt i klartekst.

Design temaet slik at det rapporterer handlingen for å unngå dette problemet:

Utdata Type Hva skal man sette det til
answered Sann/usann Sant når temaet allerede viste svaret eller prompten til brukeren.
choiceReceived Sann/usann Sant når brukeren allerede har gjort et valg.
selectedCategory Tekstmelding Når et valg mottas, inneholder denne utdataen kategorien brukeren valgte.

Legg til en instruksjon i emnebeskrivelsen slik at orkestreringslaget vet hva en vellykket kjøring betyr. Stol på toppnivåinstruksjonen i Return-resultater som output, ikke meldinger til brukeren, slik at en nyere modell sjekker disse outputene før den spør igjen.

Beste praksis for temaer i standardharnessen

  • Gi temaet et klart, spesifikt navn og en beskrivelse som sier når det skal brukes (og eventuelt hva man skal gjøre etter at det er kjørt).
  • Legg til en input for hver verdi temaet trenger, og skriv inputbeskrivelsen som en prompt til orkestreringslaget.
  • Gi inndata navn etter verdien de inneholder, siden navnet danner spørsmålet dersom orkestreringslaget må spørre brukeren.
  • Hold deterministisk logikk og rekkverk, som entiteter, validering og Power Fx, inne i temaet.
  • Unngå å sende meldinger direkte til brukeren i emnet. Bruk en meldingsnode, spørsmålsnode eller Adaptive Card kun når det er nødvendig.
  • Returner resultatene som utdata, inkludert utdata for svartilstand.
  • Last updated on