Microsoft 发布 Windows 混合智能架构：端侧代码模型与 Agent 安全容器 MXC
发布信息 ：微软官方发布于 2026 年 10 月 7 日（美国当地日期） ；按旧金山发布会所在时区换算，北京时间为 2026 年 10 月 8 日
一、核心进展
2026 年 10 月 7 日，Microsoft 发布面向 Windows 的 Hybrid Intelligence（混合智能）方案，重点不是推出单一大模型，而是把端侧推理、云端模型调度与 Agent 执行隔离整合到系统平台中。
1. 端侧代码模型与混合推理
- MAI Code 1.1 Flash ：微软介绍其模型具有 137B 总参数、6.8B 激活参数 ，通过 3-bit 量化 降低本地模型体积，并支持 256K 上下文窗口。
- 本地---云端路由 ：Windows 与 GitHub HydraFusion 配合，计划让代码任务按需求选择本地或云端模型；相关 GitHub Copilot/VS Code 集成预计于 2026 年 10 月下旬进入实验性预览。
- 运行时支持 ：Windows ML 宣布支持
llama.cpp，扩展本地开源模型的部署方式。
2. Microsoft Execution Containers（MXC）
MXC 是面向 Agent 和动态生成代码的策略驱动型执行隔离层。开发者可定义 Agent 对文件、网络、进程和用户界面的访问权限，运行时由容器执行限制，而不是让模型自行决定权限。
| 隔离方式 | 典型场景 | 状态或范围 |
|---|---|---|
| Process Container | 轻量级工具执行、生成代码 | Windows / macOS / Linux |
| Session Container | 长时间运行、需要桌面交互的 Agent | Windows 11 |
| WSL Container | Linux 工具链 | Windows 11 |
| MicroVM | 风险较高、需要更强虚拟化隔离的工作负载 | 实验性 |
MXC 已宣布正式可用（GA）；不过 Agent 身份归因及部分组织管理能力仍属于后续计划，不能全部视为现已上线。
二、为什么重要？
传统 Agent 往往在应用层完成模型推理和工具调用，容易出现 "模型能调用工具，但缺乏独立权限边界" 的问题。微软的路线则把问题拆成两个系统层面：
- 推理位置优化：按任务的延迟、成本、隐私和算力需求，在本地与云端模型之间切换。
- 执行权限最小化：即便 Agent 被提示注入诱导或生成错误代码，也应受到独立执行环境的文件和网络策略约束。
对于代码 Agent、桌面自动化和长期运行的个人助手，这比单纯提高模型基准分数更接近真实部署需求。
三、与此前工作的关系
从早期的应用层工具调用和通用沙箱，进一步发展到 Windows 平台级 Agent 隔离 + 端云混合推理。其研究价值在于把模型推理效率与操作系统安全机制联合考虑。
但仍需独立验证：量化后代码任务准确率、路由策略的端到端收益，以及各类 MXC 容器抵御越权访问的实际效果。官方能力说明不等于完整的安全验证报告。
四、具体技术细节
- MXC：利用操作系统原生机制隔离 Agent
MXC 并不是重新实现一套虚拟化系统，而是将不同操作系统已有的隔离技术统一到同一个 SDK 和策略接口之下。
其架构可以简化为：
P.S. MXC 是 Microsoft Execution Containers 的简称，提供面向 AI Agent 的策略驱动沙箱执行环境，解决 Agent 生成的代码、工具和插件可以访问哪些系统资源的问题。
不同后端提供不同强度的安全隔离，并非所有后端都已达到相同的成熟度。MicroVM 等后端仍有实验性实现。
关键设计思想是：Agent 可以决定执行什么，但不能自行决定拥有什么权限。
例如，某个
Coding Agent需要修改Git仓库，却不应该读取用户私人文档。MXC可以通过文件系统白名单、只读路径及网络策略约束其执行进程，而不依赖LLM自觉遵守提示词。
- Windows Hybrid Intelligence：本地 MoE 模型 + 智能路由
微软此次公开的本地代码模型是 MAI-Code-1.1-Flash。
它采用 Mixture-of-Experts（MoE）结构，推理时只激活一部分参数。微软公开说明了三项核心技术：
- 低比特量化：将模型压缩到约
53GB，使大型代码模型能够在具备充足统一内存的设备上运行。 Speculative Decoding：使用草稿模型先提出候选token，再由目标模型验证，以提高解码吞吐。HydraFusion路由：根据任务上下文等因素，在本地模型与云端模型之间选择推理路径。
微软的实测配置还使用了 DFlash2 sliding-window speculative decoding 和基于 llama.cpp 的 Windows ARM64 CUDA 运行时。官方报告在 256K 上下文下峰值内存约 75.5GB，并建议使用超过 120GB RAM 的设备以获得较好的运行体验。
需要注意：HydraFusion 的具体路由模型、训练目标和完整决策算法尚未在这些技术文章中充分披露，不能断言它具体使用强化学习、某种分类器或哪一个数学优化方法。
- 官方量化实验结果
测试日期： 2026 年 10 月 5 日
来源： Microsoft《Bringing local models and sandboxed tools to Windows and GitHub Copilot》
| 模型 | SWE-Bench Verified ↑ | Terminal-Bench 2.1 ↑ |
|---|---|---|
| MAI Code 1.1 Flash（非端侧量化版） | 72.6% | 62.9% |
| GPT-OSS-120B（Unsloth GGUF） | 32.0% | 23.6% |
| MAI Code 1.1 Flash（端侧量化版） | 70.8% | 66.29% |
主要结论如下：
- MAI Code 1.1 Flash 在这两项官方测试中显著超过所选 GPT-OSS-120B 基线。
在 SWE-Bench Verified 上领先 40.6 个百分点；Terminal-Bench 2.1 上领先 39.3 个百分点。 - 量化没有造成明显的任务性能崩溃。
- SWE-Bench Verified：72.6% → 70.8%，下降 1.8 个百分点。
- Terminal-Bench 2.1：62.9% → 66.29%，反而提高 3.39 个百分点。
第二项得分提高不能直接证明量化提升了推理能力，可能与推理配置、采样及测试波动有关。官方没有提供足以判断统计显著性的多次独立重复实验。
- 目前不宜将其解释为全面领先。微软选用的 GPT-OSS 基线是 Unsloth GGUF 版本，而这组数字只覆盖两个代码与终端任务基准，不构成对所有模型、所有设置下能力的全面排名。
微软在官方技术博客中给出了四种主要执行环境。这部分是理解 MXC 系统架构的关键。
| 指标 | 官方数据 |
|---|---|
| 总参数量 | 137B |
| 每 token 激活参数量 | 6.8B |
| 量化精度 | 约 3.3 bits/weight |
| 量化后模型体积 | 53 GB |
| 模型体积压缩 | 约 80% |
| 256K 上下文峰值内存 | 75.5 GB |
| 64K 上下文 Prompt 处理吞吐 | 923.5 tokens/s |
| 128K 上下文 Prompt 处理吞吐 | 769.8 tokens/s |
微软官方还对 MXC 的三种策略运行模式进行了比较。
| 模式 | 未授权访问 | 是否记录活动 | 用途 |
|---|---|---|---|
| Enforcement | 拒绝 | 不生成该模式的活动报告 | 正式运行 |
| Learning | 拒绝并记录 | 是 | 调试权限策略 |
| Permissive | 允许并记录 | 是 | 观察实际资源访问需求 |
这是一种基于官方功能整理的建议流程，并非微软规定必须按此顺序操作。
尤其要注意：Permissive 不会强制执行所声明的访问限制，因此不应将它用于运行不可信代码。官方博客也说明，这些活动报告能力目前针对 Windows Process Container。