Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Der Zustand innerhalb eines Agents folgt den gleichen Paradigmen wie moderne Webanwendungen. Das Agents SDK bietet einige Abstraktionen, um die Zustandsverwaltung zu vereinfachen.
Wie bei Web-Apps ist ein Agent inhärent zustandslos. Eine andere Instanz Ihres Agents kann jede gegebene Wendung der Unterhaltung behandeln. Für einige Agents wird diese Einfachheit bevorzugt – der Agent kann entweder ohne zusätzliche Informationen arbeiten, oder die erforderlichen Informationen sind garantiert innerhalb der eingehenden Nachricht. Für andere ist der Status (z. B. der Ort, an dem die Unterhaltung unterbrochen wurde, oder Daten, die zuvor über den Benutzer empfangen wurden) erforderlich, damit der Agent über eine nützliche Unterhaltung verfügt.
Warum brauche ich den Status?
Durch die Aufrechterhaltung des Status kann Ihr Agent aussagekräftigere Unterhaltungen führen, indem er bestimmte Dinge an einen Benutzer oder eine Unterhaltung erinnert. Wenn Sie z. B. zuvor mit einem Benutzer gesprochen haben, können Sie frühere Informationen zu ihnen speichern, damit Sie sie nicht erneut fragen müssen. Der Zustand behält auch Daten länger als die aktuelle Drehung bei, sodass Ihr Agent Informationen im Verlauf einer Multi-Turn-Unterhaltung speichert.
Da es sich um Agents handelt, gibt es einige Ebenen für die Verwendung des Status: die Speicherschicht, die Zustandsverwaltung und AgentApplication.
Speicherebene
Beginnend mit dem Back-End, in dem die Zustandsinformationen tatsächlich gespeichert werden, ist die Speicherebene. Sie können sich dies als Ihren physischen Speicher vorstellen, z. B. In-Memory, Azure oder ein Drittanbieterserver.
Das Agents SDK enthält einige Implementierungen für die Speicherebene:
Speicher implementiert speicherinternen Speicher zu Testzwecken. In-Memory-Datenspeicher ist nur für lokale Tests vorgesehen, da dieser Speicher veränderlich und temporär ist. Die Daten werden jedes Mal gelöscht, wenn der Agent neu gestartet wird.
Azure Blob Storage stellt eine Verbindung mit einer Azure Blob Storage-Objektdatenbank bereit.
Der partitionierte Azure Cosmos DB-Speicher stellt eine Verbindung mit einer partitionierten Cosmos DB NoSQL-Datenbank her.
Anweisungen zum Herstellen einer Verbindung mit anderen Speicheroptionen finden Sie unter Agents SDK Storage Übersicht
Zustandsverwaltung
Die Statusverwaltung automatisiert das Lesen und Schreiben des Status Ihres Agents auf die zugrunde liegende Speicherebene. Status wird als Statuseigenschaften gespeichert, die effektiv Schlüsselwertpaare sind, die Ihr Agent lesen und schreiben kann, ohne sich Gedanken über die spezifische zugrunde liegende Implementierung zu machen. Diese Statuseigenschaften definieren, wie diese Informationen gespeichert werden. Wenn Sie beispielsweise eine Eigenschaft abrufen, die Sie als eine bestimmte Klasse oder ein bestimmtes Objekt definiert haben, wissen Sie, wie diese Daten strukturiert werden.
Diese Zustandseigenschaften werden in bereichsbezogene "Buckets" zusammengefasst, die nur Sammlungen sind, um diese Eigenschaften zu organisieren. Das SDK enthält drei der folgenden "Buckets":
- Benutzerstatus
- Konversationsstatus
Alle diese Buckets sind Unterklassen der Agent-Statusklasse, die abgeleitet werden kann, um andere Buckettypen mit unterschiedlichen Bereichen zu definieren.
Diese vordefinierten Buckets sind abhängig vom Bucket-Typ auf eine spezifische Sichtbarkeit beschränkt.
- Der Benutzerstatus steht in jeder Reihe zur Verfügung, in der der Agent mit diesem Benutzer in diesem Kanal zusammenarbeitet, unabhängig von der Unterhaltung
- Der Gesprächsstatus ist in jeder einzelnen Gesprächsrunde einer spezifischen Unterhaltung verfügbar, unabhängig vom Benutzer, z. B. in Gruppengesprächen.
Der Benutzerstatus und der Unterhaltungsstatus sind nach Kanal festgelegt. Dieselbe Person, die unterschiedliche Kanäle verwendet, um auf Ihren Agent zuzugreifen, wird als unterschiedlichen Benutzer, einen für jeden Kanal und jeweils mit einem unterschiedlichen Benutzerstatus angezeigt.
Die für jeden dieser vordefinierten Buckets verwendeten Schlüssel sind spezifisch für den Benutzer und die Unterhaltung oder Agent. Beim Festlegen des Werts Ihrer Statuseigenschaft wird der Schlüssel intern definiert, mit Informationen, die im Turnkontext enthalten sind, um sicherzustellen, dass jeder Benutzer oder jede Unterhaltung im richtigen Bucket und in der richtigen Eigenschaft platziert wird. Insbesondere werden die Schlüssel wie folgt definiert:
- Der Benutzerstatus erstellt einen Schlüssel mithilfe der Kanal-ID und aus der ID. Beispiel:
{Activity.ChannelId}/users/{Activity.From.Id}#YourPropertyName - Der Unterhaltungsstatus erstellt einen Schlüssel mithilfe der Kanal-ID und der Unterhaltungs-ID. Beispiel:
{Activity.ChannelId}/conversations/{Activity.Conversation.Id}#YourPropertyName
Wann jeder Zustandstyp verwendet werden soll
Der Gesprächsstatus ist gut geeignet, um den Kontext des Gesprächs nachzuverfolgen, z. B.:
- Gibt an, ob der Agent dem Benutzer eine Frage gestellt hat und welche Frage dies war
- Was das aktuelle Thema der Unterhaltung ist oder was das letzte war
- Aufgezeichneter Chatverlauf
Der Benutzerstatus eignet sich gut zum Nachverfolgen von Informationen über den Benutzer, z. B.:
- Nicht kritische Benutzerinformationen, z. B. Name und Einstellungen, Alarmeinstellungen oder Warnungseinstellungen
- Informationen über die letzte Unterhaltung, die sie mit dem Agent hatten
- Beispielsweise kann ein Produktsupport-Agent nachverfolgen, welche Produkte der Benutzer gefragt hat.
AgentApplication
- Routenhandler, die Sie hinzufügen, werden mit einer
TurnStateInstanz bereitgestellt. Greifen Sie von dieser Instanz auf den Unterhaltungs- oder Benutzerstatus zu. - Der Zustand wird automatisch geladen und gespeichert.