Was Microsoft Agent Framework ist
Microsoft Agent Framework ist ein MIT-lizenziertes Open-Source-SDK samt Runtime zum Bau und zur Orchestrierung von Agents und Multi-Agent-Workflows in .NET und Python. Es stammt von den Teams hinter Semantic Kernel und AutoGen und erreichte im April 2026 sein 1.0-Release. Workflows sind Graphen mit sequenziellen, nebenläufigen, Handoff- und Gruppen-Kollaborationsmustern, mit Checkpointing, Streaming, Human-in-the-Loop-Steuerung, OpenTelemetry-Tracing und einem Middleware-System. Agents lassen sich auch in YAML deklarieren, und Microsoft dokumentiert das Hosting auf Foundry. Stand Oktober 2026 erhält Semantic Kernel Fixes, während neue Funktionen in Agent Framework entstehen, und AutoGen befindet sich im Wartungsmodus, mit Migrationsleitfäden für beide.
Im Code definierte Workflows versus deklarierte Konfiguration
Wenn Sie über die Suche nach AutoGen oder Semantic Kernel hierher gekommen sind: Der praktische Vergleich ist heute der mit Agent Framework, denn dorthin verweist Microsoft neue Projekte. Es ist ein SDK: Ihr Workflow ist Code in Ihrem Service, in Ihrer Sprache, und Sie entscheiden, wie Sie ihn hosten, absichern und auditieren, mit starker Unterstützung für Azure. EDDI geht den umgekehrten Kompromiss ein. Der Agent ist JSON-Konfiguration, die eine deployte Plattform interpretiert, sodass sich das Verhalten diffen, prüfen und ohne Rebuild ändern lässt, und die Plattform liefert API, Manager-UI, Secrets Vault und Audit-Ledger.
SDK für Ihren Service versus Plattform, die Sie deployen
| Dimension | Microsoft Agent Framework | EDDI |
|---|---|---|
| Bauform | SDK und Runtime, eingebettet in Ihren .NET- oder Python-Service | Deploybare Middleware auf einer JVM (Quarkus); läuft überall, wo Docker oder Kubernetes läuft |
| Wie Agents definiert werden | Im Code definierte Agents und Graph-Workflows; Agents lassen sich auch in YAML deklarieren | JSON-Konfiguration; deterministische Behavior Rules bestimmen die nächste Aktion, LLM-Aufrufe finden in deklarierten Tasks statt |
| Sprachen | .NET und Python (Go in einem separaten Repository) | Jede Sprache über REST, MCP und die OpenAI-kompatible API; der Agent selbst braucht keinen Code |
| Lizenz | MIT | Apache 2.0, OSI-zertifiziert |
| Eigene Logik zur Laufzeit | Ihr Code und Ihre Tool-Funktionen laufen in Ihrem Prozess | Kein eval() und keine Codeausführung zur Laufzeit; Logik wird deklariert oder liegt hinter einem MCP-Tool oder HTTP-Aufruf |
| Human in the Loop | Human-in-the-Loop-Steuerung auf Workflow-Ebene | Gates auf drei Ebenen: Turns (PAUSE_CONVERSATION), Tool-Aufrufe (toolApprovals) und Gruppenphasen, mit Timeout-Richtlinien |
| Multi-Agent-Muster | Sequenzielle, nebenläufige, Handoff- und Gruppen-Kollaboration im Code | Gruppendiskussionen mit 7 Stilen (Round Table, Peer Review, Advocatus Diaboli, Delphi, Debatte, Task Force, Verhandlung), dokumentierte Entscheidungen und abweichende Meinungen |
| Zustand und Wiederherstellung | Checkpointing und Time-Travel in der Workflow-Runtime | Von der Plattform persistierter Konversationsspeicher; explizite Zustände wie AWAITING_HUMAN |
| Observability und Audit | OpenTelemetry-Tracing und Middleware-Hooks; wohin die Daten gehen, liegt bei Ihnen | Prometheus-Metriken plus ein HMAC-signiertes, append-only geführtes, sequenzgeprüftes Audit-Ledger mit Verify-Endpunkt |
| Secrets und Identität | Die Mechanismen Ihrer Plattform, zum Beispiel Azure-Dienste | Integrierter AES-256-GCM Secrets Vault; optionales Keycloak/OIDC mit den Rollen eddi-admin und eddi-approver |
| Ökosystem-Passung | Tiefe Integration in Microsoft und Azure, einschließlich Foundry-gehosteter Agents | Herstellerneutral: 19 LLM-Anbieter, lokale Modelle über Ollama oder Jlama, 84 MCP-Tools |
Die Angaben zum jeweils anderen Tool wurden im Oktober 2026 anhand der offiziellen Dokumentation und des Repositorys geprüft. Diese Projekte ändern sich schnell. Bestätigen Sie das aktuelle Verhalten daher beim Anbieter, bevor Sie sich entscheiden.
Die Wahl zwischen beiden
Wo Microsoft Agent Framework die bessere Wahl ist
- Ihr Team schreibt .NET, und die Agents gehören in einen bestehenden C#-Service mit eigenem Deployment und eigenen Tests.
- Sie bauen auf Azure und möchten erstklassige Integration mit Foundry und den umgebenden Microsoft-Diensten.
- Sie haben Semantic-Kernel-Plugins oder AutoGen-Code, und der unterstützte Migrationspfad ist günstiger als ein Plattformwechsel.
- Der Workflow braucht Kontrollfluss, den Konfiguration nicht ausdrücken kann, etwa eigene Graph-Topologien, Checkpoint-Verzweigung oder Time-Travel-Debugging.
- Sie möchten ein Entwickler-SDK und selbst entscheiden, wie Sie es hosten, absichern und beobachten.
Wo EDDI die bessere Wahl ist
- Agent-Verhalten muss Konfiguration sein, die Reviewer lesen und ohne Rebuild zwischen Umgebungen promoten können.
- Ein Security-Review wird fragen, welcher Code zur Inferenzzeit läuft, und die Antwort soll lauten: in der Plattform keiner.
- Freigaben müssen auf Ebene von Turn, Tool-Aufruf und Gruppenphase existieren, mit einem signierten Nachweis, wer was entschieden hat.
- Sie brauchen eine fertige Manager-UI, einen Secrets Vault, eine API und ein Audit-Ledger, statt sie um ein SDK herum zusammenzusetzen.
- Sie möchten cloudneutral bleiben: Kubernetes, OpenShift, On-Premises oder Air-Gapped mit lokalen Modellen.
Umzug von AutoGen, Semantic Kernel oder Agent Framework
Rechnen Sie mit einer Übersetzung der Absicht, nicht des Codes. Rollen und Tools lassen sich übertragen; Graph-Logik wird zu Behavior Rules, und alles, was echten Code braucht, wandert hinter ein MCP-Tool oder einen OpenAPI-Endpunkt.
| Microsoft Agent Framework | EDDI |
|---|---|
| Agent mit Instructions | EDDI-Agent mit einem LLM-Task und einer System-Nachricht |
| Semantic-Kernel-Plugin oder -Funktion | MCP-Tool oder eine per httpCall oder OpenAPI-Import eingebundene API |
| Workflow-Graph oder AutoGen-Team | Behavior Rules für das Routing oder ein Gruppendiskussionsstil für Multi-Agent-Arbeit |
| Human-in-the-Loop-Schritt | PAUSE_CONVERSATION-Regel, toolApprovals-Globs oder requiresApproval auf einer Gruppenphase |
| Checkpoint-Store | Konversationsspeicher mit den Scopes step, conversation und longTerm |
| Middleware und Filter | Behavior Rules und Tool-Freigaberichtlinien |
| OpenTelemetry-Traces | Prometheus-Metriken und das Audit-Ledger |
Häufige Fragen
Ist Microsoft Agent Framework der Ersatz für AutoGen und Semantic Kernel?
Microsoft stellt es als Nachfolger beider vor und veröffentlicht Migrationsleitfäden. Stand Oktober 2026 erhält Semantic Kernel Fixes, während neue Funktionen in Agent Framework landen, und AutoGen befindet sich im Wartungsmodus. Wenn Sie ein neues Projekt auf dem Microsoft-Stack starten, ist Agent Framework das, was Sie gegen EDDI evaluieren sollten.
Kann EDDI AutoGen für Multi-Agent-Konversationen ersetzen?
In vielen Fällen ja. Die EDDI-Gruppendiskussionen decken die Stile Round Table, Peer Review, Advocatus Diaboli, Delphi, Debatte, Task Force und Verhandlung ab, mit Phasen, die eine menschliche Freigabe verlangen können, und einer dokumentierten Entscheidung samt abweichender Meinung. Wenn Ihre Agents freie Koordination auf Code-Ebene brauchen, passt ein SDK besser.
Muss ich Azure aufgeben, um EDDI zu nutzen?
Nein. EDDI unterstützt Azure OpenAI als Anbieter und läuft auf Kubernetes, einschließlich AKS. Die tiefe Azure- und Foundry-Integration von Agent Framework bietet es nicht. Wägen Sie das ab, wenn Sie auf das Microsoft-Ökosystem festgelegt sind.
Können beide zusammenarbeiten?
Ja. EDDI stellt einen MCP-Server, eine REST-API und eine OpenAI-kompatible API bereit und kann MCP-Server und A2A-Agents nutzen. Ein .NET-Service kann EDDI-Agents als Tools aufrufen, und EDDI kann Ihren Service über httpCall aufrufen.
Weitere Vergleiche
- EDDI vs. LangChain und LangGraph
- EDDI vs. CrewAI
- EDDI vs. Dify
- EDDI vs. n8n
- EDDI vs. Flowise
- EDDI vs. Rasa
- Alle Alternativen: Builder, Bibliotheken und Cloud-Plattformen
Bereit für die Produktion?
Erhalten Sie Managed Deployment, SLA-gestützten Support und praktische Unterstützung vom Team, das EDDI entwickelt.
Sprechen Sie mit uns über Enterprise-Deployment