微软技术周报 09-21~09-28：新版 Copilot Home/Code/Autopilot、Copilot 四模型扩容、C# 15 with(...) 集合表达式

本周概览

一句话核心：9 月 25 日，微软把 Copilot 从「对话助手」重构成「工作的新入口」——Home / Code / Autopilot 三合一，并把 Word、Excel、PowerPoint 直接塞进 Copilot 应用；同一周，Copilot 的模型选择器一次性扩容了 Claude Opus 5.5、GPT-6 Sol、GPT-6 Luna、Grok 4.7 四款新模型。而在开发者这一侧，本周真正有技术含量的两篇是 C# 15 的集合表达式参数 with(…) 与 .NET 11 JIT 内部机制拆解——前者把「构造参数」合法地搬回了 […]，后者讲清了守护式去虚拟化与逃逸分析这次到底多做了什么。

一、C#：C# 15 集合表达式参数 with(…)，把构造参数搬回 […]

本周 C# 侧最值得细读的一篇，是 Laurent Kempé 在 9 月 26 日发的 《C# 15 Collection Expression Arguments: What’s New vs C# 12 and 13》。它填补的是一个从 C# 12 起就存在的缺口：集合表达式很好用，但你没法在 […] 里指定 List 的初始容量、HashSet 的比较器，或者自定义集合构建器的工厂参数。

三次版本演进，别搞混

一句话记住：C# 13 改的是「方法参数的调用形状」，C# 15 改的是「集合的构造形状」。

语法规则：with(…) 必须是首元素

// ✅ 合法：with(…) 在第一位
int[] sourceIds = [1, 2, 3];
List<int> ids = [with(capacity: 256), ..sourceIds];

// ❌ 非法：with(…) 不能在元素之后
List<int> bad = [1, with(capacity: 256), 2];

with(…) 里的参数不会成为集合元素，而是交给构造函数绑定、集合构建器的 Create(…)，或受支持的接口签名去消费。

场景一：预分配容量，意图写在同一行

以前你必须在「简洁的集合表达式」和「显式构造」之间二选一：

// 老写法：为了 capacity 必须放弃集合表达式
var customers = new List<Customer>(1000);
customers.Add(new Customer(1, "John"));
customers.Add(new Customer(2, "Maria"));
customers.Add(new Customer(3, "David"));

// C# 15：容量是构造参数，不是元素
List<Customer> customers =
[
with(capacity: 1000),
new Customer(1, "John"),
new Customer(2, "Maria"),
new Customer(3, "David"),
];

编译器用重载决策挑构造函数：List<T> 有 List()、List(int capacity)、List(IEnumerable<T>)，所以 with(capacity: 10) 会命中容量构造。

场景二：HashSet 的比较器，这才是最实用的变化

// 老写法
var names = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
names.Add("John");
names.Add("JOHN");
names.Add("john");

// C# 15
HashSet<string> names = [with(StringComparer.OrdinalIgnoreCase), "John", "JOHN", "john"];
// 结果只有一个元素——比较器决定三者相同

比较器是集合行为的一部分，把它挪进集合表达式比挪进构造函数更有表达力。

场景三：自定义 CollectionBuilder 的多参数 Create

C# 15 允许 Create(…) 在末尾的 ReadOnlySpan<T> 之前再挂额外参数：

[CollectionBuilder(typeof(Tags), nameof(Create))]
internal sealed class Tags(string[] values, StringComparer comparer)
: HashSet<string>(values, comparer)
{
public static Tags Create(StringComparer comparer, ReadOnlySpan<string> items)
=> new([.. items], comparer);

public static Tags Create(ReadOnlySpan<string> items)
=> new([.. items], StringComparer.OrdinalIgnoreCase);
}

// 三种用法都成立
Tags tags = [with(StringComparer.OrdinalIgnoreCase), "CSharp", "CSHARP", "csharp", "dotnet"];
Tags newTags = [with(), "CSharp", "CSHARP", "csharp", "dotnet"]; // 走默认比较器重载
Tags oldTags = ["CSharp", "CSHARP", "csharp", "dotnet"]; // 完全不变

四条必须记住的边界

迁移清单

• 意图明确（capacity / options / comparer）的地方用 with(…)，别为了用而用。
• 数组和 span 别试，会编译不过。
• 心里那本版本账要清楚：C# 13 = params 调用形状，C# 15 = 集合构造形状。
• 自己写的构造函数/构建器如果有重载歧义，升级前先验证一遍。

同周还确认了一批随 .NET 11 RC1 落地的 C# 15 特性：with(…) 集合表达式参数、labeled break/continue、扩展索引器（extension indexers），以及此前已经稳定下来的 union types 与 closed class hierarchies。RC1 已把 C# 15 设为 net11.0 项目的默认语言版本，不再需要 LangVersion preview。

二、.NET：JIT 内部机制拆解，与 AG-UI 的官方 .NET SDK

2.1 「Performance Improvements」到底给你带来了什么——JIT 层逐条拆解

关于 .NET 11 性能文章，社区里普遍的困惑是：「我们代码是不是白变快了？」daily-devops.net 的一篇拆解给出了诚实的答案：部分场景、部分位置，且前提是 JIT 能对你的代码证明某些东西。它刻意只落在 JIT / codegen 层——去虚拟化、逃逸分析、委托布局、边界检查消除。

守护式去虚拟化（GDV）打进了泛型虚方法

接口是 OOP 的体面说法：你写 IValidator，JIT 看到的是通过方法表的一次间接调用，所有依赖内联的优化（也就是大部分优化）到此为止。

GDV 是 JIT 的绕行方案——不再永远发间接调用，而是插入一次类型检查，为它预测的目标类型准备快路径，其余走回间接调用：

public interface IValidator { bool IsValid(Order order); }

public sealed class DefaultValidator : IValidator
{
public bool IsValid(Order order) => order.Total > 0 && order.Items.Count > 0;
}

public decimal ProcessOrders(IEnumerable<Order> orders, IValidator validator)
{
decimal total = 0;
foreach (var order in orders)
{
if (validator.IsValid(order)) // GDV 可以猜 DefaultValidator 并内联
total += order.Total;
}
return total;
}

.NET 11 的新变化：GDV 扩展到了泛型虚方法（GVM），共享实例化与非共享实例化都覆盖。此前泛型派发要多走一层方法表间接寻址，因此退回间接调用的情况远比普通虚方法多。

但这不是免费的：每一次 GDV 守卫都是即使猜错也要跑的类型检查，猜错还要额外付回退路径的钱。 也就是说 GDV 是 profile-informed 而非无差别撒网——JIT 只在有理由相信某个类型占主导时才插守卫。如果你手上是个真正多态的调用点（三四个实现均匀分布），GDV 要么不触发，要么只加开销不带来收益。「我用了接口」在 .NET 11 里依然不是一个性能论据，受益与否取决于你实际调用点有多单态，而不是代码怎么标注类型。

逃逸分析：现在是 Nullable 装箱

逃逸分析的全部卖点就一句话：你不用写 workaround 的那些分配，GC 也不用碰。 判据是——这个对象会活过分配它的那个方法吗？如果能证明不会，对象可以留在栈上（运行时文档的说法是把一个驻留寄存器的栈指针递减，方法返回时自动释放），而不是上堆、最终计入一次 GC。

.NET 11 拓宽了可推理的形状，其中最值得注意的是 Nullable 装箱：过去装箱一个 Nullable<T> 在分析视角里是个不透明操作；现在 JIT 先把展开成它的组成部分再跑逃逸分析，于是「从没真正逃逸出去的装箱 Nullable」可以被完全消除。

public string FormatNullableInt(int? value)
{
object boxed = value; // value.HasValue 为真时，以前必然产生一次堆装箱
return boxed switch
{
null => "none",
int i => i.ToString(),
_ => "unexpected"
};
}

边界检查消除：安全 C# 何时能追上 unsafe

另一篇讨论面更广的文章（C# Corner）指出，.NET 11 在边界检查消除上有实打实的扩展：索引 + 常量的计算、部分 index-from-end 操作，以及 JIT 对循环条件的传递推理——比如

static int SumPairs(int[] values)
{
int total = 0;
for (int i = 0; i < values.Length – 1; i++)
{
total += values[i];
total += values[i + 1];
}
return total;
}

循环条件已建立 i < values.Length – 1，也就蕴含 i + 1 < values.Length，.NET 11 能识别这类关系并消掉冗余检查。

同时它给了一句很实在的提醒：「unsafe 更快」是个未经测量的假设。 安全版本把循环意图完整暴露给了运行时，反而给了优化的机会。真正该问的不是「unsafe 快不快」，而是「unsafe 让这条特定热路径可测量地变快了吗」。

周内其他 .NET 动态

• .NET 11 GA 时间锚定 11 月 10 日前后（STS 通道）。RC1 的 go-live 许可已生效，可以上生产，但 codegen 细节到 GA 前仍可能变，性能数字当作方向性参考而非合同。
• F# 11：字符串插值改用 String.Concat，dotnet test 支持 Android / iOS / macOS / Mac Catalyst 跨平台测试。
• NuGet 作者签名证书 9 月 23 日起轮换——如果你的流水线里有 trusted signer 策略或直接比对证书指纹，必须在切换前把新证书加进去，否则签名校验会挂。

2.2 AG-UI 协议迎来一等公民的 .NET SDK

9 月 25 日，.NET 团队与 CopilotKit 合作发布了 AG-UI 的 .NET SDK，放在 AG-UI 上游仓库里，与 TypeScript、Python SDK 并列，MIT 许可，发布在 NuGet 上。Microsoft Agent Framework（MAF）的 AG-UI 支持现在直接构建在这套 SDK 之上，不再自己维护一套协议实现。

AG-UI（Agent-User Interaction Protocol）标准化的是智能体 ↔ 用户界面这一层通信。智能体打破了传统请求—响应范式：长时运行、流式吐 token、中途派生子智能体、在响应中间调工具。没有共享协议，每个框架都吐自己的流格式，应用开发者就得自己解析分片、跟踪状态、映射事件——event 格式一变就坏。

SDK 收发双向：AGUI.Server 把一个智能体暴露成 AG-UI 端点，AGUI.Client 让 .NET 应用消费 AG-UI 端点。默认传输是 Server-Sent Events，protobuf 可选（覆盖事件子集）。协议事件分八类：生命周期、文本消息、工具调用、状态同步、活动进度、子智能体、特殊功能、草稿。

五个 NuGet 包：

最小服务端示例（智能体本身就是一个 IChatClient）：

using AGUI.Abstractions;
using AGUI.Server;
using Microsoft.AspNetCore.Http.Json;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.Options;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSingleton(CreateChatClient());
builder.Services.Configure<JsonOptions>(options => options.SerializerOptions
.TypeInfoResolverChain.Insert(0, AGUIJsonUtilities.DefaultTypeInfoResolver));

var app = builder.Build();

app.MapPost("/", (RunAgentInput input, IChatClient chatClient,
IOptions<JsonOptions> jsonOptions, CancellationToken ct) =>
{
var context = input.ToChatRequestContext(jsonOptions.Value.SerializerOptions);
var events = chatClient
.GetStreamingResponseAsync(context.Messages, context.ChatOptions, ct)
.AsAGUIEventStreamAsync(context, ct);
return TypedResults.ServerSentEvents(events);
});

await app.RunAsync();

AsAGUIEventStreamAsync 会自动在一轮运行前后补上 RUN_STARTED / RUN_FINISHED，在切换到别的消息或工具调用前关闭已打开的文本与推理块，并把多次中断合并成单个终止的 RUN_FINISHED——协议的事 SDK 管，Web 服务器还是你的。

Agent Framework 侧则薄成几行：

builder.Services.AddAGUIServer();
AIAgent agent = chatClient.AsAIAgent(name: "AGUIAssistant",
instructions: "You are a helpful assistant.");
app.MapAGUIServer("/", agent);

升级要改的 API 名（事件格式仍线兼容，老前端不用动）：

包里 1.0.0 目标 net8.0，关键包同时兼容 netstandard2.0 与 net472——也就是说 .NET Framework 4.7.2 以上的应用可以当消费者，但要暴露端点还是得用现代 .NET 的服务端设施。

顺带把三兄弟边界说清楚：MCP 给智能体送工具与外部上下文，A2A 管智能体之间通信，AG-UI 管智能体到用户界面。 三者可以在同一套架构里共存：后端用 MCP 拿工具，用 A2A 找别的智能体，再用 AG-UI 把生命周期、状态和工具活动流给前端。

三、ASP.NET Core：DBSC 实验性落地，Blazor Virtualize 被重写

3.1 DBSC：把会话凭据绑死在设备上

cookie 认证有个众所周知的死穴——cookie 窃取 / 会话劫持。长时有效的认证 cookie 从受害者机器上被拿走，就能在攻击者机器上照用，因为 cookie 是 bearer token，服务端没有任何办法知道它被偷了（除了一些很虚的启发式，比如 impossible travel）。

Device Bound Session Credentials（DBSC） 的思路是：用短生命周期凭据替换长生命周期凭据，并让刷新令牌必须由签发它的同一台设备出示。窃取因此失效——短 cookie 很快过期，刷新令牌在别处无效。验证手段是让浏览器用一把存在 TPM（可信平台模块）里的私钥对请求签名，私钥永不出 TPM，所以「同一个密钥签的」就等于「同一台机器发的」。

协议分注册与刷新两步：服务端返回 Secure-Session-Registration 头声明支持 DBSC → 浏览器生成密钥对并注册 → 服务端把长 cookie 换成短 cookie → 需要时浏览器访问刷新端点，服务端发挑战、浏览器签名回送、服务端更新短 cookie。

.NET 11 里 ASP.NET Core 加了实验性支持，以独立包 Microsoft.AspNetCore.Authentication.DeviceBoundSessions 发布。定位是现有 cookie 方案的 drop-in 加固层：你把它指向一个「源」登录方案，它负责注册握手、一个路径作用域的刷新 cookie、以及一个短时会话 cookie。最简单的用法只加一行：

builder.Services.AddAuthentication()
.AddCookie("Application", o => { /* 原有登录 cookie，不动 */ })
// 👇 为 "Application" cookie 加上 DBSC 支持
.AddDeviceBoundSession("Application");

3.2 Blazor Virtualize：可变高度、滚动锚定与严格 CSP

ABP 社区本周发的 《Blazor .NET 11: What’s New in Virtualize, AnchorMode, and CSP Support》 把 Virtualize 从「只适合规整列表」的组件，变成了能接住动态数据流的组件。作者在 Chrome / Firefox / WebKit 上实测并给出了数据。

背景是有多痛：一个展示 10 万条事件的运维看板，朴素 @foreach 会产生 400,078 个 DOM 元素；开了预渲染后，foreach 版本生成 28.6 MB 的 HTML 响应（虚拟化版本 11.7 KB），页面要花将近两分钟才可交互；而且新事件每秒都在到，描述长度还不一样。

.NET 11 的改动：

• 可变高度：Virtualize 现在会测量已渲染项并维护一个滚动平均高度，ItemSize 退化为起始估算值而非固定值。
• 滚动锚定：视口上方内容高度变化时，你正在读的内容默认不动。div 构成的列表走浏览器原生 CSS scroll anchoring；不支持的布局与浏览器走 ResizeObserver 回退方案。
• AnchorMode：新增 [Flags] 枚举 VirtualizeAnchorMode。Start（默认）在顶部时展示新项，End 在底部时跟随新项，None 都不做。离开边缘时，任何模式都会把正在读的内容钉住。
• 滚动 API：InitialItemIndex 与 ScrollToItemAsync，终于可以「打开就定位到某条」和「跳到任意条」。
• Overscan：OverscanCount 默认值从 3 提到 15——更多 DOM，更大的 ItemsProvider 请求，这是默认值的取舍。
• CSP：spacer 高度改为通过 data-blazor-virtualize-* 属性传值并用 CSSOM 应用，所以 style-src 'self' 不再打死虚拟化。对照数据很扎眼：.NET 10 上同一条策略会把 10 万条列表压成 1,227 px 的滚动范围。

RC1 实测到的毛边（作者明确列出）：

• 滚动后立刻长高的行只能部分补偿。
• InitialItemIndex 后的首次渲染可能让内容位移 53–82 px。
• append 之后 AnchorMode.End 有时距底部还差 29–77 px；Playwright 的 WebKit 构建下 30 次检查出现 10 次，Chrome / Firefox 是 1–2 次。
• WebKit 构建下，Start 列表在末尾追加时会发生跳动。
• 文档里的 AnchorMode="Start" 简写形式编译不过（工作区见原文）。

3.3 同周其他 ASP.NET Core / Blazor 动态

• HTTP QUERY 方法被 OpenAPI 文档生成器识别为已知操作类型——QUERY 是安全幂等方法，允许在请求体里发查询条件以替代过长的 URL 查询串。
• [SupplyParameterFromTempData] 从 TempData 字典向组件参数供值，简化跨页面状态传递。
• Blazor 服务端电路暂停/恢复：服务器可主动暂停电路、客户端保持状态、恢复时无缝继续。大规模部署场景下价值明确——负载高时断开非活跃用户的连接释放资源，用户切回来瞬间恢复。
• 服务端渲染表单的即时客户端验证（无需服务端往返）与异步验证规则（比如查数据库）；验证信息与属性名可本地化。
• .NET SDK 自带 MCP（Model Context Protocol）服务器模板。

四、.NET MAUI：CoreCLR 成为默认运行时——但它不改 Google Play 的分

4.1 一次运行时底座换代

.NET 11 里 CoreCLR 成为 .NET MAUI 应用的默认运行时（Android / iOS / Mac Catalyst）。对开发者来说采纳动作极简：目标框架改成 .NET 11，应用就跑在 CoreCLR 上。换来的是接入一个在整个 .NET 生态里被重度优化和验证过的运行时，连带在调试、热重载、遥测、日志、稳定性与运行时性能上都有继续改进的空间。

Android 的 Release 构建还会默认启用 composite partial ReadyToRun。 三条部署策略的取舍：

4.2 一个本周被反复澄清的误解：CoreCLR ≠ DEX 优化

Google Play 在 Play Console 里上了 DEX 代码优化指标（对未压缩 DEX 代码 ≥ 10 MB 的应用生效，相关优化指标目前设 25% 门槛）。于是很自然的一个问题是：升到 .NET 11 + CoreCLR，是不是这个分就上去了？

答案是：不会直接上去。 两件事在不同层：

.NET MAUI 应用
├── C# / .NET 代码
│ ├── CoreCLR
│ ├── ILLink / 裁剪
│ └── ReadyToRun
└── Android 平台集成
└── Java/Kotlin 代码
└── DEX
└── R8

CoreCLR 作用在 .NET 运行时侧，R8 作用在 Android/DEX 侧。 .NET 11 带来的 CoreCLR、ReadyToRun、改进的 IL 裁剪（包括针对 Android 相关托管类型的改进）能改善启动性能、可能减小应用体积，但不构成对 R8 的优化。所以完全可能出现「16 KB 页大小支持 ✅ / target SDK 36 ✅ / 64 位架构 ✅ / DEX 优化 ⚠️ 偏低」并存的状态——它们衡量的是 Android 构建的不同部分，不矛盾。ReadyToRun 也不是 DEX 优化手段，它主要服务于运行时/启动，而且因为要额外打包原生代码，反而可能换来体积代价。

4.3 MAUI 11 的功能面

Syncfusion 办的 MAUI 11 webinar（微软 PM David Ortinau）把 .NET 11 周期的 MAUI 变化过了一遍，值得关注的有：

• XAML 增量热重载（预览）：不再整页重建，而是用 source generator + MetadataUpdateHandler 修改现有页面，能处理属性变更、增删子元素、结构重排。
• Shell 路由模板：仿 ASP.NET Core / Blazor 的路由概念，支持必需、可选、默认、约束、catch-all 与混合段；参数通过 QueryProperty / IQueryAttributable 流动。当前只支持绝对导航，相对导航尚未支持。
• Passkeys（MAUI Essentials）：Android 14+、iOS/Mac Catalyst 16+、受支持的 Windows 10 上原生支持通行密钥；平台侧 WebAuthn 的服务端职责交给应用，所以开发者要配好 Associated Domains / Digital Asset Links。
• AOT 安全的 {RelativeSource AncestorType=…} 绑定编译为可裁剪的 TypedBinding，避开基于反射的字符串路径。
• Android Material 3 通过项目配置选择加入；边缘到边缘布局与安全区改进；明暗两套启动屏主题。
• CollectionView 在 Windows 上有下一代实现，Windows 地图控件换成由 Azure Maps 支持的真实实现，BoxView 增加接受 brush 的 Fill。
• AI 辅助开发：MAUI Dev Flow 这类工具让智能体直接与运行中的应用交互——升级项目、比对发布文档、跑测试、做性能基准、查启动时间与内存、找体积优化点。

五、VS / VS Code / AI 编程：四模型齐发，与「一个模型管三种建议」

5.1 Copilot 模型选择器一次性扩容四款

9 月 22 日，GitHub 连发多条 changelog，把 Copilot 的模型目录扩到了一个此前没有的宽度：

Opus 5.5 的关键实测口径：在 GitHub 的早期测试中，它以与 Opus 5 相当的任务解决率完成编码任务，但用的步数和 token 明显更少，多步任务中的错误恢复也更快。它在 Claude Code 侧同一天被设为默认 Opus 模型（100 万 token 上下文，$4/$20 每百万 token，缓存读取 $0.20/Mtok）。

两个操作层面的细节值得记一笔：

• Opus 5.5 对文本输出施加了水印。 GitHub 明确说明水印不改变含义、质量或可读性，不增加 token 或费用。
• 计费走 provider list pricing，用量计费（UBB）。 且截至 9 月 24 日，Copilot Business / Enterprise 的计费模型尚未针对 Opus 5.5 的算力成本更新——也就是说「步数更少」是否等价于「每任务更便宜」，还取决于微软侧的定价。

Copilot 的模型选择器现在横跨 VS Code、Visual Studio、JetBrains、Xcode、Eclipse、Copilot CLI、Copilot 编码智能体、Copilot 应用、github.com、GitHub Mobile——可以在一次会话中途换模型，且选择会沿用到该线程结束。

5.2 Copilot 桌面应用加沙箱，智能体活动可进你的 OpenTelemetry

Copilot 桌面客户端上了本地沙箱公开预览：限制智能体的文件系统、网络与凭据访问。对安全团队来说，这是一条显式边界，压住误泄凭据与意外网络调用的风险面。沙箱可通过 OpenTelemetry 观测，由企业管理设置配置——已有监控栈不用额外埋点就能吃进智能体活动。

其他集成改动：

• Slack / Teams：新建 issue 前会先查有没有类似的，减少重复工单；可分享文件、附件与消息链接给智能体补充上下文；长任务的实施计划状态更清晰，中断/陈旧回复恢复更好，会话空闲重连更可预期。
• JetBrains 1.18.0：组织级 / 企业级共享 skills 与组织托管的自定义指令现在在本地与智能体会话中生效——管理员发布一次编码约定、工具权限或领域上下文，全员自动继承。AI 辅助工具审批公开预览：低风险工具调用自动批准，高风险动作仍然问你。改一条早先的消息会同时回滚对话与文件变更，纠正早期误导向不再需要叠加新消息。Codex 智能体获得 plan mode。
• VS Code 1.139：可以在 SSH / Tunnel / WSL 主机上的 Dev Containers 里跑 Copilot 智能体，直接复用远程项目的工具链与依赖。UI 上是 Compact View、隐藏空组的过滤器，以及「独立聊天标签页 vs 单一活动聊天视图」的预览选项。

5.3 VS Code 把三条内联建议路径合并成了一个模型

9 月 16 日微软发了《Building the new GitHub Copilot Inline Suggestions Model: Part One》，22 日被 Visual Studio Magazine 详报。这件事的意义不在于「更快」，而在于架构收敛。

此前内联建议走三条独立模型路径：补全（completions）模型、就近下一编辑建议（nearby NES）、远距离 NES。VS Code 客户端逻辑负责决定该谁上场。现在合并为一个统一模型，由模型自己判断下一个合适的建议是「在光标处继续」、「就近改写」还是「改别处」。

做法上的几个技术点：

• 先把 nearby NES 与 long-distance NES 合成 2-in-1，再加进 completions，形成 3-in-1。
• 用统一的 diff-patch 格式取代此前补全与编辑建议各自不同的输出格式。
• 一次模型响应可以包含多处相关编辑，而不是每处单独生成。
• 后续编辑可被缓存，支撑 Tab-Tab-Tab 那种快速连续传播的模式。
• 喂给模型的代码与光标位置描述比旧的 NES 系统更简洁。

已公布的数据针对 2-in-1 阶段（最终 3-in-1 模型未公布对应数字）：相比此前三模型的生产基线，展示建议所需时间减少 10%，输出 token 减少 61%，且在所列关键使用指标（接受率、驳回率、展示率、持续参与度、累计留存字符数）上没有统计显著的回退。

过程值得一提：团队做了 200+ 次离线实验和 20 次在线实验，配合内部 dogfood、人工评估与受控 A/B。他们特别提到——离线基准上的好成绩并不总能转化为线上最好表现，因此另外补建了评估方法。补全被留到第二阶段才并入，原因是它占内联建议编辑机会的 70% 以上，是高流量路径，不能拿它先试。

5.4 Visual Studio 2026 把 VS Code 的 Hot Exit 搬来了

Visual Studio 2026 的 9 月更新（Insiders 通道）引入 Hot Exit。默认关闭，需在 Tools → Options → Preview Features 里开启，且需要重启 Visual Studio 才生效。

它保留的不只是文本：未保存的文件、有未保存修改的已保存文件、已保存文件的撤销历史（重启后 Ctrl+Z 依然能往回走）、以及标签页与窗口布局。最后一项是关键——你拿回来的不只是文字，还有「从坏编辑里退出去的路」。

作者也提醒了一句：Hot Exit 不能替代 commit。

六、Copilot / Power Platform / Microsoft 365

6.1 新版 Copilot：Home、Code、Autopilot 三合一

9 月 25 日，官方博客发布 《Introducing the new Copilot with Home, Code and Autopilot》。措辞很有意思——微软说这是在「重新构想 Microsoft Copilot」，把「人们依赖的工具」和「构建、定制、规模化 AI 所需的新一代能力」接到一起，并刻意拿它类比起 PC 时代的 Microsoft Office。

三个新能力：

• Home——新的起点，Chat 与 Cowork 在这里汇合。Chat 是即时对话（快问、查资料、起草），Cowork 是被委派的工作：你定义任务，它端到端跑完并把成品交回来（RFP 响应、发布套件、客户简报、财务结账包）。Office in Copilot 把 Word、Excel、PowerPoint 的完整能力内置进来——创建或更新真实、可编辑、对团队实时可见的文件，不再有格式损坏、游离版本或在另一个应用里重建上下文的问题。PowerPoint 现在能自动保持品牌一致性；Excel 里 Copilot 或其他协作者的改动可以看到改了什么和为什么，Copilot 还会推荐最合适的图表。
• Code——让解决方案构建走出开发者圈子。微软给的判断是：知识工作的单位一直是文件（文档、电子表格、演示文稿），Code 加上了第四个：任何人都能造的、解决具体问题的小解决方案。用自然语言描述一个应用、追踪器、看板、自动化或工作流，Copilot 自己选方案并构建——从常驻桌面小组件、可探索数据的交互式看板，到可分享给团队的云托管内部应用。与 GitHub Copilot 同源技术，跑在沙箱里，可托管在你自己的租户内，配套 Microsoft Copilot Managed Runtime 提供在 M365 环境内安全运行的托管基础设施。开发者继续用 GitHub Copilot，同时与 Copilot 平台有更多连接。
• Autopilot——此前代号 Scout，是云端托管的数字队友：有自己的身份、记忆和工作区，在组织设定的权限与边界内接手工作并持续推进。可从离开的地方接着干。

落地节奏：Home 与 Code 在 Frontier 计划中于数周内开始滚动发布；Autopilot 于月底扩展到 private preview。Code 将在今年晚些时候对 Microsoft 365 Premium 与 Pro 订阅者开放预览。M365 侧公告 MC1479277 给出的管理员部署窗口是 10 月，且冲击面评级很高——管理员需要在新体验铺开前审阅用量计费相关的管理设置。

平台与商业化的三件事：

• Microsoft IQ / Work IQ：Microsoft IQ 把 Copilot 落到组织上下文里；Work IQ（公开预览） 把它延伸到承载业务的系统，包括 Dynamics 365 与 Power Platform。通过组织的文件、会议、聊天与业务数据给回答做 grounding。
• FinOps for AI：让组织建立预算、限额与策略，把用量和支出更清楚地关联到业务结果。管理员可以设定哪些模型家族对哪些用户组可用，而这些设置同时决定 Auto 能从中选择哪些模型；用户也能自己看用量与到达限额前还剩多少容量。对 Copilot Studio 里构建的自定义智能体的支持随后在 10 月跟进。
• 插件注册表：把微软、合作伙伴与自建的插件汇到一个目录里，简化治理、发布与发现，月底前 GA。
• 计费口径变化：用户订阅仍是日常 Copilot 价值的基础，其中 Auto 居于核心——按请求权衡准确率、速度与成本，把工作路由给最合适的模型。用量计费（UBB） 用于访问高级与新兴能力，包括前沿模型与 Cowork、Code、Autopilot 里的长时智能体工作。

别处同时加的消息：GitHub 的 Copilot 用量与成本仪表盘进了 Insights，集中给出使用量、成本与采纳指标。

6.2 Power Platform：Generative Pages 进表单，pac CLI 长出 200+ 命令

9 月功能更新（企业指南视角）里值得记的几条：

• Fluent 体系的画布模板与现代化控件改进。
• 模型驱动应用头部与导航刷新 GA（版本 2609.1），对既有应用仍是 opt-in；显示密度处于公开预览且需要先开导航刷新。（注意区分：更早的 New Look 现代化浪潮已在 2026 Wave 1 变为强制。）
• Power Automate：快速开始卡片、服务端流搜索，以及从 Power Automate 调用 Microsoft Copilot Studio 智能体的能力——这把「在既有自动化流程里编排智能体」的摩擦降了下来。支持 service principal 作为流程所有者，适合关键任务型自动化，所有权不再挂在某个员工账号上。
• Generative Pages 进模型驱动应用表单：这是 9 月更新的一个重要位移。此前 Generative Pages 主要作为独立体验存在，现在可以直接嵌入模型驱动应用的表单，出现在某个分区或标签页里，与记录的标准字段并排。制作者用自然语言描述（也可以用图片或草图当参考），智能体生成基于 React 的可工作页面，此后再迭代、微调、发布；页面可编辑代码，数据源可以是 Dataverse 表，并能接收记录 ID 这类上下文，从而针对用户当前打开的那条记录工作。通过 Power Platform 连接器取数目前是公开预览。同时也支持用 GitHub Copilot CLI 这类 AI 编码工具来创建与编辑 Generative Pages，再部署到 Power Apps 环境。

pac CLI 的自动生成命令组（9 月 17 日公开预览） 是另一个结构性变化。历史上每条 pac 命令都是手工实现，导致覆盖面落后于管理中心和 PowerShell，同样的操作在不同工具里表现还不一致。现在微软从 Power Platform API 规范自动生成 CLI 命令——名称、参数、帮助与 API 调用全部生成。同一份规范此前已经在生成 .NET 的 Microsoft.PowerPlatform.Management SDK、Python 的 powerplatform-management SDK 和 Power Platform for Admins V2 连接器，现在它也生成 pac 命令：API 命名空间变成顶层命令组，API 操作变成命令。生成命令复用现有的 pac 认证配置，不用另外登录。

15 个命令组、200+ 条命令，最大的几组：

因为微软现在是 API-first 发货，有些操作会先到 CLI 再到管理中心。微软点名的三个新场景之一是在 Copilot Studio 里重新分配智能体所有权与隔离智能体。

Copilot Studio 智能体迁移到 Microsoft Entra Agent ID（MC1478488）正在推进：8 月 24 日起提供自助迁移，9 月起对没有 Entra Agent ID 的智能体启动自动迁移。2026 年 5 月之前创建的 Copilot Studio 智能体可能还在用旧的 app registration 身份。迁移收益包括：Entra ID 里的审计日志、智能体生命周期管理、与 Entra ID Governance 集成、连接器权限作为 API 权限显示在智能体身份上（Entra 和 M365 管理员不必打开 Power Platform 管理中心就能看到智能体能力范围），以及可以用 Entra 条件访问策略（网络位置、设备合规、风险条件）去靶向这些连接器权限。建议做法：先拿一小批非关键智能体试，与制作者约定验证窗口，逐批核对渠道、认证、操作、连接器、流与集成后再继续。

6.3 Microsoft 365：Copilot 开始能「写」第三方系统了

本周 M365 / Copilot 侧的更新相当密，挑几条有分量的：

• Copilot 连接器将获得写 / 更新 / 删除权限（September 22 Message Center，标记为 In development，目标 10 月 GA）。变化针对的是 federated connectors——目前这批 MCP 式集成给 Copilot Chat 的是对第三方服务的实时读权限。更新后 Copilot Chat 可以直接在外围系统里创建、更新、删除内容，目的是让用户不用离开 Copilot 去手动处理。微软明确的护栏是：每一次创建/更新/删除都必须有用户显式确认后才执行，且 Copilot 通过用户自己的账号与在连接服务上的既有权限行事；管理员可以看见哪些连接器启用了写和删除工具并禁用不符合策略的连接器。尚未澄清的部分同样重要：没有点名哪些第三方服务先支持写、没说连接器写能力的上线前评审流程、没说误改误删是否有撤销/回滚，确认界面的粒度（一次确认覆盖单条还是批量）也未指定——而文档自己也承认日志与报告的详细程度「可能因服务和配置而异」。
• Defender for Office 365 加上提示注入防护：检测并阻断旨在操纵 AI 助手与智能体的恶意邮件内容。被判为提示注入攻击的邮件归类为 High Confidence Phish 并自动隔离。对拥有 Defender for Office 365 Plan 2 或 Microsoft 365 E5 的组织默认启用。
• Copilot Notebooks 可以用 Outlook 邮件当知识源，扩展了 Copilot 做研究与工作流时可用的文档与数据范围。
• Outlook 里的 Copilot 从「单一会话」升级为跨越收件箱、日历、会议与企业数据的推理，改善摘要、上下文与后续跟进建议；并能用自然语言执行分诊动作——删除、移动、复制、分类，以及收件箱规则与文件夹管理（批量超过 5 封与规则变更需要确认）。
• Teams / Outlook / Microsoft 365 的应用与智能体统一管理（MC796790，9 月 25 日更新）：此前 IT 要在 Microsoft 365 管理中心和 Teams 管理中心分别配置可用性与安装设置，容易不一致；现在两个门户的可用性与安装策略统一，第三阶段（Phase 3）时间待公布。对终端用户没有大变化，但管理员要在这之前核对两个中心里的既有设置与内部文档。
• Excel：Copilot 聊天回复里带指向工作簿改动的可点击链接（工作表、表格、区域、图表、形状）；Show Changes 显示 Copilot 改动的归属卡片。
• Planner Agent 在基于组的 Planner 计划中可用，内置自然语言问答与任务管理。
• PowerPoint：可为 SmartArt 自动生成有意义的无障碍描述；支持用户自定义 skill。
• Microsoft Forms 加入 Copilot 聊天窗格，用于改进表单、起草邀请、分析回复。
• Vision in Copilot 能在语音会话中实时分析共享桌面屏幕与移动端摄像头画面；Copilot 应用支持 Apple CarPlay。
• Federated Copilot connectors 正式可用（面向 Researcher、Microsoft 365 Chat 与 Excel 中的 Copilot 编辑），通过用户身份实时访问、不在微软服务中存储或索引客户数据，管理治理保留。
• Purview Insider Risk Management 扩展到 Microsoft Fabric：引入基于 Power BI 活动的即用风险指标（异常数据导出、访问模式等），可纳入数据窃取与泄漏策略。10 月落地。
• SharePoint 额外存储改按量计费全球 GA，用消费计量代替按 GB 预购。
• Teams AI 会议归档文件：捕获 AI 生成的会议洞察（是结构化信息，不是原始会议内容），存在租户拥有的 SharePoint Embedded 容器里，默认启用，管理员可控生成与留存；只有会议参与者能访问基于归档的 AI 回答。
• Purview 凭据扫描：Data Security Posture Agent 新增凭据扫描，用 LLM 在配置的数据源中识别暴露的凭据——Entra ID 凭据、私钥、API 密钥——以带风险评分、AI 生成洞察和置信度的看板呈现。
• 管理侧杂项：Frontline 许可改名 Windows 365 Flex，许可证撤销时可立即取消配置 Cloud PC；Entra ID 从 10 月 26 日起弃用公司品牌自定义 CSS 定位属性（position / margin / transform / opacity / overflow / filter 等），这是 Secure Future Initiative 的一部分，用来提升登录页抗钓鱼能力；Entra ID 从 10 月初起为 B2B 用户支持 passkey。

七、安全：974 CVE 的余波，与一个新零日

本周的安全主线是消化 9 月补丁星期二——MSRC 的 2026-Sep 发布说明确认该批次包含 975 个微软 CVE，其中 Windows 占 724 个、Office 111 个、SQL 62 个。公共报道对总量的口径有 964 / 974 等差异（统计方法论不同），此处按 MSRC 官方发布说明的 975 记，另并列报道口径 974。

7.1 两个在野利用零日，与 BlueMoon 利用套件

两者均已确认在野利用，CISA 已列入 KEV 目录，联邦文职机构的修复期限是 2026 年 9 月 22 日——该期限已过。CVE-2026-85880 由 Volexity 与 Proofpoint 的 Mark Kelly、David Galazin、Jeremy Hedges 发现并报告，是继 2023 年 1 月 CVE-2023-21674 之后微软修复的第二个 ALPC 零日，也是近四年来 ALPC 组件第二次出零日。影响面覆盖 Windows 10 1607/1809/21H2/22H2 与 Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 等多个版本，含部分 Server Core 安装。

这两个漏洞正被打包进代号 BlueMoon 的利用套件，把 ALPC 与两个 Chrome 零日串成链条，据 Proofpoint 与 Volexity 的观察，已被多个与间谍活动对齐的团伙武器化用于投递恶意载荷。

同一批里还有一批 CVSS 9.8 的硬骨头：远程桌面服务、DNS 服务器、DHCP 服务器、Services for NFS，均为网络可达、无需用户交互；Windows Shell 有堆溢出；SQL Server 有一个 CVSS 9.6 的注入；Microsoft Authenticator 有一个 CVSS 8.6 的认证不当问题——对依赖微软自家 MFA 工具的组织是额外风险。

处置优先级建议：先把 CVE-2026-85880 / CVE-2026-81963 当作紧急补丁补上；其次是 RDS、DNS Server、DHCP Server、Services for NFS；依赖微软 MFA 的组织并行打 Authenticator 补丁；SQL Server 紧随其后。974 这个量级本身会诱发补丁疲劳，用自动化工具保证覆盖面，而不是尝试逐条人工分诊。

7.2 Windows 11 26H1 出带外更新（KB5129194）

微软为 Windows 11 26H1 发了带外更新（arm64 与 x64，OS 内部版本 28000.2956，KB5129194），修两个洞：

这两个此前已露过面，其中 CVE-2026-62721 在 9 月补丁批次中还一度传出把远程桌面与 Hyper-V 打坏、需要出带外修的消息。

7.3 云与服务端：CVSS 10.0 与一批高危

CVE-2026-85889（CVSS 10.0） 是 Azure AI Foundry（即 Microsoft Foundry）里的关键功能缺失认证（CWE-306）：无凭据的攻击者可经网络触达并滥用某个后端功能，绕过本该把关特权操作的身份与访问控制。攻击向量网络可达、复杂度低、无需权限、无需用户交互。发现在微软协调漏洞披露计划下由研究员 Rémy Marot（@R_Marot） 报告，未观察到在野利用或公开 PoC。作为云服务漏洞，微软已在后端基础设施上完成修复——Foundry 用户无需打补丁、无需改配置。

同窗口还修了三个 Azure 家族严重漏洞，均在服务端缓解，无需客户动作：

7.4 新零日：Windows 桌面窗口管理器（DWM）

安全机构披露 Windows DWM 存在正被积极利用的零日 CVE-2026-20805：DWM 服务对 ALPC 消息处理不当，有本地访问权限的攻击者可发精心构造的 ALPC 请求触发，实现从普通用户到 SYSTEM 的提权。DWM 存在于每一台 Windows 桌面设备上，潜在影响面极广。这类内核组件漏洞一旦与任意代码执行链结合，可用于安装恶意驱动、关闭安全防护、窃取系统凭据或实施持久化。微软已确认在野利用。

另外两条：

• CVE-2026-65660：SharePoint 漏洞最初被微软列为欺骗（spoofing），实际可导致已认证 RCE。
• CVE-2026-45498（BigDiskBuster）：研究员公开了 PoC，可阻止 Microsoft Defender 更新。

7.5 AI 代理正在把攻击规模化

威胁情报公司 Greynoise 披露的一起事件值得单独记：一名攻击者针对 PaperCut NG/MF 打印管理软件的两个漏洞构建利用程序，随后部署数百个自主 AI 代理执行入侵，在 48 小时内于 48 个国家的 395 家组织里攻陷至少 440 台服务器，部分组织在 30 秒内即被攻破。

代理自动化完成了漏洞扫描、利用、凭据窃取与域接管的全过程，把传统需要数小时乃至数天的攻击压缩到数秒至数分钟，且代理能从失败经验中学习并调整策略，展现出超越脚本化攻击的适应性。PaperCut 在 8 月底紧急修了相关零日，但大量未打补丁的系统仍暴露在外。

7.6 供应链细节：NuGet 签名证书 9 月 23 日起轮换

微软从 2026 年 9 月 23 日起更新用于 NuGet 包的作者签名证书。依赖 trusted signer 策略或直接比对证书指纹的团队，必须在切换前把新证书加进去。

八、Windows 简报（5 条）

Insider 侧（9 月 25 日新构建）：Beta 26220.9568、Experimental 26340.9577，另有 Beta(26H1) 28020.3112、Experimental(26H1) 28120.3122。实验通道亮点是开始菜单的手机伴侣改成可滚动侧栏以展示更多近期活动，以及 Quick Settings 里直接出现「能源建议」。

九、其他简报

Azure

• Foundry Agent Service 加入原生实时语音智能体（公开预览）。关键在「原生」——传统语音智能体是「语音转文字 → 文本模型推理 → 文字转语音」的三段流水线，中间等待全算延迟；新路径走语音到语音，由实时语音模型直接处理语音输入并生成语音输出，保留语气、停顿与交流节奏，并支持打断与轮次判断。底座是 Voice Live API，把语音识别、生成式 AI、文本转语音、轮次检测、打断处理收进一个统一实时接口。可选模型包括 GPT Realtime、Azure Realtime 与微软自家的 MAI 系列，也支持自带模型。覆盖 80 多种语言、140 多个区域设置。已有 Foundry Agent Service 智能体的团队，其工具调用、知识库、记忆、内容安全防护与企业数据集成可继续沿用；部署出口包括 Web 应用、Microsoft Teams、Teams Phone 以及 Twilio 的呼入呼出电话系统。
• Foundry Routines 公开预览：Foundry Agent Service 的原生触发器原语，用来让已发布的智能体自动运行。此前生产智能体要按计划或按业务事件跑，得自己拼 Logic Apps、Azure Functions、webhook、队列、自定义存储以及单独的标识与角色分配——智能体在 Foundry 里受治理，但触发层是客户自有基础设施，有自己的配置、监控与故障模式。Routines 提供循环计划、一次性延迟定时器、以及经受支持连接的事件触发，把触发、执行与可观测性都留在受治理的 Foundry 工作区内。预览版不覆盖生产 SLA。
• 托管智能体的出站网络管控公开预览：客户可编写按顺序匹配目标主机的规则（支持 *.contoso.com 这类 FQDN 通配），动作为允许、拒绝、转换出站请求头或重写目标。规则存放在智能体的 Responsible AI 策略里，在 Foundry 托管的沙箱内、流量离开运行时之前执行，基础的白名单场景不再需要独立网络设备。两种执行模式：audit（记录「本会拒绝」的决定但不阻断）与 enforce（直接阻断），可以先观察真实流量再开启强制。每条出站决定都发到 Application Insights 供审计。10 月还会扩展与 Azure API Management 的集成，预览支持新的 AI Gateway 层。
• 把 Foundry 智能体发布到 Microsoft 365 Copilot 与 Teams 正式可用：此前 Foundry 开发者没有原生路径把智能体投放到 M365，得另做部署流水线、bot 注册与应用清单。现在可以直接从 Foundry 门户发布，用户在本来就在用的界面里发现它，同时智能体继续受 Entra 与 Agent 365 的控制治理。
• Foundry Insights 与 Agent Optimizer（本月底 GA）：Insights 把生产环境的 trace 变成可诊断的发现（首次扫描审查过去 7 天的 trace）；Agent Optimizer 则针对指令、工具、skill 与模型选择生成候选改进并评估，上线前就告诉你哪项改动真的有效。配套还有开源的 run-assert-eval Skill，把微软三个开源工具串成一条工作流——Clarity 暴露开发者可能漏掉的风险，ASSERT 把需求转成可度量评估，Agent Control Specification（ACS） 在智能体不达标处施加针对性运行时控制，最后重跑评估确认改进成立且没有限制正常行为。
• Agent 治理进管理中心：Foundry 智能体的启用/禁用动作已 GA，进入 Microsoft Admin Center 的 Agent 365 治理面，管理员无需开发者介入即可控制智能体在组织内是否可用；block / unblock / delete / restore / 重新分配所有者等操作持续扩展。而且这些操作由 Foundry 运行时强制执行，不只是记在目录里。
• 数据与计算：Azure Database for PostgreSQL elastic clusters 支持 PostgreSQL 18（由 Citus 14.0 驱动）；Flexible Server 新增逻辑复制槽同步状态指标 logical_replication_slot_sync_status；面向 SAP 的 Mdsv4 / Msv4 系列内存优化 VM 公开预览（第 6 代 Intel Xeon 可扩展处理器 + Azure Boost）；Azure Payments HSM v2 公开预览（单租户支付 HSM，PCI 场景）。
• 平台：Azure Functions 支持 PowerShell 7.6 正式可用；Ephemeral OS Disk 全缓存 GA（VM 与 VMSS）；Playwright Workspaces 在选定区域 GA；App Service 可作为托管连接器的触发目标；Azure Virtual Network Manager 默认支持最多 3,000 个虚拟网络的高规模网状连接；Azure Sphere OS 26.09 GA。
• 需要排期的退役与变更：Check Inventory API 已于 9 月 25 日退役，集成要迁到新的 Check Inventory by Resource Type API；SQL Data Sync 自 9 月 9 日起阻止新部署，2027 年 9 月 30 日退役；Azure 预留交换将在 2027 年 2 月 1 日起终止——对该日期前购买的既有预留只给一次最终交换机会（这条对 FinOps 与承诺策略影响最大）；Azure Virtual Desktop classic 于 2026 年 9 月 30 日退役，之后连接 classic 资源会被阻断；Node.js 22 在 Functions 上退役。

硬件 / Surface（Snapdragon Summit 2026，Maui）

• Surface Pro 12 英寸（$1,149.99 起）与 Surface Laptop 13 英寸（$1,199 起）换用 Snapdragon X2 Plus（6 核）。宣称相比上代：Office 工作负载最多快 17%、电池效率高 18%、图形性能提升 60%+、本地 AI 推理最高快 95%（Hexagon NPU 80 TOPS）。
• Surface Pro 12：无风扇设计，500 nit 的 25% 提亮 PixelSense 触屏（2196×1464，最高 90 Hz），16 / 24 GB LPDDR5x，256 / 512 GB，机身 86% 再生材料，预估本地视频播放约 15.5 小时、网页浏览 13 小时，另有可选 5G 配置，新增黑色。
• Surface Laptop 13：3:2 500 nit 触屏（1920×1280，60 Hz），两个 USB-C（USB 3.2）+ 一个 USB-A + 3.5 mm，Wi-Fi 7、蓝牙 5.4，宣称最高 22.5 小时电池。
• Microsoft Ink Canvas 预装在 Pro 12 上：面向手写笔的 AI 体验，可直接在画布上勾画、批注、生成图像与总结文本。
• Surface Mouse（$799 起）带触觉反馈与可自定义的 Copilot 按键，蓝牙 6.0 可多设备配对，30% 再生材料。安全与可管理性从芯片到云内置：Secured-core PC 防护、含 TPM 2.0 的 Microsoft Pluton、基于 Secure Patina Core 与 Project Mu 开源组件构建的 Surface UEFI（经 Open Device Partnership 提供）。
• 三者均于 10 月 13 日在部分市场上市，同日通过 Surface for Business 面向商用客户。

开源 / 社区

• AG-UI .NET SDK 以 MIT 许可发布在 NuGet，与 TypeScript / Python SDK 同居上游仓库。
• Aspire Dashboard 更新至 13.5.4；Aspire 已从「.NET Aspire」更名为「Aspire」，版本从 9.x 跳到 13，定位为多语言平台，Python、JavaScript、Next.js、Go、Bun 均已一等公民化，TypeScript AppHost GA，并新增 aspire do 发布流水线、Kubernetes 部署（预览）与 MCP 服务器。
• run-assert-eval Skill 开源，串起 Clarity / ASSERT / ACS 三个工具。

本周报基于公开报道整理，仅供参考。财务/股价类信息已按周报口径过滤舍弃，同一事件不同来源的统计口径差异已并列标注而非取单一数字。