Eon 的高级 DevOps 工程师 Roei Zavida 把公司内部的 MCP 工具网关部署到一百多名开发者后,撞上了一个文档里不会提前告诉你的问题:Cedar 授权策略的体积逼近了配额上限。
Eon 是一家云数据平台公司,为 AWS、Azure 和 GCP 上的资源提供发现、备份和勒索软件检测。它的工程团队排查一次生产事故需要同时查 Kubernetes 日志、Grafana 指标、GitHub PR 和云服务商状态。此前每位开发者本地跑约十个 MCP 服务器,各自配置凭证,新人上手要两天。他们选择了 Amazon Bedrock AgentCore Gateway 作为统一入口,用 Cedar 策略控制人和代理各自能调用哪些工具,用 IAM 跨账户角色假设替代 VPC 对等连接。上线后新人配置降到约两分钟,本地 MCP 进程归零。
但 Zavida 在博客中重点讲的不是这些数字,而是三个在百级规模和约一万次会话后浮出的生产问题。
第一个是策略体积。网关在 DEFAULT 模式下预索引每个工具的 schema,这些全部计入 Cedar 策略体积。数十个目标暴露的大量工具清单让策略逼近配额。解法是对工具数量大的目标切换到 DYNAMIC 模式:网关在请求时实时转发 tools/list,不再预索引,策略体积增量为零。代价是 DYNAMIC 目标失去语义搜索——开发者无法用自然语言描述需求让网关匹配工具。Eon 的折中是混合配置:工具数少、需要逐用户 OAuth 同意的目标保持 DEFAULT,大目录目标用 DYNAMIC。
第二个是 OAuth 协议不匹配。Claude Code、Cursor 和 Codex 期望 OAuth 流程携带 state 参数做 CSRF 防护,但 AgentCore 使用 session-URI 绑定。Zavida 的团队在网关前加了一层 Amazon API Gateway 转换垫片,让标准客户端无需修改就能完成认证。
第三个是工具清单噪音。某些 MCP 服务器暴露数百个工具,单个开发者只需要其中一小部分。Eon 在 Runtime 层包了一个过滤包装器,缩减返回的工具数量,既减少误调用风险,也避免这些目标被迫切到 DYNAMIC 模式而失去语义搜索。
这三个问题的共同点是:托管网关解决了凭证分散和跨账户网络的核心痛点,但它的默认假设——预索引所有 schema、单一 OAuth 模式、完整工具清单——与真实的多账户、多协议环境产生了摩擦。Zavida 给出的不是换方案,而是在同一个网关内做局部适配。
对于正在构建代理式系统的团队,这篇实践记录的可迁移认识是:统一 MCP 网关的价值在于把身份和策略集中到一处,但规模一旦上去,你需要为不同特征的工具目标准备不同的接入模式,并且预留一层协议转换的余地。
信息源:aws.amazon.com