MCP 协议演进与面向 Agent 的网关生态调研¶
调研时间: 2026-07-12 | 归属: ProMan's KB — 调研分析 背景: 企业内部对上/对外有大量 MCP server，需要理解协议最新动态、给 API 网关带来的挑战，以及面向 agent 产品的网关生态全景与选型方向。 状态: 已完成（待跟进：2026-07-28 RC 正式定版）
一、MCP 协议最新更新¶
1.1 版本时间线（MCP 用日期版本号）¶
| 版本 | 状态 | 关键变化 |
|---|---|---|
| 2025-06-18 | 已发布 | Streamable HTTP 取代 HTTP+SSE、outputSchema、统一 Pagination |
| 2025-11-25 | 已发布 | Tasks（实验）、Elicitation、Sampling 工具调用、title 字段 |
| 2026-06-30 | 过渡版 | 承接多项 SEP 变更 |
| 2026-07-28 | RC 待定版 | 无状态化、移除握手、Extensions 框架、MRTR、MCP Apps |
⚠️ 注意: 协议尚未完全定版。2026-07-28 目前是 RC（官方 schema
LATEST_PROTOCOL_VERSION），SDK beta 2026-06-29 才发布。已跑在 2025-11-25 的生产部署短期勿乱升——2026-07-28 是破坏性变更。
1.2 通信流程（以最常用 2025-11-25 为例）¶
传输层 — Streamable HTTP（统一 /mcp 端点）：
- POST /mcp — 客户端发 JSON-RPC 消息（请求/通知/响应），返回 application/json 或 SSE 流
- GET /mcp — 接收服务端推送（SSE）
- 有状态模式：服务端用 MCP-Session-Id header 发会话 ID
- 另有 stdio（本地子进程通信）
生命周期三步握手：
client → server: initialize {protocolVersion, capabilities, clientInfo}
server → client: result {capabilities, serverInfo, instructions}
client → server: notifications/initialized ← 之后进入正常操作
核心方法（JSON-RPC 2.0）：
- 工具: tools/list → tools/call
- 资源: resources/list / read / templates/list
- 提示词: prompts/list / get
- 客户端特性: sampling/createMessage、roots/list
- 交叉关注: notifications/progress、notifications/cancelled、ping
2025-11-25 新增：
- Tasks（实验性）: tasks/list/get/result/cancel，跟踪长耗时异步操作，客户端轮询 pollInterval；tools/call 可带 task 参数
- Elicitation: elicitation/create（form/url 模式），服务端反过来向用户征询信息
- Sampling 支持工具调用: 服务端可让客户端模型在采样响应中调工具
1.3 2026-07-28 RC 大变革（影响未来架构）¶
由 6 个 SEP 驱动：
- 无状态化（SEP-2567/2575）: 移除 Mcp-Session-Id 和协议级会话，每请求自包含，任意 server 实例可处理 → 对负载均衡/横向扩容极友好
- 移除握手: initialize/initialized 删掉，版本与 capabilities 放每请求 _meta，新增 server/discover
- HTTP header 标准化（SEP-2243）: MCP-Protocol-Version、Mcp-Method、Mcp-Name → 网关/代理/可观测工具无需深包检测即可路由
- Extensions 框架: capabilities 增加 extensions 映射，Tasks 迁为 io.modelcontextprotocol/tasks 扩展
- MRTR（SEP-2322）: input_required 结果类型 + 多轮交互
- MCP Apps（SEP-1865）: 服务端可交付交互式 UI（ui:// URI）
💡 对网关最关键的两条: 无状态化 + HTTP header 标准化，正是为"大量 MCP 塞进网关/负载均衡"铺路。
1.4 关键来源¶
- 规范索引: https://modelcontextprotocol.io/specification/latest
- 2025-11-25 changelog: https://modelcontextprotocol.io/specification/2025-11-25/changelog
- GitHub spec 仓库: https://github.com/modelcontextprotocol/modelcontextprotocol
- SEP 索引 / SEP-1865, 2243, 2575, 2663
二、大量 MCP 对 API 网关的挑战¶
量一大（对内+对外几十上百个 server），传统 API 网关扛不住。核心是 7 类新挑战：
2.1 Discovery / 注册¶
agent 无法预先把所有工具 schema 塞进 context，需要注册中心（catalog）。MCP 目前缺统一 registry 标准，各家用私有目录实现。
2.2 聚合（最痛）¶
连 100 个 MCP server，tools/list 返回上千工具定义，直接打爆 LLM context。解法是 meta-server/工具面元化：一个入口聚合 N 个 server，用工具选择器过滤，只暴露少量"元工具"按需转发。开源实现称对 100-tool 栈省约 89% context 开销。
2.3 鉴权与安全¶
- SSE 长连接让"每请求独立鉴权"失效
- agent 自主调工具 → "谁授权了这次调用"必须可审计
- 每个 server 的上游凭证不能下发给 agent 明文携带
- 核心是工具级授权（TBAC）: 如
Equals(mcp.method,"tools/call") && Prefix(mcp.params.name,"dev_") && Contains(jwt.groups,"developers")
2.4 流控 / 2.5 可观测审计 / 2.6 成本控制 / 2.7 多租户¶
- 流控: agent 高频循环调工具 → token 级限流 + tools/call 频率限流
- 可观测: "agent 调了哪些工具、花多少 token、为何走到这步"是合规重点
- 成本: 推理 token + 工具调用开销 + 工具定义塞 context 的 token
- 多租户: 工具可见性/配额/审计/凭证按租户隔离
一句话: 传统 API 网关管 "human→REST API"；MCP 时代要叠加 "meta-server 聚合、工具级授权、工具调用审计、MCP/OAuth 传输鉴权、context 成本核算" 五层新能力。
三、面向 Agent 的网关生态全景¶
3.1 分层全图¶
客户端层: Human (Chat/IDE) & AI Agent
网关层: ①LLM网关 → ②MCP/工具网关 → ③Agent/A2A网关
★ 趋势: 三者 + 传统 REST 网关收敛到一个策略面
发现/注册层: MCP registry 、 A2A AgentCard 、 Agent marketplace
编排层: LangGraph/AutoGen/ADK + 托管平台(watsonx/Foundry/AgentCore)
后端层: 内外部 REST API + 各种 MCP server
3.2 两个互补协议¶
- MCP（模型上下文协议）: 管 "agent 怎么用工具"。MCP server registry = 工具市场。
- A2A（Agent2Agent，Google 发起、Linux 基金会化）: 管 "agent 找 agent 并交接任务"。用 AgentCard（
/.well-known/agent-card.json）描述 agent 身份/能力/技能，支持签名校验 → 补位了 MCP 缺失的 agent discovery/registry 层。 - 网关需同时懂两套协议。
3.3 网关产品梯队（MCP 支持从原生到次要）¶
通用 AI/Agent 网关（LLM+MCP 双支持） | 产品 | MCP 支持 | 商业模式 | |------|---------|---------| | Envoy AI Gateway | 原生强（MCPRoute 聚合+toolSelector+OAuth） | 开源（CNCF） | | Kong AI Gateway | 原生（从 REST API 自动生成 MCP） | 开源核心+EE | | Higress | 原生（openapi-to-mcp） | 开源（阿里） | | Traefik Hub | 原生（独立 MCP Gateway，工具级授权） | 商业 | | LiteLLM | 原生（MCP Gateway + per-tool 成本） | 开源核心+企业 | | APISIX / Portkey / Cloudflare / Azure APIM / IBM watsonx | 以 LLM 治理为主，MCP 次之 | 混合 |
专门 MCP 汇聚/托管平台
- 云托管: AWS Bedrock AgentCore（带 Gateway MCP server）、Azure AI Foundry Agent Service（MCPTool 挂远程 server）、Google Cloud Agent Registry + 16+ 官方远程 MCP
- 开源: microsoft/mcp-gateway（.NET，K8s 托管）、mikkoparkkola/mcp-gateway（Rust meta-server）、docker/mcp-gateway、agentic-community/mcp-gateway-registry（统一 MCP+agent 注册，可联邦 Bedrock）
- Agent Gateway（agentgateway.dev）: 一个 proxy 统一 REST+LLM+MCP+A2A，最贴合"统一收敛"路线
3.4 从 "human→REST API" 到 "agent→tool/agent" 的演进¶
| 维度 | 传统 API 网关 | AI/Agent 网关 |
|---|---|---|
| 调用方 | Human | AI Agent（自主、循环、并发） |
| 契约 | OpenAPI | MCP tools + A2A AgentCard |
| 鉴权 | API key/JWT 每请求 | Bearer/OAuth + 工具级 TBAC |
| 流量 | 短请求 | SSE 长连接、Streamable HTTP、流式 |
| 限流 | QPS | QPS + token 限流 + 成本配额 |
| 可观测 | 请求链路 | 工具调用审计 + token/成本 + prompt 日志 |
| 统一入口 | 单域名反代 | 多 MCP server 聚合成 meta-surface |
四、选型建议（对内+对外大量 MCP 场景）¶
趋势不是推倒重来，而是分层 + 收敛：
- 接入层（Edge）: 保留传统 API 网关做 TLS/域名/WAF/基础限流（成熟稳定）
- 语义层（Agent/MCP 网关）: 叠加模型路由 + MCP 聚合/元工具 + 工具级授权 + 调用审计 + 成本核算，处理 agent 特有的长连接/OAuth/schema/context 优化
具体推荐： - 已重度用 K8s/Envoy → Envoy AI Gateway（原生 MCP、CRD 驱动） - 已在用 Kong/APISIX → 用其 AI/MCP 插件增量升级 - 要统一 REST+LLM+MCP+A2A 且要商业托管治理 → Agent Gateway / Traefik Hub - 云团队分三家云 → 选一家托管（AgentCore/Foundry/Google）+ 自托管开源 mcp-gateway 管对内
五、结论¶
- 短期: 别追 2026-07-28 RC（破坏性变更），stake 在 2025-11-25 稳
- 中期: 核心解决"聚合 + 工具级授权 + 审计"三件套
- 远期: 等无状态化落地后，MCP 网关横向扩容会非常自然（SEP-2243 header 标准化 + sessionless）
调研来源: 官方 MCP spec/sep + context7 文档检索交叉核实（modelcontextprotocol.io, github.com/modelcontextprotocol）。生产环境建议以 https://modelcontextprotocol.io/specification/latest 当日为准。