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

📅 2026/8/18 13:26:45
从爆火到合并:AutoGen的来龙去脉(附代码)
本文的字数大约是3500字, 阅读它建议花费7分钟, 此文中介绍了其发展情况, 还提及了核心设计, 另外阐述了与MAF的合并现状。曾是用于构建LLM多智能体系统的具有标杆性质的开源框架, 在2023年末由相关方发布后, 很快就变成研究人员以及开发者的默认选择, 这些智能体之间能够相互进行对话, 还能调用工具, 编写并且执行代码, 在流程里引入人类审批用对话式的协调形式替代了单条长链条。于2026年初时, v0.4此为2025年初重新进行设计的版本乃是其在技术层面的巅峰成果。然而在2025年末, 正式将其与合并, 统一成为AgentMAF。可是, 众多人在提及源自的那种多智能体编排风格之际, 依旧习惯讲。本文对其来龙去脉予以梳理: 它究竟是什么, 为何重要, 有哪些核心设计在2026年仍旧存在, v0.4/v0.7时代的架构以及典型用法, 代码示例, 存在的利弊, 还有当下的整体状况。为什么在 2023–2024 年迅速走红在出现以前, LLM 的主流运用方式仅有两种, 一种是单线程链式调用, 也就是那种风格, 另一种是简单的工具调用智能体, 即 ReAct 循环。这套心智模型全然不一样——其中智能体是参与对话者, 整个体系是群聊模式, 时而具结构, 时而任性发挥。智能体间能委派任务, 能相互批评并更正, 能调用工具, 能编写且执行代码, 能向人类发出询问, 目标达成后自行中止。不存在任何需提前知晓完整规划的中央控制器。这套流程, 与人类解决复杂问题的方式, 高度吻合。其包括分工, 还涉及讨论, 以及审查输出。早期, 有几个病毒式传播的demo, 其中有编码者、评审者、执行者联合解数学题, 还有网络研究小组、股票分析团队。它们在许多任务上, 展现出比单智能体高2至10倍的表现。v0.4——大改版2025v0.4预计2025年初发布究其根本而言是2.0。以往的阻塞式同步 已被全新的三层架构所替换: -core承担底层事件驱动原语包含、订阅、发布/订阅消息传递 - 属于绝大多数人实际运用的高层API涵盖、、、 -ext乃是可插拔的扩展层诸如 API、MCP 工作台、gRPC 分布式智能体等。核心改进涵盖, 由完全异步化所带来的更佳可扩展性与可观测性, 模块化的自定义组件内存、模型、编排具备, 改进后的错误恢复与检查点机制也存在, 还有跨语言支持被尝试——当然始终是主力。2025 年末 / 2026 年初的典型安装方式pip install -Uautogen-agentchatautogen-ext[openai]经典双智能体模式2026 年仍在使用和教学中from autogen import AssistantAgent, UserProxyAgent, config_list_from_json# Usually load from OAI_CONFIG_LIST or envconfig_list config_list_from_json(OAI_CONFIG_LIST)assistant AssistantAgent(namehelpful_engineer,llm_config{config_list: config_list},system_messageYou are a senior Python engineer. Write clean, efficient code.)user_proxy UserProxyAgent(nameuser,human_input_modeNEVER, # NEVER / ALWAYS / TERMINATEmax_consecutive_auto_reply10,code_execution_config{work_dir: coding, use_docker: False},)user_proxy.initiate_chat(assistant,messageWrite a Python class that downloads daily OHLCV data from Yahoo Finance for any ticker and caches it in parquet.)就已经具备了完整的闭环, 短短几行代码, 有一个能做规划的LLM智能体, 有代码编写, 有本地执行, 有自动重试/错误修复循环, 还有终止条件判定。群聊—— 的标志性模式from autogen import GroupChat, GroupChatManagerresearcher AssistantAgent(nameResearcher, system_messageFind latest information., llm_configllm_config)critic AssistantAgent(nameCritic, system_messageBe skeptical and point out flaws., llm_configllm_config)writer AssistantAgent(nameWriter, system_messageWrite in engaging blog-post style., llm_configllm_config)user_proxy UserProxyAgent(nameUser, code_execution_configFalse, human_input_modeTERMINATE)groupchat GroupChat(agents[user_proxy, researcher, critic, writer],messages[],max_round12)manager GroupChatManager(groupchatgroupchat,llm_configllm_config,# speaker_selection_methodauto / round_robin / custom func)user_proxy.initiate_chat(manager,messageWrite a 800-word article about newest developments in small modular nuclear reactors in 2026.)2025年至2026年期间的实际项目里头, 5个到12个智能体的配置是较为常见的, 其中涉及规划者, 然后是研究者, 接着是编码者, 再之后是测试者, 随后是评审者, 再然后是文档编写者, 最后是用户审批者, 或者干脆让智能体自己去决定何时拆分各个子团队, 这是一种情况。的突出优势涌现行为具备着最为让人一惊的特性, 那就是智能体常常会以超出人们意料的形式去达成分工。人机协作在颗粒度方面达成了针对任意节点的审批以及编辑, 并非仅仅局限于在流程的末尾给出一个是或者否了啦。代码执行的能力使得智能体能够自行修复bug从而构建起“编写 - 运行 - 修复”这样的一个闭环。框架自身对于实验是极为包容的, 规则比较容易被打破, 是适宜于快速进行试错的。社区围绕着它衍生出来了MCP支持、研究智能体、gRPC扩展等一整套生态。痛点2024–2025智能体参与的GPT - 4o对话, 一次8个, 处理复杂任务费用可达5至30美元, 这是最直接的成本问题。非确定性致使复现与测试困难, 长对话造成Token爆炸和上下文窗口耗尽, 调试时难以追溯“谁在什么时候说了什么”, 在前述状况下又几乎不存在v0.4后期补丁出现之前的检查点/恢复机制, 此类种种都是真实落地时无法回避、必然遭遇的问题。2025–2026 年的过渡—— Agent MAF在2025年10月的时候, 宣布了这样一件事, 即不再作为独立库去接收重大功能更新。而是出现了另外一种情况, 那就是与之相关的概念被并入到Agent中, 这里存在与.NET双语言支持, 其中一部分负责企业级规划基础, 另一部分则承载多智能体编排和对话模式。MAF继承了核心精神, 即对话式智能体、群聊编排、工具调用之类要素, 然而在这基础之上弥补了工程化方面的不足, 涵盖内置检查点和恢复, 基于对象的可观测性, 也就是追踪与指标, 对于Model相关产物以及与之毗邻之物A2A的原生支持, 与Azure AI以及另外一些诸如365、M365的深度整合, 还有把规划器与特定风格团队混用起来的统一SDK。迁移指南迅速现身于Learn之上。然而, 在2026年年初的时候, 依旧存在着数量众多的、正在运用旧的 - 包的开源项目——就进行原型开发这个情况而言的话, 那般的旧 - 包确实是足够让人感觉熟悉的, 而且实际上也依然得以被派上用场。当前状态2026 年 3 月在原型开发的场景里, 经典v0.4/v0.7的代码现在依旧到处都能看到。在研究的场景当中又是如此。在教学场景之下也是如此, 那些经典v0.4/v0.7的代码仍然随处可见。生产环境几乎已经全面倾向于Agent, 或者正处于迁移的过程之中。企业的环境也是这样, 企业环境亦是趋近于企业环境几乎总体转向Agent, 或者正行进在迁移的途中。社区以围绕MAF风格模式维持着非常高的活跃度。其他后起者比如Swarm、-One等, 都在不同程度上借鉴了率先被提出的多智能体协作理念。留下了什么的作用并非局限于一个库, 它在本质上改变了开发者对于 LLM 应用的认知架构, 即由“单一掌控全体”导向“构建一支 LLM 专家团队, 促使它们相互交流对话”, 多智能体协同工作作为首要的基础要素, 截至 2026 年已然深入到整个行业领域, 就算不再编写一行代码, 在日常所使用的系统中极有可能已然融入了的特性。因框架本身作为独立产品已然经历了“退役”这一情况, 然而其架构思路却深度渗透进了 Agent 以及更为宽泛的智能体生态之中。涉及在 2026 年 3 月开启的全新项目, 应当自 Agent 文档起始处于维护旧代码或是偏好原始简洁性等场景的时候, v0.4 API极有可能还能够持续运行多年。Agent MAF当前一代的开源智能体框架是 Agent MAF, 它覆盖构建、编排、部署与管理的全流程, 尤其面向多智能体系统, 于 2025 年 10 月进入公开预览, 它是两个前代项目的官方继任者, 其中一个带来了对话式多智能体编排、涌现团队行为和面向研究的灵活性, 另一个则贡献了企业级基础, 包括类型安全、中间件、可观测性、插件/连接器体系以及生产稳定性。到二零二六年年初的时候, MAF被定位成了, 与.NET双语言智能体开发的统一长期路径, 它和Azure AI深度绑定, 不过同时保持着完全开源且模型无关。要解决的 MAF, 恰恰是 2024 至 2025 年期间开发者始终不断遭遇的那道两难问题: 要是想迅速进行原型制作、让多个智能体能够自由协作, 那就得做出选择 要是想要生产级别的可靠性、追踪功能、持久化特性、类型安全性以及企业连接器, 亦得做出选择。MAF 于单个 SDK 以及运行时当中, 将两边的能力融合到了一块儿——源自 的简洁智能体/团队抽象, 源自 的会话状态管理、中间件管道、过滤器以及检查点, 再额外增添全新的一层: 以图形为基础的显式工作流, 用于实施确定性的多智能体编排。最小单智能体from agent_framework import AIAgentfrom azure.ai.openai import AzureOpenAIClient # or openai.OpenAI etc.import osclient AzureOpenAIClient(endpointos.getenv(AZURE_OPENAI_ENDPOINT),credential…, # DefaultAzureCredential() etc.)agent client.get_chat_client(gpt-4o-mini).as_ai_agent(instructionsYou are a concise technical writer.,nameTechWriter)response await agent.run(Explain Microsoft Agent Framework in one paragraph.)print(response.content)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);多智能体群聊, 其在风格方面依旧存有状态, 2026年初的多数示例, 于模式上和0.4群聊极为相像, 不同之处在于底层增添了持久性支持。from agent_framework import GroupChat, GroupChatManager, AssistantAgent# … define researcher, critic, writer agents …group GroupChat(agents[user_proxy, researcher, critic, writer],max_rounds15,# now supports persistent session id, checkpointing, etc.)manager GroupChatManager(groupgroup)await user_proxy.initiate_chat(manager,messageResearch write 600-word post on SMR nuclear progress in 2026)除了对话式群聊之外, MAF增添了基于图/DAG的工作流编排, 节点可是智能体、函数、条件判断或者循环, 执行路径是确定的, 十分契合业务流程与合规场景 , 单个节点内部依旧能够使用对话模式, 类型安全的输入/输出在.NET里特别得手 , Azure AI于2026年初还预备了可视化工作流设计器的预览版。跟, 所面向的场景有着明晰的区分: 前者适宜于开放式的研究以及调试, 后者运用于订单处理、贷款审批、事件响应这一类必须依循严格顺序以及分支逻辑来运行的流程。继承自 的能力在 MAF 中延续在整合之前, 于2024–2025年的多项学术/研究方面, 处于领先或者并列的位置。在GAIA基准测试开放式推理当中多智能体团队针对2024年至2025年初的这一时间段, 频繁地占据榜首, 困难子集上的成功率一般是在70–85%这个区间, 单智能体在同期的成功率则是40–60%。在SWE-bench软件工程方面, 多智能体变体在代码修复任务里, 比对单智能体高出25–40%。如 Novo的数据科学流水线那样的、属于特定行业的案例, 报告了迭代周期缩短的情况, 缩短幅度约为25%。MAF 留存了这些对话, 留存了群聊模式, 涌现能力大体上得以继承, 而新增加的确定性图编排机制, 新增加的持久化机制, 预计会在不过度牺牲灵活性的情形下, 提升整体可靠性。总结