什么是 MCP 网关（MCP Gateway）？

工作原理

MCP Gateway 是围绕 Model Context Protocol 的部署模式，不是第四种协议参与者。官方架构只定义 Host、Client 与 Server。只有共享 Routing、Policy、Fleet Inventory、Credential Mediation 或 Observability 的收益足以抵消额外跳数时，才需要把 Gateway 放在网络路径上。Client 直连 Server 仍然有效，增加 Gateway 也不会自动让集成可信或具备生产可用性。

两种设计承担不同责任。Transparent Gateway 保留已配置的 Server Endpoint，在一段协议关系中转发流量并实施 Transport Control。Aggregating Gateway 向下游 Client 暴露一个 MCP Endpoint，再汇总多个上游 Server 的能力，因此对下游扮演 Server、对每个上游扮演 Client。聚合并非透明行为：它必须拥有稳定 Server Identity、明确 Version Policy、无冲突 Namespace、确定性 Discovery、有界 Fan-out、Error Mapping 与文档化 Authorization Model。

MCP 2026-07-28 从现代路径移除了 Protocol-level Initialize Handshake、Session ID、GET Stream 与 Stream Resumption。每个 Request 都在 _meta 中携带 Protocol Version 与相关 Client Capabilities，server/discover 可用于发现版本和能力。Stateless Gateway 可以把每个 Streamable HTTP POST 路由到任意兼容实例。Sticky Routing 与共享 Protocol Session Store 只属于隔离的 Legacy 2025 路径，或由业务 Handle 显式标识的应用状态，不是现代协议默认要求。

Streamable HTTP 把路由 Metadata 暴露到 Header，但 Header 不是事实源。Request 必须携带 MCP-Protocol-Version 与 Mcp-Method，tools/call、resources/read 和 prompts/get 还必须携带 Mcp-Name。Gateway 可以据此路由、计量和实施粗粒度策略，但 JSON-RPC Body 仍是权威内容。终止协议的 Gateway 必须在路由前拒绝 Header / Body 不一致与不安全编码。只有 Tool Schema 通过 x-mcp-header 显式标注的静态可达 Primitive Property 才能映射为 Mcp-Param-*，它不是通用 Argument 镜像，更不能承载 Secret。

Capability Aggregation 会形成语义控制面。Gateway 发现每个已配置 Server，校验并散列 Tool、Resource 与 Prompt Descriptor，按不可变 Server Identity 分配 Namespace，只暴露 Policy 允许的子集。它不能静默合并重名能力，也不能把自报 serverInfo、Description、Icon 与 Annotation 当作身份或安全证据。List 与 Resource Result 可携带 ttlMs 和 cacheScope；Private Result 的 Cache Key 必须绑定 Principal、Tenant、上游 Server、Protocol Version、Policy Revision 与 Authorization Context。Change Notification 只使 Cache 失效，不会自动授权新能力。

认证与授权跨越两个独立 Hop。若 Gateway 终止受保护的下游 Endpoint，它对下游 Client 扮演 OAuth Resource Server；当它调用受保护的上游 MCP Server 时，又为该 Server 扮演 OAuth Client。必须隔离 Inbound 与 Upstream Token，校验 Issuer 与 Audience，使用 RFC 8707 Resource Indicator，并申请 Least-privilege Scope；不能因为两段都使用 OAuth 就透传入口 Token。Gateway Policy 可以拒绝请求，但每个上游 Server 仍要校验有效 Principal、Tenant、Object、Argument、Purpose 与 Side Effect。

高请求量设计始于可测工作负载，而不是连接数口号。Admission Control 应按 Principal、Tenant、Server、Capability 与 Cost Class 划分；使用带 Deadline 的短队列、Per-upstream Concurrency Limit 与 Bulkhead，避免一个慢 Server 耗尽整个 Fleet。系统要传播 Cancellation，并分别测量 Queue Time、Gateway Service Time、Upstream Time 与 Response-stream Duration。现代 Response 可以是 JSON 或 Request-scoped SSE，长期 Change Notification 则使用 subscriptions/listen；Proxy 必须避免缓冲 SSE，断线后需要重新订阅，因为协议不支持 Last-Event-ID Resume。

重试依据 Operation Semantics，而不是 HTTP Method，因为 MCP Operation 都使用 POST。Discovery 与 Read Operation 可在一致性契约和 Deadline 允许时重试。带 Side Effect 的 tools/call 只有在 Server 实施 Idempotency Key 或 Transactional Deduplication，并且前一次 Effect Status 可判定时才能重试。Timeout、Transport Loss、Cancellation 或 Circuit Open 都不能证明下游写入失败。不得用 Stale Cache 伪造成功 Tool Result；应返回有界错误，或明确标记仅供读取的降级结果。

MRTR 在不恢复 Transport Session 的情况下保留交互能力。受支持 Operation 可以返回 resultType: "input_required"；Host 收集 Elicitation 或处于弃用期的输入后，以新 Request ID、inputResponses 与不透明 requestState 重试。Gateway 只按原值转发该 State，保持 Principal 与上游绑定，不解析它，也不把它视为授权。现代 Gateway 还应将 subscriptions/listen Stream 与普通 Request 隔离，并把 Cancellation 传播到选定上游。

Gateway 是高价值攻击面。Tool Poisoning 与 Rug Pull 可通过聚合 Descriptor 进入系统；Resource 或 Tool Output 可携带 Prompt Injection；Authorization Discovery 可触发 SSRF；错误 Token 处理会造成 Confused Deputy 与 Mix-up。应固定 Upstream Provenance、限制 Egress、审查 Descriptor Change、隔离 Credential、限制 Body 与 Stream 大小，并在策略决策输入不可用时 Fail Closed。Control-plane Change 需要认证作者、Review、Rollout、Rollback 与不可变 Audit Record。

生产 Telemetry 应关联 Gateway Build 与 Policy Revision、下游 Principal 与 Tenant、入口和上游 Request ID、Protocol Version、Route 与 Upstream Server Identity、Capability 与 Descriptor Hash、Authorization Decision、脱敏 Argument Digest、Queue Time、Attempt、Cache Result、Circuit State、Response Type、Byte、Latency、Cancellation、Idempotency Decision 与 Final Effect Status。不得记录 Access Token、原始 Secret、无限制 Conversation Text 或完整敏感 Tool / Resource Payload。只有共享控制价值高于 Latency、Blast Radius、运维成本与新增单点故障风险时，Gateway 才值得部署。

主要特点

• 可选部署层：增加共享路由与治理，但不成为官方 MCP Participant，也不替代直连
• 双重协议角色：终止并聚合 MCP 时，对下游实现 Server Contract，对各上游实现独立 Client Contract
• 现代无状态数据面：依据已校验 Version、Method、Name、Identity 与 Policy 路由 Request，而不是依赖 Protocol Session Affinity
• 能力控制面：为聚合的 Tool、Resource 与 Prompt Descriptor 提供 Namespace、Filter、Hash、Cache 与变更复审
• 凭据边界：分离入口 Resource Server 授权和各上游 OAuth Client Credential，并禁止 Token Passthrough
• 可靠性边界：实施有界 Queue、Bulkhead、Backpressure、安全重试、Cancellation、Circuit Breaker 与脱敏 Telemetry

常见用途

1. 通过一个 Endpoint 暴露多个内部 MCP Server 中经过批准并带 Namespace 的能力，同时保留每个 Server 的授权
2. 依据已校验 MCP Header，把高请求量 2026-07-28 Request 分发到无状态 Gateway 与 Server Replica
3. 隔离 Tenant Quota 与 Per-server Concurrency，避免慢速或高成本能力耗尽无关流量
4. 协调相互独立的入口和上游 OAuth 关系，不跨 Resource Boundary 转发 Bearer Token
5. 跨多个 Host 审计 Capability Revision 与高影响 Tool Effect，同时对敏感 Argument 和 Output 脱敏

常见问题

相关工具

相关术语

相关文章