Semantic Kernel：微软企业级 Agent 框架

为什么需要 Semantic Kernel：直连模型 SDK 的后期成本太高

传统 LLM 应用开发往往从直接调用 OpenAI/Azure OpenAI SDK 开始：写一个 prompt、接一次工具调用、调一次接口。这种方式的痛点在项目扩展时集中爆发——第一，模型服务被硬编码在业务代码里，换模型或接入多模型要改多处；第二，工具调用逻辑散落各处，没有统一的「能力注册表」，Agent 不知道该调用哪些函数；第三，日志、审计、敏感信息过滤完全没有抓手；第四，多步骤业务流程（如审批流、订单处理）缺少可编排、可恢复的状态机，只能靠手写胶水代码。

Semantic Kernel 的解法是把「模型服务」和「业务能力」都收编进 Kernel：所有 AI 服务作为 Service 注册，所有可被调用的能力作为 Plugin（插件）注册，提示词模板与非本机函数统一抽象为 KernelFunction。这样 Agent 只需要面对 Kernel 一个入口，函数的调用由模型根据描述自动选择；同时 Filters（过滤器）能在函数调用前后拦截流量，Process（进程框架）能把业务定义成可视化、可持久化的流程图，Telemetry 让遥测直接对接应用偏好系统（Application Insights / OpenTelemetry）。

与 LangChain 等框架相比，SK 的气质更「企业工程化」：强类型、强调依赖注入、三语言官方支持齐头并进，对存量 .NET/Java 系统的接入路径最短。它不追求编排花样最多，而是追求「在现有企业软件里可靠地跑起来」。

安装与环境配置：3 步就绪

第一步·安装 SDK。 按技术栈选择，Python 环境需 3.9+，.NET 需 6.0+。

第二步·配置模型凭据。 SK 不绑定密钥存储，推荐通过环境变量或 .env 文件注入。以 OpenAI 为例：

第三步·验证安装。 能导入并打印版本号即成功：

# Pythonpip install semantic-kernel # .NETdotnet add package Microsoft.SemanticKernel # Java（Maven 坐标）# com.microsoft.semantic-kernel:semantic-kernel-core

# .envOPENAI_API_KEY=sk-xxxx# 若走 Azure OpenAI，则配置# AZURE_OPENAI_API_KEY=azure-xxxx# AZURE_OPENAI_ENDPOINT=https://your-resource.openai.azure.com/

python -c "import semantic_kernel; print(semantic_kernel.__version__)"

快速上手：5 分钟跑通第一个 Skill

最小可用流程的核心思路是三步——「建 Kernel、注册模型、调函数」。在代码里依次完成：

1. 创建 Kernel 实例（统一的依赖入口）；

2. 通过 Kernel.add_service 注册一个聊天补全服务（OpenAI 或 Azure OpenAI 连接器）；

3. 用 Kernel.add_function 定义一个提示函数（prompt template，模板支持 {{$input}} 参数），并用 await kernel.invoke 调用。

运行后输出一句对 Semantic Kernel 的解释，说明管道跑通了。进阶技巧：将 OpenAIChatCompletion 换成 AzureChatCompletion（需填 endpoint、api_key、deployment_name），即可无缝迁移到 Azure OpenAI；后续给 Kernel 注册自定义的 @kernel_function 原生函数，即拥有工具调用能力。

import asyncioimport osfrom semantic_kernel import Kernelfrom semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion async def main():    kernel = Kernel()     # 1. 注册模型服务    kernel.add_service(        OpenAIChatCompletion(            service_id="chat",            ai_model_id="gpt-4o-mini",            api_key=os.getenv("OPENAI_API_KEY"),        )    )     # 2. 定义提示函数    func = kernel.add_function(        plugin_name="demo_plugin",        function_name="ask",        prompt="请用一句话解释：{{$input}}",    )     # 3. 调用    result = await kernel.invoke(func, input="什么是 Semantic Kernel？")    print(result) if __name__ == "__main__":    asyncio.run(main())

核心能力详解：5 大支柱

支柱一·Kernel 与依赖注入。 Kernel 是所有服务的注册中心，承载 AI 服务（ChatCompletionService）、插件集合、过滤器与日志。在 .NET 中，SK 原生对接 IServiceCollection，可把 Kernel 注册为单例或作用域服务；Python/Java 亦有对应的内核构建器。合理设计 Kernel 生命周期，是生产应用稳定性的基础。

支柱二·插件系统（Plugins）。 插件是一组相关函数的集合。函数分两类：原生函数（Native Function）由代码实现，标注 @kernel_function 装饰器后自动暴露给模型；提示函数（Prompt Function）由提示词模板 + 参数化输入定义。二者的命名规范是 PluginName_FunctionName，模型通过函数名和描述决定是否调用，因此「给函数写清楚描述」直接影响 Agent 的调用准确率。

支柱三·Agent 编排（Agent Framework）。 1.x 提供 ChatCompletionAgent（单 Agent 助手）、AgentGroupChat（多 Agent 群聊协作）以及 OpenAI Assistant 集成。多个 Agent 可以在一个会话里协同：一个负责检索、一个负责总结、一个负责审核，托管与路由由 SK 处理。该模块部分 API 处于实验性阶段，引入前需评估稳定性。

支柱四·Process 进程框架。 面向确定性业务流的编排层：用 ProcessBuilder 把流程定义为「步骤 + 事件」图，每一步可持久化状态，支持暂停、恢复与分布式执行。适合订单审批、工单流转、数据处理管线等既要 AI 决策又必须可审计、可回溯的场景。

支柱五·Filters 与遥测。 Filters 是 1.x 的生产级关键组件：可在函数调用前/后、提示词渲染后等时机注入钩子，做鉴权、敏感信息脱敏、调用日志、限流与降级。遥测层内置 ActivitySource，通过 OpenTelemetry 或 Application Insights 直接采集 token 消耗与调用延迟，无需埋点改造。

生产部署与监控：从上线到运维

部署方式一·容器化 + DI 生命周期管理。 SK 应用通常打包为 Docker 镜像部署到 AKS / Azure Container Apps / 自建 K8s。.NET 团队应把 Kernel 注册为作用域服务（Scoped），避免单例 Kernel 长时间持有模型连接导致的内存问题；若用 Python，则需关注 asyncio 事件循环与 Kernel 实例的绑定关系，避免多线程共享同一实例。

部署方式二·模型服务路由与成本控制。 生产环境一般同时接入多个模型（便宜的快模型做分类、强模型做复杂推理）。在 Kernel 中注册多个 ChatCompletionService 时，必须为每个服务设置唯一的 service_id，调用时显式指定，否则框架会按顺序随机路由。成本侧可通过 Filters 记录每次调用的 token 数，结合用量阈值触发告警或降级。

可观测性。 将 SK 的遥测导出到 Application Insights 或 Prometheus + Grafana：关注三个指标——调用成功率、P95 延迟、每次 Agent 任务的 token 消耗。Filters 中统一打印 Prompt 摘要与函数调用链，能在出问题时快速复现 Agent 的决策路径。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>坑1：实验性 API 直接上生产——1.x 中 Agent 与 Process 部分 API 标注 experimental，上线前必须锁定版本并核对 API 稳定性说明，否则升级会破坏行为。</li><li>坑2：API Key 硬编码——SK 默认不校验密钥来源，建议统一从环境变量/托管身份（Azure Managed Identity）读取，并在 Filter 中拦截含密钥的日志输出。</li><li>坑3：多服务未指定 service_id——注册多个 AI 服务但不写明 service_id 时，调用可能路由到错误模型，导致格式或成本失控。</li><li>坑4：函数名与描述随意——插件函数命名冲突会覆盖注册；函数描述太模糊会让模型选择错误工具，必须遵循 PluginName_FunctionName 规则并写好描述。</li><li>坑5：忽略 Kernel 生命周期——将 Kernel 注册为单例却持有短作用域的 HttpClient 或数据库上下文，会造成连接池耗尽，需按 DI 规范选择作用域。</li></ul>

版本迭代

Semantic Kernel 从 2023 年初的公开预览走到 1.x，主线是「概念收敛」与「生产化」——先是把 Skills/Planner 重构为 Kernel/Plugins/Functions，随后从流程编排延伸到 Agent 与 Process 框架，最后补齐 Filters 与遥测。整体演进方向是从「能跑」到「能上生产」。（截至训练数据，可能已有更新版本）

AI 应用场景

常见误区

面试题

参考来源

• webpageNuGet Microsoft.SemanticKernel.NET 包说明、版本与依赖信息