Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
De state binnen een agent volgt dezelfde paradigma's als moderne webtoepassingen. De SDK voor agenten biedt enkele abstracties om statusbeheer eenvoudiger te maken.
Net als bij web-apps is een agent inherent toestandloos. Een ander exemplaar van uw agent kan een bepaalde beurt in het gesprek afhandelen. Voor sommige agents heeft deze eenvoud de voorkeur: de agent kan werken zonder aanvullende informatie of de vereiste informatie is gegarandeerd binnen het binnenkomende bericht. Voor anderen is de context (zoals waar het gesprek is gebleven of gegevens die eerder over de gebruiker zijn ontvangen) nodig, zodat de agent een nuttig gesprek kan voeren.
Waarom heb ik toestand nodig?
Door de status te behouden kan uw agent zinvollere gesprekken voeren door bepaalde dingen over een gebruiker of gesprek te onthouden. Als u bijvoorbeeld eerder met een gebruiker hebt gepraat, kunt u eerdere informatie over die gebruiker opslaan, zodat u er niet opnieuw om hoeft te vragen. State bewaart ook gegevens langer dan de huidige beurt, zodat uw agent informatie bewaart tijdens een gesprek met meerdere beurten.
Aangezien het betrekking heeft op agents, zijn er enkele lagen voor het gebruik van state: de opslaglaag, statebeheer en AgentApplication.
Opslaglaag
Beginnend bij de back-end, waar de statusinformatie daadwerkelijk wordt opgeslagen, is de opslaglaag. U kunt dit beschouwen als uw fysieke opslag, zoals in-memory, Azure of een server van derden.
De SDK voor agenten bevat enkele implementaties voor de opslaglaag:
Geheugenopslag biedt in-memory opslag voor testdoeleinden. Gegevensopslag in het geheugen is alleen bedoeld voor lokale tests omdat deze opslag vluchtig en tijdelijk is. De gegevens worden gewist telkens wanneer de agent opnieuw wordt opgestart.
Azure Blob Storage maakt verbinding met een Azure Blob Storage-objectdatabase.
De gepartitioneerde Azure Cosmos DB-opslag maakt verbinding met een gepartitioneerde Cosmos DB NoSQL-database.
Zie Overzicht van SDK-opslag voor agenten voor instructies over het maken van verbinding met andere opslagopties
Toestandbeheer
Toestandsbeheer automatiseert het lezen en schrijven van de toestand van uw agent naar de onderliggende opslaglaag. De state wordt opgeslagen als state-eigenschappen, die effectief sleutel-waardeparen zijn die uw agent kan lezen en schrijven via het statebeheerobject, zonder dat u zich zorgen hoeft te maken over de specifieke onderliggende implementatie. Deze statuseigenschappen bepalen hoe die informatie wordt opgeslagen. Wanneer u bijvoorbeeld een eigenschap ophaalt die u hebt gedefinieerd als een specifieke klasse of een specifiek object, weet u hoe die gegevens worden gestructureerd.
Deze toestandseigenschappen worden samengevoegd in afgebakende verzamelingen 'buckets', die enkel dienen om deze eigenschappen te ordenen. De SDK bevat drie van deze buckets:
- Gebruikersstatus
- Gespreksstatus
Al deze buckets zijn subklassen van de agentstatusklasse, die kunnen worden afgeleid om andere typen buckets met verschillende scopes te definiëren.
Deze vooraf gedefinieerde buckets zijn gericht op een bepaalde zichtbaarheid, afhankelijk van de bucket:
- De gebruikersstatus is beschikbaar in elke interactie waarin de agent met die gebruiker op dat kanaal converseert, ongeacht het gesprek
- De gespreksstatus is op elke beurt beschikbaar in een specifiek gesprek, ongeacht de gebruiker, zoals in groepsgesprekken
Gebruikersstatus en gespreksstatus zijn per kanaal afgebakend. Dezelfde persoon die verschillende kanalen gebruikt om toegang te krijgen tot uw agent, wordt weergegeven als verschillende gebruikers, één voor elk kanaal en elk met een afzonderlijke gebruikersstatus.
De sleutels die worden gebruikt voor elk van deze vooraf gedefinieerde buckets zijn specifiek voor de gebruiker en het gesprek of agenth. Wanneer u de waarde van uw statuseigenschap instelt, wordt de sleutel intern voor u gedefinieerd, met informatie in de turncontext om ervoor te zorgen dat elke gebruiker of gesprek in de juiste bucket en eigenschap wordt geplaatst. De sleutels worden als volgt gedefinieerd:
- De gebruikersstatus maakt een sleutel met behulp van de kanaal-ID en de from-ID. Bijvoorbeeld:
{Activity.ChannelId}/users/{Activity.From.Id}#YourPropertyName - De gespreksstatus maakt een sleutel met behulp van de kanaal-ID en de gespreks-ID. Bijvoorbeeld:
{Activity.ChannelId}/conversations/{Activity.Conversation.Id}#YourPropertyName
Wanneer gebruikt u elk type status
De gespreksstatus is handig voor het bijhouden van de context van het gesprek, zoals:
- Of de agent de gebruiker een vraag heeft gesteld en welke vraag dat was
- Wat het huidige gespreksonderwerp is of wat de laatste is
- Chatgeschiedenis opnemen
De gebruikersstatus is geschikt voor het bijhouden van informatie over de gebruiker, zoals:
- Niet-kritieke gebruikersgegevens, zoals naam en voorkeuren, een alarminstelling of een waarschuwingsvoorkeur
- Informatie over het laatste gesprek dat ze met de agent hadden
- Een productondersteuningsagent kan bijvoorbeeld bijhouden naar welke producten de gebruiker heeft gevraagd.
AgentApplication
- Routehandlers die u toevoegt, krijgen een
TurnStateexemplaar. Open de gespreks- of gebruikersstatus vanuit dit exemplaar. - Status wordt automatisch geladen en opgeslagen.