Agents | The .NET Blog

NL2SQL 是智能体时代的 SQL 注入

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

NL2SQL 有一个听起来很完美的推介版本：用户用自然语言提问，智能体生成 SQL，数据返回。更少的界面，更少的查询，更少的代码。简单。

然后你再多想五分钟。

演示中没人提的问题

模式（Schema）不是为了解释事物而设计的。 晦涩的表名、不一致的列名、在没有额外谓词的情况下语义上无效的技术有效关系——这在企业数据库中很常见。这些不是 bug，只是业务变更积累的历史。但当你要求模型从一个并非为传达意图而设计的模式中推断意图时，模型还是会尝试。它不会放弃。它会生成最佳查询并自信地返回结果。

模型是非确定性的。 对同一个数据库问同一个问题两次，你可能会得到不同的 SQL。模型在计算概率，上下文中的细微变化会产生不同的输出。你无法通过测试获得智能体总是生成正确查询的保证。

用户审查无法扩展。 “执行前只需审查每个查询"听起来很安全。但这假设用户既是数据模型又是 SQL 的专家——恰恰是那些不需要自然语言界面的人。它还引入了认知过载和新型确认偏差，被查询复杂性压倒的用户会批准无效查询而不是去调查它们。

然后还有注入。 在传统 SQL 开发中，参数化解决了注入问题，因为用户输入填充的是参数，而不是 SQL 结构。在 NL2SQL 中，模型本身生成 SQL。提示词、模式上下文、对话历史和检索的数据都会影响执行的内容。如果有人精心设计一个改变模型生成内容的提示，那就是注入——不是在参数级别，而是在查询生成级别。与 DROP TABLE（明显、可恢复）不同，NL2SQL 注入会产生在没有可见错误的情况下返回错误结果的查询。业务决策基于错误数据做出。

SQL MCP Server 究竟解决了什么

这里文章提出了最有用的实用观点。SQL MPC Server 不是给智能体任意的模式访问权限并期待最好的结果，而是暴露了一个建立在 Data API builder 之上的精心策划的 API 表面。

差异很重要：智能体不生成 SQL。它调用返回预定义结果形状的命名端点。SQL 由开发人员编写一次，是确定性的。智能体的非确定性被限制在选择调用哪个端点，而不是组合任意查询。

这类似于参数化在传统应用模型中对 SQL 注入所做的——消除了从不受信任的输入构建任意查询的能力。

正确的问题

这篇文章不是说"永远不要使用 NL2SQL”。它说：对在哪里应用它以及暴露什么要有意识。对于在受控环境中、具有有限范围模式和只读访问权限的探索性分析，NL2SQL 可能没问题。对于业务决策依赖于结果的生产系统，经过精心策划的 API 层要安全得多。

说实话：有些问题确实更适合用命名端点后面的结构化查询来解决，而不是自然语言到 SQL。SQL MCP Server 为你提供了这个选项，而不必完全放弃智能体界面。

原文链接：Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

您的 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

Agent Framework中的CodeAct：如何将智能体延迟减半

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

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

在每个智能体项目中，都会有这样一个时刻：你查看追踪信息，心想：“为什么这要花这么长时间？“模型没问题，工具也能运行，但为了获得一个本可一步计算出的结果，却需要七次往返请求。

这正是CodeAct解决的问题——Agent Framework团队刚刚发布了Alpha支持，通过新的agent-framework-hyperlight包实现。

什么是CodeAct？

CodeAct模式优雅而简单：不再给模型一个工具列表让它逐一调用，而是给它一个单一的execute_code工具，让它将整个计划表达为一个简短的Python程序。智能体只需编写一次代码，沙盒执行它，你就能得到一个统一的结果。

方式	时间	令牌
传统方式	27.81秒	6,890
CodeAct	13.23秒	2,489
提升	52.4%	63.9%

安全机制：Hyperlight微型虚拟机

agent-framework-hyperlight包使用Hyperlight微型虚拟机。每次execute_code调用都在一个全新的微型VM中运行。启动时间以毫秒计算。隔离几乎是免费的。

你的工具仍在主机上运行。模型生成的粘合代码在沙盒中运行。这是正确的分工。

最小配置

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

何时使用CodeAct（何时不用）

使用CodeAct的情况：

任务需要链接许多小型工具调用（查询、连接、计算）
延迟和令牌成本很重要
需要对模型生成的代码进行强隔离

继续使用传统工具调用的情况：

智能体每轮只进行一两次工具调用
每次调用都有需要单独审批的副作用
工具描述稀少或模糊

立即尝试

pip install agent-framework-hyperlight --pre

请查阅Agent Framework博客的完整文章获取更深入的介绍。

你的 Agent 在哪里记住事情？聊天历史存储实践指南

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

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

在构建 AI Agent 时，你把大部分精力花在模型、工具和提示词上。对话历史存储在哪里这个问题看起来像是实现细节——但实际上是你将做出的最重要的架构决策之一。

它决定了用户能否分叉对话、撤销回答、重启后恢复会话，以及数据是否会离开你的基础设施。Agent Framework 团队发布了一篇深度分析。

两种基本模式

服务管理型：AI 服务存储对话状态。你的应用保持一个引用，服务自动在每次请求中包含相关历史记录。更简单，控制更少。

客户端管理型：你的应用维护完整历史记录，并在每次请求时发送相关消息。服务无状态。你控制一切。

Agent Framework 如何抽象这一切

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("我叫 Alice。", session);
var second = await agent.RunAsync("我叫什么名字？", session);

session = agent.create_session()
first = await agent.run("我叫 Alice。", session=session)
second = await agent.run("我叫什么名字？", session=session)

Session 处理底层差异。无论切换什么提供商，应用代码不变。

提供商快速参考

提供商	存储位置	模式	压缩
OpenAI/Azure Chat Completions	客户端	N/A	你
Foundry Agent Service	服务端	线性	服务端
Responses API（默认）	服务端	分叉型	服务端
Anthropic Claude, Ollama	客户端	N/A	你

如何选择

需要分叉对话或"撤销"？ → 服务管理型 Responses API
需要数据主权？ → 带数据库后端的客户端管理型
只是简单聊天机器人？ → 服务管理型线性即可

阅读完整文章了解完整决策树。

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原生设计意味着它可以与你已经在构建的工具配合使用。查阅官方公告了解详情。

VS Code 1.117：Agent 拥有了自己的 Git 分支，我举双手赞成

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

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

“AI 助手"和"AI 队友"之间的界限越来越模糊。VS Code 1.117 刚刚发布，完整的发行说明内容丰富，但核心很明确：Agent 正在成为你开发工作流中的一等公民。

以下是真正重要的内容。

Autopilot 模式终于能记住你的偏好了

以前，你每次开始新会话都得重新启用 Autopilot。很烦。现在你的权限模式会在会话之间持久化，你还可以配置默认值。

Agent Host 支持三种会话配置：

Default — 工具在运行前会请求确认
Bypass — 自动批准一切
Autopilot — 完全自主，自己回答问题并继续执行

如果你正在搭建一个带有迁移、Docker 和 CI 的新 .NET 项目——设置一次 Autopilot 就行了。这个偏好会一直保持。

Agent 会话的 worktree 和 git 隔离

这是重头戏。Agent 会话现在支持完整的 worktree 和 git 隔离。这意味着当一个 Agent 处理任务时，它会获得自己的分支和工作目录。你的主分支完全不受影响。

更好的是——Copilot CLI 会为这些 worktree 会话生成有意义的分支名称。不再是 agent-session-abc123。你会得到一个真正描述 Agent 正在做什么的名称。

对于管理多个功能分支或在长时间脚手架任务运行期间修复 bug 的 .NET 开发者来说，这是一个游戏规则的改变。你可以让一个 Agent 在一个 worktree 中构建 API 控制器，同时你在另一个 worktree 中调试服务层问题。没有冲突。没有 stash。没有混乱。

子 Agent 和 Agent 团队

Agent Host Protocol 现在支持子 Agent。一个 Agent 可以启动其他 Agent 来处理任务的各个部分。把它想象成委派——你的主 Agent 负责协调，专门的 Agent 处理各个部分。

这还处于早期阶段，但对 .NET 工作流的潜力显而易见。想象一下，一个 Agent 处理你的 EF Core 迁移，另一个设置你的集成测试。我们还没有完全到达那里，但协议支持现在落地意味着工具很快就会跟上。

Agent 发送输入时终端输出自动包含

虽小但有意义。当 Agent 向终端发送输入时，终端输出现在会自动包含在上下文中。以前，Agent 需要额外的一个回合才能读取发生了什么。

如果你曾经看到一个 Agent 运行 dotnet build，失败了，然后又需要一次往返才能看到错误——这种摩擦消失了。它立即看到输出并做出反应。

macOS 上的 Agents 应用自动更新

macOS 上的独立 Agents 应用现在可以自动更新了。不再需要手动下载新版本。它会自动保持最新。

值得了解的小改进

package.json 悬停提示现在同时显示已安装版本和最新可用版本。如果你在 .NET 项目旁边管理 npm 工具，这很有用。
JSDoc 注释中的图片在悬停和补全中正确渲染。
Copilot CLI 会话现在会显示是由 VS Code 还是外部创建的——当你在终端之间切换时很方便。
Copilot CLI、Claude Code 和 Gemini CLI 被识别为 shell 类型。编辑器知道你在运行什么。

总结

VS Code 1.117 不是一个花哨的功能堆砌。它是基础设施。Worktree 隔离、持久化权限、子 Agent 协议——这些是构建一个工作流的基石，在这个工作流中，Agent 可以处理真实的并行任务而不会干扰你的代码。

如果你正在用 .NET 开发，还没有尝试 Agent 工作流，说实话，现在就是开始的时候。

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仓库获取可运行的示例。

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 上构建真实智能工作流的真实团队做好准备。如果你一直在等待"企业就绪"的信号——就是现在。

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实现的开放模型推理 — 该平台已准备好应对严肃的工作负载。

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

VS Code 1.116 — Agents应用获得键盘导航和文件上下文补全

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

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

VS Code 1.116是2026年4月的版本，虽然比最近的一些更新更轻量，但变化是有针对性且有意义的 — 尤其是如果你每天都在使用Agents应用。

以下是基于官方发行说明的更新内容。

Agents应用改进

Agents应用继续通过可用性优化不断成熟，这些改进在日常工作流中产生了真正的影响：

专属快捷键 — 现在你可以用专属命令和键盘快捷键来聚焦更改视图、更改中的文件树，以及聊天自定义视图。如果你之前一直在Agents应用中到处点击来导航，这带来了完全由键盘驱动的工作流。

辅助功能帮助对话框 — 在聊天输入框中按Alt+F1现在会打开一个辅助功能帮助对话框，显示可用的命令和快捷键。屏幕阅读器用户还可以控制播报的详细程度。良好的辅助功能让每个人受益。

文件上下文补全 — 在Agents应用聊天中输入#来触发限定在当前工作区范围内的文件上下文补全。这是那些加速每次交互的小型生活质量改进之一 — 不再需要在引用代码时输入完整的文件路径。

CSS `@import`链接解析

前端开发者的好消息：VS Code现在可以解析使用node_modules路径的CSS @import引用。当使用打包工具时，你可以通过Ctrl+点击跳转到像@import "some-module/style.css"这样的导入。虽小但消除了CSS工作流中的一个摩擦点。

总结

VS Code 1.116是关于改进的 — 让Agents应用更易导航、更易访问、更友好的键盘操作。如果你在Agents应用中花费大量时间（我猜很多人都是如此），这些变化会累积起来。

查看完整发行说明获取完整列表。

智能体平台工程正在成为现实 — 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代理——这次更新值得关注。

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

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)

如果你从 azure-ai-agents 包迁移过来，代理现在是 azure-ai-projects 中 AIProjectClient 的一等操作。移除独立依赖，使用 get_openai_client() 来驱动响应。

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

这是解锁企业采用的功能。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 公告。

Agents | The .NET Blog

NL2SQL 是智能体时代的 SQL 注入

演示中没人提的问题

SQL MCP Server 究竟解决了什么

正确的问题

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

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

令牌链如何工作

模板部署什么

值得借鉴的设计原则

总结

Agent Framework中的CodeAct：如何将智能体延迟减半

什么是CodeAct？

安全机制：Hyperlight微型虚拟机

最小配置

何时使用CodeAct（何时不用）

立即尝试

你的 Agent 在哪里记住事情？聊天历史存储实践指南

两种基本模式

Agent Framework 如何抽象这一切

提供商快速参考

如何选择

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

什么是Toolbox

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

实践示例

不受限于Foundry Agents

为什么现在重要

总结

VS Code 1.117：Agent 拥有了自己的 Git 分支，我举双手赞成

Autopilot 模式终于能记住你的偏好了

Agent 会话的 worktree 和 git 隔离

子 Agent 和 Agent 团队

Agent 发送输入时终端输出自动包含

macOS 上的 Agents 应用自动更新

值得了解的小改进

总结

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

六种选项速览

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

部署真的很简单

内置对话管理

我的决策框架

总结

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

什么是 Azure MCP Server？

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

安全加固

你可以在哪里使用它？

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

开始使用

总结

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

Foundry Agent Service已准备好投入生产

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

SDK终于稳定了

Fireworks AI将开放模型引入Azure

其他亮点

总结

VS Code 1.116 — Agents应用获得键盘导航和文件上下文补全

Agents应用改进

CSS @import链接解析

总结

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

Git-APE究竟做什么

为什么这很重要

我的看法

总结

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

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

GitHub Copilot为你配置azd项目

Container App Jobs和部署改进

开发体验改进

总结

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

构建在 Responses API 之上

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

MCP 认证做对了

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

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

CSS `@import`链接解析