Azure Functions | The .NET Blog

Microsoft Agent Framework中的持久工作流：从内存到Azure Functions

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

早期AI代理工作流的痛点之一：它们很脆弱。绑定到单个进程的长时间运行多步骤工作流意味着进程重启 = 状态丢失。对于简单的演示这没问题。对于生产工作负载则不然。

Microsoft Agent Framework的工作流编程模型现在支持持久执行，由Durable Task框架支持，通过Azure Functions托管。以下是编程模型的工作原理以及持久性为何重要。

核心构建块

Executor是工作的基本单元。每个都是类型化的——接受特定输入并生成特定输出：

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // 查找订单，返回它
 return new Order(Id: message.OrderId, ...);
 }
}

工作流使用流畅构建器将执行器连接成有向图。框架处理执行、步骤之间的数据流和错误传播。

您可以建模：

顺序链（步骤A → 步骤B → 步骤C）
并行fan-out/fan-in（并行运行代理A、B、C，聚合结果）
条件分支
人在回路审批（暂停工作流，等待外部信号）

本地开发的内存运行器

入门很快：

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

核心包包含轻量级进程内运行器。无外部依赖，无数据库，无Azure资源。非常适合本地开发和单元测试。

使用Durable Task添加持久性

当工作流需要在进程重启后继续运行时——因为它运行时间长，因为它有人在回路步骤，因为它分散在许多并行代理调用中——内存运行器不够用。

MAF的Durable Task集成将工作流状态存储在Azure Storage中。如果进程重启，工作流从中断处继续。编程模型保持不变；只需替换运行器。

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

相同的执行器，相同的工作流图——由持久状态支持。

Azure Functions托管

第三层是Azure Functions托管。您的工作流成为Function应用：通过HTTP端点触发工作流，持久运行时处理扩展、状态和可靠性。

这意味着具有并行调用、条件分支和人工审批的多代理工作流可以在无服务器Functions环境中扩展，无需自定义状态管理。

为什么这很重要

这种组合对真实AI系统很重要：

并行代理调用——同时分发给多个专门代理而不阻塞，所有代理完成时聚合结果
长时间运行进程——涉及人工审批或外部事件的工作流可以跨小时或天暂停和恢复
扩展性——Azure Functions水平扩展执行；Durable Task框架管理并行状态协调

如果您正在构建超越简单本地演示的MAF工作流，这就是走向生产质量执行的道路。

原始文章：Durable Workflows in the Microsoft Agent Framework

停止锤打一个挣扎中的依赖：Azure Functions + Service Bus 的重试模式

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

以下是可恢复故障在 Functions 应用中变成服务中断的过程：依赖项开始超时，每个 Functions 实例立即无限重试，依赖项被数百个并发失败的请求轰炸，原本只是短暂故障的问题变成了全系统的反压事件。

你可能对这个故事很熟悉。Azure Functions 快速扩展 — 这就是整个意义所在。但"快速扩展"和"立即重试"结合在一起可能会使故障急剧恶化。

两种模式有所帮助。指数退避和熔断器。两者现在都为 Service Bus 触发的 Azure Functions 提供原生支持。

两种模式，不同角色

这些模式是互补的，而非替代：

指数退避回答：我应该什么时候重试？ 它增加重试之间的延迟，让依赖项有时间恢复。在消息级别，调整重试时机。

熔断器回答：我现在是否应该调用这个依赖项？ 在达到失败阈值后停止对不健康依赖项的重复调用，然后在冷却期后谨慎地探测。在系统级别，防止重试风暴。

你需要两者。退避处理每条消息的重试节奏。熔断器处理聚合的健康决策。

为什么这对 Service Bus 特别重要

队列吸收突发流量，这很好。但没有控制的话，队列可能增长，而工作者继续在会失败的调用上浪费计算资源。有毒消息保持活跃的时间比应该的更长。热分区或有限的下游容量会造成级联问题。

更安全的设计：

检测瞬时故障
使用指数退避延迟下一次尝试
当达到失败阈值时停止调用依赖项（电路打开）
冷却期后谨慎恢复（电路探测）
将不可恢复的工作移到 dead-letter 或隔离路径

原生支持的外观

新支持与现有的 Azure Functions 主机模型集成 — 无需额外库，无需自定义实现。配置进入你的 host.json：

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

熔断器配置设置失败阈值和重置间隔，这样不健康的依赖项在恢复期间不会被轰炸。

涵盖的语言

这不仅仅是 .NET。该功能涵盖 dotnet、JavaScript、TypeScript 和 Python — Azure Functions 中 Service Bus 触发器支持的完整语言集。

总结

重试模式在配置时并不令人兴奋，直到第一次下游中断导致你的 Functions 加剧问题而不是优雅降级。主动配置这些是廉价的。在事故中进行改造则不然。

原始文章：Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

MCP Apps 迎来 Fluent API — 三步在 .NET 中构建丰富的 AI 工具界面

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

MCP 工具非常适合赋予 AI 代理各种能力。但如果你的工具需要向用户展示某些东西呢？比如仪表板、表单或交互式可视化？这就是 MCP Apps 的用武之地，而且现在构建它们变得简单多了。

Azure SDK 团队的 Lilian Kasem 发布了全新的 Fluent 配置 API，用于 .NET Azure Functions 上的 MCP Apps。这种开发者体验的改进会让你想，为什么以前不一直这么简单呢。

什么是 MCP Apps？

MCP Apps 扩展了 Model Context Protocol，让工具可以携带自己的 UI 视图、静态资源和安全控制。你的 MCP 工具不再只是返回文本，而是可以渲染完整的 HTML 体验 — 交互式仪表板、数据可视化、配置表单 — 全部可由 AI 代理调用，并通过 MCP 客户端呈现给用户。

问题在于，手动连接这一切需要深入了解 MCP 规范：ui:// URI、特殊 MIME 类型、工具和资源之间的元数据协调。不难，但很繁琐。

Fluent API 三步走

第一步：定义你的函数。 标准的 Azure Functions MCP 工具：

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

第二步：将其提升为 MCP App。 在程序启动中：

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

第三步：添加你的 HTML 视图。 创建 assets/hello-app.html，放入你需要的界面。

就这样。Fluent API 处理了所有 MCP 协议的管道工作 — 生成合成资源函数、设置正确的 MIME 类型、注入将工具与其视图连接起来的元数据。

API 设计精良

几个我特别喜欢的地方：

视图源灵活。 你可以从磁盘文件提供 HTML，也可以将资源直接嵌入程序集中以实现自包含部署：

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP 可组合。 你明确允许应用所需的来源，遵循最小权限原则。多次调用 WithCsp，来源会累积：

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

可见性控制。 你可以让工具仅对 LLM 可见、仅对宿主 UI 可见，或两者兼具。想要一个只渲染 UI 而不应被模型调用的工具？简单：

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

开始使用

添加预览包：

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

如果你已经在用 Azure Functions 构建 MCP 工具，这只是一个包更新。如果你是新手，MCP Apps 快速入门是最好的起点。

总结

MCP Apps 是 AI 工具领域最令人兴奋的发展之一 — 不仅能做事，还能向用户展示事物的工具。Fluent API 消除了协议复杂性，让你专注于真正重要的事：工具的逻辑和界面。

阅读完整文章获取完整的 API 参考和示例。

将 Azure Functions 上的 MCP 服务器连接到 Foundry 代理 — 方法在这里

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

这是我喜欢 MCP 生态系统的一点：你只需构建一次服务器，它就能在任何地方运行。VS Code、Visual Studio、Cursor、ChatGPT — 每个 MCP 客户端都能发现并使用你的工具。现在，微软正在向这个列表中添加另一个消费者：Foundry 代理。

Azure SDK 团队的 Lily Ma 发布了一份实用指南，介绍如何将部署在 Azure Functions 上的 MCP 服务器与 Microsoft Foundry 代理连接。如果你已经有了 MCP 服务器，这纯粹是增值 — 无需重新构建。

为什么这种组合有意义

Azure Functions 为托管 MCP 服务器提供了可扩展的基础设施、内置身份验证和无服务器计费。Microsoft Foundry 为你提供能够推理、规划和行动的 AI 代理。连接两者意味着你的自定义工具 — 查询数据库、调用业务 API、运行验证逻辑 — 成为企业 AI 代理可以自主发现和使用的能力。

关键点：你的 MCP 服务器保持不变。你只是将 Foundry 添加为另一个消费者。在 VS Code 设置中运行的相同工具现在为你的团队或客户交互的 AI 代理提供动力。

身份验证选项

这是文章真正增值的地方。根据你的场景提供四种身份验证方法：

方法	使用场景
基于密钥（默认）	开发或没有 Entra 身份验证的服务器
Microsoft Entra	使用托管标识的生产环境
OAuth 身份透传	每个用户单独认证的生产环境
无身份验证	开发/测试或仅公开数据

对于生产环境，使用代理身份的 Microsoft Entra 是推荐路径。OAuth 身份透传适用于用户上下文重要的场景 — 代理提示用户登录，每个请求携带用户自己的令牌。

设置方法

大致流程：

将 MCP 服务器部署到 Azure Functions — .NET、Python、TypeScript 和 Java 的示例均可用
在你的函数应用上启用内置 MCP 身份验证
获取你的端点 URL — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
在 Foundry 中添加 MCP 服务器作为工具 — 在门户中导航到你的代理，添加新的 MCP 工具，提供端点和凭据

然后在 Agent Builder 操场中发送一个会触发你某个工具的提示来测试它。

我的看法

这里的组合性故事变得非常强大。用 .NET（或 Python、TypeScript、Java）构建一次 MCP 服务器，部署到 Azure Functions，每个 MCP 兼容的客户端都能使用它 — 编码工具、聊天应用，现在还有企业 AI 代理。这是一个真正有效的"一次编写，到处使用"模式。

特别是对于 .NET 开发者，Azure Functions MCP 扩展让这一切变得简单明了。你将工具定义为 Azure Functions，部署，就拥有了一个具备 Azure Functions 所提供的所有安全性和可扩展性的生产级 MCP 服务器。

总结

如果你有在 Azure Functions 上运行的 MCP 工具，将它们连接到 Foundry 代理是一个快速的胜利 — 你的自定义工具变成了企业 AI 能力，具有适当的身份验证，且服务器本身无需代码更改。

阅读完整指南了解每种身份验证方法的分步说明，查看详细文档了解生产环境配置。