AI Agents | The .NET Blog

Microsoft Agent Framework Bagian 3: Dari Alat ke Alur Kerja — Blok Bangunan Klik ke Tempatnya

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Postingan ini telah diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Jika kamu mengikuti seri Building Blocks for AI di .NET, kamu tahu: Bagian 1 memberi kita IChatClient (antarmuka model universal) dan Bagian 2 memberi kita Microsoft.Extensions.VectorData (pencarian semantik dan RAG). Keduanya fundamental dan berguna sendiri-sendiri. Tapi di sinilah semuanya mulai terhubung.

Bagian 3 tentang Microsoft Agent Framework — dan sejujurnya, ini adalah bagian yang saya tunggu-tunggu di .NET. Versi 1.0 rilis April lalu. API-nya stabil. Saatnya benar-benar membangun agen.

Apa itu Agen (vs. Chatbot)

Sebelum terjun ke kode, mari kita perjelas perbedaan ini. Chatbot menerima input, memanggil model, mengembalikan output. Loop sederhana.

Agen memiliki otonomi. Ia dapat bernalar tentang tugas, memutuskan alat mana yang digunakan, memanggilnya, mengevaluasi hasil, dan memutuskan apa yang harus dilakukan selanjutnya — semua tanpa kamu menulis logika langkah demi langkah untuk setiap skenario. Kamu memberinya alat dan instruksi, dan ia mengurus orkestrasi sendiri.

Pikirkan begini: IChatClient seperti mengobrol. Agen seperti mendelegasikan daftar tugas kepada seseorang.

Agen Pertamamu dalam 10 Baris

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Metode ekstensi .AsAIAgent() adalah jembatannya. Pola yang sama seperti .AsIChatClient() dari MEAI — membungkus SDK penyedia dalam abstraksi yang stabil. Bekerja dengan Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry, atau model lokal.

Streaming juga berfungsi:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Memberi Alat kepada Agen

Di sinilah agen berhenti menjadi chatbot canggih. Alat adalah fungsi yang dapat diputuskan oleh model untuk dipanggil berdasarkan permintaan pengguna. Tidak perlu logika routing dari sisimu — model yang mencari tahu sendiri.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Dua hal yang perlu diperhatikan. Pertama, AIFunctionFactory berasal dari MEAI — tool factory yang sama yang kamu gunakan dengan IChatClient biasa. Jika kamu sudah mendefinisikan alat untuk skenario chat, mereka juga berfungsi di sini.

Kedua, atribut Description sangat penting. Inilah cara model memahami apa yang dilakukan alat dan kapan menggunakannya. Perlakukan mereka sebagai dokumentasi untuk AI kamu, bukan untuk manusia.

Sesi: Percakapan yang Benar-benar Ingat

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Tanpa sesi, setiap panggilan RunAsync tidak berstateful. Dengan sesi, agen tahu lelucon mana yang kamu maksud. AgentSession menyimpan riwayat percakapan di antara giliran.

Untuk layanan tanpa state di produksi, sesi dapat diserialisasikan dengan bersih:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... simpan di suatu tempat ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

Ini krusial jika agenmu berjalan di lingkungan serverless atau horizontally-scaled.

AIContextProvider: Memori Persisten Lintas Sesi

Sesi menyimpan riwayat percakapan dalam satu sesi. Tapi bagaimana dengan mengetahui hal-hal tentang pengguna lintas sesi? AIContextProvider menangani itu.

Ia memiliki dua hook:

ProvideAIContextAsync — berjalan sebelum setiap interaksi, menyuntikkan konteks ke agen
StoreAIContextAsync — berjalan setelah setiap interaksi, memungkinkan pembelajaran dan persistensi

Polanya elegan: kamu dapat menumpuk beberapa provider — satu untuk preferensi pengguna, satu untuk interaksi terbaru, satu yang mengkueri store VectorData kamu untuk dokumen yang relevan. Yang terakhir adalah persis pola RAG dari Bagian 2, kini berjalan otomatis sebagai bagian dari setiap panggilan agen.

Alur Kerja Multi-Agen

Di sinilah framework mendapatkan namanya. Framework ini menyertakan sistem alur kerja berbasis grafik di mana eksekutor (agen, fungsi, apa saja) terhubung melalui edge.

Beberapa pola yang didukung secara native:

Sekuensial: Output Agen A mengalir ke Agen B
Konkuren (fan-out/fan-in): Dispatch ke beberapa agen secara paralel, kumpulkan hasilnya
Routing kondisional: Arahkan pekerjaan ke agen berbeda berdasarkan output
Loop penulis-kritikus: Satu agen menulis, yang lain mengevaluasi, loop sampai disetujui
Sub-alur kerja: Menyusun alur kerja secara hierarkis

Contoh penulis-kritikus:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Bersih, mudah dibaca, dan routing berbasis kondisi berarti kamu tidak perlu menulis logika loop sendiri.

Human-in-the-Loop

Tidak semua hal harus berjalan sepenuhnya otonom. Untuk operasi sensitif — penulisan database, transaksi keuangan, pengiriman komunikasi — kamu ingin manusia menyetujui sebelum agen mengeksekusi.

Framework memiliki dukungan bawaan untuk ini melalui FunctionApprovalRequestContent dan FunctionApprovalResponseContent. Agen mengusulkan pemanggilan alat, kode aplikasimu mempresentasikannya ke pengguna, dan responnya menentukan apakah eksekusi dilanjutkan.

Inilah cara yang benar untuk berpikir tentang agen dalam pengaturan enterprise: tidak sepenuhnya otonom, tapi otonomi dengan pembatas.

Gambaran Lengkap

Jika kamu mundur sebentar:

MEAI memberimu antarmuka universal ke model manapun
VectorData memberi agenmu akses ke pengetahuan organisasimu melalui pencarian semantik
Agent Framework mengorkestrasikan semuanya — menggunakan IChatClient di balik layar, berkomposisi dengan context provider, dan berkoordinasi melalui alur kerja

Setiap bagian dirancang untuk berkomposisi dengan bagian lainnya. Lihat postingan asli Jeremy Likness dan repositori GitHub Agent Framework untuk sampel lengkapnya.

Kesimpulan

Postingan Bagian 3 Microsoft Agent Framework menutup loop dari seri building blocks. Untuk developer .NET yang ingin membangun agen AI — bukan hanya chatbot, tapi agen nyata yang menggunakan alat, mengingat hal-hal, dan berkoordinasi — inilah jalannya.

Rilis stabil 1.0 berarti kamu bisa membangun ini di produksi. Jika kamu menunggu untuk terjun ke pengembangan agen di .NET, waktunya adalah sekarang.

SQL MCP Server di Azure App Service — Tanpa Container

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Postingan ini telah diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Jujur saja: setiap kali melihat “membutuhkan container” dalam sebuah tutorial, ada rasa lelah yang muncul. Container memang hebat — sampai tim kamu tidak punya strategi container, dan fitur yang tampak sederhana tiba-tiba tersangkut pada kompleksitas orkestrasi yang tidak direncanakan siapapun.

Itulah mengapa ini menarik perhatian saya. SQL MCP Server kini dapat berjalan di Azure App Service — tanpa Docker, tanpa Kubernetes, hanya dengan file konfigurasi Data API Builder (DAB) yang sama yang mengekspos database SQL kamu melalui MCP, REST, dan GraphQL.

Apa itu SQL MCP Server?

Pengenalan singkat jika kamu belum familiar. SQL MCP Server berada di antara agen AI kamu dan database SQL. Alih-alih memberikan akses langsung ke database pada agen (ide yang buruk), ia mengekspos tabel dan view kamu sebagai lapisan abstraksi — entitas dengan izin yang terdefinisi.

Dibangun di atas Data API Builder, yang berarti satu file konfigurasi mengelola MCP dan REST dan GraphQL sekaligus. Agen kamu berkomunikasi dengan endpoint MCP. Aplikasi tradisional berkomunikasi dengan REST atau GraphQL. Konfigurasi yang sama, runtime yang sama, permukaan yang berbeda.

Ini benar-benar berguna — kamu tidak perlu memelihara dua lapisan API yang terpisah.

Masalah Container (dan Solusinya)

Model deployment awal SQL MCP Server menggunakan container. Ini berfungsi dengan baik di banyak tim — tapi tidak semua. Banyak tim .NET menggunakan Azure App Service atau VM sebagai standar. Mengharuskan runtime container hanya untuk mengekspos endpoint SQL menambah hambatan yang tidak diminta siapapun.

Panduan baru menunjukkan cara melewatkan container sepenuhnya. Semuanya berjalan dengan perintah dab start, di-host di App Service sebagai proses web .NET 8 standar.

# Instal Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inisialisasi konfigurasi
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Tambahkan entitas
dab add products --source dbo.products --permissions "authenticated:*"

# Konfigurasi penyedia autentikasi App Service
dab configure --runtime.host.authentication.provider AppService

# Jalankan server
dab start

Pada titik ini kamu memiliki MCP di /mcp, REST dan GraphQL dari proses yang sama — dan tidak ada yang berjalan di container.

Autentikasi Tanpa API Key Bersama

Inilah bagian yang paling saya hargai. Saat deploy ke App Service, kamu mengonfigurasi Microsoft Entra ID sebagai penyedia autentikasi. Tidak ada rahasia bersama dalam file konfigurasi, tidak ada API key untuk dirotasi.

Connection string tetap berada di variabel lingkungan App Service (bukan di dab-config.json), dan endpoint MCP dilindungi oleh autentikasi platform. Jika workload Azure kamu sudah selaras dengan Entra ID, ini akan terintegrasi secara alami.

Untuk development lokal, beralih ke mode Simulator dan transport STDIO. Kembali ke mode AppService sebelum deployment. Bersih dan eksplisit.

Deploy ke App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Kemudian deploy proyek DAB kamu menggunakan metode deployment kode yang sudah digunakan tim kamu. Detail kuncinya: ini adalah deployment kode, bukan deployment container.

Mengapa Penting bagi Developer .NET

Jika kamu membangun agen AI di .NET, cepat atau lambat agen kamu perlu berkomunikasi dengan database. SQL MCP Server memberimu cara terstruktur untuk melakukannya — tanpa mengekspos connection string mentah.

Lihat panduan lengkapnya di postingan blog asli dan repositori sampel GitHub.

Kesimpulan

SQL MCP Server di App Service adalah pilihan pragmatis untuk tim .NET yang ingin memberikan akses data SQL terstruktur kepada agen mereka tanpa strategi container. Coba — agen kamu akan mengapresiasi permukaan API yang bersih.

Mengatur Panggilan Alat MCP di .NET dengan Agent Governance Toolkit

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

Posting ini diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Governing MCP Tool Calls in .NET with the Agent Governance Toolkit layak untuk dicermati jika Anda sedang membangun atau mengoperasikan sistem .NET dalam skala besar.

Dari sudut pandang saya, yang penting bukan fitur utamanya, melainkan seberapa cepat sebuah tim dapat mengubahnya menjadi alur kerja rekayasa yang lebih aman dan dapat diulang.

Mengapa ini penting bagi tim .NET

Kebanyakan tim menyeimbangkan antara kecepatan pengiriman, konsistensi platform, dan tata kelola. Pembaruan ini berguna karena memberikan jalur yang lebih konkret untuk meningkatkan salah satu hambatan tersebut tanpa menulis ulang segalanya.

Langkah praktis selanjutnya

Validasi fitur dalam pilot .NET kecil dengan data mirip produksi.
Tambahkan titik pemeriksaan rollback dan observabilitas yang jelas sebelum peluncuran yang lebih luas.
Tangkap pola implementasi dalam template internal Anda sehingga tim lain dapat menggunakannya kembali.

Sumber

Artikel asli: https://devblogs.microsoft.com/dotnet/governing-mcp-tool-calls-in-dotnet-with-the-agent-governance-toolkit/

Pembaruan April Visual Studio: Integrasi Cloud Agent untuk Alur Kerja .NET