微软在 Build 2026 上宣布了Azure Functions Serverless智能体运行时的公开预览版，将这项事件驱动的计算服务拓展为构建与托管 AI 智能体的平台。
核心变化包括，智能体以.agent.md文件定义，这是一种以 markdown 为中心的编程模型，智能体的指令、工具、连接与行为在同一个可读文档中声明，而不是散落在代码文件里。所有 Azure Functions 触发器现在都可以生成智能体：HTTP、Timer、Service Bus、Event Hubs、SQL、Cosmos DB，或新的基于连接的触发器（用于 Teams 消息、Outlook 邮件、日历事件和 SharePoint 条目）。
Azure Functions 团队这样描述：
Azure Functions 现在有了一套将智能体视为一等公民的编程模型。智能体可以访问 MCP 工具服务器、沙箱代码，并通过 Azure Container Apps 的动态会话在浏览器中执行，同时可以使用完整的 1,400+连接器目录。像聊天 UI、HTTP 聊天 API 与 MCP 服务器端点等内置内容均为可选项，无需任何的额外代码。
运维模型保持了开发者熟悉的形态。由 Flex Consumption 负责 scale-to-zero 功能并实现了按秒计费。Managed identity 负责认证，Application Insights 负责追踪。区别在于函数唤醒后会做什么，它不再只是处理队列消息或响应 HTTP 请求，而是运行一个可以推理、调用工具、调用 MCP 服务器并通过 1,400+托管连接器与企业系统交互的智能体，包括 Microsoft 365、Teams、Outlook、SharePoint、Salesforce 与 ServiceNow 等。
InfoQ 向 Azure Functions 产品团队提出了两个从业者会立即面临的问题。在冷启动（cold start）方面，Functions 团队回应：
智能体运行时不会在 Flex Consumption 的常规 HTTP 触发器之外增加额外的冷启动。基础设施不是瓶颈，LLM 才是。
智能体执行延迟来自模型调用与提示词的复杂性，而非 Serverless 平台本身。
在成本方面，团队确认不存在所谓的“智能体税（agents tax）”：计费方式与普通函数执行保持一致并支持 scale-to-zero，与在 Flex Consumption 上运行任何其他函数相同。
.agent.md 格式是最具辨识度的架构选择。其他智能体框架通常在 Python 或 TypeScript 中定义智能体，而 Azure Functions 使用结构化的 markdown 在单一文件中描述智能体的系统提示词、可用工具、MCP 服务器连接与触发器配置。一个以 Timer 触发、汇总每日技术新闻并通过邮件发送的智能体示例如下：
---name: Daily Tech News Emaildescription: Fetches top tech news and emails a summary daily.trigger: type: timer_trigger args: schedule: "0 0 15 * * *"---You are a news assistant. When triggered, do the following:1. Scour the web for today's top tech news headlines. Use reputable sources; Include links to the original articles.2. Summarize the top stories in a concise, well-formatted HTML email body.3. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary" followed by today's date.YAML frontmatter 声明触发器与元数据，markdown 正文会成为智能体指令。MCP 服务器与工具在配套的mcp.json与agents.config.yaml中声明。运行时会解析全部配置并负责编排、工具调度与响应生成。这样一个 Timer 触发的每日新闻摘要智能体只需要一个.agent.md文件，而不是带依赖与样板的 Python 工程。
微软已经在内部尝试使用该运行时。Azure Functions 的首席项目主管Thiago Almeida告诉 InfoQ：
Azure Functions 团队构建了一个 Timer 触发的
.agent.md，用于持续审计其所有 GitHub 组织与仓库的安全态势。每次调度运行时，它会在所有仓库上推理分支保护、秘密扫描与工作流权限，然后通过相同的连接器与 MCP 工具服务器报告结果。因为运行在 Flex Consumption 上，它在运行间隙不会产生费用。
Build 2026 还在智能体运行时之外发布了若干其他的功能。MCP扩展已经达到 GA 状态，从单一工具触发器成长为跨.NET、Java、Python、TypeScript 与 JavaScript 的完整 MCP 服务器支撑，提供了工具、资源与提示词触发器。内置的 OBO(On-Behalf-Of)认证意味着托管在 Functions 上的 MCP 服务器可以继承调用者的身份。另外，微软还计划与 Microsoft Foundry Toolbox 集成，使得从 Functions 发布的 MCP 服务器可以被 Foundry 智能体自动发现。
除此之外，Durable Task Scheduler 也有两项重要的更新。其一是规模验证，随着 Microsoft Copilot 支持复杂的长时 AI 工作流，工程团队在 Azure Functions 上标准化使用 Durable Task Scheduler，统一了跨服务的状态管理、重试与恢复。该系统目前每周运行数亿次执行。其二是按需分配的沙箱（On-demand Sandboxes，私有预览），它能够为单个编排步骤提供隔离计算。每次执行都在干净的、microVM 支持的沙箱中运行，适用于原生工具链(ffmpeg、LibreOffice、Pandoc)、CPU 繁重的预处理（例如，OCR）、跨运行时步骤（例如，从.NET 编排器调用的 Python 推理活动）以及对客户插件或 LLM 生成代码的沙箱执行。
其他的 Build 2026 公告包括将 Go 作为一等语言、Azure Functions Skills 允许像 Claude Code 与 GitHub Copilot 这类编码智能体利用 Functions 运行脚手架与调试、内置 Grafana 仪表盘、Flex Consumption 的滚动更新（现在已经正式支持零停机部署），以及基于 Flex Consumption 的容器支持 OS 级依赖。
Azure 在智能体平台栈中的定位现在已经非常明确。Azure Functions 面向偏好代码的开发者，支持以其首选语言构建智能体；Logic Apps面向低代码集成工作流，提供可视画布与 AI 助理；Azure API Management则提供治理层，涵盖统一模型路由、MCP 与 A2A 流量的内容安全性与企业 Token 指标。Almeida 向 InfoQ 确认这是有意为之：
我们的确是这么考虑的，构建面向代码的 Functions、面向低代码的 Logic Apps 以及面向治理的 APIM 的三产品框架。
Serverless 智能体运行时目前处于公开预览阶段。MCP 扩展与 Flex Consumption 的滚动更新已经公开可用（GA）。
查看英文原文：Azure Functions Ships Serverless Agents Runtime at Build 2026
