2023 年底，微软发布了 AutoGen，一个基于多 Agent 协作的对话式 AI 框架。短短一年内，它在 GitHub 上收获了 48K+ star，成为最热门的多 Agent 框架之一。但故事并没有结束——2024 年，原核心团队因内部战略分歧离开微软，fork 出了 AG2。从此，社区分裂成了两个阵营。
本章节将带你深入 AutoGen v0.7（核心包 autogen-agentchat）的源码内部，从 BaseChatAgent 到 SelectorGroupChat，从消息类型到状态管理，完整走读一遍微软设计者的思路。无论你最终选择 AutoGen 还是 AG2，理解其核心设计哲学对你的 Agent 开发都会有深远影响。
AutoGen v0.4+ 是一次彻底的重构。微软抛弃了 v0.2 中 60K+ 行的单体代码，重新设计了基于消息传递的三层架构。新的架构更清晰、更模块化，但也导致了与 v0.2 和 AG2 的 API 完全不兼容。这是一场"长痛 vs 短痛"的选择——微软选择了短痛。
| 包名 | 版本 | API 风格 | 维护方 |
|---|---|---|---|
| autogen-agentchat | v0.7+ | 三层架构、纯异步 | 微软 |
| autogen (AG2) | v0.2 延续 | initiate_chat() | 创始团队 |
AutoGen v0.4+（即 autogen-agentchat 包）采用了清晰的三层架构：Core API（Layer 1）提供运行时时基础设施；AgentChat API（Layer 2）定义 ChatAgent、Team、TerminationCondition 等抽象协议；Agent & Team 实现（Layer 3）提供 AssistantAgent、SelectorGroupChat 等具体实现。这套架构的核心设计哲学是消息传递（Message-Passing）而非图执行。
与 LangGraph 的图执行模型不同，AutoGen 的设计哲学是"Agent 是黑盒，消息是信使"。每个 Agent 是完全解耦的独立单元，只通过消息与其他 Agent 通信。这种设计带来了天然的可扩展性——你可以在不修改其他 Agent 的情况下新增、替换或移除任何一个 Agent。Team（团队）是消息路由的调度者，而非执行者。
Layer 1 Core API 包含 AgentRuntime（运行时环境）、CancellationToken（取消令牌）和 ComponentBase（组件基类）。Layer 2 AgentChat API 定义了 ChatAgent 抽象协议（on_messages() / on_messages_stream() / on_reset()）和 Team 抽象协议（run() / run_stream()）。Layer 3 是具体的实现类。
所有 AutoGen 的 Agent 都继承自 ChatAgent 抽象类。BaseChatAgent 是实际开发中真正继承的基类，它要求 Agent 名称必须是有效的 Python identifier，且 Agent 是有状态的——每次 on_messages 只传入新增消息。AssistantAgent 是最核心的 LLM Agent，封装了完整的 LLM 调用循环：System Prompt → User Message → Tool Call → Function Execution → Final Response。注意 reflect_on_tool_use 参数：当设为 True 时，Agent 在 Tool Call 后会用 LLM 再反思一次结果。
AutoGen 还内置了 CodeExecutorAgent（Docker 沙箱代码执行）、UserProxyAgent（人类输入）、SocietyOfMindAgent（内部运行 Team）、MessageFilterAgent（消息过滤中间件）等专用 Agent。设计解读：消息传递意味着每个 Agent 是完全解耦的「黑盒」——只需要实现 on_messages 和 on_reset。
AssistantAgent 的 LLM 调用循环值得深入理解。它内部维护了一个 _model_context（聊天上下文），每次 on_messages 时将新消息追加到上下文中，然后调用模型客户端生成回复。如果模型返回了工具调用，Agent 会执行这些工具、将结果追加到上下文、然后再次调用模型——这一过程会持续到模型返回文本回复或达到 max_tool_iterations 限制。
Team 是 AutoGen 中编排多 Agent 协作的核心。提供三种 GroupChat 实现：RoundRobinGroupChat（轮询顺序发言）、SelectorGroupChat（LLM 动态选择发言者）、GraphGroupChat（有向图约束 + 可达性）。所有 GroupChat 都继承自 BaseGroupChat，其核心是基于事件总线的广播模型——Manager 通过 Group Topic 广播消息，参与者通过独立 topic 接收指令。
SelectorGroupChat 的 Speaker 选择流程包含三级层级：Selector Function 覆盖 → Candidate Function 裁剪 → LLM 模型选择，并内置三次重试机制。三级设计的精妙之处在于：它允许开发者在不同层级上控制选人逻辑——最低级（selector_func）提供完全确定性控制，中级（candidate_func）提供过滤逻辑，高级（LLM）提供智能决策。
终止系统提供 6 种终止条件：StopMessageTermination（收到 StopMessage 停止）、MaxMessageTermination（消息数量上限）、TextMentionTermination（提及特定文本停止）、TokenUsageTermination（Token 用量上限）、MaxTimeTermination（时间上限）、OrTermination / AndTermination（逻辑组合）。这些终止条件通过职责链模式组合，形成复杂的终止策略。
| GroupChat 类型 | 选人方式 | 适用场景 |
|---|---|---|
| RoundRobinGroupChat | 轮询 | 确定性流程、流水线 |
| SelectorGroupChat | LLM 动态选择 | 智能协作、角色扮演 |
| GraphGroupChat | 有向图约束 | 复杂依赖、DAG 工作流 |
2023 年 9 月微软发布 AutoGen v0.1 → 2024 年 10 月创始团队离开微软 fork 出 AG2 → 2024 年底微软重构为 AutoGen v0.4+（API 不兼容）→ 2025 两条平行发展线。代码层面关键差异：AutoGen（autogen-agentchat v0.7+）采用三层架构、纯异步 on_messages() 模式、Pydantic v2 原生；AG2（autogen）延续 v0.2 API 风格、initiate_chat() / generate_reply() 模式。截至 2025 年 6 月：microsoft/autogen 48K+ Star（社区维护模式），ag2ai/ag2 约 5K+ Star（原作者领导）。
这次分叉的本质是"维护 vs 重构"的理念冲突。原团队倾向于在 v0.2 基础上逐步改进（保持向后兼容），而微软倾向于彻底重构（拥抱异步和 Pydantic v2）。两种选择各有代价：AG2 保持了 API 稳定性但背负了技术债务，AutoGen v0.7+ 代码更干净但导致了社区分裂。
对开发者而言，选择取决于你的具体需求：如果你已经基于 v0.2 构建了大量代码，AG2 是平滑迁移路径；如果你从零开始新项目，autogen-agentchat v0.7+ 的架构设计更现代、更系统化。值得一提的是，微软已推出 Microsoft Agent Framework——这才是微软的下一代官方 Agent 平台，AutoGen 已进入维护模式。
AutoGen 的整个通信基于 autogen_agentchat/messages.py 中的 Pydantic v2 模型。两大消息体系：BaseChatMessage（Agent-to-Agent 通信，包括 TextMessage、StopMessage、StructuredMessage、HandoffMessage、ToolCallSummaryMessage）和 BaseAgentEvent（Agent 内部流式事件，包括 ThoughtEvent、ToolCallRequestEvent 等）。Handoff 是 v0.4+ 引入的内置 Agent 切换机制——本质上是一个工具调用，Agent 通过「调用工具」来转移控制权。状态管理在 state/_states.py 中定义，save_state() 和 load_state() 是 ChatAgent 接口的强制方法，天然支持检查点恢复。
消息类型的设计体现了 AutoGen 对"结构化通信"的重视。TextMessage 是最基本的文本消息，StopMessage 用于终止对话（接收到后 Team 自动停止），StructuredMessage 可以携带任意结构化数据，HandoffMessage 实现 Agent 之间的控制权转移。每种消息类型都有明确的语义，使得 Team 调度器能够根据消息类型做出不同的路由决策。
状态管理的实现值得关注。save_state() 被设计为 ChatAgent 接口的强制方法——这意味着所有 Agent 天然支持序列化。这为生产系统中的"中断恢复"和"时间旅行调试"提供了基础设施。自 v0.4.9 起，状态使用 Agent 名称作为键，使得状态可以在不同的 Team 实例和运行时之间移植。
常见踩坑：包名混淆（autogen vs autogen-agentchat）、版本迁移（v0.2 API 不再支持）、GroupChat 历史管理、Token 限制。框架对比：AutoGen（消息传递、内置状态管理、维护模式）、LangGraph（DAG 图编排、灵活但学习曲线高）、CrewAI（模板化、快速原型）。一句话总结：AutoGen v0.7+ 的架构设计更干净、更系统化——三层分离、Pydantic 原生、纯异步、内置状态管理。
调试多 Agent 系统建议从最小化开始：先用 RoundRobinGroupChat 和 2 个 Agent 验证消息流，再逐步增加 Agent 数量。使用 Console(group_chat.run_stream(...)) 可以清晰地看到每条消息的流向。遇到选人不准时，检查每个 Agent 的 description 字段是否清晰描述了其职责——LLM 选择发言者时会依据这个描述。
框架选择的最终建议：如果你的场景需要确定性工作流（如代码审查流水线），LangGraph 的图模型更直观。如果需要灵活的多 Agent 协作（如角色扮演、辩论），AutoGen 的消息传递模型更自然。如果需要快速原型验证，CrewAI 上手最快。