Emre Demir

Posted on Jun 26 • Originally published at apidog.com

Was ist Semantic Kernel? Microsofts SDK für KI-Orchestrierung

Wenn Sie im Microsoft-Stack entwickeln und KI-Funktionen integrieren möchten, ohne einen separaten Python-Dienst zu betreiben, ist Semantic Kernel das passende SDK von Microsoft. Es verbindet vorhandenen Code und REST-APIs mit großen Sprachmodellen, läuft in C#, Python und Java und kann über die OpenAPI-Spezifikation bestehende APIs als aufrufbare Tools für ein Modell bereitstellen.

Testen Sie Apidog noch heute

Was Semantic Kernel ist

Semantic Kernel (SK) ist ein leichtgewichtiges Open-Source-SDK von Microsoft zum Erstellen von KI-Agenten und zum Einbinden von Modellen in bestehende Anwendungen.

Praktisch funktioniert SK wie Middleware:

Ihre Anwendung sendet eine Aufgabe an den Kernel.
Der Kernel ruft ein Modell auf.
Das Modell entscheidet, ob es eine registrierte Funktion benötigt.
SK führt diese Funktion aus.
Das Ergebnis wird zurück an das Modell gegeben.

Sie schreiben weiterhin normalen Anwendungscode. Semantic Kernel macht diesen Code für das Modell auffindbar und aufrufbar.

Semantic Kernel ist besonders nützlich, wenn:

Ihr Backend in .NET, Java oder Python läuft.
Sie bestehende Services als KI-Tools verfügbar machen möchten.
Sie REST-APIs über OpenAPI-Spezifikationen importieren wollen.
Sie Logging, Telemetrie, Filter und kontrollierbare Ausführung benötigen.

Warum Semantic Kernel für Microsoft-Stacks relevant ist

Semantic Kernel unterscheidet sich von vielen Agenten-Frameworks in drei Punkten.

1. Offizielle SDKs für C#, Python und Java

Viele Agenten-Frameworks sind Python-zentriert. Semantic Kernel bietet offizielle SDKs für:

C#/.NET
Python
Java

Für .NET-Teams bedeutet das: keine zusätzliche Python-Runtime, kein Sidecar-Service und keine unnötige Sprachgrenze zwischen Backend und KI-Orchestrierung.

2. Modellagnostische Architektur

Semantic Kernel kann mit OpenAI, Azure OpenAI und weiteren Modellanbietern arbeiten. Der Modellanbieter wird über Konfiguration und Konnektoren eingebunden, nicht hart in Ihre Geschäftslogik codiert.

Das Ziel: Modell wechseln, ohne die gesamte Anwendung umzubauen.

3. Enterprise-orientierte Kontrollpunkte

SK bietet Mechanismen für:

Telemetrie
Logging
Hooks
Filter
Nachvollziehbarkeit von Funktionsaufrufen

Das ist wichtig, wenn ein Agent nicht nur Text generiert, sondern echte interne APIs ausführt.

Kernel, Plugins und Funktionen

Das zentrale Objekt ist der Kernel.

Sie können ihn sich wie einen Dependency-Injection-Container für KI vorstellen. Dort registrieren Sie:

Modellkonnektoren
Plugins
native Funktionen
Prompt-Funktionen
Konfiguration für Funktionsaufrufe

Ein Plugin ist eine benannte Gruppe von Funktionen. Eine Funktion ist eine einzelne Fähigkeit, die das Modell verwenden darf.

Es gibt zwei typische Funktionsarten:

Native Funktionen: normale Methoden in Ihrem Code, z. B. C#-Methoden oder Python-Funktionen.
Prompt-Funktionen: Prompt-Vorlagen für Aufgaben wie Zusammenfassen, Klassifizieren oder Umschreiben.

Ein minimales C#-Beispiel:

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"
);

Ein einfaches Plugin könnte so aussehen:

using Microsoft.SemanticKernel;
using System.ComponentModel;

public class LightsPlugin
{
    [KernelFunction("change_light_state")]
    [Description("Changes the color and state of a light.")]
    public string ChangeLightState(
        [Description("The room where the light is located.")]
        string room,

        [Description("The target color for the light.")]
        string color
    )
    {
        // Hier würden Sie Ihre echte Geräte- oder Backend-API aufrufen.
        return $"Light in {room} changed to {color}.";
    }
}

Wichtig ist nicht nur die Methode selbst, sondern auch die Beschreibung. Das Modell nutzt Namen, Parameter und Beschreibungen, um zu entscheiden, ob und wie es die Funktion aufruft.

Das OpenAPI-zu-Plugin-Muster

Die praktisch wichtigste Funktion für bestehende Backend-Systeme ist der OpenAPI-Import.

Semantic Kernel kann eine OpenAPI-Spezifikation importieren und daraus automatisch aufrufbare Funktionen erzeugen. Jede Operation in der Spezifikation wird zu einer Funktion, die das Modell verwenden kann.

Das heißt:

kein manueller Wrapper für jeden Endpoint
keine doppelte Beschreibung Ihrer API
vorhandene REST-APIs werden als Agenten-Tools verfügbar

In C# verwenden Sie dafür ImportPluginFromOpenApiAsync:

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

In Python heißt das entsprechende Muster add_plugin_from_openapi.

Semantic Kernel liest aus der Spezifikation unter anderem:

Operation IDs
Pfade
HTTP-Methoden
Parameter
Request- und Response-Schemas
Beschreibungen
Datentypen
Enums

Diese Metadaten werden dem Modell als Tool-Beschreibung bereitgestellt. Wenn das Modell entscheidet, dass eine API-Operation benötigt wird, baut SK den HTTP-Request, führt ihn aus und gibt die Antwort zurück in die Modellschleife.

Semantic Kernel unterstützt OpenAPI 2.0 und 3.0 und stuft 3.1-Spezifikationen, soweit möglich, auf 3.0 herab.

OpenAPI-Spezifikationen agententauglich machen

Eine OpenAPI-Datei, die für Menschen lesbar ist, ist nicht automatisch optimal für ein Modell.

Achten Sie besonders auf:

sprechende operationId-Werte
eindeutige Parameterbeschreibungen
konkrete Schemas statt loser Strings
Enums für begrenzte Wertebereiche
möglichst kleine, fokussierte API-Oberflächen
konsistente Response-Strukturen

Schlechtes Beispiel:

operationId: update
summary: Updates data
parameters:
  - name: value
    in: query
    schema:
      type: string

Besser:

operationId: updateLightColor
summary: Updates the color of a smart light in a specific room
parameters:
  - name: room
    in: query
    required: true
    description: The room where the light is located, for example kitchen or office.
    schema:
      type: string
  - name: color
    in: query
    required: true
    description: The target color for the light.
    schema:
      type: string
      enum:
        - red
        - blue
        - green
        - white

Je genauer die Spezifikation ist, desto zuverlässiger kann das Modell die richtige Operation und die richtigen Argumente wählen.

Authentifizierung für importierte APIs

In echten Anwendungen benötigen Ihre APIs fast immer Authentifizierung. Semantic Kernel kann beim Ausführen der importierten OpenAPI-Funktionen Authentifizierungsinformationen hinzufügen.

Das konkrete Muster hängt vom SDK und Ihrer Konfiguration ab. Typisch ist:

API-Spezifikation importieren.
Ausführungsparameter konfigurieren.
Authentifizierungsinformationen pro Request hinzufügen.
Secrets nicht im Prompt oder im Plugin hart codieren.

Beispielhafte Struktur:

var executionParameters = new OpenApiFunctionExecutionParameters
{
    EnablePayloadNamespacing = true,
    // Authentifizierungslogik abhängig von Ihrem Setup ergänzen
};

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "internalApi",
    uri: new Uri("https://example.com/openapi.json"),
    executionParameters: executionParameters
);

Behandeln Sie API-Schlüssel wie normale Produktions-Secrets:

über Umgebungsvariablen laden
pro Umgebung trennen
nicht in Prompts einfügen
nicht in Logs ausgeben
Rotation einplanen

Agenten und Planung

Semantic Kernel startete mit expliziten Planern, die ein Ziel in einzelne Schritte zerlegen. Moderne SK-Anwendungen setzen stärker auf Funktionsaufrufe: Das Modell entscheidet selbst, welche Funktionen in welcher Reihenfolge benötigt werden.

Zusätzlich bietet SK eine Agent-Framework-Schicht für:

sitzungsbasierten Zustand
agentische Ausführungsschleifen
Multi-Agenten-Muster
Tool-Anbindung
Model Context Protocol (MCP)-Unterstützung

Wenn Sie Frameworks vergleichen, sieht die Einordnung so aus:

Framework	Primäre Sprachen	Orchestrierungsmodell	Optimaler Anwendungsbereich
Semantic Kernel	C#/.NET, Python, Java	Funktionsaufrufe + Agenten	.NET- und Unternehmens-Teams
LangGraph	Python, JS	Expliziter Zustandsgraph	Komplexe, verzweigte Agentenabläufe
Google ADK	Python	Agenten- + Tool-Modell	Google Cloud- und Gemini-Stacks
OpenAI Agents SDK	Python, JS	Agenten + Übergaben	OpenAI-zentrierte Anwendungen

Die Wahl hängt vor allem ab von:

Ihrer Hauptsprache
Ihrem Modellanbieter
Ihrem Bedarf an expliziter Ablaufkontrolle
Ihren Anforderungen an Observability und Governance

Semantic Kernel und Microsoft Agent Framework

Microsoft hat das Microsoft Agent Framework (MAF) eingeführt. Die Dokumentation beschreibt es als direkten Nachfolger von Semantic Kernel und AutoGen, entwickelt von denselben Teams.

MAF kombiniert:

Agenten-Abstraktionen aus AutoGen
Enterprise-Funktionen aus Semantic Kernel
graphbasierte Workflows für Multi-Agenten-Orchestrierung

Für aktuelle Projekte bedeutet das:

Bestehende SK-Anwendungen können weiterlaufen.
Semantic Kernel bleibt stabil und unterstützt.
Für neue Agentenprojekte sollten Sie die MAF-Dokumentation prüfen.
Das OpenAPI-zu-Tool-Muster bleibt relevant.

Wenn Ihre Anwendung bereits auf SK basiert, gibt es keinen technischen Grund, sofort zu migrieren. Wenn Sie neu starten und die neueste Microsoft-Richtung verfolgen möchten, prüfen Sie MAF früh in der Architekturentscheidung.

Wann Sie Semantic Kernel verwenden sollten

Semantic Kernel ist eine gute Wahl, wenn:

Ihr Backend in .NET oder Java geschrieben ist.
Sie keine separate Python-Orchestrierung betreiben möchten.
Sie bestehende REST-APIs über OpenAPI einbinden wollen.
Sie kontrollierbare Funktionsaufrufe benötigen.
Sie Telemetrie, Filter und Hooks brauchen.
Sie modellagnostisch bleiben möchten.
Sie produktionsnahe Agenten statt nur Prototypen bauen.

Weniger passend ist SK, wenn:

Ihr Team ausschließlich Python nutzt.
Sie die neuesten Multi-Agenten-Patterns priorisieren.
Sie einen expliziten Graph-Workflow für jeden Schritt brauchen.
Sie bereits vollständig auf ein anderes Agenten-Framework standardisiert haben.

APIs hinter Semantic-Kernel-Agenten testen

Semantic Kernel ersetzt Ihre APIs nicht. Es ruft sie auf.

Ein SK-Agent hängt typischerweise von zwei Arten von Endpunkten ab:

dem LLM-Endpunkt
den REST-APIs, die als OpenAPI-Plugins importiert werden

Wenn diese APIs schlecht beschrieben, instabil oder fehlerhaft sind, wird auch der Agent unzuverlässig.

Hier passt Apidog in den Workflow.

1. OpenAPI-Spezifikation validieren

Bevor Sie eine Spezifikation in Semantic Kernel importieren, sollten Sie prüfen:

Sind alle Schemas korrekt?
Haben Operationen klare IDs?
Stimmen Request- und Response-Definitionen?
Sind Pflichtfelder eindeutig?
Gibt es aussagekräftige Beschreibungen?

Da SK die Spezifikation direkt in Modell-Tools umwandelt, wirkt sich jede Unschärfe direkt auf die Tool-Aufrufe aus.

2. Endpunkte vor dem Agenten testen

Testen Sie jeden Endpoint unabhängig vom Agenten:

erfolgreiche Requests
Fehlerszenarien
Authentifizierung
Grenzwerte
Response-Schema
Statuscodes

So stellen Sie sicher, dass Probleme nicht fälschlicherweise dem Modell zugeschrieben werden.

3. Mock-APIs während der Entwicklung nutzen

Wenn ein Backend-Endpunkt noch nicht fertig ist, können Sie eine Mock-API verwenden.

Das ist hilfreich, um:

Agentenlogik früh zu testen
Frontend und Backend parallel zu entwickeln
Tokenverbrauch beim Debugging zu reduzieren
Ratenlimits zu vermeiden

Ein praktisches Muster finden Sie hier: wie man API-Aufrufe mockt.

4. Antwortstrukturen mit Assertions absichern

Wenn ein Agent eine API-Antwort erwartet, kann schon eine kleine Backend-Änderung das Verhalten beeinflussen.

Nutzen Sie API-Assertions, um zu prüfen:

Feld vorhanden
Datentyp korrekt
Statuscode korrekt
Array- oder Objektstruktur stabil
Fehlerantworten konsistent

Das ist besonders wichtig bei Tool-Aufrufen, weil das Modell auf stabile Strukturen angewiesen ist.

5. Umgebungen sauber trennen

Verwalten Sie getrennte Konfigurationen für:

Entwicklung
Staging
Produktion

Trennen Sie außerdem:

LLM-Schlüssel
interne API-Schlüssel
Testdaten
Base URLs
Mock-Endpoints

Secrets gehören nicht in Plugin-Code, Prompts oder OpenAPI-Beispiele.

Eine ausführlichere Einführung finden Sie unter Tool-Aufrufe eines Agenten mit Apidog testen.

Beispiel-Workflow: REST-API als Semantic-Kernel-Tool bereitstellen

Ein praktikabler Ablauf sieht so aus:

REST-API entwerfen.
OpenAPI-Spezifikation erzeugen oder pflegen.
Spezifikation in Apidog validieren.
Endpunkte testen und Assertions hinzufügen.
Mock-Endpoints für unfertige Services bereitstellen.
OpenAPI-Spezifikation in Semantic Kernel importieren.
Authentifizierung konfigurieren.
Agenten-Prompts mit realistischen Aufgaben testen.
Tool-Aufrufe beobachten und protokollieren.
Spezifikation nachschärfen, wenn das Modell falsche Operationen wählt.

Der wichtigste Punkt: Optimieren Sie nicht nur den Prompt. Optimieren Sie auch die API-Beschreibung.

Häufig gestellte Fragen

Ist Semantic Kernel kostenlos und quelloffen?

Ja. Semantic Kernel ist quelloffen und wird von Microsoft auf GitHub unter einer permissiven Lizenz veröffentlicht. Sie zahlen für die Modellnutzung bei Anbietern wie OpenAI oder Azure OpenAI, nicht für Semantic Kernel selbst.

Welche Sprachen unterstützt Semantic Kernel?

Semantic Kernel unterstützt C#/.NET, Python und Java. Alle drei SDKs haben Stabilitätszusagen für Version 1.0+. Das C#-SDK ist besonders relevant für Microsoft-Stack-Teams, während Python und Java die zentralen Konzepte wie Kernel, Plugins und OpenAPI-Import ebenfalls abdecken.

Wie nutzt Semantic Kernel OpenAPI-Spezifikationen?

Sie importieren eine Spezifikation zum Beispiel mit ImportPluginFromOpenApiAsync in C# oder add_plugin_from_openapi in Python. Semantic Kernel parst die Spezifikation, erzeugt daraus Funktionen und stellt diese dem Modell als Tools bereit.

Die Qualität der Spezifikation beeinflusst direkt, wie zuverlässig das Modell Ihre API nutzt. Sie können die Spezifikation und Live-Endpunkte vorher mit Apidog prüfen.

Sollte ich Semantic Kernel oder das Microsoft Agent Framework verwenden?

Wenn Sie bereits eine SK-Anwendung haben, können Sie sie weiterverwenden. Semantic Kernel ist stabil und wird unterstützt.

Für neue Agentenprojekte sollten Sie zusätzlich das Microsoft Agent Framework prüfen, da Microsoft es als Nachfolger positioniert. Die Entscheidung hängt davon ab, ob Sie Stabilität, bestehende SK-Integration oder die neueste Agentenarchitektur priorisieren.

Zum Testen der APIs, die ein Agent aufruft, siehe auch wie man die ChatGPT API mit Apidog testet.

Zusammenfassung

Semantic Kernel bietet Microsoft-Stack-Teams eine direkte Möglichkeit, KI in bestehende Anwendungen einzubauen: Der Kernel verbindet Modelle mit Code, Plugins machen Funktionen verfügbar, und der OpenAPI-Import verwandelt bestehende REST-APIs in Agenten-Tools.

Für produktive Systeme ist die API-Qualität entscheidend. Saubere OpenAPI-Spezifikationen, getestete Endpunkte, stabile Antwortschemata und getrennte Umgebungen machen Agenten zuverlässiger.

Wenn Sie die Spezifikationen und Endpunkte hinter Ihrem Agenten entwerfen, mocken und testen möchten, laden Sie Apidog herunter und validieren Sie den API-Vertrag, bevor der Agent ihn aufruft.

DEV Community