Semantic Kernel：微軟的企業級 AI 主線

當你打開 GitHub，搜尋 AI Agent 框架時，你一定會被 LangChain 或 AutoGen 的星星數閃瞎。

但在這個喧囂的舞台角落，微軟（Microsoft）正在默默推動另一套框架。它沒有每天上熱搜，但在許多大型企業、銀行、尤其是微軟自家的 Copilot 生態系背後，它是真正的中樞神經。

它叫 Semantic Kernel (SK)。

為什麼微軟自己有 AutoGen，還要推 Semantic Kernel？為什麼不用 LangChain 就好？

Semantic Kernel 的核心主張：AI 不應該是一個獨立的魔法盒子，它應該被當成普通的 SDK，安安靜靜地整合進現有的企業軟體架構中。

• 為什麼你需要認識 Semantic Kernel？
• Semantic Kernel 的三大核心積木
  • 1. Kernel（核心協調者）
  • 2. Plugins（外掛系統：讓 AI 擁有手腳）
  • 3. Planner（計畫者：讓 AI 自己決定步驟）
• 為什麼是 C# / Python 雙語並行？
• 框架比較：Semantic Kernel vs 其他框架
  • Semantic Kernel vs AutoGen：微軟為什麼要兩個框架？
• 實用建議：三個起步行動
  • 步驟 1：用你最熟悉的語言引入 SK
  • 步驟 2：把現有函數標上 [KernelFunction]
  • 步驟 3：體驗 FunctionCallingPlanner
• 我的反思
• 參考資料 (References)

為什麼你需要認識 Semantic Kernel？

如果你是一間新創公司的工程師，想要用 Python 快速做出一個 AI 應用，你大概會選 LangChain 或 OpenAI Agents SDK。

但想像一下，如果你是一間擁有 20 年歷史的銀行、或是微軟自己的 Office 團隊：

• 你的後端是用 C# / .NET 或是 Java 寫的
• 你有極度嚴格的安全與依賴注入（Dependency Injection）規範
• 你要求 AI 的呼叫必須像呼叫傳統 API 一樣可靠可控

這時候，那些「跑得很快但容易打破東西」的 Python 框架就不適合了。Semantic Kernel 就是為這個「穩健需求」而生的。

Semantic Kernel 的三大核心積木

Semantic Kernel 的設計哲學非常像傳統的作業系統核心（Kernel）——它本身不處理具體業務，而是負責協調資源（模型）與周邊裝置（外掛）。

1. Kernel（核心協調者）

Kernel 是整個框架的中心，負責把所有的組件綁在一起：

// C# 範例：建立一個 Kernel
var builder = Kernel.CreateBuilder();

// 加入 AI 服務（可以用 Azure OpenAI, 也可以用一般的 OpenAI）
builder.AddAzureOpenAIChatCompletion(
    deploymentName: "gpt-4o",
    endpoint: "https://your-resource.openai.azure.com/",
    apiKey: "your-api-key"
);

// 註冊一個本地時間的外掛
builder.Plugins.AddFromType<TimePlugin>();

Kernel kernel = builder.Build();

這段程式碼對 .NET 開發者來說極度親切。它用了標準的 Builder 模式和依賴注入，這意味著你可以隨時把 AzureOpenAI 換成 HuggingFace 模型，而不用改動後面的業務邏輯。

2. Plugins（外掛系統：讓 AI 擁有手腳）

在 SK 裡，所有的工具都被稱為 Plugin。Plugin 分兩種：

• Native Functions（原生函數）：傳統的 C# 或 Python 程式碼，例如「查資料庫」、「寄信」。
• Semantic Functions（語意函數）：用 Prompt 寫成的函數，例如「總結這段文字」。

// 一個標準的 Native Plugin
public class EmailPlugin
{
    // 加入 [KernelFunction] 屬性，AI 就能自己發現並呼叫這個函數
    [KernelFunction("send_email")]
    [Description("Sends an email to a specific recipient.")]
    public async Task SendEmailAsync(
        [Description("The recipient email address")] string to,
        [Description("The email content")] string body)
    {
        // 傳統的寄信邏輯...
        Console.WriteLine($"寄信給 {to}：{body}");
    }
}

SK 的強項在於「強型別與註解」。你寫的 [Description] 會自動被 SK 轉換成 OpenAI 的 Function Calling JSON schema。對 C# 開發者來說，寫 AI 工具就跟寫 Swagger/OpenAPI 註解一樣自然。

3. Planner（計畫者：讓 AI 自己決定步驟）

如果你給 AI 一個複雜任務：「幫我查明天的天氣，如果下雨，幫我發信取消明天的戶外會議。」

在沒有 Planner 的時候，你需要手動寫 if/else 來串聯 WeatherPlugin 和 EmailPlugin。

有了 Planner，AI 會自己「寫程式」來完成任務：

// 建立一個 Function Calling Planner
var planner = new FunctionCallingStepwisePlanner();

// 執行複雜任務
var result = await planner.ExecuteAsync(kernel, 
    "查一下明天的天氣。如果下雨，請幫我發信給 team@company.com 取消戶外會議。");

Console.WriteLine(result.FinalAnswer);

Planner 會分析 Kernel 裡面註冊了哪些 Plugin，然後像大腦一樣，決定先呼叫天氣 Plugin，拿到結果後，再決定要不要呼叫 Email Plugin。

為什麼是 C# / Python 雙語並行？

這是 Semantic Kernel 最大的戰略特色：它保證 C# 和 Python（以及 Java）的 Feature Parity（功能對齊）。

在 AI 世界，Python 幾乎是統治語言。LangChain 雖然有 LangChain4j（Java）或 LangChain.js，但更新速度永遠落後 Python 版。

但微軟是 .NET 的老家。微軟知道，世界上有成千上萬的企業核心系統是用 C# / Java 寫的。

Semantic Kernel 讓企業不需要用 Python 重寫他們的後端。你可以直接在現有的 .NET Core API 專案裡，NuGet install Microsoft.SemanticKernel，然後你的傳統系統瞬間就擁有了呼叫 GPT-4 和執行 RAG 的能力。

框架比較：Semantic Kernel vs 其他框架

Semantic Kernel vs AutoGen：微軟為什麼要兩個框架？

• Semantic Kernel 是由下而上的：它是 SDK，負責把你寫好的 C# 函數安全地暴露給 LLM。它關心的是「系統整合」。
• AutoGen 是由上而下的：它是 Agent 框架，負責讓三個不同的 AI 角色互相討論問題。它關心的是「群體智慧」。

到了 2024–2025 年，微軟正在推動兩者的融合：用 Semantic Kernel 來實作 AutoGen 裡每個 Agent 的「大腦與手腳」。

實用建議：三個起步行動

步驟 1：用你最熟悉的語言引入 SK

如果你是 Python 開發者：

pip install semantic-kernel

如果你是 C# 開發者：

dotnet add package Microsoft.SemanticKernel

去感受一下在強型別語言（C#）裡寫 AI 程式的安全感。

步驟 2：把現有函數標上 [KernelFunction]

把你專案裡現有的一個查資料函數，標上 KernelFunction 和描述。然後把它掛進 Kernel 裡，讓模型自己去呼叫它。你會發現，讓傳統系統 AI 化的成本比想像中低非常多。

步驟 3：體驗 FunctionCallingPlanner

不要自己寫 if/else。給 Planner 一個複雜的 prompt，觀察它如何在背景自動組合你的 Plugins。這是體驗「AI 作為大腦」最直接的方式。

我的反思

在這個系列寫了這麼多框架後，Semantic Kernel 給我的感覺沒有華麗的 Multi-Agent 動畫，也沒有天馬行空的自主思考循環。它的程式碼看起來就像你在寫 ASP.NET 網站後端一樣平淡無奇。

但這正是微軟的厲害之處。

微軟深知，要讓 AI 真正進入千行百業，不能只靠 Python 工程師在 Jupyter Notebook 裡寫實驗腳本。必須讓那些每天維護 ERP、銀行系統、企業內部工具的 Java 和 C# 工程師，用他們熟悉的「依賴注入、介面、型別安全」來寫 AI。

當 LangChain 在引領駭客們探索 AI 的邊界時，Semantic Kernel 在做的是另一件事：幫傳統企業鋪設從 Web 2.0 通往 AI 時代的鐵軌。

參考資料 (References)

官方資源

• Semantic Kernel 官方文件 (Microsoft Learn)
• Semantic Kernel GitHub
• Semantic Kernel 官方部落格

推薦影片