Thanawat Wongchai

Posted on Jun 26 • Originally published at apidog.com

Semantic Kernel คืออะไร: SDK จัดการ AI ของ Microsoft

หากคุณพัฒนาซอฟต์แวร์บน Microsoft stack และต้องการเพิ่ม AI โดยไม่ต้องผูกบริการ Python เข้าไปเสริม Semantic Kernel คือ SDK โอเพนซอร์สจาก Microsoft สำหรับเชื่อมโค้ดและ API ที่มีอยู่กับโมเดลภาษาขนาดใหญ่ รองรับ C#, Python และ Java บทความนี้สรุปวิธีใช้ Semantic Kernel แบบลงมือทำ: kernel, plugins, functions, การนำเข้า OpenAPI specification และแนวทางทดสอบ API ที่เอเจนต์จะเรียกใช้งาน

ลองใช้ Apidog วันนี้

Semantic Kernel คืออะไร

Semantic Kernel (SK) เป็น SDK โอเพนซอร์สจาก Microsoft สำหรับสร้างเอเจนต์ AI และผสานโมเดลเข้ากับโค้ดเบสของคุณ มองง่ายๆ คือ middleware ระหว่างแอปพลิเคชันกับโมเดล: รับคำสั่งจากโมเดล แปลงเป็นการเรียกฟังก์ชันจริง รันโค้ด แล้วส่งผลลัพธ์กลับไปให้โมเดล

จุดที่ทำให้ SK เหมาะกับงานจริงมี 3 เรื่องหลัก:

รองรับหลายภาษา: มี SDK อย่างเป็นทางการสำหรับ C#/.NET, Python และ Java พร้อมความเสถียรระดับ 1.0+
ไม่ผูกกับโมเดลเดียว: เชื่อมต่อ OpenAI, Azure OpenAI และผู้ให้บริการอื่นผ่าน connector ได้
ออกแบบสำหรับองค์กร: รองรับ telemetry, hooks และ filters เพื่อบันทึก ตรวจสอบ และควบคุมสิ่งที่ AI ทำ

ถ้า backend ของคุณเป็น .NET และต้องการนำ AI เข้ามาโดยไม่สร้าง Python sidecar เพิ่ม Semantic Kernel เป็นตัวเลือกที่ควรพิจารณา

แกนหลัก: kernel, plugins และ functions

ออบเจกต์หลักของ SK คือ Kernel ซึ่งทำหน้าที่คล้าย dependency injection container สำหรับ AI คุณลงทะเบียน model connector และ plugin ไว้ใน kernel จากนั้นให้ kernel จัดการลูปการทำงาน:

รับ prompt หรือข้อความจากผู้ใช้
เรียกโมเดล
ตรวจว่าต้องเรียก function หรือไม่
รัน function จริงในโค้ดของคุณ
ส่งผลลัพธ์กลับไปยังโมเดล
คืนคำตอบสุดท้าย

ใน SK มีแนวคิดสำคัญ 2 ระดับ:

Plugin: กลุ่มของฟังก์ชันที่เปิดให้โมเดลเรียกใช้
Function: ความสามารถหนึ่งรายการที่โมเดลสามารถเรียกได้

ฟังก์ชันมี 2 ประเภทหลัก:

Native functions: เมธอดปกติในโค้ด เช่น C# method หรือ Python function ที่ annotate เพื่อให้โมเดลเข้าใจ
Prompt functions: prompt template ที่เรียกโมเดลอีกครั้ง เหมาะกับงานสรุป จัดหมวดหมู่ หรือ rewrite ข้อความ

ตัวอย่าง C# ขั้นพื้นฐาน:

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
    modelId: "gpt-4o",
    apiKey: apiKey
);

builder.Plugins.AddFromType<LightsPlugin>("Lights");

Kernel kernel = builder.Build();

var result = await kernel.InvokePromptAsync(
    "Turn the kitchen light blue"
);

ตัวอย่าง plugin แบบ native function:

using Microsoft.SemanticKernel;
using System.ComponentModel;

public class LightsPlugin
{
    [KernelFunction("change_light_state")]
    [Description("Change the state and color of a light")]
    public string ChangeLightState(
        [Description("The room name, for example kitchen or bedroom")]
        string room,
        [Description("The target color")]
        string color
    )
    {
        // เรียก service หรือ API จริงของคุณที่นี่
        return $"Changed {room} light to {color}";
    }
}

เมื่อโมเดลตัดสินใจว่า intent ของผู้ใช้ต้องใช้ change_light_state kernel จะรันเมธอดจริง บันทึกผลลัพธ์ และส่งกลับไปยังโมเดลเพื่อสร้างคำตอบสุดท้าย

รูปแบบ OpenAPI-to-plugin

จุดที่มีประโยชน์มากของ Semantic Kernel คือการนำเข้า OpenAPI specification แล้วเปลี่ยนแต่ละ operation ให้เป็น function ที่โมเดลเรียกได้โดยอัตโนมัติ

แทนที่จะเขียน wrapper เองทุก endpoint คุณสามารถ:

เตรียม OpenAPI spec ของ REST API
ให้ SK import spec
ให้โมเดลเรียก operation ที่เหมาะสมผ่าน function calling
ให้ SK สร้าง HTTP request และจัดการ response

ตัวอย่าง C#:

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

ใน Python แนวคิดเดียวกันคือใช้ add_plugin_from_openapi ส่วน Java ก็มี importer ที่เทียบเท่า

เบื้องหลัง SK จะ:

อ่าน path และ operation จาก OpenAPI spec
ดึงชื่อ คำอธิบาย parameter type และ schema
แปลง operation เป็น callable function
ส่ง metadata เหล่านี้ให้โมเดล
สร้าง HTTP request เมื่อโมเดลเลือกเรียก operation
อ่าน response แล้วส่งกลับเข้า context ของโมเดล

SK รองรับ OpenAPI 2.0 และ 3.0 และสามารถ downgrade 3.1 เป็น 3.0 ได้หากทำได้

เช็กลิสต์สำหรับทำ OpenAPI spec ให้เหมาะกับเอเจนต์

OpenAPI spec ที่เขียนเพื่อมนุษย์อ่านได้ อาจยังไม่ชัดพอสำหรับโมเดล ก่อนนำเข้า SK ควรตรวจรายการเหล่านี้:

ใช้ operationId ที่สื่อความหมาย เช่น getCustomerById แทน getData
เขียน description ของ endpoint ให้บอก intent ชัดเจน
เขียนคำอธิบาย parameter ให้บอก format และข้อจำกัด
ใช้ enum เมื่อค่าที่รับได้มีจำนวนจำกัด
หลีกเลี่ยง string กว้างๆ ที่ไม่มี schema ชัดเจน
แยก endpoint ที่จำเป็นจริงๆ ให้โมเดลใช้ ไม่ต้องเปิดทั้งระบบ
ตรวจ response schema ให้ตรงกับของจริง

ตัวอย่าง schema ที่ช่วยให้โมเดลเลือกใช้งานได้ดีขึ้น:

paths:
  /lights/{room}/state:
    post:
      operationId: changeLightState
      summary: Change light state in a specific room
      description: Use this operation to change the color or power state of a room light.
      parameters:
        - name: room
          in: path
          required: true
          description: Room name, such as kitchen, bedroom, or living_room.
          schema:
            type: string
            enum: [kitchen, bedroom, living_room]
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - color
              properties:
                color:
                  type: string
                  description: Target light color.
                  enum: [red, blue, green, white]

คุณภาพของ spec ส่งผลโดยตรงต่อคุณภาพของการเรียก tool ของเอเจนต์

เอเจนต์และการวางแผน

Semantic Kernel เริ่มจากแนวคิด planner ที่แยกเป้าหมายเป็นขั้นตอน แต่แนวทางปัจจุบันขยับไปใช้ function calling มากขึ้น โดยให้โมเดลตัดสินใจเองว่าจะเรียก function ใดและเรียกตามลำดับใด ซึ่งเข้ากับโมเดลสมัยใหม่ได้ดีกว่า

นอกจากนี้ SK ยังมี Agent Framework layer สำหรับ:

session-based state
agent loop
multi-agent pattern
การเชื่อมต่อเครื่องมือภายนอกผ่าน Model Context Protocol (MCP)

ถ้าคุณกำลังเลือก framework สำหรับงานเอเจนต์ ภาพรวมเปรียบเทียบมีดังนี้:

เฟรมเวิร์ก	ภาษาหลัก	โมเดลการจัดการ	เหมาะที่สุดสำหรับ
Semantic Kernel	C#/.NET, Python, Java	การเรียกฟังก์ชัน + เอเจนต์	ทีม .NET และองค์กร
LangGraph	Python, JS	กราฟสถานะที่ชัดเจน	เวิร์กโฟลว์เอเจนต์ที่ซับซ้อนและมีการแตกแขนง
Google ADK	Python	โมเดลเอเจนต์ + เครื่องมือ	สแต็ก Google Cloud และ Gemini
OpenAI Agents SDK	Python, JS	เอเจนต์ + การส่งต่อ	แอปที่เน้น OpenAI เป็นหลัก

ไม่มีตัวเลือกที่ดีที่สุดสำหรับทุกกรณี ให้เลือกจากภาษาหลักของทีม provider ของโมเดล และระดับการควบคุม workflow ที่ต้องการ

Semantic Kernel เหมาะกับ Microsoft Agent Framework อย่างไร

Microsoft ได้เปิดตัว Microsoft Agent Framework (MAF) และเอกสารระบุว่าเป็นผู้สืบทอดโดยตรงของทั้ง Semantic Kernel และ AutoGen ซึ่งพัฒนาโดยทีมเดียวกัน MAF รวมแนวคิดเอเจนต์จาก AutoGen เข้ากับคุณสมบัติระดับองค์กรของ SK และเพิ่ม workflow แบบ graph สำหรับ multi-agent orchestration

ในทางปฏิบัติ:

แอป Semantic Kernel ที่มีอยู่ยังใช้งานต่อได้ และ SK ยังได้รับการสนับสนุน
โปรเจกต์ใหม่ที่ต้องการทิศทางล่าสุดควรอ่านเอกสาร MAF ก่อนเริ่ม
รูปแบบ OpenAPI-to-plugin ยังเป็นแนวทางสำคัญในทั้งสองเฟรมเวิร์ก
ถ้าคุณมีโค้ด SK อยู่แล้ว ไม่จำเป็นต้องรีบย้ายทันที
ถ้าคุณเริ่มใหม่และต้องทำ multi-agent ซับซ้อน ให้ประเมิน MAF ด้วย

สรุปคือ SK ยังเป็นตัวเลือกที่มั่นคงสำหรับ production โดยเฉพาะใน stack .NET ส่วน MAF คือทิศทางใหม่ที่ Microsoft กำลังลงทุนต่อ

เมื่อใดควรใช้ Semantic Kernel

เลือกใช้ Semantic Kernel เมื่อ:

backend ของคุณคือ .NET หรือ Java
คุณไม่ต้องการเพิ่ม Python service แยกเพื่อจัดการ AI
คุณมี REST API อยู่แล้วและต้องการให้โมเดลเรียกผ่าน OpenAPI spec
คุณต้องการ telemetry, filters, hooks และ auditability
คุณต้องการเปลี่ยน provider ของโมเดลได้โดยไม่ rewrite ทั้งแอป
คุณต้องการเริ่มจาก function calling ก่อน แล้วค่อยต่อยอดเป็น agent

ควรมองหาทางเลือกอื่นเมื่อ:

ทีมใช้ Python เป็นหลักทั้งหมด
ต้องการ multi-agent workflow ใหม่ล่าสุด
ต้องการ graph-based orchestration ที่ควบคุม state ทุกจุดอย่างชัดเจน

ในกรณีนั้น MAF หรือ framework แบบ graph-first อาจเหมาะกว่า

การทดสอบ API ที่อยู่เบื้องหลังเอเจนต์ Semantic Kernel

Semantic Kernel ไม่ได้แทนที่ API ของคุณ แต่มันเรียกใช้ API เหล่านั้น ดังนั้นคุณภาพของเอเจนต์ขึ้นอยู่กับคุณภาพของ endpoint และ OpenAPI spec โดยตรง

Apidog มีประโยชน์ในจุดนี้ เพราะช่วยออกแบบ ทดสอบ mock และตรวจสัญญา API ก่อนนำไปใช้กับเอเจนต์

งานที่ควรทำก่อนให้ SK import OpenAPI spec:

1. ตรวจ OpenAPI spec ก่อนนำเข้า

เพราะ SK ใช้ชื่อ operation, description, parameter และ schema จาก spec เพื่ออธิบาย tool ให้โมเดล ถ้า spec คลุมเครือ โมเดลก็มีโอกาสเรียก tool ผิด

ตรวจให้ครบ:

endpoint มี operationId
parameter มี type และ description
request body มี schema
response ตรงกับของจริง
auth mechanism ชัดเจน
error response ถูกระบุไว้

2. Mock API ระหว่างพัฒนา

ถ้า endpoint ยังไม่พร้อม คุณสามารถสร้าง mock API เพื่อให้ SK เรียกได้ก่อน วิธีนี้ช่วยแยกการพัฒนา agent loop ออกจาก backend จริง

ดูรูปแบบเพิ่มเติมได้ที่ วิธีจำลองการเรียกใช้ API

3. ยืนยัน response shape ด้วย assertions

ใช้ API assertions เพื่อตรวจว่า endpoint ที่เอเจนต์เรียกยังส่ง response ตาม schema ที่คาดหวัง เช่น:

field สำคัญต้องมีเสมอ
type ต้องตรง
status code ต้องถูกต้อง
error format ต้องคงที่

วิธีนี้ช่วยลดกรณีที่ backend เปลี่ยนแล้วพฤติกรรมของเอเจนต์เสียโดยไม่รู้ตัว

4. แยก environment และ credential

อย่าฮาร์ดโค้ด LLM key หรือ API key ในโค้ด agent ให้แยก environment เช่น:

dev
staging
prod

และใช้ key คนละชุดสำหรับแต่ละ environment เพื่อลดความเสี่ยงและควบคุม quota ได้ง่ายขึ้น

ถ้าต้องการตัวอย่างการทดสอบ tool call ของเอเจนต์แบบละเอียด ดู การทดสอบการเรียกใช้เครื่องมือของเอเจนต์ด้วย Apidog

คำถามที่พบบ่อย

Semantic Kernel เป็นโอเพนซอร์สและฟรีหรือไม่?

ใช่ Semantic Kernel เป็นโอเพนซอร์สและเผยแพร่โดย Microsoft บน GitHub ภายใต้ permissive license มี SDK สำหรับ C#/.NET, Python และ Java คุณจ่ายค่าการใช้งานโมเดล เช่น OpenAI หรือ Azure OpenAI ไม่ใช่ตัว SK เอง

Semantic Kernel รองรับภาษาใดบ้าง?

รองรับ C#/.NET, Python และ Java โดยทั้งหมดมีความเสถียรระดับ 1.0+ SDK สำหรับ C# มักสมบูรณ์ที่สุด แต่ Python และ Java ก็ครอบคลุมฟีเจอร์หลัก เช่น kernel, plugins และการนำเข้า OpenAPI

Semantic Kernel ใช้ OpenAPI specs อย่างไร?

คุณนำเข้าสเปกด้วย ImportPluginFromOpenApiAsync ใน C# หรือ add_plugin_from_openapi ใน Python จากนั้น SK จะเปลี่ยนแต่ละ operation ให้เป็น function ที่โมเดลเรียกได้ พร้อม metadata ของ parameter และ schema

ก่อนนำเข้า ควรตรวจ spec และทดสอบ endpoint จริงด้วย Apidog เพื่อให้แน่ใจว่า contract ถูกต้อง

ฉันควรใช้ Semantic Kernel หรือ Microsoft Agent Framework ดี?

ถ้ามีแอป Semantic Kernel อยู่แล้ว ให้ใช้ต่อได้ เพราะยังได้รับการสนับสนุนและมีความเสถียร ถ้าเริ่มโปรเจกต์ใหม่ ให้ตรวจเอกสาร Microsoft Agent Framework ล่าสุดก่อน เพราะ Microsoft วางให้เป็นผู้สืบทอดของ SK และ AutoGen

สำหรับการทดสอบ API ที่ framework เหล่านี้เรียกใช้ ดู วิธีทดสอบ ChatGPT API ด้วย Apidog

สรุป

Semantic Kernel เป็นวิธีที่ตรงไปตรงมาสำหรับทีมบน Microsoft stack ที่ต้องการเพิ่ม AI เข้าแอป: ใช้ kernel เชื่อมโมเดลกับโค้ด ใช้ plugins/functions เปิดความสามารถให้โมเดล และใช้ OpenAPI import เพื่อเปลี่ยน REST API ที่มีอยู่ให้เป็น tool ของเอเจนต์

ถ้าคุณใช้ .NET, Java หรือมี API จำนวนมากที่ต้องการให้โมเดลเรียกใช้งาน SK เป็นตัวเลือกที่ใช้งานได้จริงและเหมาะกับ production ส่วน Microsoft Agent Framework คือทิศทางใหม่ที่ควรติดตามสำหรับโปรเจกต์เอเจนต์รุ่นถัดไป

ไม่ว่าจะเลือกทางไหน API ที่เอเจนต์เรียกต้องถูกต้องและทดสอบได้ก่อนเสมอ หากต้องการออกแบบ mock และทดสอบ OpenAPI spec กับ endpoint ที่เอเจนต์พึ่งพา ให้ ดาวน์โหลด Apidog และสร้าง contract ให้ชัดเจนก่อนปล่อยให้เอเจนต์เรียกใช้งาน

DEV Community