Agent 能写代码之后，下一个问题立刻浮出来：这段代码在哪跑。让模型输出的脚本直接碰你的开发机，等于把家门钥匙交给一个多数时候靠谱、偶尔抽风的实习生；用 Docker 隔一层，又很快会遇到「容器逃逸、挂载目录、网络默认全通」这些老问题。微软 2 月创建、本周在 Show HN 上获得关注的 MXC（Microsoft eXecution Container）给出了一个系统化的答案：把「怎么隔离」抽象成一份声明式策略，把「用什么隔离」藏进九种可替换后端，三语言 SDK 一装就用。这篇实战把它在 macOS 上完整跑一遍，并把策略调优的流程走通。
一、MXC 解决的核心问题：策略与后端解耦
先看它官方给的架构图——应用通过 SDK 发起一次容器创建请求，请求里写清楚三件事：容器类型、隔离规则、要执行的命令。MXC 校验请求、选定后端、把工作负载放进容器：
- 你的应用（Launch API）→ MXC SDK（Rust / .NET / Node，进程内）→ 选中的后端（进程内）→ 被隔离的工作负载（ProcessContainer / WSLC / Bubblewrap 等）
这个分层听起来平淡，实际是它和「自己写 Docker 脚本」最大的区别。脚本方案里安全策略散落在启动参数、挂载配置、防火墙规则里，换一台机器就变一次形；MXC 把这些全部收敛进一份版本化的 JSON schema，有 stable 目录、有校验、有诊断，策略本身成了可以 review、可以进版本库的代码。
后端清单按平台分三档：
| 运行平台 | 默认后端 | 其他后端 |
|---|---|---|
| Windows 11 x64 / ARM64 | processcontainer | windows_sandbox、wslc、microvm、hyperlight、isolation_session |
| Linux x64 / ARM64 | bubblewrap | lxc、microvm、hyperlight |
| macOS ARM64 / x64 | seatbelt | 无 |
标了星号的是实验性后端。注意 macOS 只有 Seatbelt 一个选项——它直接生成系统自带的 sandbox-profile，这也是苹果 App Store 沙箱同源的技术，日常隔离可信度足够。
二、五分钟跑起来
MXC 是 SDK 依赖，不需要克隆仓库。三个包管理器各有一个入口：crates.io 上的 mxc-sdk、nuget 上的 Microsoft.Mxc.Sdk、npm 上的 @microsoft/mxc-sdk。Node 和 .NET 的包内置了原生运行时产物，装完即可用；Rust 的 crate 会把 SDK、引擎和所选后端一起编进你的应用。
Node 侧最小可运行示例长这样：
import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';
const request: ContainerRequest = {
command: 'node -e "console.log(\'hello from container\')"',
network: { egress: { default: 'deny' } },
timeoutMs: 30_000,
};
const child = await spawn(request);三个要素齐了：命令、网络策略（默认拒绝出站）、超时兜底。把 command 换成模型生成的代码路径，这就是一个最小的 Agent 执行器。官方 samples 目录里还有流式标准输入输出的完整示例，适合需要交互式执行的场景。
如果暂时不想接 SDK，也可以直接用平台专属的执行器二进制（比如 Windows 上的 wxc-exec），接受符合稳定 schema 的 JSON 请求，适合测试阶段快速验证策略。
三、策略三件套：文件系统、网络、UI
MXC 的策略模型分三个维度，全部默认收紧：
文件系统策略：只读路径、读写路径、拒绝路径三个列表。给 Agent 的执行器通常是「工作目录可写、其余只读、密钥目录显式拒绝」的组合。
网络策略：出站默认拒绝，支持代理转发和按后端的主机过滤。这一条对 Agent 场景尤其关键——模型生成的脚本最常见的恶意或失误行为就是往外发数据，出口默认关死，再按需放行包管理器的域名，能把数据外带的风险压到最低。
UI 策略：剪贴板、显示器、GUI 访问各自独立开关。桌面 Agent（比如自动化测试机器人）需要碰 UI 时显式开，纯后端执行器全程关死。
一个值得强调的设计：请求先被校验，不合法的策略直接报错，不会「尽力而为」地降级执行。这比很多沙箱工具的静默降级要诚实得多。
四、策略调优 Playbook：debug 与 audit
真实程序在沙箱里跑，第一件事几乎必然是各种 access denied。MXC 为此准备了两条工作流。
诊断模式：执行器加 --debug 参数，标准输入输出留给工作负载，MXC 自己的诊断信息单独输出，能看到每一次被拒的访问和原因。先跑一遍收集拒绝清单，再逐项把合法访问加进策略。
审计模式：这条是给「策略作者」用的捷径。对一个你信任的工具跑 audit 模式，MXC 会记录它实际访问的所有文件与能力，自动产出一份策略草稿，你再人工收紧。要特别注意官方文档里的粗体警告：audit 模式会关闭被分析工作负载的全部沙箱保护，绝对不能用它跑不可信代码——它的正确用途是给「我自己的可信插件」建档，而不是给「模型输出的脚本」放行。
这套「先全拒绝、audit 收集、人工收紧」的流程，比常见的「先全放开、出事再堵」要安全一个量级，也是我把 MXC 推荐给团队时的核心理由。
五、后端选型的现实建议
按隔离强度和开销排个序，给不同场景对号入座：
- 完全不可信的模型输出：Hyperlight 或 MicroVM（Nanvix）。Hyperlight 是微软开源的微型虚拟机库，启动开销在毫秒级，能把每次执行的隔离成本压到接近进程级；Nanvix 走完整一点的 VM 路线。两者在 Windows 和 Linux 上可用。
- 半可信的内部插件：ProcessContainer（Windows 默认）或 Bubblewrap（Linux 默认），开销最小，配合默认拒绝的网络策略已经能挡住绝大多数事故。
- macOS 开发环境：Seatbelt 没得选，但配合文件系统策略的拒绝列表，日常隔离够用。
- 桌面自动化：Windows Sandbox 或 WSLC，前者隔离完整但重，后者适合需要 Linux 工具链的场景。
一个务实的迁移路径：开发与测试阶段用默认后端图省事，生产上线前把后端字段换成 Hyperlight，策略 JSON 一行不改——这正是策略与后端解耦兑现承诺的时刻。
六、合规与工程细节
几个容易被忽略但生产上要过的点：MXC 是 MIT 协议，商用无忧；官方构建有可选遥测，但默认关闭且需要用户显式同意、管理员策略允许、应用在请求里显式开启三个条件同时满足，本地自己编译的版本遥测直接是空操作；Rust 工具链锁 1.93，Node SDK 要求 Node 24 以上，接入前先对齐版本。仓库 10 月初仍在高频提交，diagnostics 文档对「为什么我的程序在容器里跑不起来」这类问题覆盖得相当细，踩坑时先翻它。
Agent 基础设施这条线上，沙箱执行是公认的最后一块硬骨头之一。MXC 的开源把「隔离策略工程化」这件事从各家自拼脚本变成了一个有 schema、有 SDK、有多后端的标准件，光是这一点就值得每个做 Agent 产品的团队认真评估。