一句话：微软这版 Agent Framework 没加多少花活，主要把「出事时怎么收」这件事焊死了
智能体框架的竞争，前两年比的是谁接的工具多、谁的编排更花哨。但到了要进生产，开发者最怕的往往是另一类问题：一个 agent 该不该在没审批时动手、多个会话之间文件怎么互不串、长任务中途崩了断点存到哪。10 月 2 日发布的 Microsoft Agent Framework 1.20.0，恰恰把重心放在这些「出事时怎么收」的工程加固上：审批默认失败即拒绝、会话级文件访问隔离、把 Foundry 托管重做成请求作用域的智能体工厂、并原生支持 computer-use。它不像一个大版本那样堆新功能，更像是在补一道道生产环境里迟早要踩的坑。
审批改成「默认拒绝」：一个细节，一种价值观
这一版在核心层强化了审批与 MCP 运行时上下文的处理：把「匹配到的函数结果」视为终态、要求会话支撑的本地审批、并且在审批绑定或 agent 工具审批无法解析时失败即拒绝（fail closed）。这听起来只是个开关，但背后是工程价值观——当系统拿不准一个动作该不该放行时，宁可让它停下来等人，也不要默认放行。对生产系统而言，这种「悲观默认」往往比「乐观默认」少出大事故。它把安全从「靠开发者记得加检查」下沉成了框架的默认行为，相当于给每个未决的审批都装了兜底刹车。
会话级文件隔离：多会话不再共用一本账
另一个值得做工程的人留意的改动，是引入了 session-scoped 的文件访问隔离，并给 AgentExecutor 增加了 checkpoint-state 的 TypedDict，以及可选项——把函数调用上下文注入给技能脚本。这些加在一起解决的是长任务里的状态卫生：不同会话读写的临时文件彼此隔开，任务中途的断点能结构化地存下来。过去多会话共用文件空间，容易出现一个会话的脏数据污染另一个会话的诡异 bug；这一版把隔离做在了框架层，开发者不必自己造轮子。对要并发跑很多agent的平台，这类底层卫生往往比花哨编排更能决定夜里会不会被报警叫醒。
Foundry 托管重做与 computer-use：把「部署」和「动手」都接上
在托管侧，1.20.0 把 Foundry 托管围绕「请求作用域的智能体工厂」重新设计，带来持久、沙箱隔离的会话，以及可解析、可持久化的 Invocations 运行记录，并支持可配置的历史、后台执行与选项。这意味着把 agent 跑在 Foundry 上更像一个受控的工厂，而不是一次性脚本。同时，它在 Responses 客户端和 Foundry 项目嵌入上原生支持 computer-use——也就是让智能体像人一样操作图形界面。这补齐了「模型能生成文本」到「agent 真能点界面把事办了」之间那块短板，也意味着框架默认就考虑到了这类操作带来的额外权限与审计需求。
增量认知：生产级框架的护城河，正在变成「失败处理」
把 1.20.0 和近期一众关于智能体安全、评测、故障实证的稿件放在一起看，一个清晰的趋势是：框架之间的差别，越来越不在「能做什么」，而在「做砸了会怎样」。审批默认拒绝、会话隔离、断点持久化，这些都不是 demo 里能显摆的特性，却是生产里决定系统能不能让人睡安稳觉的关键。对选型团队，这版释放的信号值得记一笔：评估一个框架，别只问它支持多少模型、多少工具，也要问它在「未决审批、多会话隔离、任务中途崩溃」这三件事上的默认行为是什么。
边界：破坏性变更与生态适配成本
需要说明的是，1.20.0 里有若干被标记为破坏性的改动——例如 Foundry 托管的重做、declarative 工作流的部分属性查找对齐、以及 Gemini 相关命名空间的切换。这意味着老项目升级时可能要改代码，而不是无感替换。另外 computer-use 这类能力虽已原生支持，但其带来的权限面、审计面，以及和人类操作界面的责任边界，仍需使用方自己设计。把它当成一次「更稳的默认」升级是合适的，但别指望换了版本就自动获得生产级安全——框架给的是底座，治理规则仍要自己写。
结语
Microsoft Agent Framework 1.20.0 不靠新噱头吸引眼球，而是把生产环境里那些「平时不重要、出事要命」的环节一点点焊牢。当行业从尝鲜走向落地，这类看起来 boring 的加固，恰恰是区分玩具和工具的分界线。一个框架成不成熟，往往不看它最多能做多炫的事，而看它在拿不准时，默认选择停下来等人。