TL;DR：2026 年 4 月 3 日，Microsoft Agent Framework（MAF）1.0 正式 GA。随着 Semantic Kernel 1.77.0 版本合并 PR #13852 全面完成向 MAF 的迁移，微软 .NET AI 技术栈迎来了自 Semantic Kernel 诞生以来最大的一次架构重组。本文从技术趋势深度解读视角，解析 MAF 1.0 的五层架构设计、核心理念演化、关键 API 差异、开放协议集成以及 BUILD 2026 最新动态，为 .NET 开发者和 AI 技术从业者提供一份完整的迁移认知地图。
一、一个时代的谢幕，一个时代的开启
2026 年 4 月 3 日，微软正式发布了 Microsoft Agent Framework 1.0 General Availability（GA） 版本 (Microsoft Developer Blogs) 。这不是一次普通的 SDK 更新，而是微软在 AI Agent 领域三年布局的集大成之作——它宣告了 AutoGen 和 Semantic Kernel 这两个累计收获 75,000+ GitHub Stars 的项目正式完成历史使命，将其精华融合为一个统一、生产就绪、跨语言（.NET + Python）的企业级 Agent 开发平台 (digitalapplied.com) 。
紧随其后，Semantic Kernel 1.77.0 版本合并了由开发者 @rogerbarreto 提交的 PR #13852——.NET: Semantic Kernel -> Agent Framework - Migration/Samples Update，完成了底层代码和示例向 MAF 1.0 规范的全面对齐 (Github) 。这一动作标志着 SK 作为独立 Agent 开发框架的时代正式落幕，其 Agent 与编排相关的能力已完整迁移至 MAF 生态。
核心信号：AutoGen 和 Semantic Kernel 已于 2025 年 10 月同步进入维护模式（maintenance mode）——微软将继续修复关键漏洞和安全问题，但不再增加重大新功能 (cloudsummit.eu) 。对于企业开发者而言，这意味着所有新功能、新协议支持和新编排能力都将在 MAF 上迭代，继续投资 SK 的 Agent 相关代码将产生技术债务。
二、MAF 1.0 的五层架构：SK 不是被替代，而是被重新定位
理解 MAF 1.0 的最佳入口是其五层架构设计。这不是简单的"新框架取代旧框架"，而是一次彻底的技术栈重组——Semantic Kernel 从"万能的 AI SDK"被重新定位为基础能力支撑层，其上生长出全新的 Agent 抽象和 Workflow 编排引擎 (博客园) 。
| 层级 | 组件 | 核心职责 |
|---|---|---|
| L5 | Orchestration & Workflow Layer | 图结构工作流引擎，提供确定性、可检查点的多智能体编排 (Microsoft Developer Blogs) |
| L4 | Agent Layer (AIAgent) | 厂商中立的统一智能体抽象，管理指令、工具、会话状态和中间件管道 (Microsoft Learn) |
| L3 | Kernel Layer (Semantic Kernel) | 基础能力支撑层，提供插件、过滤器、提示词模板和向量存储集成 (digitalapplied.com) |
| L2 | Abstractions Interface (MEAI) | 标准抽象层，定义 IChatClient 和 IEmbeddingGenerator 等通用接口 (Microsoft Developer Blogs) |
| L1 | Service Connectors | 原生服务连接器：Azure OpenAI、OpenAI、Anthropic Claude、Amazon Bedrock、Google Gemini、Ollama、Microsoft Foundry (Flowtivity) |
关键洞察：SK 的核心价值（插件系统、提示词模板、向量存储）在 MAF 架构中得到了完整保留，但 SK 的 Agent 抽象（ChatCompletionAgent、AgentGroupChat 等）已被全新的 AIAgent 和 WorkflowBuilder 所取代 (Microsoft Learn) 。这种"分层继承、上层重构"的策略，使得现有 SK 用户可以渐进式迁移，而非一次性重写。
三、核心理念跃迁：从 "Kernel/Plugin" 到 "Agent/Workflow"
3.1 传统 SK 的设计痛点
在 Semantic Kernel 的体系中，构建多智能体系统需要开发者编写大量繁琐的管道代码。以最常见的"任务分配 → 审核 → 驳回/通过"流程为例，开发者必须手动实现 SelectionStrategy、TerminationStrategy，并自行维护对话历史上下文的传递 (博客园) 。
更深层的问题在于职责耦合：在 SK 中，智能体的"推理能力"和"执行策略"被混在同一个 Kernel 对象中。开发者被迫在提示词工程中编写路由逻辑，导致业务逻辑极易失控——提示词中的指令与代码中的控制流相互交织，既难以测试，也无法复用 (博客园) 。
3.2 MAF 的职责分离设计
MAF 1.0 引入了彻底的职责分离（Separation of Responsibilities） 理念，这是整个框架最具革命性的设计决策 (Microsoft Developer Blogs) ：
| 维度 | 职责定位 | 实现方式 |
|---|---|---|
| Agent（智能体） | 推理与理解（Reasoning & Interpretation） | 利用 LLM 解释输入，自主决定调用哪些工具，返回结果 (Microsoft Developer Blogs) |
| Workflow（工作流） | 执行策略与控制流（Execution Policy & Control Flow） | 通过 C# 代码级有向图定义执行边界、顺序、重试和超时 (Microsoft Developer Blogs) |
这一转变使得多智能体编排变得极其直观。在旧版 SK 中需要数百行繁琐编排代码的"序列协作模式"，在 MAF 中仅需通过 AgentWorkflowBuilder.BuildSequential() 的三行代码即可声明完成 (博客园) 。
本质变化：SK 时代，Agent 的"智能"和"流程"混在一起；MAF 时代，Agent 只负责"想"，Workflow 只负责"走"。
四、API 映射与代码对比：迁移究竟要改变什么
4.1 核心抽象对比
| 维度 | Semantic Kernel Agents (旧) | Microsoft Agent Framework 1.0 (新) |
|---|---|---|
| 基础抽象 | 强绑定的 ChatCompletionAgent、OpenAIAssistantAgent 等具体类 (Microsoft Learn) |
厂商中立的统一 AIAgent，由通用 IChatClient 转换而来 (devleader.ca) |
| 工具注册 | KernelPlugin → Kernel → Agent 三级嵌套 (Microsoft Learn) |
AIFunctionFactory.Create() 直接注册，零嵌套 (Microsoft Learn) |
| 会话状态 | 隐式线程状态，手动管理服务端线程 ID (devleader.ca) | 显式 AgentSession 对象，自动持久化 (devleader.ca) |
| 调用方法 | .InvokeAsync() 返回 ChatMessageContent 流 (devleader.ca) |
.RunAsync() 返回 AgentResponse；.RunStreamingAsync() 返回 AgentResponseUpdate (devleader.ca) |
| 编排引擎 | InProcessRuntime 或自定义复杂管道 (博客园) |
声明式 WorkflowBuilder + 预置多智能体构建器 (Microsoft Developer Blogs) |
4.2 迁移前后代码对比
场景 A：智能体创建与工具关联
// ========== Before: Semantic Kernel ==========
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;// 1. 创建 Kernel 并添加连接器
Kernel kernel = Kernel.CreateBuilder().AddAzureOpenAIChatCompletion(deploymentName, endpoint, apiKey).Build();// 2. 将类注册为 KernelPlugin
kernel.Plugins.AddFromType<SupportTools>();// 3. 实例化特定厂商的 Agent
ChatCompletionAgent agent = new()
{Name = "SupportAssistant",Instructions = "You are a helpful support agent.",Kernel = kernel
};
// ========== After: Microsoft Agent Framework 1.0 ==========
using Microsoft.Extensions.AI;
using Microsoft.Agents.AI;// 1. 获取 IChatClient 抽象
IChatClient chatClient = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential()).GetChatClient(deploymentName).AsIChatClient();// 2. 一键生成 AIAgent，直接注入 standalone 工具
AIAgent agent = chatClient.AsAIAgent(name: "SupportAssistant",instructions: "You are a helpful support agent.",tools: [AIFunctionFactory.Create(SupportTools.SearchKnowledgeBase),AIFunctionFactory.Create(SupportTools.CreateTicket)]
);
场景 B：会话管理与流式调用
// ========== Before: Semantic Kernel ==========
var chat = new AgentGroupChat(agent);
chat.AddChatMessage(new ChatMessageContent(AuthorRole.User, userInput));await foreach (ChatMessageContent message in chat.InvokeAsync())
{Console.WriteLine(message.Content);
}
// ========== After: Microsoft Agent Framework 1.0 ==========
// 1. 显式创建支持持久化的会话
AgentSession session = await agent.CreateSessionAsync();// 2. 执行流式运行，接收丰富元数据
await foreach (AgentResponseUpdate update in agent.RunStreamingAsync(userInput, session))
{if (update.Text is not null){Console.Write(update.Text);}
}// 3. 提取持久化 ConversationId 用于服务重启恢复
string savedConversationId = session.ConversationId;
关键体会：MAF 的代码更少、层级更扁平、职责更清晰。Kernel 和 KernelBuilder 的消失意味着更少的概念负担，而 IChatClient 的引入则带来了真正的厂商解耦——切换模型提供方只需修改客户端配置，Agent 代码完全不变 (devleader.ca) 。
五、图编排与持久化：WorkflowBuilder + DurableTask
5.1 Executor：工作流的基本计算单元
MAF 工作流引擎的核心是 Executor<TInput, TOutput>，每个 Executor 都有严格的输入/输出类型约束，并在编译期通过泛型进行类型安全校验 (Microsoft Developer Blogs) ：
public class OrderLookup : Executor<OrderRequest, OrderDetails>
{public OrderLookup() : base("OrderLookup") { }public override async ValueTask<OrderDetails> HandleAsync(OrderRequest message,IWorkflowContext context,CancellationToken cancellationToken = default){return await FetchOrderDetailsAsync(message.OrderId);}
}
5.2 WorkflowBuilder：声明式图编排
利用 WorkflowBuilder，开发者可以像搭积木一样构建复杂的工作流拓扑 (Microsoft Developer Blogs) ：
AddFanOutEdge：将上游输出并发广播给多个下游 Executor（并行执行）AddFanInBarrierEdge：创建栅栏（Barrier），挂起后续流直到所有并行分支完成AsAIAgent()：将底层 AIAgent 无缝包装为图中的 Executor
5.3 DurableTask：长运行流程的持久化保障
生产环境的多智能体流程往往需要跨越数小时甚至数天（如等待人工审批）。MAF 通过 Microsoft.Agents.AI.DurableTask 包，使工作流无需修改任何图拓扑代码，即可直接升级为分布式、抗进程崩溃的持久化工作流 (Microsoft Developer Blogs) ：
| 特性 | 说明 |
|---|---|
| 自动检查点（Checkpointing） | 每执行完一个 Executor，状态和流转数据自动快照持久化 (Ravikanth Chaganti) |
| 水合恢复（Hydration） | 主机崩溃或重启后，引擎自动恢复至上一步安全状态 (Microsoft Developer Blogs) |
| Durable Task Scheduler (DTS) | 负责状态调度与历史轨迹管理，支持本地 Docker 模拟器 (Microsoft Developer Blogs) |
六、开放协议原生集成：MCP + A2A
MAF 1.0 在协议层面的设计体现了微软对 Agent 生态开放性的长期承诺。两大核心协议均作为一等公民内建：
6.1 MCP（Model Context Protocol）
MCP 是由 Anthropic 推出的开放标准，用于标准化 LLM 与外部工具/数据源的连接方式。MAF 1.0 提供原生 MCP 客户端集成，使智能体能够动态发现和调用外部工具 (Microsoft Learn) 。
截至 2026 年，MCP 已获得 OpenAI、Google DeepMind、Microsoft 等主要厂商的广泛采纳，正在成为 AI-Agent 工具连接的事实标准 (arXiv.org) 。
6.2 A2A 1.0（Agent-to-Agent Protocol）
A2A v1.0 于 2026 年 3 月发布稳定规范，是首个生产就绪的跨运行时智能体通信标准。MAF 中的 A2A 支持设计精妙——interop comes for free (Microsoft Developer Blogs) ：
using A2A;
using Microsoft.Agents.AI;// 解析远程 Agent 的 AgentCard 并创建 AIAgent
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();// 像使用本地 Agent 一样使用远程 Agent
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));
远程 A2A Agent 在代码中就是普通的 AIAgent——同样的 RunAsync、同样的流式处理、同样的会话管理。你可以将本地 Azure OpenAI Agent 无缝替换为远程 A2A Agent，而无需修改调用代码 (Microsoft Developer Blogs) 。
截至 2026 年 4 月，A2A 协议已有 150+ 组织参与，覆盖金融、供应链和 IT 运维等生产场景 (byteiota.com) 。
七、BUILD 2026：从框架到平台的跃迁
2026 年 6 月的 Microsoft BUILD 大会是 MAF 生态的又一重要里程碑。在 1.0 GA 的基础上，微软发布了四大平台级能力 (Microsoft Developer Blogs) ：
7.1 Agent Harness：生产模式内置
Agent Harness 是模型推理与真实执行之间的桥梁层，通过 chatClient.AsHarnessAgent() 一行代码即可激活 (Microsoft Developer Blogs) ：
| 内置能力 | 功能描述 |
|---|---|
| Automatic context compaction | 监控 Token 使用，在长工具调用链中自动压缩历史，防止上下文溢出 (Microsoft Developer Blogs) |
| FileMemoryProvider | 会话级持久化笔记，跨轮次保留学习结果 (Microsoft Developer Blogs) |
| TodoProvider | 多步骤任务追踪（add/complete/remove/list） (Microsoft Developer Blogs) |
| AgentModeProvider | 支持 "plan" vs "execute" 两种操作模式 (Microsoft Developer Blogs) |
| BackgroundAgentsProvider | 并行子 Agent 的扇出编排 (Microsoft Developer Blogs) |
| ToolApprovalAgent | 敏感工具调用的"不再询问"审批规则 (htek.dev) |
| OpenTelemetryAgent | 自动 Semantic Conventions 链路追踪 (htek.dev) |
7.2 CodeAct：更少的模型轮次，更低的延迟
CodeAct 是 BUILD 2026 最具技术突破性的发布。它改变了 Agent 调用工具的方式——不再一步步选择工具、等待、再选择，而是让模型编写一个简短的 Python 脚本，通过 call_tool(...) 一次性调用所有需要的工具，在 Hyperlight microVM 沙箱中执行并返回汇总结果 (Microsoft Developer Blogs) 。
在代表性多步骤工作负载（跨多个用户计算订单总计，涉及数十次工具调用）中，CodeAct 实现了：
| 指标 | 传统方式 | CodeAct | 提升 |
|---|---|---|---|
| 时间 | 27.81s | 13.23s | -52.4% |
| Token 消耗 | 6,890 | 2,489 | -63.9% |
7.3 Foundry Hosted Agents：从本地到生产
Hosted Agents 提供了一条从本地 MAF Agent 到生产部署的最短路径——scale-to-zero 计费、每会话 VM 隔离沙箱、持久化文件系统、内置 OpenTelemetry 追踪 (Microsoft Developer Blogs) 。
7.4 多智能体 Handoff 编排 1.0
Handoff 模式专为"路由 → 专家 → 可能的回退/转接"场景设计。开发者声明 Agent 和它们之间的有向边，框架自动注入 handoff 工具 (Microsoft Developer Blogs) ：
AIAgent triage = chatClient.AsAIAgent(instructions: "You receive a user request and route it to the right specialist.",name: "Triage");
AIAgent billing = chatClient.AsAIAgent(instructions: "You handle billing questions.", name: "Billing");
AIAgent tech = chatClient.AsAIAgent(instructions: "You handle technical support questions.", name: "Tech");Workflow workflow = AgentWorkflowBuilder.CreateHandoffBuilderWith(triage).WithHandoff(triage, billing).WithHandoff(triage, tech).Build();
八、迁移路线图：六步渐进式策略
对于已经在使用 Semantic Kernel 的 .NET 团队，微软官方推荐以下六步渐进式迁移路线 (Microsoft Learn) ：
| 步骤 | 行动 | 说明 |
|---|---|---|
| 1 | 并行包引入 | 安装 Microsoft.Agents.AI、Microsoft.Agents.AI.Workflows，MAF 与 SK SDK 可共存 (Microsoft Learn) |
| 2 | 重用现有插件 | 保留所有 [KernelFunction] 和 [Description] 装饰的 C# 插件类，可直接作为共享工具资产 (Microsoft Learn) |
| 3 | 构建厂商中立的 ChatClient | 利用 Microsoft DI 注册底层的 IChatClient (devleader.ca) |
| 4 | Agent 实例化重构 | 将 ChatCompletionAgent 改写为通用 AIAgent，使用 AIFunctionFactory.Create() 注入工具 (Microsoft Learn) |
| 5 | 升级会话状态层 | 将 AgentGroupChat 替换为 agent.CreateSessionAsync()，持久化场景记录 session.ConversationId (devleader.ca) |
| 6 | 重构多智能体编排 | 移除手工编写的 SelectionStrategy，使用 WorkflowBuilder 声明图节点或采用标准编排模板 (Microsoft Developer Blogs) |
关键建议：MAF 设计为与原有 SK SDK 共存，无需一次性推翻重建。建议新项目直接采用 MAF，现有 SK 项目按上述六步策略渐进迁移 (Microsoft Learn) 。
九、总结：.NET AI 的 Agent-Native 未来
Microsoft Agent Framework 1.0 的 GA 标志着微软 .NET AI 技术栈完成了从"SDK 工具集"到"Agent 原生平台"的关键跃迁。这不仅仅是品牌重塑或 API 翻新，而是一次底层设计范式的根本转变：
| 维度 | Semantic Kernel 时代 | MAF 1.0 时代 |
|---|---|---|
| 核心隐喻 | Kernel（内核）+ Plugin（插件） | Agent（智能体）+ Workflow（工作流） |
| 抽象层级 | 厂商特定的 ChatCompletionAgent |
厂商中立的 AIAgent via IChatClient |
| 编排方式 | 隐式、提示词驱动的控制流 | 显式、声明式的图编排 |
| 状态管理 | 隐式线程，手动维护 | 显式 AgentSession，自动持久化 |
| 协议支持 | 后期适配 MCP/A2A | 原生内置 MCP + A2A 1.0 |
| 持久化 | 无内置长运行支持 | DurableTask 自动检查点与水合 |
| 企业就绪 | 实验性 Agent 功能 | Agent Harness + Hosted Agents + LTS |
对于 .NET 开发者而言，MAF 1.0 带来了三重确定性：稳定 API + 长期支持承诺意味着可以放心地投入生产；双语言（.NET + Python）统一编程模型意味着团队协作不再受语言边界束缚；MCP + A2A 原生集成意味着你的 Agent 可以与整个生态互联互通。
Semantic Kernel 完成了它的历史使命——它教会了 .NET 开发者如何与 LLM 对话。现在，Microsoft Agent Framework 将教会我们如何让 Agent 彼此对话、与工具对话、与企业系统对话。这才是 Agent-Native 时代的真正开始。
参考资源
- Microsoft Agent Framework 官方文档：learn.microsoft.com/agent-framework (Github)
- 迁移指南：从 Semantic Kernel 迁移到 MAF (Microsoft Learn)
- GitHub 仓库：microsoft/agent-framework (Github)
- BUILD 2026 公告：Agent Harness, CodeAct, Hosted Agents (Microsoft Developer Blogs)
- Durable Workflows 详解：devblogs.microsoft.com/dotnet (Microsoft Developer Blogs)
- A2A v1 集成指南：devblogs.microsoft.com/agent-framework (Microsoft Developer Blogs)
