现在微软解决了AI框架的争论，焦点转向了真正重要的事情：上下文、恢复逻辑，以及判断你是否真的需要代理。

　　过去一年里，我几乎和每一个启动AI项目的团队进行过同样的对话：我们应该基于Semantic Kernel（语义内核）、AutoGen（自动生成）还是Foundry（铸造）来构建？

　　起初，这感觉像是最重要的架构抉择。每个框架都有自己的理念，每个都承诺成为企业AI的基石，选错似乎会付出高昂代价。我花了很多时间帮团队权衡利弊。

　　现在回头看，我觉得我们问错了问题——我确实问错了。

　　我看到团队花了数月争论SDK，而真正决定应用能否在生产中存活的那些决策却被忽视了。有些人为本可用确定性函数完成的工作流设计了复杂的编排层；另一些人则完全避开代理框架，后来发现自己走进了死胡同。

　　然后微软替我们做了决定。它推出了统一的代理框架，悄悄将语义内核和自动生成置入维护模式，我耗费数月调停的争论戛然而止。原来，“三个里选哪个”的答案竟是“三个都不是，而是第四个”。该框架在2026年4月达到1.0版并正式发布，在.NET和Python上均保持稳定。

　　让我惊讶的不是这个决定本身，而是一场消耗我们如此多精力的辩论，竟会如此迅速地变得无关紧要。微软换了菜单，但这并没有改变这顿饭。

　　框架从来都不是困难的部分

　　框架选择曾占据我关于企业代理的每一次早期对话。我们用哪个SDK标准化？哪种编排模型最灵活？微软到底押注哪个？

　　这些问题在当时很合理。但观察这些项目一年后，我慢慢改变了看法——这些并非决定成败的关键。

　　我现在问的第一个问题要小得多：这东西真的需要代理吗？

　　听起来显而易见，但我有时仍会搞错。然而这是我见到最多的错误。有一个团队花了几周时间为一个流程设计多代理工作流，而那个流程每次只重复执行四个固定步骤：读文档、验证文档、调用API、发送通知。流程图看起来很漂亮，但生产系统却没那么好——一个经过充分测试的普通工作流本会更容易构建、维护和信任。

　　部分问题在于，“代理”成了每个人都在用的热词。有时它是正确选择，但有时它不过是我们早已知道如何构建的工作流，只是贴了新标签。代理的真正复杂性，只有当它必须做出你无法预先决定的判断、在工具间选择、根据遇到的情况自行调整下一步时才会显现。如果你已经清楚每一步做什么，那你就有一个工作流——而工作流通常是更优的工程选择。微软的合并并没有改变这一点，只是让它更易于看清。

　　构建生产级代理实际教会了我什么

　　一旦我不再纠结框架，同样有三个问题反复出现，而它们都与SDK无关。

　　上下文胜不过模型选择

　　早期我花大量时间比较模型，就像对着菜单纠结半天，最终却点了老样子。现在，我把大部分精力放在思考上下文上——这没那么有趣，却有用得多。

　　我见过好模型表现糟糕，不是因为给得少，而是因为给得太多。一个团队让模型访问几乎所有内部文档，以为信息越多答案越好，结果适得其反：响应变慢、不一致，有时还漏掉关键内容。当我把上下文精简到任务所需时，质量几乎立刻提升。这出乎我的意料，也让我学会怀疑“只管都给它”的做法。

　　我见过的优秀的代理系统，并非拥有最大上下文窗口的那些，而是懂得筛选什么内容、在何时送到模型手中的系统。而这些东西，框架不会白给你。

　　失败是真正的工作所在

　　大多数代理演示看起来很完美，因为它们是围绕“快乐路径”构建的。但生产环境可不会那么客气。

　　我记得一个项目，测试阶段一切平稳，可等代理执行完前面几步后，下游API突然超时了。我们无法直接重启，因为部分业务流程已经完成。最终，我们在恢复逻辑上花的时间远多于提示工程。那个项目彻底改变了我对这项工作的看法：困难的部分从来不是让模型做决定，而是当现实拒绝按剧本走时，确保系统不会崩溃。

　　工具调用中途失败、API返回不一致数据、模型反复调用同一工具只因上次结果不合心意——这些不是异常，而是寻常的周二。无论你选择重试、回退、暂停等待人工介入，还是继续处理部分结果，这些判断都需要你来做，没有框架能替你。

　　身份是真正的安全边界

　　这一点最让我意外。当代理不再只是聊天，而是真正触达业务系统时，身份认证比编排本身更重要。

　　每个项目最终都会问同一个问题：这个代理到底以谁的身份运行？开发者的凭证？服务账户？还是当前操作用户？一旦搞错，你就构建了一个自主运行的、拥有比任何人实际权限都大的访问能力的系统——这在审计到来前往往看起来很美好。代理框架通过MCP等标准让连接工具变得更简单，这确实有帮助。但人工审批该放在哪里、哪些操作需要额外授权、给代理多大的“自由”，这些仍然由你来定。

　　惊喜不是技术性的

　　我没想到的是，去年最难的部分竟然与技术无关，而是组织层面的。当团队听到“代理”这个词，每个人的期望都瞬间改变：业务方期待完全自主，开发人员认为它能推理一切。在我们甚至没商量好要解决什么问题之前，大家就开始为“灵活性”做设计。这个词在写任何代码之前就已经被严重过度炒作了。我发现自己花在管理期望上的时间，和花在架构讨论上的时间一样多。

　　为改变而建，而不是为今天的胜者而建

　　我并不认为去年那些挣扎的团队选错了框架——语义内核合理，AutoGen合理，Foundry在不少场景下也有道理，我会为其中任何一个签字。

　　真正受伤的，是把所有鸡蛋放进一个框架，把它当作整个系统的基础，而不是把它视为众多依赖之一。微软提供了迁移路径，但那些将应用与特定框架抽象深度耦合的团队发现，迁移几乎等于重写。这不是微软的问题，而是他们自己的架构选择。那些轻松迁移的团队，始终保持业务逻辑、提示和编排足够独立于任何SDK，因此这次变动只是可管理的项目，而不是一场大拆大卸。

　　值得一提的是，我认识的人中没有谁把这当作紧急事件。大多数人先迁移非核心工作负载，观察其表现，同时让生产关键系统继续跑在旧版上，直到真正理解新的抽象。这是正确的直觉。我怀疑这不会是最后一次整合——生态仍很年轻，框架会继续相互吸收，而它们之间的差异将越来越偏向操作层面，而非架构层面。

　　老实说，我并不后悔此前的框架争论，它们在当时是合理的。真正改变的不是微软的路线图，而是我的视角。看着这些系统在生产中运行，我明白框架其实是最容易替换的部分。恢复逻辑、上下文管理、安全边界、业务工作流本身——这些才是今天SDK被明天SDK取代后，依然会伴随你的东西。

　　所以，微软把三个框架变成一个，让一个决定变得更容易了，这很好。但五年后我们会用不同的工具，却依然会问那几个相同的问题：

　　这真的需要代理吗？它有正确的上下文吗？当出现故障（一定会有故障）时它能恢复吗？它是在以正确的身份运行吗？

　　这些问题比任何一次重写都更持久。这就是我学会投入精力的地方。

　　框架来来去去，好的架构必须能够经受住这一切。