1. 从 Semantic Kernel 到 Agent Framework一次不得不做的架构转身先交代一下背景。过去两年我在几个中大型项目里深度使用了 Semantic Kernel以下简称 SK从最早的 1.0 预览版一路跟到后面的稳定版本。SK 解决了一个很实际的问题让 .NET 开发者不用从头造轮子就能把大模型接进业务系统。那时候我写过不少基于 SK 的插件、规划器、记忆模块也确实感受到了用 C# 调大模型这件事从别扭到顺手的过程。但最近大半年我明显感觉到一件事SK 在单轮对话、单任务执行的场景里很顺手一旦进入多智能体协作、动态任务编排、跨系统自主决策这类复杂场景它的抽象层次就开始不够用了。这不是 SK 本身写得不好而是它的设计重心从一开始就偏向了模型接入和基础编排而不是智能体之间怎么合作、怎么竞争、怎么交接。所以当 Microsoft Agent Framework下文简称 MAF出现的时候我的第一反应不是又一个新框架而是微软终于把缺的那块拼图补上了。这篇文章我想从一个实际使用者的角度聊聊 MAF 对 SK 的继承、超越以及微软这次战略整合背后真正的逻辑。不是官方文档的复述更多是过去几个月用下来的真实体感。2. 先盘一盘Semantic Kernel 到底留下了什么家底要理解 MAF 为什么不是凭空冒出来的得先搞清楚 SK 做了哪些奠基工作。SK 在我看来最有价值的不是某个具体 API而是它确立的一套关于AI 应用怎么组织的心智模型。2.1 插件抽象把业务能力翻译成模型能理解的语言SK 最早让我眼前一亮的是它的插件Plugin机制。你可以把一个 C# 方法标注成语义函数或者原生函数然后模型就能通过自然语言调用它。这个设计本质上是在做一件事把企业的现有代码资产变成大模型可以感知和操作的工具。我举个实际例子。之前做一个内部知识库问答系统我们需要让模型能够查询权限范围内的文档、调用审批接口、记录用户行为。用 SK 的插件机制这几件事分别封装成三个原生函数每个函数都写清楚输入输出描述。模型在推理的时候会根据用户意图自动选择调用哪个函数。这套机制后来成了整个系统最稳定的部分。SK 的插件抽象有几个关键设计值得记住语义描述优先函数的描述信息比函数实现本身更重要因为模型是通过描述来理解何时调用它的。参数标准化所有参数必须是 JSON 可序列化的这保证了模型输出与代码调用之间没有摩擦。插件即组合单元一个插件可以包含多个函数多个插件可以组合成完整的业务流程。2.2 规划器与记忆SK 在单智能体时代的探索SK 里另外两块重要资产是规划器Planner和记忆Memory。规划器解决把复杂任务拆成多步执行的问题记忆解决对话过程中的上下文怎么存、怎么取的问题。老实说SK 的规划器一直不太成熟。早期版本我试过用手写规划器让模型自己生成执行步骤理想很丰满但实际跑起来经常出现步骤顺序错乱、函数调用参数幻觉等问题。后来 SK 转向了函数调用风格的自动规划稳定性才上来一些。这条探索路径踩的坑直接影响了 MAF 的设计——后续 MAF 不再追求让模型自由规划而是通过更结构化的方式定义智能体的行为边界。记忆模块倒是做得不错尤其是记忆向量的存储和检索设计。SK 支持内存向量存储和外部向量数据库两种模式做 RAG 类应用的时候很方便。这个能力后来也被 MAF 完整继承了而且做了进一步的抽象。2.3 .NET 生态的连接器文化SK 还有一个不太被重视但非常重要的遗产它确立了一套连接器的设计模式。无论是模型接入、向量数据库接入还是其他外部服务SK 都倾向通过配置文件加适配器的方式来解决。这种一切皆可替换的架构哲学让 .NET 生态在 AI 领域的集成能力得到了极大扩展。我用 SK 接过的模型就有 OpenAI、Azure OpenAI、本地部署的开源模型甚至还有几个国内厂商的模型服务。切换的过程基本是改配置、换适配器业务代码几乎不用动。这个经验告诉我微软做框架的思路一直很明确核心抽象要稳定外围接入要灵活。这个思路在 MAF 里被进一步加强了。3. Agent Framework 到底新在哪里从工具调用到智能体协作MAF 出来后我最关心的是它和 SK 的本质区别。用一句话概括我的理解SK 解决的是让模型能调用工具MAF 解决的是让多个智能体像一个团队一样工作。3.1 智能体作为一等公民生命周期与状态管理SK 里其实也有 Agent 的概念但那时候它更像是模型插件记忆的封装组合。而 MAF 把智能体提升到了核心抽象层每个智能体都有完整的生命周期创建、运行、暂停、恢复、终止。我记得第一次在 MAF 里创建智能体时被它的初始化配置吓了一跳模型选择、系统提示词、工具列表、记忆配置、行为策略全部是独立配置项。这种设计让智能体不再是散落的代码片段而是可以被独立部署、独立测试、独立运维的实体。更重要的是MAF 对智能体状态的持久化做得非常到位。我之前用 SK 做多轮对话最头疼的就是对话状态管理——要么自己写内存缓存要么借助外部数据库做序列化但总感觉不稳。MAF 自带的状态持久化机制解决了这个痛点智能体的完整状态可以序列化保存恢复后可以无缝继续执行。3.2 协作机制不只是消息传递还有任务分配与仲裁这是 MAF 真正超越 SK 的地方。在 MAF 里多个智能体之间可以通过消息进行协作但这种协作不是简单的你问我答而是包含了一整套任务分配、进度同步、结果仲裁的机制。我做了个模拟项目 X一个客户服务系统包含一个调度智能体、一个工单处理智能体、一个知识库查询智能体和一个售后回访智能体。调度智能体收到用户问题后先判断问题类型然后把任务分发给对应的处理智能体。处理智能体在过程中需要查询知识库时又会向知识库智能体发起请求等结果返回后再继续自己的工作。这套协作流程在 SK 里用规划器也能做个七八成但有两个根本问题解决不了并发控制SK 里的函数调用是线性的一个函数执行完才能执行下一个。但 MAF 里的智能体是可以并行运行的它们通过消息通信来协调节奏。失败隔离SK 里一个函数出错了整个链路就断了。MAF 里某个智能体出错了其他智能体还能继续工作调度智能体可以重新分配任务或者降级处理。我在对比测试中深有体会同样的多步骤任务用 SK 实现时一旦中间步骤不稳定整体失败率会指数上升而 MAF 因为每个智能体的失败都是局部的整体成功率反而更稳。这一点对于生产级系统来说太重要了。3.3 群体智能从编排到涌现MAF 有一个我很喜欢的特性支持智能体群体的动态创建和任务自适应分配。不是说所有任务都要预先定义好流程而是有些场景可以让智能体自行协商怎么分工。打个比方SK 时代我们写的是指挥家模式——所有智能体听统一调度MAF 则可以支持即兴乐队模式——多个智能体在一个安全边界内自由沟通、互相协商、共同完成任务。当然这种自由是有约束的。MAF 允许你为群体设置协作策略哪些智能体之间可以通信、哪些不可以任务分配的优先级怎么定义信息共享的范围边界在哪。这个有约束的自治设计我认为是 MAF 最务实也最有创造力的部分。4. 战略整合的深意为什么不是 SK 的升级版而是新的框架接触 MAF 之后我一度以为它就是 SK 的 2.0。但实际用了才发现两者的定位差得很远。微软为什么不直接升级 SK 而是推出新框架我理解有几个层面的原因。4.1 抽象层次完全不同SK 的抽象层次是模型-函数-记忆MAF 的抽象层次是智能体-群体-协作。这是两种不同的问题域。SK 解决的是如何让 AI 完成一个具体任务MAF 解决的是如何设计一个 AI 团队来持续解决一类问题。后者包含前者但又远不止于此。比如 MAF 中一个智能体本身内部可能就用到了类似 SK 的插件机制但多个智能体之间的交互逻辑是全新的抽象层。强行在 SK 上叠加这些能力会导致 API 和架构异常臃肿最终反而失去了框架的清晰性。4.2 生命周期策略不同SK 的设计是面向开发期的——你写代码、调接口、跑通流程。而 MAF 明显是面向运行期的——考虑的是智能体上线后怎么管理、怎么监控、怎么更新。MAF 里我比较赞赏的是对智能体运行时的建模它不是一个一次性的执行过程而是一个可以长期存活、不断感知环境、持续做出行动的实体。这带来了一系列 SK 从未考虑过的问题智能体之间的通信怎么监控任务执行到一半如果模型响应异常要不要回滚智能体的决策记录要不要审计这些在 MAF 里都有了明确的设计。4.3 生态位互补而非替代我现在的判断是SK 和 MAF 会长期共存走互补路线。SK 适合构建具体的 AI 能力模块比如一个语义检索插件、一个文档生成工具MAF 适合把这些模块组织成完整的智能体系统。微软的整合策略其实就是让两者形成一条完整的技术链路底层用 SK 的能力做具体实现上层用 MAF 做智能体编排和协作治理。这样既能保护 SK 生态已有的积累又能把 .NET AI 的能力边界推到更高的层次。5. 从零到一搭建一个 MAF 多智能体系统的完整过程说了这么多框架层面的理解来点实操的。我基于 MAF 做了一个多智能体的项目管理系统用来处理一个内部的需求收集-方案评审-任务分解-进度跟踪流程。这里我完整复盘一下搭建过程包括中间踩过的坑。5.1 环境准备与项目初始化先交代一下环境.NET 8 SDKVisual Studio 2022 或者 Rider 都行我用的是命令行加 VS Code 的组合。MAF 目前作为独立的框架通过 NuGet 包引用。dotnet new console -n AgentTeamDemo cd AgentTeamDemo dotnet add package Microsoft.Agent.Framework初始化后需要配置模型服务。MAF 支持 OpenAI 协议我用的是一套兼容 OpenAI 接口的本地代理服务这样切换模型比较方便。在appsettings.json里做基础配置{ Model: { Provider: OpenAICompatible, Endpoint: http://localhost:8080/v1, ApiKey: local-dev-key, DefaultModel: deepseek-chat, Temperature: 0.2 }, Agent: { DefaultMemoryStore: InMemory, DefaultStateStore: FileSystem, StateDirectory: ./agent_states } }一个容易忽略的细节Temperature在智能体场景下我建议调低。因为协作过程中需要稳定的决策输出过高会让智能体表现得太有创意导致任务执行不连贯。0.2 左右是实测比较稳的值。5.2 定义四个智能体的角色与行为边界我为核心流程定义了四个智能体每个的职责边界必须清晰否则协作时会互相抢任务或互相推诿。需求收集 Agent负责与用户对话理解需求输出结构化需求文档。它的行为边界是只做需求澄清不做方案设计。方案评审 Agent接收需求文档调用内部工具检索历史方案库输出评审意见和初步方案。任务分解 Agent把评审通过的方案拆解成可执行的任务项并估算优先级。进度跟踪 Agent监听任务看板更新进度异常时通知相关人。创建智能体的核心代码大致如下var demandAgent AgentBuilder.Create() .WithName(需求收集Agent) .WithSystemPrompt(你负责与用户对话收集并澄清需求。) .WithModel(deepseek-chat) .WithTool(new DemandStructuringTool()) .Build(); var reviewAgent AgentBuilder.Create() .WithName(方案评审Agent) .WithSystemPrompt(你负责评审需求方案参考历史方案库给出建议。) .WithModel(deepseek-chat) .WithTool(new HistorySearchTool()) .WithTool(new RiskAssessmentTool()) .Build();有个很重要的细节系统提示词必须写清楚什么情况下应该拒绝执行。比如需求收集 Agent 的提示词里我明确加了当用户表达的需求超出业务范围时应明确告知并请用户调整。能力边界不写在提示词里智能体就容易过度承诺这在后期非常危险。5.3 定义协作流程消息模型与任务分发策略这部分的体验和 SK 完全不同。MAF 里智能体之间的通信是显式的消息对象消息可以携带任务数据、结果数据和元信息。var collaboration CollaborationBuilder.Create() .AddAgent(demandAgent) .AddAgent(reviewAgent) .AddAgent(taskSplitAgent) .AddAgent(progressAgent) .DefineWorkflow(workflow { workflow.Start(demandAgent) .OnSuccessSendTo(reviewAgent) .OnCondition(result result.IsApproved(), sendTo: taskSplitAgent, failure: sendTo: demandAgent); });这里的核心思想是流程是显式定义的但执行过程中的分支判断是智能体自主完成的。任务是否通过评审不是预先写死的逻辑而是评审 Agent 根据实际方案内容做出的决策。这样的设计兼顾了流程的可控性和决策的灵活性。另外一个实用的设计是超时和降级。比如方案评审 Agent 如果 30 秒没有返回结果调度器会自动切换到一个简化评审模式保证流程不被阻塞。这在 SK 时期基本上要自己手写很多胶水代码。5.4 群体记忆让智能体共享上下文而非各自为战多智能体系统最大的坑之一就是上下文割裂。四个智能体各自只知道自己参与的那一段对话整个流程的关联信息很容易丢失。MAF 的群体记忆机制解决得不错。你可以定义一个共享记忆域多个智能体都可以访问var sharedMemory MemoryNamespace.Create(project-001) .WithVectorStore(new InMemoryVectorStore()) .WithEntityStore(new FileSystemEntityStore()) .Build(); demandAgent.AttachMemory(sharedMemory); reviewAgent.AttachMemory(sharedMemory);共享记忆里存了两类数据一类是结构化实体数据比如需求编号、业务领域、优先级另一类是向量数据比如需求描述的嵌入向量。实体数据方便精确查询向量数据方便相似性分析。两者配合智能体就能在协作过程中准确读取到前置环节的产出。5.5 实测表现与踩坑记录整个系统跑起来后我做了几轮端到端测试。基本流程走得通但有几个坑必须记录一下坑一模型并行调用导致的服务端限流。多个智能体同时跑每个可能都需要调用模型接口瞬时并发请求量会拉高。我的做法是在框架层做了简单的信号量控制限制同时进行的模型调用不超过 5 个实测稳定了很多。坑二系统提示词语义冲突。有一次我把不要臆造不存在的功能写进了方案评审 Agent 的提示词但同时又在它的工具描述里允许了当方案不完整时可以补充建议。结果模型经常一边说不臆造一边又疯狂补建议行为非常分裂。后来我意识到每个约束性和允许性的提示词必须放进一个统一的优先级规则里冲突会导致模型行为失控。坑三状态序列化后的模型字段缺失。MAF 的状态持久化在二次读取时偶尔出现个别智能体字段丢失的情况。排查下来发现是自己定义的数据模型没有标记为[JsonInclude]。加了对私有字段的序列化声明后问题没有再出现过。这个提醒了我们使用框架的自定义扩展点一定要仔细看序列化约束。这些坑单看都不复杂但叠加起来在调试时会很消耗时间。建议大家在做多智能体项目时第一步不是写业务流程而是先做好可观测性把每个智能体的输入、输出、决策记录都完整打点后续排查问题会省力得多。6. MAF 落地到生产环境之前你需要想清楚的几件事框架能跑起来和能上线是两个概念。如果你打算把 MAF 用到真实业务里下面这些点值得提前权衡。6.1 成本与延迟多智能体不等于免费午餐多智能体系统比单智能体调用模型要贵得多原因很简单一次协作任务可能涉及多次模型调用每次都要消耗上下文 token。还是我那套客户服务系统。一个简单的问题在 SK 时代一次函数调用就解决了在 MAF 时代可能需要调度 Agent 先理解一次、任务 Agent 再处理一次、知识库 Agent 再查一次。总的模型调用次数翻了三四倍单次任务响应时间也从 2 秒变成了 5-8 秒。这不是说 MAF 不好而是说多智能体协作应该用于值得的场景。复杂任务、需要多领域知识协同、需要分阶段决策的业务才值得付出这个成本。简单任务用多智能体是给自己找麻烦。6.2 可观测性与调试多智能体系统的断点在哪SK 时代的调试相对简单你可以在函数调用处打断点查看输入输出。MAF 时代你面对的是分布式式的协作过程传统的打断点方式很难用。我的建议是三层观测消息级日志记录所有智能体之间的消息传递包括消息类型、发送方、接收方、内容摘要。决策级日志记录每个智能体关键的决策点比如为什么把任务分给了 A 而非 B。状态级快照定期保存智能体群体状态出问题时可以回放。MAF 提供了一些内置的监听接口可以钩住智能体的生命周期事件。我用了之后很快就发现了之前隐蔽的问题有一次需求收集 Agent 和方案评审 Agent 因为同一个词的定义不一致互相踢了三次皮球如果没有决策级日志这个问题几乎不可能定位。6.3 安全边界与权限模型智能体不能想做什么就做什么多智能体系统一个容易被忽略的安全问题工具的调用权限应当继承自发起任务的用户而不是智能体自身。如果一个普通用户通过需求收集 Agent 提出了查询全部客户数据的需求而后续 Agent 的工具有全部数据权限那等于天然产生了一个提权漏洞。MAF 允许在消息中携带身份上下文我建议在工具调用层做统一校验public class PermissionFilter : IAgentToolFilter { public bool CanInvoke(AgentToolContext context, CancellationToken ct) { var userRole context.MessageMetadata[user_role]; var toolRequiredRole context.Tool.RequiredRole; return userRole toolRequiredRole; } }这个过滤逻辑看着简单但对于生产环境的意义非常大。没有这一层你和用户聊得再飞底层数据安全也始终是悬着的。7. 微软整合背后的技术路线判断.NET AI 生态的下一个五年最后聊一点我对整个生态趋势的判断。微软近年来的 AI 框架布局表面上是多个产品并行实际上已经形成了一条完整的路线图。7.1 从代码优先到智能体优先SK 时代.NET 开发者接触 AI 的方式是写代码去调用模型。MAF 时代这个关系反过来了你首先设计智能体然后配置它、装备它、让它在边界内自主行动。代码不再是一切的中心而是智能体的器官。这个转变很像从单体架构到微服务架构的演进以前我们写一个大应用现在我们编排一组服务。编程思维从实现逻辑转向定义边界与交互。7.2 从单点能力到群体能力单智能体再强也只能解决单领域的问题。真实的业务系统往往是跨领域的客服需要懂业务、懂产品、懂流程项目管理需要懂需求、懂技术、懂风险。MAF 的思路是把每个领域的专业知识封装成独立的智能体然后让它们协作形成一个覆盖整个业务域的智能体网络。这个模式的潜力很大但挑战也很大。智能体之间的信任问题、信息一致性问题、冲突消解问题目前框架只提供了机制真正的治理规则还得业务侧自己定。这也是未来 .NET AI 落地时架构师要花大量精力去思考的地方。7.3 我对框架选型的一个实操建议写了这么多我给还在犹豫的 .NET 开发者一个相对实际的建议如果你的需求是做一个带 AI 能力的工具比如文本总结、文档问答、代码生成直接用 Semantic Kernel 就够了它轻量、灵活、好调试。如果你的需求是做一个 AI 业务系统比如自动化的客服流程、智能化的项目协作、多角色参与的审批系统可以直接考虑 MAF它提供的协作抽象和多 Agent 治理机制会省掉大量自研胶水代码。如果你已经有了 SK 项目没必要急着迁移。SK 项目可以先沉淀出插件和工具层未来要升级 MAF 时把插件层直接对接给 MAF 的智能体工具即可迁移成本并不高。我自己的计划是后续新项目如果预期会有多角色的 AI 参与会直接以 MAF 作为主框架SK 则在底层作为能力组件继续使用。两个框架的边界在我这里越来越清晰。8. 实践之后的一点个人体会这个架子我陆续用了一个多月最大的感受是MAF 不是一个更好用的 SK而是一个不同层级的框架。如果你带着 SK 的使用习惯去套 MAF会处处觉得别扭但如果你先接受智能体协作这套设计哲学很多 SK 时期要自己造的轮子MAF 已经帮你造好了而且造得更稳。印象最深的一次是模拟项目群里五个智能体各自分工、互相催促进度、遇到问题自动抛给其他智能体处理的画面。那一刻我意识到.NET 生态在 AI 领域的竞争点已经变了以前拼的是谁的抽象更优雅现在拼的是谁能承载更复杂的人机协作形态。当然MAF 也不是没有短板。它的学习曲线不低尤其是协作策略和状态持久化这块官方文档的深度还不够运行时资源消耗也偏高容器化部署时要给足内存。但这些更像是新框架成长过程中的正常状态。至少从目前的迭代节奏看微软对 MAF 的投入是认真的。如果你有扎实的 SK 基础现在开始接触 MAF会是一个非常平滑的过渡。但如果你 SK 也用得不多我建议直接上手 MAF同时理解插件层面的基础能力这两者组合起来差不多就是 .NET AI 开发的下一个主流姿势。