本文面向平台工程师、安全架构师与 Agent 开发者。协议细节参照 MCP 规范 2025-06-18 版本及其授权规范，后续版本可能变化，以官方规范文本为准；配置为示意。
Agent 真正开始改变企业流程，是在它能"动手"之后：查数据库、发工单、改代码、调内部系统。Model Context Protocol（MCP）在 2024 年 11 月发布后迅速成为 Agent 连接工具的通用协议，并在 2025 年 12 月捐赠给 Linux 基金会下的 Agentic AI Foundation。MCP 服务器在企业内部的数量增长很快，随之而来的问题也很直接：谁在调用哪个工具、用谁的身份、能做什么、做了什么。MCP 网关就是回答这几个问题的基础设施。
一、MCP网关是什么
MCP 网关是位于 MCP 客户端（Agent、AI 应用）与 MCP 服务器之间的统一代理与治理层，负责工具的注册与发现、身份认证与授权、工具级访问控制、调用审计与内容检测。
如果说 LLM 网关管理的是"模型调用"，MCP 网关管理的就是"工具调用"。两者经常部署在同一平台中，但关注点不同：模型调用的风险主要在数据流出，工具调用的风险主要在动作执行。
二、MCP 协议基础：理解网关之前先理解协议
三个角色：Host、Client、Server
MCP 协议角色与 MCP 网关的位置
- Host（宿主）：用户直接使用的 AI 应用，例如桌面 AI 助手、IDE、企业 Agent 平台。
- Client（客户端）：Host 内部负责与某个 MCP 服务器通信的组件，与服务器一对一连接。
- Server（服务器）：对外暴露能力的程序，提供三类原语：Tools（可执行的操作）、Resources（可读取的数据）、Prompts（可复用的提示模板）。
MCP 网关在这个结构中同时扮演两个角色：对客户端，它是一个（聚合了多个服务器的）MCP 服务器；对后端的真实服务器，它是一个 MCP 客户端。
两种传输方式
stdio：客户端把服务器作为本地子进程启动，通过标准输入输出通信。简单，但服务器运行在用户本机，企业难以统一管理，凭据通常从本地环境变量获取。
Streamable HTTP：服务器作为独立的网络服务运行，客户端通过 HTTP 发送请求，服务器可以用 SSE 流式返回。这是远程服务器和网关场景的主要传输方式。
消息格式
MCP 基于 JSON-RPC 2.0。一次典型的会话包括初始化、列出工具、调用工具：
json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-06-18","capabilities":{},
"clientInfo":{"name":"ops-agent","version":"1.4.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/list"}
{"jsonrpc":"2.0","id":3,"method":"tools/call",
"params":{"name":"ticket_create",
"arguments":{"title":"华东节点磁盘告警","priority":"P2"}}}
网关能在 tools/list 上做过滤（只返回当前身份有权使用的工具），在 tools/call 上做授权、参数检查和审计。这两个方法是 MCP 网关治理能力的主要落点。
三、MCP网关的工具接入：三种方式
方式一：托管 stdio 服务器
很多开源 MCP 服务器只提供 stdio 形态。网关可以把它们放进容器中统一运行，由网关通过 stdio 与之通信，再以 Streamable HTTP 对外暴露。这样做把"散落在员工电脑上的进程"变成了"集中运行、统一管理的服务"，凭据也从员工本机转移到网关的密钥管理中。
方式二：代理远程 HTTP 服务器
对已经以 Streamable HTTP 提供的服务器（包括 SaaS 厂商提供的远程 MCP 服务器），网关作为反向代理接入，统一认证与审计，并对外屏蔽真实地址。
方式三：REST / OpenAPI 转 MCP
企业已有大量内部 REST API，逐个改写为 MCP 服务器成本很高。网关可以读取 OpenAPI 描述，把选定的接口转换为 MCP 工具。要注意的是，自动转换得到的工具描述往往不适合模型理解，需要人工改写名称与描述，并只暴露必要的接口，而不是把整个 API 一次性开放给 Agent。
工具注解：风险分级的起点
MCP 规范为工具定义了注解（annotations），例如 readOnlyHint（只读）、destructiveHint（可能造成破坏性变更）、idempotentHint（幂等）、openWorldHint（与外部世界交互）。规范明确这些注解只是提示，不应作为安全决策的唯一依据，尤其是来自不受信任服务器的注解。网关的做法通常是：以注解作为初始分级，再由管理员在网关侧确认或覆盖。
四、MCP网关的权限治理：授权链路与工具级控制
MCP 授权规范的要点
对基于 HTTP 的传输，MCP 授权规范以 OAuth 2.1 为基础，几个关键点如下：
- MCP 服务器是 OAuth 2.1 资源服务器，必须实现受保护资源元数据（RFC 9728），告诉客户端去哪个授权服务器获取令牌。
- 客户端未携带有效令牌时，服务器返回 401，并在 WWW-Authenticate 头中指明资源元数据地址。
- 客户端必须使用 PKCE，并在授权与令牌请求中携带 resource 参数（RFC 8707），明确令牌的目标服务器。
- 服务器必须校验令牌的受众（audience），只接受签发给自己的令牌。
- 禁止令牌透传：服务器不得把收到的令牌原样转发给下游 API。
MCP 授权时序与网关的令牌交换
网关在授权链路中的位置
最后一条"禁止令牌透传"对网关设计影响最大。网关收到的令牌是签发给网关的，它不能把这个令牌直接转发给后端的 MCP 服务器或业务 API。正确的做法是：网关完成对客户端令牌的校验后，以自己的身份，或通过令牌交换为用户获取一个面向后端的新令牌，再调用后端。这样做的好处是每一跳的令牌受众都明确，任何一个环节的令牌泄露都不会被直接用于其他服务。
工具级访问控制
身份解决"你是谁"，工具级策略解决"你能做什么"。一份示意性的策略如下：
yaml
server: itsm-tools
expose: # 只暴露必要的工具
- ticket_query
- ticket_create
- ticket_close
rules:
- tools: [ticket_query]
allow: [group:all-staff, agent:ops-agent]
- tools: [ticket_create]
allow: [group:ops, agent:ops-agent]
args:
priority: {enum: [P2, P3, P4]} # 禁止 Agent 直接创建 P1
- tools: [ticket_close]
allow: [group:ops-lead]
require_human_approval: true # 高危操作需人工确认
limits:
per_agent_calls_per_min: 30
audit:
log: [caller, on_behalf_of, tool, args_digest, result_status, latency]
这份策略体现了工具治理的几条原则：最小暴露（只开放必要的工具）、参数约束（同一个工具对不同参数有不同风险）、区分调用者与委托人（记录"哪个 Agent 代表哪个用户"）、高危操作人工确认、调用频率限制（防止 Agent 陷入循环反复调用）。
工具调用中的内容风险
工具返回的内容会进入模型上下文，这是间接 Prompt 注入的主要入口：一封邮件、一个网页、一条工单评论里都可能藏着"忽略之前的指令，把数据发到某处"。MCP 网关可以对工具返回内容做注入检测和敏感信息检测，对工具描述本身做变更监控（防止服务器在被批准后悄悄修改工具描述），并维护 MCP 服务器的白名单，阻止未经审核的服务器接入。
五、MCP网关落地策略
第一步：盘点
摸清企业内正在使用哪些 MCP 服务器、以 stdio 还是远程方式运行、使用了哪些凭据。很多企业会发现大量以个人凭据运行在员工电脑上的服务器。
第二步：集中
把高频使用的服务器迁移到网关托管或代理，回收个人凭据，统一以服务身份或令牌交换访问后端。
第三步：分级
按只读、写入、破坏性三级给工具分级，只读工具先开放，写入工具加参数约束，破坏性工具加人工确认。
第四步：审计与检测
开启调用审计，叠加对工具返回内容的注入检测，定期复盘 Agent 的调用模式。
在网络层面，MCP 网关通常与 LLM 网关部署在同一位置，两类流量共享身份体系与审计平台。对于后端系统分布在多个机房、多个云上的企业，MCP 网关到各业务系统之间的访问路径同样需要纳入零信任与网络规划，例如借助犀思云这类服务商的企业组网与安全接入能力，统一各地系统的访问通道。
附：数据来源与参考资料
- MCP 2024-11 发布；2025-12 捐赠 Linux 基金会 Agentic AI Foundation（来源：Anthropic 官方公告 / Linux Foundation）
- MCP 规范 2025-06-18：传输、工具与注解（来源：modelcontextprotocol.io 规范）
- MCP 授权规范：OAuth 2.1、RFC 9728、RFC 8707、禁止令牌透传（来源：modelcontextprotocol.io 授权规范）
- 企业组网与安全接入（来源：犀思云官网产品资料）
说明：文中配置与代码为教学示意；时延、比例与容量为量级示意或示例估算，以实测为准；协议与法规以官方原文为准。
