Créez un concierge de voyage vocal avec Amazon Bedrock AgentCore, Managed Knowledge Base et Nova Sonic

Les compagnies aériennes disposent déjà d'applications et de sites web où les voyageurs consultent les vols, choisissent des sièges et gèrent leurs réservations, et l'ajout d'une couche vocale naturelle ouvre ces tâches aux demandes parlées. Avec cette couche vocale, un voyageur peut changer de siège ou vérifier un retard en parlant, sans quitter l'application ni naviguer à travers les écrans. Sa construction exige une ingénierie soignée sur plusieurs fronts. Vous diffusez l'audio dans les deux sens et conservez le fil d'une conversation sur de nombreux tours. Vous accédez également à vos systèmes backend existants sans coupler étroitement l'agent à ceux-ci, et vous passez à l'échelle lorsque le trafic explose avant un week-end de vacances.

Cet article vous montre comment ajouter un concierge de voyage vocal à une application de compagnie aérienne, construit sur trois services gérés. Amazon Bedrock AgentCore est une plateforme agentique pour construire, déployer et exploiter des agents IA de manière sécurisée et à grande échelle, avec le framework et le modèle de votre choix. Amazon Nova Sonic sur Bedrock est un modèle de parole à parole pour la voix en temps réel. Amazon Bedrock Knowledge Bases est un service de génération augmentée par récupération entièrement géré qui fonde les réponses dans vos propres documents. Un voyageur parle, et le concierge affiche son itinéraire, change un siège, met à jour une préférence de repas, répond à une question de politique et le met en relation avec un agent humain sur demande.

Le concierge fonctionne aux côtés de vos écrans existants plutôt que de les remplacer, de sorte que les voyageurs passent du tactile à la parole dans la même session. Il fonctionne sur des services qui passent à l'échelle à la demande, vous consacrez donc votre temps à l'expérience plutôt qu'à l'infrastructure. La couche IA se connecte à un backend de compagnie aérienne d'exemple avec des données synthétiques, ce qui accélère votre implémentation lorsque vous adaptez le modèle à vos propres systèmes. Le projet est divisé en modules, ce qui vous permet de réutiliser les éléments qui correspondent à votre backend existant et de les exposer à l'agent comme outils.

Vous apprendrez à effectuer les opérations suivantes :

• Déployer un concierge IA vocal sur AWS en utilisant le AWS Cloud Development Kit (AWS CDK).
• Construire un agent avec le framework Strands Agents et Amazon Nova 2.5 Sonic pour la parole en temps réel, hébergé sur AgentCore runtime, une capacité du framework Amazon Bedrock AgentCore.
• Connecter l'agent aux services backend avec le Model Context Protocol (MCP) via AgentCore Gateway, une capacité d'Amazon Bedrock AgentCore.
• Répondre aux questions sur les politiques de la compagnie aérienne avec Amazon Bedrock Knowledge Bases.
• Transférer un voyageur à un agent humain avec un numéro de référence et un temps d'attente estimé.

Aperçu de la solution

L'architecture sépare le front end, l'agent IA et les services backend en couches distinctes, de sorte que vous pouvez développer et mettre à l'échelle chacun indépendamment. MCP est une norme ouverte pour connecter des applications IA à des outils et des données externes. Il transporte des messages standardisés entre l'agent et le backend, ce qui maintient les deux faiblement couplés.

La solution déploie les services suivants.

• Amazon Cognito gère l'authentification des utilisateurs et les informations d'identification AWS temporaires pour un accès API signé.
• Amazon Bedrock AgentCore runtime héberge l'agent avec une isolation microVM par session.
• Amazon Bedrock AgentCore Gateway expose les points de terminaison backend sous forme d'outils MCP détectables.
• Amazon API Gateway publie le backend sous forme de points de terminaison REST avec une autorisation AWS Identity and Access Management (IAM) .
• AWS Lambda exécute la logique métier pour les itinéraires, les plans de sièges, les mises à jour des passagers, le statut des vols, la fidélité, les recherches de politiques et les escalades.
• Amazon DynamoDB stocke les profils clients, les réservations, les passagers, les plans de sièges, l'historique des achats, les préférences, les conversations et les données de vol.
• Amazon Bedrock Knowledge Bases répond aux questions sur les politiques en ancrant les réponses dans vos documents de politique de la compagnie aérienne.
• Amazon Simple Email Service (Amazon SES) envoie les notifications par e-mail.
• AWS Amplify héberge le front end React.

Architecture

Le diagramme suivant présente l'architecture de la solution, organisée en quatre sections.

Figure 1 : Architecture de bout en bout couvrant le backend, l'AgentCore Gateway, le runtime AgentCore et le front end

La section A couvre l'infrastructure du backend. Cinq stacks CDK déploient des tables DynamoDB, des fonctions Lambda, des endpoints API Gateway, des Amazon Bedrock Knowledge Bases et Amazon Cognito.

La section B couvre l'AgentCore Gateway. Une stack CDK crée l'Amazon Bedrock AgentCore Gateway avec le protocole MCP et expose chaque endpoint du backend sous forme d'outil que l'agent peut appeler par son nom.

La section C couvre le runtime AgentCore. Deux stacks CDK provisionnent l'infrastructure du runtime. Amazon Elastic Container Registry (Amazon ECR) stocke l'image de conteneur, Amazon Simple Storage Service (Amazon S3) conserve les fichiers source téléversés et AWS CodeBuild produit l'image Docker ARM64. Le runtime Amazon Bedrock AgentCore s'exécute avec la prise en charge de WebSocket à l'aide du framework Strands Agents avec Amazon Nova 2.5 Sonic.

La section D couvre le front end. Une stack CDK déploie l'application React sur AWS Amplify.

Flux des requêtes utilisateur

1. L'utilisateur ouvre l'application web, hébergée sur AWS Amplify, dans un navigateur ou sur un appareil mobile.
2. L'utilisateur saisit ses identifiants sur la page de connexion. Amazon Cognito authentifie la requête et renvoie des JSON Web Tokens (JWT) et des informations d'identification AWS temporaires.
3. Le front end ouvre une connexion WebSocket signée avec SigV4 vers Amazon Bedrock AgentCore pour démarrer la session de conciergerie vocale.
4. Le runtime valide le jeton auprès d'Amazon Cognito et initialise Amazon Nova 2.5 Sonic via Amazon Bedrock.
5. L'utilisateur énonce une requête. Amazon Nova 2.5 Sonic traite l'audio et déclenche des appels d'outils. L'agent gère l'intégration des outils en invoquant l'AgentCore Gateway via MCP pour récupérer les données de vol, gérer les réservations et mettre à jour les préférences des passagers.
6. L'AgentCore Gateway transmet les requêtes sous forme d'appels d'API REST à Amazon API Gateway, qui les achemine vers les fonctions AWS Lambda.
7. Les fonctions AWS Lambda interrogent les tables Amazon DynamoDB pour les réservations, les passagers, les plans de sièges, le statut de fidélité et les informations de vol. Les notifications par e-mail sont envoyées via Amazon SES.
8. Amazon Nova 2.5 Sonic génère une réponse vocale contextuelle et la diffuse en continu à l'utilisateur via la connexion WebSocket à travers le runtime AgentCore.
9. Pour une question relative à une politique, l'AgentCore Gateway interroge directement Amazon Bedrock Knowledge Bases via le connecteur MCP Knowledge Base. La base de connaissances renvoie à l'agent les passages pertinents de la politique sous forme de citations.
10. Lorsque l'utilisateur demande un agent en direct, AWS Lambda consigne l'escalade dans Amazon DynamoDB et renvoie un numéro de référence. AWS Amplify déclenche ensuite l'appel depuis l'appareil de l'utilisateur pour le mettre en relation avec l'agent en direct.

Build et opérations

Les deux étapes suivantes se situent en dehors de la conversation en direct. Elles décrivent la manière dont la solution est construite et dont elle fonctionne au quotidien.

1. AWS CDK déploie la solution avec un seul script. Le build téléverse le code source de l'agent vers Amazon S3 et déclenche AWS CodeBuild pour produire l'image de conteneur, qui est stockée dans Amazon ECR pour le runtime AgentCore.
2. Amazon CloudWatch collecte les journaux, les métriques et les alertes de tous les services, et AWS Key Management Service (AWS KMS) chiffre les données au repos.

Prérequis

Avant de commencer, vérifiez que vous disposez des éléments suivants.

• Un compte AWS.
• L'accès au modèle dans Amazon Bedrock pour Amazon Nova 2.5 Sonic dans la Région AWS où vous effectuez le déploiement. Pour connaître la disponibilité des modèles par Région, consultez Modèles pris en charge par Région AWS dans Amazon Bedrock. Amazon Bedrock Knowledge Bases utilise un modèle d'embedding géré par le service, vous n'avez donc pas besoin d'un accès séparé à un modèle d'embedding.
• Node.js 20.x ou version ultérieure pour AWS CDK et les fonctions Lambda.
• Python 3.12 ou version ultérieure pour l'amorçage des données et le client de test.
• AWS Command Line Interface (AWS CLI) 2.x configurée avec des informations d'identification.
• AWS CDK CLI 2.x installé avec npm install -g aws-cdk, et votre compte configuré (bootstrapped) avec npx cdk bootstrap.
• Le code accompagnant l'article, disponible dans le dépôt GitHub aws-samples.

Déployez la solution avec AWS CDK

La solution se déploie avec un seul script CDK. Clonez le référentiel, configurez vos identifiants AWS et exécutez le script de déploiement. Pour connaître les étapes de déploiement détaillées, consultez le README dans le référentiel GitHub.

Le modèle de données aériennes d'exemple

API Gateway publie une API REST avec des points de terminaison autorisés par IAM et une intégration Lambda. Amazon DynamoDB stocke le modèle de données aériennes d'exemple avec une latence de quelques millisecondes et une mise à l'échelle à la demande. Les données couvrent les profils clients, les réservations, les passagers, les plans de sièges, l'historique des achats, les préférences, les transcriptions de conversations et le statut des vols.

Répondre aux questions de politique avec une base de connaissances

Les voyageurs posent des questions sur les limites de bagages, les frais de modification, les voyages avec animaux et les conditions du programme de fidélité. La solution répond à ces questions en utilisant la Génération Augmentée par Récupération (RAG) via Amazon Bedrock Knowledge Bases, en ancrant les réponses dans vos documents de politique de la compagnie aérienne. Le référentiel est livré avec des documents de politique d'exemple concernant les bagages, les annulations et remboursements, les modifications et rebookings, les règles de classes tarifaires, les conditions de fidélité, les voyages avec animaux, l'assistance spéciale et les surclassements.

Vous téléchargez vos documents sur Amazon S3 et créez la base de connaissances une seule fois. À partir de là, Amazon Bedrock gère le reste, y compris l'embedding, le découpage en chunks, l'indexation, le stockage et la récupération. Le stockage s'exécute sur Amazon S3 Vectors, une capacité d'Amazon S3. Smart Parsing prépare les PDF sources afin que les tableaux et les mises en page structurées soient récupérés avec précision. Lorsque vos documents de politique changent, vous synchronisez la base de connaissances et le nouveau contenu est disponible immédiatement. Aucun pipeline à redéployer.

La connexion de la base de connaissances à l'agent se fait directement via AgentCore Gateway. Vous ajoutez la base de connaissances comme cible Connectors et choisissez la récupération standard ou agentique, et la Gateway l'expose comme un outil MCP nommé aux côtés de vos outils d'API backend. L'agent la découvre ensuite au moment de l'exécution et l'appelle par son nom, sans code Lambda ou de récupération personnalisé à écrire. Pour les étapes de configuration, consultez Ajouter une base de connaissances comme cible de passerelle.

Pour utiliser vos propres politiques, déposez vos fichiers PDF ou texte dans le dossier des documents de politique et redéployez la pile de la base de connaissances.

Traitement vocal IA avec Amazon Bedrock AgentCore

Chaque session s'exécute dans un conteneur géré sur le runtime AgentCore avec isolation microVM, maintenant les conversations des voyageurs séparées sous charge. AgentCore fournit une mise à l'échelle automatique, une surveillance intégrée et le routage des sessions.

Pour les déploiements en production, ajoutez Amazon Bedrock Guardrails pour filtrer les tentatives d'injection de prompt et valider l'ancrage des réponses. Le modèle de confirmation avant écriture de cette solution demande au voyageur de confirmer avant d'effectuer des modifications. Ce modèle, associé aux citations de la base de connaissances qui retracent les réponses jusqu'aux documents sources, fournit déjà une base de pratique responsable de l'IA.

L'agent utilise le framework Strands BidiAgents pour définir le prompt système, les outils et le flux de conversation. Amazon Nova 2.5 Sonic apporte les capacités suivantes au concierge.

• Reconnaissance vocale des accents et robustesse au bruit de fond.
• Réponses parlées qui s'adaptent au ton du voyageur.
• Streaming bidirectionnel à faible latence.
• Appels d'outils asynchrones qui récupèrent des données ou effectuent des appels d'outils en parallèle sans mettre la conversation en pause.
• Masquage de latence qui génère des réponses parlées provisoires pendant l'attente des résultats des outils, gardant la conversation naturelle.
• Interruption (barge-in) et alternance naturelle des tours de parole.
• Contexte qui se maintient sur de nombreux tours.

Les flux audio arrivent du front end en PCM 16 kHz via le WebSocket vers le runtime AgentCore. Amazon Nova 2.5 Sonic transcrit la parole, l'agent choisit les bons outils et les appelle via MCP. L'AgentCore Gateway traduit chaque appel MCP en requête REST, Lambda exécute la logique et renvoie les résultats, et Amazon Nova 2.5 Sonic intègre ces résultats dans une réponse parlée.

Quoi de neuf dans Amazon Nova 2.5 Sonic

Cette solution utilise Amazon Nova 2.5 Sonic, un modèle de parole en parole doté d'un raisonnement puissant pour la voix en temps réel. Pour un concierge vocal qui appelle des outils en arrière-plan et suit une invite système détaillée, ce raisonnement se manifeste de plusieurs manières pratiques :

Meilleur appel d'outils et achèvement des tâches agentiques – L'agent sélectionne et enchaîne les bons outils de manière fiable dans des demandes en plusieurs étapes, comme consulter un itinéraire puis changer un siège dans une même conversation.

Suivi strict des instructions et raisonnement – Le modèle respecte étroitement l'invite système, y compris les règles de formatage comme l'épellation des codes de confirmation et des numéros de vol caractère par caractère.

Gestion précise de l'IA responsable – Le modèle répond utilement aux demandes légitimes des voyageurs tout en gérant de manière sûre les demandes inappropriées.

Authentification des utilisateurs

La solution utilise Amazon Cognito User Pools et Identity Pools pour un accès basé sur les rôles. Un voyageur se connecte avec un nom d'utilisateur et un mot de passe et reçoit des JWT, un jeton d'accès et un jeton d'ID. Le front end échange le jeton d'ID avec le Cognito Identity Pool contre des informations d'identification AWS temporaires composées d'une clé d'accès, d'une clé secrète et d'un jeton de session. Ces informations d'identification signent la connexion WebSocket vers AgentCore runtime et les requêtes vers API Gateway à l'aide de Signature Version 4 (SigV4). Seuls les voyageurs authentifiés atteignent l'application et les API de service.

Flux d'authentification et de connexion WebSocket

Le front end utilise les informations d'identification AWS temporaires pour ouvrir une connexion WebSocket signée SigV4 vers AgentCore runtime et envoie le jeton d'accès pour la vérification d'identité. Le navigateur diffuse ensuite de l'audio PCM à 16 kHz et reçoit les réponses vocales et les notifications d'outils sur la même connexion. Aucun proxy côté serveur ne se trouve au milieu.

La figure suivante montre la séquence d'authentification et de connexion WebSocket entre le navigateur, Amazon Cognito et AgentCore runtime.

Figure 2 : Un voyageur s'authentifie auprès d'Amazon Cognito, le navigateur ouvre une WebSocket signée SigV4 vers AgentCore runtime, et Amazon Nova 2.5 Sonic diffuse la voix dans les deux sens

Interaction vocale et appel dynamique d'outils

Un voyageur demande à voir ses sièges. Nova 2.5 Sonic transcrit la demande et l'agent sélectionne les outils dont il a besoin. Il les appelle en parallèle via l'AgentCore Gateway en utilisant MCP, et la Gateway traduit chaque appel en une requête REST vers API Gateway. Les fonctions Lambda interrogent DynamoDB et renvoient les résultats, et Nova 2.5 Sonic diffuse une réponse parlée qui combine le tout. Comme les appels d'outils s'exécutent de manière asynchrone, la conversation ne se bloque pas pendant le chargement des données.

La figure suivante montre comment l'agent traite une demande parlée et appelle dynamiquement les outils backend via l'AgentCore Gateway :

Figure 3 : Une demande parlée transite par Nova 2.5 Sonic, l'AgentCore Gateway, API Gateway, Lambda et DynamoDB, et la réponse vocale est diffusée en retour

Répondre à une question de politique à partir de la base de connaissances

Lorsqu'un voyageur pose une question sur la politique de bagages, l'agent accède à Amazon Bedrock Knowledge Bases via l'AgentCore Gateway en utilisant son connecteur natif. La base de connaissances exécute une récupération agentique avec un reranker géré et renvoie les passages de politique pertinents sous forme de citations. Nova 2.5 Sonic compose la réponse et la prononce au voyageur.

La figure suivante montre l'agent répondant à une question de politique en récupérant des passages sourcés depuis Amazon Bedrock Knowledge Bases :

Figure 4 : Une question de politique est répondue par Amazon Bedrock Knowledge Bases et prononcée au voyageur

Passer la main à un agent humain

Le concierge transfère un voyageur à une personne lorsqu'il ne peut pas répondre à une demande ou lorsque le voyageur le demande. Après confirmation du voyageur, l'agent appelle l'outil EscalateToAgent. Lambda enregistre l'escalade dans DynamoDB et renvoie un numéro de référence avec un temps d'attente estimé. L'agent partage ce numéro de référence, et le front end Amplify passe l'appel vers la ligne d'assistance. Cet exemple n'inclut pas d'application de centre de contact, donc la mise en relation avec une personne dépend du numéro d'assistance que vous configurez.

La figure suivante montre le flux d'escalade lorsqu'un voyageur demande un agent humain :

Figure 5 : L'agent enregistre l'escalade dans DynamoDB, partage un numéro de référence, et le front end passe l'appel vers un agent humain

Présentation du concierge

Ouvrez l'URL Amplify dans votre navigateur et connectez-vous avec les identifiants AppUser. Choisissez le bouton microphone pour démarrer une conversation vocale. L'agent vous salue par votre nom et affiche votre itinéraire en arrière-plan. À partir de là, vous pouvez parler naturellement pour changer de siège, vérifier un retard, consulter une politique ou joindre un agent humain. La vidéo suivante montre une session complète, de l'accueil à l'escalade.

Toute la conversation se déroule sans les mains sur une seule connexion WebSocket. L'agent confirme chaque modification avant de l'écrire. Il énonce les numéros de vol caractère par caractère, afin qu'ils soient clairement audibles, et il appelle les outils backend en arrière-plan, ce qui évite tout retard perceptible.

Nettoyage

Pour éviter d'encourir des frais, supprimez les ressources déployées. Prévisualisez d'abord les suppressions, puis exécutez le nettoyage.

./cleanup-all.sh --dry-run
./cleanup-all.sh

Le script détruit les ressources dans l'ordre inverse, en commençant par le front end, puis AgentCore runtime, l'AgentCore Gateway et l'infrastructure backend.

Conclusion

Cet article vous a montré comment construire un concierge de voyage vocal sur AWS. Il utilise Amazon Cognito pour l'authentification, Amazon Bedrock AgentCore pour l'hébergement de l'agent, API Gateway et Lambda pour la logique métier, DynamoDB pour le stockage et Amazon Bedrock Knowledge Bases pour les réponses sur les politiques. La conception en couches sépare le front end, l'agent et le backend afin que chacun puisse évoluer et se développer de manière indépendante. Le concierge gère les itinéraires, les changements de siège, les préferences de repas, le statut des vols, les questions de fidélité, les consultations de politiques et l'escalade vers un agent humain via des outils MCP. Amazon Nova 2.5 Sonic apporte une voix à faible latence, l'appel parallèle d'outils et la gestion naturelle des interruptions. La tarification à l'usage et la mise à l'échelle automatique maintiennent les coûts alignés sur le trafic, et grâce à l'intégration MCP, vous pouvez ajouter une nouvelle fonction Lambda sans toucher au code de l'agent. Pour commencer, visitez le dépôt de la solution sur GitHub et adaptez-le à vos propres systèmes de compagnie aérienne.

Ressources supplémentaires

• Utilisation du modèle Speech-to-Speech Amazon Nova Sonic
• Premiers pas avec Amazon Bedrock AgentCore
• Spécification du Model Context Protocol
• Amazon Bedrock Knowledge Bases

À propos des auteurs