微软AI网关层级引发争论：统一治理背后的权限隐忧

微软已发布 Azure API 管理专用 AI 网关层的公开预览版。此网关资源围绕模型、MCP 服务器和工具而非 API 来组织其控制平面，并作为独立体验构建，尽管经典版和 v2 层保留了其现有 AI 网关功能。该预览版可发布在 Foundry 上托管的模型，包括 OpenAI、Anthropic 和 Mistral，以及来自 AWS Bedrock、Google Vertex AI 和 OpenAI 的模型。所有兼容 OpenAI 的提供商共享一个端点路径，基于精确的模型字段匹配进行路由，因此每个已发布的模型需要唯一名称；Anthropic 通过自定义提供商处理，该提供商传递 Messages API。策略通过门户中的卡片而非 XML 和表达式进行配置，涵盖令牌和请求限制、配额、内容安全性和模型故障转移。遥测作为 OpenTelemetry 令牌指标导出到 Application Insights、Datadog、Grafana 和其他客户控制的目标，并且该资源在客户自己的订阅和 Entra 租户中运行。对于工具，网关从三个来源联合后端：通过 URL 连接的远程 MCP 服务器、OpenAPI 规范或涵盖超过一千个 SaaS 应用的内置连接器，无需托管服务器。每个后端的操作变为工具，团队可以为每个后端选择身份验证：无、API 密钥、OAuth 2.0 或托管身份。预期的运营模式将中央控制与团队自助服务分开：平台团队连接并发布已批准的模型和工具，而应用团队在测试控制台中使用这些资产，无需将每个更改都通过中央团队路由，尽管平台团队继续处理护栏和整体使用情况。架构师和平台工程师总体反应积极，但对治理边界提出了疑问。AI 工程师通讯作者 Paolo Perrone 指出，网关中的成本治理被低估，称其为“控制平面而非逐个应用打补丁”。企业 AI 架构师 Adolph White Jr. 提出了最尖锐的开放性问题：当代理运行未正确终止时会发生什么，询问输出是否保留以供审计，或者是否发生故障转移和重试，以区分 AI 流量治理与完整生命周期治理。公告未指定代理输出控制属于网关还是上层编排层。并非所有反馈都是正面的；来自 Aer Lingus 的 Sreenivasulu Kandakuru 表示该层迫切需要，但认为 Azure 落后于 AWS 和 Databricks，引用了六月数据与 AI 峰会中的 Unity AI 网关，该网关扩展了 Unity Catalog 以治理模型、代理、MCP 服务和技能，具有硬性支出上限、智能路由和内容护栏，并路由外部编码代理，如 Claude Code 和 Codex。微软拥有 AI 网关功能约两年，因此实际差距并不像比较所暗示的那样大。一个值得审视的设计决策是：运行时访问密钥作用域为整个网关，可访问其上的每个模型和工具；微软建议每个应用使用一个密钥，但密钥泄露会影响整个网关。依赖 APIM 订阅将用户限制到一组 API 的团队在此不会找到该边界。预览版为尽力而为，无 SLA，API、遥测、限制、区域和定价在正式发布前可能更改。预览配额限制模型、工具、运行时密钥和吞吐量，但具体细节尚未公布；定价稍后公布，使成本治理成为最不确定的部分。一个关键未解答的问题是共存，且混乱已很明显：AI 工程师 Rajib Mahapatro 回应称他们已在生产环境中使用四个月，提到了缓存、内容安全性、日志记录和令牌限制，这些都是现有功能。微软文档将 AI 网关描述为现有 API 管理网关的扩展，而非独立产品，且尚无公开指南说明现有 Premium 或 Standard v2 投资是否会被继承、并行运行或迁移。AI 网关层在美国东部 2 区和瑞典中部可用，预览期间免费，提供实验性教程，介绍发布受治理的 Foundry 模型和观察令牌速率限制。