Gestion de l'état pour les agents de données

Lorsque vous créez des applications avec l'API Conversational Analytics, la gestion de l'état est un élément architectural clé. Vous gérez l'état de la conversation de l'API et, pour les applications qui utilisent l'Agent Development Kit (ADK), l'état de la session du framework.

Modes d'état de l'API

La méthode chat de l'API Conversational Analytics est compatible avec les paramètres de contexte mutuellement exclusifs qui déterminent la façon dont les états de conversation sont gérés.

Utilisez le tableau suivant pour comparer ces modes :

Mode État Historique de la conversation Agent Paramètre Description
Discuter en utilisant une référence à une conversation Avec état Géré par l'API Oui ConversationReference Poursuit une conversation avec état en faisant référence à une conversation existante et à l'agent associé. Google Cloud stocke et gère l'historique de la conversation. Vous n'envoyez que le nouveau message pour chaque tour.
Discuter avec une référence à un agent de données Sans état Géré par votre application Oui DataAgentContext Envoie un message sans état qui se réfère à un agent de données enregistré pour le contexte. Votre application doit gérer et fournir l'intégralité de l'historique des conversations à chaque requête.
Discuter avec le contexte intégré Sans état Géré par votre application Non InlineContext Envoie un message sans état qui fournit tout le contexte directement dans la requête. Ce mode n'utilise pas d'agent de données enregistrées. Votre application doit gérer et fournir l'intégralité de l'historique de la conversation.

État de la session ADK

Si vous utilisez le framework ADK pour l'orchestration, l'ADK fournit une couche de gestion des états qui fonctionne indépendamment de l'état de l'API Conversational Analytics. Il est essentiel de comprendre les deux couches pour créer des systèmes multi-agents qui fonctionnent correctement.

L'ADK utilise des conventions de préfixe de clé pour contrôler le champ d'application et la durée de vie des variables d'état. Utilisez le tableau suivant pour évaluer ces niveaux d'accès :

Préfixe de clé Champ d'application Durée de vie Visible par Exemples
(aucun préfixe) Session Session actuelle uniquement Tous les agents de la session Thème de la conversation en cours ou résultats de la dernière requête
user: Utilisateur Dans toutes les sessions du même utilisateur Tous les agents et toutes les sessions de l'utilisateur spécifié Préférences utilisateur, ID d'agent de données enregistrées ou paramètres de langue
app: Application sur l'ensemble des sessions pour tous les utilisateurs ; Tous les agents et tous les utilisateurs Configuration globale de l'application, ID d'agent de données partagés ou indicateurs de fonctionnalité
temp: Appel Appel actuel uniquement Agent actuel dans l'invocation active Données de réponse intermédiaire, telles que les blocs de streaming ou les calculs en cours

Pour en savoir plus sur le partage d'état dans les systèmes multi-agents, consultez la documentation de l'ADK.

Interaction entre l'état de l'API et l'état de l'ADK

Lorsque vous utilisez l'API Conversational Analytics avec le framework ADK, les calques d'état fonctionnent indépendamment :

  • État de l'API : si votre application utilise des références de conversation (mode avec état), l'API gère l'historique des conversations. Si votre application utilise le contexte de l'agent de données ou le contexte intégré (modes sans état), l'API reste sans état pour chaque appel.
  • État de la session ADK : le framework ADK gère ses propres variables de session, d'événements et d'état, quel que soit le mode utilisé par l'API Conversational Analytics.

Par exemple, lorsque vous utilisez les outils ask_data_insights ou ask_data_agent dans l'ADK, chaque appel est indépendant et sans état au niveau de l'API, même si l'ADK conserve le contexte de session plus large. La démonstration de streaming ADK illustre le modèle recommandé pour cette interaction : un sous-agent de données écrit les données de réponse analysées dans l'état temp:, que les agents en aval lisent ensuite lors de la même invocation.

Étapes suivantes