Microsoft Semantic Kernel dla korporacyjnych stacków .NET/Java

Semantic Kernel to otwartoźródłowy SDK Microsoftu, który integruje duże modele językowe za pomocą pluginów, funkcji, mechanizmu function calling, magazynów wektorowych i konektorów z aplikacjami w .NET, Pythonie i Javie. Microsoft określa Microsoft Agent Framework, który łączy Semantic Kernel i AutoGen, jako bezpośredniego następcę obu projektów. Dla firm z istniejącym stackiem Microsoft, Azure i .NET Agent Framework jest najbardziej naturalnym punktem wejścia w nowe obciążenia agentowe; istniejące rozwiązania oparte na Semantic Kernel działają dalej.

• Czym jest: korporacyjny SDK do orkiestracji LLM, niezależny od modelu, przeznaczony głównie dla C#/.NET, a także dla Pythona i Javy.
• Podstawowe elementy: pluginy/funkcje (narzędzia do wywoływania), automatyczny function calling (planowanie kroków), magazyny wektorowe (pamięć, kontekst) i konektory (modele, usługi).
• Stan strategiczny w 2026 r.: Semantic Kernel i AutoGen łączą się w Microsoft Agent Framework 1.0 (GA od 3 kwietnia 2026 r., licencja MIT); SK 1.x jest nadal utrzymywany, nowe funkcje powstają w Agent Framework, a AutoGen przechodzi w tryb utrzymania.

Cztery podstawowe elementy Semantic Kernel

Semantic Kernel porządkuje integrację AI za pomocą czterech abstrakcji, z których każdą można osobno odwzorować w kodzie korporacyjnym.

Pluginy i funkcje. Plugin grupuje funkcje, które kernel może wywołać. Są dwa rodzaje: Native Functions to zwykły kod w C#, Pythonie lub Javie (np. dostęp do bazy danych albo wywołanie REST), a Prompt Functions to sparametryzowane prompty (wcześniej nazywane Semantic Functions). Oba rodzaje są udostępniane modelowi jako narzędzia do wywołania. Odpowiada to warstwie wywoływania narzędzi i funkcji z obsługą błędów, która definiuje framework agentowy.

Planowanie przez function calling. Wcześniejsze planery (Stepwise, Handlebars) Microsoft wycofał i usunął z pakietu. Dziś model sam decyduje, za pomocą automatycznego wywoływania funkcji, które funkcje pluginów wywołać i w jakiej kolejności: wywołuje funkcję, sprawdza wynik i wybiera kolejny krok. Zamiast na sztywno zakodować przepływ pracy, opisujesz dostępne pluginy. To pomost od statycznego przepływu pracy do dynamicznie sterowanego agenta. W Microsoft Agent Framework agent planuje w ten sam sposób, a workflowy oparte na grafach uzupełniają to o z góry zdefiniowane ścieżki wykonania.

Vector stores (pamięć). Pamięć przechowuje kontekst przez wiele kroków. Historię rozmowy SK prowadzi jako chat history, a trwałą wiedzę zapisuje jako embeddingi w wektorowych bazach danych (na potrzeby scenariuszy RAG). Służą do tego dziś abstrakcje vector store, które zastąpiły wcześniejsze memory stores. Dzięki temu możliwe jest zarządzanie stanem przez wiele wywołań bez ręcznego przekazywania pamięci przez cały łańcuch wywołań.

Konektory. Konektory oddzielają kod od konkretnych modeli i usług. W Microsoft Agent Framework sześciu dostawców można zamienić zmianą 1 linii kodu: Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini i Ollama (stan na 2026 r.). To wyraźnie ogranicza uzależnienie od modelu, a to kluczowe kryterium wyboru w branżach regulowanych.

Fokus na .NET/Java: dlaczego zyskują korporacyjne stacki

Zasadnicza różnica w porównaniu z frameworkami skoncentrowanymi na Pythonie, takimi jak CrewAI (tylko Python) czy Pydantic AI (tylko Python), to pełnoprawne wsparcie dla .NET. Jeśli utrzymujesz istniejące środowisko ASP.NET, Azure Functions lub Service Fabric, integrujesz agentów AI w tym samym stacku językowym i wdrożeniowym, bez zmiany języka i bez osobnej usługi w Pythonie.

Liczy się to także w kontekście zespołu: istniejący zespół .NET dalej pracuje z Agent Framework w znanym sobie języku i nie potrzebuje dodatkowo specjalistów od Pythona. Semantic Kernel obsługuje również Javę. Microsoft Agent Framework jest natomiast według Microsoft Learn dostępny dla .NET (C#) i Pythona, a także dla Go w wersji public preview; Javy Microsoft tam nie wymienia. Firmy pracujące wyłącznie w Javie powinny więc sprawdzić wsparcie języków przed startem projektu.

Do tego dochodzą cechy korporacyjne, które w praktyce decydują o gotowości produkcyjnej:

• Natywna obsługa MCP (Model Context Protocol) dla ustandaryzowanego dostępu do narzędzi, włączana np. przez konfigurację taką jak .WithMcpServer(...).
• Natywna obsługa A2A (Agent-to-Agent, protokół v1.0) wraz z Signed Agent Cards do komunikacji między agentami.
• Obserwowalność przez Application Insights, OpenTelemetry i Foundry Monitoring, ważna dla obowiązków audytowych i wymogów identyfikowalności.
• Wykonywanie kodu w sandboksie przez CodeAct/Hyperlight (wersja alfa, stan na 2026 r.).
• Hosting Azure w Europie w regionach UE Germany West Central (Frankfurt), West Europe i Sweden Central, a także Switzerland North, plus Microsoft EU Data Boundary (UE i EFTA).

Relacja z AutoGen: zapowiedziana konwergencja

Do 2025 r. Microsoft rozwijał dwa równoległe nurty: Semantic Kernel jako SDK nastawiony na produkcję i AutoGen jako framework badawczy i wieloagentowy. Microsoft Agent Framework łączy je w jedno.

Zmiana strategii jest konkretna. Microsoft Agent Framework wystartował w wersji public preview 1 października 2025 r. i 3 kwietnia 2026 r. osiągnął General Availability, na licencji MIT i z wyraźnym zobowiązaniem LTS. Przed fuzją Semantic Kernel i AutoGen miały łącznie ponad 75 000 gwiazdek na GitHubie. Nowy framework wyraźnie rozdziela agentów (stanowe jednostki wykonawcze) i workflowy (orkiestracja oparta na grafach) oraz włącza wieloagentowe koncepcje AutoGen do silnika workflowów opartego na grafach.

Kluczowe dla obecnych klientów: Semantic Kernel działa dalej, ale rozwój przeniósł się do Agent Framework. Microsoft nadal usuwa w SK 1.x krytyczne błędy i luki bezpieczeństwa, z gwarancją na co najmniej rok po zakończeniu fazy preview Agent Framework, czyli co najmniej do kwietnia 2027 r. Większość nowych funkcji powstaje w Agent Framework. Istniejące rozwiązania działają dalej i można je migrować stopniowo; wraz z GA Microsoft wyraźnie zaleca jednak przejście. AutoGen przechodzi natomiast w tryb utrzymania; nie warto już zaczynać w nim nowych projektów wieloagentowych (stan na 2026 r.).

Porównanie ścieżek migracji

Kiedy Microsoft Agent Framework pasuje do zespołów korporacyjnych, a kiedy nie

Dobrze się sprawdzi, jeśli spełniony jest co najmniej jeden z tych warunków:

• .NET/C# jest obowiązkowy lub stanowi dominujący stack.
• Istnieje środowisko Azure z wymogiem rezydencji danych w UE.
• Zespół już korzysta z Semantic Kernel lub AutoGen.
• Regulowane obciążenia w UE, które wymagają logowania, identyfikowalności i nadzoru człowieka (istotne w kontekście AI Act; Digital Omnibus (rozporządzenie (UE) 2026/1744) obowiązuje od 27 lipca 2026 r. i przesuwa obowiązki dla systemów wysokiego ryzyka z załącznika III na 2 grudnia 2027 r.).

Raczej się nie sprawdzi, jeśli:

• Zespół pracuje wyłącznie w Pythonie i liczy się time-to-demo; wtedy CrewAI (najszybszy prototyp) lub Pydantic AI są często prostszą drogą.
• Wymagana jest ścisła suwerenność bez dostawców z USA, bo w tym przypadku zależność od amerykańskiego dostawcy i dyskusja wokół CLOUD Act pozostają otwartą kwestią mimo regionów Azure w UE.
• Maksymalna dojrzałość jest potrzebna od razu: GA z 3 kwietnia 2026 r. jest wciąż świeża, a niektóre pakiety (np. agent_framework.orchestrations) dłużej pozostawały w fazie preview. Wymagania dotyczące dojrzałości trzeba zweryfikować.

Konkretny przykład: asystent ofertowy w stacku .NET

Średniej wielkości firma B2B produkująca maszyny (Wiedeń) chce odciążyć handlowców przy przygotowywaniu ofert. Istniejący stack: ASP.NET Core, SQL Server, Azure West Europe.

Architektura z Microsoft Agent Framework (elementy opisane pojęciami z Semantic Kernel):

1. Plugin ProductCatalog (Native Function) odczytuje ceny i dostępność z SQL Server.
2. Plugin PricingRules (Prompt Function) stosuje logikę rabatową jako sparametryzowany prompt.
3. Serwer MCP podłącza CRM z historią klientów (.WithMcpServer(...)).
4. Agent orkiestruje cały proces: rozumie zapytanie, przeszukuje katalog, kalkuluje cenę i generuje tekst oferty.
5. Konektor wskazuje na Azure OpenAI w regionie West Europe (rezydencja danych w UE).

Szkic w pseudokodzie:

```csharp
var agent = new AgentBuilder()
.WithAzureOpenAI("gpt-deployment", endpoint, key) // region UE
.WithPlugin<ProductCatalog>()
.WithPlugin<PricingRules>()
.WithMcpServer("crm-connector")
.Build();

var result = await agent.RunAsync(
"Przygotuj ofertę dla klienta 4711, 50 sztuk typu B");
```

Założenie dotyczące wyniku: zamiast około 25 minut ręcznego wyszukiwania informacji i pisania na każdą ofertę asystent dostarcza szkic w niecałe 60 sekund, a handlowiec tylko go sprawdza (human-in-the-loop). Przy 40 ofertach tygodniowo daje to oszczędność rzędu 16 godzin tygodniowo; konkretne liczby trzeba zweryfikować w danej firmie. Application Insights rejestruje każdy krok na potrzeby obowiązku audytowego.

Dla agencji i decydentów B2B

Dla agencji Microsoft Agent Framework to dźwignia u klientów z rozbudowanym środowiskiem Microsoft: dostarczają agentów AI w istniejącym stacku .NET/Azure, bez budowania równoległej infrastruktury w Pythonie, i mogą rzetelnie uzasadnić rezydencję danych w UE dzięki regionom Azure przed działami ochrony danych i compliance. Dla decydentów B2B konwergencja Semantic Kernel i AutoGen jest sygnałem stabilności: jeden produkt w wersji GA ze zobowiązaniem LTS zamiast dwóch równoległych projektów. Blck Alpaca wspiera firmy w całej Europie w wyborze frameworka, ocenie suwerenności i migracji istniejących rozwiązań opartych na Semantic Kernel. Rekomendacja: najpierw zdefiniuj przypadek użycia, potem wybierz framework, nigdy odwrotnie.