当你让一个 AI Agent 写一段 Python 脚本并立即执行时，你怎么确保它不会 rm -rf /、连接一个 C2 服务器、或者读取你桌面上的工资单 PDF？
这不是假设场景。GitHub Copilot CLI、OpenAI Codex、Claude Code 这些工具每天都在生成并执行代码。Agent 的能力在飞速增长，但运行环境的安全模型还停留在"相信用户不会做蠢事"的阶段。问题在于——Agent 不是用户，它是一个非确定性的、由模型驱动的自主程序。
微软在 Build 2026 上给出了他们的答案：Microsoft Execution Containers (MXC)。
MXC 的核心定位很容易被误解。它不是一个容器编排系统（不与 Kubernetes 竞争），也不是一个传统的沙箱产品（不像 gVisor 或 Firecracker 那样独立部署）。MXC 是一个嵌入在 Windows 和 WSL 内核中的策略驱动执行层。
用一句话概括：开发者声明 Agent 需要什么权限，操作系统内核负责强制执行这些边界。
开发者定义 Policy → MXC SDK 生成 Config → OS 内核执行 Containment
这个设计的巧妙之处在于：开发者不需要管理底层的隔离细节（AppContainer？Session？Micro-VM？），MXC 提供了一个统一的抽象层，相同的 Policy 可以映射到不同强度的隔离后端。
MXC 提供了四个层级的 containment 选项，形成一个"频谱"而非单一方案：
| 层级 | 后端 | 隔离强度 | 启动开销 | 适用场景 |
|---|---|---|---|---|
| 进程隔离 | ProcessContainer | 轻量 | 极低（ms 级） | Coding Agent、快速迭代 |
| 会话隔离 | IsolationSession | 中等 | 低 | 长运行 Agent、UI 自动化 |
| Micro-VM | NanVix / Hyperlight | 强 | 中 | 处理敏感数据、不可信代码 |
| Linux 容器 | WSL + LXC/Bubblewrap | 中等 | 中 | Linux-first Agent 工具链 |
进程隔离是最轻量的选项。Agent 生成的代码在一个专用进程中运行，该进程的文件系统和网络访问被限制在 Policy 声明的范围内。GitHub Copilot CLI 已经采用了这个方案——当 Copilot 生成并执行 shell 命令时，它在 MXC 进程隔离中运行，无法访问 Policy 之外的文件。
会话隔离更进一步。Agent 在独立的 Windows Session 中运行，拥有自己的桌面、剪贴板和输入设备。这解决了 UI 欺骗、输入注入和跨会话数据泄露的问题。每个 Session 绑定一个独立的本地 ID 或 Entra 云身份，所有操作都可追溯到具体的 Agent 身份。
Micro-VM 是安全边界最强的一层。它使用 hypervisor 级别的硬件隔离（类似 Firecracker），但启动时间仍然是毫秒级。这对于处理高价值数据或运行完全不可信的第三方代码的 Agent 至关重要——即使 Agent 发现了进程级沙箱的逃逸漏洞，Micro-VM 的 hypervisor 边界也能阻止它。
Linux 容器通过 WSL 将 containment 模型扩展到 Linux 生态。Agent 可以在 WSL 中使用 LXC 或 Bubblewrap 后端运行 Python ML 框架和 Linux 工具链，同时保持 OS 级别的隔离边界。
MXC 的配置完全通过 JSON 声明。一个典型的 Agent 执行配置：
{
"version": "0.6.0-alpha",
"process": {
"commandLine": "python -c \"print('hello from sandbox')\"",
"workingDirectory": "C:\\sandbox"
},
"filesystem": {
"readonlyPaths": ["C:\\tools"],
"readwritePaths": ["C:\\sandbox\\tmp"]
},
"network": {
"allowOutbound": false
},
"timeoutMs": 30000
}
TypeScript SDK @microsoft/mxc-sdk 提供了两种 API 模式：
一次性执行（One-shot）——适合短生命周期的代码执行：
import { spawnSandboxFromConfig, createConfigFromPolicy } from '@microsoft/mxc-sdk';
const config = createConfigFromPolicy({
version: '0.6.0-alpha',
filesystem: {
readonlyPaths: ['/usr/local/lib'],
readwritePaths: ['/tmp/agent-workspace'],
},
network: { allowOutbound: false },
timeoutMs: 30_000,
});
config.process!.commandLine = 'python analyze_data.py';
const child = spawnSandboxFromConfig(config, { usePty: false });
child.stdout!.on('data', (d) => process.stdout.write(d));
状态感知生命周期（State-aware）——适合长运行的 Agent 会话：
import {
provisionSandbox, startSandbox,
execInSandboxAsync, stopSandbox,
deprovisionSandbox,
} from '@microsoft/mxc-sdk';
// 多步骤生命周期：provision → start → exec → stop → deprovision
const sandbox = await provisionSandbox(config);
await startSandbox(sandbox);
const result = await execInSandboxAsync(sandbox, 'python train_model.py');
await stopSandbox(sandbox);
await deprovisionSandbox(sandbox);
这种 lifecycle 模式特别适合需要多轮交互的 Agent：先 provision 环境，然后反复执行多个步骤，最后清理。整个过程 sandbox 状态保持一致。
MXC 的生态合作伙伴名单值得仔细看看：
这个名单的意义在于：MXC 不是微软的封闭生态锁定。它是一个开放 SDK，任何模型（GPT、Claude、Llama、DeepSeek）构建的 Agent 都可以接入。
MXC 单独解决的是"containment"问题。但企业还需要"governance"——谁能部署 Agent？Agent 的行为可审计吗？策略怎么统一下发？
这就是 Agent 365 与 MXC 的集成价值所在：
这意味着企业不需要为 AI Agent 建立一套全新的安全基础设施——用现有的 Entra + Intune + Defender 栈就能管理 Agent 的安全策略。
MXC 将首先在 Windows 11 24H2（Enterprise 和 Pro 版）中发布，Windows Server 2027 随后跟进。硬件要求——支持 VBS（虚拟化安全）和 SLAT（二级地址转换）的 CPU——在大多数现代商务设备上已是标配。
The Futurum Group 的 VP Mitch Ashley 说了一句关键的话：
"身份归属是绑定每一个 Agent 操作到可审计身份的承重元素。Agent 构建者和平台团队现在需要基于 OS 强制执行的权限和身份模型来设计。"
这揭示了一个行业级的认知转变：AI Agent 的信任不是通过更好的模型来建立的，而是通过更好的 containment 来建立的。
一个 99.9% 准确的模型仍然可能在 0.1% 的情况下做出危险操作。Containment 确保这 0.1% 不会造成实际损害。MXC 的设计哲学正是基于这个认识：不假设 Agent 永远正确，而是假设 Agent 一定会犯错，然后限制犯错的影响范围。
MXC 目前仍在 early preview 阶段，微软明确表示当前的策略"过于宽松"，会在正式发布前收紧。但方向已经清晰：当 Agent 从"回答问题"进化为"自主行动"，操作系统必须成为安全的最后一道防线。
Windows 正在把自己重新定位为 AI Agent 时代的可信运行时——不是因为模型更强，而是因为 containment 更深。
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。