View a markdown version of this page

Objectifs Amazon Bedrock AgentCore Runtime - Base rocheuse de l'Amazonie AgentCore

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.

Objectifs Amazon Bedrock AgentCore Runtime

Vous pouvez ajouter un agent Amazon Bedrock AgentCore Runtime en tant que cible de passerelle. La passerelle envoie le trafic directement à l'agent d'exécution sans agrégation ni traduction de protocole. Contrairement aux cibles MCP qui combinent les fonctionnalités des outils au sein d'un serveur MCP virtuel unifié, la cible AgentCore Runtime transmet les demandes et les réponses entre les clients et l'agent d'exécution sans modification.

L'ajout AgentCore d'une cible Runtime à votre passerelle est utile lorsque vous souhaitez :

  • Offrez une gestion centralisée des accès à vos agents d'exécution via un point de terminaison de passerelle unique.

  • Utilisez l'authentification et l'observabilité intégrées de la passerelle pour vos agents d'exécution.

  • Acheminez les demandes vers des agents d'exécution spécifiques à l'aide d'un routage basé sur le chemin lorsque plusieurs cibles sont attachées à une passerelle.

  • Optimisez les performances de votre agent en utilisant l' AgentCore optimisation Amazon Bedrock pour générer des recommandations à partir des traces des agents, A/B tester les modifications avec le trafic en direct via la passerelle et déployer des configurations gagnantes. Pour plus d'informations, consultez la section AgentCore Optimisation.

Principales considérations et limites

Lorsque vous travaillez avec des cibles AgentCore Runtime, tenez compte des points suivants :

  • La passerelle envoie le trafic directement aux cibles AgentCore Runtime sans fonctionnalités d'agrégation.

  • AgentCore Les cibles d'exécution peuvent être ajoutées aux passerelles pour lesquelles aucun type de protocole n'est défini. Ils ne peuvent pas être ajoutés aux passerelles de type protocole MCP.

  • Aucune synchronisation des fonctionnalités ou aucune recherche d'outil sémantique n'est disponible pour les cibles AgentCore Runtime. Les clients doivent adresser chaque cible individuellement par le biais d'un routage basé sur le chemin.

  • Server-Sent Le streaming d'événements (SSE) est pris en charge pour les cibles AgentCore Runtime.

  • Les fonctions Lambda de l'intercepteur de requêtes et de réponses sont prises en charge en mode tampon. Les intercepteurs ne sont pas encore pris en charge en mode streaming.

Configuration cible

Lorsque vous créez une cible AgentCore d'exécution, vous fournissez l'ARN d'exécution et un qualificatif facultatif. La passerelle résout le point de terminaison d'exécution en interne, vous n'avez donc pas besoin de créer vous-même l'URL d'exécution.

La configuration cible d'une cible AgentCore Runtime utilise la structure suivante :

{ "http": { "agentcoreRuntime": { "arn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID", "qualifier": "DEFAULT", "schema": { "source": { "s3": { "uri": "s3://DOC-EXAMPLE-BUCKET/agent-schema.yaml" } } } } } }
  • arn (obligatoire) : ARN de l'agent Amazon Bedrock AgentCore Runtime.

  • qualificatif (facultatif) — Le qualificatif d'exécution. La valeur par défaut est DEFAULT .

  • schéma (facultatif) : schéma d'API qui décrit la structure de demande et de réponse de la cible d'exécution. La passerelle utilise ce schéma pour activer les fonctionnalités du moteur de politiques telles que les garde-corps. Le format du schéma est détecté automatiquement en tant que OpenAPI ou Smithy.

    Pour les agents d'exécution qui utilisent les protocoles MCP ou A2A, un schéma par défaut est appliqué automatiquement et vous n'avez pas besoin d'en fournir un. Pour les agents d'exécution qui utilisent le protocole HTTP, vous devez fournir un schéma pour utiliser des garde-corps.

    L'schemaobjet contient un source qui indique où se trouve le contenu du schéma :

    • s3 — Un URI S3 pointant vers le fichier de schéma (par exemple,s3://DOC-EXAMPLE-BUCKET/agent-schema.yaml).

    • InlinePayload — Le contenu du schéma est fourni directement sous forme de chaîne.

Note

Si votre agent d'exécution utilise le protocole HTTP et que vous souhaitez appliquer des garde-fous via le moteur de politiques de la passerelle, vous devez fournir un schéma. Pour les agents d'exécution qui utilisent les protocoles MCP ou A2A, un schéma par défaut est automatiquement appliqué.

Invocation d'une cible AgentCore d'exécution

Pour invoquer une cible AgentCore Runtime via la passerelle, envoyez une requête POST à l'URL d'invocation de la cible. Le format de l'URL est le suivant :

https://{gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com/{targetName}/invocations

{gatewayId}Remplacez-le par l'ID de votre passerelle, {region} par la AWS région et {targetName} par le nom de la cible.

L'exemple suivant utilise curl pour invoquer une cible AgentCore Runtime :

curl -X POST https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/my-target/invocations \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"input": {"prompt": "Hello"}}'

Vous pouvez également utiliser le AgentCore SDK Amazon Bedrock en remplaçant l'URL du point de terminaison :

aws bedrock-agentcore invoke-agent-runtime \ --endpoint-url https://gateway-id.gateway.bedrock-agentcore.us-west-2.amazonaws.com/my-target \ --runtimeArn arn:aws:bedrock-agentcore:us-west-2:111122223333:runtime/RUNTIME_ID

Autorisation sortante

AgentCore Les cibles d'exécution prennent en charge les types d'autorisation sortante suivants :

  • IAM (Sigv4)  : la passerelle assume le rôle de service de passerelle pour obtenir les informations d'identification nécessaires à la signature des demandes adressées à la cible d'exécution. Lorsque vous configurez l'autorisation IAM, vous pouvez utiliser des politiques IAM pour restreindre l'accès exclusivement au rôle de passerelle, en veillant à ce que toutes les demandes d'exécution passent par la passerelle.

  • Informations d'identification IAM de l'appelant  : la passerelle utilise les informations d'identification IAM de l'appelant pour signer les demandes adressées à la cible d'exécution. La passerelle joue un rôle au nom de l'appelant et signe la demande sortante avec l'identité de l'appelant.

  • OAuth (JWT) — La passerelle récupère les jetons OAuth auprès des fournisseurs d'informations d'identification configurés dans la cible via le service d'identité Amazon Bedrock. AgentCore

  • Passthrough du jeton  : la passerelle valide le jeton entrant et le transmet à la cible d'exécution sans modification. Ceci est utile lorsque le moteur d'exécution gère sa propre autorisation.

Exécution du trafic via la passerelle

Vous pouvez intégrer une AgentCore passerelle à votre AgentCore environnement d'exécution afin que celle-ci devienne le point d'entrée unique et régi du runtime, ce qui vous donne accès à une autorisation basée sur des règles, à Amazon Bedrock Guardrails, à des intercepteurs de demandes et de réponses et à une observabilité unifiée, le tout appliqué en dehors de l'environnement de l'agent. Pour en savoir plus, consultez la section Démarrez votre environnement d'exécution avec une AgentCore passerelle. Mais cela n'est utile que si vous ne pouvez pas contourner la passerelle et accéder directement au runtime. Vous pouvez désormais y parvenir, que le moteur d'exécution utilise l'autorisation entrante IAM (Sigv4) ou OAuth (JWT).

Vous configurez cette restriction sur le runtime. La passerelle marque la source de chaque requête qu'elle transmet, et le moteur d'exécution valide cette source en cours d'entrée. Le mécanisme spécifique dépend du type d'autorisation entrante du runtime :

  • Runtimes IAM (Sigv4)  : associez une politique basée sur les ressources qui limite l'invocation au rôle d'exécution de votre passerelle. Pour connaître la politique et le renforcement de la politique de confiance qu'elle nécessite, voir Restreindre les appels entrants IAM (Sigv4) vers votre passerelle.

  • Runtimes OAuth (JWT)  : configurez allowedWorkloadConfiguration les environnements d'exécution customJWTAuthorizer pour autoriser uniquement la charge de travail de votre passerelle. Pour la configuration et la référence des champs, voir Restreindre l'invocation à votre passerelle.

Comparaison des capacités avec les cibles MCP

Vous pouvez intégrer des serveurs MCP à la AgentCore passerelle Amazon Bedrock en utilisant deux approches : en utilisant le type de cible MCP en mode agrégation ou en utilisant le type de cible AgentCore Runtime. Le tableau suivant compare les capacités de chaque approche.

Capacité Passerelle MCP avec cibles MCP AgentCore Objectif d'exécution

Tool/capability agrégation

Regroupe les fonctionnalités de toutes les cibles MCP dans un seul serveur MCP virtuel unifié. Les clients obtiennent une tools/list réponse consolidée.

Fonctionne de manière isolée. La passerelle envoie le trafic directement à la cible sans fusionner les fonctionnalités. Les clients doivent adresser chaque cible individuellement par le biais d'un routage basé sur le chemin.

Recherche d'outils sémantiques

Indexe les descriptions des outils et permet leur découverte à l'aide de requêtes en langage naturel.

Indisponible. La passerelle n'ingère ni n'indexe les fonctionnalités. Les clients doivent connaître le nom exact des outils ou utiliser celui du serveurtools/list.

Intercepteur de réponse Lambda

Supporte à la fois les intercepteurs de requêtes et de réponses pour les opérations MCP hors diffusion.

Supporte les fonctions Lambda de l'intercepteur de requêtes et de réponses en mode tampon. Les intercepteurs ne sont pas encore pris en charge en mode streaming.