微软技术周报 2026-09-14~09-21：.NET 11 Runtime Async 重构、VS 2026 正式 GA、CVSS 10.0 Foundry 漏洞

本期聚焦技术动态，不含财务信息。信息来源：.NET Blog、Microsoft Learn、dotnet/core Release Notes、ASP.NET Core Blog、Microsoft Foundry Blog、GitHub Changelog、VS Code Release Notes、Windows Release Health、MSRC / SecurityWeek / The Hacker News、Microsoft 365 Message Center、Power Platform 官方博客、Azure Updates、.NET Foundation、InfoQ 中文、博客园、CSDN、稀土掘金等中英文官方与媒体报道。

概览

核心一句话：本周是 9 月 15 日的"双响炮"——一边是 Stephen Toub 的年度长文《Performance Improvements in .NET 11》公布 Runtime Async 重构（同步完成时结果直接穿透调用链、中间 Task 分配归零），另一边是 Visual Studio 2026 正式 GA，BYOK 让任何模型都能接进 IDE、五个 Copilot Agent 直接连上调试器和性能分析器的实时数据；安全侧则是 CVSS 10.0 的 Azure AI Foundry 认证缺失漏洞（CVE-2026-85889）被披露并已在服务端修复。

一、C#：union types 转正后的第一次真实检验

上周我们记录了 C# 15 随 .NET 11 RC1 转正（union types、closed hierarchies、扩展索引器、带标签 break/continue、集合表达式参数、非虚静态接口成员六项退出 preview）。这一周社区把新特性真正拿去用了，反馈也回来了——好评和"硬伤"来自同一个特性。

1.1 union types 到底解决了什么：从 OneOf 到语言原语

union 的语法极简，语义却重。它不要求你把已有类型重写进共同基类，而是把已经存在的类型组合成一个命名的封闭集合：

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

// Pet 恰好是 Cat / Dog / Bird 中的某一个
public union Pet(Cat, Dog, Bird);

Pet pet = new Dog("Rex");

string name = pet switch
{
Dog dog => dog.Name,
Cat cat => cat.Name,
Bird bird => bird.Name
// 没有 _ 丢弃分支，编译器验证穷尽性
};

关键差异在于"编译器保障"这四个字。多年来 C# 开发者用 OneOf<T0, T1> 之类的 NuGet 包近似实现这个模式，但 OneOf 的穷尽性只在运行时兜底、依赖外部包、且 IDE 对 switch 完整性的提示有限。C# 15 的 union 是编译期强制、零依赖、IDE 完全感知：往 union 里加一个新 case 类型，所有没更新的 switch 会立刻被编译器标红。

对值类型场景还有一条性能路径：编译器在模式匹配时会自动使用 union 暴露的 TryGetValue 方法，走免装箱分支。C# 首席设计师 Mads Torgersen 对这件事的评价是：“This is how unions should be.”

代价也要说清楚：union 是封闭的，扩展候选类型集合意味着重新编译——这是编译期穷尽性的固有取舍，不是实现缺陷。

1.2 正在被挑出的硬伤：System.Text.Json 无法往返

社区讨论中最集中的批评恰好落在这个刚转正的功能上：union 无法通过 System.Text.Json 完成序列化与反序列化的往返处理，因为序列化输出里不包含类型判别字段（type discriminator）。

这个问题在 API 场景下相当致命。考虑一个返回 union 的 Minimal API 端点：

public record Success(string Message);
public record Failure(int ErrorCode);
public union Result(Success, Failure);

app.MapGet("/compute", () => (Result)Compute());

得到的 JSON 是一个裸对象，反序列化端无从判断它本该还原成 Success 还是 Failure——如果两个 case 的字段结构碰巧兼容，就会静默还原成错误的类型。

目前的实践建议是：当 case 类型之间存在共同基类、且契约允许带判别字段时，用 closed hierarchies 而非 union。closed 修饰的基类配合多态 JSON 序列化（写入 $type 判别符），能完整往返；union 的优势场景是"契约本身不含判别字段"或者"case 是互不相关的基础类型/你不控制的既有类型"。ASP.NET Core 11 在 OpenAPI 文档里把 union 呈现为 anyOf，这倒是如实反映了它的语义——只是 anyOf 本身也不携带判别信息。

微软 .NET 团队的 Jon Galloway 在 Reddit 讨论中回复称，发布文章列出的是相对于上一个预览版的变化，而不是相对于 .NET 10 的变化——这解释了信息落差，但没有解决序列化问题本身。做 API 设计的话，这是本周期最需要在设计阶段就决策的一件事。

1.3 另外两个值得上手的特性

集合表达式参数填上了集合表达式语法的一块空白——以前你没法在 […] 里给底层集合的构造函数传参，现在可以：

List<string> names = [with(capacity: 100), "John", "David", "Sarah"];

HashSet<string> set = [with(StringComparer.OrdinalIgnoreCase), "Hello", "HELLO", "hello"];

第二个例子尤其实际：以前要创建带自定义比较器的 HashSet 必须写成 new 表达式，现在收集器语义和初始化语义能写在同一行里。

编译器 API ITypeSymbol.UnionCaseTypes 让分析器可以直接读取某个 union 的全部 case 类型。这是 IDE 能做穷尽性提示、第三方工具链能做增量检查的前提——没有这个 API，工具层就只能靠字符串匹配或反射猜。

二、.NET：《Performance Improvements in .NET 11》与 Runtime Async

这是本周技术含量最高的一份材料。 9 月 15 日，微软杰出工程师 Stephen Toub 发布了年度惯例长文《Performance Improvements in .NET 11》。文章以电影《摇滚万万岁》的梗开场——别人的放大器最高旋到 10，Nigel 的定制款能到 11——而 .NET 11 的定位正是如此：没有单点革命，靠成百上千个微小改进叠加出复利。

规模上：18 个章节、136 组对照数据、263 个 PR、29 位外部贡献者，原文五万多词。用一句话概括它的结论：你什么都不用改，升级就变快。没有新 API 要学、没有配置要打开、没有"高性能模式"要手动切换。

2.1 Runtime Async：近十年 CLR 异步底层最大的一次重构

这是本版本最重要的架构级变化，也是全篇的核心。

问题在哪：传统 C# async 方法依赖编译器生成的状态机来在 await 处挂起和恢复。每传一次结果，就要包装一个 Task 对象；调用链有 N 层，中间就可能积累 N−1 个纯粹为了实现细节而存在的 Task。这些 Task 从来不是 API 契约的一部分，却实实在在压着 GC。

Runtime Async 怎么改：把状态机的记账工作从编译器挪进运行时。同步完成时，返回值直接穿透调用链，只有最外层（真正被观察的那一层）才需要包装 Task。实测收益：

最后一条对可观测性的价值可能比性能数字更直观。当 async 方法挂起时，物理线程栈会展开，续体可能在线程池的另一个线程上运行——采样型 CPU 分析器能看到 CPU 花在哪，但没法可靠地把这些采样接回逻辑 async 调用链。Runtime Async 让这条链路在诊断工具里第一次变得清晰可见，且不影响异常堆栈（异常堆栈在旧模型下已有清理机制）。

边界要说清楚：Runtime Async 并非让所有异步操作零分配。文章明确指出，如果你把 Task 存进集合、手动挂接续体、或以对象形式观察它，那个对象依然必须存在。它的设计目标是"不为观察不到的边界付费"——收益集中在同步完成且结果直接穿透的常见模式上。

配套的运行时侧优化包括：为同步返回 Task 的方法生成专用的 JIT 编译 async 版本、尾部合并挂起点以缩小生成代码、续体缓存、热 async 路径的分层编译、以及识别常见 Task/ValueTask 工厂并恢复 tail-await 优化。还有一项很实用的优化：在没有环境状态需要跨 await 携带时，跳过 ExecutionContext 的捕获与恢复——这条快路径覆盖 Task、Task<T>、ValueTask、ValueTask<T>，对高频使用 ConfigureAwait(false) 且很少用 AsyncLocal 的代码最有价值。

诊断工具链同步升级：dotnet/runtime#127238 新增了轻量级 async 分析器事件流。它不再把每一次微小状态转换都作为完整事件发出去，而是在每线程缓冲区里写入紧凑记录，对时间戳和指令指针做增量编码，再批量刷出；同时在调用续体时往物理栈里放一个可识别的小包装帧，让分析器能把这个帧当作锚点，把普通 CPU 采样接回事件流表示的逻辑 async 调用栈。效果：开销 低于 1%，追踪数据量缩小一个数量级。#129043 及其后续 PR 把同一套方案扩展到了现有编译期状态机——所以不 opt-in Runtime Async 的应用同样受益，工具侧拿到的是两种实现统一的表示。

关于开发者该做什么：文章的答案是"基本什么都不用做"。继续按可读性写异步代码，需要拆辅助方法就拆，默认用 Task、在权衡确实契合时才用 ValueTask，不要仅仅因为今天的实现可能分配中间 Task 就去扭曲源码删掉一个干净的 await。降级策略应当作为一个"just work"的实现细节。

启用方式：以 net11.0 为目标的项目不再需要 EnablePreviewFeatures；运行时库自身已经使用该特性，应用侧可通过 UseRuntimeAsync 项目属性控制进出（同样支持按项目 opt-out）。截至 9 月 14 日，runtime async 跟踪标签下已有 235 个 PR——这个规模本身就说明了工程量。

2.2 JIT：泛型虚调用去虚拟化，被卡了多年的那条路径

这是全篇技术密度最高的一处改动，也是我最想单独拿出来讲的一处。

为什么泛型虚方法（GVM）一直是 .NET 最慢的派发形态：普通虚方法有 vtable 槽位，JIT 知道该去哪儿找。但接口上声明的 int SizeOf<T>(T value) 没有唯一槽位——每个类型实参实例化都是不同的方法体。解析它意味着一次运行时查找，而查找结果对 JIT 来说是一个不透明的函数指针。不透明就不会内联，不内联逃逸分析就永远看不穿这个调用。

改造分三步（三个 PR 顺序推进）：

数字（BenchmarkDotNet，同一份代码在 .NET 10 与 .NET 11 上对照）：

那 24 字节是怎么消失的，这才是真正有意思的部分。这笔分配从一开始就不是调用的目的——new Processor() 存在只是为了让接口转换有个接收者。在 .NET 10 里，因为调用不透明，JIT 必须假设接收者逃逸了，于是 Processor 被放到堆上，每次调用 24 字节。一旦调用被内联，逃逸分析就能证明这个对象从未离开当前栈帧：实例被栈分配、没有任何代码读它、然后整个折叠掉，Unsafe.SizeOf<T>() 在同一趟里变成常量。

3.8 倍的提速是真实的，但**“分配"那一列的 0 才是会在 GC 密集服务里显现出来的东西**——它把 P99 抖动从"每次调用一次堆分配"变成"没有”。

一个必要的前提提醒：这条路要求 JIT 在调用点知道接收者的精确类型（本例中就是本地构造的 sealed 类型）。真正多态的调用点仍然依赖 dynamic PGO 的守卫式去虚拟化——你拿到的是"类型检查 + 内联快路径"，而不是直接调用。如果你写 visitor 接口、泛型序列化钩子，或任何"由方法而非类型携带类型参数"的抽象，这是值得在自己代码上实测的一处改动。

2.3 逃逸分析、边界检查与断言传播

可空类型装箱的内部化是另一处高价值优化：JIT 现在能看透 Nullable<T> 的装箱操作，把临时堆分配彻底干掉。最直观的例子是 int? 的格式化：9.58 ns → 1.99 ns，提速近 5 倍。Tier0 编译器现在也具备装箱优化能力，这对启动阶段和分析器里的分配噪声都有正面影响。

边界检查消除扩展到更多循环变体。C# 是内存安全语言，array[i] 这类访问由运行时保证在界内——代价是 JIT 需要证明它在界内，否则就注入一次检查：

; x64：一次典型的边界检查
cmp ecx, dword ptr [rax+8] ; 比较索引与数组长度
jae THROW ; 无符号比较：索引 >= 长度则抛出
mov edx, dword ptr [rax+rcx*4+16]

.NET 11 的新增覆盖包括：!= 形式的循环克隆、把 return 语句更聪明地纳入范围检查克隆、以及更智能地跟踪 Span 切片以减少重复检查。注意前提：!= 循环克隆仅支持步长为 1 或 −1，i += 2 不适用——并非所有写法都能自动受益。

断言传播（assertion propagation）让 JIT 从已成功完成的操作中提取隐含事实。最简单的例子：数组创建成功，就意味着请求的长度不是负数。这一改进使 CovariantArrayStore 基准提升约 16%。同一方向上还有写屏障优化（协变数组存储、结构体整体拷贝）和 GC 依赖句柄的随龄增长机制（#78746）——ConditionalWeakTable 底层的依赖句柄过去不随引用对象老化，导致每次 gen0/gen1 回收都要重新扫描；现在句柄会随 referent 晋升，年老的句柄可以被年轻回收直接跳过。压缩式回收里的 vxsort 向量化排序也扩展到了 Arm64（#110692）。

2.4 向量化、数值计算与线程池

• AVX-512 嵌入式广播与掩码技术减少了内存占用，Vector256 乘法基准显示约 42% 的提速；AVX-512/AVX10.2 机器上的浮点转换不再调用辅助函数，提高了内联效率。
• BigInteger 的存储单元（limb）从 uint 换成 nuint（#125799）：64 位机器上每个 limb 从 32 位翻倍到 64 位，同代价的 64 位运算一次能处理两倍比特。三角函数也大幅提速。
• 线程池小任务调度开销下降（#122726）：去掉不必要的内存栅栏与共享状态更新、改为按批而非按任务与控制器交互、减少信号量自旋、只在队列确实需要时才请求新 worker——顺带也少了"队列刚空就被唤醒"的无用 worker。
• 运行时内部哈希结构：VM 内多张哈希表（如 EEHashTable）引入基于纪元的回收（#124822），读多写少场景下读者不再需要进入协作式 GC 模式；哈希函数从逐字节换成每次消费 4 字节的 xxHash（#129640）。

2.5 一个必须提前排进预算的变化：CPU 底线抬高了

这是本次升级里最容易被忽略、但影响部署规划的一条：.NET 11 把 JIT 与 AOT 编译的最低 x86/x64 基线从 x86-64-v1 抬到 x86-64-v2（Apple、Linux、Windows），意味着运行时可以假定 CX16、POPCNT、SSE3、SSSE3、SSE4.1、SSE4.2 存在。

更值得注意的是 ReadyToRun 目标：Linux 与 Windows 上从 x86-64-v2 再抬到 x86-64-v3，新增 AVX、AVX2、BMI1、BMI2、F16C、FMA、LZCNT、MOVBE 假定。从 .NET 11 起，缺少新 JIT/AOT 基线的老旧硬件可能无法运行 .NET 11。 对部署到长生命周期设备或自管服务器的软件来说，CPU 资产盘点应当写进升级计划。

Arm64 侧按操作系统分化：Apple 维持 M1 基线不变；Linux 的 JIT/AOT 基线仍是 armv8.0-a，但 ReadyToRun 镜像现在需要 LSE，缺 LSE 的设备可能要承担额外 JIT 工作；Windows 的 JIT/AOT 基线提到 armv8.0-a + LSE，ReadyToRun 提到 armv8.2-a + RCPC。微软的说法是这能降低维护复杂度、避免预编译产物去迁就过低的下限，同时允许更激进的代码生成。

2.6 MAUI 全面投奔 CoreCLR（详见第四章）

值得注意的是，运行时统一这件事是跨板块的：MAUI 在 Android、iOS、Mac Catalyst 上正式切换到 CoreCLR，最后一批还在用 Mono 的 MAUI 平台完成迁移。移动应用由此与 ASP.NET Core、云服务、桌面 .NET 共享同一个运行时、同一个 JIT、同一个 GC、同一套诊断设施——也就意味着上面这一整节的所有性能改进自动落到移动端，同时引入了 CoreCLR 的分层编译、ReadyToRun 和 PGO，并为 NativeAOT 打下共同基础。

2.7 平台与 SDK：这一周的其它 .NET 侧动作

• F# 11 成为默认语言版本：记录展开（record spreads）与直接构造委托转正；字符串插值现在编译为 String.Concat 而非基于反射的 printf 引擎，F# 发行说明指出这使它能够与裁剪和 Native AOT 配合使用；新增记录与 union 的免反射 ToString 输出、inheritdoc 与 include 文档标签支持、以及新的 Async.RunSynchronouslyImmediate 函数。
• SDK：dotnet test 支持移动与桌面目标——现在可以运行以 Android、iOS、macOS、Mac Catalyst 为目标的测试项目，并为每个平台提供新的项目模板；新增运行级选项可设置超时、在失败达到指定次数后停止运行、为每个测试应用分配独立结果目录。
• 容器发布：设置 SOURCE_DATE_EPOCH 后可在不同构建间产出相同摘要的镜像；若目标注册表中已存在镜像清单则跳过上传。这两条对 CI 缓存与供应链可复现性都有直接价值。
• dotnet format 支持基于文件的程序；Negotiate 身份验证支持 TLS 通道绑定。
• HTTP/1.1 解析器去异常化、zstd 支持、HTTP/3 首请求提速、Kestrel TLS 握手可观测性（网络栈部分见第三章）。
• .NET 9 servicing（9/16）：.NET SDK 9.0.121 / Runtime 9.0.20 发布，修复 CVE-2026-58649 与 CVE-2026-69806（Oracle Linux 等发行版同步跟进）。注意 .NET 9 已进入支持尾声——.NET 8 与 .NET 9 都将在 2026 年 11 月 10 日结束支持，与 .NET 11 GA 同一天。
• **Aspire 13.5.4 补丁（9/15）**发布。Aspire 的支持策略是"任一时刻只支持最新版本"：下一个 minor 发布时，当前版本即退出支持——这意味着升级节奏要跟上，不能长期停在某个 minor 上。
• 升级路径建议：如果你还在 .NET 9，时间是以周计而非以月计。推荐路径是先升到 **.NET 10（LTS，支持至 2028 年 11 月）**作为安全桥接，GA 之后再评估 .NET 11——不要在截止压力下直接跳到刚 GA 的版本。

三、ASP.NET Core

3.1 网络栈：HTTP/3 与 HTTP/2/3 的收尾工作

ASP.NET Core 11 在网络栈上呈现的是一条清晰的"现代化收尾"主线：HTTP/3 首请求提速、HTTP/2 与 HTTP/3 的尾部标头超时、HTTP/1.1 解析器去异常化、zstd 压缩支持、以及 runtime-async 带来的吞吐改善。这部分改动大多不需要开发者动代码，属于"升级即受益"。

3.2 OpenAPI：3.2 成为默认，语义映射更细

默认面向 OpenAPI 3.2，并补齐了几处长期缺失的语义映射：

• HTTP QUERY 被识别为已知操作类型；
• 文件下载类终结点（FileContentResult、FileStreamResult 等）自动映射为 type: string, format: binary 架构；
• SSE（服务器发送事件） 端点用 3.2 的 itemSchema 描述——这是 3.2 里比较实用的新能力，让流式端点的响应体不再只能写成模糊的 string；
• [Obsolete] 自动映射为 deprecated: true；
• 构建时生成文档可用 OpenApiGenerationEnvironment 指定环境。

API 文档在今天的定位早已不是"开发时的便利"。它同时服务于前端、移动端、集成团队、API 客户端和自动化测试系统——契约的机器可读性随着应用规模增长而变得越来越关键。

3.3 Minimal API：端点筛选器能看见绑定失败了

一个相当实际的改进：端点筛选器现在可以观察参数绑定失败，并自定义响应。

过去，绑定失败会直接产生 400，筛选器管道根本不参与——结果就是应用里的错误响应格式四分五裂：有的地方是 ProblemDetails，有的地方是自定义结构，有的地方是框架默认。现在你可以集中维护一致的响应契约：

app.MapPost("/orders", (OrderRequest req) => Results.Ok())
.AddEndpointFilter(async (ctx, next) =>
{
var result = await next(ctx);
if (result is BadHttpRequestException bre)
{
return Results.Json(new
{
success = false,
message = "Invalid request",
errors = Array.Empty<string>()
}, statusCode: 400);
}
return result;
});

配套的两条：C# union types 在凡是用 System.Text.Json 的地方都可用（OpenAPI 里呈现为 anyOf），以及异步验证端到端打通——AsyncValidationAttribute 配合 IAsyncValidatableObject，查库、调远程 API 的验证规则不再阻塞线程。

还有一个值得单独记一笔的 [ShortCircuit] 特性：路由匹配后立即执行，跳过其余中间件管道。健康检查端点、robots.txt、静态元数据这类请求不需要走完整的认证、授权、日志中间件链，直接在路由层短路掉。

3.4 Blazor：AI 组件登场，静态 SSR 拿到客户端验证

Blazor 是本次 ASP.NET Core 更新中篇幅最大的一块。

静态 SSR 的客户端验证：以前服务端渲染的表单要往返一次服务器才能显示验证反馈；现在静态 SSR 表单支持客户端验证，同时继续以 .NET 模型作为验证规则的唯一来源。这对于"表单多但不需要整体交互化"的业务应用是实质改善——不用为了表单体验把整个应用变成 interactive。

表单异步验证：支持需要外部操作的验证规则。典型流程是"格式校验 → 查数据库 → 检查可用性 → 显示结果"，这是本地模型无法独立判断的部分。

实验性 Blazor AI 组件（Microsoft.AspNetCore.Components.AI 包）是新增项里最值得关注的。它针对的场景包括流式聊天、富文本与工具渲染、人工审批流、以及类型化/共享/预测性 UI 状态，并支持通过 AG-UI 协议接入远程 Agent。设想一个 CRM：用户 → AI 助手 → 读取客户上下文 → 建议动作 → 请求审批 → 执行工具。Blazor 的组件模型确实是承载这类交互的自然位置。

但必须强调：这些组件是实验性的、预发布状态，不应被当作已定型的生产 API。官方对迁移建议的表述也很克制——“不要因为 .NET 11 是新的就采用它，采用那些能解决你应用里真实问题的部分”。

其它值得记的变化：

• QuickGrid 把分页与排序状态搬进 URL（?page=2&sort=Name），天然支持链接分享、浏览器前进后退和静态 SSR；新增行点击事件。
• Virtualize 增强：支持不等高项、原生滚动锚定、AnchorMode（Start/End，分别适合信息流与聊天）、以及编程式滚动 ScrollToItemAsync。
• 静态 SSR 拿到 TempData 与会话持久化，以及 CacheView 用于缓存子树渲染输出。
• 服务器触发线路暂停：计划停机、实例排空时可优雅暂停电路；标签页隐藏自动暂停（AutoPause）降低空闲资源占用。
• WASM 支持 IHostedService 与环境变量配置；WithBrowserOptions 可在服务端配置客户端行为。
• Blazor Web Worker 模板改名（原项目模板名不再暗示只有 WASM），生成的 worker 客户端支持 InvokeVoidAsync、取消与超时。
• 新的 Gateway 开发服务器（Microsoft.AspNetCore.Components.Gateway）取代 WebAssembly.DevServer 服务独立 Blazor WebAssembly 应用，内置 SPA 回退路由。这是工具链变更，独立 WASM 项目需要相应调整引用的包。
• Blazor Web App 模板内置容器支持，方便打包进容器镜像 → 注册表 → 云/K8s 的部署链路。
• MCP 服务器模板随 SDK 捆绑：dotnet new mcpserver，AI Agent 工具一键起步。这一点和 .NET 官方 MCP C# SDK v2.0（默认无状态协议，便于用 ASP.NET Core 构建和扩展 AI 工具）是同一方向的两个落点。

四、.NET MAUI：Mono 时代的最后一页翻过去了

4.1 核心变化：CoreCLR 成为 MAUI 的运行时

.NET 11 起，MAUI 在 Android、iOS 和 Mac Catalyst 上正式切换到 CoreCLR——最后一批还在用 Mono 的 MAUI 平台完成迁移。对开发者而言"采用"这件事简单到几乎没有动作：以 .NET 11 为目标，应用就跑在 CoreCLR 上。

意义不止于性能数字。切换之后，移动应用与 ASP.NET Core、云服务、桌面 .NET 共享同一个运行时、同一个 JIT、同一个 GC、同一套诊断设施和性能改进。它同时引入了 CoreCLR 的分层编译、ReadyToRun 和 PGO，并为 NativeAOT 打下共同基础。运行时统一后，性能优化与诊断工具链的复用度显著提高——但也别指望"移动端自动变快一个档"，具体收益仍取决于平台和负载。

4.2 Android 的"三连"优化：构建、包体、启动

清单改动从 40 秒降到 11 秒这个数字，对日常开发节奏的影响可能比启动快 2.4% 大得多。

4.3 dotnet test 移动端测试工作流：补齐了一块明显短板

这是 RC1 最有分量的更新。dotnet test 工作流扩展到 Android、iOS、tvOS、macOS 和 Mac Catalyst，测试直接在设备/模拟器或桌面目标的应用进程内运行。配套的新项目模板包括 androidtest、iostest、tvostest、macostest、maccatalysttest：

dotnet new androidtest -n MyTests
cd MyTests
dotnet test

测试框架不限于 MSTest——任何 Microsoft.Testing.Platform 支持的框架（如 NUnit）都可以配置。另外，仅 Instrumentation 的 Android 项目现在可以用 dotnet run 直接跑，不需要声明 Activity；BenchmarkDotNet 这类无头设备测试工具也因此可用了。

MAUI 的单元测试与 UI 测试长期难以搭出顺畅的工程化流程，现在这条路官方修通了。

4.4 控件、平台特性与 XAML

• TabbedPage 徽章：子页面可通过 BadgeText、BadgeColor、BadgeTextColor 附加属性显示徽章，Android、iOS、Mac Catalyst、Windows 全支持初始设置与运行时更新。小红点提醒这种高频需求终于有了官方方案。
• SwipeItem 显式颜色：新增 SwipeItem.IconColor 与 SwipeItem.TextColor，支持 AppThemeBinding。
• 主题化启动画面：MauiSplashScreen 支持暗黑模式独立配置（DarkFile、DarkColor、DarkTintColor），避免"配了暗色主题但启动时闪一下白屏"。
• BlazorWebView 静态内容缓存：通过 StaticContentCacheControlProvider 可选开启，覆盖 Android、iOS、Mac Catalyst、Windows 和 Tizen。
• FlyoutPage 迁移 Handler 架构：iOS 与 Mac Catalyst 上默认使用 FlyoutViewHandler，Apple 平台主要多页控件的 Handler 迁移至此完成。
• Resizetizer 质量可调。
• XAML 增量热重载：作为预览功能引入，并在 Debug 构建中默认启用。实现方式是用源生成器结合 MetadataUpdateHandler，对已创建的页面做修改而不整体重建 XAML。能处理的范围包括属性变化、添加/移除子项、结构重排序、附加属性、标记扩展、绑定，以及 ResourceDictionary 的更改；同样适用于 dotnet watch。
• Apple 平台：NativeAOT 和 CoreCLR 应用默认使用 trimmable-static 注册器；macOS 与 Mac Catalyst 的 NativeAOT 构建默认生成 dSYM 调试符号；绑定作者可以把可失败的 Objective-C 初始化器暴露为可空静态工厂方法。

4.5 Passkeys 进入 MAUI Essentials

最显眼的新增项是 MAUI Essentials 里的 Passkeys API，在 Android 14+、iOS 与 Mac Catalyst 16+、以及受支持的 Windows 10 版本上驱动原生 Passkey 体验。应用侧调用三个接口：

Passkeys.CreateAsync(...) // 注册凭证
Passkeys.AssertAsync(...) // 进行认证
Passkeys.IsSupported(...) // 检测底层平台是否支持

边界必须说清楚：这个 API 负责平台侧的 WebAuthn 流程，但刻意把服务器端责任留给了应用——依赖方服务器仍需生成 challenge、提供标准 WebAuthn 选项、并验证返回的断言或证明。信任配置也要自己配齐：Apple 平台需要 Associated Domains 与 Apple App Site Association 文件，Android 侧是 Digital Asset Links。客户端这半边微软帮你做了，服务端那半边还得自己扛。

4.6 生态视角与支持周期

同步发布的还有 Syncfusion 的《Build Modern .NET MAUI Apps with .NET 11》网络研讨会（微软 MAUI 首席产品经理 David Ortinau 主讲），覆盖 Shell 路由模板、地图标记聚合、Material 3 支持、安全区/边到边布局、XAML 中的 C# 表达式、以及 MAUI Dev Flow / MAUI Sherpa 这类让 Agent 与运行中应用交互的 AI 工具链实验。会议的核心观点值得记下：AI 辅助开发的价值不只是更快生成代码，也可以是帮助开发者验证、基准测试和理解自己正在构建的应用（升级项目、审查发布文档、运行测试、与运行中的应用交互、基准测试性能、调查启动时间与内存占用、识别减小包体的机会）。

技术判断：RC1 最值得关注的其实不是某个具体功能，而是 go-live 许可本身——它意味着 MAUI 在 .NET 11 上的形态基本定型，企业项目现在就可以基于 RC1 做升级评估，不必等 11 月正式版。

支持周期提醒：MAUI 10（2025 年 11 月 11 日发布，最新补丁 10.0.101 于 2026 年 9 月 7 日发布）将在 2027 年 5 月 11 日结束支持。这个周期相对短，需要写进预算规划。

横向对比（跨平台生态 9 月动态）：Flutter 无大版本，stable 频道连续推出 hotfix 至 3.47.4，集中修复 SwiftPM/Xcode 27 构建失败、Impeller 在 PowerVR GPU 上的渲染异常、flutter test 崩溃（占工具崩溃 11.7%）等问题；Kotlin 2.4.20 正式版（9/7）把 Swift 互操作能力全部转正——sealed class 映射为 Swift 枚举、跨语言继承、自动生成 Package.swift；React Native 处于版本空窗期（0.88 开发中），适合消化 0.87 的 Strict TypeScript API 迁移（deep imports 现在是类型错误，opt-out 开关 0.89 将移除）；uni-app x 最新版本仍是 5.24，三端蒸汽模式进入稳定修复期。

五、Visual Studio / VS Code / AI 编程：Visual Studio 2026 正式 GA

这是本周开发工具侧的头条。 微软在 9 月 15 日发布了 Visual Studio 2026，称其为"首个 AI 原生 IDE"，更正式的表述是 Intelligent Developer Environment。三个头条能力：BYOK、五个与实时 IDE 工具链打通的 Copilot Agent、以及挂起事件相比 VS 2022 减少 50%。

5.1 BYOK：把 Agent 基础设施与单一 AI 供应商解绑

这是架构意义上最重要的变化。在之前的版本里，Visual Studio 的 AI 辅助只能通过 GitHub Copilot 提供，且前提是持有 Copilot 订阅。BYOK（Bring Your Own Key）把 IDE 的 Agent 基础设施与 AI 供应商解绑：

• 支持的提供方：Microsoft Foundry 部署、OpenAI、Anthropic、Ollama（自托管模型），以及遵循 OpenAI 或 Ollama API 规范的自定义端点；
• 无需 GitHub 登录：BYOK 处于预览状态，在 Community、Professional、Enterprise 三个 SKU 中默认启用——没有 Copilot 订阅的开发者用自己提供的密钥也能访问 Agent 功能；
• 新的 Agent harness：BYOK 接入基于 GitHub Copilot SDK 构建的 Agent (Preview) harness，与 GitHub Copilot CLI 同源，微软称其"更少闲谈、更少纠正轮次就能完成任务"；
• 思维强度控制：对暴露该参数的模型提供 low / medium / high 三档 token 预算控制，让团队在例常任务与复杂任务之间调深度与成本。

必须注意的破坏性变更：旧版 BYOK 在 Ask 与 Agent 模式里的体验已不再支持，团队需要把 BYOK 测试迁移到新的 Agent (Preview)；在 18.10 Insiders 1 里配置过的 Ollama 模型需要重新添加。这不是一次 UI 刷新，而是编排行为的迁移——建议记录迁移前的端点、模型 ID、prompt 文件、工具配置和预期输出作为快照，否则改动的行为到底来自模型、提供方、harness 还是扩展更新，将无从判断。

另外微软明确说明：不是每个模型都支持每一项 Agent Mode 能力。碰到不支持的能力时 Visual Studio 会明确标注，而不是静默失败——但这不意味着模型之间可以互换。工具调用、上下文长度、图像输入、结构化输出和延迟都会改变同一个仓库任务的完成结果。

对企业团队的实际含义：因为合规、采购、数据驻留或成本原因而选择了非 Copilot 模型的组织，现在可以把那套模型接进 Visual Studio 的完整 Agent 基础设施，不必额外引入 Copilot 依赖。MCP 边界则是另一层控制：Visual Studio 会遵守 GitHub 组织的 MCP 服务器允许清单策略，存在允许清单时未授权的服务器无法连接。BYOK 管的是模型路径，MCP 管的是哪些外部服务能收到上下文或执行动作——这两条应当分别审批、分别记录。

5.2 五个 Copilot Agent：接的是实时运行时数据，不是源码文本

这是我认为比"Copilot 聊天更聪明了"重要得多的一处变化。五个具名 Agent 各自接入了 VS 的原生工具链——性能分析器数据、调试器状态、测试运行器输出。它们不只读你的源码，而是观察你的代码实际做了什么。

除此之外，自定义 Agent 可以写成仓库里的 .agent.md 文件（存放于 .github/agents/）随代码一起评审，用户级 Agent 则存在用户的 GitHub agent 目录；Agent 可以选择工具、模型和 MCP 连接外部知识。Visual Studio 2026 是微软第一个拥有成文 Agent 扩展模型的 IDE。

配套的其它更新：Git Agent 可以在聊天里探索 PR，返回的链接能直接打开对应的评论和文件，并支持接 GitHub 与 Azure DevOps 的 MCP 服务器获取更多 PR 上下文；内联分支高亮会在调试时用红/绿标出 && / || 复合条件里是哪个操作数决定了结果（&& 短路为假时标出失败的操作数，|| 为真时标出满足条件的操作数）；Attach to Process 支持 Podman 容器；Markdown 编辑器支持 Mermaid 图表渲染；代码覆盖率在所有版本可用；自适应粘贴（粘贴后按 Tab 自动适配命名、格式甚至语言）；Setup Assistant 一键安装缺失的 .NET SDK；MCP 服务器认证凭据集中管理；11 套新着色主题。

安装体验上，VS 2026 与 VS 2022 可以并存，兼容 VS 2022 扩展，并自动迁移设置。

5.3 C++ 侧：CppCon 2026 与 C++23 收官

在 CppCon 2026 上，微软分享了 Visual Studio 面向大型 C++ 代码库的演进方向。几个值得记的节点：MSVC Build Tools v14.51 已发布（含 C++23 一致性推进、编译器优化改进、新架构支持、Sample Profile Guided Optimization）；v14.52 将于 11 月发布，包含 /std:c++23 开关并将达成 C++23 完整实现——唯一例外是 constexpr cmath 实现，它仍是实验性的、默认关闭（用 /Zc:cmath opt-in）。该开关已在 Visual Studio 2026 Insiders 通道的最新预览编译器中可用。此外 Copilot CLI 与 Visual Studio、VS Code、GitHub Copilot 应用共用同一套 Copilot SDK，装上 C++ 语言服务器插件后可在终端获得接近 IDE 的语义智能。

5.4 VS Code 1.138 与 GitHub Copilot 周更（9/14）

auto 模型选择有了三档显式路由，这是本周 Copilot 侧最有结构性的变化：

三档从同一个模型池里选取，改变的只是路由权重而非模型目录——即三档不会给你更多或更少的模型可用性。正在向 VS Code、Copilot CLI 和 Copilot 应用铺开。计费上，费用按 auto 实际选中的模型计算，与档位无关；付费订阅用户通过 auto 计费的使用仍保留 10% 折扣。GitHub 把它称为"迈向用户可定制选择的第一步"。

copilot code review 的几处改进值得单独列：

• 后续评审中自动把已被处理的评论标记为已解决，只保留未决反馈（但如果有人在回复里要求保留某个问题，会尊重该回复）；
• 应用它的建议时，自动生成提交信息（标题 + 可选描述）；
• 评审可以调用 shell 工具来验证改动（构建、测试、脚本），运行在 agent 防火墙之后；
• Lite 强度现在使用多个 Agent 的集成结果。GitHub 给出的实验数据：已处理评论高严重度 +47%、中 +31%、低 +11%，同时评审成本降低约 8%。

Copilot 应用新增 Sentry canvas：可以从 Sentry 崩溃报告直接进入一个已加载错误、堆栈跟踪和相关上下文的 Copilot 会话，走完调查 → 验证修复 → 准备 PR 的路径，缩短"告警触发到 PR 打开"的距离。

Agents 窗口的几处 Agent 会话治理：

• 本地 Dev Container 支持：Agent 可以在项目自己声明的工具链与依赖里运行，而不是依赖宿主环境（需要 Docker + 受支持的 Dev Container 配置，渐进式铺开）；
• PR 直接创建：在 Agents 窗口里审阅生成的标题与描述、选择 draft 状态、直接创建 PR 或让 Agent 代劳；
• 不活跃会话自动标记为 Done：在所有关联 PR 合并后触发，可选在经过一个独立宽限期后删除（opt-in 预览）。

管理员侧：

• VS Code Agents 窗口的使用量指标 GA，与企业/组织报告一起提供日活用户数、会话数和用户消息总量以及用户级活动数据——注意这些指标与编辑器窗口的指标是分开的；
• 仓库自定义属性的取值建议（Copilot 建议，公测），组织与企业所有者可通过 Copilot 策略开关；
• AI 信用额度超限后可向上申请提额，所有者与计费管理员可在设置中批准、调整或拒绝，批准即恢复 AI 信用访问。该项对使用按量计费的 Copilot Business / Enterprise 计划 GA，但对采用集中托管用户的企业不可用。

其它同期动作：Copilot CLI 的 Project HydraFusion 进入 /experimental，在本地区、云端与复合模型之间做自动化语义路由；企业托管 Agent 操作权限（9/9 GA）让管理员集中设定哪些 Agent 操作被阻止、需要人工批准或可无提示执行，覆盖 shell 命令、文件读改和网络域名，且托管限制不能被用户或工作区设置、自动批准或此前保存的批准削弱；JetBrains 版 Copilot 的企业托管沙箱（9/8 公测）提供沙箱启用、文件系统/网络访问、代理、开发者工具访问、macOS 钥匙串访问等策略，同版本还带来跨文件光标跳转、聊天中的全局项目上下文、企业策略诊断、子 Agent 模型选择等。

时间线上的三个待办：9/28 起统一 Copilot 体验默认开启；10/1 起对现有卡/PayPal 客户实行预付费按席位计费；10/2 是四模型弃用清单的执行日（更早的一批 Copilot 模型弃用截止日为 10/19，覆盖聊天、内联编辑、Agent 模式与补全，Business 与 Enterprise 客户已有迁移指引）。模型清单本身本周稳定，无新增（MAI-Code-1-Flash 已下线）。

一条产品方向信号：微软在 VS Code 里预览了面向 Azure 应用的引导式 Copilot 体验，把"从想法到部署"从开放式聊天改成三段式有检查点的工作流——项目脚手架（用自然语言描述应用，Copilot 提出架构并用表单/选择器补齐缺失信息，写完任何代码前先让你审阅并批准计划）、本地开发（检查运行库、模拟器和工具链并帮你装上缺失部分，自动接好调试配置）、部署（展示将使用的工具、将创建的资源清单和成本估算，用 az / azd 执行，为应用生成基础设施文件以保证测试与预发环境可复现）。首版聚焦 JavaScript 与 TypeScript（Web 应用、Azure Functions、Container Apps、Static Web Apps，支持 PostgreSQL、Azure Storage、Key Vault、Azure OpenAI），.NET 与 Python 在路线图上。这是"从’提问然后祈祷’转向’有明确检查点和真实 UI 的结构化协作’"这一判断的落地。

六、Microsoft Copilot / Power Platform / Microsoft 365

6.1 Grok 进入 Microsoft 365 Copilot（9/12）

微软在 9 月 12 日正式把 xAI 的 Grok 模型加入 Microsoft 365 Copilot，作为 Microsoft Frontier 计划的一部分，Grok 现在可以在 Word、Excel 和 PowerPoint 里被选为模型。发布由 Satya Nadella 宣布，Elon Musk 在 X 上确认。

管理控制是核心：Grok 默认关闭，管理员必须在 Copilot 设置里的"AI providers for other large language models"下显式启用 SpaceXAI 模型。地理限制同样适用——预览阶段 EU、EFTA 与英国区的 Frontier 客户不可用。SpaceXAI 已被加入微软的 Online Services Subprocessor List，管理员对 Grok 模型处理的数据保有控制权。微软未说明 Office 预览由哪个 Grok 版本驱动（xAI 最新的前沿模型是 2026 年 8 月的 Grok 4.6）。

至此微软同时在 Copilot 各界面提供三个前沿模型家族：GPT-6 Astra（9/4）、Claude Fable 5.1（9/1）以及 Grok。

6.2 联邦 MCP 连接器 GA：不索引、不存储、只读

这是 Model Context Protocol 在 Microsoft 365 里的一次重要里程碑。联邦 Copilot 连接器在 9 月进入 GA，其关键属性是"不索引、不存储"：Copilot 通过 MCP 连接第三方数据源，以用户身份实时检索，数据不经过微软服务——这在隐私与合规上是一个显著的差异化点。认证走 OAuth 2.0 并遵循源系统的权限；协议是只读的，Agent 可以搜索和检索内容，但不能向源系统写入。

GA 时支持的界面为 Researcher Agent、Microsoft 365 Chat 与 Excel 中的 Agent 模式。管理员在 M365 管理中心 Copilot → Connectors 下管理，微软发布的一等联邦连接器会显示为 “Ready” 状态。默认环境组里包含 12 个微软一方 MCP 服务器，全部通过 Entra ID 认证（公开的 Microsoft Learn Docs MCP 服务器除外）。可用范围覆盖全球多租户、GCC、GCC High 与 DoD。

本月新增的连接器覆盖多个行业：法律（iManage Work、Boardwise、Harvey、Descrybe、Relativity、Everlaw）、金融（Mercury、Xero、FactSet、PitchBook、Morningstar）、专业服务（Asana、Notion、Canva、Linear、Dropbox）、能源（S&P Global Energy）。此外自助同步连接器进入公测：个人用户可以用自己的凭据连接 Jira Cloud 和 Confluence Cloud，无需走 IT 工单，内容在 Microsoft Graph 中按用户而非按组织探索。GA 目标为 2026 年 10 月。

6.3 Copilot Cowork GA 与"自然语言建应用"

Copilot Cowork 正式 GA（经 Frontier 计划提供），定位是 Microsoft 365 里的长时运行、多步骤工作：描述你想要的成果，Cowork 制定计划、跨你的工具与文件推理、带着可见进度推进并在过程中留出让你干预的机会。它内置了来自 Claude 和微软的技能（如日历管理、每日简报），能处理一次性任务也能处理像月度预算审查这样的可重复工作流。技术平台来自驱动 Claude Cowork 的那套。Capital Group 作为早期接入方，其企业技术高级副总裁 Barton Warner 的评价指向了价值点：“这不是生成内容或答案，而是采取真实行动——连接步骤、协调任务、在日常工作流中贯彻到底。”

同期，Researcher 新增 Critique 与 Council，用 Anthropic 与 OpenAI 等前沿实验室的模型组合把生成与评估分离，提升深度研究的质量与模型对比能力。

自然语言建应用是这一季 Copilot Studio 最有结构性的更新：Copilot Studio 的公有预览与 Copilot Cowork 里的 /app 技能，让创建者用自然语言描述业务目标——用户、数据和所需动作——Copilot 生成一个可用的初稿，用户可以细化、预览、测试并发布。应用会使用连接器和 Work IQ，遵循 Entra 身份与连接器策略，发布的应用会出现在 M365 管理中心的清单里。计费走 Copilot Credits 用量模型，建应用和执行都消耗。在 Copilot Cowork 里构建的应用可以在 Copilot Studio 中打开和编辑——这是有意设计的互操作性。

Copilot Studio 侧的其它变化：GitHub Copilot harness GA，现在有三种 harness 并有白皮书说明如何选择；新 harness 上的 Agent 无论 Copilot 许可如何都会为其全部工作计费；信用额度在创建者构建时就消耗，而不只是 Agent 运行时；新增 isCLIAgent 属性用来判断哪些 Agent 在新 harness 上；每个环境四条强制执行规则；可以对单个 Agent 设置限额；有了租户级的信用额度流向视图；新增 Agent 与工作流设计器；用于发布前检查的 Agent Review Tool；GitHub Copilot harness Agent 的 SharePoint 元数据过滤。

Work IQ API 达到 GA，连接器爬取更快，ServiceNow 连接器尊重基于角色的权限，Power BI grounding 推向全球，Viva Engage 私有社区可以 grounding Copilot。

6.4 M365 应用层的 September 更新（节选）

Power Platform 2026 年 9 月功能更新（9/17–9/18 发布）：

• Canvas Authoring Agent Plugin 转 GA：创造者与 AI Agent 在共享创作会话里协作——Agent 可以创建和修改屏幕、连接数据源、更新 Power Fx 公式、配置控件，并在实时编辑会话中验证改动。委托范围由创造者控制：把复杂或重复的任务交给 Agent，需要精确时随时恢复直接编辑。
• Model App-Builder Skill：按官方博客说法已 GA，可用 GitHub Copilot CLI、Claude Code 等 AI 编码工具从自然语言需求创建或编辑整个 model-driven app（生成 Dataverse 表、表单、视图、图表、站点地图、JavaScript 验证规则、安全角色、业务流程流和生成式页面）。
  这里有一处必须提醒的事实冲突：Microsoft Learn 上同一能力的专门文档仍标注为 preview，明确说该能力处于活跃开发中、app-spec schema 与 CLI 选项可能在版本间变化、且尚未支持所有 model-driven app 的构件与概念；官方 9 月综述里链接的学习模块标题也仍带 “(preview)”。合理结论不是"功能没发布"，而是配套记录没跟上——客户对支持预期、变更稳定性和生产级工作流的边界缺少一致答案。
  建议把它归类为受控试点：只指向开发或沙箱环境，强制人工审阅生成的规格与 dry-run 计划，通过既有的解决方案管道部署而非在共享生产环境中直接编辑。计划审批步骤有价值，但它不能替代对安全角色、表关系、JavaScript Web 资源与业务规则的审查。Learn 还提到一条具体限制：生成后的人工修改会影响后续 AI 辅助编辑——所以在让 Agent 修改既有应用之前，源代码管理、解决方案导出和成文基线是必需品。这里最危险的失败不是生成了一个明显坏掉的应用，而是后续 Agent 主导的更新悄悄覆盖了创造者在生成之后做的定制，因为那次改动没有被反映进下一份 app specification。
• Power Apps MCP 服务器进入公有预览：让外部 Agent 通过从未结构化来源（共享邮箱、SharePoint 文件夹）抽取字段并创建记录来自动化画布应用的数据录入。配套的增强 Agent 反馈给创造者提供待处理 agentic 动作的并排对比视图，可直接跳转到记录审阅或拒绝改动再提交——这条人工审批设计正是此前让企业客户观望的治理顾虑所在。预览先在美国早期发布周期环境铺开，随后按微软标准周部署节奏扩展区域。当前范围仅覆盖数据录入，微软表示会逐步增加更多 CRUD 操作。
• Power Automate 与 Copilot Studio 编排打通：自动化流程可以在过程中调用 AI Agent，并在需要判断的边界情况上接收决策后继续。对已经在跑 Copilot Studio Agent（内部门户、政策查询）的组织来说，这些 Agent 从此可以直接参与自动化流程，而不只是待在一个独立的聊天体验里。
• 生成式页面接入 Dataverse 之外的数据源：可通过 Power Platform 连接器（包括 SharePoint 与 SQL Server）绑定，不必再把数据复制进 Dataverse。这是预览，不建议用于生产；每条基于连接器的页面都需要一个既有的 Power Platform 连接，且必须用最终用户实际会使用的身份和权限来测试——对创造者可用的页面，在普通用户打开时仍可能失败、暴露意外宽泛的信息或返回不完整结果。测试前应检查连接引用、数据丢失防护策略处理、共享配置、连接器专属权限。
• Power Apps：新增六个开箱即用的 Fluent 2 屏幕模板，以及批量更新当前屏幕上合格控件的选项；批量转换是可启用所需现代控件设置的代码变更，不是外观刷新——公式、验证和 OnChange 行为都可能改变，只有在真实数据与用户路径下测试过转换后的屏幕才谈得上省时间。
• 路线图机制变更：没有 2026 release wave 2；Release Planner 于 2026 年 11 月 15 日退役；内容迁移至 AI at Work 路线图。

6.5 Microsoft 365 Copilot for Government 的下一步

微软宣布 Microsoft 365 G7 for GCC，把生产力、AI、Agent、安全、身份、合规与治理整合为一个面向政府的方案。接下来的几个月是政府云史上规模较大的一波 Copilot 能力：GPT-5.6 扩展起草、摘要、研究与多步推理；Copilot 的记忆与个性化；Word/Excel/PowerPoint 里的就地 Copilot 编辑；Outlook 中扩展的 Copilot Chat 体验（无需附加许可即可利用邮件、日历与会议信息）；Copilot 应用里重建的 Notebooks；Copilot in Forms；GCC High 的 Teams 聊天/频道/通话/会议统一 Copilot 体验；DoD 的智能会议纪要。

七、安全

7.1 CVE-2026-85889：CVSS 10.0 的 Azure AI Foundry 认证缺失漏洞

本周安全侧的最高优先项。微软在 9 月 18 日（周四）披露并修复了 Azure AI Foundry（亦名 Microsoft Foundry）的一个满分严重漏洞：

Azure AI Foundry 是用于构建、部署和管理生成式 AI 应用与 Agent 的企业平台。该环境里的权限提升具有触及 AI 工作负载、API 密钥和平台内存储数据的潜在影响面。由于是云托管服务，微软完全在自己的基础设施上完成了缓解——MSRC 公告除漏洞分类外未提供技术细节，这是服务端修复的标准做法（补丁在披露前已上线）。

同一轮修补的其它关键云漏洞：

以上全部在服务端完全缓解，客户无需采取任何动作。

7.2 18 个云与 AI 服务漏洞的集中披露

微软在同一天发布了 18 个漏洞的补丁，覆盖 Azure 云组合与 Copilot 品牌的 AI 产品。权限提升类占了大头，影响 Azure ARC、Azure AI Foundry、Azure Logic Apps、Azure Billing、Azure HorizonDB、Azure Cosmos DB、Azure Container Registry、Microsoft Fabric、Microsoft Dataverse 和 Microsoft 365 Copilot；另有若干信息泄露漏洞被修复于 Copilot、Microsoft 365 Copilot、Microsoft 365 Copilot Business Chat 和 Azure Machine Learning；Azure Portal 有一个身份伪造漏洞。

值得注意的是口径问题：微软把所有 18 个都评为 critical，但其 CVSS 分数显示其中一些实际上属于高或中危。部分漏洞由微软内部发现，许多由外部研究员报告。没有任何一个被标记为已被利用，所有修复均在服务端实施。

7.3 带外更新：两个本地提权漏洞

有两个漏洞需要用户实际更新 Windows：

两个漏洞都通过带外累积更新修复：

• Windows 11 26H1：KB5129194（Build 28000.2956，arm64 与 x64 均已发布）
• Windows 11 25H2 / 24H2：KB5129195（Build 26200.9457 / 26100.9457）
• Windows 10 22H2 / 21H2：KB5129236（Build 19045.7727 / 19044.7727）

其中 CVE-2026-62721 上月首次披露，CVE-2026-85921 当时已被标记为可利用性"较低"。

7.4 补丁星期二余波：CISA 截止日与 BlueMoon 漏洞利用套件

上一周的 9 月补丁星期二创下纪录（约 974 个漏洞，另有 964 / 966 / 970 / 999 等公开口径，差异来自统计方法论；请注意各来源数字不可直接比较），其中438 个属于权限提升类。两个已被在野实际利用的零日：

• CVE-2026-81963 — Windows Update Stack 的链接解析不当
• CVE-2026-85880 — Windows Advanced Local Procedure Call（ALPC）特权提升

两者都允许已授权的本地攻击者在低复杂度、无需用户交互的条件下提升至完整 SYSTEM 权限。CISA 已将两者加入 Known Exploited Vulnerabilities 目录，联邦修复截止日为 2026 年 9 月 22 日——也就是本期周报发布后的次日。

更需要警惕的是利用链：据 Proofpoint 与 Volexity 报告，ALPC 漏洞被与两个 Google Chrome 漏洞串联，形成了名为 BlueMoon 的漏洞利用套件，已被多个与间谍活动相关的威胁行为者武器化，用于投递恶意载荷。这意味着 Windows 侧的提权原语正在被放进浏览器攻击链里组合使用——安全团队除了验证补丁覆盖，也应复核与提权技术相关的横向移动检测与日志覆盖是否存在盲区。

7.5 9 月更新的回归问题与紧急修复

9 月安全更新后陆续暴露出若干兼容性问题，多数已通过带外更新解决：

最后一条值得单独说明：该问题主要影响开启了 Credential Guard 与 Machine Identity Isolation（MII）的企业环境，根因在 MII 功能的强制执行逻辑——其前提是域功能级别必须达到 Windows Server 2025 或更高。遇到登录故障的企业应先核对这两项配置。

另外，自 2026 年 10 月起，Windows 11 用户将分批获得增强版内存完整性防护：依托处理器硬件虚拟化能力构建基于虚拟化的安全环境，即使攻击者突破内核，隔离层仍可维持防线，并支持在业务运行状态下完成底层漏洞的热修复。

顺带一提：9 月补丁星期二还修复了 Copilot Studio 的一个严重漏洞——对同时使用 Copilot Studio 构建 Agent 的团队，这个补丁优先级不应低于系统补丁。

八、Windows 简报（5 条要点）

九、其他简报

• Azure：ARO 托管控制平面预览 — Azure Red Hat OpenShift 的 hosted control planes 进入公测（UK South、Canada Central、Australia East、Switzerland North、Brazil South、Central India、East US 2、West Europe）。用托管标识与工作负载标识替代存储凭据（短生命周期、自动轮换的令牌），默认启用 etcd 加密并支持自带密钥，满足数据驻留、主权与合规要求。原有标准架构继续完全支持与开发。
• Azure：PostgreSQL 技能与 MCP 插件 — 把受支持的 AI 编码助手（GitHub Copilot CLI、Claude Code、Codex CLI）变成懂 PostgreSQL 的上下文感知专家：结合你的 schema、PostgreSQL 版本、扩展和 Azure 环境给出建议，并配备能检视实时数据库上下文的 MCP 服务器。覆盖查询与索引调优、向量搜索与 RAG、JSONB、分区、安全、Azure 预置与扩缩容、高可用与故障转移、时间点还原、AI 函数、以及基于 Apache AGE 的知识图谱，并在通用 PostgreSQL 与 Azure 专属建议之间自动路由。
• Azure：Application Gateway 支持 HTTP/3 over QUIC（公测） — 前端客户端连接可走 QUIC，改善连接建立时间、降低延迟并提升弹性，面向对延迟敏感的 Web 应用、消息平台、移动体验、交易与 API。另外两项运维提醒：Windows App 将从 10 月初使用三个新的客户端侧通配 FQDN（*.windows.cloud.microsoft、*.service.windows.cloud.microsoft、*.windows.static.microsoft，均 443/TCP），对终端设备施加防火墙/代理/VPN/DNS 过滤的企业需提前放行；Microsoft Sentinel 体验正从 Azure 门户迁移到 Defender 门户，Azure Monitor 的旧版身份验证与 Azure Maps Render V1 API 于本月退役。
• .NET Foundation 全体会员迁移到 Outseta — 超过 900 条会员记录从多个系统（网站申请表、早期电子表格轮次、GitHub members team）合并到单一平台，这也是会员第一次能自己查看和更正持有的信息。10 月第一周会从 contact@dotnetfoundation.org 发出激活邮件（链接有效期 30 分钟，过期后可重发），登录页由 Outseta 托管在 dotnetfoundation.outseta.com——这是唯一涉及的另一个域名。若到 10 月中旬仍未收到，很可能是因为通过 GitHub members team 加入且邮箱不公开，可带姓名与 GitHub 用户名写信处理。**不愿被列出的会员可直接要求删除记录。**这不涉及营销订阅，newsletter 保持独立且 opt-in。
• Agent Governance Toolkit（AGT）开源 — 微软 .NET 官方博客发布，为 .NET 生态中的 MCP 工具调用提供统一安全治理，MIT 许可、适配 .NET 8.0+、依赖轻量、无需额外服务，dotnet add package Microsoft.AgentGovernance 即可引入。四个核心组件分工：McpGateway 作为前置治理管道完成权限校验、限流、熔断、入参合法性校验；McpSecurityScanner 对工具元数据与定义做安全扫描（识别投毒、注入、仿冒并评分，可按阈值直接拦截高风险工具注册）；McpResponseSanitizer 对返回结果脱敏清洗（移除注入特征、明文凭证、外部恶意跳转 URL）；GovernanceKernel 作为编排中枢，支持 YAML 外部策略配置、规则冲突处理与审计事件上报，原生对接 OpenTelemetry，调用延迟控制在亚毫秒级。它解决的是"MCP 协议虽有安全规范但原生 SDK 没有强制约束"这一实际缺口（工具投毒、提示注入、越权调用、敏感数据泄露），宣称完整覆盖 OWASP Agentic Top 10，并提供给 IMcpServerBuilder 的 WithGovernance(…) 扩展与面向 Microsoft Agent Framework 的中间件。多语言 SDK（Python、TypeScript、.NET、Rust、Go）共用同一套策略语言，另有 Rego / YAML / OPA / Cedar 策略模板可复用。
• Microsoft.Extensions.AI 10.10 — 移除了已经下线停用的 OpenAI Assistants 桥接，加固图像转换环节，并让不可用的评估分数按"失败即关闭"（fail closed）处理——评估结果拿不到时不再被当成通过。这是一条容易被忽略但安全相关的语义变更。
• MCP C# SDK v2.0 — 默认无状态协议，目标是让用 ASP.NET Core 构建和扩展 AI 工具更直接。它与 SDK 捆绑的 dotnet new mcpserver 模板是同一条产品线。
• 大会日程 — .NET Conf 2026：11 月 10–12 日，免费在线，将正式发布 .NET 11；社区议题征集即将开放。Microsoft Ignite 2026：11 月 17–20 日，旧金山 Moscone Center + 线上，重点包括 AI 与 Copilot 创新（Agent Factory、Agent 365 控制平面）、云与基础设施、安全与合规、开发者动手实验。
• Surface for Business 新品 — 新一代 Surface Pro for Business（13 英寸）与 Surface Laptop for Business（13.8 / 15 英寸）面向企业市场推出，搭载骁龙 X2 系列处理器并可选 Intel Core Ultra Series 3，通过专用 NPU 加速端上 AI 工作负载。均作为 Secured-core PC 出货，可通过 Intune、Windows Autopilot 和 Surface Management Portal 管理；部分 Surface Laptop 配置内置防窥屏；指定外壳部件使用 100% 再生铝合金，Energy Star 认证效率超出项目要求至少 45%。
• Copilot 路线图的两处反转 — 网页 grounding 的域排除功能在 8 月被撤下后重新回归；两个路线图项被直接取消（Proactive push notifications、Interactive Agents for Teams Meetings and Calls）。微软很少在同一周期内反复改口，这两条值得作为"路线图不等于承诺"的近期注脚。

本周报基于公开报道整理，仅供参考。