Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Étape 3 : Déployer un cas d'utilisation à l'aide de l'assistant du tableau de bord de déploiement
Dans l'assistant du tableau de bord de déploiement, vous devez choisir entre les options suivantes :
-
Cas d'utilisation du texte - Déploie une application de chat, avec des fonctionnalités RAG en option
-
Cas d'utilisation de Bedrock Agent - Utilise les agents Amazon Bedrock pour effectuer des tâches ou automatiser des flux de travail répétés
-
Serveur MCP - Déployez et gérez des serveurs MCP à l'aide de passerelles ou de méthodes d'exécution
-
Agent Builder : créez et déployez des agents personnalisés AgentCore grâce à l'intégration de MCP et à la gestion de la mémoire
-
Générateur de flux de travail : orchestrez plusieurs agents Agent Builder à l'aide de la délégation hiérarchique
Affiche cinq options : créer un cas d'utilisation du texte, créer un cas d'utilisation de l'agent Bedrock, créer un cas d'utilisation du serveur MCP, créer un cas d'utilisation du générateur d'agents ou créer un cas d'utilisation du flux de travail.
Étape 3a : Déployer un cas d'utilisation de texte
Cette section fournit des instructions pour déployer un cas d'utilisation de type Text.
Sélectionnez un cas d'utilisation
Lorsque vous choisissez Créer un cas d'utilisation du texte, l'interface utilisateur ouvre l'écran Sélectionner un cas d'utilisation. Saisissez les informations suivantes :
-
Nom du cas d'utilisation.
-
Adresse e-mail facultative pour que l'utilisateur par défaut du cas d'utilisation soit ajouté au groupe d'utilisateurs Amazon Cognito pour le cas d'utilisation et soit autorisé à interagir avec celui-ci.
-
Si vous souhaitez déployer une interface utilisateur avec ce cas d'utilisation. Si vous ne souhaitez pas déployer d'interface utilisateur avec le cas d'utilisation, vous pouvez utiliser les points de terminaison d'API déployés pour les utiliser avec votre application.
Détails du cas d’utilisation
L'étape des détails du cas d'utilisation vous permet de configurer des paramètres supplémentaires pour votre déploiement.
Par défaut, le cas d'utilisation du texte crée et configure un groupe d'utilisateurs Amazon Cognito pour vous lorsque la solution déploie le tableau de bord de déploiement. La solution authentifie les nouveaux cas d'utilisation auprès d'un client nouvellement créé dans le même groupe d'utilisateurs. Toutefois, vous pouvez fournir un identifiant de groupe d'utilisateurs et un identifiant client existants au cours de cette étape si vous souhaitez utiliser votre propre groupe d'utilisateurs et votre propre client Amazon Cognito dans le cadre de ce cas d'utilisation.
Important
Les utilisateurs administrateurs ont accès à tous les cas d'utilisation déployés lorsque le groupe d'utilisateurs Amazon Cognito est créé via l'assistant de déploiement. Si vous fournissez votre propre groupe d'utilisateurs lors du déploiement, vous devez vous assurer que l'administrateur dispose des autorisations nécessaires pour accéder aux cas d'utilisation déployés.
Vous devrez également mettre à jour le rappel autorisé URLs et la déconnexion autorisée dans les clients de votre application URLs dans Cognito. Pour cela :
-
Accédez à la console Cognito
-
Choisissez Groupes d’utilisateurs.
-
Choisissez votre groupe d'utilisateurs.
-
Choisissez App Clients dans le menu de gauche.
-
Choisissez le client d'application que vous souhaitez modifier.
-
Choisissez l'onglet Pages de connexion.
-
Choisissez Modifier et ajoutez votre URLs.
-
Sélectionnez Enregistrer les modifications.
En outre, si vous devez ajouter d'autres utilisateurs à un cas d'utilisation, consultez la section Gestion du groupe d'utilisateurs de Cognito.
Sélectionnez la configuration réseau
Cette étape de l'assistant vous permet de déployer le cas d'utilisation avec un Amazon Virtual Private Cloud (Amazon
Sélection d’un modèle
À l'étape Sélectionner un modèle, vous pouvez choisir votre fournisseur de modèles dans le menu déroulant. Il existe deux options : Bedrock et. SageMaker
Si vous le sélectionnez SageMaker, vous pouvez créer un point de terminaison du modèle SageMaker SageMaker AI dans la console AI et fournir le schéma d'entrée que le modèle attend et produit JSONPath pour la réponse LLM. Vous pouvez vous référer à la section Utiliser Amazon SageMaker AI en tant que fournisseur de LLM et aux exemples de charge utile d'SageMaker IA
Si vous sélectionnez Amazon Bedrock, quatre options vous seront proposées :
-
Modèles à démarrage rapide - Démarrez rapidement avec une collection de modèles aux price/performance caractéristiques différentes. Recommandé pour créer vos premières applications. Cette option vous permet de sélectionner un nom de modèle dans la liste fournie.
-
Autres modèles de fondation - Accédez à la gamme complète de modèles de base avec différentes capacités et spécialisations. Cette option vous permet de saisir l'identifiant du modèle de fondation Bedrock à la demande que vous souhaitez.
-
Profils d'inférence : les profils d'inférence tirent parti de l'inférence interrégionale de Bedrock pour augmenter le débit et améliorer la résilience en acheminant vos demandes entre plusieurs régions AWS pendant les pics d'utilisation. Cette option vous permet de saisir l'ID du profil d'inférence que vous souhaitez utiliser.
-
Modèles provisionnés : capacité de débit dédiée aux charges de travail de production nécessitant des performances constantes. Cette option vous permet de saisir l'ARN du provisioned/custom modèle à utiliser depuis Amazon Bedrock.
L'étape de sélection du modèle vous permet également de choisir les paramètres avancés du modèle. Reportez-vous à la section Paramètres LLM avancés pour plus de détails sur la configuration d'Amazon Bedrock Guardrails, le débit provisionné pour Amazon Bedrock et les paramètres supplémentaires du modèle.
Inférence entre régions
L'inférence entre régions aide les utilisateurs d'Amazon Bedrock à gérer facilement les pics de trafic imprévus en utilisant le calcul dans différentes régions AWS. Pour utiliser l'inférence entre régions, vous avez besoin du profil d'inférence. Un profil d'inférence est une abstraction d'un pool de ressources à la demande provenant d'un ensemble configuré de régions AWS. Il peut acheminer votre demande d'inférence, provenant de votre région source, vers une autre région configurée dans ce pool. Cela permet de répartir le trafic entre plusieurs régions AWS. Cela permet d'augmenter le débit et d'améliorer la résilience pendant les périodes de pointe.
Les profils d'inférence sont nommés d'après le modèle et les régions qu'ils prennent en charge. Vous devez appeler un profil d'inférence depuis l'une des régions qu'il inclut. Par exemple, comme indiqué dans le tableau suivant, l'ID du profil d'inférence us.anthropic.claude-3-haiku-20240307-v1:0 permet de répartir le trafic sur us-east-1 et us-west-2 les régions du modèle que vous choisissez. Certains modèles ne sont disponibles qu'avec un profil d'inférence dans une région donnée.
| Profil d’inférence | ID du profil d'inférence | Régions incluses |
|---|---|---|
|
Haïku américain Anthropic Claude 3 |
|
USA Est (Virginie du Nord) ( USA Ouest (Oregon) ( |
Si vous souhaitez utiliser un ID de profil d'inférence au lieu d'un ID de modèle, vous devez identifier l'ID de profil d'inférence approprié. Consultez la section Régions et modèles pris en charge pour les profils d'inférence dans le guide de l'utilisateur d'Amazon Bedrock pour plus d'informations. Dans la console Amazon Bedrock
Après avoir identifié l'ID du profil d'inférence à utiliser, vous pouvez l'utiliser lors de l'étape de sélection du modèle en effectuant les étapes suivantes :
-
Sélectionnez Amazon Bedrock comme fournisseur de modèles.
-
Sélectionnez l'option du bouton radio Inference Profiles.
-
Entrez l'ID de votre profil d'inférence dans la zone de texte qui apparaît.
Reportez-vous à la section Améliorez la résilience grâce à l'inférence interrégionale dans le guide de l'utilisateur d'Amazon Bedrock pour plus de détails sur les profils d'inférence.
Sélectionnez la base de connaissances
Si vous souhaitez déployer un cas d'utilisation de génération augmentée sans extraction (RAG), vous pouvez ignorer cette étape.
Toutefois, si vous souhaitez activer RAG dans le cadre de votre déploiement, vous pouvez désormais fournir un identifiant d'index Amazon Kendra préconfiguré ou un identifiant de base de connaissances Amazon Bedrock. Vous pouvez également créer un nouvel index Amazon Kendra à utiliser avec la solution. La solution prend actuellement en charge les bases de connaissances Amazon Kendra et Amazon Bedrock en tant que bases de connaissances pour votre déploiement de cas d'utilisation basé sur RAG.
Reportez-vous à la section Configuration d'une base de connaissances pour obtenir des instructions sur l'ingestion de données dans la base de connaissances à utiliser avec votre déploiement basé sur RAG.
Configurations RAG avancées
L'assistant vous permet de sélectionner des options avancées à utiliser avec votre déploiement RAG, telles que le nombre de documents à récupérer chaque fois qu'une requête est envoyée à votre base de connaissances, une réponse texte statique du LLM lorsqu'aucun document n'est trouvé dans la base de connaissances, si vous souhaitez afficher les sources des documents avec votre réponse LLM pour les contrôles de santé, etc. Vous pouvez également configurer des configurations spécifiques à la base de connaissances pour Amazon Kendra, telles que le contrôle d'accès basé sur les rôles (RBAC) ou le type de recherche de remplacement lorsque vous utilisez Amazon Serverless avec les bases de connaissances Amazon Bedrock OpenSearch . Reportez-vous à la section Paramètres avancés de la base de connaissances pour plus de détails sur ces paramètres avancés.
Note
Votre base de connaissances doit se trouver dans le même compte et dans la même région que le tableau de bord de déploiement déployé et les piles de cas d'utilisation.
Sélectionnez les invites et les limites de jetons
Au cours de cette étape, vous pouvez configurer votre invite pour une utilisation avec le LLM. Les invites peuvent nécessiter des espaces réservés tels que{input}, et{history}. {context} Ces espaces réservés indiquent au LLM où puiser les commentaires des utilisateurs, l'historique des conversations et les informations extraites de la base de connaissances.
-
Pour le fournisseur de modèles Bedrock, l'invite du système doit être fournie, sans aucune restriction pour un cas d'utilisation autre que RAG. L'invite de désambiguïsation pour le fournisseur de modèles Bedrock nécessite toutefois un minimum de deux espaces réservés - et
{input}{history} -
Pour le fournisseur de SageMaker modèles, le système et les instructions de désambiguïsation, les deux nécessitent un minimum de deux espaces réservés - et.
{input}{history} -
Pour les cas d'utilisation de RAG, pour chaque fournisseur de modèles, l'
{context}espace réservé est également requis.
Pour plus d'informations, consultez la section Configuration de vos invites. Vous pouvez également vous référer à la section Conseils pour gérer les limites de jetons des modèles lors de la sélection des tailles limites de jetons pour vos instructions.
Activer la saisie multimodale
Cette étape vous permet d'activer les fonctionnalités de saisie multimodales pour votre cas d'utilisation. Lorsque cette option est activée, les utilisateurs peuvent télécharger et envoyer des images et des documents en même temps que leurs requêtes textuelles.
Types de fichiers pris en charge et contraintes :
-
Images : jusqu'à 20 images par message. La taille de chaque image ne doit pas dépasser 3,75 Mo et 8 000 pixels de hauteur et de largeur. Formats pris en charge : png, jpeg, gif, webp
-
Documents : jusqu'à 5 documents par message. La taille de chaque document ne doit pas dépasser 4,5 Mo. Formats pris en charge : pdf, csv, doc, docx, xls, xlsx, html, txt, md
Comment utiliser la saisie multimodale :
-
Activer le MultimodalEnabledparamètre lors du déploiement des cas d'utilisation
-
Dans l'interface de chat, les utilisateurs peuvent télécharger des fichiers de deux manières :
-
En cliquant sur le bouton de téléchargement dans la zone de saisie du chat, ou
-
Glisser-déposer des fichiers directement dans l'interface de chat
-
-
Les fichiers sont chargés sur Amazon S3 et traités par le modèle sélectionné
-
Les fichiers téléchargés sont automatiquement supprimés au bout de 48 heures
Suivi de l'état des fichiers :
DevOps les utilisateurs peuvent surveiller les métadonnées des fichiers dans DynamoDB, notamment le temps de téléchargement et l'état du traitement. Les fichiers peuvent avoir les statuts suivants :
-
en attente - Le téléchargement du fichier a été lancé mais n'est pas encore terminé. Il s'agit de l'état initial lorsqu'une URL présignée est générée.
-
uploadé - Le fichier a été chargé avec succès sur S3 et est prêt à être traité par le modèle.
-
supprimé - Le fichier a été supprimé par l'utilisateur et ne devrait plus être accessible pour le traitement.
-
non valide - Les contrôles de validation du fichier ont échoué (par exemple, incompatibilité du type de fichier ou échec de la validation de sécurité).
Les fichiers en attente qui ne sont jamais téléchargés seront automatiquement nettoyés à l'expiration de leur TTL. Seuls les fichiers ayant le statut de téléchargement peuvent être traités par le modèle.
Le bucket multimodal S3 et la table de métadonnées DynamoDB sont disponibles dans les sorties du tableau de bord de déploiement avec les MultimodalDataBucketName clés et, respectivement. MultimodalDataMetadataTable
Note
Tous les modèles ne prennent pas en charge la saisie multimodale. Assurez-vous que le modèle sélectionné prend en charge le traitement des images et des documents avant d'activer cette fonctionnalité. Reportez-vous aux modèles de base pris en charge dans la documentation d'Amazon Bedrock pour savoir quel modèle prend en charge l'image comme modalité d'entrée.
Important
Les fichiers chargés par les utilisateurs sont stockés dans Amazon S3 selon une politique de cycle de vie de 48 heures. Les métadonnées relatives aux fichiers chargés sont stockées dans Amazon DynamoDB avec un TTL de 24 heures pour l'historique des conversations.
Vérification et déploiement
Après cette étape, passez en revue les paramètres que vous avez sélectionnés et choisissez Deploy Use Case. Le nouveau cas d'utilisation est ensuite déployé et devient visible dans la vue du tableau de bord de déploiement afin de poursuivre la gestion.
Étape 3b : Déployer un cas d'utilisation de l'agent Bedrock
Le cas d'utilisation de Bedrock Agent fournit un mécanisme puissant et sécurisé pour invoquer des agents Amazon Bedrock dans le cadre de vos cas d'utilisation. Cette fonctionnalité permet aux développeurs d'intégrer de manière fluide les capacités des agents autonomes alimentés par l'IA, capables d'orchestrer et d'exécuter des tâches en plusieurs étapes sur différents modèles de base, sources de données, applications logicielles et conversations avec les utilisateurs, tout en maintenant des mesures de sécurité robustes.
Conditions préalables
Avant de créer un agent Amazon Bedrock, assurez-vous de disposer des éléments suivants :
-
Le compte AWS sur lequel Generative AI Application Builder sur AWS est déployé, avec un accès à la console Amazon Bedrock.
-
Autorisations IAM appropriées pour créer et gérer des agents Amazon Bedrock.
Création d'un agent Amazon Bedrock
Reportez-vous à la section Créer et configurer manuellement un agent dans le guide de l'utilisateur d'Amazon Bedrock pour obtenir des instructions détaillées sur la création d'un agent. Vous pouvez configurer des options telles que :
-
Instructions (instructions) pour votre agent
-
Base de connaissances, qui est utilisée pour rechercher des informations supplémentaires en fonction des entrées de l'utilisateur
-
Mémoire de l'agent pour permettre aux agents de mémoriser des informations au cours de plusieurs sessions (pendant un maximum de 30 jours)
Une fois que vous avez créé avec succès un agent Amazon Bedrock, vous pouvez passer au flux de l'assistant de création d'applications Generative AI sur AWS Bedrock Agent. Pour ce faire, choisissez Déployer un nouveau cas d'utilisation sur le tableau de bord de déploiement et sélectionnez Créer un cas d'utilisation de l'agent Bedrock. Suivez l'assistant et suivez les étapes suivantes pour configurer le cas d'utilisation.
Sélectionnez un cas d'utilisation
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Sélectionnez la configuration réseau
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Sélectionnez un agent
Au cours de cette étape, vous devez fournir l'identifiant d'agent et l'identifiant d'alias de l'agent Amazon Bedrock que vous avez créé.
Étape 3c : Déployer un cas d'utilisation d'un serveur MCP
Le cas d'utilisation du serveur MCP (Model Context Protocol) vous permet de déployer et de gérer des serveurs MCP qui peuvent être intégrés à des modèles et agents d'IA. Les serveurs MCP fournissent un moyen standardisé d'exposer les outils, les ressources et les fonctionnalités aux applications d'intelligence artificielle. Vous pouvez soit créer des serveurs MCP à partir de fonctions Lambda existantes, soit héberger APIs des serveurs MCP personnalisés à l'aide d'images de conteneur.
Conditions préalables
Avant de déployer un cas d'utilisation du serveur MCP, assurez-vous que vous disposez des éléments suivants :
-
Le compte AWS sur lequel Generative AI Application Builder sur AWS est déployé.
-
Autorisations IAM appropriées pour créer et gérer les ressources Amazon Bedrock AgentCore .
-
En fonction de la méthode de création que vous avez choisie :
-
Pour la méthode Gateway (Lambda/API/MCPserveur) : fonctions Lambda, points de terminaison d'API avec leurs fichiers de schéma correspondants (format JSON pour Lambda, OpenAPI/Smithy pour APIs) ou points de terminaison URL du serveur MCP
-
Pour la méthode d'exécution (ECR) : une image de conteneur Docker envoyée à Amazon ECR contenant l'implémentation de votre serveur MCP
-
Méthodes de création du serveur MCP
La solution prend en charge deux méthodes pour créer des serveurs MCP :
Création à partir d'un serveur Lambda, API ou MCP (méthode Gateway)
Cette méthode crée une passerelle MCP qui enveloppe les fonctions Lambda existantes, les serveurs REST ou les serveurs MCP externes APIs, les rendant accessibles en tant qu'outils MCP. La passerelle gère la traduction des protocoles entre MCP et vos services existants.
-
Cibles Lambda : intégrez les fonctions Lambda existantes en fournissant l'ARN de la fonction et un fichier de schéma JSON décrivant le format de la fonction input/output
-
Cibles OpenAPI : intégrez REST à l'aide des spécifications APIs OpenAPI (format JSON ou YAML) avec prise en charge de l'authentification 2.0 ou par clé API OAuth
-
Cibles Smithy : intégration APIs définie à l'aide de fichiers de modèle Smithy (format .smithy ou .json)
-
Cibles du serveur MCP : connectez-vous directement aux serveurs MCP externes via des points de terminaison URL, ce qui permet l'intégration de serveurs MCP existants sans déployer de nouvelle infrastructure
Vous pouvez configurer plusieurs cibles (jusqu'à 10) au sein d'une même passerelle MCP, chacune représentant un outil ou une fonctionnalité différent.
Hébergement à partir d'une image ECR (méthode d'exécution)
Cette méthode déploie un serveur MCP conteneurisé à partir d'une image Amazon ECR. Utilisez cette approche lorsque vous avez une implémentation de serveur MCP personnalisée qui doit être exécutée en tant que service autonome.
-
Fournissez l'URI de l'image ECR (doit inclure une balise, par exemple,
:latestou:v1.0.0) -
Configurez éventuellement des variables d'environnement pour transmettre la configuration à votre conteneur
-
Le conteneur doit implémenter le protocole MCP et exposer les points de terminaison requis
Déploiement d'un serveur MCP
Pour déployer un cas d'utilisation du serveur MCP, choisissez Déployer un nouveau cas d'utilisation sur le tableau de bord de déploiement, puis sélectionnez Créer un cas d'utilisation du serveur MCP. Suivez l'assistant et suivez les étapes suivantes pour configurer le cas d'utilisation.
Sélectionnez un cas d'utilisation
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Sélectionnez la configuration réseau
Actuellement, seul l'accès public est activé et le VPC n'est pas pris en charge pour la configuration réseau.
Création d'un serveur MCP
Au cours de cette étape, vous configurez le déploiement de votre serveur MCP :
Méthode de création du serveur MCP
Choisissez entre les deux méthodes de création :
-
Création à partir d'un serveur Lambda, API ou MCP : créez une passerelle MCP à partir de fonctions Lambda existantes, de spécifications d'API ou de points de terminaison de serveur MCP externes
-
Hébergement à partir d'une image ECR : Déployez un serveur MCP personnalisé à partir d'une image de conteneur
Note
La méthode de création ne peut pas être modifiée après le déploiement. Si vous devez changer de méthode, vous devez déployer un nouveau cas d'utilisation du serveur MCP.
Configuration de la passerelle (pour la méthode Lambda/API/MCP serveur)
Si vous avez sélectionné la méthode Gateway, configurez une ou plusieurs cibles :
-
Nom de la cible (obligatoire) : nom convivial pour identifier cette configuration cible
-
Description de la cible (facultatif) : brève description de ce que fait cette cible
-
Type de cible : sélectionnez le type de cible à configurer :
-
Lambda : pour les fonctions AWS Lambda
-
OpenAPI : pour REST avec les spécifications APIs OpenAPI
-
Smithy : Pour les définitions APIs du modèle Smithy
-
Serveur MCP : pour une connexion directe à des serveurs MCP externes via des points de terminaison URL
-
-
Fichier de schéma (obligatoire) : téléchargez le fichier de schéma qui décrit votre cible :
-
Pour Lambda : fichier de schéma JSON décrivant input/output le format. Pour plus d'informations sur la création de schémas d'outils Lambda, consultez le schéma d'outil Lambda dans le manuel Amazon Bedrock Developer Guide. AgentCore
-
Pour OpenAPI : fichier de spécification OpenAPI (JSON ou YAML). Pour en savoir plus sur les exigences du schéma OpenAPI, consultez le schéma OpenAPI dans le manuel Amazon Bedrock Developer Guide. AgentCore
-
Pour Smithy : fichier de modèle Smithy (.smithy ou .json). Pour en savoir plus sur la création de cibles Smithy, consultez la section Building Smithy targets dans le guide du développeur Amazon Bedrock AgentCore .
-
-
ARN de la fonction Lambda (obligatoire pour les cibles Lambda) : ARN de la fonction Lambda à intégrer
-
URL du serveur MCP (obligatoire pour les cibles du serveur MCP) : point de terminaison URL du serveur MCP externe auquel se connecter. L'URL doit être correctement encodée et le serveur MCP doit prendre en charge les fonctionnalités de l'outil avec les versions du protocole MCP 2025-06-18. Pour plus d'informations, consultez la section relative aux cibles des serveurs MCP dans le manuel Amazon Bedrock AgentCore Developer Guide.
-
Authentification sortante (obligatoire pour les cibles OpenAPI) : configurez l'authentification pour les appels d'API REST :
-
Type d'authentification : choisissez OAuth 2.0 ou clé API
-
ARN du fournisseur d'authentification sortant : ARN du fournisseur d'informations d'identification dans le coffre à jetons Amazon Bedrock AgentCore
-
Configurations supplémentaires : selon le type d'authentification :
-
Pour la OAuth version 2.0 : configurer les étendues et les paramètres personnalisés
-
Pour la clé d'API : spécifiez l'emplacement (en-tête ou paramètre de requête), le nom du paramètre et le préfixe facultatif
-
-
Vous pouvez ajouter plusieurs cibles (jusqu'à 10) en choisissant Ajouter une autre cible. Chaque cible représente un outil ou une fonctionnalité distinct exposé par votre serveur MCP.
Configuration ECR (pour la méthode ECR Image)
Si vous avez sélectionné la méthode Runtime, fournissez :
-
URI de l'image ECR (obligatoire) : l'URI complet de votre image Docker dans Amazon ECR
-
Format :
account-id.dkr.ecr.region.amazonaws.com/repository-name:tag -
L'image doit se trouver dans la même région AWS que votre déploiement
-
Une étiquette est requise (par exemple
:latest,:v1.0.0)
-
-
Variables d'environnement (facultatives) : configurez les paires clé-valeur à transmettre à votre conteneur lors de l'exécution
-
Utilisez-les pour fournir une configuration, des informations d'identification ou des indicateurs personnalisés
-
Vous pouvez ajouter jusqu'à 10 variables d'environnement
-
Vérification et déploiement
Après avoir configuré votre serveur MCP, passez en revue les paramètres que vous avez sélectionnés et choisissez Deploy Use Case. Le nouveau cas d'utilisation du serveur MCP est ensuite déployé et devient visible dans la vue du tableau de bord de déploiement pour une gestion ultérieure.
Note
Les déploiements de serveurs MCP créent des ressources dans Amazon Bedrock AgentCore, notamment des passerelles, des environnements d'exécution et des identités de charge de travail. Ces ressources sont automatiquement gérées par la solution et seront nettoyées lorsque vous supprimerez le cas d'utilisation.
Étape 3d : Déployer un cas d'utilisation d'Agent Builder
L'Agent Builder vous permet de créer, de configurer et de déployer des agents d'IA prêts à être utilisés en production sur Amazon Bedrock. AgentCore Cette fonctionnalité permet de contrôler totalement le comportement des agents grâce aux instructions du système, à la sélection du modèle, à l'intégration du serveur MCP et à la gestion de la mémoire.
Le processus de déploiement est essentiellement le même que pour un cas d'utilisation en mode texte, avec quelques différences notables.
Sélectionnez un cas d'utilisation
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Détails du cas d’utilisation
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Configuration de l'agent
Au cours de cette étape, vous configurez les paramètres principaux de l'agent, notamment l'invite système, les servers/Strands outils MCP disponibles et la mémoire.
Prompt du système
L'invite du système définit le comportement, la personnalité et les capacités de l'agent. Vous pouvez effectuer les actions suivantes :
-
Modifier le modèle d'invite système par défaut
-
Utilisez le bouton Rétablir par défaut pour restaurer le modèle d'origine
-
Incluez des instructions pour l'utilisation de l'outil et le formatage des réponses
Intégration au serveur MCP (facultatif)
Configurez les serveurs Model Context Protocol pour permettre à votre agent d'accéder aux outils et aux données de l'entreprise :
-
Sélectionnez l'un des serveurs MCP disponibles dans le menu déroulant
-
Passez en revue les outils prêts à l'emploi qui seront accessibles à l'agent
Note
Les serveurs MCP doivent être configurés et accessibles avant le déploiement. Reportez-vous à la documentation MCP pour les instructions de configuration du serveur.
Configuration de la mémoire
Configurez la manière dont l'agent gère le contexte et les connaissances :
-
Mémoire à court terme : activée par défaut pour tous les agents. Maintient le contexte des conversations au cours des sessions.
-
Mémoire à long terme : basculez pour activer l'extraction et le stockage des informations entre les sessions. Utilise AgentCore la mémoire avec une stratégie de mémoire sémantique.
Vérification et déploiement
Après cette étape, passez en revue les paramètres que vous avez sélectionnés et choisissez Deploy Use Case. Le déploiement d'Agent Builder prend généralement 10 à 15 minutes. Le nouveau cas d'utilisation devient alors visible dans la vue du tableau de bord de déploiement pour une gestion plus poussée.
Étape 3e : Déployer un cas d'utilisation du flux de travail
Le générateur de flux de travail vous permet de créer des agents superviseurs qui orchestrent plusieurs agents Agent Builder à l'aide du modèle de délégation Agents as Tools. Cette fonctionnalité vous permet de créer des flux de travail multi-agents complexes en réutilisant les déploiements d'Agent Builder existants.
Le processus de déploiement suit un schéma similaire à celui d'Agent Builder, avec des étapes supplémentaires pour la découverte et la sélection des agents.
Sélectionnez un cas d'utilisation
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Détails du cas d’utilisation
Cette étape est identique au cas d'utilisation du texte décrit précédemment.
Configuration de l'agent de supervision
Au cours de cette étape, vous configurez l'agent superviseur qui coordonnera les agents spécialisés Agent Builder.
Prompt du système
L'invite du système définit la manière dont l'agent superviseur délègue le travail aux agents spécialisés. Vous pouvez effectuer les actions suivantes :
-
Modifier le modèle d'invite système par défaut
-
Incluez des instructions pour la sélection et la délégation des agents
-
Définissez comment agréger les résultats de plusieurs agents
-
Utilisez le bouton Rétablir les paramètres par défaut pour restaurer le modèle d'origine
Note
L'invite du système doit clairement décrire quand et comment utiliser chaque agent spécialisé. Les descriptions des agents sont essentielles pour une délégation appropriée.
Sélection du modèle
Sélectionnez le modèle de base pour l'agent superviseur. L'agent superviseur utilise ce modèle pour :
-
Comprendre les demandes des utilisateurs
-
Sélectionnez les agents spécialisés appropriés
-
Coordonner l'exécution des agents
-
Agréger et mettre en forme les réponses
Sélectionnez des agents spécialisés
Au cours de cette étape, vous sélectionnez les agents Agent Builder auxquels le superviseur peut déléguer le travail.
Ajouter des agents
-
Cliquez sur Ajouter un agent pour ouvrir la boîte de dialogue de sélection de l'agent
-
Sélectionnez un ou plusieurs agents Agent Builder dans la liste
-
Passez en revue les descriptions des agents qui seront fournies au superviseur
-
Confirmez la sélection
Note
-
Les flux de travail nécessitent au moins un cas d'utilisation d'Agent Builder en tant qu'agent spécialisé
-
Tous les agents spécialisés doivent être déployés avec succès avant de créer le flux de travail
Vérification et déploiement
Passez en revue la configuration du flux de travail, notamment :
-
Prompt et modèle du système de l'agent superviseur
-
Liste des agents spécialisés
-
Réglages de mémoire
Choisissez Deploy Use Case. Le déploiement du flux de travail prend généralement 15 à 20 minutes. Le nouveau flux de travail devient visible dans la vue du tableau de bord de déploiement pour une gestion plus poussée.