AutoGen进化史:从爆火到并入Microsoft Agent Framework

AutoGen以其多智能体协作模式改变LLM应用认知框架,后融入Microsoft Agent Framework,持续影响智能体生态。

原文标题:从爆火到合并:AutoGen的来龙去脉(附代码)

原文作者:数据派THU

冷月清谈:

本文回顾了多智能体系统AutoGen的兴起与演变。AutoGen因其独特的对话式智能体协作模式迅速走红,并在多个任务中展现出超越传统单智能体的性能。文章深入探讨了AutoGen的核心设计、优势与痛点,以及它与Microsoft Agent Framework(MAF)的合并。MAF继承了AutoGen的核心理念,并在工程化方面进行了增强,提供了更全面的智能体解决方案。AutoGen在原型设计和研究领域依然活跃,而生产环境则倾向于选择MAF。AutoGen的贡献在于改变了LLM应用的认知框架,将多智能体协作提升到核心地位,其架构思路也深刻影响了整个行业生态。

怜星夜思:

1、AutoGen最吸引你的特性是什么?你认为在实际应用中,哪个特性最有价值?
2、AutoGen与MAF合并后,你认为对开发者来说,最大的改变是什么?这种改变是积极的吗?
3、除了AutoGen和MAF,还有哪些多智能体协作框架值得关注?它们各自的优势是什么?

原文内容

图片
来源:DeepHub IMBA
本文约3500字,建议阅读7分钟
本文介绍了AutoGen的发展、核心设计及与MAF的合并现状。


Microsoft AutoGen 曾是构建 LLM 多智能体系统的标杆性开源框架。2023 年末由 Microsoft Research 发布后迅速成为研究人员和开发者的默认选择:智能体之间可以互相对话、调用工具、编写并执行代码、在流程中引入人类审批,以对话式的协调方式取代了单条长 Prompt 链条。



到 2026 年初,AutoGen v0.4(2025 年初重新设计的版本)是其技术上的巅峰之作。但是 2025 年末 Microsoft 正式把 AutoGen 与 Semantic Kernel 合并,统一为 Microsoft Agent Framework(MAF)。不过,很多人在谈到源自 AutoGen 的多智能体编排风格时依然习惯说"AutoGen"。本文梳理 AutoGen 的来龙去脉:它是什么、为什么重要、哪些核心设计在 2026 年仍然存续、v0.4/v0.7 时代的架构与典型用法、代码示例、利弊,以及当前的整体现状。


AutoGen 为什么在 2023–2024 年迅速走红


AutoGen 出现之前,LLM 的主流用法只有两种:单线程链式调用(LangChain 风格)和简单的工具调用智能体(ReAct 循环)。


AutoGen 带来了一套完全不同的心智模型——智能体是对话的参与者,整个系统就是一个群聊,有时有结构,有时自由发挥。智能体之间可以委派任务、互相批评与纠正、调用工具、编写并执行代码、向人类发起询问,在目标达成后自行终止。没有任何一个中央控制器需要提前知晓完整计划。


这套流程和人类解决复杂问题的方式高度吻合:分工、讨论、审查输出。早期几个病毒式传播的 demo(编码者 + 评审者 + 执行者联合解数学题、网络研究小组、股票分析团队)在许多任务上展现出比单智能体高 2–10 倍的表现。


AutoGen v0.4——大改版(2025)


v0.4(2025 年初发布)本质上是 AutoGen 2.0。旧的阻塞式同步 GroupChat 被三层新架构取代:autogen-core 负责底层事件驱动原语(RoutedAgent、订阅、发布/订阅消息传递);autogen-agentchat 是大多数人实际使用的高层 API(AssistantAgent、UserProxyAgent、GroupChat、initiate_chat);autogen-ext 则是可插拔的扩展层(OpenAI Assistant API、MCP 工作台、gRPC 分布式智能体等)。


核心改进包括完全异步化带来的更好可扩展性与可观测性、模块化的自定义组件(内存、模型、编排)、改进的错误恢复与检查点机制,以及跨语言支持的尝试——当然 Python 始终是主力。


2025 年末 / 2026 年初的典型安装方式:


 pip install -U"autogen-agentchat""autogen-ext[openai]"


 经典双智能体模式(2026 年仍在使用和教学中)


from autogen import AssistantAgent, UserProxyAgent, config_list_from_json
# Usually load from OAI_CONFIG_LIST or env
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. Write clean, efficient code."
)
user_proxy = UserProxyAgent(
name="user",
human_input_mode="NEVER", # NEVER / ALWAYS / TERMINATE
max_consecutive_auto_reply=10,
code_execution_config={"work_dir": "coding", "use_docker": False},
)
user_proxy.initiate_chat(
assistant,
message="Write a Python class that downloads daily OHLCV data from Yahoo Finance for any ticker and caches it in parquet."
)


短短几行代码就已经具备了完整的闭环:一个能做规划的 LLM 智能体、代码编写与本地执行、自动重试/错误修复循环、终止条件判定。


群聊——AutoGen 的标志性模式


from autogen import GroupChat, GroupChatManager
researcher = AssistantAgent(name="Researcher", system_message="Find latest information.", llm_config=llm_config)
critic = AssistantAgent(name="Critic", system_message="Be skeptical and point out flaws.", llm_config=llm_config)
writer = AssistantAgent(name="Writer", system_message="Write in engaging blog-post style.", llm_config=llm_config)
user_proxy = UserProxyAgent(name="User", code_execution_config=False, human_input_mode="TERMINATE")
groupchat = GroupChat(
agents=[user_proxy, researcher, critic, writer],
messages=[],
max_round=12
)
manager = GroupChatManager(
groupchat=groupchat,
llm_config=llm_config,
# speaker_selection_method="auto" / "round_robin" / custom func
)
user_proxy.initiate_chat(
manager,
message="Write a 800-word article about newest developments in small modular nuclear reactors in 2026."
)


2025–2026 年的实际项目中,5–12 个智能体的配置很常见:规划者 → 研究者 → 编码者 → 测试者 → 评审者 → 文档编写者 → 用户审批者,或干脆由智能体自行决定何时拆分子团队。


AutoGen 的突出优势


涌现行为是 AutoGen 最令人意外的特质:智能体经常以出乎预料的方式完成分工。人机协作的颗粒度做到了任意节点的审批与编辑,而非仅在流程末尾给一个是/否。代码执行能力让智能体能自己修复 bug形成"编写-运行-修复"的闭环。框架本身对实验非常宽容,规则容易打破,适合快速试错。社区围绕它衍生出了 MCP 支持、Perplexity 研究智能体、gRPC 扩展等一系列生态。


痛点(2024–2025)


成本是最直接的问题:一次 8 个智能体参与的 GPT-4o 对话,处理复杂任务时费用可达 5–30 美元。非确定性带来的复现与测试困难、长对话导致的 Token 爆炸和上下文窗口耗尽、调试时难以追溯"谁在什么时候说了什么",以及 v0.4 后期补丁出现之前几乎不存在的检查点/恢复机制,这些都是真实落地时绕不开的问题。


2025–2026 年的过渡——Microsoft Agent Framework(MAF)


2025 年 10 月,Microsoft 宣布 AutoGen 不再作为独立库接收重大功能更新。取而代之的是:AutoGen 的概念并入 Microsoft Agent Framework(Python 与 .NET 双语言支持),Semantic Kernel 负责企业级规划基础,AutoGen 部分则承载多智能体编排和对话模式。


MAF 延续了 AutoGen 的核心精神——对话式智能体、群聊编排、工具调用——但在此基础上补齐了工程化短板:内置检查点与恢复、基于 OpenTelemetry 的可观测性(追踪与指标)、对 MCP(Model Context Protocol)/A2A/OpenAPI 的原生支持、与 Azure AI Foundry / Dynamics 365 / M365 Copilot 的深度集成,以及将 Semantic Kernel 规划器与 AutoGen 风格团队混用的统一 SDK。


迁移指南很快就出现在 Microsoft Learn 和 GitHub 上。不过在 2026 年初仍有大量开源项目在使用旧的 autogen-agentchat 包——对于原型开发来说,它足够熟悉,也确实还能用。


 当前状态(2026 年 3 月)


在原型开发、研究和教学场景中,经典 AutoGen v0.4 / v0.7 的代码依然随处可见。生产和企业环境则几乎全面转向 Microsoft Agent Framework,或正在迁移途中。社区围绕 MAF + AutoGen 风格模式保持着很高的活跃度。CrewAI、LangGraph、OpenAI Swarm、Magentic-One 等后来者,都或多或少借鉴了 AutoGen 率先提出的多智能体协作理念。


AutoGen 留下了什么


AutoGen 的贡献不止于一个库。它从根本上改变了开发者对 LLM 应用的认知框架——从"一个 Prompt 统治一切"转向"组建一支 LLM 专家团队,让它们彼此对话"。多智能体协作作为一等原语,到 2026 年已经渗透到整个行业。即便不再写一行 AutoGen 代码,日常使用的系统里大概率已经携带着 AutoGen 的基因。


框架本身作为独立产品已经"退役",但其架构思路深度嵌入了 Microsoft Agent Framework 和更广泛的智能体生态。2026 年 3 月起步的新项目应直接从 Microsoft Agent Framework 文档开始;维护旧代码或偏好原始简洁性的场景下,v0.4 agentchat API 大概率还能继续运行多年。


Microsoft Agent Framework(MAF)


Microsoft Agent Framework(MAF)是 Microsoft 当前一代的开源智能体框架,覆盖构建、编排、部署与管理的全流程,尤其面向多智能体系统。2025 年 10 月进入公开预览,它是两个前代项目的官方继任者:AutoGen 带来了对话式多智能体编排、涌现团队行为和面向研究的灵活性;Semantic Kernel 则贡献了企业级基础——类型安全、中间件、可观测性、插件/连接器体系以及生产稳定性。


到 2026 年初,MAF 已被定位为 Python 与 .NET 双语言智能体开发的统一长期路径,与 Azure AI Foundry 深度绑定,但同时保持完全开源和模型无关。


MAF 要解决的,正是 2024–2025 年开发者不断碰到的那道两难题:想快速做原型、让多个智能体自由协作,选 AutoGen;想要生产级的可靠性、追踪、持久化、类型安全和企业连接器,选 Semantic Kernel。MAF 在单个 SDK 和运行时中把两边的能力合到了一起——来自 AutoGen 的简洁智能体/团队抽象,来自 Semantic Kernel 的会话状态管理、中间件管道、OpenTelemetry、过滤器和检查点,再加上全新的一层:基于图的显式工作流,用于确定性的多智能体编排。


Python最小单智能体


from agent_framework import AIAgent
from azure.ai.openai import AzureOpenAIClient # or openai.OpenAI etc.
import os
client = AzureOpenAIClient(
endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
credential=…, # DefaultAzureCredential() etc.
)
agent = client.get_chat_client("gpt-4o-mini").as_ai_agent(
instructions="You are a concise technical writer.",
name="TechWriter"
)
response = await agent.run("Explain Microsoft Agent Framework in one paragraph.")
print(response.content)


C


using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT");
var client = new AzureOpenAIClient(new Uri(endpoint), new AzureCliCredential());
var chatClient = client.GetChatClient("gpt-4o");
var agent = chatClient.AsAIAgent(
instructions: "You are a friendly assistant. Keep answers brief.",
name: "HelloAgent"
);
var response = await agent.InvokeAsync("Hello! Tell me about yourself.");
Console.WriteLine(response.Content);


多智能体群聊(风格上仍然很 AutoGen):2026 年初的多数示例在模式上与 AutoGen 0.4 群聊高度相似,区别在于底层多了持久性支持:


from agent_framework import GroupChat, GroupChatManager, AssistantAgent
# … define researcher, critic, writer agents …
group = GroupChat(
agents=[user_proxy, researcher, critic, writer],
max_rounds=15,
# now supports persistent session id, checkpointing, etc.
)
manager = GroupChatManager(group=group)
await user_proxy.initiate_chat(
manager,
message="Research & write 600-word post on SMR nuclear progress in 2026"
)


对话式群聊之外,MAF 新增了基于图/DAG 的工作流编排。节点可以是智能体、函数、条件判断或循环,执行路径是确定性的——非常适合业务流程与合规场景。单个节点内部仍然可以使用对话模式,类型安全的输入/输出在 .NET 中尤其顺手。Azure AI Foundry 在 2026 年初还提供了可视化工作流设计器的预览版。


GroupChat 和 Workflow 面向的场景有明确区分:前者适合开放式研究和调试,后者用于订单处理、贷款审批、事件响应一类必须按严格顺序和分支逻辑运行的流程。

 

继承自 AutoGen 的能力(在 MAF 中延续)


整合之前AutoGen 在 2024–2025 年多项学术/研究 Benchmark 上处于领先或并列位置。GAIA 基准测试(开放式推理)中,AutoGen 多智能体团队在 2024 年至 2025 年初频繁占据榜首,困难子集上的成功率通常在 70–85% 区间,单智能体同期为 40–60%。SWE-bench Verified(软件工程)上,多智能体 AutoGen 变体在代码修复任务中比单智能体高出 25–40%。Microsoft 的行业案例(如 Novo Nordisk 的数据科学流水线)报告了约 25% 的迭代周期缩短。


MAF 保留了这些对话/群聊模式,涌现能力基本得以继承,而新增的确定性图编排与持久化机制预计会在不过多牺牲灵活性的前提下提升整体可靠性。


总结


看学术/研究 Benchmark(GAIA、WebArena 等)经典 AutoGen 积累的排行榜成绩更多;MAF 因为发布晚(RC 阶段),相关数据还不充分。看生产可行性、一致性、延迟、可调试性、持久化、Azure 集成等早期数据指向 MAF RC 在开发者综合 Benchmark 和企业指标上领先多数替代方案。多数谨慎的采用者在等 3 月底的 GA 版本,届时 API 将稳定,文档和示例也会更完整,预计会带出一波来自 Foundry 和第三方的正式 Benchmark。


by JOLALF


编辑:于腾凯
校对:林亦霖



关于我们

数据派THU作为数据科学类公众号,背靠清华大学大数据研究中心,分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识,努力建设数据人才聚集平台、打造中国大数据最强集团军。




新浪微博:@数据派THU

微信视频号:数据派THU

今日头条:数据派THU

问:AutoGen的智能体对话协作模式,相比传统的单线程链式调用和ReAct循环,有哪些更深层次的优势?除了文章中提到的性能提升,还有哪些潜在的应用场景?

作为一个偏学院派的选手,我尝试从理论层面来分析一下:

* 模块化与解耦:AutoGen将复杂的任务分解成多个智能体,每个智能体负责特定的功能,降低了系统的复杂性,提高了可维护性和可扩展性。
* 分布式处理:多智能体系统可以并行处理任务,提高整体效率。这在处理大规模数据或需要实时响应的场景中尤为重要。
* 博弈论视角:可以将多智能体协作看作是一个博弈过程,每个智能体根据自身的目标和策略,与其他智能体进行交互。通过博弈,系统可以达到纳什均衡,实现整体优化。

应用场景方面,我觉得在一些需要高度专业化和协同的领域,AutoGen有很大的潜力:

* 金融风控:不同智能体可以分别负责信用评估、欺诈检测、合规审查等,共同构建一个更完善的风控体系。
* 智能制造:多个智能体可以协同控制生产线上的不同设备,实现更高效、灵活的生产过程。

问:AutoGen的核心思想是“组建一支LLM专家团队,让它们彼此对话”,那么如何设计一个高效的智能体协作流程?有哪些需要注意的关键点?

我理解的关键在于“有效的沟通和明确的分工”。

1. 明确的角色定义:每个智能体都应该有清晰的角色和职责,避免混淆和重复工作。例如,可以设置“规划者”、“研究者”、“编码者”、“测试者”等角色。
2. 规范的沟通协议:智能体之间需要有统一的沟通方式和数据格式,确保信息传递的准确性和效率。可以使用JSON Schema或其他类似的工具来定义消息格式。
3. 合理的流程控制:需要制定一个有效的流程控制机制,例如状态机或工作流引擎,来协调智能体的行为,确保任务按计划进行。
4. 有效的错误处理:智能体协作过程中可能会出现各种错误,例如API调用失败、模型返回错误结果等。需要建立完善的错误处理机制,及时发现和解决问题。

此外,还需要考虑成本控制。LLM的调用成本较高,需要尽量减少不必要的对话和计算,优化智能体的行为策略。

我有一个大胆的想法!参考区块链的“矿池”概念,组建一个“智能体算力池”,多个用户共享算力资源,按需分配。这样不仅降低了单个用户的成本,还可以提高算力资源的利用率。就是不知道技术上是否可行…

企业应用需要分层设计。核心业务流程,比如财务结算,需要采用 MAF 的确定性图编排,保证可靠性和合规性;而对于探索性创新项目,比如市场调研,可以使用 AutoGen 的对话式群聊模式,保持灵活性和创新性。两者并非互斥,而是互补。

降低成本的关键在于减少 Token 的使用。可以尝试知识蒸馏技术,将大型语言模型的知识迁移到小型、高效的模型上,然后在多智能体系统中使用这些轻量级模型。当然,这需要在性能和成本之间找到平衡。

引入“沙盒”机制,允许开发者在隔离的环境中尝试新的智能体协作模式和技术,验证其可行性和潜在价值。一旦验证成功,再将其逐步推广到生产环境。这样既能鼓励创新,又能控制风险。

我觉得可以引入优先级机制,根据任务的重要性和紧急程度,动态调整分配给每个智能体的算力资源。对于不太重要的任务,可以使用成本较低的模型或减少计算量,从而降低总体成本。

我觉得在需要集思广益的场景下,多智能体协作优势明显。比如,新药研发,可以让一个智能体负责文献调研,一个负责分子结构设计,一个负责毒性预测,最后再由一个智能体整合所有信息并提出方案。这样能避免单一模型的信息茧房,提高研发效率。

从经济学的角度来看,多智能体协作本质上是降低了信息不对称。在金融投资领域,可以构建一个由宏观经济分析师、行业研究员和量化交易员组成的智能体团队,利用各自的专业知识进行更全面的投资决策,避免单一视角造成的偏差。

对我来说,AutoGen 最吸引人的地方是它的涌现行为。你永远不知道这些智能体凑在一起会搞出什么新花样,这种不确定性反而很有趣。但要说在实际应用中最有价值的,我觉得还是代码执行能力,能自己Debug才是真的牛!

个人认为,合并后最大的改变是从强调“自由探索”转向了“工程落地”,对开发者来说,需要更多地考虑诸如可观测性、持久化、类型安全等企业级需求。这种改变总体是积极的,但也可能限制了AutoGen原有的灵活性和创新性,需要在两者之间找到平衡。

我觉得最大的改变是,以前玩AutoGen就像在玩泥巴,随便怎么捏都行。现在MAF就像搭乐高,虽然更规范了,但也少了很多自由发挥的空间。这种改变好不好,我觉得得分情况,要是想快速出成果,那肯定MAF更香;但要是想搞点创新,可能还是AutoGen更适合。