Semantic Kernel 与 Microsoft Agent Framework：迁移前的架构判断
语义内核将应用程序代码与语言模型、提示、工具、内存和代理工作流程连接起来。
秒懂
- 它是什么？
- Semantic Kernel 是微软出品的模型无关 AI 编排 SDK，但官方已宣布其继任者为 Microsoft Agent Framework。本文基于仓库现状，分析其核心机制、适用场景与迁移代价。
- 适合谁用？
- 如果你正在构建新的企业级多智能体系统，且没有历史包袱，应直接采用 Microsoft Agent Framework 1.0，其稳定 API 与长期支持承诺更适合生产环境。若你已用 Semantic Kernel 开发了相当规模的插件或流程，不要急于重写，先阅读官方迁移指南，评估 Kernel 对象模型与 Agent 线程 API 的差异。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 C#（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个已经宣告后继者的框架
Semantic Kernel 的 README 第一行就给出了明确信号：它已经被 Microsoft Agent Framework（MAF）取代。这不是猜测，而是仓库自述。MAF 目前是 1.0 版本，官方承诺稳定 API 与长期支持。Semantic Kernel 本身仍然活跃，最近一次推送在 2026 年 8 月，dotnet 版本号到了 1.80.0。但活跃维护与战略重心是两回事。任何评估这个项目的工程师，首先必须接受一个事实：你看到的可能是一个处于维护模式、而非创新模式的项目。
它解决的问题：连接 LLM 与应用代码
Semantic Kernel 的核心定位是模型无关的编排 SDK。它解决的具体问题，是让应用代码与语言模型、提示词、工具、记忆和智能体工作流之间建立连接。目标用户是需要在应用内集成 AI 能力的开发者，而不是研究模型本身的人。它支持 OpenAI、Azure OpenAI、Hugging Face、NVIDIA，也支持通过 Ollama、LMStudio 或 ONNX 做本地部署。这意味着你可以写一套业务逻辑，然后切换不同的模型提供商。这种抽象层在 2024 年很有价值，但到了 2026 年，模型提供商之间的 API 差异已经缩小，这个卖点不再那么突出。
核心机制：Kernel、插件与智能体
从代码示例可以看出，Semantic Kernel 的架构围绕三个概念展开。Kernel 是核心容器，通过 builder 模式创建，负责持有模型连接和插件。插件通过 kernel_function 装饰器或 KernelPluginFactory 注册，可以是原生代码函数，也可以是提示词模板。智能体则是对 Kernel 的封装，ChatCompletionAgent 接收 instructions 和 service，然后通过 get_response 方法处理用户消息。多智能体系统通过创建多个 ChatCompletionAgent 实例，配合 ChatHistoryAgentThread 来管理对话历史。这个模型清晰，但有一个隐含的成本：你写的所有插件和智能体逻辑，都绑定在 Semantic Kernel 的对象模型上，迁移到 MAF 时不是简单的换包名。
安装与运行：三行命令与一个环境变量
安装过程相当直接。Python 用户执行 pip install semantic-kernel，.NET 用户执行 dotnet add package Microsoft.SemanticKernel 和 Microsoft.SemanticKernel.Agents.Core。Java 用户需要参考单独的构建文档。运行前要设置环境变量，Azure OpenAI 用 AZURE_OPENAI_API_KEY，OpenAI 直连用 OPENAI_API_KEY。快速开始示例中，创建一个基本智能体只需要实例化 ChatCompletionAgent，传入 service 和 instructions，然后调用 get_response。这个入门体验在同类框架中算得上平顺，但注意示例代码有截断，实际运行时可能需要额外的配置参数，比如 deployment 名称和 endpoint。
一个真实的限制：示例不完整，文档有缺口
README 中的代码示例多处被截断。Python 的 haiku 输出只显示了一半，MenuPlugin 类没有完整定义，.NET 的智能体创建代码在 aw 处中断，多智能体示例只展示了两个 agent 的 instructions。这不是小问题。对于想快速验证的开发者，这意味着你必须去官方文档或 GitHub 源码里补全代码。更麻烦的是，README 没有说明如何配置 OpenAI 直连的 service 实例，只给了 Azure 的示例。如果你用的是 OpenAI 而不是 Azure，需要自己摸索 OpenAIChatCompletion 的参数。这种文档质量对于一个宣称企业就绪的框架来说，是明显的短板。
替代方案：Microsoft Agent Framework 的差异
替代方案不是别的产品，而是它自己的后继者 Microsoft Agent Framework。两者的差异在 README 中已经点明：MAF 提供企业级多智能体编排、多提供商模型支持，以及通过 A2A 和 MCP 实现的跨运行时互操作性。A2A 是智能体之间的通信协议，MCP 是模型上下文协议，这两者让 MAF 的智能体可以跨语言、跨平台协作。Semantic Kernel 虽然也支持 MCP 插件，但它的多智能体编排是库内实现，没有标准化协议。如果你需要异构系统之间的智能体协作，MAF 是更合适的选择。如果你只需要在单个应用内串联几个模型调用，Semantic Kernel 的轻量级模型可能更直接。
维护成本与许可证
许可证是 MIT，这对商业使用没有限制，但要注意微软的商标和品牌使用政策，这不属于 MIT 的范畴。维护成本方面，Semantic Kernel 的发布节奏仍然稳定，dotnet 1.80.0 和 python 1.44.1 都是 2026 年 8 月的版本。但战略上它已经让位于 MAF，这意味着新功能可能不再优先加入 Semantic Kernel。如果你选择使用它，需要自己承担未来的迁移风险。官方提供了迁移指南，但迁移不是免费的，你的插件、智能体定义和 Kernel 配置都需要重新映射到 MAF 的 API。在投入生产之前，建议先列出你使用的所有 Semantic Kernel 特性，逐一对照 MAF 的文档确认是否存在对应实现。
编辑结论
如果你正在构建新的企业级多智能体系统，且没有历史包袱，应直接采用 Microsoft Agent Framework 1.0，其稳定 API 与长期支持承诺更适合生产环境。若你已用 Semantic Kernel 开发了相当规模的插件或流程，不要急于重写，先阅读官方迁移指南，评估 Kernel 对象模型与 Agent 线程 API 的差异。需要验证的第一件事是：你依赖的 OpenAI 连接器与向量数据库集成在 MAF 中是否有对应实现，以及 .NET 10 或 Python 3.10 的运行时要求是否与你的部署环境冲突。Semantic Kernel 不会立即消失，但它的演进方向已经明确，继续在新项目上押注旧框架是风险大于收益的选择。
社区笔记