微软结束AI框架之争焦点转向核心问题既然微软为AI框架之争画上了句号那么焦点就转移到了真正重要的事情上上下文、恢复逻辑以及判断你是否真的需要一个智能体。图片来源bluestork - shutterstock.com在过去一年里我几乎和每个启动AI项目的团队都进行过同样的对话。我们应该基于Semantic Kernel、AutoGen还是Foundry来构建呢起初这感觉像是我们要做出的最重要的架构决策。每个框架都有自己的理念都承诺成为企业AI的基石选错似乎会是代价高昂的错误。我花了很多时间帮助团队权衡利弊。现在回首我觉得我们问错了问题至少我自己是这样。我看到团队花了几个月时间争论SDK却忽略了那些真正决定其应用程序能否在生产环境中存活的决策。有些团队为工作流构建了复杂的编排层而其实几个确定性的函数就能搞定。还有些团队完全避开了智能体框架后来却发现自己把设计陷入了死胡同。然后微软替我们做了决定。它推出了统一的智能体框架Agent Framework悄然将Semantic Kernel和AutoGen转为维护模式我花了几个月时间调解的这场争论突然就结束了。原来“三选一”的答案是“三个都不是这里有第四个”。该框架于2026年4月达到1.0版本并全面可用在.NET和Python环境中都很稳定。让我惊讶的不是这个决定而是一场耗费了我们大量精力的争论这么快就变得无关紧要了。微软换了菜单但没改变菜品。框架从来都不是难题在关于企业智能体的早期讨论中框架选择几乎占据了主导。我们应该以哪个SDK为标准哪种编排模型能给我们最大的灵活性微软实际上押注的是哪个这些问题都很合理。但在观察这些项目开展了一年后我慢慢有了不同的看法。这些问题并不能决定什么。我现在首先问的问题要小得多这个东西真的需要智能体吗这听起来显而易见可我有时还是会搞错而且这也是我最常看到的错误。有一个项目中一个团队花了数周时间为一个每次都执行相同四个步骤的流程设计多智能体工作流读取文档、验证文档、调用API、发送通知。设计图看起来很棒但生产环境中的系统却不尽人意。几个经过充分测试的函数会更易于构建、维护也更值得信赖。部分原因在于“智能体”成了大家常用的词汇。有时候它是正确的选择但有时候它只是给我们已经知道如何构建的工作流贴上了新标签。只有当智能体真的需要决定那些无法预先确定的事情在工具之间做出选择根据发现进行调整自行规划下一步时它的复杂性才是值得的。如果你已经知道每一步那你有的就是一个工作流而工作流通常是更好的工程选择。框架的整合并没有改变这一点只是让它更容易被看清。构建生产智能体带给我的启示当我不再执着于框架时同样的三个问题不断出现而且都与SDK无关。上下文比模型选择更重要早期我花了很多时间比较模型就像在餐厅对着菜单纠结最后还是点了常吃的那道菜。现在我大部分时间都在思考上下文这没那么有趣但实用得多。我见过优秀的模型失败原因是给它们的信息太多而不是太少。我曾合作过的一个团队基于信息越多答案越好的理论让模型访问了几乎所有内部文档。结果却适得其反响应变慢一致性变差有时还会直接跳过真正重要的内容。当我们把上下文缩减到任务所需的范围时质量几乎立刻就提升了。这是我没预料到的它让我对“把所有东西都给它”这种做法持怀疑态度。我参与过的最佳智能体系统不是那些上下文窗口最大的而是那些能谨慎控制哪些信息在何时传递给模型的系统。这可不是框架能提供的。故障处理才是真正的工作所在大多数智能体演示看起来很棒因为它们都是围绕理想情况构建的。但生产环境可不会这么友好。我记得有个项目测试时一切正常。但在智能体完成了几个前期步骤后下游API超时了。我们不能直接重启因为部分业务流程已经执行。最终我们在恢复逻辑上花费的时间远远超过了在提示词上花费的时间。那个项目改变了我对这项工作的看法。难点从来都不是让模型做决策而是确保当现实不按剧本发展时系统不会崩溃。工具调用中途失败API返回不一致的数据模型因为上一个答案不符合要求而反复调用同一个工具这些都不是例外情况而是日常常态。是重试、回滚、等待人工干预还是带着部分结果继续推进这是需要做出的判断没有哪个框架能替你做决定。身份是真正的安全边界这一点最让我惊讶。当智能体不再只是聊天机器人开始接触真正的业务系统时身份比编排更重要。每个项目最终都会面临同一个问题这个智能体实际上代表谁在行动是开发者的凭证、服务账户还是提出请求的用户如果搞错了你就构建了一个拥有超出任何人应有权限的自主系统这种系统在审计前看起来一切正常。和大多数现代工具一样智能体框架通过模型上下文协议Model Context Protocol等标准让智能体与工具的连接变得更容易这有一定帮助。但人工审批的位置、哪些需要额外授权、给系统多大的操作空间这些仍需你自己决定。挑战并非技术层面我没想到的是去年最困难的部分根本不是技术问题而是组织层面的问题。团队一听到“智能体”每个人的期望就都变了。业务相关方开始期望实现完全自主开发者则认为它能解决任何问题。在我们还没确定要解决什么问题时人们就开始为灵活性进行设计。这个词在代码编写之前就造成了影响。我发现自己花在重置期望上的时间和讨论架构的时间一样多。为变革而构建而非为当下的赢家我不认为去年陷入困境的团队选错了框架。Semantic Kernel合理AutoGen也合理Foundry在很多情况下也说得通。换作是我也会认可其中任何一个。那些受到影响的团队把所有鸡蛋都放在了一个框架里将其视为整个系统的基础而不是一个普通的依赖项。微软提供了迁移路径但那些将应用程序与特定框架抽象紧密耦合的团队发现迁移和重写不是一回事。这不是微软的问题而是他们自己的架构问题。那些能够轻松过渡的团队将业务逻辑、提示词和编排设计得足够灵活以便能独立于任何一个SDK进行演进。对他们来说变革是一个可管理的项目而不是彻底推倒重来。说句实在话和我共事的人都没把这当成紧急情况。大多数人先迁移较小的工作负载观察其表现在真正理解新的抽象概念之前不会动关键生产系统。这是正确的直觉。我怀疑这不是我们看到的最后一次整合这个生态系统还很年轻框架会不断相互融合随着时间推移它们之间的差异将更多体现在操作层面而非架构层面。说实话我并不后悔参与框架之争当时那些争论是合理的。改变的不是微软的路线图而是我的看法。观察这些系统在生产环境中的运行让我明白框架是最容易替换的部分。恢复逻辑、上下文管理、安全边界以及业务工作流本身在今天的SDK被明天的取代后仍将伴随你左右。所以微软将三个框架整合为一个让一个决策变得更容易这很好。五年后我们会使用不同的工具但仍会问同样的几个问题这真的需要智能体吗它有合适的上下文吗出问题时它能恢复吗因为肯定会出问题的它代表的身份是否正确这些问题会在每次重写后依然存在这也是我学会投入精力的地方。框架来来去去好的架构必须能经受住所有变化。本文是Foundry专家贡献者网络的一部分。想加入吗微软.NET库与框架、Python、编程语言、软件开发、人工智能