Azure Functions 在 Build 2026 大會上推出了一項重大更新，正式引入 Serverless Agents Runtime。這次更新將 Azure Functions 從傳統的事件驅動計算服務，轉型為一個能夠構建與託管 AI Agent（AI 代理）的平台。對於工程師來說，這意味著開發 AI 代理的門檻大幅降低，且能直接利用 Serverless 的彈性擴展能力。
核心變革：以 Markdown 為中心的開發模式
以往開發 AI 代理通常需要撰寫大量的 Python 或 TypeScript 程式碼來定義 Prompt、管理工具調用（Tool Calling）以及處理對話邏輯。而 Azure Functions 現在引入了一種名為 .agent.md 的編程模型。
這種模型允許開發者將代理的指令、可用工具、連接對象與行為定義在單一的 Markdown 檔案中。檔案頂部的 YAML 區塊定義觸發條件（例如定時觸發或 HTTP 請求），而正文部分則是直接寫給 LLM 的系統指令。這種做法將配置與邏輯統一，避免了開發者在多個程式碼檔案之間切換，讓代理的定義變得直觀且易於維護。
觸發機制與生態系統的整合
AI 代理不再僅限於對話視窗，它可以被任何 Azure Functions 的觸發器啟動。除了常見的 HTTP 請求，還包括 Timer（定時器）、Service Bus（訊息佇列）、SQL 數據庫，以及針對 Microsoft 365 生態系的 Teams 訊息、Outlook 郵件與 SharePoint 事件。
在能力擴展方面，這些代理可以存取 MCP（Model Context Protocol，一種標準化的模型上下文協議，旨在讓 LLM 能以統一方式連接外部數據與工具）伺服器，並透過 Azure Container Apps 的動態會話執行沙箱代碼或瀏覽器操作。此外，開發者能直接調用超過 1,400 個受管連接器，讓 AI 代理能直接與 Salesforce、ServiceNow 等企業系統互動。
運維成本與效能考量
對於 Junior 工程師最關心的冷啟動（Cold Start）與成本問題，微軟給出了明確的解答。
在冷啟動方面，由於該運行時基於 Flex Consumption（彈性消費計劃），其基礎設施的啟動延遲與普通函數無異。真正的延遲瓶頸在於 LLM 的模型推論時間與 Prompt 的複雜度，而非 Serverless 平台本身。
在成本方面，並沒有額外的代理稅。開發者只需支付標準的函數執行費用，且依然享有 Scale-to-Zero（縮減至零）的特性，也就是在沒有任務執行時不需要支付任何費用。
進階功能：MCP 與沙箱環境
除了代理運行時，本次更新還強化了 MCP 擴展功能，使其正式進入 GA（正式發佈）階段。這讓開發者可以用 .NET、Java、Python 等多種語言構建 MCP 伺服器，並利用 OBO（On-Behalf-Of，代表用戶）認證機制，讓伺服器直接繼承調用者的身分權限。
同時，Durable Task Scheduler（持久化任務調度器）引入了按需沙箱（On-demand Sandboxes）。這為複雜的 AI 工作流提供了隔離的微型虛擬機（microVM）環境，適合執行 CPU 密集型任務（如 OCR 光學字符識別）或執行由 LLM 自動生成的不可信代碼，確保主系統的安全。
Azure AI 代理平台的定位分工
為了避免產品線重疊，微軟明確了三款產品在 AI 代理生態中的定位：
Azure Functions 針對 Code-first 開發者，適合需要靈活控制、使用偏好語言構建代理的工程師。 Logic Apps 針對 Low-code 開發者，提供視覺化畫布與 AI 助手，適合快速構建集成工作流。 Azure API Management 則作為治理層（Governance Layer），統一管理模型路由、內容安全過濾以及 Token 消耗指標。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。