Designa ämnen som mini-agenter som undviker dubblettmeddelanden

Note

Denna artikel beskriver egenskaper och beteenden hos ämnen med en konversationsutlösare i standardselen. Lär dig hur du får tillgång till standardfunktioner i Access standardagenter och agentflöden.

Den här artikeln fokuserar på bästa designpraxis för att undvika dubblettmeddelanden. Dubbla meddelanden uppstår på grund av brister i kontexten, så utformningen börjar med att förstå hur kontexten förs vidare. Se diagrammet i Context distribution i standardharnessen för att förstå hur orkestreringslagret delar kontext med varje komponent.

I standardkonfigurationen anropar planeraren topics på samma sätt som den anropar verktyg och agenter. Den läser varje ämnes beskrivning för att avgöra när ämnet ska användas, genererar ämnets indata från dess aktiva kontext och från användaren, och läser ämnets utdata när ämnet är klart. Ett ämne med en tydlig beskrivning, väldefinierade indata och väldefinierade utdata beter sig som en mini-agent i planen: orkestreringslagret samlar in vad ämnet behöver, ämnet kör sin logik, returnerar det det producerade, och orkestreringslagret formaterar och kommunicerar svaret till användaren.

För användaren känns en mini-agent konversationell. Användaren kan prata naturligt medan ämnet samlar in de indata det behöver, ställa följdfrågor och få rika svar från agenten.

Tip

I standardkonfigurationen ska deterministisk logik hållas i ämnet och kommunikationen med användaren läggas på orkestreringslagret. Samla in de värden ämnet behöver som indata innan det körs, och returnera vad det producerade som utdata efter att det körts.

Namnge och beskriv ämnet så att orkestreringslagret kan dirigera till det

Orkestreringslagret använder ämnesnamnet och beskrivningen för att dirigera förfrågningar till ämnet. Skriv båda delarna för orkestreringslagret. Ge ämnet ett tydligt, specifikt namn som beskriver vad det gör.

Skriv beskrivningen i två delar. Förklara först när du ska använda ämnet. För det andra, förklara kort vad man ska göra baserat på ämnets utdata, inklusive hur orkestreringslagret ska routa förfrågningar och hantera resultat efter att ämnet körts. Beskriv inte ämnets interna skärmbilder eller steg.

Använd till exempel följande beskrivning för ett ämne som besvarar förfrågningar om kontosaldo och returnerar utdata med answered:

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.

Samla in uppgifter innan ämnet körs

Ange ett värde för varje indata som ämnet behöver. Orkestreringslagret kan samla in dessa värden från sin aktiva kontext och från användaren genom en konversation innan ämnet startas. En indata levereras till en variabel som ämnets logik sedan använder.

Använd inställningarna för inmatningsnamn, beskrivning, entitet och validering för att hjälpa orkestreringslagret att fylla en indata korrekt:

  • Inmatningsnamnet berättar för orkestreringslagret vad som samlas in, och det används för att formulera frågan om orkestreringslagret måste fråga användaren om värdet. Namnge det efter värdet, inte mekanismen. Till exempel, namnge en indata The user's request about... istället för OData filter, så att orkestreringslagret inte ber en användare att skriva en fråga.

  • Inmatningsbeskrivningen är en prompt till orkestreringslagret, inte en etikett för användaren. Använd den för att tala om för orkestreringslagret hur det ska tolka, begränsa eller transformera värdet innan ämnet tar emot det. Orkestreringslagret kan fylla i ett indatafält från konversationen, från tidigare utdata eller från användarprofildata. Den kan välja från en uppsättning värden, tillämpa vissa begränsningar och skriva frågor baserade på schemainformation.

    Inmatningsbeskrivningar kan till och med instruera orkestreringslagret att bygga ett värde i ett specifikt format. Till exempel kan ett ämne som filtrerar en lista ta en indata vars beskrivning berättar för orkestreringslagret hur filter ska konstrueras utifrån användarens begäran, inklusive tillgängliga fält, frågesyntax och några exempel.

  • Entiteter sätter tillåten typ och intervall för en indata, så att endast giltiga värden når ämnets logik.

  • Avancerad validering och villkorlig logik, inklusive Power Fx, fungerar som deterministiska kontroller. De kan förhindra att ett indatafält fylls i, eller att ämnet agerar, när ett villkor inte är uppfyllt.

Deterministiska inmatningskontroller är lika tillförlitliga som kod, så affärsregler och efterlevnadskrav respekteras även när resten av planen genereras.

Behåll logiken och avgränsningarna inom ämnet

Behåll ämnets deterministiska arbete inom ämnet: stegen det utförs, beräkningarna det gör och de regler det upprätthåller. Skaparen utövar kontroll och tillämpar avgörande affärslogik som fungerar på samma sätt varje gång, som ett verktyg.

Returnera resultat som utdata, inte meddelanden till användaren

När ämnet är klart, returnera det som producerats som utgångar så att orkestreringslagret kan använda det och bestämma hur det ska svara. Använd helst den här metoden i stället för att låta ämnet skicka meddelanden direkt till användaren. Ett ämne som skriver till användaren medan orkestreringslagret också svarar är en vanlig källa till dubblettmeddelanden – orkestreringslagret vet inte att ämnet redan svarat.

Viktigt!

Ett ämne som inte ger några utdata är en varningssignal. Om ett ämne besvarade användarens fråga, samlade in ett värde eller visade ett kort men inte returnerar något, kan orkestreringslagret inte se vad som hände och kan svara på samma förfrågan igen. Detta beteende är den vanligaste orsaken till duplicerade meddelanden från ämnen.

Följande testade resultat rekommenderas starkt som tillförlitliga mönster för kontext och kommunikation. De gäller oavsett om ämnet besvarar användarens fråga direkt eller returnerar all information till orkestreringslagret så att det kan besvara frågan.

Output Description Så här använder du
answered Sant om användaren redan har fått ett tillfredsställande svar på sin förfrågan inom detta ämne. Sätt det till sant i ämnet när det svarar eller visar resultatet. Se exempelinstruktionen på toppnivå som följer, vilket säkerställer att orkestreringslagret behandlar den delen av förfrågan som besvarad och inte upprepar den.
choiceReceived Sant om användaren redan har gjort sitt val inom detta ämne. Sätt det till true när användaren gör ett val, till exempel genom att välja en kortknapp. Orkestreringslagret ställer inte frågan igen.
balanceValue Värdet som ämnet hämtat och redan gett användaren. Ställ in den på de viktiga datauppgifter som ämnet har hämtat, och ge utdata för dessa data ett namn. Orkestreringslagret återanvänder det från kontexten istället för att hämta det igen.
messageSummary En kort sammanfattning av vad som redan visats för användaren, för att hålla det i kontext. Ställ in det när ett meddelande innehåller information som planen behöver senare. Orkestreringslagret håller sig medvetet om vad användaren fått höra och upprepar eller motsäger det inte.

Utgångarna i sig är tillräckliga för äldre modeller. Nyare modeller behöver också en toppnivåinstruktion som säger åt orkestreringslagret att kontrollera utgångarna innan de svarar.

Detta exempel på en instruktion på toppnivå är ett testat och fungerande exempel. Redigera och anpassa det efter behov.

När något ämne eller agent anropas, leta alltid efter det 'besvarade' booleska resultatet innan du bestämmer vad du ska svara. Ämnen och agenter har sin egen kommunikationskanal med användaren. Om 'svarat' är sant, anta alltid att förfrågan har besvarats korrekt med minst en av utdatavariablerna, och kontrollera vilka baserat på utdatabeskrivningen. Ge inte en obekväm bekräftelse på det besvarade innehållet. Ge bara de obesvarade resultaten och fortsätt samtalet naturligt med nästa steg.

Begreppet kanal syftar inte på en integrationskanal. Det är en prompt-enhet som talar om för orkestreringslagret att användaren kanske redan har sett svaret genom en annan komponent. Beroende på agentens modell kan det vara mer effektivt att placera en liknande instruktion i agentens egna instruktioner. Läs mer i Design, en robust överordnad instruktion för att undvika upprepade meddelanden.

Om avsnittet måste visa något som orkestreringslagret inte kan återge, till exempel ett adaptivt kort, låter du avsnittet visa det och returnera utdata med statusen besvarad.

Tip

Lär dig mer om dubblettmeddelanden och utdata för svarat tillstånd i bästa praxis för design för att undvika dubblettmeddelanden. Lär dig hur kontext rör sig mellan orkestreringslagret och ett ämne i Context distribution i standardharnessen.

Samla in svar när ett ämne fortfarande behöver användarinput

Vissa ämnen måste ställa en fråga eller visa ett kort, till exempel för att låta användaren göra ett val med knappar. Denna designmetod är giltig. Tänk på att en öppen fråga eller ett kort måste lösas när användaren ändrar kurs innan man svarar.

Innan du lägger till en frågenod, överväg om värdet kan samlas in som en indata istället. När du har en frågenod, hantera fallet där användaren frågar efter något annat medan frågan fortfarande är öppen. Läs mer i En öppen fråga eller kortretur efter att en annan begäran hanterats.

Exempel: Förhindra att ett Adaptivt Kortval omfrågas

Ett ämne ber användaren välja en kategori med ett Adaptivt Kort:

Vilken kategori är ditt problem?

[Fakturering] [Tekniskt] [Konto]

Orkestreringslagret tar emot frågetexten via konversationshistoriken, men inte det faktum att kortet visades eller att användaren tryckte på en knapp. Efter att användaren valt en knapp kan orkestreringslagret ställa samma fråga igen i klartext.

Utforma ämnet så att det rapporterar sin åtgärd för att undvika det här problemet:

Output Type Vad man ska ställa in det på
answered True/False Sant när ämnet redan visade svaret eller prompten för användaren.
choiceReceived True/False Sant när användaren redan gjort ett val.
selectedCategory Text När ett val tas emot innehåller denna utdata den kategori användaren valde.

Lägg till en instruktion i ämnesbeskrivningen så att orkestreringslagret vet vad en lyckad körning betyder. Lita på toppnivåinstruktionen i Return-resultat som utdata, inte meddelanden till användaren så att en nyare modell kontrollerar dessa utdata innan den frågar igen.

Bästa metoder för avsnitt i Standard Harness

  • Ge ämnet ett tydligt, specifikt namn och en beskrivning som anger när det ska användas (och eventuellt vad man ska göra efter att det kört).
  • Lägg till ett indatafält för varje värde som ämnet behöver, och skriv beskrivningen av indatafältet som en prompt till orkestreringslagret.
  • Namnge indata utifrån vilket värde de innehåller, eftersom namnet formulerar frågan i de fall orkestreringslagret måste fråga användaren.
  • Håll deterministisk logik och skyddsräcken, såsom entiteter, validering och Power Fx, inom ämnet.
  • Undvik att skicka meddelanden direkt till användaren inom ämnet. Använd en meddelandenod, frågenod eller adaptivt kort endast när det är nödvändigt.
  • Returnera resultaten som utdata, inklusive utdata för svarstillstånd.
  • Last updated on