微软在 2026 年 10 月 7 日的 Windows 与 Surface 发布会上，把三件事捆成一个名字讲：hybrid intelligence。一台 137B 的 MoE 编码模型能下载到本地跑；GitHub 的 HydraFusion 多模型路由器开始把本地模型纳入调度；一套叫 MXC 的 Agent 执行沙箱正式 GA。端侧模型不稀奇，稀奇的是这次上端侧的是 137B 量级、而非 7B 级补全玩具，真正决定它能不能用的，是内存和 Agent 治理这两件「不性感」的事。
模型本体 MAI-Code-1.1-Flash 是 Mixture-of-Experts：总参数 137B，每 token 激活 6.8B，上下文 256K。端侧版用约 3.3 bit/weight 的混合精度量化，权重压到约 53GB，比 bfloat16 云端版小约 80%，同时保留完整 256K 窗口。跑在 Surface Laptop Ultra（NVIDIA RTX Spark，最高 128GB 统一内存）上，256K 满载峰值内存 75.5GB；64K 上下文 prompt 吞吐 923.5 token/s，128K 下 769.8 token/s。微软给的「最佳性能」建议是 120GB 以上内存——这是推荐值，不是硬下限。
为什么是 MoE：137B 装进消费级显存的原理
MoE 这个结构本身就是省显存的关键：每生成一个 token 只激活一小部分专家参数，静态权重虽大，动态计算量却低。这也解释了为什么能把 137B 压到 53GB 还能跑——前提是量化到位、统一内存装得下激活路径上的那部分。
量化落地的两个杠杆与代码任务的敏感性
量化怎么落地，两个杠杆。位宽下降（约 3.3 bit/weight）省的是静态权重占用；投机解码 DFlash2 用小草稿模型先提议 token 块、再让目标模型校验，省的是端到端延迟。技术栈上这次跑在 Windows ARM64 的 llama.cpp CUDA 运行时，Windows ML 也接入了 llama.cpp。这里有个工程现实：llama.cpp 的 CUDA 后端依赖匹配版本的 CUDA 工具链，ARM64 + CUDA 的组合对驱动和运行时版本更挑剔，装之前先确认工具链版本对齐，否则容易卡在初始化。
代码任务对量化比自然语言更敏感。自然语言错一个词还能读，代码错一个 token 可能就是语法错误、错标识符、无效 tool call 或坏 diff。所以 SWE-bench Verified 上 70.8% vs 云端 72.6% 那 1.8 个百分点，比看起来要紧——厂商自测、尚无独立复现，换到你自己的仓库 agent loop 里是否稳定，目前没有公开数据。
基准（微软 2026-10-05 自测，三列均标注为厂商自测、无独立复现；GPT-OSS 一列是社区 GGUF 构建，非对等测试）：
| 基准 | 云端全精度 | 端侧量化 | GPT-OSS-120B(社区 GGUF) |
|---|---|---|---|
| SWE-bench Verified | 72.6% | 70.8% | 32.0% |
| Terminal-Bench 2.1 | 62.9% | 66.29% | 23.6% |
Terminal-Bench 2.1 上量化版反而高（66.29% vs 62.9%），大概率是评测噪声或采样差异，别当成「量化提升质量」。
和 6 月发布的 1.0 相比，官方称 token 流速度 +25%、完成任务所需 token -25%、成本降到 1/4；Copilot CLI 的 Terminal-Bench 2.1 +22%，.NET 任务 +15%。生产侧指标是 code survival +4%、回访 +9%。
多模型路由：HydraFusion 把本地模型纳入调度
本地模型不是独立入口，是被路由进去的。HydraFusion 始于 2026 年 9 月研究预览，建在更早的 HyDRA 上——后者按推理、代码生成、调试、工具调用四类信号给任务打分。HydraFusion 据此在三种模式里挑：Single（一个模型做完）、Cascade（便宜模型起草、质检不过再升级）、Critique（一个模型起草、另一个不带工具的评论者只读评审）。对照基线是 Claude Opus 5（同工具同限制）：
| 基准 | 成本 vs Opus 5 | 质量 vs Opus 5 |
|---|---|---|
| TerminalBench 2.1 | -67% | +4.9 pt |
| DeepSWE | -36% | -1.5 pt |
| CheckpointBench | -65% | -0.1 pt |
10 月 7 日更新把 HydraFusion 扩到 Windows 本地模型：一条路自动编排（Copilot 综合任务上下文与 cache 状态在本地/云端间路由），一条路显式选（Windows ML provider 选 MAI Code 1.1 Flash，或接 OpenAI 兼容本地端点）。本地调用零推理费，计费只按实际调到的云端模型标准费率走。
工程约束里有两条对 Agent 关键：隔离评审——评论者跑在无工具上下文、不能改仓库；工作流取消或校验失败时不打补丁，避免半成品 diff 进库。Cascade 还有个隐藏成本：升级途中被打断，仓库不落补丁，但账单上已发生的 token 不会退。
路由类方案的信任痛点很典型：开发者反馈「质量不比全程 Opus 5 差太多，但额度只有平时 10%」，同时抱怨看不到实现阶段到底用了哪个模型、AIC 计数与 CLI 计数对不上。你得能看见它替你做了什么决定，否则没法对账。
OS 级沙箱：从跑得动到能碰什么
把 Agent 真正放进来，问题从「跑不跑得动」变成「能碰什么」。MXC（Microsoft Execution Containers）10 月 7 日 GA（Windows 11 商业客户），定位策略驱动的执行层，可约束模型输出、插件、工具、harness 或整个 agent。关键设计是策略在 agent 工作负载之外——agent 或它生成的代码不能给自己加权限。开发者用统一 JSON schema + 多语言 SDK 声明资源需求，MXC 映射到对应后端，在 Windows / macOS / Linux 一致执行。四个后端：
| 后端 | 可用性 | 特点 |
|---|---|---|
| Process container | Win11 / macOS / Linux | 轻量；分别用 AppContainer / Seatbelt / Bubblewrap |
| Session container | 仅 Win11 | 独立 Windows 账户与会话，隔离桌面、剪贴板、UI、输入 |
| WSL container | 仅 Win11 | 面向 Linux 工具链 |
| MicroVM | Win11 + Linux，实验 | 硬件强隔离 |
策略覆盖 containment、process、file system、network、user interface 五个面。三种运行模式要分清：Enforcement（越界即拦，生产用）、Learning（照样拦但把被拒操作记进 JSON 报告，用来补权限）、Permissive（记录但放行，只用于策略调试，非强制）。
落地状态得诚实标：MicroVM 实验性；Intune 集中管理策略尚未 GA；Entra / Agent 365 身份与审计接入还在路上。已支持 MXC 的有 GitHub Copilot、OpenAI Codex、OpenClaw、Replit、LM Studio、NVIDIA OpenShell、Unsloth AI；Claude Code、Perplexity 等待接入。GitHub Copilot CLI 用 MXC 的 process isolation（Windows 上 ProcessContainer 的 BaseContainer 层，macOS 用 Seatbelt，Linux 用 bubblewrap），官方称本地后端不需要单独的 VM 或容器镜像。
一条常被忽略：本地推理不等于整个会话离线。远程工具调用和另发的云端请求，仍可能把工作送出 PC。MXC 管的是「能碰到什么」，不是「数据去了哪里」。
想动手，两条路。装 Foundry Local 拿一个 OpenAI 兼容端点（本地推理最省事的入口）：
winget install Microsoft.FoundryLocal
foundry model run qwen2.5-7b-instruct
foundry service status # 拿到
from foundry_local import FoundryLocalManager
from openai import OpenAI
manager = FoundryLocalManager("qwen2.5-7b-instruct")
client = OpenAI(base_url=manager.endpoint, api_key=manager.api_key) # 本地调用时 api_key 可填任意非空字符串
## 工具层自己加沙箱检查：只允许读写项目目录
## def read_file(path): # 解析后必须落在 PROJECT_ROOT 之内，否则拒绝
给 agent 写 MXC 策略，思路是写「需要什么」而非「禁止什么」（默认拒绝更安全）：
{
"containment": "process",
"filesystem": {
"readwrite": ["~/work/my-repo"],
"readonly": ["/usr/share/git"],
"deny": ["~/Documents", "~/.ssh"]
},
"network": { "outbound": false, "loopback": true },
"ui": { "desktop": false }
}
上面按策略面组织的结构为示意，实际字段以后端与 SDK 文档为准。推荐流程：先在 Learning 模式下跑，把「实际想访问但被拒」的项收集齐，再切 Enforcement 上生产。
把三条线合起来，适配人群其实很窄。有 128GB 级机器的重度 Agent 用户（全天跑 agent、上下文常年在 64K 以上、对代码隐私敏感），本地零单次推理费 + 256K 窗口是实打实收益。企业 IT / 平台团队该现在就写策略、跑 Learning 模式收集权限画像，把「给 agent 最小权限」从口头约定变成 OS 强制。普通笔记本用户被 120GB 推荐内存排除在外，Foundry Local 那条线（ONNX Runtime，CPU/GPU/NPU，8GB 起）才是入口；MXC 跨平台且开源，Linux 自托管 agent 的人也能直接用。
成本账别只看「零推理费」。本地推理把云端 OPEX 换成硬件 CAPEX + 电费 + 维护，是否更便宜取决于任务频次与硬件利用率。Surface Laptop Ultra 起步 $2,599。省的是按次推理费，付的是前置硬件与治理成本。
三块里最成熟的是 MXC（已 GA、跨平台、开源）；本地模型与 HydraFusion 的本地路由都还是 preview，性能数据目前全是厂商自测。还没接上的一环是治理：Intune 集中管控与 Entra 身份审计尚未 GA，「Agent 作为独立身份被许可和审计」仍是路线图。对要落地的人，先把 MXC 策略跑起来，比追那 1.8 个百分点更实际。
评论0