AutoGen

AutoGen 是由 Microsoft Research 构建的 Python 框架，用于在协作工作流中编排多个 AI 智能体。该框架于 2023 年发布，目前版本为 0.7.x，它允许开发者组合自主智能体，这些智能体可以通过结构化消息传递进行通信、委派任务、调用工具以及编写和执行代码，所有这些都在一个可以本地运行或跨进程分布式运行的运行时环境中进行。该框架在 GitHub 上拥有 57,500 颗星，并且仍然是生产环境中最常被引用的开源智能体框架之一。

核心框架提供三个层级：AutoGen Core（具有异步事件驱动消息传递的 Actor 模型运行时）、AgentChat（用于双智能体聊天和群聊等常见模式的高级 API）以及 Extensions（针对 OpenAI、Azure OpenAI 和 MCP 服务器的集成）。AutoGen Studio 提供了一个无代码 Web GUI，无需编写 Python 代码即可对工作流进行原型设计和调试。Magentic-One 是框架捆绑的通用多智能体预设，在 2024 年底的 GAIA、AssistantBench 和 WebArena 基准测试中取得了极具竞争力的结果。跨语言支持涵盖 Python 3.10+ 和 .NET。

2026 年 4 月的 AutoGen 实际功能

AutoGen 当前的稳定版本（v0.7.x，其中 v0.7.5 于 2025 年 9 月发布）建立在 2025 年 1 月发布的 v0.4 架构重写基础之上。该重写用 Actor 模型运行时取代了最初的同步对话循环：智能体成为独立的计算单元，通过中央运行时接收和发送类型化消息，而不是在线性链中相互调用。这解耦了消息传递与消息处理，意味着智能体可以在不同的进程、不同的机器或使用不同的语言运行。

在实践中，这解锁了更广泛的模式：将任务扇出（fan-out）给并行智能体、组合在运行中途设置检查点的流水线、将部分结果流式传输回用户代理，或者根据运行时条件在编码智能体和审查智能体之间进行交接。AgentChat 层保留了 AutoGen 0.2 用户熟悉的更简单的 API，因此现有的双智能体和群聊模式无需重写即可继续工作。

AutoGen Studio 作为 Web 界面和 Python 包捆绑提供，将智能体和团队配置呈现为拖拽式画布。它主要针对原型设计和调试用例：开发者可以切换模型、调整智能体提示词并重放会话，而无需接触代码。Microsoft 明确指出，AutoGen Studio 是一个研究原型，而非生产部署目标。

Magentic-One 是一个构建在 AgentChat 之上的预设多智能体系统，它将一个规划编排器与四个专家智能体（Web 浏览器、文件导航器、代码执行器和终端）连接在一起。在 GAIA 基准测试中，它的得分为 38%；在 WebArena 上为 32.8%。在发布时，这些数据与领先的开源系统相比具有很强的竞争力。

“领先于 LangChain 智能体一步，并且似乎比 LangChain 愿意在智能体上投入的关注和开发还要多。” - anais9，Hacker News，2023 年 10 月

AutoGen 与 CrewAI 和 AG2 的定位对比

最直接的两个比较对象是 CrewAI（新项目中最受欢迎的替代方案）和 AG2（2024 年底从 AutoGen 分支出来的社区分支）。

AutoGen vs. CrewAI： CrewAI 使用基于角色的声明式模型，开发者通过分配角色文本、目标文本和背景故事文本来定义一个智能体“团队（crew）”，框架会推断协调方式。一个基础的 CrewAI 流水线大约需要 20 行 Python 代码。AutoGen 的 AgentChat 层需要更多样板代码来指定智能体类型、终止条件和消息路由，但它支持 CrewAI 不具备的对话模式：多方小组辩论、共识协议以及会话内的动态角色切换。Token 开销基准测试始终显示 AutoGen 的消耗高于 CrewAI（约 24% 对 18%），因为其以对话为中心的模型会在每一轮保留完整的消息历史记录。在 2025-2026 年期间，CrewAI 在 GitHub 上的星数增长更快，并且是大多数“智能体入门”教程的默认推荐。

AutoGen vs. AG2： 2024 年 9 月至 10 月，原 AutoGen 负责人 Chi Wang 和合著者 Qingyun Wu 离开了 Microsoft。Wang 随后加入了 Google DeepMind。这两位研究人员在一个新的 GitHub 组织（ag2ai）下将 AutoGen 0.2 代码库分支为 AG2，在 Apache 2.0 下重新许可，并将其重新命名为“社区治理分支”。AG2 保持了与 AutoGen 0.2 的向后兼容性，并吸引了来自 Meta、IBM 和多所大学的维护者。关键的机制差异在于治理和发展轨迹：AG2 正朝着具有开放治理的 v1.0 迈进，而 Microsoft 的 AutoGen 已正式进入维护模式，没有计划推出新功能，并且 Microsoft 正将新的企业用户引导至 Microsoft Agent Framework。对于需要稳定性和向后兼容性的 AutoGen 0.2 团队来说，AG2 是自然的迁移路径。而对于构建全新智能体系统的团队来说，该领域已经出现了分化。

“AutoGen 依然充满活力，依然在获得大量投资……它是多个第一方产品底层智能体系统的基础。” - Marc Sweet，Microsoft 架构师，在 2024 年底回应社区碎片化担忧时表示

日常智能体循环的真实情况

典型的 AutoGen 工作流包括定义一个 UserProxyAgent（可以执行代码并代表人类）和一个或多个 AssistantAgents（调用 LLM），然后发起聊天。框架负责处理轮次交替、终止条件和代码沙盒。默认情况下，代码执行在 Docker 容器内运行，这提供了隔离性，但也增加了延迟，并依赖于环境中可用的 Docker。

开发者论坛和 GitHub 问题中反复出现的摩擦点集中在四个方面。首先是智能体循环：如果没有精心调整的终止条件，智能体可能会进入重复的交流循环，消耗 Token 却无法收敛。其次是成本不透明：因为每个智能体轮次都会追加到不断增长的对话缓冲区中，多智能体会话产生的 Token 数量在运行前很难预测。一次复杂的群聊运行成本可能远高于解决相同任务的单次 LLM 调用。第三是 v0.2 到 v0.4 的迁移：架构重写不向后兼容，在 v0.2 上构建生产系统的团队面临部分重写。Microsoft 维护了一个 v0.2 遗留分支，但没有为其添加新功能。第四是包名混淆：五个不同的 PyPI 包（autogen、pyautogen、autogen-agentchat、ag2 和 autogen-core）同时流通，安装错误的包会导致意外行为。

AG2 分支增加了一层政治色彩。今天选择 AutoGen 的团队，实际上是在隐性地选择 Microsoft 的维护轨迹，而不是社区治理的分支。对于所有用例来说，这两种选择都没有明显的优劣之分，但这一选择对长期依赖管理至关重要。

AutoGen 适合哪些人群

AutoGen 最适合需要灵活的对话式智能体模式并习惯于管理自身基础设施的 Python 开发者。该框架非常适合那些希望对消息流、终止逻辑和智能体组合进行细粒度控制的工程师。构建研究原型、内部工具或一次性智能体流水线的团队能从中获得最大价值。.NET SDK 使其成为少数几个原生支持企业级 C# 代码库的开源智能体框架之一。

AutoGen Studio 降低了非工程师尝试智能体配置的门槛，但它明确是一个原型设计工具。需要生产可靠性、UI 可观测性或托管服务的团队应仅将 Studio 视为沙盒。

Microsoft 自身的定位也发生了转变。该公司现在推荐将 Microsoft Agent Framework 用于全新的企业项目，并将 AutoGen 定位为为其提供参考的研究原型。AutoGen 继续接收安全补丁和错误修复，但自 v0.4 发布以来，功能更新速度已大幅下降。

AutoGen 不是什么

AutoGen 不是托管服务。没有托管 API，没有云运行时，没有内置的可观测性仪表板，也没有供应商支持层级。从模型选择到容器配置再到成本管理，每一个部署决策都由实施团队负责。

在 2026 年，它并不是构建可用智能体的最简单途径。CrewAI 能以更少的样板代码更快地实现功能演示。LangGraph 为生产环境的条件工作流提供了更明确的状态管理和更好的工具。如果您的主要目标是在产品中发布智能体功能，那么 AutoGen 的学习曲线和维护不确定性使其比 2023 年时更难被接受。

它也不适合需要供应商保证的团队。MIT 许可证意味着您可以自由使用它，但 Microsoft 已经发出了减少投资的信号。在 AutoGen 上构建关键自动化的团队应该在维护状态产生实质影响之前制定迁移计划，无论是转向 Microsoft Agent Framework（企业路径）还是 AG2（社区路径）。