Agent-Framework | 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

Handoff 模式：当一个智能体不够用时

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

在某个时刻，每个多智能体系统都会超越一个简单的路由器。第一个信号通常是当一个专业智能体需要提出后续问题时，或者在轮次中途意识到另一个智能体应该继续时。固定管道在那里失败。单次路由器在那里失败。

这正是 Microsoft Agent Framework 中 Handoff 编排模式设计解决的问题。

Handoff 如何工作

开发者声明一个图：这些是智能体，这些是它们之间的边。框架完成其余工作——为每条出边合成一个 handoff 工具并将其注入每个智能体。当智能体决定交出控制权时，它调用该工具。框架强制执行拓扑结构。

三件事使这与简单地让智能体互相调用不同：

共享转录 — 接收智能体看到完整的对话历史。不需要从头开始。
拓扑强制执行 — 智能体只能将控制权交给声明的目标。路由错误在创作时被捕获，而不是在生产中。
自然终止 — 当活跃智能体在没有调用 handoff 工具的情况下结束其轮次时，工作流让位给用户。无需轮询，无需显式退出条件。

最小示例

在 .NET 中，构建 handoff 工作流看起来像这样：

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage 可以发送给任一专家。两个专家都可以发送回 triage。图支持无环，但在需要时支持后向边（“我需要更多信息” → 返回研究）。

何时使用 Handoff（何时不使用）

Handoff 是好的选择，当：

所有权可能在对话中途改变 — 智能体可能意识到自己是错误的专家
后向边很重要 — 可能需要在不重启的情况下重新访问之前的步骤
路由决策是细微的 — handoff 的决定是上下文相关的，最好由模型而不是类型化谓词来做出

不是正确选择，当：

管道是固定且顺序的 — 为此使用 Sequential 工作流
每个步骤都是独立的 — 智能体共享一个只有一个需要的转录只是噪音
需要严格的处理保证 — 模型驱动路由的不确定性不是你想要的

后向边和 Human-in-the-Loop

Handoff 允许的最有趣的形式之一是真正的后向边。智能体可以决定"我没有足够的信息"并路由回研究步骤——不是使用硬编码循环，而是因为模型决定这是正确的决定。

Human-in-the-loop 交互也自然地组合。当专家需要用户输入时，工作流通过默认的轮次循环让位给用户，收集响应，并以完整上下文恢复。智能体从未丢失对话。

总结

Handoff 是那些看起来简单但一旦内化就能实现很多功能的模式之一：分散路由、共享上下文、强制拓扑、自然终止。当你的智能体开始说"实际上，应该由其他人来处理这个"时，这是正确的下一步。

在原始帖子中阅读完整演练：A Tour of the Handoff Orchestration Pattern

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

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

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

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

核心构建块

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

using Microsoft.Agents.AI.Workflows;

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

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

您可以建模：

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

本地开发的内存运行器

入门很快：

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

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

使用Durable Task添加持久性

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

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

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

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

Azure Functions托管

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

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

为什么这很重要

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

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

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

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

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

构建智能体是容易的部分——安全运行它们才是难的部分

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

在 AI 智能体开发中，有一个我开始称为"演示后悔"的模式。智能体在演示中运行良好。然后有人问：如果它调用了错误的工具会怎样？如果它访问了不该访问的数据？谁审计了这个？

Microsoft Agent Framework 为构建和编排提供支持。Agent Governance Toolkit（AGT）覆盖之后的部分——治理、策略执行以及运行时可审计性。

每个项目的实际用途

Microsoft Agent Framework (MAF) 提供编程模型：多智能体工作流、A2A 协议互操作性、中间件钩子、内存以及通过 Foundry Agent Service 进行托管。它在模型输入/输出层面处理内容安全。

Agent Governance Toolkit (AGT) 插入相同的中间件管道以管理操作。每次工具调用、资源访问和智能体间消息在执行前都会根据策略进行评估。亚毫秒级开销。无 sidecar，无代理，无修改的提示词。

智能体操作 --> 策略检查 --> 允许 / 拒绝 --> 审计日志 (< 0.1 ms)

不同层次，完整覆盖，一个管道。

接入只需添加中间件

在 Python 中，AGT 添加到与日志记录或内容过滤器相同的 middleware 参数：

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

在 .NET 中，通过 .Use() 使用相同模式：

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

相同的智能体，相同的编排，相同的工具。AGT 在不修改智能体逻辑的情况下添加治理能力。

你能获得什么

GovernancePolicyMiddleware — 根据声明式策略规则评估每个操作
CapabilityGuardMiddleware — 白名单规定智能体允许调用哪些工具（上面 approve_small_loan 工具故意不在允许列表中）
RogueDetectionMiddleware — 在运行时检测异常行为模式
AuditTrailMiddleware — Merkle 链式审计日志，使每个操作在密码学上防篡改

最后一点对合规性很重要。Merkle 链意味着如果有人修改日志，链就会断裂。审计即证据。

五个行业场景

AGT 代码库包含五个完整的端到端场景：金融服务（贷款专员）、医疗（患者数据）、法律（合同审查）、政府（公民服务）和制造（质量控制）。每个场景都将真实的 MAF 智能体与真实的 AGT 治理中间件配对。

这些不是玩具演示。它们是您在生产中实际需要治理的那类场景。

总结

如果您正在构建涉及真实数据、做出有后果决策或在生产中无人监管运行的智能体——治理不是可选的。MAF + AGT 的组合提供完整的技术栈：用 Agent Framework 构建，用 AGT 治理。

两个项目都是开源的。原文包含完整代码示例的链接。

原文链接：Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 发布：Microsoft Agent Framework for .NET 中的跨平台代理通信

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

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

A2A v1 发布：Microsoft Agent Framework for .NET 中的跨平台代理通信 — A2A 协议刚刚达到 v1.0，.NET 的 A2A Agent（客户端）和 A2A Hosting（服务端）包均已更新。

A2A v1 的实质

A2A 是一个面向 AI 代理的开放互操作协议，由来自 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP 和 ServiceNow 的代表组成的技术指导委员会支持。v1 标签意味着这现在是一个稳定的、可用于生产的标准。实现它的 SDK 和 Agent Framework 包仍处于预览阶段，但协议本身已锁定。

v1 在 v0.3 基础上增加了多租户支持、用于密码学身份的已签名 Agent Cards、改进的安全流程和 Web 对齐架构。

连接远程 A2A 代理

远程 A2A 代理在代码中只是一个 AIAgent — 相同的 RunAsync、相同的流式传输、相同的会话处理：

// 通过 well-known URI 发现
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// 直接配置
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// 流式传输同样适用
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

将代理公开为 A2A 端点

您已构建的任何 AIAgent — 无论是在 Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic 还是 AWS Bedrock 上 — 都可以在 ASP.NET Core 中用两行代码公开为 A2A 端点：

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

代理卡片会自动在 /.well-known/agent-card.json 处提供。

实际意义

稳定的 v1 协议意味着您可以将 .NET 代理与用 Python、Java 或任何其他语言构建的代理连接，而无需担心破坏性更改。已签名 Agent Cards 中的密码学身份也为代理间的信任验证提供了基础。

有关完整的更改日志和从 v0.3 的迁移说明，请参阅完整文章。

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博客的完整文章获取更深入的介绍。

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");

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

你的 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
需要数据主权？ → 带数据库后端的客户端管理型
只是简单聊天机器人？ → 服务管理型线性即可

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

.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示例开始动手吧。

构建不像黑盒的实时多智能体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协议仓库以深入了解。

Microsoft Agent Framework 正式发布 1.0 — 这些才是 .NET 开发者真正需要关注的

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

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

如果你一直在关注 Agent Framework 从早期 Semantic Kernel 和 AutoGen 时代走来的历程，这次的消息意义重大。Microsoft Agent Framework 刚刚发布了 1.0 版本 — 生产就绪、API 稳定、长期支持承诺。它同时支持 .NET 和 Python，并且真正可以承载实际工作负载。

让我跳过公告的噪音，专注于你用 .NET 构建 AI 驱动应用时真正重要的内容。

简短版本

Agent Framework 1.0 将之前的 Semantic Kernel 和 AutoGen 统一为一个开源 SDK。一个代理抽象。一个编排引擎。多个 AI 提供商。如果你之前一直在 Semantic Kernel（企业模式）和 AutoGen（研究级多代理工作流）之间来回切换，现在可以停了。这就是那个唯一的 SDK。

入门简单得几乎不公平

这是一个在 .NET 中运行的代理：

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

就这些。几行代码，你就有了一个在 Azure Foundry 上运行的 AI 代理。Python 的等效代码同样简洁。随着需求增长，逐步添加函数工具、多轮对话和流式输出 — API 表面会平稳地扩展，不会变得奇怪。

多代理编排 — 这才是真正的核心

单个代理对演示来说够了，但生产场景通常需要协调。Agent Framework 1.0 附带了经过实战考验的编排模式，直接来自 Microsoft Research 和 AutoGen：

顺序执行 — 代理按顺序处理（写手 → 审核 → 编辑）
并发执行 — 并行分发给多个代理，汇聚结果
移交 — 一个代理根据意图委托给另一个代理
群组聊天 — 多个代理讨论并收敛到一个解决方案
Magentic-One — 来自 MSR 的研究级多代理模式

所有这些都支持流式处理、检查点、人机回路审批以及暂停/恢复。检查点部分至关重要 — 长时间运行的工作流在进程重启后依然可以恢复。对于我们这些用 Azure Functions 构建过持久工作流的 .NET 开发者来说，这感觉很熟悉。

最重要的功能

以下是我认为值得了解的要点：

中间件钩子。 你知道 ASP.NET Core 有中间件管道吗？同样的概念，但用于代理执行。拦截每个阶段 — 添加内容安全、日志记录、合规策略 — 而无需触碰代理的提示词。这就是让代理达到企业级标准的方式。

可插拔内存。 对话历史、持久键值状态、基于向量的检索。选择你的后端：Foundry Agent Service、Mem0、Redis、Neo4j，或者自己实现。内存是将无状态的 LLM 调用变成真正能记住上下文的代理的关键。

声明式 YAML 代理。 在版本控制的 YAML 文件中定义代理的指令、工具、内存和编排拓扑。通过单个 API 调用加载和运行。这对于想要在不重新部署代码的情况下迭代代理行为的团队来说是颠覆性的。

A2A 和 MCP 支持。 MCP（Model Context Protocol）让代理能够动态发现和调用外部工具。A2A（Agent-to-Agent 协议）实现跨运行时协作 — 你的 .NET 代理可以与其他框架中运行的代理进行协调。A2A 1.0 支持即将推出。

值得关注的预览功能

1.0 中有些功能以预览形式发布 — 功能可用但 API 可能会演进：

DevUI — 一个基于浏览器的本地调试器，用于实时可视化代理执行、消息流和工具调用。可以把它想象成 Application Insights，但用于代理推理。
GitHub Copilot SDK 和 Claude Code SDK — 直接从编排代码中使用 Copilot 或 Claude 作为代理工具。在同一工作流中将编程代理与其他代理组合在一起。
Agent Harness — 一个可定制的本地运行时，为代理提供对 shell、文件系统和消息循环的访问。可以理解为编码代理和自动化模式。
Skills — 可复用的领域能力包，为代理提供开箱即用的结构化能力。

从 Semantic Kernel 或 AutoGen 迁移

如果你有现有的 Semantic Kernel 或 AutoGen 代码，有专门的迁移助手可以分析你的代码并生成逐步迁移计划。Semantic Kernel 迁移指南和 AutoGen 迁移指南会引导你完成所有步骤。

如果你一直在使用 RC 包，升级到 1.0 只需更改版本号。

总结

Agent Framework 1.0 是企业团队一直在等待的生产里程碑。稳定的 API、多提供商支持、真正能在大规模下运行的编排模式，以及从 Semantic Kernel 和 AutoGen 的迁移路径。

该框架已在 GitHub 上完全开源，你今天就可以通过 dotnet add package Microsoft.Agents.AI 开始使用。查看快速入门指南和示例来动手实践。

如果你一直在等待"可以安全用于生产"的信号 — 就是现在。

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 参考和更多示例。

Agent-Framework | 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）

代理监控仪表板（预览）

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

控制平面中的代理清单

Handoff 模式：当一个智能体不够用时

Handoff 如何工作

最小示例

何时使用 Handoff（何时不使用）

后向边和 Human-in-the-Loop

总结

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

核心构建块

本地开发的内存运行器

使用Durable Task添加持久性

Azure Functions托管

为什么这很重要

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

Foundry Hosted Agents 实际做什么

代码差异很小

两种协议，一个代理

使用 azd 的部署流程

总结

构建智能体是容易的部分——安全运行它们才是难的部分

每个项目的实际用途

接入只需添加中间件

你能获得什么

五个行业场景

总结

A2A v1 发布：Microsoft Agent Framework for .NET 中的跨平台代理通信

A2A v1 的实质

连接远程 A2A 代理

将代理公开为 A2A 端点

实际意义

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

什么是CodeAct？

安全机制：Hyperlight微型虚拟机

最小配置

何时使用CodeAct（何时不用）

立即尝试

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

GPT-5 的演进

真正发生了什么变化

定价

为什么 Foundry 很重要

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

两种基本模式

Agent Framework 如何抽象这一切

提供商快速参考

如何选择

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

基于文件的技能：起点

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

内联技能：快速桥接

脚本审批：人在回路中

为什么这种组合很重要

总结

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

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

交接拓扑才是真正的主角

真正有效的人机协作

接入出奇地简单

我的看法

总结

Microsoft Agent Framework 正式发布 1.0 — 这些才是 .NET 开发者真正需要关注的

简短版本

入门简单得几乎不公平

多代理编排 — 这才是真正的核心

最重要的功能

值得关注的预览功能

从 Semantic Kernel 或 AutoGen 迁移

总结

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

阻塞调用的问题

延续令牌如何工作

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

使用 `azd` 的部署流程