Foundry | 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

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的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上的最佳实践指南将为你节省真正的调试时间。

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

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

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

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

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

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)

如果你从 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 公告。

从笔记本到生产：用两个命令将 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 代理，试试看。查看完整教程获取包括前端聊天应用集成在内的完整步骤。

Foundry | 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

包大小改进

为什么重要

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

GPT-5 的演进

真正发生了什么变化

定价

为什么 Foundry 很重要

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

o4-mini的全球训练

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

RFT数据格式的陷阱

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

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

Foundry Agent Service已准备好投入生产

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

SDK终于稳定了

Fireworks AI将开放模型引入Azure

其他亮点

总结

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

为什么这种组合有意义

身份验证选项

设置方法

我的看法

总结

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

这里到底发生了什么

配置

控制代理可以访问什么

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

更大的 MCP 图景

总结

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

构建在 Responses API 之上

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

MCP 认证做对了

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

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

六个新区域支持托管代理

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

总结

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

新的 azd ai agent 工作流

底层发生了什么

开发内循环

实时监控

完整的命令集

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

总结

使用 `azd` 的部署流程

新的 `azd ai agent` 工作流