在 Build 2026 上,微软给 Azure API Management 添加了两项 AI 网关能力,二者合起来勾勒出模型-与-agent 控制平面的去向。第一项,Unified Model API,现处于公开预览,让客户端以 OpenAI Chat Completions 格式写一次请求,由 APIM 透明地把它们翻译成 Anthropic 的 Messages API、Google Vertex AI,或其他 provider 的原生 schema。实际收益是,你可以按成本、延迟或地区切换后端、添加模型或路由流量,而无需重写客户端代码,而治理,即速率限制、内容安全、token 计量,在那一个端点背后的每个 provider 上一致施加。
更锋利的新增是面向 agentic 层的内容安全。微软把其现有的 llm-content-safety 策略从纯 LLM 文本延伸到覆盖 Model Context Protocol 工具调用和 Agent-to-Agent 通信,扫描旧策略从未看到的三样东西:MCP 工具调用参数、MCP 响应文本,以及 A2A agent 负载。它带有类别过滤(仇恨、自残、性、暴力,按 0 到 7 的严重度刻度)和一个标记 prompt-injection 尝试的 shield-prompt 属性。对于流式响应,它把事件缓冲在一个滑动窗口里,遇到违规就直接停止转发;非流式返回 403,而一个 window-size 旋钮处理超过 Azure Content Safety 一万字符上限的内容。与此并行,APIM 现在跨 OpenAI、Anthropic、Bedrock 和 Vertex 记录推理、缓存和音频 token,发布了一个正式可用的 API Center MCP Server 用于发现已注册的 MCP 服务器、工具和 agent,并加入了 REST-到-MCP 转换,使现有 API 无需重建即可作为 MCP 服务器暴露。
时机才是故事。它落地的这一周,网关恰恰是被主动攻击的对象:LiteLLM 的命令注入漏洞进入 CISA 的已知被利用清单,正是因为一个挡在每个模型前面的代理握着 AI 基础设施里最集中的凭据堆。微软的举措是同一认知的另一面。如果一个组织的所有模型与 agent 流量都漏斗式地通过一个控制平面,那个平面同时是价值最高的目标,也是你能对一切施加策略的唯一地点。把内容安全延伸到 MCP 和 A2A 是值得划线强调的部分,因为随着 agent 调用工具、彼此调用,危险负载不再只是用户的 prompt。它变成一个 agent 构造的工具参数,以及一个 agent 发给另一个的消息,而网关是看得到这一切的唯一咽喉。
它也干净地嵌进本周其他安全线索。NIST 那个证明,即没有任何有限的 guardrails 集合是不可破解的,主张持续的、可更新的施行,而非一次性的墙,而一个中央网关策略正是你持续打补丁的地方。微软明确表示把 APIM 定位为 AI 工作负载的控制平面,并指出竞争对手,即 AWS Bedrock Guardrails、Google Apigee、Cloudflare AI Gateway,在多 provider、多协议的广度上覆盖更窄。给 builder 的要点不取决于具体选微软的网关:如果你路由不止一个模型 provider,或运行多 agent 系统,治理就在网关处集中,无论你喜不喜欢,而内容安全现在必须意味着检查工具调用和 agent 间消息,而不只是审核聊天。