Semantic-Kernel
核对日期：2026-05-09。
1. 定义与边界
Semantic Kernel 是 Microsoft 面向企业应用的 AI 编排 SDK，核心概念包括 Kernel、plugins/functions、connectors、prompt templates、filters、memory 和 Agent Framework。它强调把 AI 能力嵌入现有应用，而不是只做聊天机器人。
2. 官方能力、社区能力、实验能力和营销说法
| 类型 | 内容 |
|---|---|
| 官方能力 | Kernel、plugins、function calling、connectors、filters、planner/agent 相关框架、Azure/OpenAI 集成 |
| 社区能力 | 第三方 connector、插件和示例 |
| 实验/快速变化 | Agent Framework、process framework、部分语言 SDK 能力差异 |
| 营销说法 | “企业级”不等于默认满足审计、合规和权限，需要业务系统实现 |
3. 核心机制
Kernel 是依赖注入和编排中心；plugin/function 把业务能力暴露给模型；filter 可用于调用前后治理。
4. 架构与工程实现
适合场景：
| 场景 | 设计 |
|---|---|
| .NET/企业系统集成 | Kernel + plugin 封装内部服务 |
| Azure 生态 | 与 Azure OpenAI、身份和观测集成 |
| 需要函数治理 | filters 做审计、拦截和策略 |
| 多 Agent 企业应用 | Agent Framework + 明确权限边界 |
插件策略：
public class TicketPlugin
{
[KernelFunction]
public string CreateDraft(string title, string body)
{
return "draft-id";
}
}
5. 生产实践
- 插件函数必须是最小权限，避免暴露通用 SQL、shell 或内部管理 API。
- 使用 filter 记录函数调用、参数摘要、审批状态和异常。
- 企业环境优先接入现有身份、权限、密钥和审计系统。
- 不同语言 SDK 能力可能不同，选型时按目标语言官方文档核对。
- Agent Framework 适合企业多 Agent，但流程复杂时仍需显式状态机和评测。
6. 常见反模式
| 反模式 | 风险 |
|---|---|
| 把所有业务服务做成一个大插件 | 权限过大、难测试 |
| 让模型自由组合高权限函数 | 越权执行 |
| 忽视语言 SDK 差异 | 迁移失败 |
| 只依赖 planner 自动规划 | 缺少业务流程约束 |
7. 评测方法
评测插件调用准确率、函数参数正确性、filter 拦截率、策略命中、端到端任务成功率和 Azure/模型服务延迟。企业场景还要做权限边界测试。
8. 安全与治理
Semantic Kernel 的安全重点在 plugin 暴露面、凭证管理、函数调用审计、prompt injection 和数据分类。治理应放在 Kernel 外围和 filter 中双层实现。
9. 权威资料
- Semantic Kernel overview: https://learn.microsoft.com/en-us/semantic-kernel/overview/
- Semantic Kernel agents: https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/
- Semantic Kernel plugins: https://learn.microsoft.com/en-us/semantic-kernel/concepts/plugins/
- Semantic Kernel filters: https://learn.microsoft.com/en-us/semantic-kernel/concepts/enterprise-readiness/filters
- Semantic Kernel GitHub: https://github.com/microsoft/semantic-kernel
10. 二次精修：企业插件式 Agent 架构
10.1 当前官方能力
| 能力 | 作用 | 适合 |
|---|---|---|
| Kernel | 统一编排模型服务、prompt 和函数 | 企业应用嵌入式 AI |
| Plugins | 把业务函数暴露给模型调用 | .NET / Java / Python 服务 |
| Filters | 在函数调用、prompt、auto invocation 中插入控制 | 安全策略、日志、审批 |
| Agents | 多 Agent 和工具化任务 | 企业 Copilot 和自动化 |
| Process framework | 事件驱动业务流程 | 长流程、状态和人类在环 |
10.2 适用场景
| 场景 | 推荐原因 |
|---|---|
| Microsoft/.NET/Azure 企业系统 | 与现有身份、遥测和服务生态衔接 |
| 业务函数已服务化 | plugin 映射自然 |
| 需要企业策略插桩 | filters 适合做拦截和审计 |
| 需要把 AI 嵌入现有应用 | Kernel 可作为应用内组件 |
10.3 不适用场景
- 非 Microsoft 技术栈且团队不希望引入 SK 概念模型。
- 主要是数据检索/RAG 调优，LlamaIndex 或专门 RAG 栈可能更直接。
- 追求低代码运营配置，Dify/Coze 更适合非工程人员。
10.4 架构图
10.5 插件边界
| 插件类型 | 风险 | 控制 |
|---|---|---|
| 查询插件 | 跨租户读取 | 用户上下文和 ACL |
| 写入插件 | 误改业务数据 | 审批、幂等、回滚 |
| 外发插件 | 数据外泄 | DLP、目标 allowlist |
| 管理插件 | 权限扩大 | 管理员审批、SoD |
10.6 生产实践
- 插件函数名、描述和参数要像 API 合约一样评审。
- Filters 中实现工具调用前后的策略、脱敏、日志和审批。
- Azure/企业身份应在业务 API 层校验，不能只靠 Kernel 上下文。
- 多语言 SDK 能力可能不同，生产选型前要确认目标语言的成熟度。
- Process framework 可承接长流程，但状态、补偿和版本迁移仍需设计。
10.7 评测与安全
| 维度 | 指标 |
|---|---|
| Plugin 调用 | 函数选择准确率、参数正确率 |
| Filter | 拦截正确率、误拦截率、延迟 |
| 流程 | 分支覆盖、异常恢复、人类审批命中 |
| 安全 | prompt injection、越权插件、敏感外发 |
| 运维 | 遥测覆盖、trace 关联、成本 |
10.8 迁移策略
| 来源 | 迁移重点 |
|---|---|
| 传统 .NET 服务 | 先把稳定业务函数封装成 plugin |
| Prompt 脚本 | 把 prompt、function、filter 分层 |
| AutoGen 原型 | 把角色协作重写成 Agents/Process 或业务流程 |
| Azure Copilot 扩展 | 明确哪些走 SK，哪些走平台能力 |
核对日期：2026-05-09。
10.9 上线验收补充
| 验收项 | 通过标准 |
|---|---|
| Plugin 合约 | 函数描述、参数、scope 和错误语义评审通过 |
| Filter 策略 | 工具调用前后能拦截越权、敏感字段和高风险动作 |
| 身份 | 用户身份、服务身份和审批身份不混用 |
| Process | 长流程状态、补偿和版本迁移有设计 |
| 遥测 | Kernel trace 能关联业务 run、审计和审批 |
| SDK 差异 | 目标语言能力已实测，未用示例推断生产能力 |
这些验收项比“能跑通插件调用”更重要，因为企业系统的风险通常发生在权限、审计和状态恢复环节。 新项目还应同步评估 Microsoft Agent Framework 的路线图，避免在 Microsoft 生态内重复建设编排层。