Microsoft Agent Framework（微软智能体框架）

AutoGen 与 Semantic Kernel 自 2023 年起并行开发，面向两类不同诉求。AutoGen 出自微软研究院，擅长多智能体编排的实验性模式——群聊、顺序流程、辩论循环、分层委派，但生产化支持较弱，认证、插件管理与监控需要自行补齐。Semantic Kernel 出自微软产品团队，长于企业级模型集成：插件架构、类型安全、遥测、中间件与函数调用治理，但多智能体编排是后来附加的，复杂模式需要更多样板代码。

结果是团队往往先选一个，然后撞上需要另一个的那堵墙：用 AutoGen 的想要企业插件模型，用 Semantic Kernel 的想要多智能体模式。微软于 2025 年 10 月推出合并框架的公开预览，收集反馈后于 2026 年 4 月 3 日发布 1.0 正式版。据发布说明，框架采用 MIT 许可，仓库在正式版时约有 9,400 颗星标与 1,500 次 fork，代码构成大致为 Python 与 C# 各半，另有一小部分 TypeScript。合并本身也是一次生态整理：微软同时承诺为 Semantic Kernel v1.x 提供至少一年的延续支持，作为迁移过渡期。

框架把能力收敛到两个原语上。Agent 是个体单元：接收输入、调用模型、使用工具、维护多轮会话与状态，并可直接连接 MCP 服务器。Workflow 是图式编排引擎：把多个智能体与确定性函数连成可分支、可检查点、可暂停的多步流程，并支持类型安全的路由。

正式版稳定了 五种编排模式，均继承自 AutoGen 的研究积累：sequential（确定性流水线）、concurrent（扇出与汇合）、handoff（任务中途移交其他智能体）、group chat（多智能体对话，由选择器决定发言顺序）、Magentic-One（面向任务的层级式推理）。五种模式都支持流式输出、检查点、人工审批介入与暂停恢复，这是从演示代码走向长任务运行的关键能力。

工程细节上，智能体定义可以用声明式 YAML 描述，使配置能与应用代码一同纳入版本控制；记忆层做成可插拔组件，支持会话历史、持久键值状态与向量检索，并提供 Foundry、Mem0、Redis、Neo4j 等适配器。需要注意的是，正式版发布时 Python 与 .NET 两个 SDK 仍存在功能对齐差距，部分较新的模式与记忆后端会先在 Python 侧落地。

框架在协议层面的取向比较明确：MCP 被作为基础能力内建，而非事后补上的适配器。智能体可以动态发现并调用任何符合 MCP 的服务端工具，外部工具目录演进时无需改动应用代码。据微软 Foundry 团队的技术说明，这一选择与「把 MCP 当作基础设施而非待办项」的判断一致——对长期维护成本而言，工具接入方式是否位于架构底层，影响的是后续每一次集成。

A2A（Agent-to-Agent）1.0 的跨运行时协作支持被列为即将提供，但在正式版发布时没有给出确切时间表。这一点值得在选型时留意：如果架构预期需要与其他框架或第三方运行时中的智能体协同，接口的可用时间会直接影响排期。

模型供应商方面，框架并非以 Azure 为默认特权项，而是内置七家接入：Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic Claude、Amazon Bedrock、Google Gemini 与本地运行的 Ollama。切换供应商在理论上只需改动一处客户端构造代码，这一取向与「不做模型绑定」的企业诉求契合，但不同供应商在工具调用与流式行为上的差异仍会在细节处显现。

企业层是此次合并的着力点，主要包含四项：可观测性（基于 OpenTelemetry 的智能体动作追踪）、内容安全（Azure AI Content Safety 集成）、身份认证（Entra ID）、以及 CI/CD 集成（GitHub Actions 与 Azure DevOps）。Foundry 团队把框架的设计原则概括为开放标准与互操作、从研究到生产的通路、可扩展的模块化设计，以及企业可用性。

据发布说明，被点名的早期采用者包括 KPMG（审计自动化）、Commerzbank（客户支持）与 BMW（车辆遥测分析），同一批名单中还出现 Fujitsu、Citrix、TCS、NTT DATA、TeamViewer、Weights & Biases 与 Elastic。这些场景的共同特征是既有 .NET 或混合技术栈、对审计与合规有要求，且不希望为智能体单独引入一整套陌生的运行时。

正式版同时提供浏览器端的 DevUI 调试器，可实时展示智能体之间的消息流、工具调用与结果、决策点与耗时。它对非工程角色的价值在于把执行轨迹变成可浏览的对象，使「智能体为什么这样输出」不必依赖原始日志或临时埋点。

合并解决的是微软自身的碎片化问题，但迁移并不自动发生，代价因来源框架而异。从 Semantic Kernel 迁移相对平缓：官方提供迁移指南，API 表面兼容度足以支持分阶段改造，且 v1.x 至少一年的支持期留出了缓冲。从 AutoGen 迁移更重：编程模型从「以对话为中心的多智能体对话」转向「图式工作流编排」，虽然提供兼容层，但该层将被弃用，代码量较大时需要按真实迁移预算而不是版本升级来规划。

选型边界也需要说清楚。在 Python 优先、且没有 Azure 承诺的团队里，框架选择依然是判断题：据第三方评测与社区讨论的普遍看法，LangGraph 在状态化生产工作流上部署经验更厚，CrewAI 在从想法到可运行演示上更快，而该框架的明确适配对象是 .NET 团队与 Azure 原生组织。把版本放在而不是替代关系的框架上理解，比把它当作某一家的替代品更接近实际情况。此外，正式版发布时 DevUI、Foundry 托管智能体集成、GitHub Copilot SDK 与 Claude Code SDK 的集成仍处于预览状态，未见稳定时间表。

该框架后续的两个看点，一是 A2A 1.0 跨运行时支持的实际落地时间，这将决定它能否从单体框架升级为多框架协作的节点；二是 SK 与 AutoGen 社区的实际迁移速度，两套编程模型的存量差异不会在短期内消失。此外，模型与运行时的联合演进会持续影响框架抽象层——当模型开始针对特定外壳训练时，通用编排框架需要重新界定自己不可替代的部分。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。