Lösungen für
Bitte auswählen
Web-App testen
ki-werkzeuge

Microsoft Agent Framework

Redaktion ·

Microsoft Agent Framework — warum dich das angeht

Wer in den letzten Jahren mit Microsofts Agenten-Tooling gebaut hat, stand vor einer unangenehmen Wahl: Semantic Kernel oder AutoGen? Beide kamen aus demselben Haus, lösten ähnliche Probleme, hatten aber unterschiedliche Philosophien, getrennte APIs und keine gemeinsame Roadmap. Wer falsch wählte, baute auf einem Toten Gleis.

Mit dem Microsoft Agent Framework ist diese Wahl seit Oktober 2025 erledigt. Microsoft hat beide Projekte in ein einziges SDK zusammengeführt und am 3. April 2026 als Version 1.0 für .NET und Python freigegeben (laut Microsoft-Ankündigung „production-ready”). Semantic Kernel und AutoGen gehen damit in den Maintenance-Modus — sie bekommen weiter Bug- und Security-Fixes, aber keine neuen Features mehr.

Das ist relevant, wenn du im Microsoft- oder Azure-Ökosystem entwickelst, wenn du .NET als Agenten-Plattform brauchst (eine Lücke, die die Python-lastige Konkurrenz kaum füllt), oder wenn du einfach wissen willst, wo Microsoft im Wettbewerb mit LangGraph und CrewAI steht. Dieser Artikel erklärt die Kernkonzepte, die Architektur, die Einordnung im Markt — und für wen sich der Einstieg lohnt.

Die Kernidee: Zwei Projekte, eine Linie

Um das Framework zu verstehen, hilft ein Blick auf seine beiden Vorgänger und was jeder beigetragen hat.

AutoGen — die einfachen Abstraktionen

AutoGen war Microsofts Research-getriebenes Multi-Agenten-Framework. Seine Stärke: schlanke, intuitive Abstraktionen für einzelne Agenten und für Konversationen mehrerer Agenten untereinander. Du konntest schnell ein Setup bauen, in dem zwei oder drei Agenten miteinander reden, sich gegenseitig korrigieren und ein Problem im Dialog lösen. AutoGen war gut für Prototypen und Experimente — weniger für den harten Produktivbetrieb.

Semantic Kernel — die Enterprise-Maschinerie

Semantic Kernel kam aus der anderen Richtung: ein Enterprise-orientiertes SDK mit Fokus auf Stabilität, Typsicherheit, Telemetrie, Filtern (Middleware) und breiter Modell- und Embedding-Unterstützung. Es war robuster, aber auch schwergewichtiger und komplexer im Einstieg.

Das Agent Framework als Synthese

Das Agent Framework nimmt von beiden das Beste: AutoGens einfache Agenten-Abstraktionen plus Semantic Kernels Enterprise-Features — sessionbasiertes State-Management, Typsicherheit, Middleware, Telemetrie. Darauf packt es etwas Neues: graphbasierte Workflows für explizite Mehr-Agenten-Orchestrierung. Gebaut wurde es von denselben Teams, die vorher an SK und AutoGen gearbeitet haben — es ist also kein Fremdkörper, sondern die direkte Fortsetzung beider Linien.

Die zwei Säulen: Agents und Workflows

Die zentrale Designentscheidung des Frameworks ist die Trennung in zwei Kategorien. Wer diese Unterscheidung verinnerlicht, hat das Framework im Kern verstanden.

Agents — autonome Einzelakteure

Ein Agent ist eine Einheit, die ein Sprachmodell nutzt, um Eingaben zu verarbeiten, Tools und MCP-Server aufzurufen und Antworten zu erzeugen. Agenten sind die richtige Wahl, wenn die Aufgabe offen oder dialogisch ist, wenn das Modell selbst entscheiden soll, welches Tool wann sinnvoll ist, und wenn ein einzelner Modell-Aufruf (eventuell mit Tools) reicht.

Ein minimaler Agent in Python sieht so aus:

from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

client = FoundryChatClient(
    project_endpoint="https://your-foundry-service.services.ai.azure.com/api/projects/your-project",
    model="gpt-5.4-mini",
    credential=AzureCliCredential(),
)

agent = client.as_agent(
    name="HelloAgent",
    instructions="Du bist ein freundlicher Assistent. Halte dich kurz.",
)

result = await agent.run("Was ist die größte Stadt Frankreichs?")
print(result)

In .NET ist das Muster fast identisch — dotnet add package Microsoft.Agents.AI.Foundry, dann ein AIAgent über den AIProjectClient. Dass beide Sprachen erstklassig unterstützt sind, ist der vielleicht wichtigste Unterscheidungspunkt zum restlichen Markt.

Workflows — explizite Orchestrierung

Ein Workflow ist ein gerichteter Graph, der Agenten und gewöhnliche Funktionen zu mehrstufigen Abläufen verbindet — mit typsicherem Routing, Checkpointing und Human-in-the-Loop-Unterstützung. Workflows sind die richtige Wahl, wenn der Prozess klar definierte Schritte hat, wenn du die Ausführungsreihenfolge explizit kontrollieren willst und wenn mehrere Agenten oder Funktionen koordiniert zusammenarbeiten müssen.

Der Unterschied in einem Satz: Ein Agent entscheidet selbst, was als Nächstes passiert; ein Workflow schreibt den Pfad vor und lässt das Modell nur die einzelnen Knoten füllen.

Die Bausteine darunter

Unter Agents und Workflows liegen die Komponenten, aus denen sich konkrete Anwendungen zusammensetzen. Diese Liste ist nützlich, weil sie zeigt, wie weit das Framework über „LLM-Aufruf mit Schleife” hinausgeht.

  • Model Clients — Anbindung an Chat-Completion- und Responses-APIs. Unterstützt werden laut Microsoft unter anderem Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic und Ollama (lokal).
  • Agent Session — sessionbasiertes State-Management für mehrturnige Dialoge und langlaufende Abläufe.
  • Context Providers — das Gedächtnis des Agenten: relevanter Kontext wird über diese Schnittstelle bereitgestellt.
  • Middleware — fängt Agenten-Aktionen ab, um sie zu loggen, zu filtern oder zu modifizieren (das frühere „Filter”-Konzept aus Semantic Kernel).
  • MCP-Clients — Tool-Integration über das Model Context Protocol, plus Unterstützung für das A2A-Protokoll (Agent-to-Agent).
  • Checkpointing — Workflows lassen sich an definierten Punkten speichern und wieder aufnehmen, wichtig für lange Läufe und Fehlerresilienz.
  • Telemetrie — Observability über OpenTelemetry, eng verzahnt mit Azure AI Foundry für Tracing, Evaluation und Monitoring.

Die MCP- und A2A-Unterstützung ist bemerkenswert: Microsoft setzt damit auf offene Protokolle statt auf einen geschlossenen Eigenstandard — was die Interoperabilität mit Tools und Agenten anderer Anbieter erleichtert.

Einordnung: Wo steht das Framework im Wettbewerb?

Der Markt für Agenten-Frameworks hat sich 2026 weitgehend auf einige wenige ernsthafte Optionen konsolidiert. Eine ehrliche Einordnung gegen die zwei wichtigsten Alternativen — mehr dazu im Überblick über Agenten-Frameworks.

| Kriterium | Microsoft Agent Framework | LangGraph | CrewAI | |---|---|---|---| | Modell | Agents + graphbasierte Workflows | Graphbasierte State-Machine | Rollenbasierte „Crews” | | Sprachen | Python + .NET | Python (TS separat) | Python | | Stärke | Azure-Integration, .NET, offene Protokolle | Produktionsreife, durable State | Schnellster Prototyp | | Reife (Stand 2026) | GA 1.0 seit April 2026 | Lange Produktionserfahrung | Große Community | | Protokolle | MCP, A2A | MCP | MCP u. a. |

Die grobe Daumenregel, die sich in den Vergleichsartikeln des Jahres 2026 herauskristallisiert: LangGraph ist die Default-Wahl für zustandsbehaftete, durable Produktions-Workflows — besonders in regulierten Branchen mit langer Live-Erfahrung (Uber, LinkedIn, Klarna laufen laut Berichten seit über einem Jahr darauf). CrewAI ist der schnellste Weg vom Konzept zur funktionierenden Multi-Agenten-Demo. Und das Microsoft Agent Framework ist die naheliegende Wahl, wenn du .NET brauchst, tief in Azure steckst oder Wert auf A2A/MCP legst.

Stolperfallen

Ein paar Dinge, die in der Praxis überraschen.

Du baust an junger Software

Trotz der 1.0-Bezeichnung ist das Framework in seiner vereinten Form erst seit April 2026 GA — also wenige Wochen, gemessen am Stand dieses Artikels. Die SDK-Pakete trugen bis kurz davor das --prerelease-Flag. Wer auf maximale Stabilität und ein großes Ökosystem an Tutorials angewiesen ist, findet bei LangGraph schlicht mehr Material und mehr Produktionsmeilen.

Migration ist nötig, nicht optional

Wenn du heute auf Semantic Kernel oder AutoGen sitzt, ist der Maintenance-Modus eine Ansage: neue Features gibt es nur noch im Agent Framework. Microsoft stellt Migrations-Guides für beide Wege bereit, aber es ist echte Arbeit, kein Drop-in-Replacement. Plane das ein, statt es zu verschieben.

„Third-Party Systems” auf eigenes Risiko

Microsoft weist in der Doku ausdrücklich darauf hin: Wer Nicht-Azure-Modelle oder fremde Agenten/Server anbindet, tut das auf eigenes Risiko und unter deren Lizenzbedingungen. Datenschutz, Datenflüsse über Azure-Grenzen hinaus und eigene Responsible-AI-Schutzmaßnahmen (Content-Filter, Metaprompts) liegen in deiner Verantwortung — das Framework nimmt sie dir nicht ab.

Für wen lohnt sich der Einstieg?

Klare Ja-Fälle: Du entwickelst in .NET und willst Agenten produktiv bauen — hier ist die Auswahl an reifen Frameworks dünn, und Microsofts Lösung ist erstklassig. Du steckst tief im Azure-Ökosystem und willst Foundry Agent Service, Observability und Deployment aus einem Guss. Oder du sitzt bereits auf Semantic Kernel oder AutoGen und musst ohnehin migrieren.

Eher Nein: Du baust ein reines Python-Projekt ohne Azure-Bindung und brauchst maximale Produktionsreife heute — dann ist LangGraph die konservativere Wahl. Oder du willst in einem Nachmittag eine Multi-Agenten-Demo bauen — dann ist CrewAI schneller am Ziel.

FAQ

Ist das Microsoft Agent Framework dasselbe wie Azure AI Foundry?
Nein, aber sie greifen ineinander. Das Agent Framework ist das Open-Source-SDK und die Runtime zum Bauen von Agenten. Azure AI Foundry (mit dem Foundry Agent Service) ist die gehostete Plattform, auf der du diese Agenten betreibst, beobachtest und deployst. Du kannst das Framework auch ohne Foundry nutzen, gewinnst mit Foundry aber Tracing, Evaluation und Deployment.
Sind Semantic Kernel und AutoGen jetzt tot?
Nicht tot, aber im Maintenance-Modus. Sie bekommen weiterhin Bug- und Security-Fixes, aber keine neuen Features. Microsoft empfiehlt die Migration zum Agent Framework, um an neue Funktionen zu kommen.
Welche Sprachen werden unterstützt?
Python und .NET (C#), beide erstklassig und mit weitgehend parallelen APIs. Diese starke .NET-Unterstützung ist der wichtigste Unterschied zur Python-dominierten Konkurrenz wie LangGraph und CrewAI.
Kann ich Nicht-Microsoft-Modelle nutzen?
Ja. Laut Microsoft werden unter anderem OpenAI, Anthropic und lokale Modelle über Ollama unterstützt — neben Azure OpenAI und Microsoft Foundry. Für Nicht-Azure-Modelle gelten allerdings deren Lizenz- und Datenschutzbedingungen, und du trägst das Risiko selbst.
Was ist der Unterschied zwischen einem Agent und einem Workflow?
Ein Agent entscheidet autonom, was als Nächstes passiert, und ist gut für offene, dialogische Aufgaben. Ein Workflow ist ein expliziter, gerichteter Graph mit fest definierten Schritten — du kontrollierst die Reihenfolge, das Modell füllt nur die Knoten. Workflows bieten Checkpointing und Human-in-the-Loop.

Fazit

Das Microsoft Agent Framework ist Microsofts Aufräumen im eigenen Garten: zwei konkurrierende Projekte zu einer Linie zusammengeführt, mit klarem Konzept (Agents für Autonomie, Workflows für Kontrolle) und ernsthafter Enterprise-Ausstattung. Die echten Stärken liegen in der erstklassigen .NET-Unterstützung, der tiefen Azure-Integration und der Wette auf offene Protokolle (MCP, A2A).

Die Einschränkung ist die Jugend: GA erst seit April 2026, weniger Produktionsmeilen als LangGraph. Wer im Microsoft-Universum baut, sollte es trotzdem zur Standardoption machen. Wer frei wählen kann und maximale Reife heute braucht, vergleicht ehrlich gegen die Alternativen — und entscheidet nach Sprache, Cloud-Bindung und gewünschtem Kontrollgrad.

Themenuebersicht

KI-WerkzeugeAgenten-Frameworks