Semantic Kernel là gì? SDK của Microsoft cho điều phối AI

Nếu bạn xây dựng phần mềm trên nền tảng Microsoft và muốn thêm AI mà không cần phải gắn một dịch vụ Python bên cạnh, Semantic Kernel chính là SDK mà Microsoft đã tạo ra dành cho bạn. Đây là một bộ công cụ mã nguồn mở kết nối mã và API hiện có của bạn với các mô hình ngôn ngữ lớn, và nó chạy trên C#, Python và Java. Hướng dẫn này giải thích nó là gì, cách kernel và plugin hoạt động cùng nhau, và cách hỗ trợ đặc tả OpenAPI của nó biến bất kỳ REST API nào thành thứ mà một mô hình có thể gọi được.

button

Semantic Kernel thực sự là gì

Semantic Kernel (SK) là một bộ công cụ phát triển nhẹ, mã nguồn mở từ Microsoft để xây dựng các tác nhân AI và tích hợp các mô hình vào cơ sở mã của bạn. Microsoft mô tả nó như một middleware: nó nằm giữa ứng dụng của bạn và mô hình, dịch các yêu cầu của mô hình thành các lệnh gọi hàm thực tế, chạy chúng và trả kết quả về. Bạn viết mã thông thường. Mô hình sẽ quyết định khi nào gọi nó.

Ba điều khiến SK nổi bật giữa vô vàn thư viện tác nhân.

Thứ nhất, nó thực sự đa ngôn ngữ. SK cung cấp các SDK chính thức cho C#/.NET, Python và Java, với cam kết ổn định phiên bản 1.0+ trên cả ba nền tảng. Hầu hết các framework tác nhân đều ưu tiên Python và coi các ngôn ngữ khác là phần bổ sung. Nếu backend của bạn là .NET, SK là một trong số ít lựa chọn trưởng thành mang lại cảm giác nguyên bản.

Thứ hai, nó không phụ thuộc vào mô hình. SK kết nối với OpenAI, Azure OpenAI và các nhà cung cấp khác thông qua một bộ kết nối. Khi bạn muốn thay đổi mô hình, bạn chỉ cần thay đổi cấu hình chứ không phải toàn bộ ứng dụng của mình.

Thứ ba, nó được xây dựng với các mối quan tâm của doanh nghiệp. Telemetry, hooks và filters là những tính năng hàng đầu, cho phép bạn ghi nhật ký, kiểm toán và chặn những gì AI thực hiện. Chính sự tập trung đó là lý do tại sao Microsoft và một số đội ngũ thuộc Fortune 500 đã áp dụng nó.

Kernel, plugin và hàm

Đối tượng cốt lõi là kernel. Hãy coi nó như một container tiêm phụ thuộc (dependency-injection container) cho AI. Bạn đăng ký các trình kết nối mô hình và plugin của mình trên kernel, sau đó yêu cầu nó chạy các tác vụ. Kernel xử lý việc điều phối: nhắc lệnh (prompt), gọi mô hình, gọi hàm, kết quả, lặp lại.

Một plugin là một nhóm hàm được đặt tên mà bạn cung cấp cho mô hình. Một hàm là một khả năng duy nhất mà mô hình có thể gọi. Các hàm có hai loại:

Hàm gốc (Native functions) là các phương thức thông thường trong mã của bạn (một phương thức C#, một hàm Python) mà bạn chú thích để kernel có thể mô tả chúng cho mô hình.
Hàm nhắc (Prompt functions) là các nhắc lệnh được tạo mẫu gọi chính mô hình, hữu ích cho việc tóm tắt, phân loại hoặc viết lại văn bản.

Đây là cấu trúc của nó trong C#. Bạn xây dựng một kernel, đăng ký một mô hình trò chuyện, thêm một plugin và để mô hình gọi các hàm khi cần.

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

Khi mô hình trả về và kernel thấy nó muốn gọi change_light_state, kernel sẽ chạy mã của bạn, thu thập kết quả và truyền lại cho mô hình. Vòng lặp đó là trái tim của SK.

Mô hình OpenAPI-thành-plugin

Đây là tính năng đáng biết nhất, và nó là cầu nối sạch nhất đến các dịch vụ hiện có của bạn. SK có thể nhập một đặc tả OpenAPI và tự động biến mỗi thao tác thành một hàm có thể gọi được. Bạn không cần viết mã bao bọc (wrapper code). Bạn chỉ cần chỉ SK đến một đặc tả, và mỗi đường dẫn/thao tác sẽ trở thành một hàm mà mô hình có thể gọi.

Trong C#, lệnh gọi là ImportPluginFromOpenApiAsync. Trong Python là add_plugin_from_openapi. Java cũng có một trình nhập tương đương. Đây là phiên bản C# tải một đặc tả từ URL:

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters()
    {
        EnablePayloadNamespacing = true
    }
);

Ẩn dưới, SK phân tích đặc tả, trích xuất tên, mô tả, kiểu và lược đồ cho mọi tham số, và chuyển siêu dữ liệu đó cho mô hình. Mô hình sẽ suy luận xem nên gọi thao tác nào và truyền đối số nào. SK sau đó xây dựng yêu cầu HTTP, áp dụng hàm gọi lại xác thực của bạn, gửi nó và đọc lại phản hồi. SK hỗ trợ OpenAPI 2.0 và 3.0, và hạ cấp các đặc tả 3.1 xuống 3.0 nếu có thể.

Vấn đề là các đặc tả viết cho con người không phải lúc nào cũng rõ ràng đối với một mô hình. Hướng dẫn của Microsoft là thêm ID thao tác mô tả, viết mô tả tham số hữu ích, giữ số lượng endpoint thấp, và ưu tiên enum và tham số có kiểu thay vì chuỗi lỏng lẻo. Chất lượng đặc tả của bạn trực tiếp quyết định mức độ tác nhân gọi API của bạn. Điều đó làm cho bản thân đặc tả trở thành thứ đáng để thiết kế và kiểm tra cẩn thận, chứ không phải là một điều phụ.

Tác nhân (Agents) và lập kế hoạch (planning)

SK bắt đầu với các bộ lập kế hoạch rõ ràng phân tách một mục tiêu thành các bước. Framework này sau đó đã chuyển sang gọi hàm, nơi chính mô hình quyết định các hàm nào sẽ được gọi và theo thứ tự nào, điều này đáng tin cậy hơn với các mô hình hiện đại. Trên hết, SK đã thêm một lớp Agent Framework để xây dựng các tác nhân và các mô hình đa tác nhân, với trạng thái dựa trên phiên (session-based state), các vòng lặp tác nhân (agentic loops) và hỗ trợ Giao thức Ngữ cảnh Mô hình (Model Context Protocol - MCP) để kết nối các công cụ bên ngoài.

Nếu bạn đang so sánh các cách tiếp cận, đây là cách SK so sánh với các SDK tác nhân khác được đề cập trên blog này.

Framework	Ngôn ngữ chính	Mô hình điều phối	Phù hợp nhất
Semantic Kernel	C#/.NET, Python, Java	Gọi hàm + tác nhân	Các đội .NET và doanh nghiệp
LangGraph	Python, JS	Đồ thị trạng thái rõ ràng	Các luồng tác nhân phức tạp, phân nhánh
Google ADK	Python	Mô hình tác nhân + công cụ	Nền tảng Google Cloud và Gemini
OpenAI Agents SDK	Python, JS	Tác nhân + chuyển giao	Ứng dụng tập trung vào OpenAI

Không có cái nào trong số này tốt hơn một cách tuyệt đối. Lựa chọn phù hợp phụ thuộc vào ngôn ngữ của bạn, nhà cung cấp mô hình của bạn và mức độ kiểm soát rõ ràng bạn muốn đối với việc thực thi.

Semantic Kernel phù hợp ở đâu với Microsoft Agent Framework

Phần này phát triển nhanh chóng, vì vậy đây là tình trạng thực tế của mọi thứ. Microsoft đã giới thiệu Microsoft Agent Framework (MAF), và tài liệu mô tả nó là người kế nhiệm trực tiếp của cả Semantic Kernel và AutoGen, được xây dựng bởi cùng một nhóm. MAF kết hợp các khả năng trừu tượng hóa tác nhân của AutoGen với các tính năng dành cho doanh nghiệp của SK và bổ sung các quy trình làm việc dựa trên đồ thị để điều phối đa tác nhân.

Điều đó có nghĩa trên thực tế:

Semantic Kernel ổn định và vẫn được hỗ trợ. Các ứng dụng SK hiện có vẫn hoạt động, và cam kết không phá vỡ tính tương thích ngược (non-breaking-change) phiên bản 1.0+ vẫn được giữ nguyên.
Đối với các dự án tác nhân hoàn toàn mới, Microsoft hướng bạn đến Agent Framework, và xuất bản hướng dẫn di chuyển mã SK sang đó.
Ý tưởng OpenAPI-thành-plugin được tiếp tục. Cấp quyền truy cập cho một tác nhân vào REST API của bạn thông qua một đặc tả là một mô hình mà cả hai framework đều chia sẻ.

Vì vậy, hãy coi SK là một lựa chọn vững chắc, đã được kiểm chứng trong sản xuất và vẫn đang được duy trì, đồng thời biết rằng khoản đầu tư mới nhất đang hướng vào MAF. Nếu bạn đang quyết định hôm nay và mã của bạn đã nằm trong SK, không cần phải vội vàng thay đổi. Nếu bạn bắt đầu mới và muốn theo hướng mới nhất, hãy đọc tài liệu MAF trước khi cam kết.

Khi nào nên sử dụng Semantic Kernel

Hãy tìm đến SK khi:

Nền tảng của bạn là .NET hoặc Java và bạn muốn điều phối AI mà cảm thấy tự nhiên thay vì một sidecar Python.
Bạn có một danh mục các REST API hiện có và muốn một mô hình gọi chúng thông qua các đặc tả OpenAPI của chúng.
Bạn cần các tính năng cấp doanh nghiệp: telemetry, filters, hooks và khả năng kiểm toán những gì AI đã làm.
Bạn muốn giữ tính độc lập với mô hình và thay đổi nhà cung cấp mà không cần viết lại ứng dụng của mình.

Hãy tìm nơi khác khi đội ngũ của bạn chỉ dùng Python và bạn muốn các tính năng đa tác nhân mới nhất tuyệt đối, trong trường hợp đó MAF hoặc một thư viện ưu tiên đồ thị có thể phù hợp hơn với bạn.

Kiểm thử các API đằng sau tác nhân Semantic Kernel của bạn

Đây là nơi các công cụ API trở nên quan trọng, và là nơi Apidog phù hợp một cách hoàn hảo. SK không xây dựng hay thay thế API của bạn. Nó gọi các API đó. Một tác nhân SK phụ thuộc vào hai loại endpoint: endpoint của LLM mà nó giao tiếp, và các REST API bạn nhập dưới dạng plugin OpenAPI. Cả hai đều cần phải chính xác, được mô tả rõ ràng và đáng tin cậy, nếu không tác nhân sẽ gọi sai.

Một vài công việc thực tế:

Thiết kế và kiểm thử đặc tả OpenAPI trước khi bạn nhập nó. Vì SK biến mỗi thao tác thành một hàm và cung cấp mô tả tham số của bạn cho mô hình, một đặc tả cẩu thả sẽ tạo ra các lệnh gọi công cụ cẩu thả. Xác thực đặc tả, thực hành mọi endpoint và xác nhận phản hồi khớp với lược đồ. Hợp đồng rõ ràng, tác nhân tốt hơn.
Giả lập các phụ thuộc trong quá trình phát triển. Bạn có thể thiết lập một API giả lập cho một endpoint chưa được xây dựng, hoặc giả lập endpoint LLM để tránh lãng phí token và vượt quá giới hạn tốc độ khi bạn gỡ lỗi vòng lặp điều phối. Xem cách giả lập các lệnh gọi API để biết mẫu.
Xác nhận cấu trúc phản hồi. Sử dụng các xác nhận API để xác minh rằng các endpoint công cụ mà tác nhân của bạn gọi trả về đúng cấu trúc mà mô hình mong đợi, để một thay đổi backend không làm hỏng hành vi của tác nhân một cách âm thầm.
Quản lý khóa theo từng môi trường. Giữ thông tin đăng nhập LLM và API của bạn tách biệt giữa các môi trường dev, staging và prod thay vì mã hóa cứng chúng.

Đây là công việc API thông thường, được thực hiện trước và xung quanh tác nhân, chứ không phải thay thế nó. Nếu bạn muốn tìm hiểu sâu hơn, kiểm thử các lệnh gọi công cụ của tác nhân bằng Apidog sẽ trình bày chi tiết.

Các câu hỏi thường gặp

Semantic Kernel có miễn phí và mã nguồn mở không?

Có. Semantic Kernel là mã nguồn mở và được Microsoft xuất bản trên GitHub theo giấy phép cho phép, với các SDK cho C#/.NET, Python và Java. Bạn trả tiền cho việc sử dụng mô hình (OpenAI, Azure OpenAI, v.v.), chứ không phải cho bản thân SK.

Semantic Kernel hỗ trợ những ngôn ngữ nào?

C#/.NET, Python và Java, tất cả đều có cam kết ổn định phiên bản 1.0+. SDK C# là trưởng thành nhất, nhưng các SDK Python và Java bao gồm các tính năng kernel cốt lõi, plugin và nhập OpenAPI.

Semantic Kernel sử dụng đặc tả OpenAPI như thế nào?

Bạn nhập một đặc tả bằng ImportPluginFromOpenApiAsync (C#) hoặc add_plugin_from_openapi (Python). SK phân tích đặc tả, biến mỗi thao tác thành một hàm có thể gọi với siêu dữ liệu tham số của nó và cho phép mô hình gọi các thao tác đó. Vì mô hình dựa vào mô tả của bạn, điều quan trọng là phải xác thực đặc tả trước. Bạn có thể làm điều đó, và kiểm thử các endpoint trực tiếp, với Apidog.

Tôi nên sử dụng Semantic Kernel hay Microsoft Agent Framework?

Nếu bạn đã có một ứng dụng SK, hãy tiếp tục sử dụng nó; nó được hỗ trợ và ổn định. Đối với các dự án mới, Microsoft định vị Agent Framework là người kế nhiệm và cung cấp hướng dẫn di chuyển. Kiểm tra tài liệu MAF hiện tại trước khi bắt đầu mới, vì lĩnh vực này đang thay đổi nhanh chóng. Để kiểm tra các API mà một trong hai gọi, hãy xem cách kiểm thử ChatGPT API bằng Apidog.

Tóm lại

Semantic Kernel mang đến cho các nhóm phát triển trên nền tảng Microsoft một cách rõ ràng để điều phối AI: một kernel kết nối các mô hình với mã của bạn, các plugin và hàm mà mô hình có thể gọi, và một đường dẫn nhập OpenAPI giúp phơi bày các REST API hiện có của bạn như các công cụ tác nhân. Nó ổn định và đã được kiểm chứng trong sản xuất, với Agent Framework hiện đang định hướng phát triển mới nhất. Dù bạn chọn cái nào, các API bên dưới vẫn cần phải vững chắc. Để thiết kế, giả lập và kiểm thử các đặc tả và endpoint mà tác nhân của bạn phụ thuộc, hãy tải Apidog và xây dựng hợp đồng trước khi tác nhân gọi nó.