Metas do Amazon Bedrock AgentCore Runtime
Você pode adicionar um agente Amazon Bedrock AgentCore Runtime como destino do gateway. O gateway envia tráfego diretamente para o agente de tempo de execução sem agregação ou tradução de protocolo. Ao contrário dos alvos MCP que combinam recursos de ferramentas em um servidor MCP virtual unificado, o destino AgentCore Runtime encaminha solicitações e respostas entre clientes e o agente de tempo de execução sem modificação.
Adicionar um destino AgentCore de tempo de execução ao seu gateway é útil quando você deseja:
-
Forneça gerenciamento de acesso centralizado para seus agentes de tempo de execução por meio de um único endpoint de gateway.
-
Use a autenticação e a observabilidade integradas do gateway para seus agentes de tempo de execução.
-
Encaminhe solicitações para agentes de tempo de execução específicos usando roteamento baseado em caminho quando vários destinos estão conectados a um gateway.
-
Otimize o desempenho do seu agente usando a AgentCore otimização do Amazon Bedrock para gerar recomendações a partir de rastreamentos de agentes, A/B testar alterações com tráfego ao vivo por meio do gateway e implantar configurações vencedoras. Para obter mais informações, consulte AgentCore otimização.
Tópicos
Principais considerações e limitações
Ao trabalhar com metas AgentCore de tempo de execução, esteja ciente das seguintes considerações:
-
O gateway envia tráfego diretamente para os destinos do AgentCore Runtime sem agregar recursos.
-
AgentCore Os alvos de tempo de execução podem ser adicionados aos gateways que não têm um tipo de protocolo definido. Eles não podem ser adicionados aos gateways do tipo de protocolo MCP.
-
Nenhuma sincronização de recursos ou pesquisa de ferramentas semânticas está disponível para destinos de AgentCore tempo de execução. Os clientes devem abordar cada alvo individualmente por meio de roteamento baseado em caminhos.
-
Server-Sent O streaming de eventos (SSE) é suportado para destinos AgentCore de tempo de execução.
-
As funções Lambda do interceptor de solicitações e respostas são suportadas no modo de buffer. Os interceptores ainda não são suportados no modo de streaming.
Configurações de destino
Ao criar um destino AgentCore de tempo de execução, você fornece o ARN do tempo de execução e um qualificador opcional. O gateway resolve o endpoint de tempo de execução internamente, então você não precisa criar o URL de tempo de execução sozinho.
A configuração de destino para um alvo AgentCore Runtime usa a seguinte estrutura:
{ "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 (obrigatório) — O ARN do agente Amazon AgentCore Bedrock Runtime.
-
qualificador (opcional) — O qualificador de tempo de execução. O padrão é
DEFAULT. -
esquema (opcional) — O esquema da API que descreve a estrutura de solicitação e resposta do alvo de tempo de execução. O gateway usa esse esquema para habilitar recursos do mecanismo de políticas, como grades de proteção. O formato do esquema é detectado automaticamente como OpenAPI ou Smithy.
Para agentes de tempo de execução que usam protocolos MCP ou A2A, um esquema padrão é aplicado automaticamente e você não precisa fornecer um. Para agentes de tempo de execução que usam o protocolo HTTP, você deve fornecer um esquema para usar grades de proteção.
O
schemaobjeto contém umsourceque especifica onde o conteúdo do esquema está localizado:-
s3 — Um URI do S3 apontando para o arquivo do esquema (por exemplo,).
s3://DOC-EXAMPLE-BUCKET/agent-schema.yaml -
InlinePayload — O conteúdo do esquema fornecido diretamente como uma string.
-
nota
Se seu agente de tempo de execução usa o protocolo HTTP e você deseja aplicar proteções por meio do mecanismo de políticas do gateway, você deve fornecer um esquema. Para agentes de tempo de execução que usam protocolos MCP ou A2A, um esquema padrão é aplicado automaticamente.
Invocando um alvo de AgentCore tempo de execução
Para invocar um destino AgentCore de tempo de execução por meio do gateway, envie uma solicitação POST para a URL de invocação do destino. O formato do URL é:
https://{gatewayId}.gateway.bedrock-agentcore.{region}.amazonaws.com/{targetName}/invocations
{gatewayId}Substitua pelo ID do gateway, pela AWS região e {targetName} pelo nome do destino. {region}
O exemplo a seguir usa curl para invocar um destino de AgentCore tempo de execução:
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"}}'
Você também pode usar o Amazon Bedrock AgentCore SDK com uma substituição de URL de endpoint:
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
Autorização de saída
AgentCore Os destinos de tempo de execução oferecem suporte aos seguintes tipos de autorização de saída:
-
IAM (SigV4) — O gateway assume a função de serviço do gateway para obter credenciais para assinar solicitações para o destino de tempo de execução. Ao configurar a autorização do IAM, você pode usar políticas do IAM para restringir o acesso exclusivo à função de gateway, garantindo que todas as solicitações de tempo de execução fluam pelo gateway.
-
Credenciais do IAM do chamador — O gateway usa as credenciais do IAM do chamador para assinar solicitações no destino do tempo de execução. O gateway assume uma função em nome do chamador e assina a solicitação de saída com a identidade do chamador.
-
OAuth (JWT) — O gateway recupera tokens OAuth de provedores de credenciais configurados no destino por meio do serviço de identidade Amazon Bedrock. AgentCore
-
Passagem do token — O gateway valida o token de entrada e o passa para o destino do tempo de execução sem modificação. Isso é útil quando o tempo de execução manipula sua própria autorização.
Impondo o tráfego por meio do gateway
Você pode usar um AgentCore gateway em seu AgentCore Runtime para que o gateway se torne o único ponto de entrada controlado para o tempo de execução, oferecendo autorização baseada em políticas, Amazon Bedrock Guardrails, interceptores de solicitações e respostas e observabilidade unificada, tudo aplicado fora do próprio ambiente do agente. Para obter a justificativa completa, consulte Enfrente seu tempo de execução com um AgentCore gateway. Mas isso só é útil se você não puder ignorar o gateway e acessar o tempo de execução diretamente. Agora você pode fazer isso independentemente de o tempo de execução usar a autorização de entrada IAM (SigV4) ou OAuth (JWT).
Você configura essa restrição no tempo de execução. O gateway marca a origem de cada solicitação que encaminha, e o tempo de execução valida essa fonte na entrada. O mecanismo específico depende do tipo de autorização de entrada do tempo de execução:
-
Tempos de execução do IAM (SigV4) — anexe uma política baseada em recursos que restrinja a invocação à função de execução do seu gateway. Para saber a política e o fortalecimento da política de confiança que ela exige, consulte Restringir a invocação de entrada do IAM (SigV4) ao seu gateway.
-
Tempos de execução do OAuth (JWT) — Configure
allowedWorkloadConfigurationno tempo de execuçãocustomJWTAuthorizerpara permitir somente a carga de trabalho do seu gateway. Para a configuração e a referência do campo, consulte Restringir a invocação ao seu gateway.
Comparação de capacidade com alvos de MCP
Você pode integrar servidores MCP ao AgentCore gateway Amazon Bedrock usando duas abordagens: usando o tipo de alvo MCP no modo de agregação ou usando o AgentCore tipo de destino Runtime. A tabela a seguir compara os recursos de cada abordagem.
| Recurso | Gateway MCP com alvos MCP | AgentCore Objetivo de tempo |
|---|---|---|
|
Tool/capability agregação |
Agrega recursos de todos os destinos MCP em um único servidor MCP virtual unificado. Os clientes veem uma |
Opera de forma isolada. O gateway envia tráfego diretamente para o destino sem mesclar recursos. Os clientes devem abordar cada alvo individualmente por meio de roteamento baseado em caminhos. |
|
Pesquisa de ferramentas semânticas |
Indexa as descrições das ferramentas e permite a descoberta por meio de consultas em linguagem natural. |
Não disponível. O gateway não ingere nem indexa recursos. Os clientes devem saber os nomes exatos das ferramentas ou usar os do próprio servidor |
|
Interceptor de resposta Lambda |
Suporta interceptores de solicitação e resposta para operações MCP sem streaming. |
Suporta as funções Lambda do interceptor de solicitações e respostas no modo buffer. Os interceptores ainda não são suportados no modo de streaming. |