AutoGen 到 MAF 迁移认知图摘要

小刘先生liu

508人浏览 · 2026-05-14 16:20:16

小刘先生liu · 2026-05-14 16:20:16 发布

摘要：本文面向有 AutoGen 开发经验的工程师，系统梳理从 AutoGen 到 Microsoft Agent Framework（MAF）的核心概念迁移映射。围绕“可观测性 → 可控性”的认知升级主线，提供概念对照表、代码迁移路径与工程化思维转变指南。

一、为什么要迁移：从“实验利器”到“生产基座”

1.1 AutoGen 的历史使命

Microsoft AutoGen（2023–2025）是开创性多智能体开源框架，由 Microsoft Research 主导开发。它首次将“群聊式协作”引入多智能体系统——智能体是对话的参与者，可以互相委派任务、批评纠正、调用工具、编写并执行代码，目标达成后自行终止。

AutoGen v0.4（2025 年初发布，本质为 2.0）是其技术巅峰，采用三层架构：

架构层级	组成	功能定位
底层核心	`autogen-core`	事件驱动原语（RoutedAgent、Pub/Sub）
高层 API	`autogen-agentchat`	AssistantAgent、GroupChat、initiate_chat
扩展层	`autogen-ext`	OpenAI API、MCP 工作台、gRPC 分布式支持

AutoGen 在 GAIA、SWE-bench 等基准测试中表现优异，多智能体团队成功率较单智能体提升 25%–85%。

1.2 AutoGen 的生产困境

尽管实验效果惊艳，AutoGen 在落地时暴露出明显短板：

高延迟与成本风险：多 Agent 对话极易导致 28 轮辩论花费 $12；
终止条件难控：GitHub 高频 Issue 显示，超过 60% 的用户卡在 GroupChatManager 的终止条件配置上；
缺乏内置状态持久化：依赖上下文传递，无检查点与恢复机制；
可观测性薄弱：难以追踪和审计 Agent 执行链路。

1.3 MAF 的诞生：大一统

2025 年末，Microsoft 正式将 AutoGen 与 Semantic Kernel 合并，统一为 Microsoft Agent Framework（MAF）。官方如此阐述其定位：

“With Semantic Kernel, we gave developers a stable SDK with connectors into enterprise systems, content moderation, and telemetry. With AutoGen, pioneered in Microsoft Research, we opened the door to experimental multi-agent orchestration patterns.”

MAF 保留了 AutoGen 的核心精神——对话式智能体、群聊编排、工具调用，同时补齐了工程化短板：

内置检查点与恢复机制
基于 OpenTelemetry 的可观测性（追踪与指标）
MCP/A2A/OpenAPI 原生支持
与 Azure AI Foundry / Dynamics 365 / M365 Copilot 深度集成

二、核心概念映射表

2.1 单 Agent 概念映射

AutoGen 概念	MAF 等价概念	说明
`AssistantAgent`	`ChatClientAgent`	MAF 的核心 Agent 类型，通过 `IChatClient` 抽象与模型交互
`UserProxyAgent`	`AIAgent`（Human-in-the-Loop）	MAF 通过中间件和工作流的人机循环节点实现
`ConversableAgent`	`AIAgent`（基类）	MAF 统一 Agent 基类，支持 `IChatClient` 注入
`llm_config`	`IChatClient` + Provider 配置	通过 `appsettings.json` 驱动，一行代码切换模型厂商
`system_message`	`instructions` 参数	语义等价，API 层面参数重命名
`code_execution_config`	工作流 + Docker Executor	MAF 通过工作流步骤实现隔离执行
`human_input_mode`	`HumanInTheLoopMiddleware`	MAF 以中间件形式注入，更灵活可控

对照说明：在 AutoGen 中，AssistantAgent 是通过 llm_config 配置模型、system_message 定义角色的核心类型。MAF 使用 ChatClientAgent 替代此概念，并通过 IChatClient 抽象解耦模型提供方——这意味着同一个 Agent 代码可以从 OpenAI 切换到 Azure OpenAI 或 Ollama，只需更改配置。

UserProxyAgent（负责代码执行与用户交互代理）在 MAF 中没有直接一对一映射。MAF 通过中间件和工作流中的“人机循环”节点来实现类似功能，这种设计将“执行”与“审批”关注点分离，更符合企业级安全模型。

2.2 多 Agent 编排概念映射

AutoGen 概念	MAF 等价概念	说明
`GroupChat`	`Team` + `GroupChatStrategy`	MAF 保留群聊模式，并增强策略控制
`GroupChatManager`	`GroupChatStrategy`（内置策略）	不再需要手写选择逻辑
`RoundRobinGroupChat`	`SequentialWorkflow` / `RoundRobinStrategy`	MAF 同时支持群聊与图工作流模式
`initiate_chat()`	`agent.RunAsync()`	统一入口 API
自定义 `speaker_selection`	`GroupChatStrategy` + 策略配置	MAF 提供声明式而非编程式选择

对照说明：在 AutoGen 中，GroupChat 管理多个智能体，支持 auto、round_robin 或自定义函数选择发言者。MAF 既保留了对话式群聊模式（通过 Team + GroupChatStrategy），又引入了基于图/DAG 的确定性工作流，让开发者在同一框架内既可用“涌现式协作”也可用“确定性编排”。

2.3 工具与能力概念映射

AutoGen 概念	MAF 等价概念	说明
`function_map`	`AITool` / `AIFunction`	MAF 使用 `Microsoft.Extensions.AI` 统一抽象
`Tool` 定义	`MCPTool` / `AITool`	原生支持 MCP 协议，工具可跨框架复用
`register_function`	DI 注册 `AIFunction`	融入 .NET 依赖注入体系
`code_executor`	`Workflow Executor`	工作流步骤中的强类型 Executor
`@agent.register_for_execution()`	`AgentSkill`（声明式 Skill）	MAF 1.1+ 支持强类型类定义 Skill

对照说明：AutoGen 中的工具注册通过 function_map 字典映射实现，而 MAF 将工具抽象统一到 Microsoft.Extensions.AI 的 AIFunction 体系下，支持通过 DI 注入。MAF 1.1.0 更推出了强类型 AgentClassSkill<T>，可将资源、脚本、业务规则内聚到一个 C# 类中，便于代码治理和单元测试。

三、迁移路径详解

3.1 阶段一：模型客户端切换

AutoGen 方式（Python）：

python

from autogen import AssistantAgent, config_list_from_json

config_list = config_list_from_json("OAI_CONFIG_LIST")
assistant = AssistantAgent(
    name="helpful_engineer",
    llm_config={"config_list": config_list},
    system_message="You are a senior Python engineer."
)

MAF 方式（C#）：

csharp

// 通过 appsettings.json 管理模型配置，IChatClient 抽象解耦提供方
var agent = new OpenAIClient(...)
    .GetResponsesClient("gpt-4.1")
    .AsAIAgent(
        name: "helpful_engineer",
        instructions: "You are a senior Python engineer."
    );

Console.WriteLine(await agent.RunAsync("Write a function..."));

MAF 支持 6 个模型厂商，切换只需要改一个字符串。MAF 通过 IChatClient 抽象将 Agent 代码与底层模型提供方完全解耦，同时支持 Azure OpenAI、OpenAI、Ollama 本地模型等。

3.2 阶段二：工具/函数迁移

AutoGen 方式：

python

def get_weather(city: str) -> str:
    return f"The weather in {city} is sunny, 72°F"

assistant = AssistantAgent(
    name="weather_agent",
    llm_config={"config_list": config_list},
    function_map={"get_weather": get_weather}
)

MAF 方式（C#）：

csharp

// 使用 Microsoft.Extensions.AI 的 AIFunction 体系
[Description("Gets the current weather for a location")]
static string GetWeather([Description("The city name")] string city)
{
    return $"The weather in {city} is sunny, 72°F";
}

var agent = new ChatClientAgent(...)
{
    Tools = [AIFunctionFactory.Create(GetWeather)]
};

工具定义从函数字典映射迁移到声明式 [Description] 标注 + AIFunctionFactory，更符合 .NET 开发习惯。此外 MAF 还原生支持 MCP 协议，Agent 可直接发现并调用 MCP 服务器暴露的工具，无需手动逐一集成。

3.3 阶段三：多 Agent 编排迁移

AutoGen 群聊方式（Python）：

python

from autogen import GroupChat, GroupChatManager

researcher = AssistantAgent("researcher", ...)
critic = AssistantAgent("critic", ...)
writer = AssistantAgent("writer", ...)

group_chat = GroupChat(
    agents=[researcher, critic, writer],
    messages=[],
    max_round=12,
    speaker_selection_method="auto"
)
manager = GroupChatManager(groupchat=group_chat, ...)
researcher.initiate_chat(manager, message="Write a report...")

MAF 方式（C#）：

方式一：延续群聊风格（对话式编排）：

csharp

var team = new Team("report_team")
{
    Agents = [researcher, critic, writer],
    Strategy = new GroupChatStrategy { MaxRounds = 12 },
    TerminationCondition = new BudgetStopCondition(tokenBudget: 5000)
};
await team.RunAsync("Write a report...");

方式二：确定性工作流（图编排）：

csharp

var workflow = new WorkflowBuilder()
    .AddExecutor(new ResearchExecutor())
    .AddExecutor(new ReviewExecutor())
    .AddExecutor(new WriteExecutor())
    .Edge<ResearchExecutor, ReviewExecutor>()
    .Edge<ReviewExecutor, WriteExecutor>()
    .Build();

路径选择建议：上述两种风格针对截然不同的场景——复杂、开放式的多智能体场景保留“群聊”风格，在确定性的、可审计的业务流程中优先使用工作流。MAF 让开发者在同一框架内按需选用，而非二选一。

四、认知升级：从“可观测”到“可控”

4.1 认知框架对比

维度	AutoGen 思维	MAF 思维	认知转变
编排哲学	“群聊涌现”——让智能体自由对话	“双模式并行”——群聊 + 确定性图	从完全信任涌现到精准控制执行路径
状态管理	依赖对话上下文隐式传递	内置会话状态 + 检查点持久化	从“相信模型记忆”到“工程化状态治理”
可观测性	依赖日志，难以追踪	OpenTelemetry 原生集成	从“事后排查”到“全链路追踪”
故障恢复	出错只能整段重来	检查点 + 断点续跑	从“重试一切”到“精确定位恢复”
工具集成	函数字典，框架内耦合	MCP 协议，跨框架互通	从“框架私有”到“协议开放”
开发体验	Python 为主，研究导向	.NET + Python 统一，工程导向	从“快速实验”到“生产交付”

4.2 核心认知跃迁

跃迁一：从“涌现智能”到“涌现 + 确定性”双引擎

AutoGen 时代，开发者信任“群聊涌现”——让智能体自由对话，期待智慧自然产生。MAF 时代，这一心智模型升级为：用群聊处理创意探索，用图工作流保障核心流程。MAF 同时支持确定性业务流程和动态多 Agent 编排模式——关键业务路径走确定性图，边缘探索走群聊讨论。

跃迁二：从“Prompt 工程”到“Harness 工程”

MAF 1.4 引入的 Harness Engineering 核心思想是：在模型外面补一层“可执行的脚手架”，把 AI 的能力约束成稳定产出。Harness 不关心“模型会不会回答”，而是关心“智能体能不能稳定把事情做完”。

其四大支柱为：有输入、有步骤、有验收、有兜底。当智能体开始访问文件系统、管理中间状态、处理中断、接受审批时，真正决定系统能不能落地的，往往已经不是模型本身，而是模型外面那层执行骨架。

跃迁三：从“Agent 为中心”到“团队 + 工作流为中心”

AutoGen 的设计以单个 Agent 为核心——定义 Agent、赋予能力、让它参与群聊。MAF 将设计重心从单个 Agent 上移到团队编排和工作流设计层面——Agent 仍然重要，但编排逻辑、状态管理、错误边界、可观测性被提升到一等公民。MAF 给出的抽象是“你定义步骤，框架处理执行、数据流和错误传播”。

跃迁四：从“框架私有”到“协议开放”

AutoGen 的工具生态偏向框架内耦合。MAF 将 MCP 和 A2A 作为一等公民支持——工具可以跨框架共享，Agent 可以与外部系统互操作。协议开放性在 2026 年被视为与框架能力同等重要。

五、迁移决策指南

5.1 什么时候该迁移

信号	说明
你的系统需要上生产	MAF 提供检查点、恢复、遥测，AutoGen 缺乏这些
你在 .NET 技术栈	MAF 是 .NET AI 的统一基座，AutoGen .NET 已停止演进
你需要审计和合规	MAF 的图工作流提供确定性执行和全链路追踪
你需要长期支持	MAF 提供稳定 API 和长期支持承诺
你希望减少框架碎片化	一个框架同时满足 Agent + 工作流 + 工具集成

5.2 什么时候暂缓迁移

信号	说明
纯实验和原型验证	AutoGen 的 Python 生态 + AutoGen Studio 仍适合快速迭代
已有大量 AutoGen 生产代码	需要评估迁移成本，可渐进式进行
团队尚未熟悉 .NET	MAF 虽然也支持 Python，但 C# 生态更成熟
纯粹的单 Agent 简单场景	MAF 的工程化优势在简单场景中体现不明显

5.3 渐进式迁移路径建议

先跑通单 Agent：将 AutoGen 中一个 AssistantAgent 迁移为 MAF ChatClientAgent，熟悉新的模型客户端和工具注册方式；
再迁移工具：将 function_map 中的函数逐一迁移为 AIFunction，验证工具调用流程；
引入工作流：对确定性业务流程使用 WorkflowBuilder + Executor，体验图编排模式；
最后迁移群聊：将 GroupChat 迁移为 MAF 的 Team + GroupChatStrategy；
全量切换：在所有模块验证通过后，完成从 AutoGen 到 MAF 的全量切换。

六、总结

从 AutoGen 到 MAF 的迁移，表面上是框架 API 的替换，实质上是从“研究驱动的涌现式协作”到“工程驱动的可控式编排”的认知升级。

该延续的延续了：Agent 角色定义、群聊编排、工具调用——AutoGen 的核心设计在 MAF 中完整保留。
该补齐的补齐了：检查点恢复、OpenTelemetry 可观测性、确定性工作流、MCP/A2A 协议支持——这些都是生产环境不可或缺的能力。
该统一的统一了：模型提供方抽象（IChatClient）、工具注册体系（AIFunction）、Agent 编程模型（AIAgent）——消除了框架碎片化。

MAF 是下一代 Semantic Kernel 和 AutoGen。它延续了 AutoGen 的核心精神——对话式智能体、群聊编排、工具调用——但在此基础上补齐了工程化短板。迁移本身不是目的，目的是让你的智能体系统从“能跑”到“能运维”，从“演示酷炫”到“生产可靠”。