O que é o Microsoft Agent Framework
O Microsoft Agent Framework é um SDK e runtime de código aberto, com licença MIT, para criar e orquestrar agentes e workflows multiagente em .NET e Python. Vem das equipes por trás do Semantic Kernel e do AutoGen e chegou à versão 1.0 em abril de 2026. Os workflows são grafos com padrões de colaboração sequencial, concorrente, de handoff e em grupo, com checkpointing, streaming, controle human-in-the-loop, rastreamento OpenTelemetry e um sistema de middleware. Os agentes também podem ser declarados em YAML, e a Microsoft documenta a hospedagem no Foundry. Em outubro de 2026, o Semantic Kernel recebe correções enquanto o trabalho de novos recursos acontece no Agent Framework, e o AutoGen está em modo de manutenção, com guias de migração para ambos.
Workflows definidos em código versus configuração declarada
Se você chegou aqui procurando AutoGen ou Semantic Kernel, a comparação prática hoje é com o Agent Framework, porque é para ele que a Microsoft encaminha os novos projetos. É um SDK: o seu workflow é código no seu serviço, na sua linguagem, e você escolhe como hospedar, proteger e auditar, com forte suporte ao Azure. O EDDI faz a troca oposta. O agente é configuração JSON interpretada por uma plataforma implantada, de modo que o comportamento pode ser comparado por diff, revisado e alterado sem recompilar, e a plataforma fornece a API, a interface Manager, o cofre de segredos e o ledger de auditoria.
SDK para o seu serviço versus plataforma que você implanta
| Dimensão | Microsoft Agent Framework | EDDI |
|---|---|---|
| Formato | SDK e runtime embutidos no seu serviço .NET ou Python | Middleware implantável em uma JVM (Quarkus); roda onde o Docker ou o Kubernetes rodam |
| Como os agentes são definidos | Agentes e workflows em grafo definidos em código; os agentes também podem ser declarados em YAML | Configuração em JSON; regras de comportamento determinísticas decidem a próxima ação, e as chamadas ao LLM acontecem em tarefas declaradas |
| Linguagens | .NET e Python (Go em um repositório separado) | Qualquer linguagem por meio de REST, MCP e da API compatível com OpenAI; o agente em si não precisa de código |
| Licença | MIT | Apache 2.0, aprovada pela OSI |
| Lógica personalizada em tempo de execução | Seu código e suas funções de ferramentas rodam no seu processo | Sem eval() nem execução de código em tempo de execução; a lógica é declarada ou fica atrás de uma ferramenta MCP ou de uma chamada HTTP |
| Human in the loop | Controle human-in-the-loop no nível do workflow | Pontos de aprovação em três níveis: turnos (PAUSE_CONVERSATION), chamadas de ferramentas (toolApprovals) e fases de grupo, com políticas de timeout |
| Padrões multiagente | Colaboração sequencial, concorrente, de handoff e em grupo, em código | Discussões em grupo com 7 estilos (mesa redonda, revisão por pares, advogado do diabo, Delphi, debate, força-tarefa, negociação), com decisões e divergências registradas |
| Estado e recuperação | Checkpointing e time-travel no runtime de workflows | Memória de conversa persistida pela plataforma; estados explícitos como AWAITING_HUMAN |
| Observabilidade e auditoria | Rastreamento OpenTelemetry e hooks de middleware; para onde os dados vão fica por sua conta | Métricas Prometheus e um ledger de auditoria assinado com HMAC, somente de acréscimo e com verificação de sequência, com endpoint de verificação |
| Segredos e identidade | Os mecanismos da sua plataforma, por exemplo serviços do Azure | Secrets Vault integrado com AES-256-GCM; Keycloak/OIDC opcional com os papéis eddi-admin e eddi-approver |
| Adequação ao ecossistema | Integração profunda com a Microsoft e o Azure, incluindo agentes hospedados no Foundry | Neutro em relação a fornecedores: 19 provedores de LLM, modelos locais com Ollama ou Jlama, 84 ferramentas MCP |
Os detalhes sobre a outra ferramenta foram conferidos na documentação oficial e no repositório dela em outubro de 2026. Esses projetos mudam rápido, então confirme o comportamento atual com o fornecedor antes de decidir.
Como escolher entre os dois
Onde o Microsoft Agent Framework é a melhor escolha
- Sua equipe escreve .NET, e os agentes pertencem a um serviço C# existente, com implantação e testes próprios.
- Você desenvolve no Azure e quer integração de primeira classe com o Foundry e os demais serviços da Microsoft.
- Você tem plugins do Semantic Kernel ou código AutoGen, e o caminho de migração suportado custa menos do que trocar de plataforma.
- O workflow precisa de um fluxo de controle que a configuração não consegue expressar, como topologias de grafo sob medida, ramificação de checkpoints ou depuração com time-travel.
- Você quer um SDK para desenvolvedores e prefere decidir por conta própria como hospedar, proteger e observar.
Onde o EDDI é a melhor escolha
- O comportamento do agente precisa ser configuração que revisores consigam ler e promover entre ambientes, sem recompilar.
- Uma revisão de segurança vai perguntar que código roda no momento da inferência, e você quer que a resposta seja nenhum, na plataforma.
- As aprovações precisam existir no nível de turno, de chamada de ferramenta e de fase de grupo, com um registro assinado de quem decidiu o quê.
- Você precisa de uma interface Manager, de um cofre de segredos, de uma API e de um ledger de auditoria prontos, em vez de montá-los em torno de um SDK.
- Você quer continuar neutro em relação à nuvem: Kubernetes, OpenShift, on-premises ou isolado da internet (air-gapped) com modelos locais.
Migrando do AutoGen, do Semantic Kernel ou do Agent Framework
Espere uma tradução de intenção, não de código. Papéis e ferramentas se mantêm; a lógica de grafo vira regras de comportamento, e tudo o que exige código de verdade passa para trás de uma ferramenta MCP ou de um endpoint OpenAPI.
| Microsoft Agent Framework | EDDI |
|---|---|
| Agente com instruções | Agente EDDI com uma tarefa de LLM e uma mensagem de sistema |
| Plugin ou função do Semantic Kernel | Ferramenta MCP, ou uma API httpCall ou importada via OpenAPI |
| Grafo de workflow ou equipe do AutoGen | Regras de comportamento para o roteamento, ou um estilo de discussão em grupo para o trabalho multiagente |
| Etapa human-in-the-loop | Regra PAUSE_CONVERSATION, globs de toolApprovals ou requiresApproval em uma fase de grupo |
| Armazenamento de checkpoints | Memória de conversa com os escopos step, conversation e longTerm |
| Middleware e filtros | Regras de comportamento e políticas de aprovação de ferramentas |
| Traces do OpenTelemetry | Métricas Prometheus e o ledger de auditoria |
Perguntas frequentes
O Microsoft Agent Framework é o substituto do AutoGen e do Semantic Kernel?
A Microsoft o apresenta como sucessor de ambos e publica guias de migração. Em outubro de 2026, o Semantic Kernel recebe correções enquanto os novos recursos chegam ao Agent Framework, e o AutoGen está em modo de manutenção. Se você está começando um novo projeto na pilha da Microsoft, o Agent Framework é o que deve ser avaliado em comparação com o EDDI.
O EDDI pode substituir o AutoGen em conversas multiagente?
Em muitos casos, sim. As discussões em grupo do EDDI cobrem os estilos mesa redonda, revisão por pares, advogado do diabo, Delphi, debate, força-tarefa e negociação, com fases que podem exigir aprovação humana e uma decisão registrada com as divergências. Se os seus agentes precisam de coordenação livre no nível do código, um SDK é a opção mais adequada.
Preciso abrir mão do Azure para usar o EDDI?
Não. O EDDI oferece suporte ao Azure OpenAI como provedor e roda no Kubernetes, inclusive no AKS. Ele não oferece a integração profunda com o Azure e o Foundry que o Agent Framework tem, então pondere isso se você está comprometido com o ecossistema da Microsoft.
Os dois podem funcionar juntos?
Sim. O EDDI expõe um servidor MCP, uma API REST e uma API compatível com OpenAI, e pode consumir servidores MCP e agentes A2A. Um serviço .NET pode chamar agentes do EDDI como ferramentas, e o EDDI pode chamar o seu serviço por meio de httpCall.
Outras comparações
- EDDI vs. LangChain e LangGraph
- EDDI vs. CrewAI
- EDDI vs. Dify
- EDDI vs. n8n
- EDDI vs. Flowise
- EDDI vs. Rasa
- Todas as alternativas: construtores, bibliotecas e plataformas em nuvem
Pronto para produção?
Obtenha implantação gerenciada, suporte com SLA e ajuda prática da equipe que desenvolve o EDDI.
Fale conosco sobre implantação enterprise