先认识 MCP
MCP(Model Context Protocol,模型上下文协议)是一套让大模型与 AI Agent 以标准方式调用外部工具和数据源的协议:模型可以按统一规范去访问文件、数据库、搜索、第三方 API 与内部系统等能力,而不必为每个工具单独定制对接方式。随着 AI Agent 接入的 MCP 服务器越来越多,如何统一治理这些工具调用,就成了新的问题。
什么是 MCP 网关
MCP 网关是把各个 MCP 服务器作为「第一类资源」统一接入的入口,并用与大模型流量同一套密钥、鉴权、限流、预算与提示词 / 响应护栏,来治理每一次工具调用。当一个 AI Agent 同时接入文件、数据库、搜索与多个内部系统的 MCP 服务器时,分散的密钥、各不相同的鉴权、失控的调用频率、缺失的审计,都会成为难题。MCP 网关把这些统一收敛到一个入口来解决:让工具调用与大模型调用共用同一套密钥、鉴权、限流、预算与护栏。
为什么需要 MCP 网关
没有 MCP 网关时,每个 MCP 服务器各自实现认证与限流、各自记录日志,既难治理也难审计;工具调用又是 AI Agent 真正「动手做事」的一步,一旦失控风险更直接。MCP 网关把工具调用纳入同一治理面来应对以下问题。
分散的 MCP 服务器难以统一鉴权
当团队接入多个 MCP 服务器(文件、数据库、搜索、内部系统等)后,每个服务器各自实现认证与授权,身份与权限口径各不相同,缺少一处能统一约束「谁能调用哪些工具」的入口。
限流与配额各自为政
工具调用可能触达数据库、第三方 API 或内部服务,一旦某个 Agent 失控地高频调用,分散的 MCP 服务器难以统一限流与配额,容易拖垮下游或产生意外开销。
审计与可观测缺失
工具调用往往是 AI Agent 真正「动手做事」的一步,却常常没有统一日志与追踪:谁、用哪把密钥、调用了哪个工具、传入了什么参数、结果如何,难以事后审计。
把工具调用纳入同一治理面
MCP 网关把工具调用与大模型调用收敛到同一套治理面:同一把密钥既能调模型,也能调工具,鉴权、限流、预算、护栏、审计一处生效,而不必为工具调用另建一套治理体系。
MCP 网关的核心能力
不同产品覆盖程度不一,但一个完整的 MCP 网关通常提供以下能力。
注册与聚合多个 MCP 服务器
把分散的多个 MCP 服务器注册到同一入口并对外聚合,应用与 AI Agent 只需接入一个端点,即可发现并调用背后的多个工具服务。
按密钥 / 团队的访问控制
以密钥或团队为粒度控制「谁能调用哪些 MCP 服务器与工具」,把工具调用的授权收敛到统一入口,避免每个 MCP 服务器各自实现一套权限。
限流与预算
对工具调用做限流与配额,并可与大模型调用共用同一套预算口径,防止失控的高频调用拖垮下游或产生意外开销。
对工具调用做护栏
在入口对工具调用的输入与返回结果做校验与过滤(如敏感信息、注入、不合规内容),为 AI Agent 的「动手」环节提供与大模型流量一致的安全基线。
可观测与审计
统一采集每一次工具调用的密钥、目标 MCP 服务器、工具、参数、延迟与结果,提供日志、指标与追踪,便于排障、成本分析与合规审计。
哪些网关支持 MCP
越来越多的 AI 网关开始把 MCP 纳入能力范围,以下是几个常见选择。
AISIX
已交付 MCP 网关,用与大模型流量同一套密钥、限流与护栏来治理 MCP 工具调用,把 MCP 服务器作为第一类资源纳入同一治理面。
LiteLLM
开源版即包含 MCP 网关能力,可在其代理中接入并治理 MCP 服务器。
Portkey
提供 MCP 网关,可在其网关与治理平台中接入 MCP 工具服务。
Envoy AI Gateway
在 v1.0 GA 中提供 MCP 支持,把 MCP 纳入其 AI 网关能力。
Kong
MCP 相关能力位于企业版中。
