← 返回概念解读

Concept Fable精修版

Semantic Kernel

Semantic Kernel · Enterprise AI orchestration SDK

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

总调度台不需要学会每间工坊的手艺

王城有座百工调度堂,里面既有会写信的文士,也有查账的账房、画图的匠人和跑腿的驿卒。过去客人办一件复杂事,要自己在各屋之间传话,跑断腿还常漏材料。

新管事把每种手艺登记成可调用的工牌:这位能查账,需要哪些材料;那位能画图,交付什么格式;驿卒能送信,但要地址和印章。文士若要完成一封商函,可按工牌请人补证据、画草图、送回执。

第一版调度堂很乱。文士想起谁就叫谁,账房要的材料不齐,驿卒拿到半张地址。客人只觉得“大厅很聪明”,真正办事时却卡在细节。

管事便写流程:先理解请求,再选手艺,再传入材料,再把结果接回下一步。每个工牌还要说明失败时怎么报、需要谁审批、结果交给谁。光登记手艺不够,还要让手艺按顺序协作。

后来,常见差事被编成小套件。写报价、查库存、起草回信、安排送达,各自能组合,也能替换。客人看到的是一条顺畅服务,背后却是多种手艺按约定连接。

有次账房暂时关门,调度堂没有假装完成,而是把差事停在查账步骤,通知文士先起草不含金额的部分。等账房恢复,流程继续接上。管事这才放心:调度不是把风险藏起来,而是让每步可见。

调度堂的价值在把会说话的文士和可执行的工牌组织起来。单个聪明人不够,能把意图、技能、记忆和步骤串成可靠流程,复杂工作才跑得动。

后来调度堂扩建,新增了算账、验货和刻章手艺。管事没有让文士随意呼唤,而是先补工牌和流程。大厅越大,越需要统一约定;否则手艺越多,客人的差事越容易断在半路。后来客人看不见背后的工牌,却能感到差事少了断点和重复解释。

揭示

这个故事讲的是:Semantic Kernel

Semantic Kernel 是微软的开源 AI 编排 SDK,定位是在企业应用中集成大语言模型、插件、规划器、记忆和原生应用代码。它的核心抽象包括:Kernel(编排核心)、Plugins(能力封装,可包含 Semantic Functions 和 Native Functions)、Planner(将用户意图分解为多步执行计划)、Memory(通过向量存储实现语义记忆和检索)。Semantic Kernel 最大的特色是企业级嵌入——它不作为独立服务运行,而是嵌入到现有 .NET / Python / Java 应用中,复用企业已有的认证、日志、配置和部署体系。在 RAG 和 Agent 场景中,Semantic Kernel 的价值是把 AI 能力以 SDK 方式注入现有业务系统,而不是另起一套独立服务。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 每间分坊了解所有分坊的能力:应用代码硬编码所有 AI 调用路径,扩展性差
  • 东家一个人翻译和调度:用单个 LLM prompt 处理所有任务路由,缺乏结构化编排
  • 总调度台不关心工艺细节:Semantic Kernel 的 Kernel 抽象,只管任务编排
  • 接口规范声明:Plugins 的函数签名和描述,让 Kernel 知道每项能力能做什么
  • 跨任务记忆册:Semantic Kernel Memory,用向量存储承载对话历史、用户偏好和领域知识
  • 拆成几步分派:Planner 将复杂意图分解为多步执行链
  • 标准插槽注册:插件化架构,新能力以 Plugin 形式接入,不改 Kernel 核心
  • 分坊只做最擅长的事:关注点分离——LLM 做推理,Plugin 做执行,Kernel 做编排

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

pluginplannerkernelfunctionmemoryMicrosoft Copilot stack