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

什么是 Semantic Kernel？

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

如果你已经有 .NET、Python 或 Java 项目，Semantic Kernel 的价值不是“重新做一个 AI 平台”，而是把 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？

安装

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 的身份和行为由 name、instructions 决定
• 用户输入通过 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 理解成“更贴近企业应用集成”的方案；如果你更喜欢角色化协作，可以参考 Agent 框架横评 中 CrewAI 的部分。

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

与 MCP 的关系

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

如果你正在做工具接入，可以对照 MCP Inspector 调试实战 和 MCP 协议详解 一起看。

与 RAG 的关系

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

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

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

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

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

选型建议

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