Microsoft 已将 Azure API Management 的专用 AI Gateway tier 推向公共预览。它的变化不只是增加一个 AI 相关功能，而是重新定义了控制面：管理对象从传统 API 转向模型、MCP Server 和工具。
这一层可以把 Foundry、Amazon Bedrock、Google Vertex AI 和 OpenAI 放到统一入口之后。架构团队因此少维护几套调用方式，平台团队也能把模型路由、工具访问和治理规则集中处理。不过，真正需要评估的问题是：Gateway 应该治理哪些事情，模型平台、业务服务和 MCP Server 又分别负责哪些事情？
控制面从 API 变成 AI 组件
传统 API Management 的核心对象是 API、操作、订阅和策略。专用 AI Gateway tier 则围绕以下对象组织：
- 模型：包括不同供应商、不同版本和不同能力的模型。
- MCP Server：为模型或智能体提供外部上下文和操作能力。
- 工具：可被模型调用的函数、数据查询和业务动作。
- 统一入口：让应用不必为每个模型供应商维护独立的连接和认证逻辑。
这类设计适合已经同时使用多个模型平台的组织。例如，内部知识问答可以使用 Foundry 中的模型，某个区域的工作负载使用 Bedrock，另一个团队则继续调用 OpenAI。应用只面对一个 Gateway 入口，后端再根据配置和策略选择实际提供商。
统一入口的价值不只在于隐藏供应商差异。它还可以成为审计、访问控制、速率限制、成本观测和模型切换的集中位置。相应地，Gateway 也会成为更敏感的基础设施：一条配置错误的路由，可能把数据发送到不应使用的模型；一个授权过宽的 MCP 工具，可能让模型执行超出预期的业务操作。
Policy cards 降低治理门槛，也改变了策略边界
预览版本强调使用 policy cards，而不是让使用者直接维护 XML 策略。对平台使用者来说，这意味着常见治理动作可以通过更贴近 AI 场景的配置完成，例如模型路由、请求限制、工具授权和访问控制。
这种方式有明显优点：策略更容易被架构师和应用团队理解，也更适合把模型供应商差异封装起来。但它同时带来一个需要验证的边界问题：哪些规则由 AI Gateway 负责，哪些规则仍应放在模型平台、MCP Server 或业务服务内部？
可以按下面的边界进行初步拆分：
| 治理问题 | 更适合放置的位置 |
|---|---|
| 统一认证、调用方身份和订阅 | AI Gateway |
| 跨供应商路由和基础限流 | AI Gateway |
| 单个模型的上下文窗口、原生安全设置 | 模型平台或模型适配层 |
| 工具是否允许访问某类业务数据 | MCP Server 与业务授权层 |
| 写入订单、发送邮件等高风险动作 | 业务服务的最终授权与确认流程 |
| 全链路审计和成本归属 | Gateway、模型平台和业务系统联合记录 |
这张表不是产品的固定限制，而是可以这样实践的架构起点。尤其不能把 MCP 工具授权简单等同于“模型可以调用的函数列表”。工具背后通常连接真实数据和真实动作，最终授权仍应由业务系统执行，不能只依赖模型提示词或 Gateway 上的一项开关。
一个统一入口的实践示例
下面的命令是一个可改造的 HTTP 示例。它假设组织已经在 AI Gateway 上配置了统一入口、模型路由和调用凭据。AI_GATEWAY_ENDPOINT、AI_GATEWAY_KEY 和请求体中的模型名称需要替换成实际环境的值；字段名称仅用于展示集成思路，具体预览 API 以部署时的产品文档为准。
export AI_GATEWAY_ENDPOINT="https://<your-gateway-host>/ai"
export AI_GATEWAY_KEY="<your-gateway-key>"
curl --fail-with-body --silent --show-error \
-X POST "$AI_GATEWAY_ENDPOINT/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $AI_GATEWAY_KEY" \
-H "X-Application-Name: knowledge-assistant" \
-d '{
"model": "general-chat",
"messages": [
{
"role": "user",
"content": "请用三句话总结本季度的服务可用性报告。"
}
],
"metadata": {
"costCenter": "platform",
"dataClass": "internal"
}
}'
在这个示例里，应用只依赖 general-chat 这样的逻辑模型名。平台团队可以把它映射到不同供应商的实际模型，并在 Gateway 层增加调用方认证、配额、日志和路由策略。迁移供应商时，应用代码不必立刻改动。
如果调用还需要 MCP 工具，建议把工具访问作为明确的治理对象，而不是隐式放开。下面是一个用于评审的策略卡草案，属于示意配置，不代表 Azure API Management 公共预览版本的精确配置格式：
# illustrative-policy-card.yaml
name: knowledge-assistant-policy
model:
logicalName: general-chat
allowedProviders:
- foundry
- openai
fallback: deny
request:
maxTokens: 4096
rateLimitPerMinute: 60
dataClassesAllowed:
- internal
mcp:
servers:
- name: company-search
allowedTools:
- search_documents
requireUserAuthorization: true
writeOperations: deny
observability:
record:
- caller
- logicalModel
- provider
- toolName
- latency
- estimatedCost
这类配置表达了几个重要决策：逻辑模型允许使用哪些供应商；请求可以处理哪类数据；MCP Server 暴露哪些工具；写操作是否默认拒绝；审计记录是否足以追踪模型、工具和成本。落地时应把这些字段映射到实际的 policy cards、身份系统和 MCP Server 授权机制中。
采用前要回答的四个问题
公共预览阶段适合做受控试点，不适合直接把所有生产 AI 流量迁移过去。评估时可以重点检查：
- 治理边界是否清楚：Gateway 负责统一入口和跨供应商规则，还是也试图承担业务授权、内容安全和工具内部权限？
- 故障转移是否可接受：不同模型的上下文窗口、工具调用能力和输出格式可能不同。自动 fallback 不能只看 HTTP 状态码。
- 数据和审计是否完整：需要确认请求内容、模型名称、实际供应商、工具调用、响应延迟和成本信息如何记录，以及哪些内容必须脱敏。
- 策略是否可版本化：policy cards 更易读，但仍应纳入代码评审、环境 promotion、回滚和变更审计流程。
一个稳妥的试点路径是先选择低风险、只读的知识查询场景，接入一个统一逻辑模型和一个只读 MCP 工具。验证认证、路由、限流、审计和故障恢复后，再考虑多供应商 fallback 以及会修改业务状态的工具。
结语
专用 AI Gateway tier 的核心意义，是让 API Management 的控制面适应多模型和工具调用时代。它为 Foundry、Bedrock、Vertex AI 和 OpenAI 提供了统一入口，也为模型和 MCP 工具的集中治理提供了一个新的落点。
但统一入口不等于统一承担所有责任。平台团队应把 Gateway 当作治理协调层，保留模型平台的原生能力、MCP Server 的工具边界，以及业务服务对高风险动作的最终授权。只有把这些边界写进策略、代码和审计流程，AI Gateway 才能从“代理转发层”真正变成可运营的 AI 基础设施。