Skip to main content

08 · 微软阵营：一个 60k star 项目被冻结的故事

这一篇不只是介绍三个框架，更是本专题里最好的一个选型风险案例。

一、AutoGen：星最多，但已经冻结​

仓库microsoft/autogen
Star60.5k
最后提交2026-04-15
状态冻结，能力迁往 Microsoft Agent Framework

AutoGen

图片来源：AutoGen 0.2 文档

它的核心贡献：把多智能体做成「群聊」​

AutoGen 的范式在 2023 年是新鲜的 —— 多个 Agent 像人一样在一个房间里轮流发言，直到问题解决：

# AutoGen v0.4 AgentChat 风格
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient

# AutoGen 把「模型客户端」和「Agent」分开：一个 client 可以给多个 Agent 共用
model_client = OpenAIChatCompletionClient(model="gpt-4o")

# 两个 Agent 的差别只有 system_message —— 这就是「角色」的全部实现
writer = AssistantAgent("writer", model_client=model_client, system_message="你负责写作。")
critic = AssistantAgent("critic", model_client=model_client, system_message="你负责挑刺，满意就说 APPROVE。")

# RoundRobinGroupChat = 轮流发言：writer 说一句 → critic 说一句 → writer 再改 → ……
# 直到满足终止条件（比如 critic 说出 APPROVE，或达到最大轮数）
team = RoundRobinGroupChat([writer, critic])
await team.run(task="写一首关于秋天的短诗")

这个「写手 + 批评者」的循环几乎定义了后来所有多智能体框架的范式 —— CrewAI、CAMEL、MetaGPT 都能看到它的影子。

它还带了一个 AutoGen Studio 低代码 GUI：

AutoGen Studio

图片来源：microsoft/autogen

两次断裂​

  1. v0.2 → v0.4：完全重写成事件驱动 Actor 架构，API 不兼容。大量教程、博客、课程一夜过期。
  2. v0.4 → 冻结：并入 Microsoft Agent Framework，官方提供迁移指南。

社区分叉出了 AG2（4.9k star，"formerly AutoGen"），继续维护 v0.2 血脉。60k star 的原仓库停更，4.9k star 的分叉在活跃 —— star 数在这里彻底失去了指示意义。

这件事的教训

评估框架时，pushed_at 和「背后组织的战略连续性」比 star 数重要。

AutoGen 是微软研究院的项目，Semantic Kernel 是微软产品部门的项目 —— 两个团队各做各的，最后必然要合并。这种「同一家公司做两套」的信号，在任何生态里都值得警惕。

同样的信号也出现在别处：Google 有 ADK 也有各种 Gemini 工具链，OpenAI 有 Agents SDK 也有 Assistants API 的历史包袱。选框架时问一句：这是这家公司的战略主线，还是众多实验之一？

二、Semantic Kernel：企业 .NET 的老兵​

仓库microsoft/semantic-kernel
Star28.5k
版本1.44.1
主语言C#（也有 Python / Java）
状态活跃维护，但新项目官方推荐迁到 MAF

SK 的定位一直很清楚：给已经在 .NET / Azure 生态里的企业开发者，一个能把 LLM 塞进现有系统的 SDK。 它的抽象（Kernel、Plugin、Function、Planner、Memory）非常「企业软件」：依赖注入、强类型、和 ASP.NET 无缝对接。

它在中文社区存在感低，但在欧美传统企业 IT 里装机量很大 —— 因为那些公司的后端就是 C#。

官方现在给的路径是从 SK 迁移到 MAF。

三、Microsoft Agent Framework：合流之后的产物​

Microsoft Agent Framework

图片来源：microsoft/agent-framework

仓库microsoft/agent-framework
Star12.9k（新项目，增长快）
版本agent-framework 1.14.0 / NuGet Microsoft.Agents.AI
语言Python + C#/.NET 双一等公民
许可证MIT
一句话AutoGen 的多智能体编排 + SK 的企业工程能力，重新做一遍

最小代码​

import asyncio
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

async def main():
    agent = Agent(
        # client 决定「模型从哪来」。FoundryChatClient 走 Azure Foundry，
        # AzureCliCredential 表示复用你 `az login` 的身份，不用在代码里放密钥。
        # 端点和模型名可以从环境变量读，也可以直接传参
        client=FoundryChatClient(credential=AzureCliCredential()),
        name="HaikuAgent",
        instructions="You are an upbeat assistant that writes beautifully.",
    )
    print(await agent.run("Write a haiku about Microsoft Agent Framework."))

asyncio.run(main())

.NET 侧是对等的一等公民：

using Microsoft.Agents.AI;

// DefaultAzureCredential 会依次尝试环境变量、托管标识、az login 等方式取凭据
AIAgent agent = new AIProjectClient(new Uri(endpoint), new DefaultAzureCredential())
    // AsAIAgent 把一个 Foundry 项目客户端「变成」一个 Agent
    .AsAIAgent(model: deploymentName,
               instructions: "You are an upbeat assistant that writes beautifully.",
               name: "HaikuAgent");

// 和 Python 版的 agent.run(...) 完全对应 —— 这就是「双一等公民」的意思
Console.WriteLine(await agent.RunAsync("Write a haiku about Microsoft Agent Framework."));

「Python 和 .NET API 一致」是它在本专题里的独特卖点 —— ADK 有五种语言但以 Python 为主导；MAF 是真的把 .NET 当第一梯队做。

官方自己给的适用判断​

MAF 文档里直接列了「什么情况适合你」，很少见地诚实：

  • 你构建的 Agent / 工作流预期要跑在生产环境
  • 你需要超出单次提示或无状态聊天循环的编排
  • 你要基于图的模式：sequential、concurrent、handoff、group collaboration
  • 你在意持久性、可重启、可观测性、治理、人工介入控制
  • 你需要供应商灵活性，架构演进时不用大改

翻译成人话：它是冲着「LangGraph 那一层能力 + 企业治理」去的，不是冲着快速原型。

生态覆盖​

支持 Microsoft Foundry、Azure OpenAI、OpenAI、GitHub Copilot SDK。托管上有 A2A、Foundry hosted agents，以及独立的 Durable Agent Framework extension（Durable Task / Azure Functions 集成）—— 持久执行被拆成了扩展包，这一点和 LangGraph 把 checkpointer 做进核心不同。

四、三者怎么选​

你的处境选择
新项目，微软生态Microsoft Agent Framework
老项目在 AutoGen v0.4走官方迁移指南到 MAF
老项目在 AutoGen v0.2，不想大改AG2 分叉
老项目在 Semantic Kernel，跑得好好的不急着动，SK 仍在维护；新模块用 MAF
不在微软生态说实话，LangGraph / ADK 社区更大，除非你要 .NET

五、供应商中立性​

部分换出 Azure 的成本
Agent / Workflow 抽象低
模型低（支持 OpenAI 直连等）
快速上手路径中 —— 文档和示例默认 FoundryChatClient + AzureCliCredential
Durable / Azure Functions 集成高
Foundry hosted agents高

README 里那段第三方系统免责声明也值得一读：微软明确说，你用 MAF 连非 Azure 的模型 / Agent / 服务，风险和成本自负。这是一个在合规上很清楚地划了圈的框架 —— 圈里很舒服，圈外自己负责。

六、什么时候用 / 什么时候别用​

用它，如果​

  • 后端是 .NET —— 本专题里几乎没有对手（ADK Java 只有 1.7k star）
  • 在 Azure / Foundry 上 —— 托管、身份、合规链路是通的
  • 需要 sequential / concurrent / handoff / group 四种编排模式的现成实现
  • 企业治理是硬要求 —— 可观测性、审计、HITL 是它主打的部分

别用它，如果​

  • 想要最大社区 —— 12.9k star，遇到问题时能搜到的答案远少于 LangChain 生态
  • 纯 Python 团队且不在 Azure —— 那 MAF 的两个最大优势都用不上
  • 被 AutoGen 的两次断裂伤过 —— 这是合理的顾虑，虽然 MAF 明显是这次的战略主线
  • 只是要一个会调工具的循环 —— 它的设计目标是生产级编排，杀鸡用牛刀

七、回到那个教训​

本篇真正想说的一句话：

选 Agent 框架时，「这个仓库最近三个月有没有提交」和「背后的组织会不会明年换个方向重做一遍」，比 star 数、比 API 好不好看，都更能决定你两年后的痛苦程度。

具体到检查动作，在 13 选型决策 里给了一个可执行的 checklist。

参考资料