Créer des workflows agentiques dans une application avec un backend cloud et ADK

Certaines tâches sont trop complexes pour tenir en une seule session sur l'appareil. Organiser un voyage complet clé en main, c'est coordonner les horaires de vol, choisir les chambres d'hôtel, réserver les billets de musée et planifier les restaurants. Lancer un tel processus multi-étapes directement sur le téléphone risque de faire perdre la progression lorsque l'application est fermée, et jongler avec une multitude d'étapes et de clés API sur un appareil portable devient vite inconfortable. Pour ces longs workflows, un backend auto-hébergé est mieux adapté : il exécute les agents de réservation en arrière-plan pendant que l'application Android reste connectée à la session, affiche la progression et ne sollicite l'utilisateur que lorsque c'est réellement nécessaire.

La base de tout cela est l'Agent Development Kit (ADK). Dans l'exemple Python, un agent spécialisé est défini flight_agent via Agent(name="Flight Booker", model="gemini-3.1-flash-lite",...) avec deux outils de fonction : search_flights(destination, date) et reserve_flight(flight_time). À noter que, pour reserve_flight il est défini require_confirmation=True, donc ADK interrompt l'exécution et attend l'approbation explicite de l'utilisateur avant d'effectuer cette étape irréversible. L'agent est exécuté via InMemoryRunner, où run_async(user_id, session_id) ведёт цикл. ADK сам занимается исполнением — отслеживает контекст диалога, маршрутизирует сообщения между пользователем и моделью и вызывает зарегистрированные инструменты, когда модель их запрашивает, — так что вам остаётся писать процедурную логику, а оркестрацией управляет фреймворк.

Pour transmettre les mises à jour du backend vers l'appareil en temps réel, le serveur utilise AG-UI — un protocole de transport bidirectionnel qui standardise les types de messages entre les agents et les clients d'interface utilisateur. L'agent peut notifier le client des événements de cycle de vie, des messages texte, des appels d'outils et des changements d'état, tandis que le client renvoie les messages utilisateur, les résultats d'outils et les événements d'action personnalisés. Sur le serveur, AG-UI produit les mises à jour sous forme de Server-Sent Events (par exemple, event: TEXT_MESSAGE_CONTENT, transportant un delta JSON). Sur Android, un SDK Kotlin écoute ce flux et mappe la charge utile sur des événements client typés : HttpAgent se configure au moyen de HttpAgentConfig, RunAgentInput porte le fil de discussion et un UserMessage, et runAgentObservable(input).collect { ... } permet de brancher selon TextMessageStartEvent, TextMessageContentEvent et TextMessageEndEvent.

Le rendu de ces seuls événements texte donne un simple chatbot. Pour afficher nativement des composants interactifs, A2UI permet aux agents de décrire dynamiquement des éléments d'interface. Le client déclare un catalogue de composants pris en charge, et le serveur envoie un JSON avec la disposition et les propriétés — par exemple, une surface Flight Reservation, contenant un InteractiveOptionPicker avec une invite, des options telles que « 10:00 AM » et « 2:00 PM », ainsi qu'un bouton de confirmation. Côté backend, l'intégration A2UI dans ADK utilise A2uiSchemaManagerpour compiler les schémas JSON des composants et les instructions de disposition dans le prompt système via generate_system_prompt(...), — ainsi le modèle apprend la structure exacte qu'il doit générer pour produire des payloads A2UI valides que le client pourra afficher.

Côté client, l'ajout d'A2UI commence par les dépendances Gradle, telles que androidx.a2ui:a2ui-model, androidx.a2ui.compose:compose-runtime, compose-ui et androidx.compose.material3:material3-a2ui — toutes en version 1.0.0-alpha01. La classe de chaque composant du catalogue transforme les propriétés JSON en composable Jetpack Compose, et le A2uiCatalogpersonnalisé, enregistré avec un catalogId, le relie à la définition côté serveur. Pour les éléments standards — texte, boutons, cases à cocher et sélecteurs de date et d'heure — des implémentations Material 3 prêtes à l'emploi sont fournies par materialA2uiBasicCatalogV1(...), sans écrire son propre code. BookingAssistantViewModel alimente en messages un A2uiMessageProcessor, dont le StateFlow activeSurfaces l'écran est rendu par le composable A2uiSurface, qui se charge du suivi de l'état, des indicateurs de chargement, de la gestion des erreurs et des transitions animées. Les deux côtés doivent utiliser le même ID de définition de catalogue ; si vous ajoutez ou modifiez des propriétés, il faut incrémenter le numéro de version et mettre à jour la classe de composant correspondante en Kotlin afin d'éviter les erreurs d'analyse.