Qué es Microsoft Agent Framework
Microsoft Agent Framework es un SDK y entorno de ejecución de código abierto, con licencia MIT, para crear y orquestar agentes y flujos de trabajo multiagente en .NET y Python. Procede de los equipos de Semantic Kernel y AutoGen y alcanzó su versión 1.0 en abril de 2026. Los flujos de trabajo son grafos con patrones de colaboración secuencial, concurrente, de traspaso y de grupo, con puntos de control, streaming, control human-in-the-loop, trazado con OpenTelemetry y un sistema de middleware. Los agentes también pueden declararse en YAML, y Microsoft documenta el alojamiento en Foundry. En octubre de 2026, Semantic Kernel recibe correcciones mientras el trabajo de nuevas funciones se realiza en Agent Framework, y AutoGen está en modo de mantenimiento, con guías de migración para ambos.
Flujos de trabajo definidos en código frente a configuración declarada
Si llegó aquí buscando AutoGen o Semantic Kernel, la comparación práctica hoy es con Agent Framework, porque es hacia donde Microsoft dirige los proyectos nuevos. Es un SDK: su flujo de trabajo es código en su servicio, en su lenguaje, y usted elige cómo alojarlo, protegerlo y auditarlo, con un soporte sólido para Azure. EDDI hace el compromiso contrario. El agente es configuración JSON interpretada por una plataforma desplegada, de modo que el comportamiento puede compararse con diff, revisarse y cambiarse sin recompilar, y la plataforma aporta la API, la interfaz Manager, el vault de secretos y el libro de auditoría.
SDK para su servicio frente a plataforma que usted despliega
| Dimensión | Microsoft Agent Framework | EDDI |
|---|---|---|
| Formato | SDK y entorno de ejecución integrados en su servicio .NET o Python | Middleware desplegable sobre JVM (Quarkus); se ejecuta donde se ejecute Docker o Kubernetes |
| Cómo se definen los agentes | Agentes y flujos de trabajo en grafo definidos en código; los agentes también pueden declararse en YAML | Configuración JSON; reglas de comportamiento deterministas deciden la siguiente acción, y las llamadas al LLM ocurren en tareas declaradas |
| Lenguajes | .NET y Python (Go en un repositorio aparte) | Cualquier lenguaje mediante REST, MCP y la API compatible con OpenAI; el agente en sí no requiere código |
| Licencia | MIT | Apache 2.0, aprobada por la OSI |
| Lógica personalizada en tiempo de ejecución | Su código y sus funciones de herramientas se ejecutan en su proceso | Sin eval() ni ejecución de código en tiempo de ejecución; la lógica se declara o reside tras una herramienta MCP o una llamada HTTP |
| Human in the loop | Control human-in-the-loop a nivel de flujo de trabajo | Puertas de aprobación en tres niveles: turnos (PAUSE_CONVERSATION), llamadas a herramientas (toolApprovals) y fases de grupo, con políticas de tiempo de espera |
| Patrones multiagente | Colaboración secuencial, concurrente, de traspaso y de grupo en código | Debates de grupo con 7 estilos (mesa redonda, revisión por pares, abogado del diablo, Delphi, debate, grupo de trabajo, negociación), con decisiones y disensos registrados |
| Estado y recuperación | Puntos de control y viaje en el tiempo en el entorno de ejecución del flujo de trabajo | Memoria de conversación persistida por la plataforma; estados explícitos como AWAITING_HUMAN |
| Observabilidad y auditoría | Trazado con OpenTelemetry y ganchos de middleware; el destino de los datos depende de usted | Métricas de Prometheus más un libro de auditoría firmado con HMAC, de solo anexado y con control de secuencia, con un endpoint de verificación |
| Secretos e identidad | Los mecanismos de su plataforma, por ejemplo servicios de Azure | Secrets Vault integrado con AES-256-GCM; Keycloak/OIDC opcional con los roles eddi-admin y eddi-approver |
| Encaje en el ecosistema | Integración profunda con Microsoft y Azure, incluidos los agentes alojados en Foundry | Neutral respecto a proveedores: 19 proveedores de LLM, modelos locales mediante Ollama o Jlama, 84 herramientas MCP |
Los datos sobre la otra herramienta se contrastaron con su documentación oficial y su repositorio en octubre de 2026. Estos proyectos cambian rápido, así que confirme el comportamiento actual con el proveedor antes de decidir.
Cómo elegir entre ambas
Cuándo Microsoft Agent Framework es la mejor opción
- Su equipo escribe .NET y los agentes pertenecen a un servicio C# existente, con su propio despliegue y sus propias pruebas.
- Desarrolla sobre Azure y quiere una integración de primer nivel con Foundry y los servicios de Microsoft que lo rodean.
- Tiene plugins de Semantic Kernel o código de AutoGen, y la ruta de migración soportada sale más barata que un cambio de plataforma.
- El flujo de trabajo necesita un flujo de control que la configuración no puede expresar, como topologías de grafo a medida, ramificación de puntos de control o depuración con viaje en el tiempo.
- Quiere un SDK para desarrolladores y prefiere decidir por sí mismo cómo alojarlo, protegerlo y observarlo.
Cuándo EDDI es la mejor opción
- El comportamiento del agente debe ser configuración que los revisores puedan leer y promover entre entornos, sin recompilar.
- Una revisión de seguridad preguntará qué código se ejecuta durante la inferencia, y usted quiere que la respuesta sea ninguno en la plataforma.
- Las aprobaciones deben existir en el nivel de turno, de llamada a herramienta y de fase de grupo, con un registro firmado de quién decidió qué.
- Necesita una interfaz Manager, un vault de secretos, una API y un libro de auditoría listos, en lugar de ensamblarlos en torno a un SDK.
- Quiere mantenerse neutral respecto a la nube: Kubernetes, OpenShift, instalaciones propias o entornos aislados (air-gapped) con modelos locales.
Cómo migrar desde AutoGen, Semantic Kernel o Agent Framework
Cuente con una traducción de la intención más que del código. Los roles y las herramientas se conservan; la lógica de los grafos pasa a ser reglas de comportamiento, y todo lo que requiera código real se traslada tras una herramienta MCP o un endpoint OpenAPI.
| Microsoft Agent Framework | EDDI |
|---|---|
| Agente con instrucciones | Agente de EDDI con una tarea LLM y un mensaje de sistema |
| Plugin o función de Semantic Kernel | Herramienta MCP, o httpCall o una API importada desde OpenAPI |
| Grafo de flujo de trabajo o equipo de AutoGen | Reglas de comportamiento para el enrutamiento, o un estilo de debate de grupo para el trabajo multiagente |
| Paso human-in-the-loop | Regla PAUSE_CONVERSATION, patrones glob de toolApprovals, o requiresApproval en una fase de grupo |
| Almacén de puntos de control | Memoria de conversación con los ámbitos step, conversation y longTerm |
| Middleware y filtros | Reglas de comportamiento y políticas de aprobación de herramientas |
| Trazas de OpenTelemetry | Métricas de Prometheus y el libro de auditoría |
Preguntas frecuentes
¿Microsoft Agent Framework sustituye a AutoGen y Semantic Kernel?
Microsoft lo presenta como el sucesor de ambos y publica guías de migración. En octubre de 2026, Semantic Kernel recibe correcciones mientras las nuevas funciones llegan a Agent Framework, y AutoGen está en modo de mantenimiento. Si empieza un proyecto nuevo sobre el stack de Microsoft, Agent Framework es el que debe evaluar frente a EDDI.
¿Puede EDDI sustituir a AutoGen en conversaciones multiagente?
En muchos casos, sí. Los debates de grupo de EDDI cubren los estilos de mesa redonda, revisión por pares, abogado del diablo, Delphi, debate, grupo de trabajo y negociación, con fases que pueden exigir aprobación humana y una decisión registrada con su disenso. Si sus agentes necesitan una coordinación libre a nivel de código, un SDK encaja mejor.
¿Tengo que renunciar a Azure para usar EDDI?
No. EDDI admite Azure OpenAI como proveedor y se ejecuta en Kubernetes, incluido AKS. No ofrece la integración profunda con Azure y Foundry que sí ofrece Agent Framework, así que téngalo en cuenta si está comprometido con el ecosistema de Microsoft.
¿Pueden funcionar juntos?
Sí. EDDI expone un servidor MCP, una API REST y una API compatible con OpenAI, y puede consumir servidores MCP y agentes A2A. Un servicio .NET puede llamar a los agentes de EDDI como herramientas, y EDDI puede llamar a su servicio mediante httpCall.
Otras comparativas
- EDDI vs. LangChain y LangGraph
- EDDI vs. CrewAI
- EDDI vs. Dify
- EDDI vs. n8n
- EDDI vs. Flowise
- EDDI vs. Rasa
- Todas las alternativas: constructores, bibliotecas y plataformas en la nube
¿Listo para producción?
Obtenga despliegue gestionado, soporte respaldado por SLA y ayuda directa del equipo que desarrolla EDDI.
Hable con nosotros sobre el despliegue empresarial