AI 网关的限流不应只看每秒请求数。一次请求可能触发大模型生成、工具调用或 Agent 编排，消耗的令牌数、并发连接数和下游资源差异很大。Amazon Bedrock AgentCore Gateway 支持针对 AI 流量配置限流，并可按 JWT 声明或 IAM 身份划分额度，让单一调用方或单一目标的流量尖峰不会拖垮模型、工具或 Agent。
限流维度要和资源消耗对齐
常见 Web API 往往只限制请求速率，但 AI 请求至少需要同时考虑三类预算：
- 请求数：控制调用频率，适合防止循环重试、爬虫式调用和突发批量任务。
- 令牌数：控制模型推理成本与吞吐占用。短请求与长上下文、长输出请求的资源消耗并不等价。
- 连接数：限制同时进行的流式响应或长连接，避免少数客户端长期占满连接池。
这些限制应落在真正的资源边界前。对于 AgentCore Gateway 而言，网关可以在流量到达下游模型、工具或 Agent 前执行控制，因此拒绝请求不会继续放大为模型推理、工具执行或编排开销。
把额度作用域设为“谁在访问什么”
全局限流很容易产生误伤：一个高流量租户占满总额度后，其他正常用户也会失败。更实用的模型是把限流键拆为身份维度和目标维度：
rate-limit-key = <caller-identity> + <target>
其中，caller-identity 可以来自 JWT 中稳定、不可由客户端随意伪造的声明，例如 sub、租户 ID 或已验证的客户 ID；使用 IAM 鉴权时，则可以基于调用方 IAM 身份。target 则代表实际要保护的下游对象，例如某个模型路由、工具端点或 Agent。
这样可以形成明确的隔离效果：
- 租户 A 对
support-agent的突发调用不会消耗租户 B 的预算。 - 某个昂贵模型可以有更严格的令牌预算，而轻量工具保留更高的请求额度。
- 长时间流式调用可受连接上限约束，不会挤占所有可用连接。
选择 JWT 声明时要避免使用邮箱、显示名等可变字段。优先选身份提供方签发的主体 ID；如果要按组织计费或隔离，使用经过验证的租户声明，并确保其只能由可信身份提供方写入。
先为目标分级，再设置初始阈值
限流值没有通用正确答案。一个可执行的起点是按下游目标的成本和容量分层，而不是为所有路由复制同一份配额。
| 目标类型 | 主要限制 | 初始策略示例 |
|---|---|---|
| 交互式聊天 Agent | 请求、令牌、连接 | 防止高频追问和长流式连接堆积 |
| 高成本推理模型 | 令牌优先 | 限制单用户在一个时间窗口内的输入与输出令牌预算 |
| 读操作工具 | 请求优先 | 允许较高吞吐，但限制突发峰值 |
| 有副作用的工具 | 请求、并发连接 | 对写入、支付、部署等操作设置更保守的额度 |
阈值应来自实际观测：每个目标的正常峰值、下游限额、可接受延迟、单位请求令牌分布和失败重试模式。不要把下游服务的物理最大值直接配置为网关额度；应留出重试、内部流量和异常恢复的容量。
可以这样实践：在发布前校验限流策略
具体的 AgentCore Gateway 配置字段应以当前 AWS 控制台、CLI 或 SDK 版本为准。下面的 YAML 是一个策略设计清单，不是可直接提交到 AWS 的资源模板。它适合纳入仓库并由部署脚本转换为当前环境所需的 AgentCore 配置，避免限流规则只存在于控制台操作记录中。
# rate-limit-policy.yaml
version: 1
scope:
identity:
type: jwt_claim
claim: tenant_id
target: gateway_target
limits:
- target: support-agent
request_rate:
max_requests: 60
window_seconds: 60
token_rate:
max_tokens: 120000
window_seconds: 60
concurrent_connections: 10
- target: finance-tool
request_rate:
max_requests: 12
window_seconds: 60
concurrent_connections: 2
部署前，可以运行以下 Python 校验脚本，阻止容易造成事故的配置进入流水线，例如身份作用域缺失、窗口值不合理，或高风险目标没有连接上限。
# validate_rate_limit_policy.py
from pathlib import Path
import sys
import yaml
policy = yaml.safe_load(Path("rate-limit-policy.yaml").read_text())
errors = []
identity = policy.get("scope", {}).get("identity", {})
if identity.get("type") not in {"jwt_claim", "iam_identity"}:
errors.append("scope.identity.type must be jwt_claim or iam_identity")
if identity.get("type") == "jwt_claim" and not identity.get("claim"):
errors.append("JWT-scoped limits require scope.identity.claim")
for item in policy.get("limits", []):
target = item.get("target", "<unknown>")
request_rate = item.get("request_rate", {})
if request_rate:
if request_rate.get("max_requests", 0) <= 0:
errors.append(f"{target}: max_requests must be greater than 0")
if request_rate.get("window_seconds", 0) <= 0:
errors.append(f"{target}: request window must be greater than 0")
token_rate = item.get("token_rate", {})
if token_rate and token_rate.get("max_tokens", 0) <= 0:
errors.append(f"{target}: max_tokens must be greater than 0")
if item.get("concurrent_connections", 0) <= 0:
errors.append(f"{target}: concurrent_connections must be greater than 0")
if errors:
print("Invalid rate-limit policy:")
print("\n".join(f"- {error}" for error in errors))
sys.exit(1)
print("Rate-limit policy is valid")
安装依赖并执行：
python -m pip install pyyaml
python validate_rate_limit_policy.py
将 YAML 中的 tenant_id、目标名称和数值替换为自己的身份模型与网关目标。随后由部署流程调用当前版本的 AgentCore Gateway API 或基础设施即代码工具写入对应规则。关键是让“身份声明、目标和三类额度”成为可审查、可测试的配置，而不是散落在业务代码中。
拒绝请求后，客户端也必须收敛
网关限流只能保护下游，不能自动修复客户端的重试风暴。调用方收到限流响应后，应区分临时拥塞与永久错误：读取服务返回的重试提示，在有限次数内采用指数退避和随机抖动；交互式请求可以提示用户稍后再试，批处理任务则应排队或延迟执行。
还应监控至少四类信号：按身份和目标统计的限流拒绝数、令牌使用量、活跃连接数，以及下游模型或工具的延迟与错误率。若拒绝率突然升高，要先判断是攻击、客户端缺陷、真实业务增长，还是配额过低；不同原因对应不同动作。
上线检查清单
- 为每个需要保护的模型、工具和 Agent 明确目标级额度。
- 使用已验证的 JWT 声明或 IAM 身份作为调用方作用域。
- 同时评估请求、令牌和连接三种预算，避免只限制 QPS。
- 为高成本和有副作用的目标设置更保守的默认值。
- 将策略纳入版本控制，并在部署前执行结构校验。
- 在客户端实现有限重试、退避和队列化，避免限流后放大流量。
- 根据监控数据持续调整阈值，而不是一次性设定后长期不变。
限流的目标不是让 AI 调用尽可能多地通过，而是在资源紧张时仍让关键用户、关键目标和下游服务保持可用。把额度绑定到身份和目标，才能把这条边界真正落到多租户 AI 系统的运行模型上。