Jika Anda membangun perangkat lunak di ekosistem Microsoft dan ingin menambahkan AI tanpa harus menyambungkan layanan Python secara terpisah, Semantic Kernel adalah SDK yang dibuat Microsoft untuk Anda. Ini adalah perangkat sumber terbuka yang menghubungkan kode dan API Anda yang ada ke model bahasa besar, dan berjalan di C#, Python, dan Java. Panduan ini menjelaskan apa itu, bagaimana kernel dan plugin bekerja sama, serta bagaimana dukungan spesifikasi OpenAPI-nya mengubah setiap REST API menjadi sesuatu yang dapat dipanggil oleh model.
Apa Sebenarnya Semantic Kernel
Semantic Kernel (SK) adalah perangkat pengembangan sumber terbuka yang ringan dari Microsoft untuk membangun agen AI dan mengintegrasikan model ke dalam codebase Anda. Microsoft menggambarkannya sebagai middleware: ia berada di antara aplikasi Anda dan model, menerjemahkan permintaan model menjadi panggilan fungsi nyata, menjalankannya, dan mengembalikan hasilnya. Anda menulis kode normal. Model memutuskan kapan akan memanggilnya.
Tiga hal yang membuat SK menonjol dari kerumunan pustaka agen.
Pertama, ia benar-benar multi-bahasa. SK menyediakan SDK resmi untuk C#/.NET, Python, dan Java, dengan komitmen stabilitas versi 1.0+ di ketiganya. Sebagian besar kerangka kerja agen mengutamakan Python dan menganggap bahasa lain sebagai pelengkap. Jika backend Anda adalah .NET, SK adalah salah satu dari sedikit pilihan matang yang terasa alami.
Kedua, ia agnostik model. SK terhubung ke OpenAI, Azure OpenAI, dan penyedia lain melalui serangkaian konektor. Saat Anda ingin mengganti model, Anda mengubah konfigurasi, bukan seluruh aplikasi Anda.
Ketiga, ia dibangun dengan mempertimbangkan masalah perusahaan. Telemetri, kait (hooks), dan filter adalah kelas satu, sehingga Anda dapat mencatat, mengaudit, dan mencegat apa yang dilakukan AI. Fokus itulah mengapa Microsoft dan sejumlah tim Fortune 500 mengadopsinya.
Kernel, Plugin, dan Fungsi
Objek intinya adalah kernel. Anggap saja sebagai wadah injeksi dependensi untuk AI. Anda mendaftarkan konektor model dan plugin Anda pada kernel, lalu memintanya untuk menjalankan berbagai hal. Kernel menangani orkestrasi: prompt, panggilan model, panggilan fungsi, hasil, ulangi.
Plugin adalah kelompok fungsi bernama yang Anda ekspos ke model. Fungsi adalah satu kapabilitas yang dapat dipanggil model. Fungsi datang dalam dua rasa:
- Fungsi native adalah metode reguler dalam kode Anda (metode C#, fungsi Python) yang Anda anotasi sehingga kernel dapat mendeskripsikannya kepada model.
- Fungsi prompt adalah prompt yang diberi template yang memanggil model itu sendiri, berguna untuk meringkas, mengklasifikasi, atau menulis ulang teks.
Ini adalah bentuknya di C#. Anda membangun kernel, mendaftarkan model chat, menambahkan plugin, dan membiarkan model memanggil fungsi saat dibutuhkan.
var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();
// Model sekarang dapat memanggil fungsi LightsPlugin selama obrolan
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");
Ketika model kembali dan kernel melihat bahwa ia ingin memanggil `change_light_state`, kernel menjalankan kode Anda, menangkap hasilnya, dan memberikannya kembali ke model. Loop itu adalah inti dari SK.
Pola OpenAPI-ke-Plugin
Ini adalah fitur yang paling layak diketahui, dan ini adalah jembatan paling bersih ke layanan Anda yang ada. SK dapat mengimpor spesifikasi OpenAPI dan secara otomatis mengubah setiap operasi menjadi fungsi yang dapat dipanggil. Anda tidak menulis kode pembungkus (wrapper code). Anda mengarahkan SK ke spesifikasi, dan setiap jalur/operasi menjadi fungsi yang dapat dipanggil model.
Di C# panggilannya adalah `ImportPluginFromOpenApiAsync`. Di Python adalah `add_plugin_from_openapi`. Java memiliki importir yang setara. Berikut adalah versi C# yang memuat spesifikasi dari URL:
await kernel.ImportPluginFromOpenApiAsync(
pluginName: "lights",
uri: new Uri("https://example.com/v1/swagger.json"),
executionParameters: new OpenApiFunctionExecutionParameters()
{
EnablePayloadNamespacing = true
}
);
Di balik layar, SK mengurai spesifikasi, mengekstrak nama, deskripsi, tipe, dan skema untuk setiap parameter, dan menyerahkan metadata tersebut kepada model. Model mempertimbangkan operasi mana yang akan dipanggil dan argumen apa yang akan diteruskan. SK kemudian membangun permintaan HTTP, menerapkan callback otentikasi Anda, mengirimkannya, dan membaca responsnya kembali. SK mendukung OpenAPI 2.0 dan 3.0, serta menurunkan spesifikasi 3.1 ke 3.0 jika memungkinkan.
Kendalanya adalah spesifikasi yang ditulis untuk manusia tidak selalu jelas bagi model. Pedoman Microsoft sendiri adalah menambahkan ID operasi deskriptif, menulis deskripsi parameter yang membantu, menjaga jumlah endpoint tetap rendah, dan lebih memilih enum dan parameter berjenis daripada string bebas. Kualitas spesifikasi Anda secara langsung membentuk seberapa baik agen memanggil API Anda. Itu membuat spesifikasi itu sendiri menjadi hal yang patut dirancang dan diuji dengan cermat, bukan sekadar pelengkap.
Agen dan Perencanaan
SK dimulai dengan perencana eksplisit yang menguraikan tujuan menjadi langkah-langkah. Kerangka kerja ini kemudian bergeser ke panggilan fungsi, di mana model itu sendiri memutuskan fungsi mana yang akan dipanggil dan dalam urutan apa, yang lebih dapat diandalkan dengan model modern. Selain itu, SK menambahkan lapisan Kerangka Kerja Agen untuk membangun agen dan pola multi-agen, dengan status berbasis sesi, loop agen, dan dukungan Model Context Protocol (MCP) untuk menghubungkan alat eksternal.
Jika Anda membandingkan pendekatan, berikut adalah bagaimana SK sejajar dengan SDK agen lain yang dibahas di blog ini.
| Kerangka Kerja | Bahasa Utama | Model Orkestrasi | Paling Cocok |
|---|---|---|---|
| Semantic Kernel | C#/.NET, Python, Java | Panggilan fungsi + agen | Tim .NET dan perusahaan |
| LangGraph | Python, JS | Grafik status eksplisit | Alur agen yang kompleks dan bercabang |
| Google ADK | Python | Model agen + alat | Tumpukan Google Cloud dan Gemini |
| OpenAI Agents SDK | Python, JS | Agen + serah terima | Aplikasi yang berpusat pada OpenAI |
Tidak ada di antara ini yang secara ketat lebih baik. Pilihan yang tepat tergantung pada bahasa Anda, penyedia model Anda, dan seberapa banyak kontrol eksplisit atas eksekusi yang Anda inginkan.
Di Mana Semantic Kernel Cocok dengan Microsoft Agent Framework
Bagian ini bergerak cepat, jadi ini adalah kondisi jujur dari segala sesuatu. Microsoft memperkenalkan Microsoft Agent Framework (MAF), dan dokumen-dokumennya menggambarkannya sebagai penerus langsung Semantic Kernel dan AutoGen, yang dibangun oleh tim yang sama. MAF menggabungkan abstraksi agen AutoGen dengan fitur perusahaan SK dan menambahkan alur kerja berbasis grafik untuk orkestrasi multi-agen.
Apa artinya dalam praktik:
- Semantic Kernel stabil dan masih didukung. Aplikasi SK yang ada tetap berfungsi, dan komitmen perubahan non-breaking 1.0+ tetap berlaku.
- Untuk proyek agen yang benar-benar baru, Microsoft mengarahkan Anda ke Agent Framework, dan menerbitkan panduan migrasi untuk memindahkan kode SK.
- Ide OpenAPI-ke-plugin terus berlanjut. Memberikan agen akses ke REST API Anda melalui spesifikasi adalah pola yang dimiliki oleh kedua kerangka kerja.
Jadi, anggap SK sebagai pilihan yang solid dan terbukti di produksi yang masih dipertahankan, sambil mengetahui bahwa investasi terbaru masuk ke MAF. Jika Anda memutuskan hari ini dan kode Anda sudah ada di SK, tidak ada alasan mendesak. Jika Anda memulai yang baru dan menginginkan arah terbaru, baca dokumen MAF sebelum Anda berkomitmen.
Kapan Menggunakan Semantic Kernel
Gunakan SK ketika:
- Tumpukan Anda adalah .NET atau Java dan Anda menginginkan orkestrasi AI yang terasa native alih-alih sidecar Python.
- Anda memiliki portofolio REST API yang ada dan ingin model memanggilnya melalui spesifikasi OpenAPI mereka.
- Anda membutuhkan dukungan perusahaan: telemetri, filter, hooks, dan kemampuan untuk mengaudit apa yang dilakukan AI.
- Anda ingin tetap agnostik model dan menukar penyedia tanpa menulis ulang aplikasi Anda.
Cari di tempat lain jika tim Anda hanya menggunakan Python dan Anda menginginkan fitur multi-agen terbaru, dalam hal ini MAF atau pustaka yang mengutamakan grafik mungkin lebih cocok untuk Anda.
Menguji API di Balik Agen Semantic Kernel Anda
Di sinilah alat API menjadi penting, dan di sinilah Apidog sangat cocok. SK tidak membangun atau mengganti API Anda. Ia memanggilnya. Agen SK bergantung pada dua jenis endpoint: endpoint LLM yang berkomunikasi dengannya, dan REST API yang Anda impor sebagai plugin OpenAPI. Keduanya harus benar, dijelaskan dengan baik, dan dapat diandalkan, atau agen akan membuat panggilan yang buruk.
Beberapa tugas praktis:
- Rancang dan uji spesifikasi OpenAPI sebelum Anda mengimpornya. Karena SK mengubah setiap operasi menjadi fungsi dan memberikan deskripsi parameter Anda kepada model, spesifikasi yang ceroboh menghasilkan panggilan alat yang ceroboh. Validasi spesifikasi, uji setiap endpoint, dan konfirmasikan respons sesuai dengan skema. Kontrak yang bersih, agen yang lebih baik.
- Moc dependensi selama pengembangan. Anda dapat menyiapkan mock API untuk endpoint yang belum dibuat, atau memoc endpoint LLM untuk menghindari pembakaran token dan mencapai batas laju saat Anda men-debug loop orkestrasi. Lihat cara memoc panggilan API untuk polanya.
- Tegaskan bentuk respons. Gunakan penegasan API untuk memverifikasi bahwa endpoint alat yang dipanggil agen Anda mengembalikan struktur yang persis seperti yang diharapkan model, sehingga perubahan backend tidak secara diam-diam merusak perilaku agen.
- Kelola kunci per lingkungan. Jaga kredensial LLM dan API Anda terpisah di seluruh lingkungan dev, staging, dan prod daripada mengodekannya secara langsung.
Ini adalah pekerjaan API biasa, dilakukan sebelum dan di sekitar agen, bukan sebagai penggantinya. Jika Anda ingin panduan lebih mendalam, menguji panggilan alat agen dengan Apidog mencakup harness secara detail.
Pertanyaan yang Sering Diajukan
Apakah Semantic Kernel gratis dan sumber terbuka?
Ya. Semantic Kernel adalah sumber terbuka dan diterbitkan oleh Microsoft di GitHub di bawah lisensi permisif, dengan SDK untuk C#/.NET, Python, dan Java. Anda membayar untuk penggunaan model (OpenAI, Azure OpenAI, dan sebagainya), bukan untuk SK itu sendiri.
Bahasa apa saja yang didukung Semantic Kernel?
C#/.NET, Python, dan Java, semuanya dengan komitmen stabilitas versi 1.0+. SDK C# adalah yang paling matang, tetapi SDK Python dan Java mencakup fitur inti kernel, plugin, dan impor OpenAPI.
Bagaimana Semantic Kernel menggunakan spesifikasi OpenAPI?
Anda mengimpor spesifikasi dengan `ImportPluginFromOpenApiAsync` (C#) atau `add_plugin_from_openapi` (Python). SK mengurai spesifikasi, mengubah setiap operasi menjadi fungsi yang dapat dipanggil dengan metadata parameternya, dan membiarkan model memanggil operasi tersebut. Karena model bergantung pada deskripsi Anda, penting untuk memvalidasi spesifikasi terlebih dahulu. Anda dapat melakukannya, dan menguji endpoint langsung, dengan Apidog.
Haruskah saya menggunakan Semantic Kernel atau Microsoft Agent Framework?
Jika Anda sudah memiliki aplikasi SK, terus gunakan; itu didukung dan stabil. Untuk proyek baru, Microsoft memposisikan Agent Framework sebagai penerus dan menyediakan panduan migrasi. Periksa dokumen MAF saat ini sebelum memulai yang baru, karena area ini berubah dengan cepat. Untuk menguji API yang dipanggil salah satu dari keduanya, lihat cara menguji API ChatGPT dengan Apidog.
Ringkasan
Semantic Kernel memberi tim stack Microsoft cara yang bersih untuk mengorkestrasi AI: kernel yang menghubungkan model ke kode Anda, plugin dan fungsi yang dapat dipanggil model, dan jalur impor OpenAPI yang mengekspos REST API Anda yang ada sebagai alat agen. Ini stabil dan terbukti di produksi, dengan Agent Framework sekarang membawa arah terbaru ke depan. Mana pun yang Anda pilih, API di bawahnya tetap harus solid. Untuk merancang, memoc, dan menguji spesifikasi dan endpoint yang diandalkan agen Anda, unduh Apidog dan bangun kontraknya sebelum agen memanggilnya.