EDDI vs. Microsoft Agent Framework (AutoGen et Semantic Kernel)

Ce qu'est Microsoft Agent Framework

Microsoft Agent Framework est un SDK et un runtime open source sous licence MIT pour créer et orchestrer des agents et des workflows multi-agents en .NET et Python. Il est issu des équipes de Semantic Kernel et d'AutoGen et a atteint sa version 1.0 en avril 2026. Les workflows sont des graphes avec des modèles de collaboration séquentiels, concurrents, de passation (handoff) et de groupe, avec points de contrôle, streaming, contrôle Humain dans la boucle, traçage OpenTelemetry et un système de middleware. Les agents peuvent aussi être déclarés en YAML, et Microsoft documente l'hébergement sur Foundry. En octobre 2026, Semantic Kernel reçoit des correctifs tandis que le développement de nouvelles fonctionnalités se fait dans Agent Framework, et AutoGen est en mode maintenance, avec des guides de migration pour les deux.

Workflows définis en code ou configuration déclarée

Si vous êtes arrivé ici en cherchant AutoGen ou Semantic Kernel, la comparaison pertinente aujourd'hui est avec Agent Framework, car c'est là que Microsoft oriente les nouveaux projets. C'est un SDK : votre workflow est du code dans votre service, dans votre langage, et vous choisissez comment l'héberger, le sécuriser et l'auditer, avec un solide support d'Azure. EDDI fait le compromis inverse. L'agent est une configuration JSON interprétée par une plateforme déployée : son comportement peut être comparé, relu et modifié sans reconstruction, et la plateforme fournit l'API, l'interface Manager, le coffre-fort de secrets et le registre d'audit.

SDK pour votre service ou plateforme que vous déployez

Dimension	Microsoft Agent Framework	EDDI
Forme	SDK et runtime intégrés à votre service .NET ou Python	Middleware déployable sur JVM (Quarkus) ; s'exécute partout où Docker ou Kubernetes fonctionne
Définition des agents	Agents et workflows de graphes définis en code ; les agents peuvent aussi être déclarés en YAML	Configuration JSON ; des règles de comportement déterministes décident de l'action suivante, les appels LLM ont lieu dans des tâches déclarées
Langages	.NET et Python (Go dans un dépôt séparé)	Tout langage via REST, MCP et l'API compatible OpenAI ; l'agent lui-même ne nécessite aucun code
Licence	MIT	Apache 2.0, approuvée par l'OSI
Logique personnalisée à l'exécution	Votre code et vos fonctions d'outils s'exécutent dans votre processus	Aucun eval() ni exécution de code à l'exécution ; la logique est déclarée, ou se trouve derrière un outil MCP ou un appel HTTP
Humain dans la boucle	Contrôle Humain dans la boucle au niveau du workflow	Points de validation à trois niveaux : tours (PAUSE_CONVERSATION), appels d'outils (toolApprovals) et phases de groupe, avec politiques de délai
Modèles multi-agents	Collaboration séquentielle, concurrente, de passation et de groupe en code	Discussions de groupe avec 7 styles (table ronde, revue par les pairs, avocat du diable, Delphi, débat, task force, négociation), décisions et désaccords consignés
État et reprise	Points de contrôle et retour dans le temps dans le runtime de workflow	Mémoire de conversation persistée par la plateforme ; états explicites tels que AWAITING_HUMAN
Observabilité et audit	Traçage OpenTelemetry et hooks de middleware ; la destination des données vous appartient	Métriques Prometheus et registre d'audit signé HMAC, en ajout seul, à séquence vérifiée, avec un point de terminaison de vérification
Secrets et identité	Les mécanismes de votre plateforme, par exemple les services Azure	Secrets Vault intégré en AES-256-GCM ; Keycloak/OIDC optionnel avec les rôles eddi-admin et eddi-approver
Adéquation à l'écosystème	Intégration poussée avec Microsoft et Azure, y compris les agents hébergés sur Foundry	Neutre vis-à-vis des éditeurs : 19 fournisseurs LLM, modèles locaux via Ollama ou Jlama, 84 outils MCP

Les informations sur l'autre outil ont été vérifiées dans sa documentation officielle et son dépôt en octobre 2026. Ces projets évoluent vite : confirmez le comportement actuel auprès de l'éditeur avant de décider.

Choisir entre les deux

Quand Microsoft Agent Framework est le meilleur choix

Votre équipe écrit du .NET et les agents appartiennent à un service C# existant, avec son propre déploiement et ses propres tests.
Vous développez sur Azure et voulez une intégration de premier ordre avec Foundry et les services Microsoft environnants.
Vous avez des plugins Semantic Kernel ou du code AutoGen, et le chemin de migration pris en charge coûte moins cher qu'un changement de plateforme.
Le workflow exige un flux de contrôle que la configuration ne peut pas exprimer, comme des topologies de graphe sur mesure, des branches de points de contrôle ou le débogage par retour dans le temps.
Vous voulez un SDK pour développeurs et préférez décider vous-même comment l'héberger, le sécuriser et l'observer.

Quand EDDI est le meilleur choix

Le comportement des agents doit être une configuration que les relecteurs peuvent lire et promouvoir entre environnements, sans reconstruction.
Une revue de sécurité demandera quel code s'exécute au moment de l'inférence, et vous voulez que la réponse soit : aucun dans la plateforme.
Des approbations doivent exister au niveau du tour, de l'appel d'outil et de la phase de groupe, avec une trace signée de qui a décidé quoi.
Vous avez besoin d'une interface Manager, d'un coffre-fort de secrets, d'une API et d'un registre d'audit prêts à l'emploi plutôt que de les assembler autour d'un SDK.
Vous voulez rester neutre vis-à-vis du cloud : Kubernetes, OpenShift, sur site ou isolé du réseau (air-gapped) avec des modèles locaux.

Migrer depuis AutoGen, Semantic Kernel ou Agent Framework

Attendez-vous à une traduction d'intention plutôt que de code. Les rôles et les outils se transposent ; la logique de graphe devient des règles de comportement, et tout ce qui exige du vrai code passe derrière un outil MCP ou un point de terminaison OpenAPI.

Microsoft Agent Framework	EDDI
Agent avec instructions	Agent EDDI avec une tâche LLM et un message système
Plugin ou fonction Semantic Kernel	Outil MCP, ou httpCall ou API importée depuis OpenAPI
Graphe de workflow ou équipe AutoGen	Règles de comportement pour le routage, ou un style de discussion de groupe pour le travail multi-agents
Étape Humain dans la boucle	Règle PAUSE_CONVERSATION, globs toolApprovals, ou requiresApproval sur une phase de groupe
Magasin de points de contrôle	Mémoire de conversation avec les portées step, conversation et longTerm
Middleware et filtres	Règles de comportement et politiques d'approbation des outils
Traces OpenTelemetry	Métriques Prometheus et registre d'audit

Questions fréquentes

Microsoft Agent Framework remplace-t-il AutoGen et Semantic Kernel ?

Microsoft le présente comme le successeur des deux et publie des guides de migration. En octobre 2026, Semantic Kernel reçoit des correctifs tandis que les nouvelles fonctionnalités arrivent dans Agent Framework, et AutoGen est en mode maintenance. Si vous démarrez un nouveau projet sur la pile Microsoft, c'est Agent Framework qu'il faut évaluer face à EDDI.

EDDI peut-il remplacer AutoGen pour les conversations multi-agents ?

Dans de nombreux cas, oui. Les discussions de groupe d'EDDI couvrent les styles table ronde, revue par les pairs, avocat du diable, Delphi, débat, task force et négociation, avec des phases pouvant exiger une approbation humaine et une décision consignée avec les désaccords. Si vos agents ont besoin d'une coordination libre au niveau du code, un SDK convient mieux.

Dois-je renoncer à Azure pour utiliser EDDI ?

Non. EDDI prend en charge Azure OpenAI comme fournisseur et s'exécute sur Kubernetes, y compris AKS. Il ne propose pas l'intégration poussée avec Azure et Foundry qu'offre Agent Framework : pesez ce point si vous êtes engagé dans l'écosystème Microsoft.

Les deux peuvent-ils fonctionner ensemble ?

Oui. EDDI expose un serveur MCP, une API REST et une API compatible OpenAI, et peut consommer des serveurs MCP et des agents A2A. Un service .NET peut appeler des agents EDDI comme outils, et EDDI peut appeler votre service via httpCall.

Autres comparatifs

Prêt pour la production ?

Bénéficiez d'un déploiement géré, d'un support garanti par SLA et de l'accompagnement direct de l'équipe qui développe EDDI.

Parlez-nous de votre déploiement en entreprise

Fonctionnalités

Entreprise

Cloud managé et support entreprise

Ressources