发布事实：两条产品线的合并与一个明确信号
先厘清时间线。Microsoft Agent Framework 于 2025 年 10 月进入公开预览，2026 年 4 月初达到 1.0 正式版：微软官方开发者博客在 Foundry 四月更新中确认 1.0 GA 将 Semantic Kernel 与 AutoGen 统一为单一开源 SDK；多方第三方报道给出的具体日期为 4 月 2 日或 4 月 3 日，存在一天口径差异（本文以官方博客「4 月 2 日 GA」表述为准，业界多数报道写 4 月 3 日，读者知悉即可）。合并的信号同样明确：AutoGen 与 Semantic Kernel 转入维护模式——只修缺陷、不加功能，新项目被官方引导到 MAF。社区分支 AG2 延续 AutoGen 的独立演进，但微软的推荐路径已无歧义。
为什么合并是必然而非权宜？两条产品线各有明显短板：AutoGen（微软研究院出身）在多智能体协作模式上积累深厚——群聊、顺序工作流、辩论循环、层级委派，但默认配置偏研究取向，认证、插件管理、监控等生产化工作要团队自建；Semantic Kernel（产品团队出身）有成熟的企业插件架构与 Azure OpenAI 集成，但多智能体编排是后补的，复杂模式需要大量样板代码。实践中团队总是「选一个、撞另一堵墙」。MAF 的解法是把 AutoGen 的编排思想架在 Semantic Kernel 的生产地基上，.NET 与 Python 双语言提供一致的概念与 API。
MAF 1.0 的迁移成本集中在包名变更：.NET 侧统一到 Microsoft.Agents.AI，Python 侧使用 agent-framework 系列包。从 AutoGen 或 Semantic Kernel 迁移的团队需要更新导入并对照官方迁移指南——1.0 的包已去掉预览标记，属于受长期支持的稳定 API。
另一个常被忽略的发布事实：MAF 1.0 并不绑定 Azure。官方文档明确它可以对接任何 OpenAI 兼容端点，2026 年 5 月 BUILD 大会上公布的 Agent Harness 能力清单里，多模型连接器覆盖 Azure OpenAI、OpenAI、Anthropic、Amazon Bedrock、Google Gemini 与 Ollama 等六家以上供应商，一行配置即可切换。这决定了 MAF 的竞争姿态：它卖的是运行时与治理层，不是模型分销。
五层核心抽象：对齐生产环境的心智模型
多家第三方分析把 MAF 1.0 的架构归纳为五个核心抽象，恰好映射了生产 Agent 系统的五个真实问题：
| 抽象层 | 解决的生产问题 | 1.0 状态 |
|---|---|---|
| Agent Harness | 模型推理与真实执行（shell、文件系统、审批）之间的衔接层，长会话上下文管理 | BUILD 2026 公布，随 1.0 基座演进 |
| Skills | 能力的版本化、可发现注册，避免能力散落在提示词里 | 公共预览 |
| Memory | 会话内记忆、跨会话用户记忆、跨运行习得行为三档分层 | 会话与用户档 GA，程序性档预览 |
| Middleware Pipeline | 过滤器、遥测钩子、护栏与自定义拦截器统一包裹每次 Agent 动作 | GA |
| Orchestration Patterns | 顺序、并发、交接、群聊、Magentic-One 五种多智能体协作模式 | GA |
这张表值得细看的地方在于「状态」一列：Memory 与 Skills 分档渐进开放，说明微软把「稳定」和「探索」切得很清楚——编排、中间件这些成熟模式直接 GA，程序性记忆这类仍在验证的机制放预览。对选型团队而言，这比「全家桶全 GA」的宣传更可信，也更利于风险评估。
Agent Harness：把「生产模式」变成内置件
BUILD 2026 公布的 Agent Harness 是 1.0 之后最重要的增量。它的定位是「模型推理与真实执行之间的层」：shell 与文件系统访问、人在环审批流、跨长会话的上下文管理，这些在生产环境反复被验证过的模式，被做成了一等公民。
看几个有代表性的内置件：
- 自动上下文压缩：监控 token 用量，在工具调用链过长的中途压缩聊天历史，防止上下文窗口溢出。这与 Claude Code、Codex CLI 等终端 Agent 的 auto-compaction 是同一类问题，MAF 把它下沉到了框架层。
- Provider 家族：
FileMemoryProvider（会话级文件记忆，跨轮次沉淀笔记）、TodoProvider（多步任务清单）、AgentModeProvider（计划与执行两种模式分离）、AgentSkillsProvider（从文件系统发现并执行技能）、BackgroundAgentsProvider（子任务委派给并行子 Agent）。熟悉 Claude Code 与 Hermes Agent 的读者会发现，这套清单几乎是开源终端 Agent 社区验证过的实践汇编。 - 治理件：
ToolApprovalAgent支持敏感工具调用的「不再询问」式审批规则；OpenTelemetryAgent提供符合语义约定的自动追踪。
设计取向由此清晰：Anthropic、OpenAI 的 Harness 把生产模式做进自家 Agent 产品里，MAF 则把它们做成框架的公共层——你用任意模型、任意托管方式，都能拿到同一套生产模式。这个「Harness 平民化」的定位，是 MAF 与其他框架差异最大的地方。
五种编排模式与 Magentic-One：固定流水线到动态调度
多智能体编排是 AutoGen 的老本行，MAF 1.0 把五种模式做成稳定 API，每种都支持流式、检查点、人在环审批与暂停恢复：
| 模式 | 工作方式 | 适用场景 |
|---|---|---|
| Sequential | Agent A 完成，输出传给 B，再传给 C | 有明确阶段门的流水线（提取→校验→转换） |
| Concurrent | 多 Agent 并行执行，结果汇聚合并 | 独立调研任务、多源数据收集 |
| Handoff | 依据意图检测结果把控制权移交给专家 Agent | 客服分流、分层支持升级 |
| Group Chat | 多 Agent 在共享会话中讨论，管理者决定下一位发言者 | 设计评审、协作分析、头脑风暴 |
| Magentic-One | 专职管理者 Agent 维护各专家能力与任务进展台账，依据上下文动态指派下一步 | 无法预先确定执行序列的开放式复杂任务 |
其中 Magentic-One 值得单独说明。它源自微软研究院 AutoGen 项目，在 MAF 1.0 达到稳定版。与前四种「流程固定」的模式不同，Magentic-One 的管理者维护一份台账（ledger）：每个专家能做什么、已经试过什么、失败在哪。任务推进中动态重新指派工作。这让它在复杂文档处理、跨系统调查这类「中途需要换策略」的任务上有明显优势——代价是更高的 token 消耗与更难预测的执行路径。第三方分析普遍把「选哪种编排模式」列为 MAF 架构决策中影响延迟、成本与失败形态的头号选择，这个判断我们认同。
程序性记忆：让 Agent 记住「怎么干活」
MAF 1.0 在架构上最具启发性的增量是程序性记忆（procedural memory，公共预览）。它与两类常见记忆的区别在于记的内容：
- 用户记忆记事实：「这个用户偏好公制单位」；
- 会话记忆记上下文：本次对话的状态；
- 程序性记忆记方法：Agent 怎么完成一类任务——把执行过程中形成的有效流程沉淀下来，应用到未来运行。
官方给出的量化口径是：启用程序性记忆后，Tau-bench 评估的绝对成功率提升 7–14 个百分点，成本接近基线。一个直观场景：PR 审查 Agent 被教练一次「先查测试覆盖率、再标记新依赖、最后看破坏性 API 变更」，数周后面对完全不同的 PR，它自主执行同样的序列。这更接近人类专家形成工作模式的方式，也是对当前主流无状态 Agent 架构的一次实质性超越。
两点保留意见。其一，7–14pp 来自微软自报的 Tau-bench 评估，评估配置与任务集构成未完全公开，第三方独立复现数据暂缺；其二，该能力处于公共预览期，生产采用需要预留行为变化的容错。但对记忆架构这个方向而言，「把流程本身作为可迁移资产」的问题定义，比具体数字更有长期价值——这与本站此前对 Agent 长期记忆架构的分析（热冷路径、时序图谱）形成互补：那批方案记忆的是「知识与事实」，程序性记忆记忆的是「过程与技能」。
Agent 记忆正在分化为三个正交维度：记事实（语义记忆）、记上下文（情景记忆）、记方法（程序性记忆）。前两者已被 Mem0、Zep 等方案充分覆盖，程序性记忆是 2026 年才进入主流框架的新维度——它把「教会 Agent」从一次性提示词工程，变成了可累积的组织资产。
生态位对照：与 Agents SDK、LangGraph、ADK 的分工
把 MAF 放回 2026 年的框架竞争格局，四个主流选项的分工已经相当清楚：
| 框架 | 核心取向 | 相对优势 | 相对短板 |
|---|---|---|---|
| Microsoft Agent Framework 1.0 | 企业运行时与治理层 | 编排模式齐备、Azure 生态、治理件内置、双语言一致 | 非 Azure 环境的托管能力有限，社区规模尚在积累 |
| OpenAI Agents SDK | 轻量编排原语 | 概念精简、与 OpenAI 模型链路深度整合、控制/计算平面分离 | 企业治理层需自建或依赖其他组件 |
| LangGraph | 图工作流运行时 | 状态机表达力强、Checkpointer 与 interrupt 机制成熟、供应商中立 | 学习曲线陡，企业集成件需拼装 |
| Google ADK | 模型协同与事件驱动 | 图工作流运行时、HITL 与自动重试、GCP 集成 | 与 Google 生态绑定较深 |
一个共同的收敛方向值得记录：本站此前对 OpenAI Agents SDK 与 Google ADK 2.0 的解构中提到的「Agent 即运行时」趋势——持久状态、沙箱隔离、故障恢复、人在环审批——在 MAF 1.0 里同样齐备。五大平台的差异化正在从「有没有这些能力」转移到「这些能力以什么形态交付」：OpenAI 与 Anthropic 做进自家产品，LangGraph 做成中立库，微软与 AWS 做成企业云服务。选型的本质，从「选框架」变成了「选运行时交付形态」。
局限与风险
- 迁移成本真实存在：1.0 的包名与导入路径相对 AutoGen 0.2/0.4 与 Semantic Kernel 有实质变化，存量项目需要完整回归；AutoGen 特有的对话式多智能体范式在 MAF 中的等价物并非一比一对应。
- 程序性记忆数据口径单一：7–14pp 的 Tau-bench 提升为微软自报，缺少独立复现；预览期能力不建议直接承担核心业务流程。
- 编排模式选择即风险：五种模式在延迟、成本、失败形态上差异巨大，Magentic-One 类动态调度尤其难以预估 token 账单；团队需要为「选错模式」准备回退路径。
- Azure 引力的双刃剑：MAF 可脱离 Azure 运行，但 Foundry Agent Service 的托管、追踪与版本化优势都在 Azure 侧；深用 MAF 的团队实际面对的是「多云可用、单云最优」的现实。
- 社区生态仍在早期：相较 LangGraph 庞大的示例库与第三方教程积累，MAF 的社区内容厚度尚有差距，踩坑时的检索成本更高。