# AgentCore Gateway MCP：返回格式与账单

> 挂 AgentCore Gateway 前先看 EveryInfra MCP 的返回格式和记账坑：数据侧真调，AWS 侧为配置示例，附每月账单。

- Canonical page: https://everyinfra.com/blog/bedrock-agentcore-gateway-mcp-social-data
- Published: 2026-11-10T01:31:00+08:00 · Fact-checked: 2026-11-10T01:30:00+08:00

这篇文章讲把 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 要每小时跑一次才不漏帖，这决定了每月的调用量和账单。

> **本文要点**
>
> - AgentCore Gateway 的 MCP server target 支持 API key 出站认证（AWS 文档里的认证矩阵），EveryInfra 的密钥要配成请求头 `Authorization`、前缀 `Bearer`；我们实测换成 `X-API-Key` 头会被拒，返回 unauthorized，没有扣费。
> - 按 2026-11-10 读到的定价页：Gateway 调用每 1,000 次 $0.005，语义搜索每 1,000 次 $0.025，Policy 授权每次 $0.000025；经 Gateway 用 AgentCore Identity 存密钥不另收费。
> - 我们请求 MCP 协议版本 `2026-07-28`，EveryInfra 回的是 `2025-11-25`；Gateway 支持这个版本，但 MCP Tasks 只在 `2026-07-28` 上可用，慢任务要改用 `everyinfra_get_job` 轮询。
> - 一个盯 Rivian 的品牌监测 agent，每天 37 次工具调用，每月数据费 $0.6313，Gateway 和两个 interceptor 的 Lambda 合计约 $0.0108，占数据费 1.71%；加上 Policy 是 6.11%。
> - 用 interceptor 把 12 个工具过滤到 4 个，`tools` 数组从 16,883 字节降到 4,357 字节；成功返回里没有 `structuredContent`，扣费金额要从 `content[0].text` 这段 JSON 里读。

场景是这样的：公司已经在 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 返回什么、扣多少钱，都是实测。

![示意插图：一封信封沿着传送带从左往右走，先经过一个旁边放着一小摞硬币和计数灯的闸机，再进入一个透明玻璃亭；亭子里一条从金属保险柜伸出来的机械臂，把一枚青绿色钥匙挂牌夹到信封上，信封继续走向远处的服务器；下方另一条传送带把一个包裹从服务器方向送回来，也穿过同一个玻璃亭。只有钥匙挂牌和计数灯是青绿色。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/img-explain.webp)

闸机代表 REQUEST interceptor 先查预算，玻璃亭代表 Gateway 在出站时从凭据库取出 API key 附到请求上，回程的包裹再过一次 RESPONSE interceptor 记账。

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

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

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

| 日期 | 变化 | 对品牌监测 agent 的意义 | 出处 |
| --- | --- | --- | --- |
| 2025-07-16 | AgentCore 预览发布 | Gateway 当时只把 API、Lambda 转成工具 | What's New 公告，见上一段 |
| 2025-10-13 | AgentCore GA，Gateway 能连已有 MCP 服务器 | EveryInfra 这类远程 MCP 可以直接挂成 target | 同上，见上一段 |
| 2025-11-26 | Gateway interceptor 发布 | 每次调用前后能跑自己的 Lambda，做预算和过滤 | [发布博客](https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/) |
| 2026-02-24 | Bedrock Responses API 可以在服务端执行 Gateway 工具 | 模型调用和工具调用能放进一次 API 请求 | [What's New](https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-server-side-tool-execution-agentcore-gateway/) |
| 2026-06-29 | AWS WAF 可以挂在 Gateway 上 | 按 IP、速率、托管规则挡流量 | [What's New](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-waf-amazon-bedrock-agentcore/) |
| 2026-08-06 | Gateway 支持自配速率限制，Policy 加入时间类规则 | 按 JWT 声明或工具名限速，不用自己写 | [What's New](https://aws.amazon.com/about-aws/whats-new/2026/08/temporal-policies-agentcore/) |
| 2026-09-01 | AgentCore Identity 托管授权页 | 三方 OAuth 不再需要自建回调 | [What's New](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-agentcore/) |
| 2026-10（发布说明） | Gateway 支持 MCP Tasks 扩展；AgentCore CLI 1.0；target 可用私有 CA 证书 | Tasks 只在协议 `2026-07-28` 上可用；EveryInfra 用公网证书 | [发布说明](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html) |
| 2026-10-22 | Gateway 支持 Bedrock InvokeModel 和模型回退 | 模型流量和工具流量能走同一个网关、同一套日志 | [What's New](https://aws.amazon.com/about-aws/whats-new/2026/10/agentcore-gateway-invokemodel-fallback/) |
| 2026-11-05 | Web Answer 连接器 GA（目前只在美东） | 简报开头的背景可用它写，原帖仍要逐条取 | [GA 博客](https://aws.amazon.com/blogs/machine-learning/getting-started-with-web-answer-on-amazon-bedrock-agentcore/)、[连接器文档](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-answer-tool.html) |

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

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

这个问题在社区里有过直接的讨论。Reddit 的 r/aws 上有人问，怎么让 AgentCore 直接用 SaaS 厂商托管的远程 MCP、不自己跑容器；得票最高的回答说，agent 代码本身（例如用 Strands、LangGraph）就能直连远程 MCP，把它挂到 Gateway 上「多半是过度设计」；另一位回答补充，如果要让很多 agent 经一个中间层去连多个远程 MCP，Gateway 能把入站、出站身份和可观测性收拢到一处（[r/aws 讨论](https://www.reddit.com/r/aws/comments/1pwtc53/how_to_integrate_aws_agentcore_with_a_remote_mcp/)）。两种说法都对，区别在于你有几个 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 会自己发现工具、执行调用、把结果注入对话（[服务端工具执行公告](https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-server-side-tool-execution-agentcore-gateway/)）。

| 情况 | 建议 | 理由 |
| --- | --- | --- |
| 1 个开发者、1 个 agent、本地或单个服务 | agent 直连 EveryInfra MCP | 少一层配置；密钥放 Secrets Manager 即可 |
| 多个团队、多个 agent，要统一身份和日志 | 挂到 Gateway 后面 | 入站 JWT、出站密钥、调用日志集中在一处 |
| 要按团队限预算、限可用工具 | Gateway + interceptor 或 Policy | 预算逻辑在 agent 之外，改一处全生效 |
| 用 Bedrock Responses API 在服务端调工具 | 挂到 Gateway | 公告里的做法是在请求中填 Gateway 的 ARN |

站内两篇相近的文章可以对照着看：[Gemini Enterprise Agent Platform 接 MCP 做品牌舆情](/blog/gemini-enterprise-agent-platform-mcp-brand-sentiment) 讲的是 Google Cloud 一侧，那边的自定义 MCP 数据存储只收 OAuth 或不认证，带密钥的服务要绕道 ADK agent；[Copilot Studio 接 MCP 做会前客户简报](/blog/copilot-studio-mcp-linkedin-account-research) 讲的是微软一侧的销售场景。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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html)）。工具清单有两种同步方式：默认的 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 生命周期](https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle)）；`2026-07-28` 版规范把 Tasks 列为需要双方在初始化时协商的扩展（[MCP 2026-07-28 规范](https://modelcontextprotocol.io/specification/2026-07-28)）。四个版本都在 Gateway 的支持列表里，所以握手不会出问题，但 Gateway 的 MCP Tasks 扩展写明只在 `2026-07-28` 上可用（[Gateway 上的 Tasks](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-mcp-tasks.html)），挂 EveryInfra 时用不上。好在 EveryInfra 自己有异步方式：请求里加 `"mode":"async"` 先拿 job_id，再用 `everyinfra_get_job` 工具轮询，这和 Tasks 想解决的问题一样，只是走工具层而不是协议层。Gateway 单次调用的超时上限是 15 分钟（[服务配额](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html)），本次真调里最慢的一次同步调用是 29.5 秒，离这个上限很远。

| 检查项（Gateway 同步时会做的） | 我们对 EveryInfra MCP 的实测 | 结论 |
| --- | --- | --- |
| 协议版本 | 请求 2026-07-28，回 2025-11-25 | 在 Gateway 支持列表内；Tasks 扩展用不上 |
| tools 能力 | 12 个工具，16,250 字节，不要密钥 | 满足；同步成功不代表密钥对 |
| prompts、resources | 7 个提示词、6 个资源 | Gateway 会一并同步进目录 |
| 资源模板 | 0 个 | 无影响 |
| 工具名加前缀后长度 | 最长 42 字符 | 远低于 256 字符上限 |

工具名会被改写，这是接入时最容易漏掉的细节。Gateway 对外暴露的工具名是 `目标名___工具名`，中间是三个下划线（[工具命名规则](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-tool-naming.html)）。如果 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](https://github.com/awslabs/agentcore-samples/issues/809)）；r/aws 上也有人问怎么把 GitHub 的远程 MCP 挂到 Gateway，提问者最后没有配通三方 OAuth（[r/aws：AgentCore 接 GitHub MCP](https://www.reddit.com/r/aws/comments/1t7fp90/agentcore_connection_to_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 凭据和令牌透传（[出站认证](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html)）。其中 SigV4 只对托管在 AWS 原生支持 IAM 签名的服务后面的 MCP 服务器有用（AgentCore Gateway、AgentCore Runtime、API Gateway、Lambda 函数地址），EveryInfra 不在 AWS 上用 IAM 验签，所以这条走不通；EveryInfra 目前也没有 OAuth 授权服务器；剩下的就是 API key。

![AWS 文档截图：标题 Set up outbound authorization for your gateway，下面一句 The type of outbound authorization that you can set up is dependent on the gateway target type，再下面是一张 6 行 9 列的表。MCP server 这一行用青绿色框整行标出：No authorization Yes、Gateway service role Yes、Caller IAM credentials No、OAuth client credentials Yes、OAuth authorization code Yes、OAuth token exchange Yes、Token passthrough No、API key Yes，最后一格 API key 的 Yes 另加一个青绿色粗框。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/img-doc-outbound-auth.webp)

MCP 服务器 target 支持 API key 出站认证（截图取自 2026-11-10，只保留了标题、说明句和表格）。 [AWS 文档：Set up outbound authorization for your gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html)

API key 出站要两步。第一步在 AgentCore Identity 里建一个 API key 凭据提供方：控制台里在 Outbound Auth 一节选「Add API key」，可以直接粘贴密钥，也可以引用 Secrets Manager 里已有的密钥，名称最长 50 个字符（[添加 API key](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-add-api-key.html)）；用 API 时调 `CreateApiKeyCredentialProvider`（[接口说明](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateApiKeyCredentialProvider.html)）。第二步在创建 target 时把这个提供方挂上去，字段是 `credentialProviderType: API_KEY`，下面的 `apiKeyCredentialProvider` 要填四个值：提供方 ARN、凭据位置（`HEADER` 或 `QUERY_PARAMETER`）、参数名和前缀（[target 授权配置](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-building-adding-targets-authorization.html)）。

这四个值填什么，取决于 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 月的公告](https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-bedrock-agentcore-gateway-privatelink-invocation-logging/)），把密钥写进地址等于多存了一份。

```bash
# 配置示例（未在 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](https://github.com/aws/bedrock-agentcore-starter-toolkit/issues/499)）；2026 年 10 月发布说明里 AgentCore CLI 1.0 加了直接操作 gateway 的命令组，但没写这个问题是否修好，所以用 CLI 1.0 以前的版本时，建议像上面一样直接调控制面 API 或 CloudFormation。二是如果你用了自定义的 Gateway 服务角色，要给它加 `GetWorkloadAccessToken`、`GetResourceApiKey` 和对应密钥的 `secretsmanager:GetSecretValue` 三条权限，文档里有完整的策略样例（[出站认证 API key 一节](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html)）。

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

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

入站这一侧决定「谁能用这个品牌监测 agent」。AWS 文档列了三类：JWT、IAM 身份，以及把决定交给别的组件的「卸载」类型（只认证不授权、完全不认证）（[入站认证](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html)）。企业员工通过 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 配置](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-configuration.html)）；文档同时提醒，请求头里有令牌和凭据，interceptor 不要把它们写进日志。

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

| 入站方式 | 适合 | 品牌监测 agent 怎么用 |
| --- | --- | --- |
| CUSTOM_JWT | 员工经公司身份服务登录 | 推荐；令牌里带 `team` 声明，interceptor 按团队记账 |
| IAM | 机器对机器、AWS 内部服务调用 | 定时任务用 IAM 角色调 Gateway |
| 只认证不授权（SigV4） | 授权交给 Policy 或 interceptor | 可以，但预算要靠 IAM 主体区分团队 |
| 不认证 | 公开服务，自己做限流 | 不要用：出站会自动带上付费密钥 |

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

interceptor 是 Gateway 在 2025 年 11 月 26 日加的功能，AWS 在发布博客里说它用于细粒度访问控制、按身份过滤工具、改写请求和响应（[interceptor 发布博客](https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/)）。同年 12 月的 re:Invent 上，Gateway 团队在讲台上（视频 25:37 处）说这是应大量客户要求、上周刚上线的功能，客户想在 agent 调用和工具调用之间跑一段统一的逻辑（[re:Invent 2025 AIM3313 演讲视频](https://www.youtube.com/watch?v=DlIHB8i6uyE)）。文档里的规则很简单：一个 Gateway 最多一个 REQUEST interceptor、一个 RESPONSE interceptor，都用 Lambda 实现；REQUEST 在 Gateway 调用 target 之前跑，RESPONSE 在 target 返回之后、Gateway 回给调用方之前跑；Gateway 可能因为超时或失败重试 interceptor，所以函数要幂等（[interceptor 概览](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html)）。

interceptor 收到的载荷是 JSON-RPC 原文。REQUEST 阶段能看到 `gatewayRequest.body`，里面有 `method`（例如 `tools/call`）和 `params`（工具名和参数）；RESPONSE 阶段多一个 `gatewayResponse`，有状态码和响应体。REQUEST interceptor 如果在输出里放了 `transformedGatewayResponse`，Gateway 会直接把它回给调用方，不再调 target，这就是「拦下」的写法；注意即使拦下了，RESPONSE interceptor 也还会被调用一次（[interceptor 载荷格式](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-types.html)）。AWS 自己有一个开源样例，用两个 Lambda interceptor 给推理 target 做按用户的成本归集和每日、每月硬预算，超了返回 403 和 BUDGET_EXCEEDED（[aws-samples 用量 interceptor](https://github.com/aws-samples/sample-agentcore-gateway-usage-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。如果你按状态码统计成功率或决定是否记账，统计会是错的。

```text
# 配置示例（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 会按文档一字不差地传载荷。

| 用例（输入是真实返回） | interceptor 的处理 | 当天累计 |
| --- | --- | --- |
| `tools/list`，12 个工具 | 过滤成 4 个，`tools` 数组 16,883 → 4,357 字节 | — |
| 调 `everyinfra_solve_captcha` | REQUEST 阶段拦下，回「not enabled」 | $0 |
| `reddit/search` 成功，10 条 | 记 $0.000556 | $0.000556 |
| `twitter/search` 成功，25 条 | 记 $0.000556 | $0.001112 |
| 经 MCP 撞限速 rate_limited | HTTP 200，记 $0 | $0.001112 |
| 错误排序值 invalid_value | HTTP 200，记 $0 | $0.001112 |
| `reddit/comments` 成功，7 条 | 记 $0.000556 | $0.001668 |
| 再调 `youtube/comments` | 预留 $0.000556 会超 $0.002，拦下 | $0.001668 |

过滤工具清单这一步值得单独说。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 演讲视频](https://www.youtube.com/watch?v=DlIHB8i6uyE)）；只接一个 MCP 服务器、工具不多时，在 interceptor 里过滤比打开语义搜索更省事，也不用付每 1,000 次 $0.025 的搜索费。另一个办法是在 target 上直接写静态工具清单 `mcpToolSchema`：接口文档说这对所有凭据类型都支持，代价是 Gateway 不再自动同步，EveryInfra 以后改了工具描述你要手动更新（[McpServerTargetConfiguration](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_McpServerTargetConfiguration.html)）。还要注意，`everyinfra_call_api` 在工具注解里声明了 `destructiveHint: true`（因为它会扣钱），按「只读工具」写的策略会把它挡掉，策略要按工具名写。

![条形图，2026 年 11 月 10 日 tools/list 返回经 interceptor 过滤前后：工具数从 12 个降到 4 个，tools 数组体积从 16,883 字节降到 4,357 字节，过滤后的条是青绿色。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-07-tools-size-bar.zh.light.svg)

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

Gateway 上能管流量的不止 interceptor。2026 年 8 月 6 日 AWS 同时发布了自配速率限制和 Policy 的时间类规则（[公告](https://aws.amazon.com/about-aws/whats-new/2026/08/temporal-policies-agentcore/)、[速率限制博客](https://aws.amazon.com/blogs/machine-learning/configure-rate-limits-for-ai-traffic-on-agentcore-gateway/)）。速率限制按「维度」分桶，可用的维度包括 target 名、`target___工具` 形式的工具名、JWT 里的任意声明、IAM 主体，以及调用方带的请求头和请求体字段（后两个要和一个身份维度一起用）（[速率限制维度](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits-dimensions.html)）。每个 Gateway 最多 50 条限制，改动 30 秒内生效，不另收费。

| 开关 | 管什么 | 按什么分 | 费用（2026-11-10 定价页） | 用在品牌监测 agent |
| --- | --- | --- | --- | --- |
| interceptor（Lambda） | 任意逻辑：预算、工具过滤、改写 | 你代码里能读到的一切 | 按 Lambda 计费 | 按团队记美元预算、过滤工具 |
| 速率限制 | 每段时间的请求数 | 工具名、JWT 声明、IAM 主体等 | 不另收费 | 每个团队每分钟不超过 EveryInfra 的限速 |
| Policy（Cedar） | 允许或拒绝某次工具调用 | 身份、工具、工具参数 | 每次授权 $0.000025 | 只许品牌团队调 `twitter/search` 之类的规则 |
| WAF | 网络层的攻击和滥用 | IP、速率、托管规则 | 按 WAF 计费 | Gateway 对外开放时挡扫描 |

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

![流程动画：品牌监测 agent 的一次工具调用从上往下经过 AgentCore Gateway 里的入站认证、速率限制和 Policy、REQUEST interceptor、出站凭据，到达 EveryInfra 远程 MCP；返回从下往上经过 RESPONSE interceptor 记账和裁字段，再带着加了前缀的工具名回到 agent。出站凭据和 RESPONSE interceptor 两个框是青绿色。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-01-gateway-flow.zh.light.svg)

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

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

```bash
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 帖子搜索接口页](/reddit-api/search)）。品牌监测 agent 真正要用的只有标题、正文前一段、链接、发布时间、点赞和评论数、社区名；其余字段（作者名、缩略图、外链域名）对判断口碑没有帮助，作者名还属于个人信息，简报里不该出现。

![代码卡片截图：上半部分是发往 https://api.everyinfra.com/mcp 的 tools/call 请求，工具名 everyinfra_call_api，参数 platform reddit、action search、keyword Rivian、sort newest，标注 2026-11-10 00:18:20 新加坡时间、HTTP 200、4.69 秒；下半部分是返回里的 3 条帖子标题、社区和发布时间（作者名已隐去），以及 count 10 和 billing 里 charged_usd 0.000556，后者用青绿框标出。第二张小卡片是 00:24:46 经 MCP 撞限速的返回：HTTP 200、isError true、code rate_limited、retry_after 14，同样用青绿框标出。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/img-mcp-response.webp)

一次成功的 MCP 往返和一次限速返回：两者的 HTTP 状态码都是 200（作者名已隐去）。 [EveryInfra MCP 接口 2026-11-10 原始返回](https://api.everyinfra.com/mcp)

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

| 时间（新加坡时间） | 经 | 能力或方法 | 结果 | 耗时 | 扣费 |
| --- | --- | --- | --- | --- | --- |
| 00:17:51 | MCP | initialize | 200，版本 2025-11-25 | 0.16 秒 | $0 |
| 00:17:52 | MCP | tools/list | 12 个工具，16,250 字节 | 0.12 秒 | $0 |
| 00:18:20 | MCP | `reddit/search` newest | 10 条 | 4.69 秒 | $0.000556 |
| 00:20:28 | REST | `twitter/search` 默认排序 | 25 条（前 4 次 429） | 29.52 秒 | $0.000556 |
| 00:21:17 | REST | `youtube/search` newest | 10 条 | 7.18 秒 | $0.000556 |
| 00:24:29 | MCP | `everyinfra_get_account` | 余额和限速 | 0.24 秒 | $0 |
| 00:25:03 | MCP | `reddit/comments` | 7 条 | 10.56 秒 | $0.000556 |
| 00:26:42 | MCP | `twitter/search` latest | 25 条 | 27.10 秒 | $0.000556 |
| 00:28:05 | MCP | `youtube/comments` newest | 20 条 | 14.64 秒 | $0.000556 |
| 00:42:08 | MCP | `reddit/search` newest（第二次） | 10 条，和第一次相同 | 4.39 秒 | $0.000556 |
| 00:42:25 | REST | `reddit/search` 收窄关键词 | 5 条 | 4.83 秒 | $0.000556 |
| 00:42:56 | MCP | `threads/search` | 17 条 | 12.10 秒 | $0.000556 |

![横向条形图，2026 年 11 月 10 日每次成功调用的耗时（秒）：免费的握手和列工具中位数 0.14 秒；reddit/search 4.69；youtube/search 7.18；reddit/comments 10.56；youtube/comments 14.64；twitter/search latest 27.10；twitter/search 默认排序 29.52，最后一根是青绿色。副标题说明 Gateway 调用超时上限 15 分钟，最慢的一次不到它的 4%。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-02-latency-bar.zh.light.svg)

耗时这张图说明两件事。一是数据工具本身的耗时从 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 评论接口页](/reddit-api/comments)）。

**新闻两次都没查成。** `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 搜索](/threads-api)：17 条，全部提到 Rivian，耗时 12.1 秒，跨 17 小时，里面有法语和乌克兰语的帖子，做多语种监测时要在简报前先按语言分组。

![横向条形图，2026 年 11 月 10 日实测一页结果覆盖的时间跨度（小时）：Reddit 搜索按最新排序 10 条 1.21 小时；X 搜索按最新排序 25 条 25.19 小时。Reddit 那根是青绿色，副标题说明 Reddit 一页覆盖不到 2 小时，所以每小时调一次。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-05-coverage-bar.zh.light.svg)

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

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

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

| 能力 | 原始体积（字节） | 裁剪后（字节） | 节省 |
| --- | --- | --- | --- |
| `reddit/search` | 11,672 | 5,334 | 54.3% |
| `twitter/search` | 32,604 | 8,001 | 75.5% |
| `youtube/search` | 22,687 | 4,652 | 79.5% |
| `youtube/comments` | 8,684 | 4,932 | 43.2% |
| `reddit/comments` | 3,519 | 2,260 | 35.8% |

![分组条形图，2026 年 11 月 10 日五类真实返回裁剪字段前后的字节数：reddit/search 11,672 到 5,334；twitter/search 32,604 到 8,001；youtube/search 22,687 到 4,652；youtube/comments 8,684 到 4,932；reddit/comments 3,519 到 2,260。裁剪后的条是青绿色，X 和 YouTube 搜索省得最多，都超过 75%。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-06-trim-bar.zh.light.svg)

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

还有一个和过滤有关的坑。AWS 文档写明，Policy 只对 MCP 工具生效，不论评估模式如何，Gateway 总是放行 `prompts/list`、`prompts/get` 和 `resources/list`、`resources/read`、`resources/templates/list`（[在 Gateway 上用 Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/use-gateway-with-policy.html)）。r/AI_Agents 上有人专门发帖提醒这一点：新加一个 MCP 服务器 target，就可能多出一批 Policy 管不到的资源（[r/AI_Agents 讨论](https://www.reddit.com/r/AI_Agents/comments/1xat5hx/agentcore_gateway_policy_covers_mcp_tools_only/)）。我们实测 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 定价](https://aws.amazon.com/bedrock/agentcore/pricing/)），Lambda 单价来自 Lambda 定价页（[Lambda 定价](https://aws.amazon.com/lambda/pricing/)）。

| 计费项 | 单价 | 这个场景用不用 |
| --- | --- | --- |
| Gateway API 调用（ListTools、InvokeTool、Ping） | 每 1,000 次 $0.005 | 用，每次列工具和调工具都算 |
| Search API（语义搜索工具） | 每 1,000 次 $0.025 | 不用，只有 4 个工具 |
| Tool Indexing（工具索引） | 每月每 100 个工具 $0.02 | 只有开语义搜索才需要 |
| Identity 取 API key | 每 1,000 次 $0.010，经 Gateway 使用不另收费 | 用，但不收费 |
| Policy 授权请求 | 每次 $0.000025（每 1,000 次 $0.025） | 可选 |
| 自定义速率限制 | 不另收费 | 用 |
| 到客户自有 VPC 的数据流出 | 每 GB $0.006 | 不用，EveryInfra 在公网 |
| Lambda（interceptor） | 每百万次请求 $0.20，另按 GB-秒计；每月前 100 万次免费 | 用，两个 interceptor |

定价页自己举的例子里，一个 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。各平台的价格以[价格页](/pricing)为准。

![对数刻度横向条形图，2026 年 11 月 10 日每 1,000 次的价格（美元）：Gateway 调用 0.005；Policy 授权 0.025；语义搜索 0.025；每 1,000 条 Reddit 帖子 0.0556；reddit/search 每 1,000 次 0.556；google_news/search 0.792。reddit/search 那根是青绿色，副标题说明 Gateway 调用费是 reddit/search 的 0.89%。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-03-cost-per-1000-bar.zh.light.svg)

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

| 项目 | 每月数量 | 每月金额（美元） |
| --- | --- | --- |
| EveryInfra 数据费 | 1,110 次工具调用 | 0.6313 |
| Gateway 调用 | 1,860 次（1,110 次调工具 + 750 次列工具） | 0.0093 |
| 两个 interceptor 的 Lambda（请求费加执行时长） | 3,720 次，每次按 100 毫秒、128 MB 估 | 0.00152（在免费额度内则为 0） |
| Policy 授权（可选） | 1,110 次 | 0.02775 |
| 语义搜索索引（可选，按 12 个工具折算） | 12 个工具 | 0.0024 |
| AWS 一侧合计（不含 Policy） |  | 0.01082 |

![横向条形图，按 2026 年 11 月 10 日单价估算的品牌监测 agent 每月费用（美元）：EveryInfra 数据费 0.6313；Policy 授权 0.02775；Gateway 调用 0.0093；语义搜索索引 0.0024；Lambda 请求 0.00152。数据费那根是青绿色，副标题说明 Gateway 加 Lambda 只占数据费的 1.71%。](https://everyinfra.com/articles/bedrock-agentcore-gateway-mcp-social-data/fig-04-monthly-cost-bar.zh.light.svg)

结论很直接：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 的做法，三篇各有侧重，挑平台时可以对照看。

|  | AgentCore Gateway（本文） | Gemini Enterprise Agent Platform | Copilot Studio |
| --- | --- | --- | --- |
| 远程 MCP 怎么带密钥 | target 上配 API key 凭据，放进 `Authorization` 头 | 平台内 MCP 只有 OAuth 和免认证，带密钥要走 ADK 加 Agent Gateway | 连接器里配 API key |
| 员工身份 | Gateway 入站认证，JWT 或 IAM | Google 身份 | Microsoft Entra 身份 |
| 用量控制 | interceptor（Lambda）+ 速率限制 + Policy | 见那篇文章 | 见那篇文章 |
| 文中场景 | 品牌监测：Reddit、X、YouTube、新闻 | 品牌舆情，DJI 真调 | 销售会前客户简报，LinkedIn |
| 文章 | 本文 | [Gemini Enterprise 品牌舆情](/blog/gemini-enterprise-agent-platform-mcp-brand-sentiment) | [Copilot Studio 会前客户简报](/blog/copilot-studio-mcp-linkedin-account-research) |

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

## 做不了或要注意的地方

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

**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](https://github.com/aws/bedrock-agentcore-starter-toolkit/issues/499)）。我们没有确认它是否已修复。稳妥做法是用 `CreateGatewayTarget` 接口或控制台直接配，再用一次 `tools/call` 验证，而不是只看 target 状态。

**数据使用要守平台规则。** 品牌监测拿到的是公开帖子和评论，但用途仍受各平台规则约束：Reddit 的[数据接口条款](https://redditinc.com/policies/data-api-terms)、X 的[开发者政策](https://docs.x.com/developer-terms/policy)、YouTube 的[开发者政策](https://developers.google.com/youtube/terms/developer-policies)。简报里只引帖子内容和链接，不收集、不展示普通用户的个人资料。

**测试 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」有关、时间线里没有的四件事。

| 日期 | 变化 | 链接 | 对品牌监测 agent 的影响 |
| --- | --- | --- | --- |
| 2026-11-06 | 用 Okta Cross App Access 治理 agent 访问（第 2 部分） | [AWS 博客](https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-access-with-okta-cross-app-access-and-amazon-bedrock-agentcore-part-2/) | 员工身份在 Okta 时，入站 JWT 配置可以直接照它做 |
| 2026-11-03 | Gateway 用代用户令牌交换（OBO）调 ServiceNow | [AWS 博客](https://aws.amazon.com/blogs/machine-learning/servicenow-on-behalf-of-token-exchange-with-bedrock-agentcore-gateway/) | 适合每个员工在目标系统有自己权限的场景；按团队记账的数据服务用团队级 API key 更合适 |
| 2026-10-29 | MoEngage 把 400 多个 API 变成 agent 工具 | [AWS 博客](https://aws.amazon.com/blogs/machine-learning/how-moengage-turned-over-400-apis-into-agent-tools-with-agentcore-gateway/) | 工具上百时语义搜索和索引费才划算；只挂 EveryInfra 时不用 |
| 2026-10-28、10-20 | 在 AgentCore 上搭企业 agent 平台；Eon 用 Gateway 做多云排查 | [平台文章](https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore/)、[Eon 案例](https://aws.amazon.com/blogs/machine-learning/how-eon-built-multi-cloud-investigation-with-an-mcp-gateway-on-amazon-bedrock-agentcore/) | 都把 Gateway 当公司所有 agent 的统一出口，正是本文建议挂 Gateway 的情况 |

## 常见问题

**AgentCore Gateway 和 AgentCore Runtime 有什么区别？**（搜索联想词「agentcore gateway vs runtime」）Runtime 运行 agent 本身的代码，Gateway 管 agent 往外调的工具、模型和其他 agent。品牌监测 agent 可以跑在 Runtime 上，也可以跑在你自己的容器里，只要它能用 MCP 连上 Gateway 的地址（[Gateway 概览](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)）。

**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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-targets-mcp.html)）。

**MCP 服务器 target 能用 API key 吗，密钥放在哪？**（联想词「agentcore gateway api key」，以及 [starter toolkit 问题 499](https://github.com/aws/bedrock-agentcore-starter-toolkit/issues/499)）能。用 `CreateApiKeyCredentialProvider` 在 AgentCore Identity 里存密钥，target 的凭据配置里写请求头名 `Authorization`、前缀 `Bearer`。密钥由 Identity 保管，agent 代码和提示词里都没有它（[添加 API key](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-add-api-key.html)）。

**interceptor 是 REQUEST 还是 RESPONSE，要写几个？**（联想词「agentcore gateway interceptor request / response」）每个 Gateway 最多各配一个。做预算控制要两个都写：REQUEST 在调用前查额度、超了就直接返回错误；RESPONSE 在调用后读实际扣费、记账、裁字段（[interceptor 配置](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-configuration.html)）。

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

**直接在 agent 里连远程 MCP 不就行了，为什么要 Gateway？**（[r/aws 讨论](https://www.reddit.com/r/aws/comments/1pwtc53/how_to_integrate_aws_agentcore_with_a_remote_mcp/)）一个人一个 agent 时直连就行，多团队共用时再挂，见上文「要不要把远程 MCP 挂到 Gateway 后面」一节。

**Policy 能挡住所有 MCP 请求吗？**（[r/AI_Agents 讨论](https://www.reddit.com/r/AI_Agents/comments/1xat5hx/agentcore_gateway_policy_covers_mcp_tools_only/)）不能，prompt 和 resource 类请求总是放行，见上文「字段裁剪」一节末尾。

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

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

各平台能力的参数和返回字段见 [Reddit 数据接口](/reddit-api)、[X 数据接口](/twitter-api)、[YouTube 数据接口](/youtube-api) 以及 [X 搜索接口页](/twitter-api/search)、[YouTube 评论接口页](/youtube-api/comments)；其他数据、搜索和自动化工具的对比见[基础设施市场](/market)。

## 参考资料

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/>
1. 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/>
1. AWS 文档：Amazon Bedrock AgentCore Gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html>
1. AWS 文档：Supported targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-supported-targets.html>
1. AWS 文档：MCP targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-targets-mcp.html>
1. 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/>
1. 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/>
1. 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/>
1. 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/>
1. 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/>
1. AWS 文档：AgentCore release notes (November and October 2026) <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html>
1. 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/>
1. 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/>
1. 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/>
1. AWS 文档：MCP servers targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html>
1. Model Context Protocol：Specification 2025-11-25: Lifecycle <https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle>
1. Model Context Protocol：Specification 2026-07-28 <https://modelcontextprotocol.io/specification/2026-07-28>
1. AWS 文档：MCP tasks in AgentCore Gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-mcp-tasks.html>
1. AWS 文档：Quotas for Amazon Bedrock AgentCore <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html>
1. AWS 文档：Tool naming <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-tool-naming.html>
1. GitHub awslabs/agentcore-samples：Issue 809: tools/call internal error on an OAuth MCP target <https://github.com/awslabs/agentcore-samples/issues/809>
1. AWS 文档：Outbound authorization <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html>
1. AWS 文档：Add an API key credential provider <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-add-api-key.html>
1. AWS API Reference：CreateApiKeyCredentialProvider <https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateApiKeyCredentialProvider.html>
1. AWS 文档：Target authorization configuration <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-building-adding-targets-authorization.html>
1. 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/>
1. 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>
1. AWS：Amazon Bedrock AgentCore pricing <https://aws.amazon.com/bedrock/agentcore/pricing/>
1. AWS 文档：Inbound authorization <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html>
1. AWS 文档：Configure interceptors <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-configuration.html>
1. YouTube：AWS re:Invent 2025 AIM3313: AgentCore Gateway（2025-12） <https://www.youtube.com/watch?v=DlIHB8i6uyE>
1. AWS 文档：Gateway interceptors <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html>
1. AWS 文档：Interceptor types and payloads <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-types.html>
1. GitHub aws-samples：sample-agentcore-gateway-usage-interceptor <https://github.com/aws-samples/sample-agentcore-gateway-usage-interceptor>
1. AWS API Reference：McpServerTargetConfiguration <https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_McpServerTargetConfiguration.html>
1. 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/>
1. AWS 文档：Rate limit dimensions <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits-dimensions.html>
1. AWS 文档：Rate limits <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits.html>
1. AWS 文档：Policy in AgentCore <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html>
1. AWS 文档：Protecting your gateway with AWS WAF <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-waf.html>
1. AWS 文档：Gateway features <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-features.html>
1. AWS 文档：Use MCP sessions with your AgentCore gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-sessions.html>
1. Reddit：Data API Terms <https://redditinc.com/policies/data-api-terms>
1. X Developer Platform：Developer Policy <https://docs.x.com/developer-terms/policy>
1. AWS 文档：Use an AgentCore Gateway with Policy <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/use-gateway-with-policy.html>
1. 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/>
1. AWS：AWS Lambda pricing <https://aws.amazon.com/lambda/pricing/>
1. Reddit r/aws：AgentCore connection to GitHub MCP? <https://www.reddit.com/r/aws/comments/1t7fp90/agentcore_connection_to_github_mcp/>
1. Google for Developers：YouTube API Services Developer Policies <https://developers.google.com/youtube/terms/developer-policies>
1. 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/>
1. AWS 文档：Web Answer connector <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-answer-tool.html>
1. 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/>
1. 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/>
1. 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/>
1. 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/>