一个被忽略的请求后半程

想象一个相当常见的部署：智能体放在AI网关后面，提示词做了速率限制，个人身份信息被清洗，成本按团队归集，越狱尝试会被标记。这套配置看起来已经比较完整。随后智能体通过MCP接入工具调用，去访问客户关系管理系统、内部搜索索引和若干内部接口。网关这边没有任何变化，因为从网关的视角看，模型调用进出仍然保持原样。

但此时请求多出了第二段路径，而这一段没有任何人在观察。

AI网关与MCP网关各管一段

AI网关本质上是面向大模型流量的反向代理。它位于应用和模型供应商之间，无论调用的是OpenAI、Anthropic、Bedrock、Gemini还是自托管模型，都统一收敛到一个接口后面。它处理的内容围绕模型流量展开：基于令牌的速率限制、流式响应、供应商故障切换、语义缓存、成本归因，以及对输入提示和输出补全的内容策略。

结构上它看不到模型决定调用工具之后发生的事。一旦补全结果里包含工具调用，执行就转移到运行智能体工具逻辑的组件上。如果这部分通过模型上下文协议进行，那就是完全不同的另一条传输通道。

MCP网关补上的治理空白

MCP是一个开放标准，让智能体通过一致的客户端－服务器接口发现并调用外部工具和数据源，避免每个团队为每种模型到系统的组合手写连接器。它常被描述为把M×N的集成问题变成M+N：每个系统一个客户端、一个服务器，任何符合MCP规范的组件都能互相通信。

方便归方便，MCP本身对治理没有约束。协议不阻止智能体调用服务器暴露的所有工具，也不记录它实际用这些工具做了什么。MCP网关正是放在这段流量前面，补上几项能力：为每个智能体到服务器的连接做认证，包括远程服务器的OAuth流程；按工具、按智能体做授权，不只是判断智能体能否访问服务器，还要限定它能用服务器上的哪些具体工具；盘点整个组织内的MCP服务器，包括那些没人登记的影子服务器；记录谁调用了什么、带什么参数、返回什么结果的审计日志；检查工具调用和返回结果中是否藏有注入尝试或数据外泄。

逐工具策略的实际形态

一个MCP网关会执行的逐工具策略大致可以这样描述：智能体是支持机器人，服务器是内部客户关系管理系统。允许清单里包括查询客户工具，每分钟最多调用20次；更新工单状态工具，无需审批。拒绝清单里则包括导出客户工具。

这种粒度是AI网关无法提供的。AI网关看到的是模型请求和模型响应，MCP网关看到的是工具调用和工具返回。两者观察的流量不同，能执行的策略自然也不同。

生产环境为什么通常需要两者并用

当智能体只做文本生成时，AI网关已经覆盖了主要风险面。一旦智能体开始通过MCP调用内部系统，请求路径上就出现了一段AI网关看不见的流量。工具调用可能携带敏感参数，工具返回可能夹带不该离开内网的数据，某个智能体可能越权调用未授权工具。这些风险都落在MCP网关的职责范围内。

把AI网关和MCP网关分开看待，不是因为其中一个不够好，而是因为它们本来就是为请求路径的不同阶段设计的。模型流量需要令牌级控制、供应商切换和内容策略，工具流量需要逐工具授权、调用审计和返回内容检查。两者叠加，才能覆盖从提示词进入到工具执行完成的完整链路。