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

Wenn Sie Software auf dem Microsoft-Stack entwickeln und KI hinzufügen möchten, ohne einen Python-Dienst anzudocken, ist Semantic Kernel das SDK, das Microsoft für Sie entwickelt hat. Es ist ein Open-Source-Kit, das Ihren bestehenden Code und Ihre APIs mit großen Sprachmodellen verbindet und in C#, Python und Java läuft. Dieser Leitfaden erklärt, was es ist, wie Kernel und Plugins zusammenpassen und wie seine Unterstützung für die OpenAPI-Spezifikation jede REST-API in etwas verwandelt, das ein Modell aufrufen kann.

Was Semantic Kernel tatsächlich ist

Semantic Kernel (SK) ist ein leichtgewichtiges, quelloffenes Entwicklungs-Kit von Microsoft zum Erstellen von KI-Agenten und zur Integration von Modellen in Ihre Codebasis. Microsoft beschreibt es als Middleware: Es sitzt zwischen Ihrer Anwendung und dem Modell, übersetzt die Anfragen des Modells in tatsächliche Funktionsaufrufe, führt sie aus und gibt die Ergebnisse zurück. Sie schreiben normalen Code. Das Modell entscheidet, wann es aufgerufen wird.

Drei Dinge heben SK von der Masse der Agenten-Bibliotheken ab.

Erstens ist es wirklich mehrsprachig. SK liefert offizielle SDKs für C#/.NET, Python und Java, mit Stabilitätszusagen für Version 1.0+ über alle drei hinweg. Die meisten Agenten-Frameworks sind Python-zentriert und behandeln andere Sprachen als Nebensache. Wenn Ihr Backend .NET ist, ist SK eine der wenigen ausgereiften Optionen, die sich nativ anfühlt.

Zweitens ist es modellagnostisch. SK verbindet sich mit OpenAI, Azure OpenAI und anderen Anbietern über eine Reihe von Konnektoren. Wenn Sie Modelle austauschen möchten, ändern Sie die Konfiguration, nicht Ihre gesamte Anwendung.

Drittens wurde es mit Blick auf Unternehmensanforderungen entwickelt. Telemetrie, Hooks und Filter sind erstklassig, sodass Sie protokollieren, überwachen und abfangen können, was die KI tut. Dieser Fokus ist der Grund, warum Microsoft und eine Reihe von Fortune-500-Teams es übernommen haben.

Der Kernel, Plugins und Funktionen

Das Kernobjekt ist der Kernel. Stellen Sie es sich wie einen Dependency-Injection-Container für KI vor. Sie registrieren Ihre Modellkonnektoren und Ihre Plugins im Kernel und fordern ihn dann auf, Dinge auszuführen. Der Kernel übernimmt die Orchestrierung: Prompt, Modellaufruf, Funktionsaufruf, Ergebnis, Wiederholung.

Ein Plugin ist eine benannte Gruppe von Funktionen, die Sie dem Modell zur Verfügung stellen. Eine Funktion ist eine einzelne Fähigkeit, die das Modell aufrufen kann. Funktionen gibt es in zwei Varianten:

• Native Funktionen sind reguläre Methoden in Ihrem Code (eine C#-Methode, eine Python-Funktion), die Sie annotieren, damit der Kernel sie dem Modell beschreiben kann.
• Prompt-Funktionen sind vorlagenbasierte Prompts, die das Modell selbst aufrufen und nützlich zum Zusammenfassen, Klassifizieren oder Umschreiben von Text sind.

So sieht es in C# aus. Sie erstellen einen Kernel, registrieren ein Chat-Modell, fügen ein Plugin hinzu und lassen das Modell Funktionen aufrufen, wenn es sie benötigt.

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

Wenn das Modell zurückkehrt und der Kernel erkennt, dass es `change_light_state` aufrufen möchte, führt der Kernel Ihren Code aus, erfasst das Ergebnis und speist es zurück ins Modell. Diese Schleife ist das Herzstück von SK.

Das OpenAPI-zu-Plugin-Muster

Dies ist die Funktion, die am wichtigsten ist und die sauberste Brücke zu Ihren bestehenden Diensten darstellt. SK kann eine OpenAPI-Spezifikation importieren und jede Operation automatisch in eine aufrufbare Funktion umwandeln. Sie schreiben keinen Wrapper-Code. Sie verweisen SK auf eine Spezifikation, und jeder Pfad/jede Operation wird zu einer Funktion, die das Modell aufrufen kann.

In C# ist der Aufruf `ImportPluginFromOpenApiAsync`. In Python ist es `add_plugin_from_openapi`. Java verfügt über einen gleichwertigen Importer. Hier ist die C#-Version, die eine Spezifikation von einer URL lädt:

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

Unter der Haube parst SK die Spezifikation, extrahiert Name, Beschreibung, Typ und Schema für jeden Parameter und übergibt diese Metadaten an das Modell. Das Modell überlegt, welche Operation aufgerufen werden soll und welche Argumente übergeben werden sollen. SK erstellt dann die HTTP-Anfrage, wendet Ihren Authentifizierungs-Callback an, sendet sie und liest die Antwort zurück. SK unterstützt OpenAPI 2.0 und 3.0 und stuft 3.1-Spezifikationen, wo möglich, auf 3.0 herab.

Der Haken ist, dass Spezifikationen, die für Menschen geschrieben wurden, für ein Modell nicht immer klar sind. Die eigene Empfehlung von Microsoft ist, beschreibende Operations-IDs hinzuzufügen, hilfreiche Parameterbeschreibungen zu schreiben, die Anzahl der Endpunkte niedrig zu halten und Enums und typisierte Parameter gegenüber losen Strings zu bevorzugen. Die Qualität Ihrer Spezifikation beeinflusst direkt, wie gut der Agent Ihre API aufruft. Das macht die Spezifikation selbst zu etwas, das sorgfältig entworfen und getestet werden sollte, und nicht zu einem nachträglichen Gedanken.

Agenten und Planung

SK begann mit expliziten Planern, die ein Ziel in Schritte zerlegten. Das Framework hat sich seitdem in Richtung Funktionsaufrufe verlagert, bei denen das Modell selbst entscheidet, welche Funktionen in welcher Reihenfolge aufgerufen werden sollen, was bei modernen Modellen zuverlässiger ist. Darüber hinaus fügte SK eine Agent Framework-Schicht für den Aufbau von Agenten und Multi-Agenten-Mustern hinzu, mit sitzungsbasiertem Zustand, agentischen Schleifen und Model Context Protocol (MCP)-Unterstützung zum Verbinden externer Tools.

Wenn Sie Ansätze vergleichen, sehen Sie hier, wie sich SK im Vergleich zu anderen in diesem Blog behandelten Agenten-SDKs schlägt.

Keines davon ist strikt besser. Die richtige Wahl hängt von Ihrer Sprache, Ihrem Modellanbieter und davon ab, wie viel explizite Kontrolle Sie über die Ausführung wünschen.

Wo Semantic Kernel zum Microsoft Agent Framework passt

Dieser Bereich entwickelt sich schnell, daher hier der aktuelle Stand der Dinge. Microsoft hat das Microsoft Agent Framework (MAF) eingeführt, und die Dokumentation beschreibt es als den direkten Nachfolger von Semantic Kernel und AutoGen, entwickelt von denselben Teams. MAF kombiniert AutoGens Agenten-Abstraktionen mit den Unternehmensfunktionen von SK und fügt graphbasierte Workflows für die Multi-Agenten-Orchestrierung hinzu.

Was das in der Praxis bedeutet:

• Semantic Kernel ist stabil und wird weiterhin unterstützt. Bestehende SK-Anwendungen funktionieren weiterhin, und die Zusage für 1.0+ nicht-brechende Änderungen bleibt bestehen.
• Für brandneue Agentenprojekte verweist Microsoft auf das Agent Framework und veröffentlicht einen Migrationsleitfaden zur Übertragung von SK-Code.
• Die OpenAPI-zu-Plugin-Idee wird weitergeführt. Einem Agenten über eine Spezifikation Zugriff auf Ihre REST-APIs zu ermöglichen, ist ein Muster, das beide Frameworks teilen.

Betrachten Sie SK also als eine solide, in der Produktion bewährte Wahl, die weiterhin gepflegt wird, während Sie wissen, dass die neuesten Investitionen in MAF fließen. Wenn Sie heute entscheiden und Ihr Code bereits in SK ist, besteht kein Grund zur Eile. Wenn Sie neu starten und die neueste Richtung einschlagen möchten, lesen Sie die MAF-Dokumentation, bevor Sie sich festlegen.

Wann Semantic Kernel verwenden

Greifen Sie zu SK, wenn:

• Ihr Stack .NET oder Java ist und Sie eine KI-Orchestrierung wünschen, die sich nativ anfühlt, anstatt eines Python-Sidecars.
• Sie ein Portfolio bestehender REST-APIs haben und möchten, dass ein Modell diese über ihre OpenAPI-Spezifikationen aufruft.
• Sie Unternehmens-Infrastruktur benötigen: Telemetrie, Filter, Hooks und die Möglichkeit zu prüfen, was die KI getan hat.
• Sie modellagnostisch bleiben und Anbieter wechseln möchten, ohne Ihre App neu schreiben zu müssen.

Suchen Sie woanders, wenn Ihr Team nur aus Python-Entwicklern besteht und Sie die absolut neuesten Multi-Agenten-Funktionen wünschen; in diesem Fall könnte MAF oder eine graph-basierte Bibliothek besser für Sie geeignet sein.

Testen der APIs hinter Ihrem Semantic Kernel Agenten

Hier kommt es auf API-Tools an, und hier passt Apidog perfekt. SK erstellt oder ersetzt Ihre APIs nicht. Es ruft sie auf. Ein SK-Agent hängt von zwei Arten von Endpunkten ab: dem LLM-Endpunkt, mit dem er kommuniziert, und den REST-APIs, die Sie als OpenAPI-Plugins importieren. Beide müssen korrekt, gut beschrieben und zuverlässig sein, sonst tätigt der Agent fehlerhafte Aufrufe.

Ein paar praktische Aufgaben:

• Entwerfen und testen Sie die OpenAPI-Spezifikation, bevor Sie sie importieren. Da SK jede Operation in eine Funktion umwandelt und dem Modell Ihre Parameterbeschreibungen zuführt, führt eine unsaubere Spezifikation zu unsauberen Tool-Aufrufen. Validieren Sie die Spezifikation, testen Sie jeden Endpunkt und bestätigen Sie, dass die Antworten dem Schema entsprechen. Sauberer Vertrag, besserer Agent.
• Mocken Sie die Abhängigkeiten während der Entwicklung. Sie können eine Mock-API für einen Endpunkt einrichten, der noch nicht gebaut ist, oder den LLM-Endpunkt mocken, um das Verbrennen von Tokens und das Erreichen von Ratenbegrenzungen während der Fehlersuche in der Orchestrierungsschleife zu vermeiden. Sehen Sie unter wie man API-Aufrufe mockt nach dem Muster.
• Antwortstrukturen überprüfen. Verwenden Sie API-Assertions, um zu überprüfen, dass die Tool-Endpunkte, die Ihr Agent aufruft, genau die Struktur zurückgeben, die das Modell erwartet, sodass eine Backend-Änderung das Agentenverhalten nicht stillschweigend unterbricht.
• Schlüssel pro Umgebung verwalten. Halten Sie Ihre LLM- und API-Anmeldeinformationen getrennt über Entwicklungs-, Staging- und Produktionsumgebungen hinweg, anstatt sie fest zu codieren.

Dies ist gewöhnliche API-Arbeit, die vor und um den Agenten herum erledigt wird, nicht an seiner Stelle. Wenn Sie eine tiefere Einführung wünschen, deckt das Testen der Tool-Aufrufe eines Agenten mit Apidog das Framework detailliert ab.

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, mit SDKs für C#/.NET, Python und Java. Sie zahlen für die Modellnutzung (OpenAI, Azure OpenAI usw.), nicht für SK selbst.

Welche Sprachen unterstützt Semantic Kernel?

C#/.NET, Python und Java, alle mit Stabilitätszusagen für Version 1.0+. Das C#-SDK ist das ausgereifteste, aber die Python- und Java-SDKs decken die Kernfunktionen von Kernel, Plugins und OpenAPI-Import ab.

Wie nutzt Semantic Kernel OpenAPI-Spezifikationen?

Sie importieren eine Spezifikation mit `ImportPluginFromOpenApiAsync` (C#) oder `add_plugin_from_openapi` (Python). SK parst die Spezifikation, wandelt jede Operation in eine aufrufbare Funktion mit ihren Parameter-Metadaten um und lässt das Modell diese Operationen aufrufen. Da das Modell auf Ihren Beschreibungen basiert, lohnt es sich, die Spezifikation zuerst zu validieren. Das können Sie mit Apidog tun und die Live-Endpunkte testen.

Sollte ich Semantic Kernel oder das Microsoft Agent Framework verwenden?

Wenn Sie bereits eine SK-Anwendung haben, verwenden Sie diese weiterhin; sie wird unterstützt und ist stabil. Für neue Projekte positioniert Microsoft das Agent Framework als Nachfolger und bietet einen Migrationsleitfaden an. Überprüfen Sie die aktuellen MAF-Dokumente, bevor Sie neu beginnen, da sich dieser Bereich schnell ändert. Um die APIs zu testen, die eine der beiden aufruft, lesen Sie wie man die ChatGPT API mit Apidog testet.

Zusammenfassung

Semantic Kernel bietet Microsoft-Stack-Teams eine saubere Möglichkeit, KI zu orchestrieren: einen Kernel, der Modelle mit Ihrem Code verbindet, Plugins und Funktionen, die das Modell aufrufen kann, und einen OpenAPI-Importpfad, der Ihre bestehenden REST-APIs als Agenten-Tools verfügbar macht. Es ist stabil und produktionserprobt, wobei das Agent Framework nun die neueste Richtung vorantreibt. Egal, wofür Sie sich entscheiden, die zugrunde liegenden APIs müssen dennoch solide sein. Um die Spezifikationen und Endpunkte, von denen Ihr Agent abhängt, zu entwerfen, zu mocken und zu testen, laden Sie Apidog herunter und erstellen Sie den Vertrag, bevor der Agent ihn jemals aufruft.