返回博客列表

当 AI Agent 开始自主执行代码，谁来兜底？微软 MXC 给出了操作系统级的答案

2026-06-18T16:00:00+08:00
MicrosoftMXCAI Agent沙箱安全Build 2026

当 AI Agent 开始自主执行代码，谁来兜底？微软 MXC 给出了操作系统级的答案

大纲

  • AI Agent 的信任困境：能力越强，风险越大
  • MXC 是什么：不是 Docker，不是 K8s，而是 OS 级的 Agent 执行边界
  • 四层 Containment 频谱：从进程隔离到 Micro-VM
  • JSON Schema + TypeScript SDK：开发者怎么用
  • 生态落地：OpenAI、NVIDIA、Manus、OpenClaw 已接入
  • Agent 365 + MXC：企业治理闭环
  • 对行业的意义：Containment 先于 Trust

当你让一个 AI Agent 写一段 Python 脚本并立即执行时，你怎么确保它不会 rm -rf /、连接一个 C2 服务器、或者读取你桌面上的工资单 PDF？

这不是假设场景。GitHub Copilot CLI、OpenAI Codex、Claude Code 这些工具每天都在生成并执行代码。Agent 的能力在飞速增长，但运行环境的安全模型还停留在"相信用户不会做蠢事"的阶段。问题在于——Agent 不是用户，它是一个非确定性的、由模型驱动的自主程序。

微软在 Build 2026 上给出了他们的答案：Microsoft Execution Containers (MXC)。

MXC 是什么：不是 Docker，不是 K8s，而是 OS 级的 Agent 执行边界

MXC 的核心定位很容易被误解。它不是一个容器编排系统（不与 Kubernetes 竞争），也不是一个传统的沙箱产品（不像 gVisor 或 Firecracker 那样独立部署）。MXC 是一个嵌入在 Windows 和 WSL 内核中的策略驱动执行层。

用一句话概括：开发者声明 Agent 需要什么权限，操作系统内核负责强制执行这些边界。

开发者定义 Policy → MXC SDK 生成 Config → OS 内核执行 Containment

这个设计的巧妙之处在于：开发者不需要管理底层的隔离细节（AppContainer？Session？Micro-VM？），MXC 提供了一个统一的抽象层，相同的 Policy 可以映射到不同强度的隔离后端。

四层 Containment 频谱：从进程隔离到 Micro-VM

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 级别的隔离边界。

JSON Schema + TypeScript SDK：开发者怎么用

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 状态保持一致。

生态落地：OpenAI、NVIDIA、Manus、OpenClaw 已接入

MXC 的生态合作伙伴名单值得仔细看看：

  • OpenAI：Codex 使用 MXC 执行环境安全地生成和运行代码。OpenAI 技术团队成员 David Wiesen 表示："结合 Codex 的能力与 MXC 的执行环境，我们的目标是帮助开发者从意图到可靠执行更快。"
  • NVIDIA：将 OpenShell 带到 Windows 上，基于 MXC 构建。OpenShell 提供了一个易于部署的包，用于安全运行自主、常驻的 Agent。
  • OpenClaw：已使用 MXC 在 Windows 上安全运行 node 和 gateway。
  • Manus：首席产品官 Tao Zhang 表示："MXC 给开发者提供了策略驱动的方式定义 Agent 可以访问什么，并在运行时强制执行这些边界。"
  • Hermes Agent（Nous Research）：将集成 OpenShell 和 MXC。CEO Dillon Rolnick 说："持续运行的本地 Agent 需要有意的隔离。MXC 提供了策略驱动的基础。"

这个名单的意义在于：MXC 不是微软的封闭生态锁定。它是一个开放 SDK，任何模型（GPT、Claude、Llama、DeepSeek）构建的 Agent 都可以接入。

Agent 365 + MXC：企业治理闭环

MXC 单独解决的是"containment"问题。但企业还需要"governance"——谁能部署 Agent？Agent 的行为可审计吗？策略怎么统一下发？

这就是 Agent 365 与 MXC 的集成价值所在：

  • Microsoft Entra：为每个 Agent 分配云身份，所有操作可追溯到具体 Agent
  • Intune：IT 团队通过策略统一下发 MXC containment 规则（如禁止访问某些文件路径）
  • Defender：实时检测 prompt injection 和其他 Agent 特有威胁
  • Purview：数据治理和合规审计

这意味着企业不需要为 AI Agent 建立一套全新的安全基础设施——用现有的 Entra + Intune + Defender 栈就能管理 Agent 的安全策略。

MXC 将首先在 Windows 11 24H2（Enterprise 和 Pro 版）中发布，Windows Server 2027 随后跟进。硬件要求——支持 VBS（虚拟化安全）和 SLAT（二级地址转换）的 CPU——在大多数现代商务设备上已是标配。

对行业的意义：Containment 先于 Trust

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人工智能时代，转载请注明出处。

觉得文章不错？分享给更多人！