Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Bemærkning
Denne artikel beskriver egenskaber og adfærd af emner med en samtaleudløser i standardselen. Lær, hvordan du får adgang til standardfunktioner i Access standardagenter og agentflows.
Denne artikel fokuserer på designbedste praksis for at undgå duplikerede beskeder. Duplikerede beskeder kommer fra konteksthuller, så design starter med at forstå, hvordan konteksten flyder. Se diagrammet i Context distribution i standardharnessen for at forstå, hvordan orkestreringslaget deler kontekst med hver komponent.
I standardharnesset kalder planlæggeren emner på samme måde, som den kalder værktøjer og agenter. Den læser hvert emnes beskrivelse for at beslutte, hvornår emnet skal bruges, genererer emnets input fra dets aktive kontekst og fra brugeren, og læser emnets output, når emnet er færdigt. Et emne med en klar beskrivelse, veldefinerede input og veldefinerede output opfører sig som en mini-agent i planen: orkestreringslaget indsamler, hvad emnet har brug for, emnet kører sin logik, returnerer det, det producerede, og orkestreringslaget formaterer og kommunikerer svaret til brugeren.
For brugeren føles en mini-agent samtaleagtig. Brugeren kan tale naturligt, mens emnet samler de nødvendige input, stille opfølgende spørgsmål og få rige svar fra agenten.
Tip
I standardharnessen skal deterministisk logik holdes inde i emnet og brugerkommunikationen overlades til orkestreringslaget. Indsaml de værdier, emnet har brug for som input, før det kører, og returnér det, det producerede som output, efter det kører.
Navngiv og beskriv emnet, så orkestreringslaget kan rute til det
Orkestreringslaget bruger emnenavnet og beskrivelsen til at dirigere anmodninger til emnet. Skriv begge til orkestreringslaget. Giv emnet et klart, specifikt navn, der beskriver, hvad det gør.
Skriv beskrivelsen i to dele. Forklar først, hvornår du skal bruge emnet. For det andet, forklar kort, hvad man skal gøre baseret på emnets output, herunder hvordan orkestreringslaget skal rute anmodninger og håndtere resultater efter emnets kørsel. Beskriv ikke emnets interne skærme eller trin.
For eksempel kan følgende beskrivelse bruges til et emne, der besvarer kontosaldoanmodninger og rapporterer tilbage med et answered output:
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.
Indsaml input, før emnet kører
Giv emnet input til hver værdi, det har brug for. Orkestreringslaget kan indsamle disse værdier fra sin aktive kontekst og fra brugeren på en samtalemæssig måde, før emnet kører. Et input leveres til en variabel, som emnets logik derefter bruger.
Brug indstillingerne for inputnavn, beskrivelse, entitet og validering for at hjælpe orkestreringslaget med at udfylde et input nøjagtigt:
Inputnavnet fortæller orkestreringslaget, hvad der indsamles, og det bruges til at danne spørgsmålet om, hvorvidt orkestreringslaget skal bede brugeren om værdien. Navngiv det efter værdien, ikke mekanismen. For eksempel kan du navngive et input
The user's request about...i stedet forOData filter, så orkestreringslaget ikke beder brugeren om at skrive en forespørgsel.Inputbeskrivelsen er en prompt til orkestreringslaget, ikke en etiket til brugeren. Brug den til at fortælle orkestreringslaget, hvordan værdien skal fortolkes, begrænses eller transformeres, før emnet modtager den. Orkestreringslaget kan udfylde et input fra samtalen, fra et tidligere output eller fra brugerprofildata. Den kan vælge fra et sæt værdier, anvende nogle begrænsninger og skrive forespørgsler baseret på skema-information.
Inputbeskrivelser kan endda instruere orkestreringslaget i at bygge en værdi i et bestemt format. For eksempel kan et emne, der filtrerer en liste, tage et input, hvis beskrivelse fortæller orkestreringslaget, hvordan filteret skal konstrueres ud fra brugerens anmodning, inklusive de tilgængelige felter, forespørgselssyntaksen og nogle få eksempler.
Entiteter sætter den tilladte type og interval for et input, så kun gyldige værdier når emnets logik.
Avanceret validering og betinget logik, inklusive Power Fx, fungerer som deterministiske kontroller. De kan forhindre et input i at blive udfyldt, eller forhindre emnet i at handle, når en betingelse ikke er opfyldt.
Deterministiske inputkontroller er lige så pålidelige som kode, så forretningsregler og overholdelseskrav respekteres, selv når resten af planen genereres.
Hold logikken og sikkerhedsforanstaltningerne i emnet
Hold emnets deterministiske arbejde inde i emnet: de trin, det udfører, de beregninger det foretager, og de regler, det håndhæver. Skaberen udøver kontrol og anvender afgørende forretningslogik, der kører på samme måde hver gang, som et værktøj.
Returner resultater som output, ikke beskeder til brugeren
Når emnet er afsluttet, skal du returnere det output, det genererede, så orkestreringslaget kan bruge det og afgøre, hvordan der skal svares. Foretrækker denne tilgang frem for at lade emnet sende direkte besked til brugeren. Et emne, der skriver til brugeren, mens orkestreringslaget også svarer, er en almindelig kilde til dubletter – orkestreringslaget ved ikke, at emnet allerede har svaret.
Important
Et emne, der ikke returnerer nogen output, er et advarselstegn. Hvis et emne svarede brugeren, indsamlede en værdi eller viste et kort, men ikke returnerer noget, kan orkestreringslaget ikke se, hvad der skete, og kan svare på den samme anmodning igen. Denne adfærd er den mest almindelige årsag til duplikerede beskeder fra emner.
Følgende testede output anbefales kraftigt som pålidelige mønstre for kontekst og kommunikation. De gælder, uanset om emnet svarer brugeren direkte eller returnerer al information til orkestreringslaget for at besvare.
| Resultat | Beskrivelse | Sådan bruger du |
|---|---|---|
answered |
Det er sandt, hvis brugeren allerede har modtaget et tilfredsstillende svar på deres anmodning inden for dette emne. | Sæt den til true på emnet, når der svares, eller resultatet vises. Se eksempelet på topniveau-instruktionen, der følger, som sikrer, at orkestreringslaget behandler den del af forespørgslen som besvaret og ikke gentager den. |
choiceReceived |
Det er sandt, hvis brugeren allerede har truffet deres valg inden for dette emne. | Sæt det til sand, når brugeren har valgt noget, for eksempel ved at vælge en kortknap. Orkestreringslaget stiller ikke spørgsmålet igen. |
balanceValue |
Den værdi, emnet har hentet og allerede givet til brugeren. | Sæt den til de vigtige data, emnet hentede, og navngiv outputtet for de data. Orkestreringslaget genbruger det fra kontekst i stedet for at hente det igen. |
messageSummary |
Et kort resumé af det, der allerede var vist brugeren, for at holde det i kontekst. | Indsæt det, når en besked indeholder information, som planen har brug for senere. Orkestreringslaget forbliver opmærksom på, hvad brugeren blev fortalt, og gentager eller modsiger det ikke. |
Udgangene alene er tilstrækkelige for ældre modeller. Nyere modeller kræver også en topniveau-instruktion, der fortæller orkestreringslaget at tjekke outputtene før svar.
Denne eksempelinstruktion på topniveau er et testet fungerende eksempel. Rediger og tilpas det efter behov.
Når et emne eller en agent bliver kaldt, skal du altid lede efter det 'besvarede' booleske output, før du beslutter, hvad du vil svare. Emner og agenter har deres egen kommunikationskanal med brugeren. Hvis 'besvaret' er sandt, antag altid, at anmodningen er blevet besvaret korrekt ved brug af mindst én af outputvariablerne, og tjek hvilke baseret på outputbeskrivelsen. Giv ikke en akavet anerkendelse af det besvarede indhold. Giv kun de ubesvarede resultater, og fortsæt samtalen naturligt med næste skridt.
Begrebet kanal refererer ikke til en integrationskanal. Det er en prompting-enhed, der fortæller orkestreringslaget, at brugeren måske allerede har set svaret gennem en anden komponent. Afhængigt af agentens model kan det være mere effektivt at placere en lignende instruktion i agentens egne instruktioner. Lær mere i Design, en robust topniveau-instruktion til at undgå gentagne beskeder.
Hvis emnet skal vise noget, som orkestreringslaget ikke kan gengive, f.eks. et Adaptive Card, så lad emnet vise det og returner et output i besvaret tilstand.
Tip
Få mere at vide om dublerede meddelelser og output i besvaret tilstand i Bedste designpraksisser til at undgå dublerede meddelelser. Lær, hvordan konteksten bevæger sig mellem orkestreringslaget og et emne i Context distribution i standardharnessen.
Indsaml svar, når et emne stadig kræver brugerinput
Nogle emner skal stille et spørgsmål eller vise et kort, for eksempel for at samle et valg med knapper. Denne designtilgang er gyldig. Husk, at et åbent spørgsmål eller kort skal løses, når brugeren ændrer kurs, før man svarer.
Før du tilføjer en spørgsmålsnode, bør du overveje, om værdien kan indsamles som input i stedet. Når du har en spørgsmålsnode, håndter det tilfælde, hvor brugeren beder om noget andet, mens spørgsmålet stadig er åbent. Læs mere i Et åbent spørgsmål eller kortretur efter en anden anmodning blev håndteret.
Eksempel: Forhindre, at et Adaptivt Kortvalg bliver spurgt igen
Et emne beder brugeren om at vælge en kategori med et Adaptivt Kort:
Hvilken kategori er dit problem?
[Fakturering] [Teknisk] [Konto]
Orkestreringslaget modtager spørgsmålsteksten gennem samtalehistorikken, men ikke det faktum, at kortet blev vist, eller at brugeren har trykket på en knap. Efter brugeren har valgt en knap, kan orkestreringslaget stille det samme spørgsmål igen i klartekst.
Design emnet til at rapportere dets handling for at undgå dette problem:
| Resultat | Type | Hvad skal man sætte den til |
|---|---|---|
answered |
Sandt/Falsk | Sandt, når emnet allerede viste svaret eller prompten til brugeren. |
choiceReceived |
Sandt/Falsk | Det er sandt, når brugeren allerede har truffet et valg. |
selectedCategory |
Tekst | Når et valg modtages, indeholder dette output den kategori, brugeren har valgt. |
Tilføj en instruktion til emnebeskrivelsen, så orkestreringslaget ved, hvad et vellykket run betyder. Stol på topniveau-instruktionen i Return-resultater som output, ikke beskeder til brugeren, så en nyere model tjekker disse output, før den spørger igen.
Bedste praksis for emner i standardharnessen
- Giv emnet et klart, specifikt navn og en beskrivelse, der angiver, hvornår det skal bruges (og eventuelt hvad man skal gøre, når det kører).
- Tilføj et input for hver værdi, emnet har brug for, og skriv inputbeskrivelsen som en prompt til orkestreringslaget.
- Navngiv input for den værdi, de har, da navnet udgør spørgsmålet, hvis orkestreringslaget skal spørge brugeren.
- Hold deterministisk logik og sikkerhedsforanstaltninger, såsom entiteter, validering og Power Fx, inden for emnet.
- Undgå at skrive direkte til brugeren inden for emnet. Brug kun en beskednode, spørgsmåls-node eller Adaptive Card, når det er nødvendigt.
- Returnér resultater som outputværdier, herunder en outputværdi for tilstanden "besvaret".
Relaterede oplysninger
- Kontekstfordeling i standardharnessen
- Design bedste praksis for at undgå dublerede beskeder
- Design subagenter, der undgår dublerede beskeder
- Fejlsøg dublerede beskeder og ubesvarede svar
- Følg bedste praksis for emneforfattere
- Styr emneinddata og emneuddata
- Orkestrere agentfunktionsmåde med generativ AI
- Anvend generative orkestreringsmuligheder