Concepts de base pour Amazon Bedrock Gateway AgentCore

Une AgentCore passerelle fournit un point d'accès unique et sécurisé permettant à un agent d'accéder à des outils, à d'autres agents et à des modèles. Une passerelle peut avoir plusieurs cibles réparties en 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 une passerelle se connecte. 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 agrège dans un serveur MCP unifié. Les cibles HTTP définissent les HTTP-based services, tels que les agents AgentCore d'exécution et autres agents, auxquels le proxy de la passerelle demande directement. 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 les jetons, IAM (AWS Signature Version 4) pour l'autorisation basée sur l' AWS identité, authentification 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, il 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 attaché pour appeler 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 signature Sigv4 ou ne pas utiliser d'autorisation pour les points de terminaison accessibles au public.

Les cibles MCP fonctionnent en mode agrégation. La passerelle combine les fonctionnalités de toutes les cibles MCP dans un seul serveur MCP virtuel unifié. Les clients reçoivent 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 capacités ni la recherche d'outils sémantiques. Les clients s'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, les 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 de grands modèles linguistiques (LLM) 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 les 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 un outil, vous permettant d'implémenter une logique métier personnalisée dans votre langage de programmation préféré. La passerelle appelle la fonction Lambda et traduit la réponse au format MCP.

Utilisez les modèles Smithy pour définir vos interfaces d'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 instructions 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 annoncées par le serveur MCP.

Utilisez des modèles préconfigurés fournis par des fournisseurs d'intégration.

Utilisez des connecteurs intégrés aux outils.