第 45 章 Semantic Kernel：把 Kernel、Plugin、Process 与 Agent 融成企业框架

Semantic Kernel 的系统观，有很强的 Microsoft 风格。

它不是先从“怎么做一个酷炫 autonomous agent”开始。 它更像是从企业软件问题开始倒推：

• 如何把模型接进现有应用
• 如何把函数、插件、服务和流程统一起来
• 如何让 agent 与已有系统、依赖注入、配置和治理一起工作

因此，第 45 章第一条结论应该是：

Semantic Kernel 的核心不是单个 Agent 循环，
而是一个把 Kernel、Plugin、Process、Agent 和企业系统连接起来的总框架。

这就是为什么它最重要的几个对象不是“人格化 agent”，而是：

• Kernel
• Plugin
• KernelFunction
• service / connector
• Process
• ChatCompletionAgent
• AgentGroupChat

#45.1 它真正解决的，不是“做一个 agent”，而是“把 AI 接入企业系统”

如果把 Semantic Kernel 和前面几个框架相比，会发现它的出发点明显不同。

它不是先问：

• 怎么做一个更灵活的图 runtime
• 怎么做一个更统一的高层 agent 入口
• 怎么把 run loop 对象产品化

它首先在问的是：

企业现有的服务、API、流程、权限和监控体系，
怎样和 AI 能力统一起来？

这也是为什么 Microsoft 官方会把它直接定位成一种 enterprise-ready orchestration framework，甚至明确使用 middleware 这种语言。

也就是说，Semantic Kernel 不是把自己理解成“聊天 agent 工具包”，而是理解成：

• 模型接入层
• 企业服务接入层
• 插件与函数目录层
• 流程建模层
• agent 协作层
• 可观测与治理层

这正是企业框架的典型姿态。

因此，本章第一条判断可以进一步强化成：

Semantic Kernel 的本质不是“再造一个 Agent 壳”，
而是把 AI 能力插进现有企业软件体系的中间层框架。

#45.2 Kernel：为什么它是整个框架真正的中心

要理解 Semantic Kernel，必须先把 Kernel 看懂。

在这个框架里，Kernel 不是一个普通工具对象，也不是某个模型客户端的简单包装。 从官方文档和源码都能看出，它更像一个运行核心：

• 管理 services
• 管理 plugins
• 管理 functions
• 管理 filters
• 管理 AI service selection
• 作为系统运行和监控的统一入口

也就是说，Kernel 在这里扮演的是一种“容器”角色。

它把一堆本来会分散在各处的东西收拢起来：

• 模型连接
• 企业 API 接入
• 插件注册
• 过滤器
• 执行参数
• 监控与可观测钩子

这意味着 Semantic Kernel 的系统中心不是：

先造一个 Agent，再慢慢给它加工具。

而是：

先造一个统一内核，让模型、插件、服务和治理先有共同容器，
再在这个内核之上生成 Agent 能力。

这和很多 Agent-first 框架差异很大。

因为在 Semantic Kernel 这里，agent 并不是天然的最高对象。 Kernel 才是那个决定系统如何接入企业世界的中心对象。

#45.3 Plugin / KernelFunction：它为什么不是“工具列表”，而是企业能力目录

Semantic Kernel 的另一个核心，是 plugin 体系。

这里最容易被低估的一点是：

它的 Plugin 不是简单工具列表。

从源码和文档看，KernelPlugin 更像一个带命名、描述、函数元数据的能力容器。 它内部装的是 KernelFunction，而不是随手丢进去的 callable。

这件事很关键。

因为一旦把企业能力组织成 plugin / function 目录，你得到的就不只是“模型能调用它”：

• 你得到稳定命名
• 你得到函数元数据
• 你得到可治理的函数集合
• 你得到与现有服务边界更一致的组织方式

这正是 Microsoft 文档不断强调 plugin 贴合企业现有 API/服务/DI 方式的原因。

也就是说，Semantic Kernel 并不鼓励你把所有工具能力临时塞给模型。 它更倾向于先把企业能力建设成：

AI-facing 的函数目录层。

于是，Plugin 在这里的真实意义就很清楚了：

• 它是企业代码与 AI 系统的接缝
• 它是业务语义被对象化的地方
• 它是函数治理的收口点

这也是为什么 Semantic Kernel 对 OpenAPI、MCP、native code plugin 都有比较完整的支持。

因为它真正想做的是：

让你已有的系统能力以统一方式暴露给 Kernel，
再由 Kernel 统一暴露给 agent、process 和模型。

#45.4 Process：为什么它在 Semantic Kernel 里不是附属能力，而是独立一层

如果说 Kernel 解释了“能力如何接入”，那 Process Framework 解释的就是“业务流程如何建模”。

这一层非常重要。

因为很多 Agent 框架一旦开始讲流程，很容易把流程也混进对话 loop 里。 但 Semantic Kernel 的做法明显更企业化：

• process 是独立抽象
• step 是独立工作单元
• event / edge / state 是显式建模对象
• process 支持暂停、恢复、审计、可观测

从 ProcessBuilder 源码就能看出来，这不是简单地“把几个函数串起来”。 它显式建模：

• step 注册
• initial state
• external event target map
• entry steps
• process factories

这说明 Semantic Kernel 对流程的理解，不是“agent 自己规划一下”。 它更像是在说：

业务流程有自己独立的结构语义，
不能被 agent chat 完全吞掉。

这点对企业场景尤其关键。

因为很多企业问题本质上都不是“开放探索任务”，而是：

• 有明确阶段
• 有明确事件
• 有明确审批点
• 有明确状态推进
• 有明确可审计需求

这类问题如果被重新压回自由聊天，往往会失去可控性。

所以，本章必须明确写下一条很重要的判断：

在 Semantic Kernel 里，能被流程化的事情，应该先流程化；
Agent 是流程中的参与者，而不是天然的最高控制器。

#45.5 Agent：它建立在 Kernel 之上，而不是独立于 Kernel

理解 Semantic Kernel 的 agent 层，也必须避免一个误解：

不要把它看成一套脱离 Kernel 的独立 agent 栈。

以 ChatCompletionAgent 为例，源码写得很清楚。 它的关键输入包括：

• kernel
• plugins
• service
• instructions
• function_choice_behavior
• arguments

也就是说，agent 在这里并不是一个从零开始构造的自治体。 它天然建立在：

• Kernel 提供的服务容器之上
• Plugin 提供的能力目录之上
• Function choice / arguments 提供的执行策略之上

这非常关键。

因为它说明 Semantic Kernel 的 agent 层本质上是：

在 Kernel 世界之上的自治与会话协作接口。

这和那种“先有 Agent，对外再挂工具”的框架很不一样。

同样，AgentThread、AgentGroupChat、channel、selection strategy、termination strategy 这些对象也都说明：

它在多 Agent 层面关心的，不是几个 prompt 互相说话， 而是带有策略、线程状态和通信结构的协作系统。

#45.6 三层分工：Kernel / Agent / Process 是三种不同系统主语

如果把整个框架压缩来看，Semantic Kernel 最值得肯定的一点，其实是它没有把所有问题压成同一种抽象。

它很明确地分出了三层：

第一层，Kernel / Plugin / Function 层。 这层回答：

• 能力从哪里来
• 服务怎么接
• 业务函数怎么暴露
• 过滤器和服务选择怎么接入

第二层，Agent / Chat / Thread / GroupChat 层。 这层回答：

• 多轮交互怎么进行
• 多 agent 如何协作
• 谁来选择下一位 agent
• 何时终止

第三层，Process / Step / Event / Edge / State 层。 这层回答：

• 流程如何建模
• 状态如何推进
• 事件如何驱动
• 审计与恢复如何成立

这三层一旦分开看，Semantic Kernel 的系统观就非常清楚了：

工具与业务能力，应先进入 Kernel / Plugin 体系；
会话协作，应进入 Agent 体系；
结构化流程，应进入 Process 体系。

这正是企业框架应有的分工。

因为企业系统最忌讳的事，就是让所有语义都坍缩成一种“万能 agent”。

#45.7 过滤器与观测：为什么它的治理重心不在 prompt，而在内核

如果继续往治理层看，Semantic Kernel 的企业属性会更明显。

它并不把治理主要寄托在 prompt 约束上。 相反，它把很多关键治理点放在了：

• filters
• function invocation pipeline
• prompt rendering pipeline
• auto function invocation pipeline
• telemetry / observability

这件事非常重要。

因为这意味着：

• 权限检查
• 提前终止
• 重试
• PII 脱敏
• 缓存
• 模型切换

这些能力有明确的工程落点，而不是散在 prompt 里。

所以，Semantic Kernel 的治理心智和 LangChain middleware 有点像，但更靠近内核执行管线。

如果压缩成一句话，就是：

Semantic Kernel 的治理中心更靠近 Kernel execution pipeline，
而不是靠 Agent 自己“自觉遵守规则”。

#45.8 业务适配：它为什么尤其适合企业助理、业务 copilot 和流程化系统

从业务适配角度看，Semantic Kernel 最适合的是这样一类问题：

• 已有很多企业 API、服务和系统
• 需要通过插件把这些能力暴露给模型
• 需要把业务流程、审批和事件显式建模
• 需要企业级 observability、filters、DI、服务连接
• 需要 agent 参与，但不希望 agent 独吞全部控制权

这类场景通常包括：

• 企业助手
• 业务 copilot
• 流程化审批系统
• 多系统编排
• Azure / Microsoft 生态中的企业集成应用

而它不那么适合的，往往是：

• 只是想最快做一个轻量 chat + tool demo
• 把复杂性都押在单个自由 agent 上
• 不关心现有系统接入，只想做纯 prompt-driven 实验

这不是说它做不到，而是说那样会浪费它最核心的价值。

#45.9 它最容易被误用成什么

真正理解 Semantic Kernel，也要看它最容易被误用成什么。

最常见的误用，至少有五种。

第一，把它仅仅当成 prompt 包装器。 这会完全浪费其 Kernel / Plugin / Process 结构。

第二，把所有问题都强行做成自由 chat agent，而不利用 process framework。 这会让最适合结构化流程的问题重新退化为不稳定对话。

第三，忽视其企业对象模型，直接把业务规则塞进 prompt。 这会让它失去相对其它框架最关键的优势。

第四，把 plugin 当成普通工具列表，而不把它当企业能力目录来治理。

第五，把 process 和 agent chat 混成一件事。 但两者解决的问题并不相同：

• process 更像结构化业务流程
• agent chat 更像带策略的会话协作

一旦把这两层混淆，就很容易把本来应当确定的流程又重新拖回不稳定聊天里。

#45.10 它和前面几个框架的本质差异

现在可以把前面几个框架和它并列起来看。

• LangGraph 的中心是图、状态、检查点和中断
• LangChain 的中心是高层入口、中间件和应用接口
• OpenAI Agents SDK 的中心是 run、session、result、state、handoff、trace
• Semantic Kernel 的中心是 Kernel、Plugin、Process、Agent 与企业系统集成

这说明 Semantic Kernel 最独特的地方，不是某一个 agent API，而是它的整体系统姿态：

它更像企业 AI 中间层，
而不是单纯的 Agent 框架。

因此，本章最后要留下的判断是：

Semantic Kernel 的本质不是“微软版 Agent 包”，
而是一个以 Kernel、Plugin、Process 为骨架，把 Agent 纳入企业软件体系的框架。