微软为 MCP 服务器发布了 Azure 函数支持

作者 | Tim Anderson

译者 | 刘雅梦

策划 | 丁晓昀

微软已将其模型上下文协议（MCP）对 Azure Functions 的支持提升至一般可用性，标志着向标准化、身份安全的代理式工作流程的转变。通过集成原生 OBO 认证和流式 HTTP 传输，本次更新旨在解决历史上阻碍 AI 智能体访问敏感下游企业数据的“安全痛点”。

MCP 扩展于 2025 年 4 月进入公开预览，现支持 .NET、Java、JavaScript、Python 和 TypeScript，而新的自托管选项允许开发者在不修改代码的情况下部署现有的基于 MCP SDK 的服务器。

由 Anthropic 开发的模型上下文协议（Model Context Protocol）提供了一个标准化的接口，使 AI 智能体能够访问外部工具、数据源和系统。自 2024 年 11 月推出以来，包括 OpenAI、谷歌 DeepMind 和微软在内的主要 AI 平台已采用该协议，到 2025 年 4 月，服务器下载量从大约 10 万次增长到超过 800 万次。

然而，正如 Mirantis 的 Randy Bias所指出的那样：“安全和合规团队不能允许运行在开发人员笔记本电脑上的未经审查的‘影子代理’访问电子医疗记录或客户个人身份信息等关键数据系统”——这推动了对具有内置治理的托管平台的需求。

一般可用的 MCP 扩展引入了几个为生产部署设计的功能。对流式 HTTP 传输协议的支持取代了旧的服务器发送事件（SSE）方法，微软建议除非客户端特别需要 SSE，否则使用新的传输。该扩展暴露了两个端点：/runtime/webhooks/mcp 用于流式 http 和 /runtime/webhooks/mcp/sse 用于遗留的 SSE 连接。

对于 Java 开发人员，Maven 构建插件（版本 1.40.0）提供了构建时对 MCP 工具注释的解析和验证，自动生成正确的扩展配置。根据微软的说法，这种构建时分析可以防止运行时反射在 Java 应用程序中引入的冷启动时间增加。

内置的认证和授权实现了 MCP 授权协议 要求，包括发出 401 挑战和托管受保护资源元数据文档。开发者可以为服务器认证配置 Microsoft Entra 或其他 OAuth 提供商。该功能还支持代表用户（OBO）认证，使工具能够使用用户的身份而不是服务账户访问下游服务。

首席软件工程师 Den Delimarsky 在 2025 年 4 月分享了关于使用 Azure Functions 和 API 管理实现安全的 MCP 服务器的 见解：

开发者面临的一个主要痛点是实现与认证和授权相关的任何内容。如果你没有安全专业知识，这本质上是痛苦且有风险的。你可能会错误地配置一些东西，最终将所有数据暴露给不能看到它们的人。

Sitecore 的云架构师 Victor Karabedyants详细说明 了实践中的认证流程。当客户端连接到远程 MCP 服务器时，Azure Functions 会以包含受保护资源元数据路径的 401 响应拒绝初始匿名请求。客户端读取此元数据，触发 Microsoft Entra ID 登录流程，获得 OAuth 令牌，并用令牌重试请求。“你的 Python 或 Node 脚本永远不会看到认证逻辑，”Karabedyants 解释说。“平台负责处理繁重的工作。”

对于 Java 开发者，Maven Build Plugin（版本 1.40.0）在构建时提供 MCP 工具注释的解析和验证，自动生成正确的扩展配置。据微软称，这种构建时分析可以防止 Java 应用程序中运行时反射引入的冷启动时间增加。

新的自托管 MCP 服务器 功能目前处于公开预览阶段，允许团队将使用官方 SDK 构建的 MCP 服务器部署到 Azure Functions 作为自定义处理程序；轻量级 Web 服务器代理请求到开发者的现有进程。微软将此描述为“提升和转移”方法，只需要一个 host.json 配置文件来定义 Functions 应该如何运行服务器。该功能目前支持使用 Python、TypeScript、C# 或 Java SDK 实现的流式 http 传输的无状态服务器。

（来源：Microsoft Learn）

微软的高级云倡导者 Yohan Lasorsa 在开发者社区 博客文章中 强调了自托管方法的简单性：

在 Azure Functions 上托管 MCP 服务器，可以让你兼得两者的优点：无服务器基础设施的简单性和官方 Anthropic SDK 的强大功能。只需一个简单的配置步骤，你就可以将现有的 Node.js MCP 服务器部署到一个生产就绪、自动扩展的平台。

Gaurav Rawat 在 Medium 上一篇关于生产部署模式的详细 文章 中，强调了在大规模运行 MCP 服务器时的几个运维考虑因素。他指出，对于 P95 延迟超过 1 秒、错误率超过 2% 以及 SSE 连接频繁掉线等监控指标，需要在生产环境中立即进行调查。

Rawat 还记录了实践者应该意识到的当前限制：在与 Azure AI Foundry 集成时，嵌套数组和复杂类型必须序列化为逗号分隔的字符串，并且由于 UI 基础的批准在自动化部署中不持久，因此需要使用 require_approval="never"进行程序化工具批准以用于生产工作流程。

Azure Functions 提供了多种托管计划，以满足不同的 MCP 服务器需求。Flex 消费计划根据需求自动扩展，采用按执行付费的计费模式和零规模经济。当 MCP 工具闲置时，成本降至零，同时保持快速的唤醒时间。Premium 计划支持“始终就绪”的实例，这些实例保持预初始化状态，消除了冷启动延迟，这对于初始化延迟可能导致 SSE 连接超时和代理响应时间差的关键时刻工具至关重要。Rawat 建议为关键的 24/7 工具设置两到三个始终就绪的实例，以确保故障转移能力。开发人员还可以使用专用计划来满足需要可预测性能或与虚拟网络集成的工作负载。

微软已经发布了多种语言的快速入门模板，涵盖这两种托管方法。MCP 扩展快速入门覆盖了 C# (.NET)、Python、TypeScript (Node.js)，Java 快速入门即将推出。该平台直接与 Azure AI Foundry 集成，允许智能体在无需额外配置层的情况下发现和调用 MCP 工具。

https://www.infoq.com/news/2026/01/azure-functions-mcp-support/

声明：本文为 InfoQ 翻译，未经许可禁止转载。