XBSTACK
小白 / Xiaobai

小白 / Xiaobai

开发者 · 产品构建者

持续构建 AI 工程系统、开发者工具与长期数字资产。

关于作者与 XBSTACK →
Semantic Kernel 使用 Plugins、KernelFunction 与 automatic function calling 的当前架构
ai

Semantic Kernel 实战：Plugins、Function Calling 与 Agent 编排怎么做

Semantic Kernel 当前怎么用？本文按 Kernel、Plugins、KernelFunction、automatic function calling、依赖注入、权限与 Agent Framework 迁移边界重写，明确 Stepwise/Handlebars Planner 已移除。

发布 · 2026-01-206 分钟阅读XBSTACK 原创
#AI Agent#Semantic Kernel#Plugins#Function Calling#C##Architecture#Microsoft Agent Framework

直接答案：Semantic Kernel 现在仍然值得用于企业应用的 AI 能力封装，但主线已经不是“给 Skills 配 Planner”。当前更准确的架构是 Kernel + Plugins + function calling：把现有 C# / Python / Java 服务封装为 Plugin functions，让模型通过原生 function calling 选择函数；早期 Stepwise 和 Handlebars planners 已被弃用并从主要 SDK 包中移除。

这篇旧文最大的问题不是 SEO，而是 API 代际。它曾推荐 SequentialPlanner，并把 FunctionCallingStepwisePlanner、skprompt.txt、config.json、Semantic Function 等旧范式写成 2026 主线。现在继续这样教，会直接把读者带进过时文档。

Semantic Kernel 当前到底解决什么问题

Semantic Kernel 的价值不是“替模型再写一套 Planner”，而是把 AI service 和企业已有能力放进一个可治理 Kernel 中。

Kernel 可以集中管理：

  • 模型/AI service；
  • Plugins；
  • Dependency Injection；
  • Logging / telemetry；
  • function calling 所需要的函数 Schema；
  • 应用自己的服务依赖。

所以它特别适合这样的项目：已经有 C#/.NET 服务、数据库、HTTP Client、权限组件和领域服务，希望把其中少量能力安全暴露给模型，而不是为了 AI 再复制一套业务代码。

Plugin 是当前核心：把已有服务变成模型可调用函数

一个 Plugin 本质上是一组有明确语义说明的 functions。函数可以读取数据，也可以执行任务。

Microsoft 当前文档强调，Plugin 不只有函数本身，还需要让模型理解：

  • Plugin 名称；
  • Function 名称；
  • Function 描述；
  • 参数名称和 Schema；
  • 返回值 Schema；
  • 可能的副作用。

在 C# 中，一个 native plugin 可以直接由现有类构成：

using System.ComponentModel;
using Microsoft.SemanticKernel;

public sealed class OrderPlugin
{
    private readonly IOrderService _orders;

    public OrderPlugin(IOrderService orders)
    {
        _orders = orders;
    }

    [KernelFunction("get_order_status")]
    [Description("Read an order status. This function never changes the order.")]
    public async Task<string> GetOrderStatusAsync(
        [Description("Internal order identifier")] string orderId)
    {
        return await _orders.GetStatusAsync(orderId);
    }
}

然后把它注册进 Kernel：

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
    deploymentName: deploymentName,
    endpoint: endpoint,
    apiKey: apiKey
);

builder.Services.AddSingleton<IOrderService, OrderService>();
builder.Plugins.AddFromType<OrderPlugin>("Orders");

Kernel kernel = builder.Build();

这里的优势是 Plugin 可以直接复用依赖注入里的业务服务，而不是让 Tool 函数自己创建数据库连接或在 Prompt 中携带凭据。

Planning 现在由 function calling 完成

Semantic Kernel 早期确实有 Planner：模型先生成计划，再由框架按计划执行函数。

但随着 OpenAI、Claude、Gemini、Mistral 等模型普遍支持原生 function calling，Semantic Kernel 的设计已经转向：把 Plugin functions 提供给模型，由模型在对话循环中选择需要调用的函数。

Microsoft 当前 planning 文档明确说明：

  • function calling 是当前主要 planning/执行方式；
  • Stepwise planner 已移除；
  • Handlebars planner 已移除；
  • Python、.NET、Java 都不再支持这些旧 planners；
  • 新 Agent 应使用 function calling。

因此下面这些内容不应该再出现在新的“推荐方案”里：

SequentialPlanner
FunctionCallingStepwisePlanner
HandlebarsPlanner

如果旧系统还依赖它们，应按 migration guide 迁移，而不是在新代码继续加深依赖。

自动 Function Calling 的正确边界

自动 function calling 能帮模型解决：

“当前用户问题应该调用哪个 Plugin function，参数是什么，调用结果后下一步是否还要调用其他函数？”

它不能自动解决：

  • 用户有没有权限；
  • 这个 Tool Call 是否被人工批准；
  • 写入是否已经执行过；
  • 网络超时后能不能安全重试；
  • 支付/发布/删除是否满足业务条件。

一个生产执行链应该是：

Model requests function
        │
        ▼
Schema validation
        │
        ▼
Authorization / policy gate
        │
        ├─ high risk ─► Human approval
        ▼
Idempotency check
        │
        ▼
Business service executes
        │
        ▼
Result returned to model

Plugin 描述得再清楚，也不能替代权限系统。

Native Code、OpenAPI、MCP：Plugin 不只来自本地类

Semantic Kernel 当前文档给出的主要 Plugin 来源包括：

  1. Native code：最适合复用现有服务和 Dependency Injection；
  2. OpenAPI：适合已有 HTTP API 或跨团队能力；
  3. MCP Server：适合把标准化 MCP 能力引入 Kernel。

这也是 Semantic Kernel 和 MCP 不应该被写成“二选一框架”的原因：MCP 可以是 Plugin 来源/互操作边界，Semantic Kernel 则负责应用内部的 Kernel、服务和函数调用编排。

Plugin Schema 比“Prompt 写得聪明”更重要

如果两个函数都写成：

search_data
query_data

而描述都只是“查询数据”，模型很难稳定选择。

生产 Plugin 应明确：

  • 什么时候使用；
  • 什么时候禁止使用；
  • 是否只读；
  • 参数约束；
  • 输出是否完整；
  • 是否可能产生副作用；
  • 错误类型是否可重试。

函数越高风险，描述和 Schema 越要具体，同时还要有代码层 policy gate。

Dependency Injection 是 Semantic Kernel 的真正企业优势之一

Kernel 本身可以作为服务与 Plugin 的组合入口。对于 .NET 项目，这意味着：

  • Plugin 复用 HttpClientFactory；
  • Plugin 注入 Repository / Domain Service；
  • 统一日志、Telemetry 与 CancellationToken；
  • 不把 API Key 直接暴露给模型；
  • 测试时替换 mock service。

这种工程边界比“自动生成一条 Planner 路径”更值得长期维护。

Semantic Kernel 与 Microsoft Agent Framework 怎么选

Microsoft 已经提供从 Semantic Kernel 到 Microsoft Agent Framework 的官方迁移指南。Agent Framework 更集中于新的 Agent / Workflow API 和跨 Provider 的统一开发体验。

但这并不意味着 Semantic Kernel Plugin 架构立即失效。已有 SK 项目可以先问：

  • 当前只是调用 Plugin，还是已经需要复杂 Agent/Workflow？
  • 是否需要 Agent Framework 的统一会话、Workflow、handoff 或 HITL 模型？
  • 迁移能否减少维护成本？
  • 已有 Kernel Plugin 是否可以作为稳定业务能力继续复用？

如果现有应用只是“模型 + 企业 Plugins + function calling”，没有必要为了新 SDK 名称立即重写。

旧文章里哪些概念现在必须降级为历史背景

旧概念当前处理
Skill统一使用 Plugin / Function 语义理解新代码
Semantic Function / Native Function 二分当前重点放在 Plugin functions 与 KernelFunction
SequentialPlanner已不应作为新项目推荐
FunctionCallingStepwisePlanner已不应作为新项目推荐
Handlebars Planner已移除
skprompt.txt + config.json 作为 Plugin 主线不应再代表现代 native plugin 教程

FAQ

Semantic Kernel 还是 LangChain？

没有统一赢家。已有 .NET 企业服务、依赖注入和 Microsoft 平台资产时，Semantic Kernel 的 Plugin 模型非常自然；Python Agent 项目希望使用 LangChain v1 Middleware 与 LangGraph runtime 时，LangChain 更直接。应该按语言、运行时、状态与业务权限选择，而不是按 GitHub 热度。

可以用 Ollama / 本地模型吗？

具体支持应按当前 Semantic Kernel connector 与 Provider 文档核对。不要像旧文那样承诺“实现一个 ITextCompletion 就能 100% 隐私”，因为实际数据边界还涉及 telemetry、Plugin 外部 API、日志和应用部署方式。

继续阅读

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作，让每篇文章都回到明确的主题主页面。

进入 AI Agent 专题 → 查看架构指南 订阅

继续阅读

返回专题 →
OpenAI Agents API vs Agents SDK vs Responses API：生产级 Agent 到底该把控制权交给谁？OpenAI 在 2026 年 9 月推出 Agents API 后，Responses API、Agents SDK、Agents API 三套能力很容易被混在一起。本文从 Agent Loop、状态、恢复、Tool Calling、Sandbox、多 Agent、成本、可移植性和业务控制权拆解三者的真实边界，并给出生产选型路径。OpenAI 开始试验“按结果收费”：AI Agent 为什么可能不再只按 Token 计费？OpenAI CFO Sarah Friar 表示，公司正在企业 AI 中试验基于业务结果而非单纯使用量的定价。本文结合 OpenAI、Intercom、Salesforce、AWS 等一手资料，分析 AI Agent 定价为何从 Token/Usage 走向 Task、Outcome 与 ROI，以及独立开发者应如何设计成本、评测、计费和模型路由。Context Engineering 是什么？AI Agent 如何用 Retrieval、Tool Search、Memory 降低上下文成本Context Engineering 不只是 Prompt Engineering。本文结合 Microsoft、Anthropic、Google 官方资料与 XBSTACK 本地实测，解释 Retrieval、Tool Search、MCP、Memory、Compaction 如何减少无效上下文与 AI Agent Token 成本。Gemini 3.8 Flash vs 3.7 Flash：价格没变，Coding、Agent 和实际成本怎么选？Gemini 3.8 Flash 和 3.7 Flash 有什么区别？核对价格、1M 上下文、Thinking Level、AI 编程、AIGC、Claude/GPT 选型语境、Agent 路由、迁移和 Token 成本。

AI 工程周报

只发真正改变工程判断的变化、故障、实验和新资产。

评论与补充证据

参与讨论

问题、验证与勘误

登录后可发表评论。所有新评论先进入审核；审核期间仅评论者本人和管理员可见，通过后才公开。

登录评论 审核后公开
正在加载评论区…