Azure | The .NET Blog

Microsoft Foundry 2026年4月：Foundry Local GA、GPT-5.5、Hyperlight上的CodeAct

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

微软Foundry迎来了繁忙的一个月。以下是最重要的公告。

Foundry Local正式发布

Foundry Local — 微软的跨平台本地AI运行时 — 在Windows、macOS（Apple Silicon）和Linux x64上从预览版升级为GA版本。具备开发者友好SDK的生产就绪本地模型推理。1.1版本增加了转录、embeddings和Responses API支持。

GPT-5.5

GPT-5系列的最新模型现已在Foundry中提供。Tier 5和Tier 6订阅的默认配额。如果您一直在使用早期的GPT-5变体，值得针对您的用例进行评估。

Foundry中的Agent Framework追踪

本月有两项追踪功能以预览形式发布：

Microsoft Agent Framework追踪 — MAF代理现在可以向Foundry发送OpenTelemetry追踪。调试代理行为，追踪多步骤执行，显示工具调用中的延迟和错误。这填补了一个真实的空白：知道代理在生产中实际做了什么，而不仅仅是它返回了什么。

托管代理追踪 — 托管代理的会话、工具调用和运行步骤也出现在Foundry追踪中。相同的可观测性能力延伸到托管层。

Hyperlight上的CodeAct（Alpha）

这是技术上最有趣的新增功能：Agent Framework现在可以在Hyperlight微型虚拟机中执行Python代码。

CodeAct是代理将Python代码作为工具生成并执行的模式。显而易见的担忧是安全性 — 您正在运行模型生成的代码。Hyperlight的微型VM以接近原生的启动时间提供进程级隔离，使沙盒代码执行变得实用，而无需完整容器或VM的开销。

对于需要代码执行的代理工作流，这是相比在宿主进程中运行代码的重大安全改进。

代理监控仪表板（预览）

统一的操作仪表板，在一个视图中结合了令牌使用情况、延迟、运行成功率和评估器分数。与常规可观测性仪表板的区别：它在操作指标旁边包含评估结果，因此您可以将"代理变慢了"与"评估器分数下降了"关联起来 — 或确认它们无关。

持续评估自定义评估器（预览）

您现在可以将自己的基于代码或提示的评估器带入持续评估管道。以前，持续评估仅限于内置评估器。自定义评估器让您在生产监控循环中执行团队特定的质量标准。

控制平面中的代理清单

Foundry控制平面的Operate视图现在显示订阅中所有受支持的代理：Foundry代理、Azure SRE Agent、Logic Apps代理循环和已注册的自定义代理。一个视图来了解部署了什么以及在哪里。

原始帖子：What’s new in Microsoft Foundry | April 2026

您的本地 MAF 代理刚刚在生产环境中找到了家

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

让代理在本地运行是有趣的部分。棘手的部分是之后的一切：不用抓狂地部署它、管理会话、设置身份、连接可观测性。通常这意味着大量自定义基础设施粘合代码。

Foundry Hosted Agents 刚刚为 Microsoft Agent Framework (MAF) 用户消除了大部分粘合代码。

Foundry Hosted Agents 实际做什么

当您将 MAF 代理部署到 Foundry Hosted Agents 时，平台会处理一个令人惊讶的长列表，这些都是您否则需要自己构建的：

缩放到零 — 代理空闲时不花费任何费用，并自动重新启动
每个会话的 VM 隔离沙箱 — 每个用户会话都有自己的沙箱，具有在缩减事件中存活的文件系统持久性
内置 Entra ID — 每个代理都获得自己的身份，可以调用 Foundry 模型、Toolbox 和 Azure 服务，而无需将密钥嵌入镜像
版本化部署 — 每个部署都是不可变的快照，支持蓝/绿和金丝雀发布
零配置可观测性 — APPLICATIONINSIGHTS_CONNECTION_STRING 在运行时注入，使 MAF 的 OpenTelemetry 跟踪自动流入 App Insights

最后一点确实很好。无需额外配置，无需额外设置。跟踪就这样出现了。

代码差异很小

这是我最欣赏这个集成的地方。您无需重写代理。只需包装它：

.NET 中：

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

Python 中：

server = ResponsesHostServer(agent)
server.run()

就这样。您在本地测试的相同逻辑就是在生产中运行的。平台用会话管理、身份和扩展基础设施来包装它。

两种协议，一个代理

Hosted Agents 支持两种端点样式：

Responses (/responses) — 兼容 OpenAI，管理会话历史和流式传输。聊天形式代理的良好默认选择。
Invocations (/invocations) — 您定义请求/响应模式。适合非对话工作流。

如果您构建的东西看起来像对话，从 Responses 开始。如果您构建的是接受结构化输入并返回结构化输出的 API 形式代理，Invocations 给您灵活性。

使用 `azd` 的部署流程

当您使用 MAF 代理运行 azd up 时：

可选地创建 Foundry 项目并部署模型
打包代码并将镜像推送到 Azure Container Registry
从 ACR 镜像供应计算
为代理分配专用 Entra ID
公开稳定端点 (https://{project_endpoint}/agents/{agent_name})
从此处理其他一切

会话持续最多 30 天。空闲计算在 15 分钟后取消供应，并在下一个请求时透明地恢复。从代理的角度来看，没有任何变化。

总结

“在本地运行"和"在生产中运行"之间的距离历来对 AI 代理来说既漫长又痛苦。Foundry Hosted Agents + MAF 显著缩小了这一差距。如果您已经有了用 Agent Framework 构建的本地代理，今天就值得一试。

团队说 GA 即将到来 — 目前处于预览阶段。查看 MAF Hosted Agent 集成文档和 .NET 示例开始使用。

原始文章: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1：实时转录、Embeddings 和 Responses API

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

Foundry Local 1.0 已证明了这一概念：通过开发者友好的 SDK 在 Windows、macOS（Apple Silicon）和 Linux x64 上本地运行 AI 模型。1.1 版本新增三项功能，涵盖了许多真实的生产用例。

实时音频转录

最重要的新功能：直接从麦克风进行实时语音转文字流式处理。字幕、语音 UI、会议转录、无障碍工具——全部在本地运行，无任何云依赖。

API 基于会话，结果一到达即流式传输，使用 is_final 标记区分中间文本和最终文本。适用于所有语言绑定：JavaScript、C#、Python 和 Rust。

从目录加载流式语音模型，使用音频设置（采样率、声道、语言）创建会话，启动它，推送原始 PCM 音频块，并消费结果的异步流。文章中有完整的 Python 和 C# 示例。

文本 Embeddings

语义搜索、RAG 管道、聚类、相似性匹配——这些都需要 embeddings。Foundry Local 1.1 新增 embedding 模型支持，让你可以直接从同一 SDK 本地生成向量，无需将数据发送到云端。

对于数据驻留地很重要或需要处理敏感内容的应用程序，本地 embedding 生成是一项有意义的功能。

Responses API

Foundry Local 现已支持 Responses API——专为代理式交互设计的结构化接口。这新增了：

工具调用——让本地运行的模型调用你定义的工具
多模态视觉-语言输入——向视觉模型传递图像 + 文本
与标准 API 格式兼容，因此针对 OpenAI Responses API 的现有 agent 可以直接对接本地模型

包大小改进

两项更改减少了 JavaScript 包大小：

koffi FFI 层已替换为自定义 Node-API C 插件
WebGPU 执行提供程序作为单独插件提供，不需要 GPU 加速的应用无需承担额外的大小开销

C# SDK 现在针对更低的框架版本，以获得更广泛的 .NET 兼容性。

为什么重要

三项功能组合——转录、embeddings、工具调用——涵盖了许多 AI 应用程序的核心构建块。在本地运行它们意味着：

无需互联网
无每令牌费用
数据不离开设备
无论网络状况如何，延迟保持一致

Foundry Local 是边缘场景、隐私敏感工作负载、离线应用程序或任何希望在开发过程中避免云依赖的场景的正确选择。

原文：Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell 现已推出公共预览版 — 并且内置了 MCP 服务器

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

如果您曾经为了回答一个关于 Cosmos DB 的问题，不得不在门户标签页、SDK 示例和半成品脚本之间来回切换，那么您已经了解这个项目旨在消除的摩擦。

Azure Cosmos DB Shell 刚刚进入公共预览版。这是一个具有类 bash 语法的开源 CLI，还有——让它变得有趣的部分——一个内置的 MCP 服务器。

与其他数据库 CLI 的不同之处

CLI 本身很有用：熟悉的命令、脚本支持、CI/CD 集成。这部分是面向开发者的数据库工具的最低要求。

有趣的部分是 MCP 服务器集成。CLI 公开的每个命令都可以作为 AI 代理可以调用的 MCP 工具。没有自定义 API 层，没有需要编写的集成代码。您的代理可以：

使用 cd、ls、pwd 导航数据库层次结构
使用 query 执行 SQL 查询并获取结构化结果
使用 create item、update、rm 创建和修改项目
使用 mkdb、mkcon、rmdb、rmcon 管理数据库和容器
使用 endpoint、pwd 检查当前上下文

关键变化：您的代理不是在与 Cosmos DB API 交互——而是在与您使用的相同 shell 界面交互。命令是确定性的、可审计的，并且是开源的，因此您可以检查确切发生了什么。

开源基础很重要

这不是一个黑箱托管服务。Shell 是开源的，这意味着：

安全团队可以审计实现
平台团队可以 fork 并根据其特定标准进行扩展
开发者可以贡献对所有人有益的改进

对于采用 AI 工具的企业团队来说，“我们能确切看到它是如何工作的吗"越来越不是可选要求。这里的开源是一个重要的差异化因素。

三个变得更容易的场景

智能数据分析 — 将代理连接到 shell，用自然语言提问，获取结构化查询结果。代理处理查询构建；shell 处理执行。

自主数据管理 — 需要在 Cosmos DB 中创建、更新或删除数据的工作流可以通过 MCP 工具完成，无需自定义集成。

实时监控和警报 — 代理可以定期查询容器，比较结果，并通过任何有意义的通知渠道报告异常。

MCP 接口使这些场景可以与任何支持 MCP 的 AI 平台组合——不仅仅是微软的工具。

入门

Shell 处于公共预览阶段。安装它，配置您的 Cosmos DB 连接，并启用 MCP 服务器。从那里，任何 MCP 兼容的代理宿主都可以发现并使用这些工具。

原始文章：Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

您的 AI 代理有一个身份问题（这是解决它的模板）

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

在每个 AI 代理项目中都有这样一个时刻：演示完美运行，代理解释自然语言，调用正确的 API，返回正确的数据。然后你开始思考真实用户。

什么能阻止一个用户的代理会话看到另一个用户的数据？如果代理通过提示注入被欺骗会怎样？如果它以意外的方式调用工具会怎样？

这些不是边缘情况。这些是你需要在发布之前做出的设计决策。

Curity 和 Microsoft 的新 azd 模板为您提供了针对这个问题的可工作参考。

核心问题：身份验证 ≠ 授权

大多数代理示例都很好地处理了用户身份验证。它们对授权处理得很差。知道用户是谁并不能告诉你他们应该看到什么数据。

传统客户端应用程序进行可预测的 API 调用。AI 代理是不确定性的——它解释自然语言并决定调用什么。它可以很有创意。它也可能出错。如果通过提示注入被操纵，你需要不依赖于 AI 良好行为的规则。

这个模板演示的解决方案：为每一跳携带正确信息的短期令牌。

令牌链如何工作

该模板使用带有令牌交换的 OAuth 2.0 访问令牌，在每个步骤缩小权限。用户令牌在到达 MCP 服务器之前会被交换两次：

第一次交换 — 缩小作用域并将不透明令牌转换为 JWT
第二次交换 — 添加代理身份和 MCP 服务器跳的新受众

MCP 服务器令牌的样子：

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id 由授权服务器嵌入令牌中，而不是作为代理控制的参数传递。API 检查令牌，而不是代理的指令。

这意味着：即使有人欺骗代理尝试获取另一个客户的数据，令牌也不会授权它。

模板部署什么

用几个 azd 命令，您将获得：

Microsoft Foundry 上的后端代理（C#、Microsoft A2A 和 MCP SDK）
公开示例投资组合 API 的 MCP 服务器
Curity Identity Server 作为授权服务器，以及用于身份验证的 Entra ID
处理令牌交换和审计日志的外部和内部 API 网关
所有 Azure 基础设施的 Bicep：Container Apps、VNet、ACR、Azure AI Foundry、Key Vault、Azure SQL Database、存储

整个模式是可检查和可定制的。

值得借鉴的设计原则

即使您不使用 Curity，该模式也是可转移的：代理永远不应该拥有永久 API 访问权限。每个操作都应使用仅具有该特定调用所需最小作用域的短期令牌，为特定代理身份颁发，携带 API 进行授权决策所需的声明。

这能抵御创意代理、错误和提示注入，而"只要确保代理不做坏事"永远做不到这一点。

总结

AI 代理的安全模式在整个行业中仍在研究中。这个模板是我见过的最完整的参考实现之一——它涵盖了实际的授权流程，而不仅仅是身份验证。

原始文章：Least privilege AI agents: A new azd template from Curity and Microsoft

私有端点、VNet、NSG — Aspire 现在接管网络管理

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

我见过这个场景太多次了。应用程序已经完成。演示很棒。然后安全清单出现了：将存储从公共互联网移除、在 VNet 内运行、为合作伙伴允许列表提供出站 IP、证明只有正确的子网与正确的服务通信。

此时应用程序模型和基础设施模型开始以令人痛苦的方式分离。

Aspire 新的 Azure 企业网络支持直接解决了这个问题。你在 AppHost 中将网络形态描述在使用它的资源旁边。

构建块

每个 Azure 网络概念的用途，提炼如下：

功能	使用时机	为何重要
虚拟网络	需要私有地址空间时	子网、私有端点和路由的网络边界
子网	需要在 VNet 内分离工作负载时	系统的每个部分获得自己的地址范围和策略面
委托子网	平台服务（如 ACA）需要管理子网时	允许服务安全地在 VNet 中放置受管基础设施
NAT 网关	需要可预测的出站公共 IP 时	用于允许列表和审计的稳定地址
私有端点	希望 PaaS 资源可私密访问时	在 VNet 内放置该服务的私有 IP，消除公共暴露
NSG	需要子网级流量规则时	每个子网的入站和出站流量显式允许/拒绝

在 AppHost 中描述它

这里的关键转变是你将网络与使用它的资源一起建模，而不是在随时间与应用模型产生偏离的单独 Bicep 文件中。

从 AppHost，你可以：

使用 AddVirtualNetwork() 和 AddSubnet() 创建 VNet 和子网
为子网附加 NAT 网关以获得稳定的出站 IP
为存储、Key Vault、SQL 和其他 PaaS 服务创建私有端点
使用入站和出站安全规则定义 NSG
配置网络安全边界以实现跨资源策略

结果是当你运行 azd up 时，基础设施与应用模型所说需要的内容相匹配。而不是手动维护的模板所说的。

为何对实际应用程序重要

一旦在 Aspire 中建模了网络，一些事情就会变得容易很多：

Key Vault 和存储的私有端点 — 你在这些资源上描述 WithPrivateEndpoint()，Aspire 处理 DNS 区域配置和端点附加。应用程序永远不会改变。

一致的出站 IP — 向相关子网添加 NAT 网关，应用程序的每个出站请求都通过一个已知的稳定 IP。合作伙伴可以将其加入允许列表。审计人员可以追踪它。

代码中的 NSG 规则 — 不再需要在门户中点击或维护 Bicep 代码段，你的安全规则与它们保护的资源一起存在于 AppHost 中。

这是不会让演示令人兴奋但会让生产系统可维护的集成类型。

总结

如果从一开始就与应用程序一起建模，网络安全在项目生命周期后期出现是一个已解决的问题。Aspire 的企业网络支持使这成为可能，而无需单独的基础设施轨道。

完整详情请参阅原始文章：Securing Azure apps with Aspire enterprise networking

Aspire 13.3：Kubernetes 支持、浏览器日志和 Aspireify 技能

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

五周对于一个版本来说并不长，但 Aspire 13.3 让人感觉不是这样。主要内容非常重要：使用 Helm 进行 Kubernetes 和 AKS 一流部署、名为 Aspireify 的代理辅助入门技能、直接在仪表板中捕获浏览器日志，以及结构化命令结果。还包括 45 项新功能、134 项改进和 93 个错误修复。

让我们来看看亮点。

Aspireify：代理辅助入门

将 Aspire 添加到现有项目听起来很简单——添加 AppHost，完成。实际上需要大量研究：哪些端口重要、哪些环境变量是真正的依赖项、哪些 Docker Compose 服务应该映射到 Aspire 集成。

新的 Aspireify 技能 正是为此为您的编码代理提供了引导工作流程。当 aspire init 创建骨架 AppHost 时，Aspireify 技能会帮助代理检查存储库、了解其已有的工作方式，并连接 AppHost 以适应应用程序——而不是反过来。

默认立场是"最小化对代码的更改"。如果您的应用程序已经读取 DATABASE_URL，代理会使用 WithEnvironment() 进行映射，而不是要求您重写配置。如果端口是硬编码的，该技能会告诉代理何时保留它。

这正是那种能真正节省时间而不是生成更多审查工作的 AI 工具。

一流的 Kubernetes 和 AKS 部署

这在愿望清单上已经有一段时间了。Aspire 13.3 提供了使用 Helm 的 Kubernetes 和 AKS 一流部署支持。您现在可以直接从 Aspire 工具中将 AKS 指定为部署目标。

对于已经在 AKS 上运行生产工作负载的团队，这弥补了一个重要缺口。您的 Aspire 应用模型现在有了从本地开发到 Kubernetes 的清晰路径，无需手动编写 Helm 图表。

仪表板中的浏览器日志

这是那些在调试前端问题之前看起来很小的功能之一。

新的 WithBrowserLogs() API 将跟踪的浏览器资源附加到任何支持端点的资源。Aspire 使用私有 CDP 管道启动 Chromium，并将控制台日志、网络请求和错误直接流式传输到资源的日志流中：

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost 同样支持：

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

控制台错误、失败的网络请求、客户端异常——所有这些都在您已经观察追踪和指标的同一仪表板中可见。不再需要为了基础内容切换到浏览器 DevTools。

结构化命令结果

资源命令获得了重大升级。到目前为止，命令返回成功/失败。现在它们返回结构化结果：流经模型、仪表板 UI、CLI 和 MCP 工具的文本、JSON 或 Markdown。

仪表板通过标题中的新通知中心将这一切联系在一起。命令结果以带时间戳的通知形式出现，带有 Markdown 渲染和"查看响应"操作。

这使资源命令真正可组合。集成现在可以公开一个返回有意义输出的命令——比如隧道 URL——而不仅仅是在某处更改状态。

结论

Aspire 13.3 仅凭 Kubernetes 支持就值得升级。浏览器日志和结构化命令结果感觉像是那种在日常开发工作流程中快速积累的生活质量改进。

完整发布说明：What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 于 2026年5月11日至15日 在 伦敦 Barbican Centre 举办。为期3天的核心大会从周二到周四，周一和周五有可选的全天工作坊。

拥有 78场演讲 和 14场工作坊，是欧洲内容最丰富的开发者大会之一。

主题

架构思维
C# 13 中的函数式代码
无服务器设计
语义 AI
Azure Kubernetes Services
精益 DevOps 策略
模型上下文协议 (MCP)
.NET 中的智能代理 AI
重构单体应用
使用 LLM 更快编程
后量子世界中的密码学
本地优先开发

演讲者

世界级阵容包括 Kevlin Henney、Neal Ford、Sander Hoogendoorn、Andrew Clymer、Jacqui Read、Christian Weyer、Jeff Prosise、Jules May、Oliver Sturm 和 Raju Gandhi。

门票和信息

98%的 SDD 2025 参会者将整体体验评为"好"、“非常好"或"优秀”。

SQL MCP Server 在 Azure App Service 上运行 — 无需容器

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处。

老实说：每次在教程中看到"需要容器"，我内心都会叹一口气。容器很棒——直到你的团队没有容器策略，一个看似简单的功能突然被意料之外的编排复杂性阻挡。

这就是为什么这个让我眼前一亮。SQL MCP Server 现在可以在 Azure App Service 上运行——无需 Docker，无需 Kubernetes，只需相同的 Data API Builder（DAB）配置文件，通过 MCP、REST 和 GraphQL 公开你的 SQL 数据库。

什么是 SQL MCP Server？

如果你还不了解，简单介绍一下。SQL MCP Server 位于你的 AI 代理和 SQL 数据库之间。它不是让代理直接访问数据库（这是个糟糕的想法），而是将你的表和视图作为带有定义权限的实体抽象层公开。

它构建在 Data API Builder 之上，这意味着单个配置文件同时管理 MCP、REST 和 GraphQL。你的代理与 MCP 端点通信，传统应用与 REST 或 GraphQL 通信。相同的配置，相同的运行时，不同的接口。

这真的很有用——你不需要维护两个独立的 API 层。

容器问题（及解决方案）

SQL MCP Server 最初的部署模型是容器。这在很多团队中运行良好，但并非所有团队都适用。许多 .NET 团队标准化使用 Azure App Service 或虚拟机。仅仅为了公开 SQL 端点而需要容器运行时，增加了没有人要求的摩擦。

新的教程展示了如何完全跳过容器。一切都通过 dab start 命令运行，作为标准的 .NET 8 Web 进程托管在 App Service 上。

# 安装 Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# 初始化配置
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# 添加实体
dab add products --source dbo.products --permissions "authenticated:*"

# 配置 App Service 认证提供程序
dab configure --runtime.host.authentication.provider AppService

# 启动服务器
dab start

此时，你在 /mcp 有 MCP，同一进程提供 REST 和 GraphQL，没有任何东西运行在容器中。

无需共享 API 密钥的身份验证

这是我最欣赏的部分。部署到 App Service 时，你将 Microsoft Entra ID 配置为身份验证提供程序。配置文件中没有共享密钥，不需要轮换 API 密钥。

连接字符串保留在 App Service 环境变量中（不在 dab-config.json 中），MCP 端点通过平台身份验证保护。如果你的 Azure 工作负载已经与 Entra ID 对齐，这将自然融入。

本地开发时，切换到 Simulator 模式和 STDIO 传输。部署前切换回 AppService 模式。干净且明确。

部署到 App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

然后使用你的团队已经使用的代码部署方法部署你的 DAB 项目。关键细节：这是代码部署，不是容器部署。

为什么这对 .NET 开发者很重要

如果你在 .NET 中构建 AI 代理，你的代理最终需要与数据库通信。SQL MCP Server 提供了一种结构化的方式来实现这一点，无需暴露原始连接字符串。

查看原始博客文章和 GitHub 示例仓库的完整教程。

总结

App Service 上的 SQL MCP Server 是 .NET 团队的实用选择，无需容器策略即可为代理提供结构化的 SQL 数据访问。试试看——你的代理会很感激清晰的 API 接口。

用 Agentic Platform Engineering 消除迁移的重复性工作

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处.

Removing the Monkey Work of Migration with Agentic Platform Engineering — Git-Ape（git 智能体平台工程工具）将真实的 AWS Terraform 仓库迁移到 Azure 的演练，专注于提取部署意图而非逐行转换。

输入：contoso-migration

源项目是一个真实的 Terraform 项目（contoso-migration），在 AWS 上部署 Next.js 应用——EC2 用于计算，ALB 用于负载均衡，S3 用于制品，IAM 密钥用于身份认证。成本：约 34 美元/月。目标不是在 Azure 上复现相同的基础设施；而是弄清楚这个部署实际上要做什么，然后用 Azure 原生服务重新构建它。

步骤 1：验证与认证

Git-Ape 首先验证所有必需的 CLI 工具——az、aws、gh、jq、git——并在进行任何操作之前确认活跃的认证会话。不做部分运行。

步骤 2：意图提取

智能体通过 GitHub API 读取整个源仓库，并提取部署意图：运行时（Node.js）、计算类型、入口模式、制品处理、身份模型、网络和监控。这是关键步骤——它构建了一个关于部署做什么的语义模型，而不是它使用了哪些 Terraform 关键字。

步骤 3：服务映射

AWS 服务映射到 Azure 等效服务：

EC2 → App Service（Linux，Node 20 LTS）
ALB → App Service 内置负载均衡
IAM 角色/密钥 → Managed Identity
Terraform → Bicep + GitHub Actions

步骤 4：评审智能体

在生成输出之前，评审智能体运行并发现两个阻塞问题：

启动时构建反模式 — 原始 Terraform 在 EC2 启动时运行 npm install && npm run build。修复：在 CI 中构建，部署已就绪的制品。
不必要的 Blob Storage — S3 用于制品暂存，通过适当的 CI/CD 可以完全省去。评审智能体将其彻底删除。

步骤 5：生成的输出

结果是约 80 行 Bicep，而不是原来的 200 多行 Terraform。智能体创建了一个新的 GitHub 仓库，包含 infra/main.bicep 和 .github/workflows/deploy.yml，并删除了所有 AWS 特定文件。

安全态势对比

迁移还带来了显著的安全升级：

AWS 原始	Azure 输出
仅 HTTP	仅 HTTPS，TLS 1.2
SSH 对 0.0.0.0/0 开放	无 SSH 暴露
IAM 访问密钥	OIDC + Managed Identity
无监控	Application Insights

成本：约 13 美元/月，而原来是 34 美元/月。

与语法转换器的区别

评审智能体步骤是将其与机械翻译区分开来的关键。它发现了在 AWS 上可行但在 Azure 上会出错的模式——并修复了它们而不是复制它们。输出不是"Azure 语法的 AWS"；而是以更简洁方式实现同一目标的 Azure 原生部署。

请查看完整演练以获取完整的智能体追踪和生成的文件。

SQL Server 2025作为代理就绪数据库：一个引擎中的安全、备份和MCP

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击这里。

我一直饶有兴趣地关注Aditya Badramraju的Polyglot Tax系列。第4部分用实际决定你是否会在生产环境中信任这种架构的部分来结束系列。

所有数据模型的单一安全模型

一个行级安全策略覆盖所有数据模型。对审计员来说，一个策略，一个证明。

统一备份 = 原子恢复

在多语言堆栈中，跨五个数据库的时间点恢复是一场一致性噩梦。只有一个数据库时，恢复在定义上就是原子的。

MCP集成：无需手动编写中间件

SQL Server 2025直接支持SQL MCP服务器。代理调用工具，引擎自动强制租户隔离和列掩码。

原始文章（Aditya Badramraju著）：The Polyglot Tax – Part 4。

Azure MCP Server 现在是 .mcpb — 无需任何运行时即可安装

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

本文已自动翻译。如需查看原文，请点击此处。

你知道配置 MCP 服务器有什么烦人的地方吗？需要运行时。npm 版需要 Node.js，pip/uvx 需要 Python，dotnet 版需要 .NET SDK。

Azure MCP Server 刚刚改变了这一切。它现在作为 .mcpb — MCP Bundle — 提供，配置方式是拖放。

什么是 MCP Bundle？

把它想象成 VS Code 扩展（.vsix）或浏览器扩展（.crx），但用于 MCP 服务器。.mcpb 文件是一个独立的 ZIP 存档，包含服务器二进制文件及其所有依赖项。

如何安装

1. 为你的平台下载 Bundle

前往 GitHub Releases 页面，下载适合你 OS 和架构的 .mcpb 文件。

2. 在 Claude Desktop 中安装

最简单的方式：在扩展设置页面（☰ → 文件 → 设置 → 扩展）打开时，将 .mcpb 文件拖放到 Claude Desktop 窗口中。查看服务器详情，点击安装，确认。完成。

3. 向 Azure 进行身份验证

az login

就这样。Azure MCP Server 使用你现有的 Azure 凭据。

能做什么

直接从 AI 客户端访问 100 多个 Azure 服务工具：

查询和管理 Cosmos DB、Storage、Key Vault、App Service、Foundry
为任何任务生成 az CLI 命令
创建 Bicep 和 Terraform 模板

开始使用

查看完整文章。

Azure SDK 2026年4月：AI Foundry 2.0及.NET开发者须知

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击这里。

月度SDK发布通常容易被忽略。这次有几件事值得关注——特别是如果你在使用AI Foundry、Java版Cosmos DB或从.NET代码进行基础设施配置。

Azure.AI.Projects 2.0.0 — 有意义的破坏性变更

命名空间拆分、类型重命名、布尔属性统一使用Is*命名规则。

Cosmos DB Java：关键安全修复（RCE）

4.79.0版本修复了远程代码执行漏洞（CWE-502）。立即更新。

.NET的新Provisioning库

原始文章：Azure SDK Release (April 2026)。

GPT-5.5 已来到 Azure Foundry — .NET 开发者需要了解的一切

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

本文已自动翻译。如需查看原文，请点击此处。

微软刚刚宣布 GPT-5.5 在 Microsoft Foundry 正式发布。如果你一直在 Azure 上构建 Agent，这就是你一直等待的更新。

GPT-5 的演进

GPT-5：将推理与速度统一到单一系统中
GPT-5.4：更强的多步推理，面向企业的早期 Agent 能力
GPT-5.5：更深入的长上下文推理，更可靠的 Agent 执行，更好的 Token 效率

真正发生了什么变化

Agent 编码改进：GPT-5.5 在大型代码库中保持上下文，诊断架构级故障，并预测测试需求。模型在行动前推理修复还会影响什么。

Token 效率：更少的 Token 和更少的重试产生更高质量的输出。生产部署的成本和延迟直接降低。

长上下文分析：处理大量文档和多会话历史记录而不失去线索。

定价

模型	输入 ($/M tokens)	缓存输入	输出 ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

为什么 Foundry 很重要

Foundry Agent Service 允许你在 YAML 中定义 Agent，或与 Microsoft Agent Framework、GitHub Copilot SDK、LangGraph 或 OpenAI Agents SDK 连接——并将它们作为具有持久文件系统、独立 Microsoft Entra 身份和零扩展定价的隔离托管 Agent 运行。

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "你是一个有用的助手。", name: "我的Agent");

查看完整公告了解所有详情。

Foundry Toolboxes：AI Agent工具的统一端点

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

本文已自动翻译。如需查看原始版本，请点击此处。

有一个问题听起来无聊，直到你真正遇到它：你的组织在构建多个AI Agent，每个都需要工具，每个团队都从头开始配置。相同的Web搜索集成、相同的Azure AI Search配置、相同的GitHub MCP服务器连接——但在不同的仓库里，由不同的团队，使用不同的凭据，没有任何共享治理。

Microsoft Foundry刚刚以公开预览版发布了Toolboxes，这是对该问题的直接回应。

什么是Toolbox

Toolbox是一个有命名的、可复用的工具包，在Foundry中定义一次，通过单一MCP兼容端点公开。任何能够使用MCP的Agent运行时都可以消费它——不受限于Foundry Agents。

承诺很简单：build once, consume anywhere。定义工具，集中配置身份验证（OAuth直通、Entra托管标识），发布端点。需要这些工具的每个Agent连接到端点即可获取全部工具。

四个支柱（今天两个可用）

支柱	状态	功能
Discover	即将推出	无需手动搜索即可发现已批准的工具
Build	现已可用	将工具整合到可复用包中
Consume	现已可用	单一MCP端点公开所有工具
Govern	即将推出	集中身份验证+所有工具调用的可观测性

实践示例

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="搜索文档并回应GitHub issues",
 tools=[
 {"type": "web_search", "description": "搜索公开文档"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

发布后，Foundry提供统一端点。一次连接，获取所有工具。

不受限于Foundry Agents

Toolboxes在Foundry中创建和管理，但消费面是开放的MCP协议。可以从使用Microsoft Agent Framework或LangGraph的自定义Agent、GitHub Copilot和其他MCP兼容IDE以及任何支持MCP的运行时中使用它们。

为什么现在重要

多Agent浪潮正在进入生产环境。每个新Agent都是重复配置、过期凭据和不一致行为的新风险面。Build + Consume基础足以开始集中化。当Govern支柱推出时，你将拥有对整个Agent群完全可观测、集中控制的工具层。

总结

还是早期阶段——公开预览，Python SDK优先，Discover和Govern仍在路上。但模型是稳固的，MCP原生设计意味着它可以与你已经在构建的工具配合使用。查阅官方公告了解详情。

azd + GitHub Copilot：AI 驱动的项目设置和智能错误修复

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

你是否有过这样的经历：想把现有应用部署到 Azure，却盯着空白的 azure.yaml 发呆，想不起来 Express API 到底该用 Container Apps 还是 App Service？这种时刻即将成为历史。

Azure Developer CLI（azd）现已与 GitHub Copilot 以两种实用的方式集成：azd init 时的 AI 辅助项目脚手架，以及部署失败时的智能错误排查。两项功能都完全在终端内运行——正是我想要的方式。

在 azd init 中使用 Copilot 设置

运行 azd init 时，现在会出现"Set up with GitHub Copilot (Preview)“选项。选择它，Copilot 会分析你的代码库，根据实际代码生成 azure.yaml、基础架构模板和 Bicep 模块。

azd init
# 选择："Set up with GitHub Copilot (Preview)"

前提条件：

azd 1.23.11 或更高版本 — 用 azd version 检查，或用 azd update 更新
有效的 GitHub Copilot 订阅（Individual、Business 或 Enterprise）
GitHub CLI（gh） — 必要时 azd 会提示登录

我觉得真正实用的是它能双向工作。从零开始构建？Copilot 从一开始就帮你配置正确的 Azure 服务。有现有应用想部署？把 Copilot 指向它，无需重构代码即可生成配置。

它实际做什么

假设你有一个 Node.js Express API，依赖 PostgreSQL。不必手动在 Container Apps 和 App Service 之间抉择，也不必从零编写 Bicep，Copilot 检测到你的技术栈后会生成：

包含正确 language、host 和 build 设置的 azure.yaml
Azure Container Apps 的 Bicep 模块
Azure Database for PostgreSQL 的 Bicep 模块

并在做任何更改前运行预检——验证 git 工作目录是否干净，提前请求 MCP 服务器工具的授权。一切都在你知情的情况下进行。

Copilot 驱动的错误排查

部署错误无可避免。缺少参数、权限问题、SKU 可用性问题——而错误信息很少告诉你真正需要知道的那一件事：如何修复。

没有 Copilot 时的循环：复制错误 → 搜索文档 → 读三篇不相关的 Stack Overflow 回答 → 运行一些 az CLI 命令 → 重试并祈祷。有了集成在 azd 中的 Copilot，这个循环消失了。任何 azd 命令失败时，它会立即提供四个选项：

Explain — 用通俗语言解释出了什么问题
Guidance — 逐步修复指导
Diagnose and Guide — 完整分析 + Copilot 应用修复（经你批准）+ 可选重试
Skip — 自己处理

关键在于：Copilot 已经了解你的项目、失败的命令和错误详情。它的建议针对你的具体情况，而非泛泛的文档。

设置默认行为

如果你总是选择同一个选项，可以跳过交互式提示：

azd config set copilot.errorHandling.category troubleshoot

可选值：explain、guidance、troubleshoot、fix、skip。还可以启用自动修复和重试：

azd config set copilot.errorHandling.fix allow

随时重置为交互模式：

azd config unset copilot.errorHandling.category

总结

这正是真正有价值的 Copilot 集成。运行 azd update 获取最新版本，在下一个项目中试试 azd init。

阅读原文公告。

Foundry的RFT更便宜、更智能了 — 看看有什么变化

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

如果你正在开发依赖微调模型的.NET应用，这个月的Foundry更新值得关注。Reinforcement Fine-Tuning变得更易获取，价格也大幅降低。

完整详情请参阅官方公告，这里是实用要点总结。

o4-mini的全球训练

o4-mini是推理密集型和智能体工作负载的首选模型。重大消息：你现在可以从13+个Azure区域启动微调任务，与Standard训练相比，每token的训练费率更低。相同的基础设施，相同的质量，更广的覆盖范围。

如果你的团队分布在不同地区，这很重要。你不再局限于少数几个区域来进行训练。

以下是启动全球训练任务的REST API调用：

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

那个trainingType: globalstandard标志就是关键区别。

新模型评分器：GPT-4.1系列

评分器定义了模型优化所针对的奖励信号。此前，基于模型的评分器仅限于较少的模型集合。现在你有三个新选项：GPT-4.1、GPT-4.1-mini和GPT-4.1-nano。

什么时候应该使用模型评分器而不是确定性评分器？当你的任务输出是开放式的，当你需要在多个维度上进行部分评分，或者当你在构建智能体工作流且工具调用的正确性取决于语义上下文时。

关键在于，分层策略很实用：

GPT-4.1-nano 用于初始迭代。低成本，快速反馈循环。
GPT-4.1-mini 当你的评分标准稳定并需要更高保真度时使用。
GPT-4.1 用于生产环境评分或每个评分决策都至关重要的复杂标准。

你甚至可以在单个RFT任务中混合使用评分器类型。用string-match来评判"正确答案"维度，用模型评分器来评估推理质量。说实话，这种灵活性才是它对实际工作负载真正有用的地方。

RFT数据格式的陷阱

这是很多人会踩的坑。RFT的数据格式与SFT不同。每行的最后一条消息必须是User或Developer角色——不是Assistant。期望的答案放在顶层键中，如reference_answer，评分器会直接引用它。

如果你之前一直在做监督微调并想切换到RFT，你需要重新组织训练数据。不要跳过这一步，否则你的任务会静默失败。

为什么这对.NET开发者很重要

如果你通过Azure OpenAI SDK从.NET应用中调用微调模型，更便宜的训练意味着你可以更积极地迭代。模型评分器选项意味着你可以针对细微的任务进行微调——不仅仅是精确匹配场景。GitHub上的最佳实践指南将为你节省真正的调试时间。

从小处开始。十到一百个样本。简单的评分器。验证循环。然后扩展。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 于 2026年4月18日 在马德里 Alcobendas 的 Kinépolis Diversia 举办。这是西班牙最大的社区驱动 Azure 活动，38位演讲者在3个平行分场分享 AI 代理、Azure 网络、Cosmos DB、Fabric、IoT、安全等主题。

活动时间为 08:30 至 18:30，包括主题演讲、茶歇、午餐和闭幕问答环节。

议程亮点

Domando Agentes de IA：使用 Azure AI Foundry 和 Azure API Management 的治理、工具和 API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!：多代理系统实战
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

门票

注册为象征性捐赠 — 门票全部收入直接捐赠给 Plan International，支持全球儿童权利和平等。名额有限，请尽早报名。

Azure Tour 2026

除马德里外，Global Azure Tour 2026 还将在 萨拉戈萨、特内里费 和 塞维利亚 举办。

你在Azure上的AI实验正在烧钱——这样解决

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

如果你现在正在Azure上构建AI驱动的应用，你可能已经注意到一件事：你的云账单看起来和以前不一样了。不只是更高了——更奇怪了。波动很大，难以预测。

Microsoft刚刚发布了一篇关于仍然重要的云成本优化原则的优秀文章，说实话，时机再好不过了。因为AI工作负载在成本方面已经改变了游戏规则。

为什么AI工作负载不一样

事情是这样的。传统的.NET工作负载相对可预测。你了解你的App Service层级，了解你的SQL DTU，可以相当准确地估算每月开支。AI工作负载呢？完全不是这么回事。

你在测试多个模型看哪个合适。你在启动GPU支持的基础设施进行微调。你在调用Azure OpenAI的API，而token消耗量会因prompt长度和用户行为的不同而产生巨大差异。每个实验都要花真金白银，你可能需要运行几十次才能找到正确的方法。

这种不可预测性正是成本优化至关重要的原因——不是事后才想到，而是从第一天开始。

管理与优化——了解区别

文章中有一个我认为开发者容易忽视的区别：成本管理和成本优化是不同的。

管理是跟踪和报告。你在Azure Cost Management中设置预算，收到警报，查看仪表板。这是基本功。

优化是你真正做决策的地方。你真的需要S3层级，还是S1就能处理你的负载？那个始终运行的计算实例周末是不是闲着？你能否用竞价实例来跑训练任务？

作为.NET开发者，我们往往专注于代码，把基础设施决策留给"运维团队"。但如果你在Azure上部署，这些决策也是你的决策。

真正有效的方法

根据这篇文章和我自己的经验，以下是真正能产生效果的做法：

了解你在花什么钱、花在哪里。 给你的资源打标签。我是认真的。如果你无法分辨哪个项目或实验在消耗你的预算，你就无法优化任何东西。配合适当标签的Azure Cost Management是你最好的朋友。

实验之前设好护栏。 使用Azure Policy限制dev/test环境中昂贵的SKU。为你的Azure OpenAI部署设置消费上限。不要等到账单到了才发现有人让GPU集群在周末一直运行。

持续进行合理配置。 原型阶段选的那个VM？可能不适合生产环境。Azure Advisor会给你建议——真的去看看。每月审查，而不是每年。

考虑生命周期。 开发资源应该关闭。测试环境不需要7×24小时运行。使用自动关机策略。特别是对于AI工作负载，考虑使用按执行付费的无服务器选项，而不是让计算资源一直保持运行。

衡量价值，而不仅仅是成本。 这一点容易忘记。一个成本更高但能产出显著更好结果的模型可能才是正确的选择。目标不是花最少的钱——而是花得聪明。

总结

云成本优化不是一次性的清理工作。它是一个习惯。随着AI工作负载让开支比以往任何时候都更难预测，尽早养成这个习惯可以帮你避免日后的痛苦惊喜。

如果你是一名在Azure上构建的.NET开发者，开始像对待代码一样对待你的云账单吧——定期审查，混乱时重构，永远不要在不了解成本的情况下部署。

Azure MCP 工具现已内置于 Visual Studio 2022 — 无需安装扩展

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

如果你一直通过单独的扩展在 Visual Studio 中使用 Azure MCP 工具，那你一定很熟悉这套流程——安装 VSIX、重启、祈祷别出问题、处理版本不匹配。这种摩擦现在消失了。

Yun Jung Choi 宣布，Azure MCP 工具现在直接作为 Visual Studio 2022 中 Azure 开发工作负载的一部分发布。无需扩展，无需 VSIX，无需重启。

这实际意味着什么

从 Visual Studio 2022 版本 17.14.30 开始，Azure MCP Server 捆绑在 Azure 开发工作负载中。如果你已经安装了该工作负载，只需在 GitHub Copilot Chat 中启用它即可。

超过 230 个工具，覆盖 45 项 Azure 服务——直接从聊天窗口即可访问。列出你的存储账户、部署 ASP.NET Core 应用、诊断 App Service 问题、查询 Log Analytics——全程无需打开浏览器标签页。

为什么这比听起来更重要

开发工具有个道理：每多一个步骤就是摩擦，摩擦会扼杀采用率。MCP 作为单独的扩展意味着版本不匹配、安装失败，以及又多了一个需要保持更新的东西。将它内置到工作负载中意味着：

单一的更新路径——通过 Visual Studio Installer
无版本偏差——扩展和 IDE 之间不会出现版本不一致
始终保持最新——MCP Server 随 VS 常规发布一起更新

对于标准化使用 Azure 的团队来说，这意义重大。安装一次工作负载，启用工具，每次会话都能使用。

你能用它做什么

这些工具通过 Copilot Chat 覆盖完整的开发生命周期：

学习——询问 Azure 服务、最佳实践、架构模式
设计与开发——获取服务推荐，配置应用代码
部署——预配资源并直接从 IDE 进行部署
排查问题——查询日志、检查资源健康状况、诊断生产环境问题

一个简单的例子——在 Copilot Chat 中输入：

List my storage accounts in my current subscription.

Copilot 在后台调用 Azure MCP 工具，查询你的订阅，返回一个包含名称、位置和 SKU 的格式化列表。无需打开门户。

如何启用

更新到 Visual Studio 2022 17.14.30 或更高版本
确保已安装 Azure development 工作负载
打开 GitHub Copilot Chat
点击 Select tools 按钮（双扳手图标）
开启 Azure MCP Server

就这样。跨会话保持启用状态。

一个注意事项

这些工具默认是禁用的——你需要手动启用。而且 VS 2026 特有的工具在 VS 2022 中不可用。工具的可用性还取决于你的 Azure 订阅权限，与门户中一样。

更大的图景

这是一个清晰趋势的一部分：MCP 正在成为在开发者 IDE 中呈现云工具的标准方式。我们已经看到了 Azure MCP Server 2.0 稳定版发布以及在 VS Code 和其他编辑器中的 MCP 集成。将其内置到 Visual Studio 的工作负载系统中是自然而然的演进。

对于我们这些常年在 Visual Studio 中工作的 .NET 开发者来说，这又少了一个需要切换到 Azure 门户的理由。说实话，标签页切换越少越好。

Aspire 13.2 新增 MongoDB EF Core 和 Azure Data Lake — 两个值得尝试的集成

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 刚刚发布，带来了两个新的数据库集成，值得关注：MongoDB Entity Framework Core 和 Azure Data Lake Storage。如果你一直想在 Aspire 应用中使用 EF Core 操作 MongoDB，或者需要将 Data Lake 工作负载与服务发现连接起来，这个版本同时满足了这两个需求。

MongoDB 在 Aspire 中遇见 EF Core

这是让我最兴奋的一个。Aspire 支持 MongoDB 已经有一段时间了，但一直是原始驱动程序——没有 EF Core，没有 DbContext，没有对文档的 LINQ 查询。现在你可以获得完整的 EF Core 体验配合 MongoDB，加上 Aspire 的自动健康检查和服务发现。

配置遵循典型的 Aspire 模式。在你的 AppHost 中：

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

然后在消费项目中，添加 EF Core 集成：

dotnet add package Aspire.MongoDB.EntityFrameworkCore

注册你的 DbContext：

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

接下来就是标准的 EF Core 了。定义你的实体，像使用其他任何提供程序一样使用 DbContext。集成会在后台处理连接池、OpenTelemetry 跟踪和健康检查。

对于那些一直使用原始驱动程序操作 MongoDB 并手动配置连接字符串的 .NET 开发者来说，这是一个很好的体验提升。你可以获得完整的 EF Core 抽象，同时不会失去 Aspire 的服务发现。

Azure Data Lake Storage 加入阵营

第二个重大新增是 Azure Data Lake Storage (ADLS) 集成。如果你正在构建数据管道、ETL 流程或分析平台，现在可以像连接其他 Aspire 依赖项一样连接 Data Lake 资源。

在 AppHost 中：

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

在消费项目中：

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

不需要手动管理连接字符串，不需要四处寻找凭据。Aspire 负责资源的预配和注入。对于我们这些构建同时涉及运营数据和分析工作负载的云原生 .NET 应用的人来说，这让 Data Lake 在 Aspire 模型中真正成为了一等公民。

值得关注的小修复

除了主要功能之外，还有一些值得一提的改进：

MongoDB 连接字符串修复 — 数据库名称前的斜杠现在可以正确处理了。如果你之前有临时解决方案，现在可以移除了
SQL Server 导出 — Aspire.Hosting.SqlServer 现在导出额外的服务器配置选项，提供更精细的控制
模拟器更新 — ServiceBus 模拟器 2.0.0、App Configuration 模拟器 1.0.2，CosmosDB 的预览模拟器现在包含就绪检查
Azure Managed Redis — 现在默认使用 rediss://（Redis Secure），连接开箱即加密

最后一点虽然不起眼但很重要——默认加密的 Redis 意味着生产环境中少了一项需要配置的东西。

总结

Aspire 13.2 是一个增量版本，但 MongoDB EF Core 和 Data Lake 集成填补了真实的空白。如果你一直在等待 Aspire 中 MongoDB 的正式 EF Core 支持，或者需要 Data Lake 成为一等依赖项，升级到 13.2 试试看吧。aspire add 命令会为你生成所需的一切。

阅读完整的发行说明了解更多详情，查看集成库获取完整列表。

azd update — 一个命令搞定所有包管理器

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

你知道那个每隔几周就会弹出来的"azd 有新版本可用"提示吗？就是那个你总是忽略掉的，因为你根本想不起来当初是用 winget、Homebrew 还是半年前跑的那个 curl 脚本安装的 azd。好了，这个问题终于解决了。

Microsoft 刚刚发布了 azd update — 一个命令就能将 Azure Developer CLI 更新到最新版本，不管你最初是怎么安装的。Windows、macOS、Linux — 都一样。就一个命令。

工作原理

azd update

就这么简单。如果你想提前体验新功能，可以切换到每日 Insiders 构建：

azd update --channel daily
azd update --channel stable

这个命令会自动检测你当前的安装方式，并在后台使用对应的更新机制。再也不用纠结"等等，这台机器上我用的是 winget 还是 choco 来着？"

一个小前提

azd update 从版本 1.23.x 开始提供。如果你用的是更早的版本，需要用原来的安装方式做最后一次手动更新。之后，azd update 就能接管一切了。

用 azd version 查看你当前的版本。如果需要全新安装，安装文档可以帮到你。

为什么这很重要

这是一个小小的生活质量改善，但对于我们这些每天都在用 azd 把 AI Agent 和 Aspire 应用部署到 Azure 的人来说，保持最新意味着更少的"这个 bug 在最新版本里已经修复了"的尴尬时刻。少操心一件事。

阅读完整公告和 Jon Gallant 的深入分析了解更多。

Azure Smart Tier 正式发布 — 无需生命周期规则即可自动优化 Blob Storage 成本

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

如果你曾经花时间调整 Azure Blob Storage 的生命周期策略，然后看着它们在访问模式变化时土崩瓦解，那这篇文章就是为你准备的。微软刚刚宣布了 Azure Blob 和 Data Lake Storage 的 smart tier 正式发布 — 这是一项完全托管的分层功能，根据实际使用情况自动在 hot、cool 和 cold 层之间移动对象。

Smart tier 实际做了什么

概念很简单：smart tier 持续评估存储账户中每个对象的最后访问时间。频繁访问的数据保持在 hot 层，不活跃的数据在 30 天后移到 cool 层，再过 60 天移到 cold 层。当数据被再次访问时，立即提升回 hot 层。循环重新开始。

无需配置生命周期规则。无需预测访问模式。无需手动调优。

在预览期间，微软报告称 超过 50% 的 smart tier 管理容量根据实际访问模式自动转移到了更冷的层级。对于大型存储账户来说，这是一笔可观的成本节省。

为什么这对 .NET 开发者很重要

如果你正在构建生成日志、遥测数据、分析数据或任何类型的不断增长的数据资产的应用 — 说实话，谁不是呢 — 存储成本会很快累积起来。传统的做法是编写生命周期管理策略，测试它们，然后在应用的访问模式变化时重新调整。Smart tier 完全消除了这个工作流。

一些实用的场景：

应用遥测和日志 — 调试时是 hot，几周后几乎不再访问
数据管道和 ETL 输出 — 处理期间频繁访问，之后大多处于 cold 状态
用户生成内容 — 最近上传的是 hot，较老的内容逐渐变冷
备份和归档数据 — 偶尔因合规需要访问，大部分时间处于闲置状态

如何设置

启用 smart tier 是一次性配置：

新账户：在创建存储账户时选择 smart tier 作为默认访问层（需要区域冗余）
现有账户：将 blob 访问层从当前默认值切换到 smart tier

小于 128 KiB 的对象保持在 hot 层，不产生监控费用。其他所有对象按照标准 hot/cool/cold 容量费率计费，没有层级转换费用，没有提前删除罚金，没有数据检索成本。每个对象的月度监控费用涵盖编排服务。

需要了解的权衡

Smart tier 的分层规则是固定的（30 天 → cool，90 天 → cold）。如果你需要自定义阈值 — 比如某个特定工作负载在 7 天后移到 cool — 生命周期规则仍然是正确的选择。而且不要混用：避免对 smart tier 管理的对象使用生命周期规则，因为它们可能会产生冲突。

总结

这算不上革命性的改变，但它解决了一个实实在在的运维痛点。如果你管理着不断增长的 blob storage 账户，并且厌倦了维护生命周期策略，启用 smart tier 让 Azure 来处理吧。目前在几乎所有区域公有云区域都可以使用。

Azure上のAIエージェントはどこにホストすべき？実践的な判断ガイド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

如果你现在正在用.NET构建AI代理，你可能已经注意到一件事：在Azure上托管它们的方式太多了。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents——在你真正需要选择之前，每个都听起来合理。Microsoft刚刚发布了一份Azure AI代理托管综合指南来澄清这个问题，我想从.NET开发者的实践角度来拆解它。

六种选项速览

以下是我对这个版图的总结：

选项	最适合	你需要管理
Container Apps	无需K8s复杂性的完整容器控制	可观测性、状态、生命周期
AKS	企业合规、多集群、自定义网络	所有东西（这就是重点）
Azure Functions	事件驱动的短时代理任务	几乎不需要——真正的无服务器
App Service	简单的HTTP代理、可预测的流量	部署、扩展配置
Foundry Agents	通过门户/SDK的无代码代理	几乎不需要
Foundry Hosted Agents	托管基础设施上的自定义框架代理	仅你的代理代码

前四个是通用计算——你可以在上面运行代理，但它们不是为此设计的。最后两个是代理原生的：它们将对话、工具调用和代理生命周期理解为一等概念。

Foundry Hosted Agents——.NET代理开发者的最佳选择

这是引起我注意的地方。Foundry Hosted Agents正好处于中间位置：你获得运行自己代码的灵活性（Semantic Kernel、Agent Framework、LangGraph——随便什么），但平台处理基础设施、可观测性和对话管理。

关键部分是Hosting Adapter——一个将你的代理框架连接到Foundry平台的薄抽象层。对于Microsoft Agent Framework，看起来是这样的：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

这就是你的整个托管方案。适配器自动处理协议转换、通过server-sent events的流式传输、对话历史和OpenTelemetry追踪。不需要自定义中间件，不需要手动配置。

部署真的很简单

我以前在Container Apps上部署过代理，虽然可以工作，但最后你会写很多胶水代码来处理状态管理和可观测性。使用Hosted Agents和azd，部署是：

# 安装AI代理扩展
azd ext install azure.ai.agents

# 从模板初始化
azd ai agent init

# 构建、推送、部署——完成
azd up

这个单独的azd up会构建你的容器、推送到ACR、配置Foundry项目、部署模型端点并启动你的代理。五个步骤压缩成一个命令。

内置对话管理

这是在生产中节省最多时间的部分。不需要构建自己的对话状态存储，Hosted Agents原生处理：

# 创建持久对话
conversation = openai_client.conversations.create()

# 第一轮
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 第二轮——上下文被保留
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

不需要Redis。不需要Cosmos DB会话存储。不需要自定义中间件来序列化消息。平台直接处理了。

我的决策框架

在审查了所有六个选项之后，这是我的快速心智模型：

需要零基础设施？ → Foundry Agents（门户/SDK，无容器）
有自定义代理代码但想要托管主机？ → Foundry Hosted Agents
需要事件驱动的短期代理任务？ → Azure Functions
需要不用K8s的最大容器控制？ → Container Apps
需要严格合规和多集群？ → AKS
有流量可预测的简单HTTP代理？ → App Service

对于大多数使用Semantic Kernel或Microsoft Agent Framework构建的.NET开发者来说，Hosted Agents可能是正确的起点。你能获得scale-to-zero、内置OpenTelemetry、对话管理和框架灵活性——无需管理Kubernetes或搭建自己的可观测性栈。

总结

Azure上的代理托管格局正在快速成熟。如果你今天要开始一个新的AI代理项目，我会在习惯性地使用Container Apps或AKS之前认真考虑Foundry Hosted Agents。托管基础设施节省实际时间，而hosting adapter模式让你保留框架选择。

查看Microsoft的完整指南和Foundry Samples仓库获取可运行的示例。

.NET的Agent Skills变得真正灵活了

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

如果你一直在用Microsoft Agent Framework构建代理，那你已经熟悉流程了：定义技能，连接到provider，让代理决定调用哪个。新的是你如何创建这些技能——灵活性的提升非常显著。

最新更新引入了三种agent skill编写模式：基于文件的、基于类的和内联代码定义的。三种都连接到单一的 AgentSkillsProviderBuilder，意味着你可以自由混搭，无需路由逻辑或特殊粘合代码。让我带你了解每种模式以及何时使用。

基于文件的技能：起点

基于文件的技能顾名思义——磁盘上的一个目录，包含 SKILL.md 文件、可选脚本和参考文档。给代理添加新能力最直接的方式：

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md 的frontmatter声明技能名称和描述，指令部分告诉代理如何使用脚本和参考：

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

然后用 SubprocessScriptRunner.RunAsync 连接脚本执行：

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

代理自动发现技能并在需要检查账户状态时调用配置脚本。干净简单。

基于类的技能：通过NuGet分发

这里对团队来说变得有趣了。基于类的技能继承自 AgentClassSkill<T> 并使用 [AgentSkillResource] 和 [AgentSkillScript] 等属性，让框架通过反射发现一切：

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

妙处在于团队可以将其打包为NuGet包。你添加到项目中，放入builder，它就能和基于文件的技能一起工作，无需协调：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

两个技能都出现在代理的系统提示中。代理根据对话决定使用哪个——不需要路由代码。

内联技能：快速桥接

你知道那个时刻吗，另一个团队正在构建你需要的技能，但要到下个sprint才能完成？AgentInlineSkill 就是你的桥梁：

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

和其他技能一样添加到builder：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

当NuGet包最终发布时，你只需将内联技能替换为基于类的版本。代理不会注意到区别。

但内联技能不仅仅用于桥接。当你需要在运行时动态生成技能——想想从配置加载的每个业务单元一个技能——或者当脚本需要捕获不属于DI容器的本地状态时，它们也是正确的选择。

脚本审批：人在回路中

对我们构建生产代理的.NET开发者来说，这是真正打开部署讨论的部分。有些脚本有实际后果——给某人注册福利、查询生产基础设施。开启 UseScriptApproval，代理在执行任何脚本前会暂停：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

当代理想执行脚本时，它会返回一个审批请求。你的应用收集决定——批准或拒绝——代理相应继续。在受监管的环境中，这就是"我们可以部署这个"和"法务说不行"之间的区别。

为什么这种组合很重要

真正的力量不在于任何单一模式——而在于组合。你可以：

用基于文件的技能从小处开始，迭代指令，不写C#就能发布
将可复用的技能作为NuGet包分发，其他团队一行代码就能添加
当现在需要某样东西时，用内联技能填补空白
用谓词过滤共享目录，让代理只加载应该加载的
为触及生产系统的脚本添加人工监督

这一切都通过 AgentSkillsProviderBuilder 组合。没有特殊路由，没有条件逻辑，没有技能类型检查。

总结

.NET中的agent skills现在拥有了真正灵活的编写模型。无论你是用基于文件的技能做原型的独立开发者，还是通过NuGet分发打包能力的企业团队，这些模式都能适配。脚本审批机制使其在需要人工检查点的环境中也能投入生产。

查看原始公告、Microsoft Learn上的Agent Skills文档和GitHub上的.NET示例开始动手吧。

Azure MCP Server 2.0 正式发布——自托管智能云自动化来了

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

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

如果你最近一直在用 MCP 和 Azure 构建东西，你可能已经知道本地体验非常好。接入一个 MCP 服务器，让你的 AI 智能体与 Azure 资源对话，然后继续工作。但一旦你需要在团队中共享这个设置？那就会变得复杂。

不再是这样了。Azure MCP Server 刚刚发布 2.0 稳定版，而主打功能正是企业团队一直在要求的：自托管远程 MCP 服务器支持。

什么是 Azure MCP Server？

快速回顾一下。Azure MCP Server 实现了 Model Context Protocol 规范，并将 Azure 功能暴露为结构化、可发现的工具，AI 智能体可以调用。把它看作是你的智能体和 Azure 之间的标准化桥梁——配置、部署、监控、诊断，都通过一个统一的接口。

这些数字说明一切：跨越 57 个 Azure 服务的 276 个 MCP 工具。这是真正的覆盖范围。

重大突破：自托管远程部署

关键是这样的。在你的本地机器上运行 MCP 对于开发和实验来说没问题。但在真实的团队场景中，你需要：

开发者和内部智能体系统的共享访问
集中化配置（租户上下文、订阅默认值、遥测）
企业网络和策略边界
与 CI/CD 流程的集成

Azure MCP Server 2.0 解决了所有这些问题。你可以将其部署为一个集中管理的内部服务，具有基于 HTTP 的传输、适当的身份验证和一致的治理。

对于身份验证，你有两个不错的选择：

托管标识——在 Microsoft Foundry 旁边运行时
代表流 (OBO 流)——OpenID Connect 委托，使用已登录用户的上下文调用 Azure API

对于我们 .NET 开发者来说，OBO 流特别有趣。这意味着你的智能工作流可以使用用户的实际权限运行，而不是某个过度特权的服务账户。最小权限原则，内置其中。

安全加固

这不仅仅是一个功能发布——它也是一个安全发布。2.0 版本添加了：

更强的端点验证
针对面向查询工具中注入模式的保护
更严格的开发环境隔离控制

如果你要将 MCP 暴露为共享服务，这些保障措施很重要。非常重要。

你可以在哪里使用它？

客户端兼容性范围很广。Azure MCP Server 2.0 可与以下配合使用：

IDE：VS Code、Visual Studio、IntelliJ、Eclipse、Cursor
CLI 智能体：GitHub Copilot CLI、Claude Code
独立版：用于简单设置的本地服务器
自托管远程：2.0 的新星

此外，还有针对 Azure 美国政府版和由 21Vianet 运营的 Azure 的主权云支持，这对于受管制的部署至关重要。

为什么这对 .NET 开发者很重要

如果你使用 .NET 构建智能应用——无论是使用 Semantic Kernel、Microsoft Agent Framework，还是你自己的编排——Azure MCP Server 2.0 让你能够以生产级的方式让你的智能体与 Azure 基础设施交互。没有自定义 REST 包装。没有服务特定的集成模式。只是 MCP。

结合几天前发布的 MCP 应用流畅 API，.NET MCP 生态系统正在快速成熟。

开始使用

选择你的路径：

GitHub 仓库——源代码、文档，一切
Docker 镜像——容器化部署
VS Code 扩展——IDE 集成
自托管指南——2.0 的旗舰功能

总结

Azure MCP Server 2.0 正是那种在演示中看起来不起眼但在实践中改变一切的基础设施升级。具有适当身份验证、安全加固和主权云支持的自托管远程 MCP 意味着 MCP 已为在 Azure 上构建真实智能工作流的真实团队做好准备。如果你一直在等待"企业就绪"的信号——就是现在。

GitHub Copilot 的现代化评估是你还没用上的最好迁移工具

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

将传统 .NET Framework 应用迁移到现代 .NET 是那种每个人都知道应该做但没人想开始的任务。它从来不是简单的"更改目标框架"。而是消失的 API、不再存在的包、工作方式完全不同的托管模型，以及关于什么要容器化、什么要重写、什么要保持不变的无数小决策。

Jeffrey Fritz 刚刚发布了一篇 GitHub Copilot 现代化评估的深入解析，说实话？这是我见过的 .NET 最好的迁移工具。不是因为代码生成 — 那现在已经是标配了。而是因为它生成的评估文档。

它不仅仅是代码建议引擎

VS Code 扩展遵循评估 → 计划 → 执行模型。评估阶段分析你的整个代码库，生成一份结构化文档，捕获一切：什么需要更改、需要配置哪些 Azure 资源、使用什么部署模型。下游的一切 — 基础设施即代码、容器化、部署清单 — 都源自评估发现的内容。

评估存储在项目的 .github/modernize/assessment/ 下。每次运行产生一份独立的报告，因此你可以积累历史记录，并在修复问题时跟踪迁移态势的演变。

两种开始方式

推荐评估 — 快捷路径。从策划好的领域（Java/.NET 升级、云就绪、安全）中选择，无需配置即可获得有意义的结果。非常适合初次了解应用的状态。

自定义评估 — 定向路径。精确配置要分析的内容：目标计算（App Service、AKS、Container Apps）、目标操作系统、容器化分析。选择多个 Azure 目标来并排比较迁移方法。

那个比较视图真的很有用。一个应用在 App Service 上可能有 3 个必须解决的问题，在 AKS 上可能有 7 个。看到两者有助于在确定迁移路径之前做出托管决策。

问题分解是可操作的

每个问题都带有严重程度级别：

必须 — 必须修复，否则迁移失败
潜在 — 可能影响迁移，需要人工判断
可选 — 推荐的改进，不会阻止迁移

每个问题都链接到受影响的文件和行号，提供详细描述说明什么地方有问题以及为什么对目标平台重要，给出具体的修复步骤（不仅仅是"修复这个"），并包含官方文档链接。

你可以将单个问题分配给开发者，他们拥有行动所需的一切。这就是告诉你"有个问题"的工具和告诉你如何解决的工具之间的区别。

涵盖的升级路径

针对 .NET 具体来说：

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

每条升级路径都有检测规则，知道哪些 API 被移除、哪些模式没有直接等价物、哪些安全问题需要关注。

对于管理多个应用的团队，还有一个 CLI 支持多仓库批量评估 — 克隆所有仓库，全部评估，获取每个应用的报告加上汇总的组合视图。

我的看法

如果你坐拥传统 .NET Framework 应用（说实话，大多数企业团队都是这样），这就是那个应该开始使用的工具。仅评估文档就值得投入时间 — 它将模糊的"我们应该现代化"变成了一个具体的、有优先级的工作项列表，指明了前进的方向。

协作工作流也很聪明：导出评估、与团队分享、无需重新运行即可导入。决策者不是运行工具的人的架构评审？涵盖了。

总结

GitHub Copilot 的现代化评估将 .NET 迁移从一个可怕的、不明确的项目转变为一个结构化的、可跟踪的过程。从推荐评估开始了解你的现状，然后使用自定义评估来比较 Azure 目标并制定迁移计划。

阅读完整演练并获取 VS Code 扩展在你自己的代码库上试试。

Microsoft Foundry 2026年3月 — GPT-5.4、Agent Service GA，以及改变一切的SDK刷新

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

每月的"Microsoft Foundry新动态"文章通常是增量改进和偶尔亮点功能的混合。2026年3月版呢？基本上全是亮点功能。Foundry Agent Service正式GA，GPT-5.4投入生产，SDK获得重要的稳定版本发布，Fireworks AI将开放模型推理引入Azure。让我来解析对.NET开发者来说什么最重要。

Foundry Agent Service已准备好投入生产

这是最大的新闻。新一代代理运行时已正式发布 — 构建在OpenAI Responses API之上，与OpenAI代理协议兼容，并向多个提供商的模型开放。如果您今天正在使用Responses API构建，迁移到Foundry将在您现有的代理逻辑之上添加企业级安全性、私有网络、Entra RBAC、完整追踪和评估功能。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

关键新增功能：端到端私有网络、MCP认证扩展（包括OAuth透传）、语音对语音代理的Voice Live预览，以及在6个新区域托管代理。

GPT-5.4 — 可靠性优于纯粹的智能

GPT-5.4不是为了变得更聪明，而是为了变得更可靠。在长时间交互中更强的推理能力、更好的指令遵循性、更少的工作流中途故障，以及集成的计算机使用功能。对于生产环境的代理来说，这种可靠性比基准测试分数重要得多。

模型	价格（每百万token）	最佳用途
GPT-5.4 (≤272K)	$2.50 / $15 输出	生产代理、编码、文档工作流
GPT-5.4 Pro	$30 / $180 输出	深度分析、科学推理
GPT-5.4 Mini	经济实惠	分类、提取、轻量级工具调用

聪明的策略是路由：GPT-5.4 Mini处理高吞吐量、低延迟的工作，而GPT-5.4负责推理密集型的请求。

SDK终于稳定了

azure-ai-projects SDK在所有语言中发布了稳定版 — Python 2.0.0、JS/TS 2.0.0、Java 2.0.0和.NET 2.0.0（4月1日）。azure-ai-agents依赖已经消失 — 一切都在AIProjectClient下。使用pip install azure-ai-projects安装，包中直接捆绑了openai和azure-identity作为依赖项。

对于.NET开发者来说，这意味着一个NuGet包就能覆盖Foundry的全部功能。不再需要在多个代理SDK之间来回切换。

Fireworks AI将开放模型引入Azure

也许是架构上最有趣的新增：Fireworks AI每天处理超过13万亿token，速度达到~180K请求/秒，现在可以通过Foundry使用。DeepSeek V3.2、gpt-oss-120b、Kimi K2.5和MiniMax M2.5在发布时可用。

真正的故事是自带权重 — 从任何地方上传量化或微调的权重，无需更改服务栈。通过无服务器按token付费或预配置吞吐量进行部署。

其他亮点

Phi-4 Reasoning Vision 15B — 针对图表、图形和文档布局的多模态推理
Evaluations GA — 开箱即用的评估器，配合持续生产监控，直接接入Azure Monitor
Priority Processing（预览）— 面向延迟敏感型工作负载的专用计算通道
Voice Live — 直接连接到Foundry代理的语音对语音运行时
Tracing GA — 具有排序和过滤功能的端到端代理追踪检查
PromptFlow弃用 — 在2027年1月前迁移到Microsoft Framework Workflows

总结

2026年3月是Foundry的转折点。Agent Service GA、所有语言的稳定SDK、用于可靠生产代理的GPT-5.4，以及通过Fireworks AI实现的开放模型推理 — 该平台已准备好应对严肃的工作负载。

阅读完整汇总并构建您的第一个代理来开始吧。

SQL MCP Server — 给 AI 代理数据库访问的正确方式

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

说实话：今天市面上大多数数据库 MCP 服务器都很可怕。它们接受自然语言查询，即时生成 SQL，然后在你的生产数据上执行。有什么可能出错的？（一切。一切都可能出错。）

Azure SQL 团队刚刚发布了 SQL MCP Server，它采用了一种根本不同的方法。作为 Data API builder（DAB）2.0 的功能构建，它为 AI 代理提供结构化、确定性的数据库操作访问 — 没有 NL2SQL，不暴露你的架构，每一步都有完整的 RBAC。

为什么不用 NL2SQL？

这是最有趣的设计决策。模型不是确定性的，复杂查询最容易产生微妙的错误。用户希望 AI 能生成的那些查询，恰恰也是在非确定性生成时最需要审查的查询。

相反，SQL MCP Server 使用 NL2DAB 方法。代理使用 Data API builder 的实体抽象层和内置查询构建器来确定性地生成准确、格式良好的 T-SQL。对用户来说结果相同，但没有幻觉 JOIN 或意外数据泄露的风险。

七个工具，不是七百个

SQL MCP Server 精确暴露七个 DML 工具，与数据库大小无关：

describe_entities — 发现可用实体和操作
create_record — 插入行
read_records — 查询表和视图
update_record — 修改行
delete_record — 删除行
execute_entity — 运行存储过程
aggregate_records — 聚合查询

这很聪明，因为上下文窗口是代理的思考空间。用数百个工具定义淹没它们会减少推理空间。七个固定工具让代理专注于思考而不是导航。

每个工具可以单独启用或禁用：

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

三条命令开始

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

这就是一个运行中的 SQL MCP Server，暴露你的 Customers 表。实体抽象层意味着你可以为名称和列创建别名、按角色限制字段，并精确控制代理看到的内容 — 而不暴露内部架构细节。

安全故事很扎实

这是 Data API builder 成熟度发挥价值的地方：

每一层都有 RBAC — 每个实体定义哪些角色可以读取、创建、更新或删除，以及哪些字段可见
Azure Key Vault 集成 — 安全管理连接字符串和密钥
Microsoft Entra + 自定义 OAuth — 生产级认证
内容安全策略 — 代理通过受控契约交互，而不是原始 SQL

架构抽象特别重要。你的内部表名和列名永远不会暴露给代理。你定义对 AI 交互有意义的实体、别名和描述 — 而不是你的数据库 ERD 图。

多数据库和多协议

SQL MCP Server 支持 Microsoft SQL、PostgreSQL、Azure Cosmos DB 和 MySQL。由于它是 DAB 的功能，你可以从同一配置同时获取 REST、GraphQL 和 MCP 端点。相同的实体定义、相同的 RBAC 规则、相同的安全性 — 跨所有三种协议。

DAB 2.0 的自动配置甚至可以检查你的数据库并动态构建配置，如果你愿意为快速原型设计减少抽象的话。

我的看法

这就是 AI 代理的企业级数据库访问应该如何工作。不是"嘿 LLM，给我写点 SQL 然后对生产环境 YOLO"。而是：定义良好的实体层、确定性查询生成、每一步的 RBAC、缓存、监控和遥测。以最好的方式无聊着。

对于 .NET 开发者，集成故事很清晰 — DAB 是 .NET 工具，MCP Server 作为容器运行，与大多数人已经在用的 Azure SQL 配合工作。如果你正在构建需要数据访问的 AI 代理，从这里开始。

总结

SQL MCP Server 是免费、开源的，可在任何地方运行。这是微软为给 AI 代理提供安全数据库访问的规范性方法。查看完整文章和文档开始使用。

构建不像黑盒的实时多智能体UI

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

多智能体系统的问题在于：它们在演示中看起来令人难以置信。三个智能体互相传递工作、解决问题、做出决策。然后你试图把它展示给真实用户，得到的却是……沉默。一个旋转的加载指示器。完全不知道哪个智能体在做什么，或者系统为什么暂停了。这不是产品——这是信任问题。

Microsoft Agent Framework团队刚刚发布了一篇精彩的教程，介绍如何将MAF工作流与AG-UI配合使用。AG-UI是一个开放协议，通过Server-Sent Events将智能体执行事件流式传输到前端。说实话，这正是我们一直缺少的桥梁。

为什么这对.NET开发者很重要

如果你在构建AI驱动的应用，可能已经遇到过这堵墙。你的后端编排工作得很好——智能体之间传递任务、工具触发、决策做出。但前端完全不知道幕后发生了什么。AG-UI通过定义一个标准协议来解决这个问题，将智能体事件（想想RUN_STARTED、STEP_STARTED、TOOL_CALL_*、TEXT_MESSAGE_*）通过SSE直接传输到你的UI层。

他们构建的演示是一个包含三个智能体的客户支持工作流：一个路由请求的分诊智能体、一个处理退款事务的退款智能体，以及一个管理换货的订单智能体。每个智能体都有自己的工具，交接拓扑是明确定义的——没有"从提示词中猜测"的感觉。

交接拓扑才是真正的主角

让我眼前一亮的是HandoffBuilder如何让你声明智能体之间的有向路由图：

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

每个add_handoff创建一条带有自然语言描述的有向边。框架基于这个拓扑为每个智能体生成交接工具。因此路由决策是基于你的编排结构，而不是LLM随意决定的。这对生产环境的可靠性意义重大。

真正有效的人机协作

演示展示了任何真实世界智能体应用都需要的两种中断模式：

工具审批中断 ——当智能体调用标记为approval_mode="always_require"的工具时，工作流暂停并发出事件。前端渲染一个包含工具名称和参数的审批模态框。没有烧掉token的重试循环——只是一个干净的暂停-审批-恢复流程。

信息请求中断 ——当智能体需要用户提供更多上下文（比如订单ID）时，它会暂停并询问。前端显示问题，用户回答，执行从停止的地方精确恢复。

两种模式都作为标准AG-UI事件进行流式传输，所以你的前端不需要针对每个智能体的自定义逻辑——只需渲染通过SSE连接传来的任何事件。

接入出奇地简单

MAF和AG-UI之间的集成就是一个函数调用：

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory为每个线程创建一个新的工作流，这样每个对话都有隔离的状态。端点自动处理所有SSE管道。如果你已经在使用FastAPI（或者可以把它作为轻量层添加），这几乎是零摩擦的。

我的看法

对于我们.NET开发者来说，第一个问题是：“我能用C#做这个吗？“Agent Framework同时支持.NET和Python，AG-UI协议是语言无关的（只是SSE）。所以虽然这个特定演示使用Python和FastAPI，但模式可以直接移植。你可以用ASP.NET Core最小API配合SSE端点，遵循相同的AG-UI事件模式来实现。

更重要的启示是，多智能体UI正在成为一等公民的关注点，而不是事后才想到的事情。如果你在构建任何需要智能体与人类交互的东西——客户支持、审批工作流、文档处理——MAF编排加AG-UI透明度的组合就是应该遵循的模式。

总结

AG-UI + Microsoft Agent Framework给你两全其美：后端强大的多智能体编排和前端的实时可视化。不再有黑盒式的智能体交互。

查看完整教程和AG-UI协议仓库以深入了解。

将 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 能力，具有适当的身份验证，且服务器本身无需代码更改。

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

智能体平台工程正在成为现实 — Git-APE展示了方法

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

平台工程一直是那种在技术大会上听起来很棒的术语，但通常意味着"我们搭了一个内部门户和一个Terraform封装器。“真正的承诺 — 真正安全、受治理且快速的自助式基础设施 — 总是差那么几步。

Azure团队刚刚发布了智能体平台工程系列的第二部分，这次全是关于动手实现。他们称之为Git-APE（是的，这个缩写是故意的），这是一个开源项目，使用GitHub Copilot智能体加Azure MCP服务器，将自然语言请求转化为经过验证和部署的基础设施。

Git-APE究竟做什么

核心思路：开发者不再需要学习Terraform模块、浏览门户UI或向平台团队提交工单，而是直接和Copilot智能体对话。智能体理解意图、生成基础设施即代码、根据策略进行验证并部署 — 全部在VS Code内完成。

配置如下：

git clone https://github.com/Azure/git-ape
cd git-ape

在VS Code中打开工作区，GitHub Copilot会自动发现智能体配置文件。你直接与智能体交互：

@git-ape deploy a function app with storage in West Europe

智能体在底层使用Azure MCP Server与Azure服务交互。VS Code设置中的MCP配置启用特定功能：

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

为什么这很重要

对于我们在Azure上构建的人来说，这将平台工程的对话从"如何构建一个门户"转变为"如何将我们的护栏描述为API。“当你的平台接口是AI智能体时，你的约束和策略的质量就成了产品本身。

第一部分博客阐述了理论：描述良好的API、控制模式和明确的护栏使平台做好了智能体化的准备。第二部分通过交付实际工具证明它确实有效。智能体不会盲目生成资源 — 它会根据最佳实践进行验证、遵守命名约定并应用你组织的策略。

清理同样简单：

@git-ape destroy my-resource-group

我的看法

说实话 — 这里更多是关于模式而非具体工具。Git-APE本身是一个演示/参考架构。但底层的理念 — 智能体作为平台的接口、MCP作为协议、GitHub Copilot作为宿主 — 这就是企业开发者体验的前进方向。

如果你是一个正在寻找如何让内部工具对智能体友好的平台团队，没有比这更好的起点了。如果你是.NET开发者想知道这和你的世界如何关联：Azure MCP Server和GitHub Copilot智能体可以与任何Azure工作负载配合使用。你的ASP.NET Core API、你的.NET Aspire技术栈、你的容器化微服务 — 都可以成为智能体部署流程的目标。

总结

Git-APE是对智能体平台工程实践的一个早期但具体的展示。克隆仓库，试试演示，开始思考你的平台的API和策略需要是什么样子，才能让智能体安全地使用它们。

阅读完整文章获取详细教程和演示视频。

azd现在可以在本地运行和调试AI代理了 — 2026年3月都有哪些变化

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

一个月七个版本。这是Azure Developer CLI (azd) 团队在2026年3月发布的成果，而头条功能正是我一直在等的：AI代理的本地运行和调试循环。

PC Chan 发布了完整摘要，虽然内容很多，但让我筛选出对构建AI驱动应用的.NET开发者真正重要的部分。

不用部署就能运行和调试AI代理

这是最大的亮点。新的 azure.ai.agents 扩展添加了一组命令，为AI代理提供了完整的内循环体验：

azd ai agent run — 在本地启动你的代理
azd ai agent invoke — 向其发送消息（本地或已部署的）
azd ai agent show — 显示容器状态和健康状况
azd ai agent monitor — 实时流式传输容器日志

以前，测试AI代理意味着每次修改都要部署到Microsoft Foundry。现在你可以在本地迭代，测试代理行为，准备好了再部署。

GitHub Copilot为你配置azd项目

azd init 现在提供了"Set up with GitHub Copilot (Preview)“选项。无需手动回答关于项目结构的提示，Copilot代理为你生成配置。当命令失败时，azd 提供AI辅助的问题排查——全程不需要离开终端。

Container App Jobs和部署改进

Container App Jobs：azd现在通过现有的host: containerapp配置部署Microsoft.App/jobs。
可配置的部署超时：azd deploy的新--timeout标志和azure.yaml中的deployTimeout字段。
远程构建回退：当ACR构建失败时，azd自动回退到本地Docker/Podman构建。
本地预检验证：部署前在本地验证Bicep参数。

开发体验改进

自动检测pnpm/yarn — JS/TS项目
pyproject.toml支持 — Python打包
本地模板目录 — azd init --template接受文件系统路径
更好的错误消息 — --no-prompt模式
构建环境变量 — 注入到所有框架构建子进程（.NET、Node.js、Java、Python）

总结

本地AI代理调试循环是这个版本的明星，但部署改进和DX优化的积累使azd比以往更加成熟。如果你在Azure上部署.NET应用——特别是AI代理——这次更新值得关注。

查看完整发行说明了解所有细节。

KubeCon Europe 2026：.NET 开发者真正需要关注的内容

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

你知道那种感觉吗？一个巨大的公告文章出来了，你一边滚动一边想"不错，但这对我到底有什么改变"？这就是我每个 KubeCon 季的状态。

微软刚刚发布了他们的 KubeCon Europe 2026 完整总结——出自 Brendan Burns 本人之手——说实话？这次有真正的干货。不只是功能清单，而是真正改变你在生产环境中运维方式的运营改进。

让我来梳理一下对我们 .NET 开发者真正重要的内容。

不用付服务网格税的 mTLS

服务网格的问题在于：每个人都想要安全保障，没人想要运营负担。AKS 终于在弥补这个差距了。

Azure Kubernetes Application Network 给你提供了双向 TLS、应用感知授权和流量遥测——不需要部署一个带 sidecar 的重型 mesh。结合 Advanced Container Networking Services 中的 Cilium mTLS，你可以获得使用 X.509 证书和 SPIRE 身份管理的加密 pod 间通信。

这在实践中意味着什么：你的 ASP.NET Core API 与后台 worker 通信，你的 gRPC 服务互相调用——全部在网络层加密和身份验证，零应用代码更改。这意义重大。

对于从 ingress-nginx 迁移的团队，还有 Meshless Istio 的 Application Routing 全面支持 Kubernetes Gateway API。无 sidecar。基于标准。并且发布了 ingress2gateway 工具用于增量迁移。

不再是事后想到的 GPU 可观测性

如果你在 .NET 服务旁运行 AI 推理（说实话，谁现在还没开始？），你可能遇到过 GPU 监控盲区。CPU/内存仪表板很棒，然后 GPU 部分…没有手动配置导出器就什么都没有。

AKS 现在原生暴露 GPU 指标到托管的 Prometheus 和 Grafana。同样的技术栈，同样的仪表板，同样的告警管道。无需自定义导出器，无需第三方代理。

在网络方面，增加了 HTTP、gRPC 和 Kafka 流量的逐流可见性，配合一键 Azure Monitor 体验。IP、端口、工作负载、流方向、策略决策——全部在内置仪表板中。

让我看了两遍的是：agentic container networking 添加了一个 Web UI，你可以用自然语言询问集群的网络状态。“为什么 pod X 无法到达服务 Y？"→ 从实时遥测获取只读诊断。凌晨两点真的很有用。

不需要博士学位的跨集群网络

多集群 Kubernetes 历来是"自带网络胶水"的体验。Azure Kubernetes Fleet Manager 现在通过托管 Cilium 集群网格提供跨集群网络：

AKS 集群间的统一连接
用于跨集群发现的全局服务注册表
集中管理配置，而不是每个集群重复

如果你为了弹性或合规在多个区域运行 .NET 微服务，这替代了很多脆弱的自定义胶水。West Europe 的服务 A 可以通过网格发现和调用 East US 的服务 B，使用一致的路由和安全策略。

不需要勇气的升级

说实话——生产环境中的 Kubernetes 升级是有压力的。“升级然后祈祷"一直是太多团队的实际策略，也是集群版本落后的主要原因。

两个新功能改变了这一点：

Blue-green 代理池升级 用新配置创建一个并行节点池。验证行为，逐步转移流量，保持干净的回滚路径。不再在生产节点上进行就地变更。

代理池回滚 允许你在升级出问题后将节点池恢复到之前的 Kubernetes 版本和节点镜像——无需重建集群。

两者结合，终于给运维人员提供了对升级生命周期的真正控制。对于 .NET 团队来说很重要，因为平台速度直接控制你能多快采用新的运行时、安全补丁和网络能力。

AI 工作负载成为 Kubernetes 一等公民

上游开源工作同样重要。Dynamic Resource Allocation (DRA) 刚在 Kubernetes 1.36 中 GA，使 GPU 调度成为真正的一等功能而不是变通方案。

值得关注的项目：

项目	作用
AI Runway	推理的通用 Kubernetes API——不懂 K8s 也能部署模型，带 HuggingFace 发现和成本估算
HolmesGPT	云原生的智能体故障排除——现在是 CNCF Sandbox 项目
Dalec	带 SBOM 生成的声明式容器镜像构建——构建阶段减少 CVE

方向很明确：你的 .NET API、Semantic Kernel 编排层和推理工作负载应该都运行在一个一致的平台模型上。我们正在接近。

这周我会从哪里开始

如果你在为团队评估这些变化，这是我真诚的优先级列表：

先搞可观测性——在非生产集群中启用 GPU 指标和网络流日志。看看你一直错过了什么。
测试 blue-green 升级——在下次生产集群升级前测试回滚工作流。建立对流程的信心。
试点身份感知网络——选择一个内部服务路径并用 Cilium 启用 mTLS。测量开销（剧透：很小）。
评估 Fleet Manager——如果你运行超过两个集群，跨集群网络光减少自定义胶水就能回本。

小实验，快反馈。这永远是正确的做法。

总结

KubeCon 公告可能让人应接不暇，但这批更新确实为 AKS 上的 .NET 团队带来了实质性改变。更好的网络安全（无 mesh 开销）、真正的 GPU 可观测性、更安全的升级以及更强大的 AI 基础设施支撑。

如果你已经在用 AKS，现在是加强运营基准的好时机。如果你计划将 .NET 工作负载迁移到 Kubernetes——平台刚刚变得更加适合生产环境了。

SQL MCP Server、SSMS 中的 Copilot 以及带 AI 代理的 Database Hub：SQLCon 2026 真正重要的内容

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft 刚刚在亚特兰大与 FabCon 同期举办了 SQLCon 2026，内容非常多。原始公告涵盖了从节省计划到企业合规功能的方方面面。我打算跳过企业定价的幻灯片，专注于对使用 Azure SQL 和 AI 进行开发的人来说真正重要的部分。

SQL MCP Server

这是我眼中的头条新闻。Azure SQL Database Hyperscale 现在有了一个 SQL MCP Server 公共预览版，让你可以使用 Model Context Protocol 将 SQL 数据安全地连接到 AI 代理和 Copilot。

如果你一直在关注 MCP 的浪潮——说实话，现在想不注意到都难——这是一个大事件。你不再需要构建自定义数据管道来为 AI 代理提供来自数据库的上下文，而是获得了一个标准化协议来直接公开 SQL 数据。你的代理可以查询、推理并基于实时数据库信息采取行动。

对于我们这些用 Semantic Kernel 或 Microsoft Agent Framework 构建 AI 代理的人来说，这打开了一条干净的集成路径。你的代理需要检查库存？查找客户记录？验证订单？MCP 提供了一种结构化的方式来做这些事情，而不需要你为每个场景编写定制的数据获取代码。

SSMS 22 中的 GitHub Copilot 现已正式发布

如果你在 SQL Server Management Studio 中花过任何时间——说实话，我们大多数人还在用——GitHub Copilot 现在已在 SSMS 22 中正式发布。和你在 VS Code 和 Visual Studio 中使用的 Copilot 体验一样，但用于 T-SQL。

实际价值很直接：基于聊天的辅助来编写查询、重构存储过程、排查性能问题和处理管理任务。概念上没什么革命性的，但直接在 SSMS 中使用意味着你不需要为了获得数据库工作的 AI 帮助而切换到另一个编辑器。

向量索引获得了重大升级

Azure SQL Database 现在拥有更快、更强大的向量索引，完全支持插入、更新和删除操作。这意味着你的向量数据可以实时保持最新——不需要批量重建索引。

新功能如下：

量化在不损失太多精度的情况下缩小索引大小
迭代过滤 获得更精确的结果
与查询优化器更紧密的集成 实现可预测的性能

如果你正在使用 Azure SQL 作为向量存储进行 Retrieval-Augmented Generation (RAG)，这些改进直接有用。你可以将向量和关系数据放在同一个数据库中，相比运行单独的向量数据库，这大大简化了你的架构。

同样的向量增强功能在 Fabric 中的 SQL Database 也可用，因为两者底层运行的是同一个 SQL 引擎。

Fabric 中的 Database Hub：代理式管理

这个更偏向未来，但很有意思。Microsoft 宣布了 Microsoft Fabric 中的 Database Hub（抢先体验），为你提供跨 Azure SQL、Cosmos DB、PostgreSQL、MySQL 和 SQL Server via Arc 的统一视图。

有意思的不仅仅是统一视图——而是代理式的管理方法。AI 代理持续监控你的数据库群，展示发生了什么变化，解释为什么重要，并建议下一步该做什么。这是一个人机协作（human-in-the-loop）模型，代理做前期工作，你来做决策。

对于管理多个数据库的团队来说，这可能真正减少运维噪音。代理把信号带给你，而不是让你在各个门户之间跳来跳去手动检查指标。

这对 .NET 开发者意味着什么

贯穿所有这些公告的主线很清晰：Microsoft 正在将 AI 代理嵌入数据库技术栈的每一层。不是作为噱头，而是作为实用的工具层。

如果你正在构建基于 Azure SQL 的 .NET 应用，以下是我实际会做的事情：

试试 SQL MCP Server，如果你在构建 AI 代理的话。这是给代理提供数据库访问最干净的方式，不需要自定义的管道代码。
在 SSMS 中启用 Copilot，如果还没有的话——对日常 SQL 工作来说是免费的生产力提升。
了解一下向量索引，如果你在做 RAG 且目前运行着单独的向量存储。整合到 Azure SQL 意味着少管理一个服务。

总结

完整公告还有更多内容——节省计划、迁移助手、合规功能——但对开发者来说，重点在 MCP Server、向量改进和代理式管理层。这些才是改变你构建方式的东西，而不仅仅是改变你做预算的方式。

查看 Shireesh Thota 的完整公告获取全貌，如果你想试试新的管理体验，可以注册 Database Hub 抢先体验。

Azure DevOps MCP Server 登陆 Microsoft Foundry：这对你的 AI 代理意味着什么

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP（Model Context Protocol）正在迎来它的高光时刻。如果你一直在关注 AI 代理生态系统，你可能已经注意到 MCP 服务器到处涌现 — 通过标准化协议赋予代理与外部工具和服务交互的能力。

现在 Azure DevOps MCP Server 已在 Microsoft Foundry 中可用，这是那种让你思考实际可能性的集成之一。

这里到底发生了什么

Microsoft 已经发布了 Azure DevOps MCP Server 的公开预览版 — 那是 MCP 服务器本身。新的是 Foundry 集成。你现在可以直接从工具目录将 Azure DevOps MCP Server 添加到 Foundry 代理中。

对于还不熟悉 Foundry 的人：它是 Microsoft 用于大规模构建和管理 AI 驱动应用程序和代理的统一平台。模型访问、编排、评估、部署 — 全部在一个地方。

配置

配置出奇地简单：

在你的 Foundry 代理中，进入 Add Tools > Catalog
搜索 “Azure DevOps”
选择 Azure DevOps MCP Server（preview）并点击 Create
输入你的组织名称并连接

就这样。你的代理现在可以访问 Azure DevOps 工具了。

控制代理可以访问什么

这是我欣赏的部分：你不会被困在全有或全无的方式中。你可以指定哪些工具对代理可用。如果你只想让它读取工作项但不碰管道，可以这样配置。最小权限原则，应用到你的 AI 代理上。

这在企业场景中很重要，你不希望一个代理因为有人让它"帮忙发布"就意外触发部署管道。

为什么这对 .NET 团队很有趣

想想这在实践中能实现什么：

冲刺规划助手 — 可以拉取工作项、分析速度数据并建议冲刺容量的代理
代码审查机器人 — 因为能实际读取你的仓库和关联的工作项，所以理解你的 PR 上下文的代理
事件响应 — 可以创建工作项、查询最近的部署并将 bug 与最近的更改关联的代理
开发者入职 — “我应该做什么？“得到基于实际项目数据的真实回答

对于已经在 CI/CD 管道和项目管理中使用 Azure DevOps 的 .NET 团队来说，拥有一个能直接与这些系统交互的 AI 代理是迈向有用自动化的重要一步。

更大的 MCP 图景

这是更广泛趋势的一部分：MCP 服务器正在成为 AI 代理与外部世界交互的标准方式。我们在 GitHub、Azure DevOps、数据库、SaaS API 中都能看到它们 — 而 Foundry 正在成为所有这些连接汇聚的中心。

如果你在 .NET 生态系统中构建代理，MCP 值得关注。协议是标准化的，工具正在成熟，Foundry 集成使其无需手动配置服务器连接即可访问。

总结

Foundry 中的 Azure DevOps MCP Server 目前处于预览阶段，所以预计它会继续发展。但核心工作流是可靠的：连接、配置工具访问，让你的代理使用你的 DevOps 数据工作。如果你已经在 Foundry 生态系统中，只需几次点击就能开始。试试看你能构建什么工作流。

查看完整公告获取完整的配置步骤和更多详情。

Foundry Agent Service 正式发布：对 .NET 代理开发者真正重要的是什么

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

说实话 — 构建一个 AI 代理原型是简单的部分。困难的是之后的一切：用适当的网络隔离投入生产、运行真正有意义的评估、处理合规要求，以及不在凌晨 2 点搞崩东西。

Foundry Agent Service 刚刚正式发布，这个版本像激光一样聚焦在"之后一切"的鸿沟上。

构建在 Responses API 之上

标题新闻：新一代 Foundry Agent Service 构建在 OpenAI Responses API 之上。如果你已经在用这个 wire protocol 构建，迁移到 Foundry 只需最少的代码改动。你获得的：企业安全、私有网络、Entra RBAC、完整追踪和评估 — 在你现有的代理逻辑之上。

架构是有意开放的。你不被锁定在一个模型提供商或一个编排框架上。用 DeepSeek 做规划、OpenAI 做生成、LangGraph 做编排 — 运行时处理一致性层。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

私有网络：企业阻碍已移除

这是解锁企业采用的功能。Foundry 现在支持完整的端到端私有网络配合 BYO VNet：

无公共出口 — 代理流量永远不会触及公共互联网
容器/子网注入到你的网络以实现本地通信
工具连接也包含在内 — MCP 服务器、Azure AI Search、Fabric 数据代理都通过私有路径运作

最后一点至关重要。不只是推理调用保持私有 — 每个工具调用和检索调用也都留在你的网络边界内。对于在数据分类策略下禁止外部路由的团队来说，这就是缺失的那块。

MCP 认证做对了

MCP 服务器连接现在支持完整的认证模式谱系：

认证方式	何时使用
基于密钥	组织范围内部工具的简单共享访问
Entra Agent Identity	服务间；代理以自身身份认证
Entra Managed Identity	按项目隔离；无凭证管理
OAuth Identity Passthrough	用户委托访问；代理代表用户行事

OAuth Identity Passthrough 是有趣的那个。当用户需要授予代理访问他们的个人数据 — 他们的 OneDrive、Salesforce 组织、按用户范围的 SaaS API — 代理使用标准 OAuth 流程代表他们行事。没有假装是所有人的共享系统身份。

Voice Live：无需管道工程的语音对语音

给代理添加语音曾经意味着拼凑 STT、LLM 和 TTS — 三个服务、三次延迟跳转、三个计费面，全部手动同步。Voice Live 将这一切压缩为单个托管 API：

语义语音活动和轮次结束检测（理解含义，不仅仅是沉默）
服务端噪声抑制和回声消除
插话支持（用户可以在响应中途打断）

语音交互通过与文本相同的代理运行时。相同的评估器、相同的追踪、相同的成本可见性。对于客户支持、现场服务或无障碍场景，这取代了以前需要自定义音频管道的方案。

评估：从勾选框到持续监控

这是 Foundry 认真对待生产质量的地方。评估系统现在有三层：

开箱即用评估器 — 连贯性、相关性、扎实度、检索质量、安全性。连接到数据集或实时流量获取分数。
自定义评估器 — 编码你自己的业务逻辑、语调标准和领域特定合规规则。
持续评估 — Foundry 采样实时生产流量，运行你的评估器套件，并在仪表板中显示结果。设置 Azure Monitor 告警以监控扎实度下降或安全阈值突破。

一切发布到 Azure Monitor Application Insights。代理质量、基础设施健康、成本和应用遥测 — 全在一处。

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

六个新区域支持托管代理

托管代理现在在 East US、North Central US、Sweden Central、Southeast Asia、Japan East 等区域可用。这对数据驻留要求很重要，也有助于在代理靠近数据源运行时压缩延迟。

为什么这对 .NET 开发者重要

虽然 GA 公告中的代码示例是 Python 优先的，但底层基础设施是语言无关的 — azure-ai-projects 的 .NET SDK 遵循相同的模式。Responses API、评估框架、私有网络、MCP 认证 — 这些都可以从 .NET 使用。

如果你一直在等 AI 代理从"酷炫演示"变成"我真的可以在工作中交付"，这个 GA 版本就是信号。私有网络、适当的认证、持续评估和生产监控是缺失的那些拼图。

总结

Foundry Agent Service 现在可用。安装 SDK，打开门户，开始构建。快速入门指南带你在几分钟内从零到运行中的代理。

包含所有代码示例的完整技术深度分析，请查看 GA 公告。

Microsoft Agent Framework 中的后台响应：告别超时焦虑

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

如果你用 o3 或 GPT-5.2 等推理模型构建过任何东西，你就知道那种痛苦。你的代理开始思考一个复杂的任务，客户端在那里等待，在"没问题"和"它是不是崩了？“之间的某个时刻，你的连接超时了。那些工作？全没了。

Microsoft Agent Framework 刚刚推出了后台响应 — 说实话，这是那种从第一天就应该存在的功能。

阻塞调用的问题

在传统的请求-响应模式中，你的客户端会阻塞直到代理完成。对于快速任务来说没问题。但当你让推理模型做深度研究、多步分析或生成 20 页报告时？你面对的是几分钟的实际等待时间。在这个窗口期：

HTTP 连接可能超时
网络抖动会杀死整个操作
你的用户盯着一个加载动画想知道是否有事情在发生

后台响应彻底翻转了这个局面。

延续令牌如何工作

你不再阻塞等待，而是启动代理任务并获得一个延续令牌。把它想象成修理店的取件单 — 你不需要站在柜台前等着，准备好了再回来取就行。

流程很简单：

使用 AllowBackgroundResponses = true 发送请求
如果代理支持后台处理，你会收到一个延续令牌
按你的节奏轮询，直到令牌返回 null — 这意味着结果准备好了

这是 .NET 版本：

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// 轮询直到完成
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

如果代理立即完成（简单任务、不需要后台处理的模型），不会返回延续令牌。你的代码正常工作 — 无需特殊处理。

带恢复的流式传输：真正的魔法

轮询对于即发即忘的场景没问题，但当你想要实时进度呢？后台响应也支持带内置恢复功能的流式传输。

每个流式更新都携带自己的延续令牌。如果你的连接在流传输中断了，你可以从中断的确切位置恢复：

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // 模拟网络中断
}

// 从中断的确切位置恢复
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

无论客户端发生什么，代理都会继续在服务器端处理。这是内置的容错能力，无需你编写重试逻辑或断路器。

什么时候该真正使用这个

不是每个代理调用都需要后台响应。对于快速完成，你只是在无故增加复杂性。但以下场景是它们大放异彩的地方：

复杂推理任务 — 多步分析、深度研究、任何让推理模型真正思考的内容
长内容生成 — 详细报告、多部分文档、广泛分析
不可靠的网络 — 移动客户端、边缘部署、不稳定的企业 VPN
异步 UX 模式 — 提交任务，去做别的事，回来取结果

对于构建企业应用的 .NET 开发者来说，最后一点特别有趣。想想一个 Blazor 应用，用户请求一个复杂的报告 — 你启动代理任务，显示进度指示器，让他们继续工作。不需要 WebSocket 体操，不需要自定义队列基础设施，只需一个令牌和一个轮询循环。

总结

后台响应现在通过 Microsoft Agent Framework 在 .NET 和 Python 中都可用。如果你构建的代理做的事情比简单的问答更复杂，这值得加入你的工具包。延续令牌模式保持简单的同时解决了一个非常真实的生产问题。

查看完整文档获取完整的 API 参考和更多示例。

从笔记本到生产：用两个命令将 AI 代理部署到 Microsoft Foundry

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

你知道"在我的机器上能跑"和"已部署并正在处理流量"之间的鸿沟吗？对于 AI 代理来说，这个鸿沟一直痛苦地大。你需要配置资源、部署模型、配置身份、设置监控 — 这些都是在任何人能实际调用你的代理之前要做的。

Azure Developer CLI 刚刚把这变成了两个命令的事。

新的 `azd ai agent` 工作流

让我带你看看这实际是什么样子。你有一个 AI 代理项目 — 比如说一个酒店礼宾代理。它在本地运行正常。你想让它在 Microsoft Foundry 上运行。

azd ai agent init
azd up

就这样。两个命令。azd ai agent init 在你的仓库中生成基础设施即代码，azd up 在 Azure 上配置一切并发布你的代理。你会得到一个直接指向 Foundry 门户中你的代理的链接。

底层发生了什么

init 命令在你的仓库中生成真实的、可检查的 Bicep 模板：

一个 Foundry Resource（顶层容器）
一个 Foundry Project（你的代理所在的地方）
模型部署配置（GPT-4o 等）
带有适当 RBAC 角色分配的托管身份
服务映射用的 azure.yaml
带有代理元数据和环境变量的 agent.yaml

关键是：这一切都是你的。它是仓库中的版本化 Bicep。你可以检查它、自定义它，并与你的代理代码一起提交。没有魔法黑盒。

开发内循环

我真正喜欢的是本地开发体验。当你在迭代代理逻辑时，不想每次改变提示词都重新部署：

azd ai agent run

这会在本地启动你的代理。配合 azd ai agent invoke 发送测试提示，你就有了一个紧密的反馈循环。编辑代码、重启、调用、重复。

invoke 命令的路由也很智能 — 当本地代理在运行时，它会自动指向本地。不在运行时，指向远程端点。

实时监控

这是说服我的功能。一旦你的代理部署完成：

azd ai agent monitor --follow

流经你的代理的每个请求和响应都会实时传输到你的终端。对于调试生产问题，这是无价之宝。不用挖 Log Analytics，不用等指标聚合 — 你看到的就是现在正在发生的事情。

完整的命令集

快速参考：

命令	功能
`azd ai agent init`	用 IaC 搭建 Foundry 代理项目
`azd up`	配置 Azure 资源并部署代理
`azd ai agent invoke`	向远程或本地代理发送提示
`azd ai agent run`	在本地运行代理用于开发
`azd ai agent monitor`	从已发布的代理流式传输实时日志
`azd ai agent show`	检查代理健康状态和状态
`azd down`	清理所有 Azure 资源

为什么这对 .NET 开发者重要

虽然公告中的示例是基于 Python 的，但基础设施的故事是语言无关的。你的 .NET 代理得到相同的 Bicep 脚手架、相同的托管身份设置、相同的监控管道。如果你已经在用 azd 部署 .NET Aspire 应用或 Azure 部署，这直接融入你现有的工作流。

AI 代理的部署鸿沟一直是生态系统中最大的摩擦点之一。从一个工作原型到一个具有适当身份、网络和监控的生产端点，不应该需要一周的 DevOps 工作。现在只需要两个命令和几分钟。

总结

azd ai agent 现在可用。如果你一直因为基础设施设置看起来工作量太大而推迟部署 AI 代理，试试看。查看完整教程获取包括前端聊天应用集成在内的完整步骤。

Azure | The .NET Blog

Microsoft Foundry 2026年4月：Foundry Local GA、GPT-5.5、Hyperlight上的CodeAct

Foundry Local正式发布

GPT-5.5

Foundry中的Agent Framework追踪

Hyperlight上的CodeAct（Alpha）

代理监控仪表板（预览）

持续评估自定义评估器（预览）

控制平面中的代理清单

您的本地 MAF 代理刚刚在生产环境中找到了家

Foundry Hosted Agents 实际做什么

代码差异很小

两种协议，一个代理

使用 azd 的部署流程

总结

Foundry Local 1.1：实时转录、Embeddings 和 Responses API

实时音频转录

文本 Embeddings

Responses API

包大小改进

为什么重要

Cosmos DB Shell 现已推出公共预览版 — 并且内置了 MCP 服务器

与其他数据库 CLI 的不同之处

开源基础很重要

三个变得更容易的场景

入门

您的 AI 代理有一个身份问题（这是解决它的模板）

核心问题：身份验证 ≠ 授权

令牌链如何工作

模板部署什么

值得借鉴的设计原则

总结

私有端点、VNet、NSG — Aspire 现在接管网络管理

构建块

在 AppHost 中描述它

为何对实际应用程序重要

总结

Aspire 13.3：Kubernetes 支持、浏览器日志和 Aspireify 技能

Aspireify：代理辅助入门

一流的 Kubernetes 和 AKS 部署

仪表板中的浏览器日志

结构化命令结果

结论

SDD Conference 2026

主题

演讲者

门票和信息

SQL MCP Server 在 Azure App Service 上运行 — 无需容器

什么是 SQL MCP Server？

容器问题（及解决方案）

无需共享 API 密钥的身份验证

部署到 App Service

为什么这对 .NET 开发者很重要

总结

用 Agentic Platform Engineering 消除迁移的重复性工作

输入：contoso-migration

步骤 1：验证与认证

步骤 2：意图提取

步骤 3：服务映射

步骤 4：评审智能体

步骤 5：生成的输出

安全态势对比

与语法转换器的区别

SQL Server 2025作为代理就绪数据库：一个引擎中的安全、备份和MCP

所有数据模型的单一安全模型

统一备份 = 原子恢复

MCP集成：无需手动编写中间件

Azure MCP Server 现在是 .mcpb — 无需任何运行时即可安装

什么是 MCP Bundle？

如何安装

能做什么

开始使用

Azure SDK 2026年4月：AI Foundry 2.0及.NET开发者须知

Azure.AI.Projects 2.0.0 — 有意义的破坏性变更

Cosmos DB Java：关键安全修复（RCE）

.NET的新Provisioning库

GPT-5.5 已来到 Azure Foundry — .NET 开发者需要了解的一切

GPT-5 的演进

真正发生了什么变化

定价

使用 `azd` 的部署流程