Configure rate limits for AI traffic on AgentCore gateway

在 AgentCore 网关上配置 AI 流量的速率限制 | 人工智能

在 AgentCore 网关上配置 AI 流量的速率限制

Amazon Bedrock AgentCore 网关是一个全托管的无服务器 AI 网关，为 AI 流量提供单一且安全的接入入口。AgentCore 网关将流量路由到托管网络搜索、托管知识库、MCP 服务器、推理模型（LLM）、代理（A2A、代理作为工具等）或 HTTP 端点等工具。今天，我们宣布在 AgentCore 网关上新增速率限制功能，让您能够对通过网关的单个用户流量进行更精细的控制。

AgentCore 网关的速率限制功能使您能够按用户粒度控制用户对工具、推理模型和代理的使用情况。您可以基于 OAuth 或 IAM 定义每分钟请求数、并发连接数和令牌吞吐量的规则，确保在流量高峰期间下游服务始终保持可用。

使用 AgentCore 网关实现 AI 流量的集中式速率限制

AgentCore 网关提供三种目标类型：MCP 目标、推理目标和 HTTP 透传目标。以下速率限制指标适用于这些目标：

• 请求速率限制，以每秒请求数（RPS）和每分钟请求数（RPM）衡量，适用于所有目标类型。每个限制定义了在指定时间窗口内允许的最大请求数，网关会将每个传入请求与该限制进行比对。无论请求完成时间长短，每个请求都计为一个单位。例如，一个耗时 50 毫秒的请求和一个持续 90 秒的流式请求，都会消耗相同的一个单位配额。

• 令牌速率限制，以每分钟令牌数（TPM）衡量，仅适用于推理目标。令牌速率限制同时涵盖输入令牌和输出令牌。请求的完整往返令牌成本将计入限制配额。AgentCore 网关使用通用分词器预估请求的输入令牌数量，并在网关分发推理调用前直接从速率限制桶中扣除该数量。当推理调用返回响应（包含模型提供商报告的实际输入和输出令牌使用情况）后，网关将根据实际令牌消耗情况进行配额调整。

• 连接速率限制，以每秒连接数（CPS）衡量，适用于所有目标类型。与请求速率限制不同，连接速率限制会跟踪每个请求保持开放连接的时间长度。例如，如果一个流式推理调用耗时 100 秒完成，该请求在整个持续时间内会占用一个连接槽位。CPS 提供了一种额外机制，用于保护目标免受长期并发会话的影响，特别适用于需要限制目标同时连接数上限（而非每个窗口内请求数）的场景。

对于此使用场景，假设有三个用户组：Basic（基础）、Advanced（高级）和 Beta（测试）。AgentCore 身份验证通过 JSON 网络令牌（JWT）处理入站认证，使用 Microsoft Entra ID 作为身份提供商，同时作为出站目标的令牌发放服务。Amazon Bedrock AgentCore 中的策略强制实施基于角色的访问控制（RBAC），将每个用户组的访问权限限定到特定目标和模型。下图展示了该配置的示意图。

图1：AgentCore网关速率限制架构，包含用户组、身份和策略执行

基础用户受到比高级用户更严格的速率限制，而Beta用户在受限模型上获得更高的速率限制，使组织能够在向更广泛的组织推广这些模型之前，对性能和适用性进行基准测试。在为每个用户组设置速率限制之前，请先查看速率限制结构。

速率限制结构

速率限制配置由两部分组成：维度键和条目。维度键定义网关如何将入站流量分组到速率桶中。条目定义每个桶允许的吞吐量。

在本文中，我们使用AWS命令行界面（AWS CLI）创建速率限制配置。以下示例展示了维度键和条目之间的关系。该速率限制使用targetName作为维度键，并定义了两个条目：一个针对预订目标（MCP服务器）的特定条目，限速为每秒100次请求；以及一个通配符条目，对每个剩余目标单独应用每秒10次请求的限制，这意味着每个其他目标都会获得自己的每秒10次请求桶。

图2：包含维度键和条目的速率限制结构

维度键定义网关如何将流量分组到速率桶中。当请求到达时，网关会从请求上下文中解析每个维度键的值，并使用得到的组合将请求分配到正确的速率桶。AgentCore网关支持以下维度键：targetName、toolName、qualifiedModelId、$.context.jwt.<claim>、$.context.iam.principal和$.context.iam.sourceIdentity。我们将在后续章节通过示例逐一探讨这些维度键。

条目是速率限制中的规则。每个条目指定要匹配的一组维度键，以及该匹配允许的吞吐量。条目支持特殊通配符默认值*，该值为每个不同值分配独立的桶，并按照配置的速率进行限制。当网关评估请求时，会先按名称检查条目是否匹配，再回退到通配符匹配。命名条目具有优先级，因为它明确引用了值，而不是依赖通配符。

以先前的速率限制为例，当请求到达预订目标（MCP服务器）时，网关会匹配第一条目并允许最高达每秒100次请求。该条目具有优先级，因为最具体的值匹配会优先于默认值*，因为它通过名称明确引用了预订目标。对于任何其他目标，由于不存在命名条目，网关会回退到通配符条目并允许最高达每秒10次请求。每个匹配通配符的目标（Docs、BedrockMantle、CustomPlatform和awsdocsagent）都会获得自己的独立桶。

您可以组合多个维度键以实现更精细的控制。例如，dimensionKeys: ["targetName", "$.context.jwt.role"]会根据目标和调用者身份角色声明对流量进行分组，使每个用户组（如前面示例中的基础、高级或Beta用户）在每个目标下都有自己的独立速率桶。

速率限制类型及示例配置

AgentCore 网关实施了两层速率限制机制：客户自定义速率限制和服务配额。系统会优先评估客户自定义速率限制。如果请求通过该限制，将接着评估服务配额。以下部分将解释服务配额和不同类型的客户自定义速率限制。

• 服务管理配额

这些是服务在每个 AWS 账户上对 AgentCore 网关实施的限制。服务管理配额定义了客户自定义速率限制不能超过的上限。请求的实际有效速率是客户自定义限制和服务管理限制中的较小值。对于某些配额，您可以使用 Service Quotas 控制台申请提高配额。

• 客户自定义用户限制

用户级限制使用 $.context.jwt.<claim>、$.context.iam.principal 和 $.context.iam.sourceIdentity 作为维度键，用于控制单个用户或整个用户组可以消耗的流量。这些限制确保调用者群体的公平使用，防止任何单个调用者独占网关容量。以下示例为不同用户组分配了不同的请求速率。JWT 角色声明是一个数组，因此每个唯一组合都需要单独的条目。

aws bedrock-agentcore-control create-gateway-rate-limit \
  --gateway-identifier my-gateway-abc1234567 \
  --dimension-keys '["$.context.jwt.role"]' \
  --description "Per-role request and connection limit" \
  --entries '[
    {
      "dimensions": {"$.context.jwt.role": "[\"Basic\"]"},
      "requests": [{"rate": 100, "period": "minute"}],
      "connections": [{"rate": 50, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\"]"},
      "requests": [{"rate": 300, "period": "minute"}],
      "connections": [{"rate": 150, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\", \"Beta\"]"},
      "requests": [{"rate": 300, "period": "minute"}],
      "connections": [{"rate": 200, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "*"},
      "requests": [{"rate": 80, "period": "minute"}],
      "connections": [{"rate": 10, "period": "second"}]
    }
  ]'

在此配置中，Basic 用户获得两个桶：100 RPM 和 50 CPS，这意味着任何 Basic 用户的每个请求都会计入相同的 100 RPM 总量，每个连接也会计入相同的 50 CPS 总量。如果一个 Basic 用户在一分钟内发送 80 个请求，则该窗口内所有其他 Basic 用户仅剩 20 个请求配额。Advanced 用户拥有自己的两个桶：300 RPM 和 150 CPS，受相同集体行为规则约束。拥有 ["Advanced", "Beta"] 组成员身份的用户获得 300 RPM 和 200 CPS 的两个桶。更高的连接配额可满足其以流式处理为主的基准测试工作负载。

然而，在组内，单个用户仍可能消耗整个组的配额桶，导致该组内其他用户被限流。例如，一个 Basic 用户在一分钟内发送 100 个请求，将导致其他所有 Basic 用户在该窗口内没有可用容量。为防止这种情况，我们还需要创建以下速率限制配置。

aws bedrock-agentcore-control create-gateway-rate-limit \
  --gateway-identifier my-gateway-abc1234567 \
  --dimension-keys '["$.context.jwt.role", "$.context.jwt.sub"]' \
  --description "Per-user request and connection limit within each role" \
  --entries '[
    {
      "dimensions": {"$.context.jwt.role": "[\"Basic\"]", "$.context.jwt.sub": "*"},
      "requests": [{"rate": 20, "period": "minute"}],
      "connections": [{"rate": 10, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\"]", "$.context.jwt.sub": "*"},
      "requests": [{"rate": 60, "period": "minute"}],
      "connections": [{"rate": 30, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\", \"Beta\"]", "$.context.jwt.sub": "*"},
      "requests": [{"rate": 60, "period": "minute"}],
      "connections": [{"rate": 50, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "*", "$.context.jwt.sub": "*"},
      "requests": [{"rate": 20, "period": "minute"}],
      "connections": [{"rate": 20, "period": "second"}]
    }
  ]'

通过此配置，每个用户无论其所在组中有多少用户，其个人请求和连接速率都将被单独限制。JWT中的$.context.jwt.sub声明可唯一标识每个用户，使网关能够跟踪并执行针对个人的限制。即使组级限制允许Basic组每分钟100次请求，但任何单个用户都不能超过每分钟20次请求和每秒10次连接的共享池配额。高级用户和Beta用户的相同逻辑也适用于其各自的个人限制。组级限制和用户级限制共同构成了双层执行模型：组级上限可防止一个组占用其他组的资源，用户级上限可防止同一组内的某个用户占用其他用户的资源。

两个速率限制分别独立评估，采用AND语义。请求必须同时通过组级限制和用户级限制才能继续。如果任一检查拒绝请求，网关将返回限流响应。例如，如果Arnav（Basic用户）已单独消耗了每分钟20次请求，即使Basic组仍有80次请求配额剩余，他的下一个请求仍会被用户级限制拒绝。相反，如果Basic组整体已消耗了每分钟100次请求，所有Basic用户都将被限流，无论其个人消耗情况如何。

• 客户自定义目标级限制

目标级限制使用targetName、qualifiedModelId或toolName作为维度键，用于控制对特定下游目标、模型或工具的吞吐量。这些限制可保护后端资源容量，并在目标资源之间分配负载。以下示例展示了如何按目标级别限制流量。

aws bedrock-agentcore-control create-gateway-rate-limit \
  --gateway-identifier my-gateway-abc1234567 \
  --dimension-keys '["targetName"]' \
  --description "Per-target rate limit" \
  --entries '[
    {
      "dimensions": {"targetName": "Booking"},
      "requests": [{"rate": 20, "period": "second"}]
    },
    {
      "dimensions": {"targetName": "Docs"},
      "requests": [{"rate": 15, "period": "second"}]
    },
    {
      "dimensions": {"targetName": "awsdocsagent"},
      "requests": [{"rate": 10, "period": "second"}],
      "connections": [{"rate": 60, "period": "second"}]
    },
    {
      "dimensions": {"targetName": "BedrockMantle"},
      "tokens": [{"rate": 100000, "period": "minute"}],
      "connections": [{"rate": 250, "period": "second"}]
    },
    {
      "dimensions": {"targetName": "CustomPlatform"},
      "tokens": [{"rate": 50000, "period": "minute"}],
      "connections": [{"rate": 100, "period": "second"}]
    },
    {
      "dimensions": {"targetName": "*"},
      "tokens": [{"rate": 10000, "period": "minute"}],
      "requests": [{"rate": 10, "period": "second"}],
      "connections": [{"rate": 50, "period": "second"}]
    }
  ]'

你也可以使用 qualifiedModelId 为每个模型设置连接速率限制（CPS），或使用 toolName 为单个工具（如 Booking___bookTool 或 Docs___searchDocsTool）设置请求速率限制（RPS）。

注意：我们排除了客户自定义的目标级别速率限制配置。Beta 用户会对受限模型执行大量基准测试工作负载，消耗不成比例的共享目标级别配额。由于此限制仅基于 targetName 维度，所有用户共享同一个上限，这意味着某一群组或个人的高流量可能会导致其他用户在该目标上资源不足。当预期某部分用户会在特定目标上主导令牌或连接消耗时，应改为通过身份维度进行限制（例如：["targetName", "$.context.jwt.role"]）。请参见以下示例。

• 客户自定义的目标-用户级别限制。

混合限制将目标和用户维度结合在单一速率限制配置中，为你提供最细粒度的控制。通过多维度键，你可以将速率限制范围限定到特定目标、模型或工具上的特定用户或用户组。

以下示例在模型级别实施令牌限制，并限定到每个用户组内的每个用户。qualifiedModelId 维度是推理目标的完全限定模型标识符，可唯一标识被调用的模型（详见文档）。

aws bedrock-agentcore-control create-gateway-rate-limit \
  --gateway-identifier my-gateway-abc1234567 \
  --dimension-keys '["$.context.jwt.role", "qualifiedModelId", "$.context.jwt.sub"]' \
  --description "Per-user per-role per-model TPM and access limit" \
  --entries '[
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\", \"Beta\"]", "qualifiedModelId": "anthropic.claude-fable-5", "$.context.jwt.sub": "*"},
      "tokens": [{"rate": 80000, "period": "minute"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Basic\"]", "qualifiedModelId": "anthropic.claude-fable-5", "$.context.jwt.sub": "*"},
      "requests": [{"rate": 0, "period": "second"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\"]", "qualifiedModelId": "anthropic.claude-fable-5", "$.context.jwt.sub": "*"},
      "requests": [{"rate": 0, "period": "second"}]
    },
    ... (repeat for openai.gpt-5.6-luna and openai.gpt-5.6-terra)
    {
      "dimensions": {"$.context.jwt.role": "[\"Advanced\"]", "qualifiedModelId": "*", "$.context.jwt.sub": "*"},
      "tokens": [{"rate": 40000, "period": "minute"}]
    },
    {
      "dimensions": {"$.context.jwt.role": "[\"Basic\"]", "qualifiedModelId": "*", "$.context.jwt.sub": "*"},
      "tokens": [{"rate": 20000, "period": "minute"}]
    }
  ]'

在此配置中，anthropic.claude-fable-5 是一个受限模型。只有具有 [“Advanced”, “Beta”] 角色的用户才能调用它，每个用户可获得 80,000 TPM 用于基准测试和评估工作负载。[“Basic”] 和 [“Advanced”] 用户均被禁止调用此模型，速率设为零。其他受限模型（openai.gpt-5.6-luna 和 openai.gpt-5.6-terra）采用相同模式，请确保为每个模型添加结构相同的条目。对于通用可用模型，Basic 用户每人可获得 20,000 TPM，Advanced 用户每人可获得 40,000 TPM，通过通配符条目实现。

具体条目优先于通配符，遵循“最具体匹配优先”规则。当 María（sub: “María”，role: [“Advanced”, “Beta”]）调用 anthropic.claude-fable-5 时，网关匹配显式条目，为 María 个人应用 80,000 TPM 限制。如果 María 用尽 80,000 TPM 配额，其他 Beta 用户不受影响，因为 * 在 $.context.jwt.sub 上为每个用户分配了独立的存储桶。当 John（sub: “John”，role: [“Advanced”]）尝试调用 anthropic.claude-fable-5 时，网关匹配该模型的显式 [“Advanced”] 条目，将请求速率设为零，阻止调用。当 John 调用通用可用模型（如 anthropic.claude-sonnet-5）时，由于没有该模型角色组合的显式条目，网关会回退到 [“Advanced”] 的通配符条目，应用 40,000 TPM 限制。当 Arnav（sub: “Arnav”，role: [“Basic”]）调用相同通用可用模型时，他通过 Basic 通配符条目获得 20,000 TPM。

还可以组合维度，例如 [“ $.context.jwt.role ”, “ targetName ”] 用于按角色/目标的请求限制，[“ $.context.jwt.sub ”, “ targetName ”] 用于按用户/目标的请求和令牌组合限制，或 [“ $.context.jwt.role ”, “ toolName ”] 用于按角色/工具的请求限制。有关更多速率限制配置，请参阅 速率限制 API 示例。

代理工作负载的速率限制

/think

考虑以下 AgentCore 网关配置示例，其中用户调用 AWS 文档代理。该代理通过网关使用两个下游资源：用于文档搜索和检索的 Docs MCP 目标，以及通过 anthropic.claude-sonnet-5 模型进行推理的 BedrockMantle 推理目标。以下架构展示了这一场景：

图 3：智能代理工作负载的下游资源消耗速率限制

智能代理工作负载需要考虑两种类型的速率限制：

• 代理调用的速率限制

第一类限制保护用户或其他服务调用代理的频率。这些是针对代理目标本身的请求（RPM）和连接（CPS）限制。在最简单的情况下，仅根据目标名称进行维度划分，例如 {“targetName”: “awsdocsagent”}，这样所有用户共享一个调用上限。对于更精细的控制，可以将目标名称与用户维度（如 [“targetName”, “$.context.jwt.role”] 或 [“targetName”, “$.context.jwt.role”, “$.context.jwt.sub”]）组合，以限制每个用户组或单个用户调用代理的频率。

• 代理消耗资源的速率限制

第二类限制保护代理在每次调用时消耗的下游资源。AWS 文档代理会触发多个下游请求。代理会调用 Docs MCP 目标进行文档检索，调用 BedrockMantle 目标进行推理。如何对这些下游调用进行速率限制，取决于代理在调用这些资源时如何向网关进行身份验证。

如果代理基于用户传入的 JWT 令牌执行代表用户（OBO）令牌交换，那么下游请求将携带原始用户的身份。所有现有的基于用户的速率限制都适用。之前配置的每角色和每用户限制将应用于代理的下游调用，就像用户直接发起请求一样。

然而，如果代理通过机器到机器授权获取新令牌（例如客户端凭据流程），下游请求将携带代理自身的身份，而不是调用方的身份。在这种情况下，基于用户的速率限制将无法匹配用户的声明。应添加基于代理自身身份的速率限制，根据您的身份提供商使用唯一标识代理的声明（如 $.context.jwt.azp（授权方）），并相应限制，以防止单个代理耗尽共享资源。

速率限制最佳实践

在使用 AgentCore 网关创建速率限制时，请遵循以下最佳实践：

• 如果您在 AgentCore 中使用策略来实施基于角色的访问控制（RBAC）授权，请理解评估顺序非常重要。速率限制首先应用；AgentCore 策略在之后评估。这意味着即使用户或角色最终被 AgentCore 策略拒绝访问，其请求仍会在拒绝发生前消耗速率限制配额。为避免这种消耗，请创建明确将速率设为零的速率限制条目，针对 AgentCore 策略会阻止的用户或组，这确保请求在速率限制层被拒绝，而不会消耗授权调用者的可用预算。

• 网关优先使用更多维度键（更具体的限制具有更高优先级）评估速率限制。在维度数量相同的情况下，网关优先评估限制更严格（数值更低）的速率限制。评估过程在首次拒绝请求时会中断，这意味着一旦请求被拒绝，网关将不再评估剩余的速率限制。请设计速率限制配置，使最严格的限制位于最高维度层级（例如，三键 [“$.context.jwt.role”, “qualifiedModelId”, “$.context.jwt.sub”] 限制）。

• 在相同网关上，不能创建具有相同维度键但顺序不同的速率限制。例如，无法同时创建维度键为 [“$.context.jwt.role”, “qualifiedModelId”, “$.context.jwt.sub”] 和 [“qualifiedModelId”, “$.context.jwt.role”, “$.context.jwt.sub”] 的速率限制。但维度键的顺序非常重要。当速率限制包含多个维度键时，声明顺序决定了通配符的使用方式。默认的通配符 * 只能出现在末尾位置。如果在第 N 位置使用 *，后续所有位置也必须为 *。这种仅限末尾的限制有助于实现可预测的匹配行为。要理解这种行为，请参阅示例。

• 避免将高基数或无界 JWT 声明用作维度键（例如，$.context.jwt.jti、$.context.jwt.nonce 或请求 ID）。这些会创建无界数量的速率桶，可能降低速率限制的有效性。建议使用稳定且有界的身份标识符，如 sub、role、team 或 tier。

• 网关在速率限制评估中使用开箱即用语义。由于开箱即用行为的存在，请不要仅依赖速率限制作为安全边界。将速率限制用于流量管理和服务质量，而将认证、授权和 AWS WAF 规则用于安全策略执行。

• 在 AgentCore 网关上启用应用日志。这将为您提供访问速率限制日志的权限。网关会在服务器跨度中为每个评估了客户速率限制的请求发出 OpenTelemetry (OTEL) 跨度属性。使用这些属性进行调试和监控。

• 确保包含一个通配符兜底条目，为简化说明，考虑一个仅包含单个速率限制的网关：

aws bedrock-agentcore-control create-gateway-rate-limit \
  --gateway-identifier my-gateway-abc1234567 \
  --dimension-keys '["$.context.jwt.sub"]' \
  --description "Per-sub request limit" \
  --entries '[
    {
      "dimensions": {"$.context.jwt.sub": "Arnav"},
      "requests": [{"rate": 100, "period": "minute"}]
    }
  ]'

在此配置中，仅 Arnav 有显式条目。如果 John（$.context.jwt.sub: “John”）调用网关，请求将不匹配任何条目，速率限制将被跳过，John 将直接进入服务管理的配额，而不会触发任何客户定义的限制。添加通配符兜底条目可确保所有没有显式条目的调用者都能获得自己的每用户速率限制桶：

aws bedrock-agentcore-control create-gateway-rate-limit \
  --gateway-identifier my-gateway-abc1234567 \
  --dimension-keys '["$.context.jwt.sub"]' \
  --description "Per-sub request limit" \
  --entries '[
    {
      "dimensions": {"$.context.jwt.sub": "Arnav"},
      "requests": [{"rate": 100, "period": "minute"}]
    },
    {
      "dimensions": {"$.context.jwt.sub": "*"},
      "requests": [{"rate": 50, "period": "minute"}]
    }
  ]'

现在，John、María以及其他任何调用者都将通过通配符获得各自独立的50 RPM速率桶，而Arnav仍然保留其明确的100 RPM配额。如果没有通配符条目，未匹配的调用者将完全绕过速率限制。

有关更多最佳实践，请参阅AgentCore网关文档。

结论

在本文中，我们介绍了如何在Amazon Bedrock AgentCore网关上配置速率限制以管理AI流量，通过在不同角色和用户之间强制实施公平使用策略，同时帮助防止任何单个调用者或工作负载耗尽共享资源。我们演示了如何分层设置速率限制：针对每角色和每用户的公平性设置用户级限制，针对保护下游服务容量设置目标级限制，以及结合用户和目标的多维限制以实施细粒度速率控制。我们还讨论了智能体工作负载的速率限制注意事项，其中下游资源消耗会根据代理如何与网关进行身份验证而有所不同。

速率限制是全面流量管理策略的一个组成部分。结合AgentCore身份认证实现身份验证、AgentCore策略实现基于角色的访问控制，以及应用日志实现可观测性，这些工具可帮助您自信地运营生产级AI网关，促进公平使用、保护后端服务，并在工作负载扩展时保持可用性。

下一步

要开始在AgentCore网关上使用速率限制，请查阅以下资源：

• 为AgentCore网关添加速率限制，完整API参考文档，涵盖使用维度键、条目和支持指标创建、更新和删除速率限制的完整操作。
• 速率限制API示例，附加CLI示例，涵盖批量操作、列表、过滤和删除工作流。
• AgentCore网关配额和限制，服务管理配额、默认限制以及如何申请配额提升。
• AgentCore身份认证，配置AgentCore网关目标的入站JWT认证和出站令牌发放。
• AgentCore策略，设置基于角色的访问控制，与速率限制相结合实现授权执行。
• AgentCore网关应用日志，启用基于OpenTelemetry的日志记录，实时监控速率限制评估、拒绝情况和每个速率桶的消耗情况。

我们将根据客户反馈继续投资改进AgentCore网关。我们期待看到您如何将AgentCore网关作为AI流量的中央执行系统进行使用。

作者简介

'"`