Microsoft 将 Azure API Management 的 AI Gateway 专用层开放为公开预览。它不再只把 AI 流量视为一组普通 HTTP API，而是围绕模型、MCP Server 和工具构建控制平面，并计划用策略卡片取代传统 XML 策略配置。更重要的是，Foundry、Amazon Bedrock、Google Vertex AI 和 OpenAI 可以被收敛到统一入口之后。
这项变化解决了多模型接入中的一部分工程复杂度，但也带来一个必须提前回答的问题：网关应该管到哪里，模型平台、身份系统和业务应用又各自负责什么？
控制对象从 API 变成模型与工具
传统 API 网关通常围绕路由、方法、订阅、配额和响应码组织资源。生成式 AI 的治理对象更复杂：同一个聊天接口背后可能切换多个模型，模型还可能通过 MCP 调用搜索、数据库或工单系统。
因此，AI Gateway 专用层把模型、MCP Server 和工具提升为控制平面中的一等对象。这种资源模型更贴近实际调用链：
客户端
-> AI Gateway
-> 模型：Foundry / Bedrock / Vertex AI / OpenAI
-> MCP Server
-> 搜索工具
-> 数据库工具
-> 工单工具
对平台团队而言，这意味着可以在统一入口处理认证、流量限制、后端选择和调用观测，而不必让每个应用分别集成四套模型供应商接口。策略卡片则试图降低 XML 策略的维护门槛，让架构师和平台管理员围绕具体治理能力组合策略。
不过，公开预览阶段不应把“统一入口”理解为“供应商差异已经消失”。模型名称、上下文窗口、流式响应、工具调用格式、内容过滤能力和错误语义仍可能不同。网关可以统一接入面，但应用仍需定义可接受的兼容范围。
一个端点带来的收益与代价
统一端点最直接的收益是隔离变化。业务应用只依赖企业内部的网关地址，平台团队则可以调整后端模型、密钥和路由规则。发生区域故障、配额耗尽或模型退役时，也更容易集中切换后端。
这种架构同时引入新的集中风险：
- 网关会成为高价值凭据、提示词和模型响应经过的集中节点。
- 错误的全局策略可能同时影响多个应用和模型。
- 如果只记录 HTTP 状态码，而不记录模型、令牌量、工具调用和策略决策，统一入口反而会降低排障能力。
- 多供应商路由可能造成结果漂移，同一个提示词在不同模型上不一定产生可替换的输出。
- MCP 工具具有执行副作用时，普通 API 限流不足以构成完整授权机制。
因此，生产设计不能只有“请求能否通过”这一层，还要考虑调用者身份、模型权限、工具权限、数据分类、成本预算和审计关联。
可以这样实践：先定义稳定的客户端契约
下面是一个可复制并改造的调用示例。由于摘要没有给出预览版资源的确切 URL、请求路径和认证头，这里明确采用一个假设：团队在 AI Gateway 上暴露了与 OpenAI Chat Completions 风格兼容的内部接口。运行前需要把 AI_GATEWAY_URL、AI_GATEWAY_TOKEN 和模型别名替换成实际配置。
export AI_GATEWAY_URL="https://gateway.example.com"
export AI_GATEWAY_TOKEN="replace-with-a-short-lived-token"
curl --fail-with-body --silent --show-error \
-X POST "$AI_GATEWAY_URL/v1/chat/completions" \
-H "Authorization: Bearer $AI_GATEWAY_TOKEN" \
-H "Content-Type: application/json" \
-H "X-Correlation-ID: demo-$(date +%s)" \
-d '{
"model": "customer-support-default",
"messages": [
{
"role": "system",
"content": "Answer only from the supplied customer-service context."
},
{
"role": "user",
"content": "Summarize the refund policy in three bullet points."
}
],
"temperature": 0.2
}'
这里故意使用 customer-support-default 这样的业务别名，而不是供应商模型名称。别名可以由网关映射到具体模型，使应用与供应商版本解耦。但这种映射必须可审计：每次请求至少应记录最终后端、模型版本、策略版本、调用者、关联 ID、延迟和令牌用量。
如果需要验证多供应商切换不会破坏业务契约，可以这样建立最小回归测试。示例仍假设网关提供兼容接口：
import os
import requests
url = os.environ["AI_GATEWAY_URL"].rstrip("/") + "/v1/chat/completions"
token = os.environ["AI_GATEWAY_TOKEN"]
payload = {
"model": "customer-support-default",
"messages": [
{"role": "user", "content": "Reply with exactly: gateway-ok"}
],
"temperature": 0,
}
response = requests.post(
url,
headers={
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
"X-Correlation-ID": "gateway-smoke-test",
},
json=payload,
timeout=30,
)
response.raise_for_status()
body = response.json()
content = body["choices"][0]["message"]["content"].strip()
assert content == "gateway-ok", body
print("AI Gateway smoke test passed")
安装依赖并运行：
python -m pip install requests
export AI_GATEWAY_URL="https://gateway.example.com"
export AI_GATEWAY_TOKEN="replace-with-a-short-lived-token"
python smoke_test.py
真实回归测试不应只检查固定文本，还应覆盖流式输出、超时、限流、后端故障、工具拒绝、敏感数据策略和模型切换后的结构化输出。
MCP 让治理边界变得更尖锐
模型调用通常是读取和生成信息，MCP 工具却可能执行操作。例如，“查询订单”与“取消订单”可以挂在同一个 MCP Server 上，但风险完全不同。网关识别出工具，并不等于它已经拥有足够的业务上下文来批准工具执行。
比较稳妥的职责划分是：
- AI Gateway 负责入口认证、模型与工具发现、全局限流、基础策略和统一审计。
- MCP Server 负责工具级授权、参数校验、租户隔离和副作用控制。
- 业务服务继续执行领域规则，例如退款期限、审批额度和订单状态约束。
- 身份系统签发短期、范围受限的凭据，避免在网关或提示词中传递长期密钥。
- 应用负责向用户展示关键操作，并在高风险工具执行前取得明确确认。
对于写操作，还应使用幂等键，并把“模型建议调用工具”和“系统批准执行工具”拆成两个事件。否则，重试、模型重复调用或提示词注入都可能造成不可逆副作用。
公开预览阶段的采用清单
这项专用层适合先放入受控试点，而不是立即替换所有模型接入。落地时可以按以下清单推进：
- 选择一条低风险、可回滚的模型调用链作为试点。
- 用业务模型别名隔离供应商和版本变化。
- 明确哪些策略放在网关，哪些规则必须保留在 MCP Server 与业务服务中。
- 检查流式响应、工具调用和供应商特有参数是否会被统一接口丢失。
- 为策略变更建立评审、版本管理和回滚流程，即使策略卡片降低了配置难度。
- 将提示词、响应内容和工具参数按敏感数据处理，并配置必要的脱敏与留存期限。
- 对后端切换运行质量、延迟、成本和结构化输出回归测试。
- 为网关故障、供应商限额和模型不可用准备降级路径。
Azure API Management 的 AI Gateway 专用层把多模型与 MCP 工具治理集中到一个更符合 AI 工作负载的控制平面中。它减少的是接入和策略分散，而不是业务授权、模型差异与数据治理本身。能否真正降低系统风险，取决于团队是否把统一入口与清晰的责任边界一起设计。