前言：AI Agent，终于有了"正规军"
过去两年，AI 大模型的浪潮席卷了整个软件开发行业。但对于大多数 .NET 开发者来说，有一个问题始终没有得到很好的解答：
「我该用什么框架，把 AI 能力真正融入到企业级应用里？」
Semantic Kernel 太重，学习曲线陡峭；AutoGen 偏向 Python 和研究场景，.NET 支持参差不齐；自己封装 OpenAI 接口，多模型切换就是噩梦……
2025 年 10 月，微软给出了自己的答案——**Microsoft Agent Framework（MAF）**正式开源预览。2026 年 4 月 7 日，MAF 1.0 正式 GA（生产可用），承诺长期支持稳定 API。
这不是又一个新框架，而是微软把 Semantic Kernel 团队和 AutoGen 团队合并之后，联合打造的下一代 AI Agent 开发基座。
今天这篇文章，就带大家彻底搞清楚：MAF 是什么，解决了什么问题，核心能力有哪些，以及 .NET 开发者现在该不该用它。
一、MAF 是什么？
MAF 是一个开放的、支持多语言的框架，专门用于在 .NET 和 Python 中构建生产级 AI 智能体（Agent）和多智能体工作流（Multi-Agent Workflow）。它面向的是那些要把 Agent 从原型推向生产的团队。
但光看这句话还不够直观。我们换个角度来理解它的定位。
MAF 将 AutoGen 针对单智能体和多智能体的简洁抽象，与 Semantic Kernel 的企业级能力——基于会话的状态管理、类型安全、过滤器、遥测以及广泛的模型和 Embedding 支持——融合在了一起。除此之外，MAF 还引入了全新的工作流引擎，让开发者可以对多 Agent 的执行路径进行显式控制，以及一套更强健的状态管理系统，专门用于长时间运行和 Human-in-the-Loop 场景。
用一句话总结：「MAF 是 Semantic Kernel 和 AutoGen 的继承者，由同一批团队创建，是下一代的官方统一框架。」
2026 年 4 月，MAF 1.0 正式发布，标志着从"发布候选版"进入"正式可用"阶段——API 稳定，承诺长期支持。无论是构建单个助手，还是编排一支专业化的多智能体协作团队，MAF 1.0 都提供了企业级的多智能体编排能力、多模型提供商支持，以及通过 A2A 和 MCP 实现的跨运行时互操作性。
二、为什么需要 MAF？痛点先说清楚
在 MAF 出现之前，.NET 开发者构建 AI Agent 是什么体验？
场景一：你用 Semantic Kernel 搭了一个 Agent，现在需要接入两个专业子 Agent 协同工作，结果发现多 Agent 编排能力非常有限，要自己大量手写调度逻辑。
场景二：你用 OpenAI 的 API 直接调用，换个模型（比如从 OpenAI 换成 Azure OpenAI，或者换成本地的 Ollama）就要重构一大堆代码，耦合非常严重。
场景三：Agent 执行过程中需要人工确认某些高风险操作，但框架没有内置 Human-in-the-Loop 机制，要自己实现复杂的暂停-恢复状态机。
场景四：Agent 在执行复杂任务时中途崩溃，整个流程从头重跑，没有任何检查点机制。
「MAF 针对性地解决了以上所有问题。」
MAF 的核心价值体现在几个方面：统一 API（为单智能体和多智能体系统提供一致的接口，降低复杂度）；简化编排（更轻松地构建和托管工作流，最大限度减少样板代码）；增强特性（增加了显式工作流、检查点和更完善的状态管理，这些在前身框架中都不够完整）；以及以开发者为中心的设计（充分利用了 .NET 的依赖注入、最小化 API 等成熟模式，无缝集成）。
三、五行代码跑通第一个 Agent
学习一个框架最好的方式，是先看它最简单的用法是什么。
MAF 的极简 Agent 创建，简单得出乎意料：
就这样，一个能调用 LLM 并返回响应的 Agent 就建好了。从这里出发，你可以继续添加工具函数、多轮对话、中间件和工作流，构建出真正的生产应用。
如果你不用 Azure AI Foundry，也可以直接对接 OpenAI：
这里的核心是 IChatClient 接口——来自 Microsoft.Extensions.AI，它是整个 MAF 的模型抽象层，让你可以自由切换底层 LLM，而不需要改动任何 Agent 逻辑。
四、核心能力详解：MAF 的四大支柱
4.1 多模型、多提供商支持
MAF 的灵活性来自于 Microsoft.Extensions.AI，它通过 IChatClient 接口标准化了模型访问方式。ChatClientAgent 实现接受任何 IChatClient，让你可以在 Azure OpenAI、OpenAI、Ollama 等提供商之间自由选择——切换模型不需要改动 Agent 代码。
这意味着：你今天在本地用 Ollama 跑 Llama 开发调试，明天部署到生产用 Azure OpenAI，不用改一行 Agent 业务逻辑代码。
4.2 工具调用（Function Calling）
让 Agent 不只是"说"，而是能真正"做"事情：
框架会自动处理 Function Calling 的完整循环：LLM 决策调用哪个工具 → 框架执行工具函数 → 把结果返回给 LLM → LLM 生成最终答案。整个过程对你透明，不需要手动写循环。
4.3 多轮对话与 Session 管理
当你需要管理多轮对话时，使用 AgentSession，MAF 会自动管理消息历史。当你在多个不同 Agent 之间传递上下文时，使用显式的 List<ChatMessage>，你完全控制每次调用中包含哪些历史消息。
4.4 中间件管道（Middleware Pipeline）
MAF 的中间件管道与 ASP.NET Core 的请求管道如出一辙，可以在不修改核心 Agent 逻辑的情况下，拦截 Agent 运行来处理横切关注点，比如对话持久化、限流、错误处理等。
这意味着你可以用熟悉的方式扩展 Agent 行为——就像给 ASP.NET Core 添加中间件一样自然。
五、多 Agent 工作流：真正让人兴奋的部分
单个 Agent 能力有限，真实的企业场景往往需要多个专业 Agent 协同工作。MAF 内置了一套完整的工作流引擎，这才是它最让人兴奋的地方。
5.1 四种编排模式
MAF 支持多种灵活的工作流模式：顺序（Sequential）——Agent 按顺序执行，每个 Agent 的输出作为下一个的输入；并发（Concurrent）——多个 Agent 并行处理任务的不同方面；交接（Handoff）——根据上下文或结果，将控制权在 Agent 之间转移；群聊（GroupChat）——Agent 在共享的实时对话空间中协作。
来看一个典型的顺序工作流例子——内容生产流水线：
单智能体使用一个系统提示处理所有任务；多智能体编排则把每个认知角色分配给独立的 Agent——研究员、评审者、写作者。这种专业化分工带来更高质量的输出，因为每个 Agent 完全专注于一项工作，而评审者和研究员之间的反馈循环还允许持续迭代改进。
5.2 基于图的工作流与检查点
MAF 的工作流构建在有向图上，包含三个核心概念：执行器（Executor），代表工作流中的单个处理单元，可以是 AI Agent 或自定义逻辑组件；边（Edge），定义执行器之间的连接关系，可以包含根据消息内容进行条件路由的逻辑；工作流（Workflow），由执行器和边构成的有向图，从初始执行器开始，根据边中定义的条件和逻辑沿不同路径推进。
MAF 还支持检查点机制——通过保存工作流状态，支持长时间运行流程的服务端恢复和续跑。这意味着一个执行几小时的复杂任务，中途崩溃后可以从上次的断点继续，而不是从头开始。
5.3 Human-in-the-Loop：关键操作等人审批
这是企业级 Agent 场景不可缺少的能力。想象一个财务报销 Agent，当报销金额超过阈值时，必须有人工审批才能继续执行转账操作。
MAF 原生支持 Human-in-the-Loop 工作流，任务可以被标记为需要人工审批，Agent 会在等待确认期间暂停执行。
框架检测到需要审批的工具调用时，会暂停整个流程，把审批请求返回给调用方（你的 UI 或后台系统），等待人工决策后再继续——整套机制完全内置，不需要你手写复杂的状态机。
六、A2A + MCP：迈向开放的 Agent 生态
MAF 1.0 的一个重要里程碑是对两个开放协议的原生支持：A2A（Agent-to-Agent）协议，是一个结构化的跨运行时 Agent 通信协议，例如用 Python 构建的 Agent 可以无缝与运行在 .NET 环境中的 Agent 协同工作；MCP（Model Context Protocol），完整集成了模型上下文协议，让 Agent 可以动态发现和调用外部工具与数据源，无需手动集成代码。
这两个协议组合在一起，意味着什么？
用 .NET 写的销售 Agent 可以调用 Python 写的数据分析 Agent；你的 Agent 可以通过 MCP 接入 GitHub、Notion、数据库等任意工具，而不需要单独写适配代码；不同团队、不同技术栈开发的 Agent 可以像乐高积木一样组合协作。
这是从「单体 Agent」到「Agent 互联网」的关键一步。
七、可观测性与生产级特性
MAF 通过 OpenTelemetry 提供完整的可观测性支持——Agent 的每一次动作，包括工具调用、编排步骤、推理流程和性能数据，都可以被追踪和监控，并接入 Microsoft Foundry 仪表盘。
对于生产运维来说，这意味着你可以清楚地看到：某次用户请求触发了哪些工具调用、各步骤耗时多少、哪个 Agent 出现了异常、Token 消耗分布如何——而不是像以前一样面对一个黑盒。
此外，MAF 还支持：
「安全性」：可以托管在 Microsoft Foundry 上，获得角色访问控制、私有数据处理、内置内容安全等企业级安全能力。
「持久性」：Agent 线程和工作流支持暂停、恢复和从错误中恢复，适合长时间运行的业务流程。
「云中立」：Agent 可以在容器中运行、在本地部署，也可以跨多个不同的云平台运行——不强制绑定 Azure。
八、MAF vs Semantic Kernel vs AutoGen：该怎么选？
这是很多开发者第一时间会问的问题。
Semantic Kernel 和 AutoGen 开创了 AI 智能体和多智能体编排的概念。Agent Framework 是由同一团队创建的直接继承者，它将 AutoGen 针对单智能体和多智能体模式的简洁抽象，与 Semantic Kernel 的企业级功能结合在一起，并在此基础上增加了更多新能力。简而言之，Agent Framework 是下一代 Semantic Kernel 和 AutoGen。
实际操作建议：
「新项目」：直接用 MAF，不要再选 Semantic Kernel 或 AutoGen，它们的继任者已经 1.0 GA 了。
「老项目用 Semantic Kernel」：官方提供了迁移指南，核心概念基本可以映射过来，迁移成本可控。
「老项目用 AutoGen」：同样有官方迁移文档，AutoGen 的 Agent 抽象在 MAF 中有对应的 ChatClientAgent。
「不需要 Multi-Agent、不需要工作流编排」：如果只是简单的单次 LLM 调用，其实 Microsoft.Extensions.AI 直接用 IChatClient 就够了，不一定要引入整个 MAF。
九、快速上手：安装与配置
「安装 NuGet 包：」
「在 ASP.NET Core 中集成（依赖注入）：」
总结
当微软在 2025 年 10 月推出 MAF 时，目标是把 Semantic Kernel 的企业级基础和 AutoGen 的创新编排能力统一到一个框架中。经过几个月来自社区的反馈、压力测试和真实用户的生产验证，MAF 1.0 已经准备好了。
对 .NET 开发者来说，MAF 的出现意味着：
你终于有了一个「官方的、稳定的、生产级的」 AI Agent 开发框架；不用再在 Semantic Kernel 和 AutoGen 之间摇摆；不用担心今天选的框架明天被废弃；Multi-Agent 编排、Human-in-the-Loop、工作流检查点、MCP 工具集成……这些以前要自己造轮子的能力，现在开箱即用。
AI Agent 的时代已经来了，.NET 开发者也有了自己的一席之地。
最后
看到这里辛苦啦～如果这篇文章让你对 MAF 有了清晰的认识，顺手点赞支持一下！
欢迎在评论区留言：你目前在用 Semantic Kernel 还是 AutoGen？打算迁移到 MAF 吗？一起交流！
