返回资料库 实战:框架与工具

Semantic Kernel 实战:微软生态里的 Agent 编排框架

Semantic Kernel 是微软开源的一个 Agent 编排 SDK。它不是一个拖拽式平台,而是一层可以嵌入到现有应用里的 Agent 中间件,适合你在已有业务系统中加入大模型、工具调用、多 Agent 协作和流程编排能力。

来源:Microsoft Learn 中文:Agent Framework · Microsoft Learn 中文:快速入门 · Semantic Kernel GitHub · Microsoft Learn English:Agent Architecture | 整理时间:2026-04-29


什么是 Semantic Kernel?

Semantic Kernel 是微软开源的一个 Agent 编排 SDK。它不是一个拖拽式平台,而是一层可以嵌入到现有应用里的 Agent 中间件,适合你在已有业务系统中加入大模型、工具调用、多 Agent 协作和流程编排能力。

如果你已经有 .NET、Python 或 Java 项目,Semantic Kernel 的价值不是“重新做一个 AI 平台”,而是把 Agent 模式接进现有工程。

关键数据

项目 信息
定位 企业级、模型无关的 Agent 编排框架
主要语言 .NET、Python、Java
Python 安装 pip install semantic-kernel
.NET 包 Microsoft.SemanticKernel + Microsoft.SemanticKernel.Agents.Core
核心能力 Agent、插件、函数调用、多 Agent、流程框架、向量检索
生态特点 与 Azure、Microsoft 365、Azure AI Search 等微软生态衔接紧密

它和其他框架有什么不同?

框架 定位 复杂度 适合场景
Semantic Kernel 企业应用内嵌式 Agent 编排 已有业务系统接入 Agent、微软技术栈
LangGraph 图式工作流与状态编排 需要精确控制节点、状态和回溯
CrewAI 角色化多 Agent 协作 快速搭建 Agent 团队
Google ADK 代码优先、模型无关的 Agent 开发 从零构建生产级 Agent 服务

一句话判断:如果你的问题是“怎么把 Agent 能力接进现有企业应用”,Semantic Kernel 往往比纯研究型或 demo 型框架更顺手。


核心概念

1. Kernel

Kernel 是运行时容器,负责把模型服务、插件、提示词和执行设置装配到一起。你可以把它理解成 Agent 的“能力底座”。

2. ChatCompletionAgent

ChatCompletionAgent 是最常用的 Agent 类型,基于聊天模型工作。它适合做问答助手、企业 Copilot、内部运维助手和流程触发器。

3. Agent Thread

Thread 表示一次会话的上下文状态。对于本地模式,你通常用聊天历史保存上下文;对于托管式 Agent,线程状态也可以由云服务管理。

4. Plugins / Kernel Functions

Semantic Kernel 的工具系统叫插件。你可以把 Python 函数、C# 方法、OpenAPI 接口,甚至 MCP 能力包装成插件,再交给 Agent 自动调用。

5. Orchestration

当一个 Agent 不够用时,Semantic Kernel 可以把多个 Agent 组织成一个协作系统。典型模式包括:

  • Triage Agent:先分流,再交给专门 Agent 处理
  • Review Agent:先生成,再交给审查 Agent 校验
  • Human in the loop:关键步骤必须人工确认

什么时候该选 Semantic Kernel?

场景 是否适合 原因
你在维护 .NET / Azure 企业应用 非常适合 与微软生态集成自然,SDK 和文档成熟
你需要把 LLM 能力接入现有系统 适合 Kernel 和插件模式便于增量接入
你想做多 Agent 协作 适合 有 Agent Framework 和编排层
你要做复杂图式状态机 一般 LangGraph 往往更细粒度
你只想零代码拖拽一个 Agent 不优先 Dify、Coze 这类平台更省事

安装

Python

pip install semantic-kernel

.NET

dotnet add package Microsoft.SemanticKernel
dotnet add package Microsoft.SemanticKernel.Agents.Core

如果你要接 OpenAI Assistant API 或更复杂的编排能力,再按需补充代理包和编排包。

常见环境变量

export AZURE_OPENAI_API_KEY="your-key"
export AZURE_OPENAI_ENDPOINT="https://your-resource.openai.azure.com"
export AZURE_OPENAI_DEPLOYMENT="gpt-4.1-mini"

如果你直接用 OpenAI,也可以改成 OPENAI_API_KEY 这类配置。


第一个 Agent:最小可运行示例

下面这个 Python 版本几乎就是官方快速上手的最小形态:创建一个 ChatCompletionAgent,给它一段系统指令,然后直接收一条消息。

import asyncio
from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion


async def main():
    agent = ChatCompletionAgent(
        service=AzureChatCompletion(),
        name="SK-Assistant",
        instructions="你是一位中文技术助手,回答时保持准确、简洁。",
    )

    response = await agent.get_response(
        messages="用三句话解释什么是 Semantic Kernel。"
    )
    print(response.content)


asyncio.run(main())

这个示例已经足够说明 Semantic Kernel 的基本模型:

  • 模型服务由 service 提供
  • Agent 的身份和行为由 nameinstructions 决定
  • 用户输入通过 messages 进入
  • 返回结果是一个结构化响应对象,而不是纯字符串

给 Agent 加工具:插件示例

真正让 Semantic Kernel 进入“Agent”状态的关键,是让模型能调用你的业务函数。

import asyncio
from typing import Annotated
from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion
from semantic_kernel.functions import kernel_function


class TicketPlugin:
    @kernel_function(description="查询指定工单的当前状态")
    def lookup_ticket(
        self,
        ticket_id: Annotated[str, "工单编号"],
    ) -> str:
        fake_db = {
            "INC-1024": "处理中,负责人是张工,预计今天 18:00 前恢复。",
            "INC-2048": "已恢复,等待复盘。",
        }
        return fake_db.get(ticket_id, "未找到该工单,请检查编号。")


async def main():
    agent = ChatCompletionAgent(
        service=AzureChatCompletion(),
        name="Ops-Agent",
        instructions="你是运维助手,遇到工单问题时优先调用插件查询。",
        plugins=[TicketPlugin()],
    )

    response = await agent.get_response(
        messages="请帮我查一下 INC-1024 的进度,并给一句处理建议。"
    )
    print(response.content)


asyncio.run(main())

这个模式非常适合接企业内部系统:

  • CRM 查询
  • 工单和告警中心
  • OA 审批接口
  • ERP / 库存系统
  • 知识库检索

你不用把业务逻辑塞进 prompt,只要把已有函数暴露成插件即可。


多 Agent 怎么做?

Semantic Kernel 的 Agent Framework 适合下面这类协作链路:

用户问题
  -> 分流 Agent
  -> 专家 Agent A(检索资料)
  -> 专家 Agent B(生成方案)
  -> 审查 Agent(校验风险)
  -> 返回最终答案

这种模式在企业里很实用,因为它天然对应组织分工:

  • 一个 Agent 负责判断问题属于哪条流程
  • 一个 Agent 负责查知识库或调用内部 API
  • 一个 Agent 负责把结果整理成对外答复
  • 必要时再加一个人工确认节点

如果你已经读过 LangGraph 指南,可以把 Semantic Kernel 理解成“更贴近企业应用集成”的方案;如果你更喜欢角色化协作,则可对照 CrewAI 指南


和 MCP、RAG、微软生态怎么结合?

与 MCP 的关系

Semantic Kernel 自身有插件生态,也能与 OpenAPI、原生函数和 MCP 能力衔接。对中国开发者来说,这意味着你可以把已经写好的内部服务继续保留,只在 Agent 层增加一层编排。

如果你正在做工具接入,可以一起阅读:

与 RAG 的关系

Semantic Kernel 很适合“知识库 + 工具调用”的企业场景:

  • 先从向量库或 Azure AI Search 检索资料
  • 再让 Agent 调内部 API 获取实时数据
  • 最后把两类结果整合成可读答案

这比单纯聊天机器人更接近真正的企业 Copilot。

为什么中国开发者值得关注?

  1. 很多团队本来就在用 .NET、Azure、Microsoft 365,Semantic Kernel 的接入成本更低。
  2. 它适合做企业内网助手、知识库问答、流程自动化,这些正是国内最常见的落地方向。
  3. 中文系统教程相对 LangGraph、CrewAI 更少,提早掌握会有明显信息差。

选型建议

你的情况 更推荐
我是 .NET / Azure 团队 Semantic Kernel
我想精确控制每个节点和状态 LangGraph
我想最快搭一个多 Agent 团队 demo CrewAI
我需要跨模型、代码优先、云原生 Agent Google ADK

如果你的目标是“在现有业务系统里稳妥接入 Agent”,Semantic Kernel 往往是被低估的一条路线。


下一步怎么学?

建议顺序:

  1. 先跑通最小 ChatCompletionAgent
  2. 把一个真实业务函数改造成插件
  3. 给 Agent 接上知识库或检索层
  4. 再尝试双 Agent 分工和人工审核

只要第 2 步能跑起来,Semantic Kernel 对你就已经不是“框架概念”,而是可以开始接业务的工程能力了。

相关链接

常见问题

Semantic Kernel 实战:微软生态里的 Agent 编排框架 适合什么读者?

想搞清楚 实战 这一块的人,尤其是从概念跨到能动手做的过渡阶段。页面带摘要、同主题延伸和来源链接,你不用再去满网找。

阅读 Semantic Kernel 实战:微软生态里的 Agent 编排框架 需要多久?

预计 9 分钟。看不下去就跳到结论部分,把感兴趣的小节做个标记,后面再回来。

怎么把 Semantic Kernel 实战:微软生态里的 Agent 编排框架 用在自己的项目里?

挑一个文章里的最小例子先跑通,跑通之后再拿到自己的项目里。卡住的地方对照来源链接核验细节,部署和评估的部分可以从同主题其他文章补。