昨天有朋友在群里问：Microsoft Agent Framework 正式版都出来好几个月了，Semantic Kernel 是不是要凉？我们项目上 SK 刚用顺手，到底迁不迁？
这个问题在 .NET 圈子里已经飘了半年，说法很多，摆证据的不多。我把两个仓库的 GitHub 发版记录、微软官方博客和迁移文档、社区的 Benchmark 数据对了一遍，先说结论：SK 没有凉，但重心确实在搬；迁不迁，取决于你属于三种情况里的哪一种。
一、"SK 停更"是谣言，但两个仓库的发版节奏确实拉开了
先辟谣：Semantic Kernel 一直在发版。我查了 GitHub 的 release 记录，.NET 的 dotnet-1.80.0 在 8 月 18 日刚发布，Python 的 python-1.44.1 也在 8 月初更新，再往前翻基本保持每月一版，没有断档。
再看被官方定位为"继任者"的 Microsoft Agent Framework：dotnet-1.19.0 在 8 月 22 日发布，python-1.15.0 在 8 月 21 日发布，基本是一到两周一版，.NET 和 Python 双线推进。
一个是按月维护，一个是双周冲刺。做过开源维护的都懂，这种节奏差异，基本就是"保障运行"和"主战场"的区别。
二、真正的信号：有组件开始"搬家"了
光是节奏差异，还能解释成"SK 维护得挺认真"。但 dotnet-1.80.0 的更新日志里有条容易被忽略的改动：已经迁移走的 .NET 向量数据组件（MEVD）被移除了，原地只留了个指向新家的说明。GitHub翻译一下：SK 的部分组件不是在"更新"，而是被整体搬去了新框架，原地址只剩一张"转发条"。
官方口径更直接。2025 年 10 月，微软宣布将 AutoGen 与 Semantic Kernel 合并，统一为 Microsoft Agent Framework。知乎SK 的产品负责人在官方博客里说得更明白：MAF 是 Semantic Kernel 的继任者，可以把它理解成"同一个团队打造的 Semantic Kernel v2.0"。
官方的承诺是：SK v1.x 会继续处理关键 bug 和安全问题，但绝大多数新功能只会在 MAF 上构建，支持期至少持续到 MAF 正式版发布一年后。微软官方博客而按社区的梳理，MAF 在今年 4 月就在 .NET 和 Python 双平台达到 v1.0 正式版，承诺长期支持。知乎也就是说，"至少一年"的倒计时，从 4 月就已经开始了。
官方文档也已经备好了一份完整的"Migrate from Semantic Kernel"指南，.NET 部分列了 11 项映射差异：命名空间更换、Kernel 装配改成一行扩展方法创建 Agent、Thread 换成 Session、插件注册改成直接挂工具，一项一项都给了前后对照。Microsoft Learn官方仓库里还有 .NET 和 Python 两份迁移示例代码，连官方视频教程都专门做了真实项目迁移的专场。一句话总结：官方已经把"搬家"的电梯修到你家门口了，问题只在于你现在搬不搬、搬一次要花多少钱。
三、如果迁移动机是"新框架更聪明"，这组数据可以给你降温
做决定之前，值得先看一组公开研究。2026 年有团队在统一模型（GPT-5.2）、统一提示词、16495 个任务的条件下测了 22 个 Agent 框架，结果发现：12 个主流框架的平均准确率集中在 74.57%～75.94% 之间，最大差距只有约 1.4 个百分点。知乎换句话说，模型一样时，换框架几乎不会改变模型的智力水平——框架干的是"组织"的活：Agent 循环、工具调用、状态管理，不是"提智"的活。
真正拉开差距的是编排失控。把框架拆开看，核心也就是顺序执行、并行执行、任务交接这几类编排模式，但同样的模式，不同实现跑出来的结局天差地别。同一项实验里，有框架因为上下文不受控膨胀，一个测试集跑了 11 天都没结束。
另一个极端是成本失控：有框架在部分任务里累计烧掉约 478 万 Token，单个任务折算成本约 1434 美元。知乎整个实验累计约 108.6 亿输入 Token、68.5 万次 API 请求。吃掉预算的从来不是模型的能力，而是框架内部的重试、记忆和上下文膨胀循环。
还有一个更反直觉的结论：MAFBench 的受控实验显示，只换框架架构、不换模型和任务，就能造成超过 100 倍的延迟差异。知乎所以"迁移=变更强"这个等式不成立，迁移换来的是另一样东西：更简的 API、统一的 provider 接口、官方长期支持的承诺，以及未来的所有新功能。值不值这一次全量改造的工程投入，是笔算账题，不是信仰题。
四、三种人，三种做法
第一种：新项目，还没开始写代码。直接上 MAF。官方的建议也很明确：能等到 MAF 正式发布再上线的新项目，推荐直接从 MAF 起步。微软官方博客MAF 的上手门槛比 SK 低，不用先啃 Kernel、Plugin 那套概念链，一个 chatClient.AsAIAgent() 就能把 Agent 建起来，后面再往上添工具、会话和工作流。
第二种：SK 项目已经在生产上稳定跑着。别急着迁。Benchmark 数据已经说明，迁移不会带来效果的质变，而迁移成本是实打实的——光 .NET 就有 11 项映射差异要改，后面还跟着全量回归测试。官方的口径也是：已有项目继续用 SK，完全没问题。微软官方博客建议给自己设三个观察信号：一是你依赖的 SK 组件开始出现"移除+重定向"，向量存储组件已经开始了；二是新连接器、新模型支持变成 MAF 首发、SK 不再跟进；三是官方公布 SK 的支持截止日。三个信号都没出现之前，照常使用、照常打补丁就行。另外补一句：今年上半年 SK 曝出过两个可被提示词注入触发的主机级 RCE（CVE-2026-25592/26030），还没升到修复版本的，先把补丁打了，这件事比迁不迁更急。
第三种：需要工作流、多智能体协作、长任务恢复、人工介入。MAF 值得认真评估。图式工作流、检查点恢复、中间件、编排模式这些是 MAF 的主打能力，而它们恰恰是你今天在 SK 上要自己手搓的部分。知乎但动手前记得前面那个结论：框架不保证效果，写法才保证效果——迁之前先用真实业务负载跑一轮 PoC，比看任何对比文章都靠谱。
最后补两条外围信息：MAF 的 Go 版本已经进入公开预览，技术栈不只有 .NET 和 Python；社区消息里微软还在推进企业级 Agent 的统一治理，团队规模大的值得持续留意。
迁，还是守？欢迎在评论区聊聊你踩过的坑。我会持续盯这两个仓库的动向，三个观察信号一旦触发，第一时间更新。
