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

Lorsque vous créez une application 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 des paramètres de contexte mutuellement exclusifs qui déterminent la façon dont l'état de la conversation est géré.

Le tableau suivant compare 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 en utilisant 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 de la conversation à chaque requête.
Discuter en utilisant 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é. 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, il fournit une couche de gestion de l'état 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 champs d'application :

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 Sujet de conversation actuel 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 de l'utilisateur, ID d'agent de données enregistrés ou paramètres de langue
app: Application Dans toutes les sessions de tous les utilisateurs Tous les agents et tous les utilisateurs Configuration globale de l'application, ID d'agent de données partagés ou flags de fonctionnalité
temp: Appel Appel actuel uniquement L'agent actuel dans l'appel actif Données de réponse intermédiaires, telles que des blocs de streaming ou des 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 couches 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 de la conversation. Si votre application utilise le contexte d'un agent de données ou un contexte intégré (modes sans état), l'API reste sans état pour chaque appel.
  • État de la session ADK : le framework ADK conserve sa propre session, ses propres événements et ses propres variables 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 de l'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 dans le même appel.

Étape suivante