Concepts fondamentaux d'Amazon Bedrock Gateway AgentCore

Une AgentCore passerelle fournit un point d'accès sécurisé unique permettant à un agent d'accéder à des outils, à d'autres agents et à des modèles. Une passerelle peut avoir plusieurs cibles dans trois catégories : MCP, HTTP et inférence. Pour les cibles MCP, la passerelle fonctionne en mode agrégation, agissant comme un serveur MCP qui combine les capacités de toutes ses cibles MCP dans un serveur MCP virtuel unifié. Pour les cibles HTTP, la passerelle envoie le trafic directement à la cible (par exemple, un autre agent ou un service A2A) sans agrégation ni traduction de protocole. Pour les cibles d'inférence, la passerelle achemine les demandes LLM vers un ou plusieurs fournisseurs de modèles via un point de terminaison de routage unifié basé sur un modèle.

Une cible définit le backend auquel se connecte une passerelle. Il existe trois catégories de cibles. Les cibles MCP définissent des API, des fonctions Lambda, des serveurs MCP ou des définitions d'outils que la passerelle regroupe dans un serveur MCP unifié. Les cibles HTTP définissent HTTP-based des services, tels que des agents AgentCore d'exécution et d'autres agents, auxquels la passerelle envoie directement les requêtes. Les cibles d'inférence acheminent le trafic LLM vers un ou plusieurs fournisseurs de modèles via un point de terminaison unifié, en sélectionnant la destination en fonction du modèle demandé.

Chaque passerelle doit disposer d'une configuration d'autorisation entrante pour contrôler l'accès des clients. La passerelle prend en charge les types d'autorisation entrante suivants : OAuth (JWT) pour l'autorisation basée sur des jetons, IAM (AWS Signature Version 4) pour l'autorisation basée sur l' AWS identité, authentifier uniquement pour valider les jetons tout en déléguant l'autorisation à la cible, et aucune autorisation pour les scénarios de développement et de test. Vous pouvez configurer l'autorisateur lorsque vous créez ou mettez à jour une passerelle.

Lorsque Gateway appelle vos API ou votre fonction Lambda, elle doit utiliser certaines informations d'identification pour accéder à ces fonctionnalités. Lorsque vous créez une cible Smithy ou Lambda, Gateway utilise le rôle d'exécution associé pour passer des appels vers ces cibles. Lorsque vous créez une cible de serveur OpenAPI ou MCP, vous pouvez associer un fournisseur AgentCore d'informations d'identification qui stocke la clé API ou les informations d'identification OAuth, configurer l' IAM-based autorisation avec la signature Sigv4 ou n'utiliser aucune autorisation pour les terminaux accessibles au public.

Les cibles MCP fonctionnent en mode agrégation. La passerelle combine les capacités de toutes les cibles MCP en un seul serveur MCP virtuel unifié. Les clients obtiennent une tools/list réponse consolidée qui inclut les outils de toutes les cibles MCP associées. Les cibles MCP prennent en charge la synchronisation des capacités, la recherche d'outils sémantiques et l'OAuth à trois branches (3LO) au niveau de la cible. Les types de cibles MCP incluent les fonctions Lambda, les API REST API Gateway, les spécifications OpenAPI, les modèles Smithy, les serveurs MCP, les modèles de fournisseurs d'intégration intégrés et les connecteurs intégrés aux outils.

Les cibles HTTP envoient le trafic directement à la cible sans agrégation ni traduction de protocole. Les cibles HTTP ne prennent pas en charge la synchronisation des fonctionnalités ni la recherche d'outils sémantiques. Les clients adressent chaque cible individuellement par le biais d'un routage basé sur le chemin. Les types de cibles HTTP incluent les agents Amazon Bedrock AgentCore Runtime, d'autres agents Agent-to-Agent (y compris les services (A2A)), les serveurs MCP externes et tout point de terminaison HTTP atteint via une cible intermédiaire.

Les cibles d'inférence acheminent le trafic LLM (Large Language Model) vers un ou plusieurs fournisseurs de modèles via un point de terminaison unifié. La passerelle sélectionne le fournisseur de destination en fonction du model champ de la demande, offrant ainsi aux agents une interface unique et cohérente entre des fournisseurs tels qu'Amazon Bedrock, OpenAI et Anthropic.

Transformez les API REST existantes en MCP-compatible outils en fournissant une spécification OpenAPI. La passerelle gère automatiquement la traduction entre les formats MCP et REST.

Connect Lambda fonctionne comme des outils, vous permettant d'implémenter une logique métier personnalisée dans votre langage de programmation préféré. La passerelle invoque la fonction Lambda et traduit la réponse au format MCP.

Utilisez les modèles Smithy pour définir vos interfaces API et générer des MCP-compatible outils. Smithy est un langage permettant de définir les services et les SDK qui peuvent être utilisés avec AWS les services. La passerelle peut utiliser les modèles Smithy pour générer des outils qui interagissent avec des AWS services ou des API personnalisées.

Utilisez des serveurs MCP distants pour connecter des outils, des instructions et des ressources à l'environnement d'exécution de votre agent. Gateway prend en charge les outils, les invites et les fonctionnalités de ressources MCP. Des outils sont nécessaires ; les instructions et les ressources sont facultatives. Les invites fournissent des modèles d'invite réutilisables avec des arguments. Les ressources fournissent des données contextuelles identifiées par des URI. Au cours de la synchronisation, la passerelle découvre toutes les fonctionnalités proposées par le serveur MCP.

Utilisez des modèles préconfigurés provenant de fournisseurs d'intégration.

Utilisez des connecteurs intégrés pour les outils.