Microsoft Agent Framework 是什么
Microsoft Agent Framework 是采用 MIT 许可证的开源 SDK 和运行时，用于在 .NET 和 Python 中构建和编排智能体及多智能体工作流。它出自 Semantic Kernel 和 AutoGen 背后的团队，于 2026 年 4 月发布 1.0 版本。工作流是图，支持顺序、并发、交接和群组协作模式，并具备检查点、流式传输、人工介入控制、OpenTelemetry 追踪和中间件系统。智能体也可以用 YAML 声明，Microsoft 还提供了在 Foundry 上托管的文档。截至 2026 年 10 月，Semantic Kernel 仅接收缺陷修复，新功能开发在 Agent Framework 中进行，AutoGen 处于维护模式，两者都有迁移指南。
代码定义的工作流与声明式配置
如果你是为了搜索 AutoGen 或 Semantic Kernel 而来，如今实际可比的对象是 Agent Framework，因为 Microsoft 将新项目引导至那里。它是一个 SDK：你的工作流是服务中以你所用语言编写的代码，由你选择如何托管、保护和审计，并对 Azure 提供强力支持。EDDI 做出相反的取舍。智能体是由已部署平台解释执行的 JSON 配置，因此行为可以做差异比较、评审，并且无需重新构建即可修改，而平台提供 API、Manager 界面、密钥保险库和审计账本。
嵌入你服务的 SDK 与自行部署的平台
| 维度 | Microsoft Agent Framework | EDDI |
|---|---|---|
| 形态 | 嵌入你的 .NET 或 Python 服务的 SDK 和运行时 | 基于 JVM（Quarkus）的可部署中间件；能运行 Docker 或 Kubernetes 的地方就能运行 |
| 智能体的定义方式 | 代码定义的智能体和图工作流；智能体也可以用 YAML 声明 | JSON 配置；确定性的行为规则决定下一步动作，LLM 调用发生在已声明的任务中 |
| 语言 | .NET 和 Python（Go 在单独的代码仓库中） | 可通过 REST、MCP 和 OpenAI 兼容 API 使用任何语言；智能体本身无需代码 |
| 许可证 | MIT | Apache 2.0，OSI 认证 |
| 运行时的自定义逻辑 | 你的代码和工具函数在你的进程中运行 | 没有运行时 eval() 或代码执行；逻辑通过声明实现，或放在 MCP 工具或 HTTP 调用之后 |
| 人工介入 | 工作流层面的人工介入控制 | 三个层级的关卡：对话轮次（PAUSE_CONVERSATION）、工具调用（toolApprovals）和群组阶段，带超时策略 |
| 多智能体模式 | 以代码实现的顺序、并发、交接和群组协作 | 支持 7 种风格的群组讨论（圆桌会议、同行评审、魔鬼代言人、德尔菲法、辩论、专项小组、谈判），并记录决策与异议 |
| 状态与恢复 | 工作流运行时中的检查点和时间回溯 | 对话记忆由平台持久化；带有 AWAITING_HUMAN 等明确状态 |
| 可观测性与审计 | OpenTelemetry 追踪和中间件钩子；数据流向由你决定 | Prometheus 指标，外加 HMAC 签名、仅追加、带序号校验并提供验证端点的审计账本 |
| 密钥与身份 | 使用你所在平台的机制，例如 Azure 服务 | 内置 AES-256-GCM Secrets Vault；可选的 Keycloak/OIDC，含 eddi-admin 和 eddi-approver 角色 |
| 生态契合度 | 与 Microsoft 和 Azure 深度集成，包括 Foundry 托管智能体 | 厂商中立：19 个 LLM 提供商，可通过 Ollama 或 Jlama 使用本地模型，84 个 MCP 工具 |
关于对方工具的信息，已于 2026 年 10 月对照其官方文档和代码仓库核实。这些项目更新很快，决策前请向厂商确认当前行为。
如何在两者之间选择
Microsoft Agent Framework 更合适的场景
- 你的团队使用 .NET，智能体应当放在已有的 C# 服务内部，由该服务自行部署和测试。
- 你在 Azure 上构建，希望与 Foundry 及周边 Microsoft 服务实现一流的集成。
- 你已有 Semantic Kernel 插件或 AutoGen 代码，受支持的迁移路径比更换平台成本更低。
- 工作流需要配置无法表达的控制流，例如定制的图拓扑、检查点分支或时间回溯调试。
- 你想要的是开发者 SDK，并希望自己决定如何托管、保护和观测。
EDDI 更合适的场景
- 智能体行为必须是评审人员可以阅读、并能在各环境之间推进的配置，无需重新构建。
- 安全评审会询问推理时运行了什么代码，而你希望平台给出的答案是“没有”。
- 审批必须存在于对话轮次、工具调用和群组阶段层面，并有谁做出了什么决定的签名记录。
- 你需要现成的 Manager 界面、密钥保险库、API 和审计账本，而不是围绕 SDK 自行拼装。
- 你希望保持云中立：Kubernetes、OpenShift、本地部署，或搭配本地模型的离线隔离环境。
从 AutoGen、Semantic Kernel 或 Agent Framework 迁移
预期这是意图的转换，而不是代码的转换。角色和工具可以沿用；图逻辑变为行为规则，任何需要真正代码的部分则移到 MCP 工具或 OpenAPI 端点之后。
| Microsoft Agent Framework | EDDI |
|---|---|
| 带指令的智能体 | 带 LLM 任务和系统消息的 EDDI 智能体 |
| Semantic Kernel 插件或函数 | MCP 工具，或 httpCall，或通过 OpenAPI 导入的 API |
| 工作流图或 AutoGen 团队 | 用于路由的行为规则，或用于多智能体协作的群组讨论风格 |
| 人工介入步骤 | PAUSE_CONVERSATION 规则、toolApprovals glob 模式，或群组阶段上的 requiresApproval |
| 检查点存储 | 具有 step、conversation 和 longTerm 作用域的对话记忆 |
| 中间件和过滤器 | 行为规则和工具审批策略 |
| OpenTelemetry 追踪 | Prometheus 指标和审计账本 |
常见问题
Microsoft Agent Framework 是 AutoGen 和 Semantic Kernel 的替代品吗？
Microsoft 将其定位为两者的继任者，并发布了迁移指南。截至 2026 年 10 月，Semantic Kernel 仅接收缺陷修复，新功能进入 Agent Framework，AutoGen 处于维护模式。如果你要启动新的 Microsoft 技术栈项目，应当拿来与 EDDI 对比评估的是 Agent Framework。
EDDI 可以替代 AutoGen 进行多智能体对话吗？
在许多情况下可以。EDDI 的群组讨论涵盖圆桌会议、同行评审、魔鬼代言人、德尔菲法、辩论、专项小组和谈判等风格，其阶段可要求人工审批，并记录决策及异议。如果你的智能体需要代码层面的自由协调，SDK 更合适。
使用 EDDI 就必须放弃 Azure 吗？
不需要。EDDI 支持将 Azure OpenAI 作为提供商，并可运行在包括 AKS 在内的 Kubernetes 上。它不提供 Agent Framework 那样深度的 Azure 和 Foundry 集成，所以如果你已深度投入 Microsoft 生态，请权衡这一点。
两者可以协同工作吗？
可以。EDDI 提供 MCP 服务器、REST API 和 OpenAI 兼容 API，并且可以使用 MCP 服务器和 A2A 智能体。.NET 服务可以把 EDDI 智能体当作工具调用，EDDI 也可以通过 httpCall 调用你的服务。