Agentic Easter: Einführung in das Microsoft Agent Framework
Wie der Osterhase zum C#-Developer wurde und Agenten lieben lernte
Der Osterhase hatte ein Problem.Jedes Jahr wurden die Anforderungen komplexer: mehr Eier, mehr Farben, mehr Sonderwünsche. Irgendwann war klar – das alles lässt sich nicht mehr mit handgeschriebenen To-do-Listen und Bauchgefühl lösen.
Also tat der Osterhase das Naheliegende: Er wurde C#-Developer 🐰💻.
Doch schnell wurde ihm klar:
Nicht der Code ist das eigentliche Problem – sondern die Organisation der Arbeit. Und genau hier kommen Agenten ins Spiel, denn der wahre Business-Wert von GenAI dann entsteht, wenn Aufgaben delegiert werden können.
- Wie baut man Systeme, die genau das zuverlässig tun?
- Und wie verhindert man, dass aus erfolgreichen Prototypen keine schwer wartbaren Insellösungen werden, sondern aus AI-Demos produktive Prozesse werden?
Die Antwort darauf führte den Osterhasen direkt in die Microsoft-Welt und stolperte er über etwas, das sein Leben für immer verändern sollte:
Das Microsoft Agent Framework
Das Microsoft Agent Framework ist ein moderner Ansatz, um KI-gestützte Agenten zu bauen, die eigenständig Aufgaben planen, ausführen und miteinander kommunizieren können.Agenten sind dabei keine einfachen Chatbots mehr, sondern
- planen ihre nächsten Schritte selbst
- rufen Funktionen oder externe Systeme auf
- arbeiten mit anderen Agenten zusammen
- können orchestriert, validiert und überwacht werden
Kurz gesagt: Agenten handeln, statt nur zu antworten. Das ist genau, was der Osterhase braucht!
Was bedeutet das für Unternehmen?
Statt einzelner KI-Use-Cases entsteht hier etwas ganz anderes: Digitale Teams statt einzelner Tools.
Das bedeutet konkret, dass Aufgaben nicht mehr manuell zwischen Systemen übergeben werden. Prozesse laufen strukturiert und nachvollziehbar ab und Verantwortungen können klar definiert werden (welcher Agent macht was?). Dadurch wird die Automatisierung skalierbar und greift nicht nur punktuell.
Dieser Unterschied ist entscheidend: Die KI unterstützt nicht nur einen Schritt,
sondern ein System erledigt ganze Prozesse eigenständig.
Ein kurzer Blick zurück:
Semantic Kernel & AutoGen
Bevor es das Microsoft Agent Framework gab, hat Microsoft bereits an wichtigen Bausteinen gearbeitet:
Semantic Kernel (Fähigkeiten schaffen)
Der Microsoft Semantic Kernel war (und ist) ein Software Development Kit, um Large Language Models mit Code zu verbinden.Es brachte Konzepte wie:
- Plugins
- Native Functions
- Planner
- Prompt-Templates
Damit konnte man KI erstmals sinnvoll in Anwendungen integrieren.
Statt nur Antworten zu generieren, kann die KI Daten abrufen, Aktionen auslösen und Systeme integrieren. Das bildet die Grundlage für die wertvolle Wirkung von KI in Unternehmen und aus einem "sprechenden Modell" wird ein handlungsfähiges System.
kurze Historie zu Semantic Kernel
Semantic Kernel ist aus dem praktischen Bedürfnis entstanden, LLMs nicht nur „chatten“ zu lassen, sondern sie mit echten Fähigkeiten (Code/APIs) zu verbinden: Plugins kapseln Funktionen, die ein Modell per Function Calling aufrufen kann.
In der frühen Phase wurden in SK sogenannte Planner genutzt, die über Prompts Funktionen auswählten. Mit dem Aufkommen von modellnativem Function Calling (quer über Modelle hinweg) hat sich SK weiterentwickelt: Function Calling ist heute der bevorzugte Mechanismus, um Aufgaben zu planen und auszuführen; ältere Planner (z.B. Stepwise/Handlebars) wurden deprecated und entfernt.
Wer noch tiefer einsteigen möchte, sind diese Learn-Seiten die beste Basis:
Welche „Funktionen“ / Bausteine gibt es?
In Semantic Kernel meint „Funktionen“ meist Kernel-/Plugin-Funktionen, die ein Modell (automatisch oder manuell) aufrufen kann. Die wichtigsten Bausteine aus der Learn-Doku:
- Kernel: Zentrale Laufzeit/Container (ähnlich DI-Container) für Services und Plugins. Understanding the kernel
- Plugins: Gruppen von Funktionen („Tools/Actions“), die semantisch beschrieben werden, damit das Modell sie korrekt auswählt. Plugins
- Plugins können aus nativem Code, aus einer OpenAPI-Spezifikation oder direkt von einem MCP Server importiert werden. (Siehe „Importing different types of plugins“ in Plugins)
- MCP-Plugins (Import)
- Function Calling: SK serialisiert verfügbare Funktionen (JSON Schema), sendet sie mit Chat-History ans Modell, führt Tool-Calls aus und reicht Ergebnisse zurück (Loop). Function calling with chat completion
- Zwei typische Funktionsarten in Plugins:
- Data retrieval functions für RAG (Daten holen/aufbereiten)
- Task automation functions (Aktionen ausführen, oft mit Human-in-the-Loop)
Siehe „The different types of plugin functions“ in Plugins.
AutoGen (Zusammenarbeit ermöglichen)
Parallel dazu entstand AutoGen, ein Framework für Multi-Agent-Szenarien. Mehrere Agenten arbeiten zusammen wie ein Team. Agenten können dabei Rollen übernehmen, miteinander kommunizieren, Aufgaben aufteilen und iterativ Lösungen erarbeiten. Komplexe Aufgaben werden zerlegbar, Wissen wird strukturiert genutzt und Prozesse werden robuster (es gibt keinen Single Point of Failure). Das entspricht einer Organisation aus Spezialisten - nur digital.
Der Osterhase stellte schnell fest:
Semantic Kernel war großartig für Fähigkeiten und AutoGen perfekt für Zusammenarbeit.
Beides zusammengeführt ergibt das Microsoft Agent Framework. Es verbindet die Stärken beider Welten:
- die Fähigkeiten & Tooling aus dem Semantic Kernel
- die Agenten-Interaktion & Orchestrierung aus AutoGen
- plus: strukturierte Workflows als neue zentrale Ebene
kurze Historie zu AutoGen
AutoGen startete als Forschungsprojekt bei Microsoft Research und hat mehrere heute weit verbreitete Multi-Agent-Konzepte früh geprägt – insbesondere GroupChat-Patterns und eine event-getriebene Agent-Runtime.
Eine gute, offizielle Einordnung findest man in der Learn-Doku rund um die Weiterentwicklung Richtung Microsoft Agent Framework:
Welche „Funktionen“ / Bausteine gibt es?
AutoGen ist kein „ein einzelner Bot“, sondern ein Baukasten für Agenten und deren Zusammenarbeit. Aus der Learn-Perspektive (und den dort referenzierten AutoGen-Konzepten) sind vor allem diese Bausteine relevant:
- Sprachen: In den offiziellen Learn-Tutorials wird AutoGen primär in Python genutzt (z.B. Prerequisites: Python 3.10+). Im AutoGen-Projekt gibt es außerdem explizit Cross-Language-Support für .NET und Python (siehe „Core API“ in der AutoGen README).
- Agenten & Rollen: Agenten sind spezialisierte Teilnehmer, die Aufgaben übernehmen und sich über Nachrichten koordinieren. (Siehe Background im Migration Guide.)
- Tooling / Funktionen: AutoGen kann Funktionen/Tools registrieren und aufrufen (z.B. als „Function Tools“) – häufig in Kombination mit einem „Tool Agent“, der die Ausführung übernimmt. Ein praxisnahes Beispiel mit Tool-Ausführung ist der Code-Interpreter-Ansatz in Azure Container Apps: Tutorial: Use code interpreter sessions in AutoGen with Azure Container Apps
- Orchestrierung / Group-Chat-Patterns: Zusammenarbeit entsteht über wiederkehrende Muster (z.B. GroupChat/Round-Robin, Manager/Worker-ähnliche Patterns). Die Learn-Doku nutzt AutoGen hier als Referenzpunkt für Patterns, die später in Agent Framework weitergeführt werden (siehe Abschnitt „Multi-Agent Feature Mapping“ im Migration Guide).
- Event-getriebene Runtime: AutoGen kombiniert einen event-driven Kern (low-level) mit höher-level Abstraktionen (z.B. Team/GroupChat), um Multi-Agent-Flows zu bauen. (Siehe „Programming Model Overview“ im Migration Guide.)
- Low-/No-Code (AutoGen Studio): Für schnelles Prototyping gibt es AutoGen Studio als GUI, um Multi-Agent-Workflows ohne viel Code zu bauen und auszuführen. (Siehe „AutoGen Studio“ in der AutoGen README.)
- Observability / Tracing: Für produktionsnahe Szenarien ist Nachvollziehbarkeit entscheidend (welcher Agent war wann dran, welche Tool-Calls, welche Latenzen). Ein konkreter Learn-Einstieg dazu ist: Tracing AutoGen (MLflow Tracing)
Damit war AutoGen „perfekt für Zusammenarbeit“: mehrere Agenten, die gemeinsam iterieren, planen und ausführen.
Warum ist das relevant?
Weil damit etwas entsteht, das viele Unternehmen bisher nicht sauber lösen konnten: End-to-End automatisierte, nachvollziehbare Prozesse.
Mit dem Framework kann man:- einzelne spezialisierte Agenten baut
- diese Agenten über standardisierte Schnittstellen verbinden (HTTP, Tools oder MCP)
- Prozesse orchestrieren
- Qualität sichern (Validation) und
- Menschen gezielt einbinden (Human-in-the-Loop)
MCP als Enabler für Integration
Ein zentraler Baustein ist MCP (Model Context Protocol). Das ist der Standard, der entscheidet, wie einfach sich KI in bestehende Systemlandschaften integrieren lässt. Statt individueller Integrationen gibt es eine einheitliche Schnittstelle, wiederverwendbare Tools und eine deutlich schnellere Time-to-Value.
MCP UI (MCP Apps): Wenn KI nicht nur Text liefert
In der Praxis zeigt sich ein oft unterschätztes Problem: Gerade bei Freigaben, Formularen oder Visualisierungen reicht Text nicht immer aus und es braucht echte Benutzeroberflächen. MCP UI als interaktives Oberflächen-Tool löst genau das, um bessere User Experience und höhere Akzeptanz bei Anwender:innen zu erreichen. So wird eine klar definierte Interaktionen zwischen Mensch und KI unterstützt.
Der Osterhase ist jedenfalls schon begeistert. Endlich konnte er seine Arbeit strukturieren, automatisieren und skalieren. Und schließlich ist ja genau das der eigentliche Mehrwert von Agenten.
Ein Hinweis zur Blogserie & zum Code
Alles, was du in dieser Blogserie lesen wirst, basiert auf echtem Code.Die komplette Beispielanwendung liegt in einem GitHub-Repository, das:
- eine React-Web-App als UI enthält
- mehrere Agenten mit eigenen HTTP-Endpunkten
- Schritt für Schritt mit jedem Blogpost erweitert wird
Jeder Blogpost baut dabei logisch auf dem vorherigen auf – genau wie der Osterhase seine Agenten-Werkstatt erweitert.
Die Eierkochmaschine existiert (leider) nicht wirklich. Sie wird später nur grafisch im Chat dargestellt.
Was kommt als Nächstes?
Im nächsten Blogpost krempelt der Osterhase die Ärmel hoch und baut seinen ersten Agenten:- mit nativen Funktionen
- gesteuert über TCP-Kommandos
- verantwortlich für seine (bald) berühmte Eierkochmaschine.
Von weichgekocht bis superstabil – alles unter Agenten-Kontrolle.
Fazit
Das Microsoft Agent Framework ist kein weiteres KI-Spielzeug.
Es ist ein fundamentaler Baustein, um echte, verteilte, intelligente Systeme zu bauen.
Der Osterhase hat es schon verstanden. Und falls du in der Zwischenzeit schon Ideen für deinen Agenten oder vielleicht sogar schon mehreren Agenten hast: Ich freue mich über einen Austausch!
Und im nächsten Post wird gekocht. 🥚🔥
Share this
You May Also Like
These Related Stories

Agentic Easter: Der Osterhase delegiert an die KI
Agentic AI vs. Klassische Prozessautomatisierung

