AgentCore Gateway MCP：返回格式与账单

这篇文章讲把 EveryInfra 的远程 MCP 挂到 Amazon Bedrock AgentCore Gateway 后面之前，要先弄清的返回格式、密钥配置和账单。先说清楚测了什么：我们没有在 AWS 上部署 Gateway，文中 AWS 一侧的命令、target 配置和 interceptor 部署都是照 docs.aws.amazon.com 原文写的配置示例，没有执行过；EveryInfra 一侧的每个数都来自 2026 年 11 月 10 日 00:17 到 00:45（新加坡时间）的真调原始返回，interceptor 的 Python 代码按 AWS 文档的载荷格式、喂这些真实返回在本机跑过。钱的方面，Gateway 自己的费用几乎可以忽略：按同一天读到的 AWS 定价页，每 1,000 次 Gateway 调用 $0.005，而同样 1,000 次 reddit/search 的数据费是 $0.556，Gateway 只占 0.89%。真正要花心思的是三件事，都来自这批原始返回：第一，EveryInfra 的 tools/list 不需要密钥，所以 Gateway 同步工具清单成功、target 显示 READY，并不能证明你填的 API key 是对的，必须再发一次 tools/call；第二，经 MCP 返回的限速（rate_limited）、参数错误、未授权都是 HTTP 200 加 isError，interceptor 如果只看状态码，会把失败当成功记账；第三，按「最新」排序的 Reddit 搜索一页 10 条只覆盖了 72 分钟，品牌监测 agent 要每小时跑一次才不漏帖，这决定了每月的调用量和账单。

场景是这样的：公司已经在 AWS 上跑 agent，用 Amazon Bedrock AgentCore 管运行、身份和工具，现在品牌和公关团队想要一个能自己去 Reddit、X、YouTube 和新闻里查品牌讨论的 agent。工具从 EveryInfra 的远程 MCP（https://api.everyinfra.com/mcp）来，要求是三条：员工用公司身份登录才能用；EveryInfra 的密钥不出现在 agent 代码和提示词里；每个团队每天的数据花费有上限。AgentCore Gateway 正好管这三件事：入站认证、出站凭据、在每次调用前后跑一段自己的代码（interceptor）。下文凡是写到 Gateway 自己怎么转发、怎么注入请求头、RESPONSE 改写是否生效，都是 AWS 文档的说法，不是我们测出来的；凡是写到 EveryInfra 返回什么、扣多少钱，都是实测。

Bedrock AgentCore Gateway 是什么：从 2025 年预览到 2026 年 11 月

AgentCore 是 AWS 的一组 agent 基础服务，2025 年 7 月 16 日以预览形式发布，当时的公告把 Gateway 描述成「把现有 API 和 Lambda 函数转成 MCP 兼容工具」的服务（AWS What's New，2025-07-16）。2025 年 10 月 13 日正式发布（GA）时，同一篇公告加了一句对本文最关键的话：Gateway 现在除了转换 API 和 Lambda，还能连接已有的 MCP 服务器（AWS What's New，2025-10-13）。也就是说，从那天起，一个第三方托管的远程 MCP 可以不经改写，直接挂到 Gateway 后面，成为它统一工具目录里的一部分。

到 2026 年 11 月，官方文档对 Gateway 的定位又扩大了一圈：它是一个托管的 AI 网关，给 agent 流量提供单一的安全入口，连接工具、其他 agent 和大模型（Gateway 概览）。target 分成三类：MCP target 以「聚合模式」工作，Gateway 把所有 MCP target 的能力合成一个虚拟 MCP 服务器；HTTP target 直接转发，不聚合也不转协议；inference target 按模型名把请求路由到不同的模型服务商（支持的 target）。MCP target 下面又有七种来源：Lambda 函数、API Gateway REST 阶段、OpenAPI、Smithy、MCP 服务器、集成商模板和内置连接器（MCP targets）。本文只用其中一种：MCP 服务器 target。

这张表说明一件事：Gateway 一年里从「API 转 MCP 的转换器」长成了一个带身份、限速、过滤和模型路由的网关，企业把第三方数据工具放到它后面，图的是集中管，不是图它帮你转协议。

要不要把远程 MCP 挂到 Gateway 后面

这个问题在社区里有过直接的讨论。Reddit 的 r/aws 上有人问，怎么让 AgentCore 直接用 SaaS 厂商托管的远程 MCP、不自己跑容器；得票最高的回答说，agent 代码本身（例如用 Strands、LangGraph）就能直连远程 MCP，把它挂到 Gateway 上「多半是过度设计」；另一位回答补充，如果要让很多 agent 经一个中间层去连多个远程 MCP，Gateway 能把入站、出站身份和可观测性收拢到一处（r/aws 讨论）。两种说法都对，区别在于你有几个 agent、几个团队、谁来管密钥。

我们的判断按三个问题来。只有一个开发者、一个 agent、一个 EveryInfra 密钥时，直连最简单：把密钥放进 Secrets Manager，agent 启动时读出来，MCP 客户端带上请求头就行，Gateway 多出来的是一层你要维护的配置。到了公司里有品牌、公关、客服三个团队各自做 agent，或者安全部门要求「第三方密钥只能放在一个地方、每次调用都有日志」时，Gateway 的价值就出来了：密钥由 AgentCore Identity 保管，agent 代码里只有 Gateway 的地址；员工用公司的身份服务登录，Gateway 验 JWT；每个团队的预算和可用工具在 interceptor 里统一管。第三种情况是你已经在用 Bedrock 的 Responses API，想让模型在服务端直接调工具：这条路要求工具在 Gateway 后面，2026 年 2 月 24 日的公告写明，Responses API 请求里填 Gateway 的 ARN 作为工具连接器，Bedrock 会自己发现工具、执行调用、把结果注入对话（服务端工具执行公告）。

站内两篇相近的文章可以对照着看：Gemini Enterprise Agent Platform 接 MCP 做品牌舆情 讲的是 Google Cloud 一侧，那边的自定义 MCP 数据存储只收 OAuth 或不认证，带密钥的服务要绕道 ADK agent；Copilot Studio 接 MCP 做会前客户简报 讲的是微软一侧的销售场景。AWS 这边的不同在于，MCP 服务器 target 本身就支持 API key 出站认证，不用绕道，下一节细说。

MCP 服务器 target 怎么接 EveryInfra：版本、同步和工具名

先看 AWS 对 MCP 服务器 target 的硬要求。文档列了三条：MCP 服务器必须有 tools 能力，prompts 和 resources 可选、服务器声明了就自动同步；支持的协议版本是 2026-07-28、2025-11-25、2025-06-18 和 2025-03-26 四个；服务器地址要做 URL 编码，Gateway 用同一个地址调用（MCP 服务器 target）。工具清单有两种同步方式：默认的 DEFAULT 模式下，创建或更新 target 时 Gateway 会调一次 tools/list、prompts/list、resources/list 和 resources/templates/list，把结果放进统一目录，以后服务器的工具变了要手动调 SynchronizeGatewayTargets；DYNAMIC 模式下每次客户端请求时才去问服务器，但这种模式不能用语义搜索，也不能用三方 OAuth。

我们在 2026 年 11 月 10 日 00:17 到 00:18（新加坡时间）把 Gateway 同步时会发的这几个请求，按同样的顺序对 https://api.everyinfra.com/mcp 发了一遍，全部免费。initialize 在 0.16 秒内返回；tools/list 0.12 秒返回 12 个工具，响应 16,250 字节；prompts/list 返回 7 个提示词（其中一个就叫 brand_monitoring），resources/list 返回 6 个资源，resources/templates/list 是空的。协议版本协商是这次最有用的结果：客户端请求 2026-07-28 时，EveryInfra 回的是 2025-11-25；请求 2025-06-18、2025-03-26 时原样回同一个版本。这符合 MCP 规范的写法：服务器支持客户端请求的版本就原样回，不支持就回一个自己支持的版本，通常是自己支持的最新版（MCP 2025-11-25 生命周期）；2026-07-28 版规范把 Tasks 列为需要双方在初始化时协商的扩展（MCP 2026-07-28 规范）。四个版本都在 Gateway 的支持列表里，所以握手不会出问题，但 Gateway 的 MCP Tasks 扩展写明只在 2026-07-28 上可用（Gateway 上的 Tasks），挂 EveryInfra 时用不上。好在 EveryInfra 自己有异步方式：请求里加 "mode":"async" 先拿 job_id，再用 everyinfra_get_job 工具轮询，这和 Tasks 想解决的问题一样，只是走工具层而不是协议层。Gateway 单次调用的超时上限是 15 分钟（服务配额），本次真调里最慢的一次同步调用是 29.5 秒，离这个上限很远。

工具名会被改写，这是接入时最容易漏掉的细节。Gateway 对外暴露的工具名是 目标名___工具名，中间是三个下划线（工具命名规则）。如果 target 叫 everyinfra，agent 看到的就是 everyinfra___everyinfra_call_api。我们按这个规则算了 12 个工具的新名字，最长的是 everyinfra___everyinfra_list_captcha_types，42 个字符，配额表里工具名上限是 256 字符，没有问题。但你写在系统提示词里的工具名、写在 interceptor 里的白名单、写在 Policy 里的规则，都要用改写后的名字，或者像本文的 interceptor 那样先按 ___ 切掉前缀再比较。

还有一点 Gateway 用户在 GitHub 上踩过：工具清单是同步时缓存的，所以 tools/list 能用不代表 tools/call 能用。一个公开的问题单里，用户的 MCP target 配了 OAuth 客户端凭据，target 状态 READY、tools/list 正常，可 tools/call 一直返回「An internal error occurred」，后端日志里根本没收到调用请求（agentcore-samples 问题 809）；r/aws 上也有人问怎么把 GitHub 的远程 MCP 挂到 Gateway，提问者最后没有配通三方 OAuth（r/aws：AgentCore 接 GitHub MCP）。这件事放到 EveryInfra 身上会更隐蔽：我们的 initialize、tools/list、prompts/list 都不需要密钥，即使你在 AgentCore Identity 里存错了 key，同步也会成功，target 照样显示 READY，要等第一次真正的调用才报错。所以配完 target 一定要做一次「冒烟测试」：经 Gateway 调一次 everyinfra_get_account。我们在 00:24 实测这个工具 0.24 秒返回余额和限速信息，不扣费。不带密钥调 everyinfra_call_api 时，我们在 00:18 实测拿到的是 HTTP 200、isError 和 unauthorized，也不扣费；错误密钥下 everyinfra_get_account 的返回我们没有单独测，冒烟测试时看到的只要不是余额，就先查凭据。

出站认证：EveryInfra 的 API key 怎么交给 Gateway

AWS 的出站认证文档有一张矩阵，列出每种 target 支持哪些出站认证方式。MCP 服务器这一行支持不认证、Gateway 服务角色（SigV4 签名）、OAuth 客户端凭据、OAuth 授权码、OAuth 令牌交换和 API key 六种，不支持调用方 IAM 凭据和令牌透传（出站认证）。其中 SigV4 只对托管在 AWS 原生支持 IAM 签名的服务后面的 MCP 服务器有用（AgentCore Gateway、AgentCore Runtime、API Gateway、Lambda 函数地址），EveryInfra 不在 AWS 上用 IAM 验签，所以这条走不通；EveryInfra 目前也没有 OAuth 授权服务器；剩下的就是 API key。

API key 出站要两步。第一步在 AgentCore Identity 里建一个 API key 凭据提供方：控制台里在 Outbound Auth 一节选「Add API key」，可以直接粘贴密钥，也可以引用 Secrets Manager 里已有的密钥，名称最长 50 个字符（添加 API key）；用 API 时调 CreateApiKeyCredentialProvider（接口说明）。第二步在创建 target 时把这个提供方挂上去，字段是 credentialProviderType: API_KEY，下面的 apiKeyCredentialProvider 要填四个值：提供方 ARN、凭据位置（HEADER 或 QUERY_PARAMETER）、参数名和前缀（target 授权配置）。

这四个值填什么，取决于 EveryInfra 认哪种写法。我们在 00:18 用同一个密钥做了对照：放在 Authorization: Bearer <key> 请求头里，tools/call 正常执行并扣费；放在 X-API-Key 请求头里，返回 unauthorized，错误信息写着「no API key provided (header Authorization: Bearer or ?key= query param)」，并注明 Nothing was charged；完全不带密钥时结果一样。所以凭据位置填 HEADER，参数名填 Authorization，前缀填 Bearer。错误信息里提到的 ?key= 查询参数也能用，但我们不建议：查询参数会出现在各种访问日志里，而 Gateway 本身会把调用记进 CloudWatch、S3 或 Firehose（2025 年 9 月的公告），把密钥写进地址等于多存了一份。

# 配置示例（未在 AWS 上执行）：1) 存密钥  2) 建 Gateway  3) 挂 EveryInfra MCP target
aws bedrock-agentcore-control create-api-key-credential-provider \
  --name everyinfra-brandmon \
  --api-key "$EVERYINFRA_API_KEY"

aws bedrock-agentcore-control create-gateway \
  --name brandmon-gw \
  --role-arn arn:aws:iam::123456789012:role/brandmon-gateway-role \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration '{"customJWTAuthorizer":{
      "discoveryUrl":"https://login.example.com/.well-known/openid-configuration",
      "allowedAudience":["brandmon-gateway"]}}' \
  --interceptor-configurations '[{"interceptor":{"lambda":{"arn":"arn:aws:lambda:ap-southeast-1:123456789012:function:brandmon-interceptor"}},
      "interceptionPoints":["REQUEST","RESPONSE"],"inputConfiguration":{"passRequestHeaders":true}}]'

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier <GATEWAY_ID> \
  --name everyinfra \
  --target-configuration '{"mcp":{"mcpServer":{"endpoint":"https://api.everyinfra.com/mcp"}}}' \
  --credential-provider-configurations '[{"credentialProviderType":"API_KEY",
      "credentialProvider":{"apiKeyCredentialProvider":{
        "providerArn":"<上一步返回的 ARN>",
        "credentialLocation":"HEADER",
        "credentialParameterName":"Authorization",
        "credentialPrefix":"Bearer"}}}]'

这段命令里有两个地方要按你的环境核对。一是命令行工具的版本：AgentCore 自己的 CLI 有一个公开问题单指出，项目配置文件 agentcore.json 里 MCP 服务器 target 的出站认证当时只有 NONE 和 OAUTH 真能用，API_KEY 只对 API Gateway target 生效，虽然底层的 CloudFormation 接口支持（starter toolkit 问题 499，2026-04-10）；2026 年 10 月发布说明里 AgentCore CLI 1.0 加了直接操作 gateway 的命令组，但没写这个问题是否修好，所以用 CLI 1.0 以前的版本时，建议像上面一样直接调控制面 API 或 CloudFormation。二是如果你用了自定义的 Gateway 服务角色，要给它加 GetWorkloadAccessToken、GetResourceApiKey 和对应密钥的 secretsmanager:GetSecretValue 三条权限，文档里有完整的策略样例（出站认证 API key 一节）。

钱的方面，AgentCore Identity 单独用时按每 1,000 次取令牌或 API key 收 $0.010，但定价页写明，经 AgentCore Gateway 或 Runtime 使用 Identity 不另收费（AgentCore 定价）。所以把 EveryInfra 的密钥交给 Gateway 保管，账单上不会多一行。

入站认证：员工用公司身份调 Gateway

入站这一侧决定「谁能用这个品牌监测 agent」。AWS 文档列了三类：JWT、IAM 身份，以及把决定交给别的组件的「卸载」类型（只认证不授权、完全不认证）（入站认证）。企业员工通过 Okta、Microsoft Entra ID、Cognito 这类身份服务登录，最常用的是 JWT：建 Gateway 时填 CUSTOM_JWT，给出身份服务的 OIDC 发现地址，再用 allowedAudience、allowedClients 或允许的 scope 限定哪些令牌能进来。令牌无效时，Gateway 按 RFC 6750 返回带 WWW-Authenticate 头的错误，里面写明需要哪些 scope，MCP 客户端可以据此重新走登录。文档还提醒，JWT 里的部分声明会写进 CloudTrail，其中包括 subject，所以别在 subject 里放邮箱这类个人信息。

本文的预算控制要靠 JWT 里的一个自定义声明 team：品牌团队的令牌里是 brand-na，公关团队是 pr-emea。Gateway 验完签名后，interceptor 从请求头里的令牌读出这个声明，按团队记账。这里有一个配置上的前提：interceptor 默认拿不到请求头，必须把 passRequestHeaders 设成 true（interceptor 配置）；文档同时提醒，请求头里有令牌和凭据，interceptor 不要把它们写进日志。

「不认证」这个选项要特别说一句。文档写得很重：不要为了测试方便用不认证的 Gateway，不要让它连会返回敏感信息的 target，只有你打算公开、并且自己做好了限流和检查的 Gateway 才考虑。对 EveryInfra 来说，Gateway 出站时会自动带上你的密钥，如果入站不认证，任何拿到 Gateway 地址的人都能花你钱包里的钱。这和我们在 远程 MCP 接入步骤 里强调的一样：密钥等于钱包。

interceptor 做用量控制：每个团队每天的数据预算

interceptor 是 Gateway 在 2025 年 11 月 26 日加的功能，AWS 在发布博客里说它用于细粒度访问控制、按身份过滤工具、改写请求和响应（interceptor 发布博客）。同年 12 月的 re:Invent 上，Gateway 团队在讲台上（视频 25:37 处）说这是应大量客户要求、上周刚上线的功能，客户想在 agent 调用和工具调用之间跑一段统一的逻辑（re:Invent 2025 AIM3313 演讲视频）。文档里的规则很简单：一个 Gateway 最多一个 REQUEST interceptor、一个 RESPONSE interceptor，都用 Lambda 实现；REQUEST 在 Gateway 调用 target 之前跑，RESPONSE 在 target 返回之后、Gateway 回给调用方之前跑；Gateway 可能因为超时或失败重试 interceptor，所以函数要幂等（interceptor 概览）。

interceptor 收到的载荷是 JSON-RPC 原文。REQUEST 阶段能看到 gatewayRequest.body，里面有 method（例如 tools/call）和 params（工具名和参数）；RESPONSE 阶段多一个 gatewayResponse，有状态码和响应体。REQUEST interceptor 如果在输出里放了 transformedGatewayResponse，Gateway 会直接把它回给调用方，不再调 target，这就是「拦下」的写法；注意即使拦下了，RESPONSE interceptor 也还会被调用一次（interceptor 载荷格式）。AWS 自己有一个开源样例，用两个 Lambda interceptor 给推理 target 做按用户的成本归集和每日、每月硬预算，超了返回 403 和 BUDGET_EXCEEDED（aws-samples 用量 interceptor）。那个样例管的是模型 token 的钱；我们把同一个思路搬到 MCP 工具调用上，管的是数据费。

设计要回答三个问题：调用前怎么知道这次要花多少钱，调用后怎么知道实际花了多少，失败的调用怎么算。第一个问题，EveryInfra 的免费目录 GET /api/v1/social/catalog 给每个能力标了 price_usd，interceptor 每天拉一次缓存起来，调用前按 platform/action 查价预留；查不到的能力按偏高的价格预留。第二个问题要看真实返回。我们对比了 00:18 和 00:25 的几次 MCP 真调：成功的 tools/call 返回里只有 content，没有 structuredContent，扣费金额在 content[0].text 这段 JSON 字符串的 billing.charged_usd 里；失败的返回反过来带 structuredContent.error，里面有错误码。第三个问题，EveryInfra 失败和空结果不扣费，charged_usd 是 0，按实际值记账就自然不会把失败算成花费。

真正的坑在状态码。我们在 00:18 到 00:19 用 REST 接口连发时撞上了这把测试密钥每分钟 10 次的限速，REST 返回的是 HTTP 429；00:24 经 MCP 再撞一次，返回的是 HTTP 200，JSON-RPC 结果里 isError: true，错误码 rate_limited，还带 retry_after: 14。00:24 故意传一个错误的排序值 sort: "hot"，MCP 同样回 HTTP 200，错误码 invalid_value，并给出 did_you_mean: ["popular", "top"]；不带密钥时也是 HTTP 200 加 unauthorized。MCP 规范把工具执行错误放在结果里而不是协议层，这样模型能看到错误内容并自己改正，这是对的做法；但它意味着 RESPONSE interceptor 和 Gateway 的调用日志里，失败的调用状态码也是 200。如果你按状态码统计成功率或决定是否记账，统计会是错的。

# 配置示例（Lambda，REQUEST + RESPONSE 共用）。载荷格式照 AWS 文档 interceptorInputVersion 1.0；
# 本机用本次真调的原始返回离线测过，没有部署到 AWS。线上把 Store 换成 DynamoDB 原子 ADD。
import base64, json, os, time
ALLOWED = {"everyinfra_call_api", "everyinfra_get_job", "everyinfra_get_account", "everyinfra_list_capabilities"}
BUDGET = float(os.environ.get("DAILY_BUDGET_USD", "0.50"))
PRICE = json.loads(os.environ.get("PRICE_TABLE", "{}"))      # {"reddit/search": 0.000556, ...} 每天从目录刷新
spent = {}                                                   # 线上用 DynamoDB

def team_of(headers):            # Gateway 已验过签名，这里只读声明
    tok = (headers or {}).get("Authorization", "").split()[-1]
    body = tok.split(".")[1] if tok.count(".") == 2 else ""
    try: return json.loads(base64.urlsafe_b64decode(body + "=" * (-len(body) % 4))).get("team", "unknown")
    except Exception: return "unknown"

def deny(req, text):             # 直接回给调用方，不再调 EveryInfra
    return {"interceptorOutputVersion": "1.0", "mcp": {"transformedGatewayResponse": {"statusCode": 200, "body": {
        "jsonrpc": "2.0", "id": req.get("id"), "result": {"isError": True, "content": [{"type": "text", "text": text}]}}}}}

def lambda_handler(event, context=None):
    mcp = event["mcp"]; req = mcp["gatewayRequest"]["body"]
    key = team_of(mcp["gatewayRequest"].get("headers")) + "#" + time.strftime("%Y-%m-%d", time.gmtime())
    if "gatewayResponse" not in mcp or mcp["gatewayResponse"] is None:          # REQUEST
        if req.get("method") == "tools/call":
            tool = req["params"]["name"].split("___", 1)[-1]                  # 去掉 target 前缀
            if tool not in ALLOWED:
                return deny(req, f"tool {tool} is not enabled for brand monitoring")
            a = req["params"].get("arguments", {})
            if spent.get(key, 0) + PRICE.get(f"{a.get('platform')}/{a.get('action')}", 0.0021) > BUDGET:
                return deny(req, f"daily data budget {BUDGET} USD reached; try again tomorrow")
        return {"interceptorOutputVersion": "1.0", "mcp": {"transformedGatewayRequest": {"body": req}}}
    resp = mcp["gatewayResponse"]; result = (resp.get("body") or {}).get("result") or {}  # RESPONSE
    if req.get("method") == "tools/list":
        result["tools"] = [t for t in result.get("tools", []) if t["name"].split("___", 1)[-1] in ALLOWED]
    elif req.get("method") == "tools/call":
        try:   # 成功返回没有 structuredContent，扣费在 content[0].text 的 JSON 里
            charged = float(json.loads(result["content"][0]["text"]).get("billing", {}).get("charged_usd") or 0)
        except Exception:
            charged = 0.0  # rate_limited、invalid_value、unauthorized 都是 HTTP 200 + isError，不扣费
        spent[key] = spent.get(key, 0) + charged
    return {"interceptorOutputVersion": "1.0", "mcp": {"transformedGatewayResponse": {
        "statusCode": resp.get("statusCode", 200), "body": resp.get("body")}}}

我们把本次真调的原始返回按 AWS 文档里的载荷格式包了一层（target 名和上文配置示例一样取 everyinfra，所以工具名都带 everyinfra___ 前缀），喂给这段代码的完整版本（多了一个团队维度的内存账本），预算设成每天 $0.002，按顺序跑了七个用例。下表是本机的离线结果，不是 Gateway 上的结果：它证明的是「这段逻辑对 EveryInfra 的真实返回格式能正确工作」，不证明 Gateway 会按文档一字不差地传载荷。

过滤工具清单这一步值得单独说。EveryInfra 的 MCP 有 12 个工具，品牌监测只要其中 4 个：调数据的 everyinfra_call_api、查异步任务的 everyinfra_get_job、查余额的 everyinfra_get_account、查能力的 everyinfra_list_capabilities。验证码、AI 对话、充值链接、工单这几个工具留着，既占模型的上下文，又给了 agent 不该有的动作。RESPONSE interceptor 过滤以后，agent 看到的 tools 数组从 16,883 字节降到 4,357 字节，少了 74%。工具描述每一轮对话都会进模型上下文，按 4 字节一个 token 粗算，每轮省下约 3,000 个 token。AWS 在 re:Invent 2025 的 Gateway 演讲里（视频 19:17 处）讲过极端情况：客户的 agent 挂了约 300 个工具，光加载工具描述就花掉几十万 token，AWS 的解法是语义搜索（re:Invent 2025 AIM3313 演讲视频）；只接一个 MCP 服务器、工具不多时，在 interceptor 里过滤比打开语义搜索更省事，也不用付每 1,000 次 $0.025 的搜索费。另一个办法是在 target 上直接写静态工具清单 mcpToolSchema：接口文档说这对所有凭据类型都支持，代价是 Gateway 不再自动同步，EveryInfra 以后改了工具描述你要手动更新（McpServerTargetConfiguration）。还要注意，everyinfra_call_api 在工具注解里声明了 destructiveHint: true（因为它会扣钱），按「只读工具」写的策略会把它挡掉，策略要按工具名写。

interceptor、速率限制、Policy、WAF：四个开关各管什么

Gateway 上能管流量的不止 interceptor。2026 年 8 月 6 日 AWS 同时发布了自配速率限制和 Policy 的时间类规则（公告、速率限制博客）。速率限制按「维度」分桶，可用的维度包括 target 名、target___工具 形式的工具名、JWT 里的任意声明、IAM 主体，以及调用方带的请求头和请求体字段（后两个要和一个身份维度一起用）（速率限制维度）。每个 Gateway 最多 50 条限制，改动 30 秒内生效，不另收费。

最容易误用的是速率限制。文档用加粗字写了：速率限制默认「失败放行」，限制服务不可用或维度解析不出来时，请求照常通过，不要把它当成唯一的安全边界（速率限制）。所以它适合做「别让一个团队把 EveryInfra 的限速吃满」这种保护，不适合做「每天最多花 $0.50」这种钱的上限；后者要用 interceptor 自己记账。Policy 用 Cedar 语言写规则，在每次工具调用前判定允许或拒绝（Policy 概览），适合表达「哪些人能调哪些工具、参数能填什么」，它不知道一次调用花多少钱。WAF 则在更外面一层：每个 Gateway 绑一个 web ACL，所有入站请求在到达任何 target 之前先过 WAF 规则（用 WAF 保护 Gateway）。四者可以叠用：WAF 挡扫描，速率限制挡突发，Policy 管权限，interceptor 管钱。

一次真实往返：agent 发出什么，EveryInfra 回了什么

Gateway 是聚合模式，agent 看到的请求和直连 EveryInfra 时几乎一样，只是工具名多了前缀。下面是 00:18:20（新加坡时间）我们发出的真实请求和返回的结构，为了能在本机直接跑，工具名用的是 EveryInfra 原名；经 Gateway 时 agent 发的是 everyinfra___everyinfra_call_api，Gateway 去掉前缀、从 AgentCore Identity 取出密钥放进 Authorization 头，再转给 EveryInfra。

curl -s https://api.everyinfra.com/mcp \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":11,"method":"tools/call","params":{"name":"everyinfra_call_api",
       "arguments":{"platform":"reddit","action":"search","params":{"keyword":"Rivian","sort":"newest"}}}}'
# 返回（节选）：HTTP 200，4.69 秒，13,233 字节
# {"jsonrpc":"2.0","id":11,"result":{"content":[{"type":"text","text":"{\"platform\":\"reddit\",\"action\":\"search\",
#   \"results\":[{\"title\":\"Anyone Have Experience with a Rivian Buyback? R1S in Shop for 46 Days\",
#   \"community\":\"r/Rivian\",\"comment_count\":6,\"posted_at\":\"2026-11-09T15:58:16+00:00\", ...}, ... 共 10 条],
#   \"count\":10,\"billing\":{\"charged\":true,\"charged_usd\":0.000556, ...}}"}]}}

返回里每条帖子带 id、url、title、text、author_username、community、like_count、comment_count、posted_at 等字段，和目录里 reddit/search 的 response_fields 一一对应（见 Reddit 帖子搜索接口页）。品牌监测 agent 真正要用的只有标题、正文前一段、链接、发布时间、点赞和评论数、社区名；其余字段（作者名、缩略图、外链域名）对判断口碑没有帮助，作者名还属于个人信息，简报里不该出现。

这里有个和 Gateway 账单相关的细节。定价页把 ListTools、InvokeTool、Ping 都算作「Gateway 调用」，每 1,000 次 $0.005（AgentCore 定价）。一个 agent 每跑一轮，通常先列一次工具，再调若干次工具；如果你的 MCP 客户端每次都重新 initialize 和 tools/list，调用数会比工具调用数多出一截。下面算账时我们按「每轮 1 次列工具 + 实际工具调用数」估计，没有把 initialize 单列，因为定价页没有说它是否计入。Gateway 的 MCP 会话功能会保存 MCP 服务器 target 的会话号、在后续工具调用里复用，避免每次请求都重新初始化（Gateway 功能列表、MCP 会话），值得打开。

耗时这张图说明两件事。一是数据工具本身的耗时从 4.7 秒到 29.5 秒不等，X 搜索最慢；Gateway 在中间多转一手的开销我们没法测（没有部署），但和这个量级相比，任何合理的网关开销都不是瓶颈。二是 agent 的提示词和超时设置要按最慢的工具来定：如果 MCP 客户端默认 10 秒超时，X 搜索会被客户端自己掐断，agent 拿不到结果，而 EveryInfra 那边的请求可能仍在执行；我们没有测客户端断开后是否扣费，不要指望重试一次就没事。遇到这种情况，在参数里加 "mode":"async" 拿 job_id，再用 everyinfra_get_job 取结果，是更稳的写法。

品牌监测实测：每个来源一页能看多远

Gateway 只管门口，agent 好不好用，取决于工具一次能拿回多少有用的东西。我们用电动车品牌 Rivian 做对象，因为 2026 年 11 月初它的新车 R2 正在交付，Reddit、X、YouTube 上都有大量讨论，适合测一个品牌监测 agent 一天里要调多少次工具。下面每个结论都来自 00:18 到 00:28（新加坡时间）这一轮真调的原始返回。

Reddit 一页只覆盖 72 分钟。 reddit/search 按 newest 排序，一次返回 10 条，最早一条发于 2026-11-09 15:01 UTC，最晚一条 16:13 UTC，前后 1.21 小时。这意味着如果 agent 每 6 小时才查一次 Reddit，中间大部分新帖会被漏掉，除非翻页。翻页也是按次计费，每页 $0.000556，所以「每小时查一页」和「每 6 小时查 6 页」的花费差不多，但前者能更早看到负面帖。我们最后的计划是每小时一次 reddit/search，一天 24 次。这条帖子列表里有一条「R1S 在维修店待了 46 天，有人做过回购吗」，评论 6 条，正是品牌团队最想第一时间看到的那种。

X 的 latest 一页跨了 25 小时，而且不是严格按时间排。 我们用 twitter/search 搜 Rivian since:2026-11-08、sort 设为 latest，25 条结果从 2026-11-08 15:14 UTC 到 11-09 16:26 UTC，跨 25.19 小时；按 posted_at 检查，顺序并不是严格从新到旧。agent 不能把「第一条的时间」当成「已经看到哪里」的游标，要自己按 id 去重。默认排序更不适合做监测：同一个关键词默认排序返回的 25 条里，有 5 条发布于 30 天以前，另有 5 条来自品牌自己的官方账号（247,707 个粉丝），这些对「用户在说什么」没有帮助，却同样占模型上下文。品牌监测 agent 的提示词里应该写明：用 latest，排除品牌官方账号。

YouTube 搜索结果里混着频道和老视频。 youtube/search 按 newest 返回 10 条，只有 6 条是 7 天内发布的视频；另外 4 条是频道条目（没有 url 和 view_count）或一个多月前、甚至 2024 年的视频。我们第一次写分析脚本时直接读 view_count，碰到频道条目就报错，换成 .get() 才跑通。interceptor 或 agent 拿到结果后应该先按发布时间过滤一遍，再交给模型。

YouTube 评论的时间是相对值。 youtube/comments 对视频 KP8I6yoWXsY（标题「Rivian Replaced My R2 After Just 2 Months」，2026-11-07 发布，调用时约 1 万次观看）按 newest 取 20 条评论，posted_at 是「30 minutes ago」「1 day ago」这种写法。要放进数据库做趋势，必须在拿到时就用调用时刻换算成绝对时间，过了一天再换算就差出一天。

评论里多少是在说品牌。 我们把这 20 条 YouTube 评论和 Reddit 回购帖下的 7 条评论按一条规则逐条手工标注（单人标注，规则写在原始文件里）：抱怨产品、服务、交付或说不买了的算「负面」，主要在说视频作者的算「谈作者」。YouTube 20 条里负面 8 条、谈作者 6 条、提问 4 条、其他 2 条；Reddit 7 条里负面 3 条，其余 4 条是在讨论维修件和法律细节。这说明两件事：一是视频评论区有近三分之一在谈作者而不是品牌，直接按关键词数负面会高估；二是 Reddit 帖子下面的评论比标题更能说明问题，所以计划里每天对负面帖调 5 次 reddit/comments（见 Reddit 评论接口页）。

新闻两次都没查成。 google_news/search 在 00:21:45 经 REST 返回 HTTP 503，00:42:42 经 MCP 再试返回 HTTP 200 加 isError、错误码 unavailable，两次都写明不扣费。agent 应该把它当作「这次没查成」而不是「没有新闻」；interceptor 如果只统计成功调用，会把它当成「今天没新闻」写进简报，提示词和 interceptor 里都要处理。

00:42（新加坡时间）我们又跑了一轮，看看这些结论是不是偶然。第一，隔 23.8 分钟再按 newest 搜一次 Rivian，返回的 10 条和第一次完全相同，最新一条仍是 16:13 UTC 那条，而这次调用发生在 16:42 UTC。我们分不清是这半小时确实没有新帖，还是搜索结果有延迟；但不管哪种，每小时查一次都不会比每 20 分钟查一次漏得更多，interceptor 还可以按帖子 id 判断「这一轮没有新内容」，直接不让模型再读一遍。第二，把关键词收窄成 Rivian R2 problem，只回来 5 条，其中一条在问 Alienware m18 R2 笔记本、一条在说游戏主机，关键词是按词匹配而不是按语义，agent 要自己再过滤一道。第三，顺手测了 Threads 搜索：17 条，全部提到 Rivian，耗时 12.1 秒，跨 17 小时，里面有法语和乌克兰语的帖子，做多语种监测时要在简报前先按语言分组。

字段裁剪：RESPONSE interceptor 能省多少模型输入

Gateway 的 Lambda 账单很小，模型的账单才大。品牌监测 agent 每天调 37 次工具，返回的 JSON 全部塞进模型上下文，按我们的实测体积估算，每天约 468,047 字节，粗略按 4 字节一个 token 算约 11.7 万 token，一个月约 351 万 token（新闻没有样本，没算进去）。RESPONSE interceptor 本来就要解析返回来记账，顺手把模型用不到的字段删掉，是成本最低的一步。

我们对每类返回只留下判断口碑要用的字段：标题、正文（截到 280 字符）、链接、发布时间、点赞数、观看数、评论数、社区名；删掉作者名、头像、缩略图、外链域名和重复的嵌套对象。用真实返回算出来的体积变化如下：

X 和 YouTube 搜索省得最多，因为每条推文和视频都带着一整套作者资料和媒体链接。改返回要注意两点。第一，AWS 文档说 RESPONSE interceptor 返回的 transformedGatewayResponse 会替换原返回（interceptor 载荷格式），所以改的是 content[0].text 里那段 JSON 字符串，要先解析、裁剪、再序列化回去，billing 字段要留着，否则 agent 看不到花了多少钱。第二，作者名删掉不只是为了省 token：Reddit 数据接口条款和 X 开发者政策都对用户身份信息的使用有限制（Reddit 数据接口条款、X 开发者政策），品牌简报里本来就不该点名普通用户。

还有一个和过滤有关的坑。AWS 文档写明，Policy 只对 MCP 工具生效，不论评估模式如何，Gateway 总是放行 prompts/list、prompts/get 和 resources/list、resources/read、resources/templates/list（在 Gateway 上用 Policy）。r/AI_Agents 上有人专门发帖提醒这一点：新加一个 MCP 服务器 target，就可能多出一批 Policy 管不到的资源（r/AI_Agents 讨论）。我们实测 EveryInfra 的 MCP 公布了 7 个 prompt（包括 brand_monitoring）和 6 个 resource，6 个 resource 全是 everyinfra://guide/...、everyinfra://pricing 这类公开说明文档，读取不扣费，也不碰任何数据，所以对这个场景没有风险；但如果你在同一个 Gateway 上还挂了公司内部的 MCP 服务器，要单独检查它公布的 resource。

Bedrock AgentCore Gateway pricing：一个品牌监测 agent 每月多少钱

先把 AWS 一侧的单价列清楚。下表是 2026 年 11 月 10 日 00:15（新加坡时间）读 AWS 定价页得到的数字（AgentCore 定价），Lambda 单价来自 Lambda 定价页（Lambda 定价）。

定价页自己举的例子里，一个 agent 每月 60 万次 InvokeTool 的 Gateway 费是 $3（每百万次 $5），而同一个例子里的网页搜索费是 $1,400（每 1,000 次查询 $7）。Gateway 本身便宜，贵的是它后面挂的工具，这一点在我们的场景里同样成立。

再看 EveryInfra 一侧。目录里 reddit/search、twitter/search、youtube/search、youtube/comments、reddit/comments 每次调用都是 $0.000556，也就是每 1,000 次 $0.556；google_news/search 每 1,000 次 $0.792。失败、限速、参数错误和空结果都不扣费，这在本次真调里有 12 次实例：7 次限速、2 次未授权、1 次参数错误、2 次新闻没查成，扣费全是 0；9 次成功调用合计扣费 $0.005004。各平台的价格以价格页为准。

有了两边的单价，按前面实测出来的调用计划算一个月。计划是：Reddit 每小时搜一次（每天 24 次），对负面帖取评论（每天 5 次），X 每天搜 2 次（因为一页能覆盖 25 小时），YouTube 每天搜 1 次、对新视频取评论 3 次，新闻每天 2 次。合计每天 37 次工具调用，每天 25 轮（24 个整点轮加 1 个日报轮），每轮开头列一次工具。

结论很直接：AWS 一侧 Gateway 加两个 interceptor 的 Lambda 每月约 $0.0108，是 EveryInfra 数据费的 1.71%；如果再打开 Policy，每次调工具多付 $0.000025，合计占比升到 6.11%，因为 Policy 每 1,000 次 $0.025，比 Gateway 调用本身贵 5 倍。按每 1,000 次算，Gateway 费是 reddit/search 数据费的 0.89%；按每 1,000 条 Reddit 帖子算，数据费是 $0.0556。表里 Lambda 一项已经按每次 100 毫秒、128 MB 估进了执行时长费；没有算的是两项：记预算用的 DynamoDB 读写，以及模型本身的费用。模型每月要读约 351 万 token 的工具返回，它的费用取决于你选哪个模型，几乎一定比上表所有项目加起来都高，这也是为什么前一节要在 interceptor 里裁字段。

如果团队规模变大，比如 10 个品牌、每个品牌一套同样的计划，数据费变成每月约 $6.31，Gateway 层约 $0.108，比例不变，因为两边都按次计费。真正会改变比例的是语义搜索：一旦在同一个 Gateway 上挂了几百个工具、打开语义搜索，每次搜工具 $0.025 / 1,000 次，加上每月按工具数收的索引费。只挂 EveryInfra 一个 target 时不需要它。

和 Gemini Enterprise、Copilot Studio 的做法有什么不同

我们之前写过另外两个企业 agent 平台接 EveryInfra MCP 的做法，三篇各有侧重，挑平台时可以对照看。

如果你的数据最后要落进数仓而不是给人看简报，可以看 Snowflake Cortex Agents 接 MCP 的那篇，那里的 MCP 连接器只认 OAuth，做法完全不同。如果你还没定平台，只想先把多平台口碑监测的数据设计想清楚（目标清单、去重、增量游标、什么时候要人工复核），先读多平台口碑监控蓝图；失败退款怎么对账，见失败退款对账。

做不了或要注意的地方

先把我们没有验证、或者确定做不了的列出来，免得照着文章做到一半才发现。

AWS 一侧没有跑过。 本文所有 aws bedrock-agentcore-control 命令、target 和凭据的 JSON，以及 interceptor 部署到 Lambda 之后的行为，都是照 AWS 文档写的配置示例，没有在 AWS 账号里执行。interceptor 的 Python 代码我们在本机按 AWS 文档的载荷格式、用真实返回跑过，但 Gateway 真正发给 Lambda 的载荷可能有我们没看到的字段。上线前请在测试 Gateway 上先跑通一次 tools/list 和一次 tools/call。

API key 出站在部分工具链里不生效。 GitHub 上 starter toolkit 有一个问题报告：在 agentcore.json 里给 MCP target 配 API_KEY 出站，部署后并没有生效（starter toolkit 问题 499，2026-04-10）。我们没有确认它是否已修复。稳妥做法是用 CreateGatewayTarget 接口或控制台直接配，再用一次 tools/call 验证，而不是只看 target 状态。

数据使用要守平台规则。 品牌监测拿到的是公开帖子和评论，但用途仍受各平台规则约束：Reddit 的数据接口条款、X 的开发者政策、YouTube 的开发者政策。简报里只引帖子内容和链接，不收集、不展示普通用户的个人资料。

测试 key 的限额。 本次真调用的测试 key 每分钟 10 次，我们撞了 7 次限速。正式 key 的限额在 everyinfra_get_account 的返回里能看到，按自己的额度配 Gateway 的速率限制，让 Gateway 先挡，比让 EveryInfra 返回 rate_limited 再重试更省事。

最近 60 天 Gateway 的变化

开头的时间线已经列了 Gateway 自己的功能变化（MCP Tasks、InvokeModel 回退、Web Answer）。这里只补 2026 年 10 月 20 日到 11 月 6 日 AWS 博客上和「第三方工具挂 Gateway」有关、时间线里没有的四件事。

常见问题

AgentCore Gateway 和 AgentCore Runtime 有什么区别？（搜索联想词「agentcore gateway vs runtime」）Runtime 运行 agent 本身的代码，Gateway 管 agent 往外调的工具、模型和其他 agent。品牌监测 agent 可以跑在 Runtime 上，也可以跑在你自己的容器里，只要它能用 MCP 连上 Gateway 的地址（Gateway 概览）。

AgentCore Gateway 和 Amazon API Gateway 是一回事吗？（联想词「agentcore gateway vs api gateway」）不是。API Gateway 管普通 HTTP API；AgentCore Gateway 说 MCP，把多个工具来源合成一个 MCP 服务器给 agent 用。两者能配合：API Gateway 的 REST 阶段可以作为 AgentCore Gateway 的一种 MCP target（MCP targets）。

MCP 服务器 target 能用 API key 吗，密钥放在哪？（联想词「agentcore gateway api key」，以及 starter toolkit 问题 499）能。用 CreateApiKeyCredentialProvider 在 AgentCore Identity 里存密钥，target 的凭据配置里写请求头名 Authorization、前缀 Bearer。密钥由 Identity 保管，agent 代码和提示词里都没有它（添加 API key）。

interceptor 是 REQUEST 还是 RESPONSE，要写几个？（联想词「agentcore gateway interceptor request / response」）每个 Gateway 最多各配一个。做预算控制要两个都写：REQUEST 在调用前查额度、超了就直接返回错误；RESPONSE 在调用后读实际扣费、记账、裁字段（interceptor 配置）。

bedrock agentcore gateway pricing 怎么算，会不会比数据本身贵？（联想词「amazon bedrock agentcore gateway pricing」）不会：按本文的计划，Gateway 每月约 $0.0093，数据费约 $0.6313，算法见上文定价一节。

直接在 agent 里连远程 MCP 不就行了，为什么要 Gateway？（r/aws 讨论）一个人一个 agent 时直连就行，多团队共用时再挂，见上文「要不要把远程 MCP 挂到 Gateway 后面」一节。

Policy 能挡住所有 MCP 请求吗？（r/AI_Agents 讨论）不能，prompt 和 resource 类请求总是放行，见上文「字段裁剪」一节末尾。

上手：先直连跑通，再挂 Gateway

1. 在 EveryInfra 控制台建一把 API key，按快速开始用 curl 发一次 tools/list 和一次 tools/call，确认密钥和余额都没问题。远程 MCP 在各客户端里的配置见远程 MCP 配置和 MCP 服务器页。
2. 用 CreateApiKeyCredentialProvider 把同一把 key 存进 AgentCore Identity。
3. 建 Gateway，入站选 CUSTOM_JWT，填公司身份服务的发现地址和允许的客户端。
4. 加一个 MCP 服务器 target，地址 https://api.everyinfra.com/mcp，出站凭据选上一步的 API key，请求头 Authorization、前缀 Bearer。
5. 等 target 同步完成后，经 Gateway 发一次 tools/call（比如 reddit/search），看返回里有没有 billing；只看到工具列表不算通。
6. 部署 REQUEST 和 RESPONSE 两个 interceptor，把团队预算写进环境变量，按本文的代码先在测试 Gateway 上跑。
7. 按 everyinfra_get_account 返回的限额配 Gateway 速率限制，按团队的 JWT 声明分开限。

各平台能力的参数和返回字段见 Reddit 数据接口、X 数据接口、YouTube 数据接口 以及 X 搜索接口页、YouTube 评论接口页；其他数据、搜索和自动化工具的对比见基础设施市场。

参考资料

AWS 一侧的页面都在 2026 年 11 月 10 日（新加坡时间）读取；括号里是页面自己写的发布日期，文档页没有写日期的不标。EveryInfra 一侧的数字来自同一天的真调原始返回。

1. AWS What's New：Amazon Bedrock AgentCore preview（2025-07-16） <https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-bedrock-agentcore-preview/>
2. AWS What's New：Amazon Bedrock AgentCore is now generally available（2025-10-13） <https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available/>
3. AWS 文档：Amazon Bedrock AgentCore Gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html>
4. AWS 文档：Supported targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-supported-targets.html>
5. AWS 文档：MCP targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-targets-mcp.html>
6. AWS Machine Learning Blog：Apply fine-grained access control with Bedrock AgentCore Gateway interceptors（2025-11-26） <https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/>
7. AWS What's New：Server-side tool execution with AgentCore Gateway（2026-02-24） <https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-server-side-tool-execution-agentcore-gateway/>
8. AWS What's New：AWS WAF for Amazon Bedrock AgentCore（2026-06-29） <https://aws.amazon.com/about-aws/whats-new/2026/06/aws-waf-amazon-bedrock-agentcore/>
9. AWS What's New：Temporal policies and rate limits in AgentCore（2026-08-06） <https://aws.amazon.com/about-aws/whats-new/2026/08/temporal-policies-agentcore/>
10. AWS What's New：AgentCore Identity hosted consent portal（2026-09-01） <https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-agentcore/>
11. AWS 文档：AgentCore release notes (November and October 2026) <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html>
12. AWS What's New：AgentCore Gateway InvokeModel support and model fallback（2026-10-22） <https://aws.amazon.com/about-aws/whats-new/2026/10/agentcore-gateway-invokemodel-fallback/>
13. AWS Machine Learning Blog：Getting started with Web Answer on Amazon Bedrock AgentCore（2026-11-05） <https://aws.amazon.com/blogs/machine-learning/getting-started-with-web-answer-on-amazon-bedrock-agentcore/>
14. Reddit r/aws：How to integrate AWS AgentCore with a remote MCP server <https://www.reddit.com/r/aws/comments/1pwtc53/how_to_integrate_aws_agentcore_with_a_remote_mcp/>
15. AWS 文档：MCP servers targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html>
16. Model Context Protocol：Specification 2025-11-25: Lifecycle <https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle>
17. Model Context Protocol：Specification 2026-07-28 <https://modelcontextprotocol.io/specification/2026-07-28>
18. AWS 文档：MCP tasks in AgentCore Gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-mcp-tasks.html>
19. AWS 文档：Quotas for Amazon Bedrock AgentCore <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html>
20. AWS 文档：Tool naming <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-tool-naming.html>
21. GitHub awslabs/agentcore-samples：Issue 809: tools/call internal error on an OAuth MCP target <https://github.com/awslabs/agentcore-samples/issues/809>
22. AWS 文档：Outbound authorization <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html>
23. AWS 文档：Add an API key credential provider <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-add-api-key.html>
24. AWS API Reference：CreateApiKeyCredentialProvider <https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateApiKeyCredentialProvider.html>
25. AWS 文档：Target authorization configuration <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-building-adding-targets-authorization.html>
26. AWS What's New：AgentCore Gateway PrivateLink and invocation logging（2025-09） <https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-bedrock-agentcore-gateway-privatelink-invocation-logging/>
27. GitHub aws/bedrock-agentcore-starter-toolkit：Issue 499: API_KEY outbound auth on an MCP target（2026-04-10） <https://github.com/aws/bedrock-agentcore-starter-toolkit/issues/499>
28. AWS：Amazon Bedrock AgentCore pricing <https://aws.amazon.com/bedrock/agentcore/pricing/>
29. AWS 文档：Inbound authorization <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html>
30. AWS 文档：Configure interceptors <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-configuration.html>
31. YouTube：AWS re:Invent 2025 AIM3313: AgentCore Gateway（2025-12） <https://www.youtube.com/watch?v=DlIHB8i6uyE>
32. AWS 文档：Gateway interceptors <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html>
33. AWS 文档：Interceptor types and payloads <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-types.html>
34. GitHub aws-samples：sample-agentcore-gateway-usage-interceptor <https://github.com/aws-samples/sample-agentcore-gateway-usage-interceptor>
35. AWS API Reference：McpServerTargetConfiguration <https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_McpServerTargetConfiguration.html>
36. AWS Machine Learning Blog：Configure rate limits for AI traffic on AgentCore Gateway（2026-08-06） <https://aws.amazon.com/blogs/machine-learning/configure-rate-limits-for-ai-traffic-on-agentcore-gateway/>
37. AWS 文档：Rate limit dimensions <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits-dimensions.html>
38. AWS 文档：Rate limits <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits.html>
39. AWS 文档：Policy in AgentCore <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html>
40. AWS 文档：Protecting your gateway with AWS WAF <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-waf.html>
41. AWS 文档：Gateway features <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-features.html>
42. AWS 文档：Use MCP sessions with your AgentCore gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-sessions.html>
43. Reddit：Data API Terms <https://redditinc.com/policies/data-api-terms>
44. X Developer Platform：Developer Policy <https://docs.x.com/developer-terms/policy>
45. AWS 文档：Use an AgentCore Gateway with Policy <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/use-gateway-with-policy.html>
46. Reddit r/AI_Agents：AgentCore Gateway Policy covers MCP tools only <https://www.reddit.com/r/AI_Agents/comments/1xat5hx/agentcore_gateway_policy_covers_mcp_tools_only/>
47. AWS：AWS Lambda pricing <https://aws.amazon.com/lambda/pricing/>
48. Reddit r/aws：AgentCore connection to GitHub MCP? <https://www.reddit.com/r/aws/comments/1t7fp90/agentcore_connection_to_github_mcp/>
49. Google for Developers：YouTube API Services Developer Policies <https://developers.google.com/youtube/terms/developer-policies>
50. AWS Machine Learning Blog：Govern AI agent access with Okta Cross App Access and AgentCore, part 2（2026-11-06） <https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-access-with-okta-cross-app-access-and-amazon-bedrock-agentcore-part-2/>
51. AWS 文档：Web Answer connector <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-answer-tool.html>
52. AWS Machine Learning Blog：ServiceNow on-behalf-of token exchange with AgentCore Gateway（2026-11-03） <https://aws.amazon.com/blogs/machine-learning/servicenow-on-behalf-of-token-exchange-with-bedrock-agentcore-gateway/>
53. AWS Machine Learning Blog：How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway（2026-10-29） <https://aws.amazon.com/blogs/machine-learning/how-moengage-turned-over-400-apis-into-agent-tools-with-agentcore-gateway/>
54. AWS Machine Learning Blog：Building an agentic AI platform on Amazon Bedrock AgentCore（2026-10-28） <https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore/>
55. AWS Machine Learning Blog：How Eon built multi-cloud investigation with an MCP gateway on AgentCore（2026-10-20） <https://aws.amazon.com/blogs/machine-learning/how-eon-built-multi-cloud-investigation-with-an-mcp-gateway-on-amazon-bedrock-agentcore/>