做 .NET 后台开发的过去两年基本绕不过 Semantic Kernel 这个词。从最初想给业务系统接大模型到后来做知识库问答、做工具调用SK 几乎是社区默认的起手式。它把提示词、函数调用、向量记忆这些东西装进一套统一的抽象解决了“裸调模型接口没法维护”的大问题。但用久了你会慢慢感觉到它本质上还是一个“函数编排器”离真正的“智能体框架”还有一段距离。直到 Microsoft Agent Framework下文统一简称 Agent Framework被推到前台这个局面才出现真正的变化。注意不是 SK 被淘汰了而是被重构了SK 的 Kernel、插件、连接器这些老资产被原样保留下来继续做底层执行引擎Agent 架构则被放到上层变成新的开发模型。整个 .NET AI 生态的开发范式正在从“编排函数”切换成“编排智能体”。这篇文章是我梳理这个演进过程的笔记包含框架继承关系的拆解、两套编码风格的对比、迁移示例以及一些踩坑后的经验。如果你手头已有跑得不错的 SK 项目或者正在做 .NET 下的 AI 技术选型应该能从中找到一些可以抄作业的东西。1. 从 Semantic Kernel 到 Agent Framework.NET AI 生态的一次范式换代1.1 Semantic Kernel 当年解决了什么问题写代码接入大模型最痛苦的不是调接口而是怎么把模型能力干净地嵌进业务系统。没有框架的时候大家普遍的做法是写一堆 Prompt 模板靠字符串拼接塞上下文再手工解析 JSON 输出。结果就是提示词和业务代码纠缠在一起模型一换整个逻辑全崩。SK 解决的就是这个问题。它提出了 Kernel 这个核心对象把模型、工具、记忆统一管理起来。开发者只需要在 Kernel 上注册一个插件函数模型就能在对话过程中通过函数调用机制决定“什么时候调这个函数、用什么参数调”。对话逻辑和业务逻辑被拆开了代码可维护性一下子高了不少。除了函数编排SK 还带来了几个关键设施。Connector 抽象了不同模型服务商的差异让项目不绑定特定厂商Memory 抽象了向量存储和检索让 RAG 场景有统一的接入方式Plugin 提供了用自然语言定义的语义函数和用代码定义的原生函数两种形态照顾了不同层次的开发者。可以说在过去两年里SK 就是 .NET AI 生态的基础设施层。大量企业项目、知识库问答系统、数据抽取流水线都是基于它搭起来的。很多团队已经把业务工具全部封装成插件就等着上层框架把它们用起来——这也是后面 Agent Framework 能顺利接盘的一个重要前提。1.2 Agent Framework 的定位变化Agent Framework 不是要“再做一个更强的 SK”而是要把开发范式从“函数编排”拉升到“智能体编排”。先说定位差异。SK 的核心概念是 Kernel、Plugin、Function开发者关心的是“怎么把一个个能力暴露给模型去调用”Agent Framework 的核心概念是 Agent、Chat Template、GroupChat开发者关心的是“怎么让一个具备角色和目标的智能体自主完成工作”。SK 的视角是功能Agent 的视角是主体。这种变化直观地反映在代码写法上。SK 时代大家习惯注册几个插件函数然后手动维护 ChatHistory一次次把历史记录发给模型Agent Framework 里你创建一个 Agent给它指令和工具列表它内部用 Chat Template 管理上下文自己决定调用顺序和调用时机。另外Agent Framework 在语言栈上刻意做了对齐。SK 本身有 .NET、Python、TypeScript 三套实现但 API 各有各的脾气到了 Agent Framework三个语言栈的抽象模型基本统一同一个 Agent 概念同样的 Chat Template 结构同样的群组协作模式。这件事对跨语言团队意义很大尤其是总部和后端分离、前端也想写 Agent 流程的团队一套思路通用三端培训成本低了很多。1.3 为什么是“继承”而不是推倒重来这里有个很关键的产品决策为什么不直接另起炉灶搞一个全新框架如果完全重写SK 这两年积累的插件生态、连接器生态和社区教程全部作废.NET 开发者等于从零学一个新东西迁移成本高到没法接受。更重要的是SK 的底层抽象——用 Kernel 统一管理模型、内存、工具——在 Agent 时代依然成立。Agent 表面上很玄乎本质上还是在“一个循环里反复调用 Kernel 来完成目标”。所以最终的做法是保留 SK 的内核在它之上做一次“向上抽象”。Kernel、Connector、Plugin 继续作为底层执行引擎Agent 架构作为更上层的开发模型。换句话说Agent Framework 不是在 SK 旁边新放了一个竞争对手而是把 SK 包进来当心脏再给它装上大脑和神经系统。这个设计思路往下看代码会更清楚。2. 继承了什么SK 沉淀下来的技术资产2.1 Kernel 和连接器体系原样保留Agent Framework 里Kernel 没有消失。你写一个 Agent底层依然要构建一个 Kernel 实例来处理模型调用和工具执行。基本结构大概是这样var builder Kernel.CreateBuilder() .AddOpenAIChatCompletion(gpt-4o-mini, apiKey) .Build();这个 Kernel 一路沿用到现在顶层的 Agent 对象内部持有它。模型连接器那一整套体系也被保留不同模型服务商的接口差异仍然由连接器层消化开发者面对的是统一的调用方式。这个继承为什么重要因为连接器层是存量项目里最容易出现定制代码的地方。很多企业内部用的不是标准模型接口而是经过网关转发、带特殊认证的端点这些基本都是通过自定义 Connector 实现的。如果框架重写时把这一层换掉存量项目的迁移量会瞬间爆炸。保留连接器体系等于给老项目留了一条稳定的迁移通道。2.2 插件系统如何演化为智能体的工具SK 最受欢迎的设计就是插件机制。开发者把一个业务功能封装成一个类用[KernelFunction]标注方法配上描述和参数说明模型就能在需要的时候自动调用。到了 Agent Framework插件没有消失只是换了个身份成为 Agent 的工具来源。你以前写的那些[KernelFunction]方法在 Agent Framework 里依然可以注册为 Agent 的工具。同一个方法两种叫法底层走的是同一套函数调用的机制。这给存量项目带来的安全感很直接不需要把已有插件全部重写只需要把它们挂到 Agent 上就能从“函数编排”升级到“智能体编排”。我见过很多团队纠结要不要迁移核心顾虑就是“重写插件太伤”。实际测试下来这一步基本是无痛的。2.3 记忆、向量与 RAG 能力继续可用RAG 是大多数 .NET AI 项目真正的核心诉求。SK 引入的 Memory 抽象——不管底层是内存向量库、Redis 还是更专业的外部索引——在 Agent Framework 里依然可用。Agent 可以在指令里写“先基于知识库回答查不到就明确说不知道”配合底层的 Memory 服务把一个单纯的 RAG 问答升级成有角色、有流程、有兜底策略的智能体。这种组合不是新瓶装旧酒。以前是你手动组织“检索 提示词拼接 生成”现在变成了 Agent 根据上下文自主决定何时检索、检索结果如何整合、检索不到时怎么回答。对知识库类应用来说这个升级体验非常直观。2.4 存量 SK 项目的兼容与迁移主线我自己对存量项目的判断是保持内核重构外层。保持内核指的是模型连接、Kernel 构建、已有插件函数这些尽量不动。重构外层指的是把原来手动调 ChatCompletion 做多轮对话、手动处理工具调用循环的逻辑改成 Agent 定义加 Chat Template 的形式。注意最省力的迁移方式不是一行行改代码而是先写一个最小的 Agent Demo 打通链路再一步步把普通函数替换成 Agent 工具。这个渐进路径第 4 部分我会展开讲。3. 超越在哪里Agent 范式的关键跃迁3.1 编排对象从函数升级到智能体这是整个演进里最本质的一条。SK 时代的代码结构是“我提供一批函数模型在需要时调用它们”。Agent 时代的代码结构变成了“我定义一个角色给它目标和边界它自己规划步骤并执行”。举个具体例子。做一个会议纪要助手。SK 的写法是准备“转写文本的插件”“提取要点的插件”“写邮件的插件”然后靠提示词约束模型按顺序调用一旦顺序没按预期走输出质量很容易崩。Agent 的写法是定义一个 Agent指令是“你是一名会议纪要助理收到转写文本后先提炼要点、再生成待办清单、最后输出固定格式的会议纪要”。Agent 内部自己决定先做什么后做什么每一步用哪些工具甚至可以在信息缺失时主动追问。开发者的重心从“设计函数调用顺序”转移到了“定义角色与边界”上。下面这张表可以快速看出两代框架的核心差异维度Semantic Kernel 时代Agent Framework 时代核心抽象Kernel / Plugin / FunctionAgent / ChatTemplate / GroupChat编排单位函数调用序列自主决策的智能体会话管理手动维护 ChatHistoryChatTemplate 内置管理多角色协作实验性支持一等公民调试手段日志加手动追踪Activity 全链路记录部署形态类库嵌入类库加托管运行时3.2 多智能体协作从单打独斗到群组作战单智能体能解决的问题始终有限。一个提示词里塞太多职责模型很容易顾此失彼长对话场景下上下文越滚越长 Agent 越到后面越“健忘”。Agent Framework 引入了 GroupChat 模式允许定义多个 Agent每个 Agent 专注一个角色然后把它们放进一个群组协作。典型配置是“一个协调者加若干专家”。协调者负责任务拆分、信息汇总和最终回复专家负责接收自己的子任务输出领域结果。GroupChat 内部管理消息流转和会话历史开发者也可以自定义每轮由哪个 Agent 发言。这个能力吸收了研究侧多智能体协作的成果。SK 时代虽然也有一些群聊实验代码但到了 Agent Framework多智能体协作成了核心卖点API 设计和运行时支持都成熟了很多。对 .NET 开发者来说以前需要自己拼装的多 Agent 框架现在有了官方支持的落地方案。3.3 可观测性Activity 全链路记录多智能体系统的调试比单体应用痛苦得多。一次任务流程可能跨多个模型调用、多次工具执行、多轮 Agent 间消息出错时根本不知道问题出在哪一步。Agent Framework 为此引入了统一的 Activity 跟踪机制每一次模型调用、每一步工具执行、每一条 Agent 间消息都会产生一条记录带完整时间、调用参数、输入输出。这套机制可以对接现有的链路追踪体系把整个 Agent 运行流程可视化。我在排查问题时基本不看乱糟糟的日志直接看 Activity 列表里哪一步的输入输出异常定位速度快很多。对刚接触 Agent 开发的人来说这可能比任何 API 特性都更早派上用场。3.4 从“类库”到“托管运行时”SK 本质是一个类库你把它包进自己的进程它帮你完成模型编排。但 Agent Framework 的野心不止于此它定义了一套 Agent 运行时的标准支持把智能体部署到云端的托管服务。这意味着同一个 Agent 代码可以跑在本地进程里做调试也可以部署到云端作为独立服务通过统一协议对外提供能力。这个变化的影响很深。以前每个团队自己搭 Agent 服务API 风格不一、监控靠写日志、扩容靠手写脚本托管运行时把生命周期、健康检查、入参出参都标准化了。对 .NET 后台开发者来说这相当于在框架层面把“智能体”当成了一种标准化的后台服务产品来治理。4. 落地实操从 SK 迁移到 Agent Framework 的示例与避坑指南4.1 基础问答 Agent两套代码风格对比先看一段 SK 风格的最简问答代码var builder Kernel.CreateBuilder() .AddOpenAIChatCompletion(gpt-4o-mini, apiKey); var kernel builder.Build(); var chat kernel.GetRequiredServiceIChatCompletionService(); var history new ChatHistory(你是一个乐于助人的助手。); history.AddUserMessage(给我介绍下 .NET 8 的 AOT 特性。); var reply await chat.GetChatMessageContentAsync(history); Console.WriteLine(reply);这段代码很直观初始化 Kernel、拿聊天服务、手动维护历史、取结果。到了 Agent Framework同样功能可以写成这样API 以当前发布版本文档为准我只展示结构差异var builder Kernel.CreateBuilder() .AddOpenAIChatCompletion(gpt-4o-mini, apiKey); var chatTemplate new ChatTemplate() .WithSystemInstruction(你是一个乐于助人的助手。); var agent new ChatAgent.Builder() .WithKernel(builder.Build()) .WithChatTemplate(chatTemplate) .Build(); var response await agent.AsInteractiveAsync().SendAsync( 给我介绍下 .NET 8 的 AOT 特性。, CancellationToken.None); Console.WriteLine(response.Text);两段代码看着差不多区别在结构上系统指令变成了显式配置的 Chat Template一次对话变成了 Agent 的一次交互。简单场景看不出多大优势但一旦涉及工具调用、多轮上下文切换、多 Agent 协作这种结构化的好处就会成倍放大。4.2 把已有 SK 插件升级为 Agent 工具假设我在 SK 里已经有这样一个查询天气的插件函数public class WeatherPlugin { [KernelFunction] [Description(查询指定城市的当前天气)] public string GetWeather( [Description(城市名)] string city) { // 内部调用气象服务 return 晴25°C; } }在 Agent Framework 中这个函数不需要重写只需要把插件挂到 Agent 上var kernel builder.Build(); kernel.Plugins.AddFromTypeWeatherPlugin(Weather); var agent new ChatAgent.Builder() .WithKernel(kernel) .WithChatTemplate(chatTemplate) .Build();注意AddFromType依然是从 SK 继承下来的 API。它自动读取方法上的[Description]和参数上的[Description]生成模型能识别的工具定义。以前在 SK 里认真写的那些注释现在直接变成了 Agent 的能力描述。这也是我前面说“插件系统是 SK 留下的优质资产”的原因。4.3 多智能体协作的配置要点多 Agent 场景比单 Agent 复杂在消息怎么流转。以 GroupChat 为例简化配置大概是var coordinator new ChatAgent.Builder()...Build(); var analyst new ChatAgent.Builder()...Build(); var reporter new ChatAgent.Builder()...Build(); var groupChat new GroupChat.Builder() .WithAgents(coordinator, analyst, reporter) .Build(); var result await groupChat.RunAsync(userPrompt, cancellationToken);配置上有两个要点。第一每个 Agent 的指令必须写清楚“什么时候该说话、什么时候不该说话”。群聊里如果两个 Agent 职责边界模糊会出现反复抢话或互相踢皮球这比单 Agent 的提示词质量更影响最终结果。第二群组会话的终止条件要提前设计比如“协调者收到专家结果后输出总结并结束对话”。否则模型很容易一路闲聊下去token 成本完全失控。4.4 迁移路上我踩过的坑这些经验都是实测出来的常规文档里不太会写。第一不要指望 Agent 靠一段提示词解决一切。Agent 是降低了编排复杂度不是降低了提示词要求。恰恰因为有了更大的自主权指令里的角色、边界、输出格式反而要想得更细。我见过不少项目“升级”到 Agent 后效果反而变差最后都在指令上补了很久。注意Agent 范式不等于提示词可以随便写。相反Agent 的自主性越强对角色边界、输出规范和终止条件的定义要求就越高。第二token 消耗会肉眼可见地上涨。多智能体协作、工具调用、状态管理都意味着更多上下文。上线前务必做 token 成本估算尤其是群聊场景长会话累积下来的开销很吓人。可以在对话轮次上做限制定期清理无关历史。第三调试时优先看 Activity而不是自己打日志。多 Agent 协作场景里每个 Agent 的输入输出都以 Activity 形式记录直接看事件的输入输出字段能快速定位是哪一步的数据出了问题。自己写日志排查信息碎片化严重效率极低。第四迁移不要追求一步到位。先把一个最核心的场景用 Agent 重写跑通之后看效果再扩大范围。一次把所有旧代码改成 Agent 结构失败概率很大而且容易把问题归咎于框架本身。4.5 一套稳妥的渐进迁移流程给一个可以直接参考的流程梳理现有 SK 项目的插件清单和功能边界分清哪些适合保留为 Agent 工具哪些逻辑可以被 Agent 指令替代。搭建最小 Agent 示例把最核心的问答场景跑通验证模型通道和工具调用链路无误。把第一批插件注册为 Agent 工具设置系统指令跑一批真实业务请求对比新旧两套代码的输出质量和耗时。输出质量稳定后再引入 GroupChat 等协能力处理跨步骤的复杂任务。最后统一处理可观测性把 Activity 接入团队现有链路追踪系统让 Agent 逐步替换旧管道。这套流程慢是慢一点但对生产系统最稳。技术选型上的激进应该体现在“小范围验证、快速试错、快速回滚”而不是“全量切换”。5. 战略整合的深层逻辑与影响范围5.1 为什么 AI 框架需要统一运行时先把视角拉高。Agent Framework 出现之前市面上的 Agent 框架确实有些碎片化有侧重企业集成的有侧重研究型多智能体的还有一堆社区项目。对 .NET 开发者来说选择过多反而是负担学一个框架的时候另一个又出了新概念项目里用了这个团队里别人用的是那个协作体验很割裂。统一运行时的价值在于学习成本收敛到一条线社区经验可以跨项目复用云服务只需要适配一套标准就能服务所有用户。把 SK 的 Kernel 作为底层、Agent Framework 作为上层既保住了已有的生态积累又定义了 Agent 时代的统一标准。我个人认为这对 .NET 生态尤其重要。过去 .NET 在 AI 领域的存在感比 Python 世界弱一个重要原因是缺少一个统一且有份量的框架。Agent Framework 至少让 .NET 在 Agent 开发上有了正面竞争的底气。5.2 对现有项目和团队技能栈的影响对已经在用 SK 的项目来说底层基础设施没有变但框架的重心会明显向 Agent 方向倾斜。新功能、新连接器、新的最佳实践大概率会优先出现在 Agent Framework 路径上SK 单独使用的场景会慢慢收窄。对团队来说建议尽早把 Agent 开发纳入技能规划。原来熟悉 SK 的成员迁移到 Agent Framework 的学习成本不高核心概念是平移的但完全没有 SK 基础的团队直接上手 Agent Framework 会吃力因为底层很多抽象还是 SK 那一套。从 SK 入手再进入 Agent Framework是更顺畅的学习曲线。5.3 生态位重构.NET 在 AI 应用层的新位置这次整合背后有一个更大的趋势.NET 在 AI 生态里的位置正在从“模型调用库”向“应用层运行时”移动。以前 .NET 开发者做 AI 应用主要工作是“把模型接口封装到业务系统里”现在有了 Agent Framework.NET 的价值变成了“承载智能体的运行和协作”。这跟后台开发者的既有技能高度重合并发、部署、可观测性、服务治理本来就是 .NET 后台团队的看家本领。Agent Framework 把这个优势跟 AI 应用直接接上了让 .NET 开发者不必改换语言栈也能做完整的 Agent 服务。往长远看这类框架会跟云上的托管服务形成更紧密的组合。本地用同一套 Agent 代码调试部署时直接享受托管运行时的弹性、监控和治理能力这种“本地开发加云端托管”的模式很可能会成为企业级 Agent 应用的标准形态。提前掌握 Agent Framework 的 .NET 团队接下来在企业 AI 应用落地中会占一个比较主动的位置。5.4 给 .NET 开发者的行动建议最后给几条务实的建议。如果还没接触过 SK不要跳过它直接学 Agent Framework。至少要把 Kernel、Plugin、函数调用机制这三个概念弄清楚它们是理解 Agent 底层机制的基础。找一个真实业务场景练手比如把内部的知识库问答、工单分类这类任务用 Agent 模式重写一遍。光看文档记不住动手踩过坑才有体感。关注框架的示例仓库和发布说明。Agent Framework 迭代速度很快API 有可能变动建议以当前版本文档为准不要盲目照抄旧博客里的代码。同时警惕过度设计不是所有功能都需要做成多智能体单 Agent 加工具调用往往已经能解决问题在引入群聊之前先确认业务确实需要多个角色协作和上下文隔离。还有提前思考线上运维。Agent 应用最怕线上出错没法定位从第一天就把 Activity 监控、日志、成本统计接好后面会省很多事。框架可以换数据资产和运维体系不会白搭。写了这么多落到最真实的体感上其实是两句话。第一Agent 指令的权重比预想的高得多。同样的工具、同样的模型指令写得好与不好跑出来的效果可以是天壤之别这东西没有捷径只能反复迭代。第二这次重构真正有价值的地方不在多了一堆新 API而在于它把多智能体协作从研究概念变成了 .NET 开发者可以日常使用的工程能力。对我这个长期写后台服务的人来说框架叫什么名字不重要重要的是它有没有把复杂度从开发者手里真正接走。从这个角度看这次演进的方向是对的。