1149 字
6 分钟
给 AI Agent 选沙箱：先决定是否共享内核
给 AI Agent 选择沙箱时，我不会先比较启动时间或 API 数量，而会先问：能否接受它与宿主机共享内核？ 这个答案会同时影响隔离、启动、资源、存储和调度。
如果没有先回答这个问题，参数表很容易把不同安全模型的产品放在一起比较，最后选到一个“启动很快”，但无法满足威胁模型的方案。
四类方案不是四个性能档次
常见方案可以按隔离位置理解：
| 方案 | 隔离主要发生在哪里 | 主要优势 | 主要代价 |
|---|---|---|---|
| 容器 | namespace、cgroup、capability | 启动快、生态完整 | 与宿主共享内核 |
| gVisor | 用户态系统调用拦截 | 缩小宿主内核暴露面 | 系统调用兼容与性能成本 |
| microVM | 独立 Guest Kernel 与虚拟硬件 | 内核边界清晰 | 启动、内存和调度更重 |
| Wasm | 受限指令与能力接口 | 体积小、能力边界明确 | 不能直接运行任意 Linux 程序 |
它们不是从低到高的统一档次，而是四种取舍。需要运行任意二进制、浏览器和编译器时，Wasm 通常不适合；执行不可信代码且后果较高时，共享宿主内核的容器又可能不够。
所以第一步不是选产品，而是写清威胁模型：
- 代码来自内部受控逻辑，还是任意用户输入；
- 是否接触凭证、私有代码和生产网络；
- 逃逸后的影响范围是单任务、单节点还是整个租户；
- 是否需要完整 Linux ABI。
隔离确定后，再比较七个工程角度
确定隔离模型后，再比较其他工程指标：
| 角度 | 需要回答的问题 |
|---|---|
| 启动 | 创建、恢复和可执行分别需要多久 |
| 资源 | CPU、内存和 PID 是软限制还是硬边界 |
| 存储 | 工作区如何持久化、复用和回收 |
| 调度 | 是否依赖 KVM、专用节点或本地状态 |
| 网络 | 出口策略能否按域名、身份和租户控制 |
| 镜像 | 环境如何分层、缓存和按需加载 |
| 观测 | 能否定位创建、执行、暂停和销毁阶段 |
这些问题在不同隔离方案中会得到不同答案。例如 microVM 的 Snapshot 可以减少 Guest Boot，却不能省掉节点选择和资源分配；Warm Pool 可以降低冷启动，却会增加容量管理与空闲成本。
因此，单个指标很少能够独立决定选型。详细机制分别放在后续专题中：资源模型、存储与 Warm Pool、镜像分层、网络出口和调度观测。
我的选择：先固定合同，再替换引擎
生产平台不应让业务代码直接依赖某个 Sandbox SDK。我更倾向于在上层保留统一合同：
Create → Ready → Execute → Pause / Resume → Destroy合同至少要统一 Workspace 身份、资源规格、网络策略、执行结果、TTL 和销毁语义。底层可以根据任务风险选择容器、gVisor 或 microVM。
这种 Facade 不是为了隐藏所有差异。KVM 依赖、网络能力和文件一致性仍需要显式暴露；它的作用是让差异停留在平台边界，不进入每个 Agent 的业务逻辑。
我的默认判断是：
- 内部受控任务优先选择容器，换取启动速度与生态；
- 不可信代码或高价值凭证场景，提高到 gVisor 或 microVM；
- 能力封闭、运行形态固定时，再评估 Wasm；
- 在真实工作负载上验证冷启动、系统调用、文件和网络行为。
最终选型不是“哪个引擎最好”，而是：
在目标威胁模型下，哪种隔离边界足够可靠，并且平台愿意承担它的启动与运营成本。
实现依据：为什么其他指标受隔离模型影响
- 容器共享宿主内核，创建成本主要来自 namespace、cgroup、文件层和进程启动。
- gVisor 增加系统调用拦截层，安全收益与兼容成本集中在 syscall 路径。
- microVM 需要 Guest Kernel、虚拟设备和 KVM，调度时还要确认节点能力。
- Wasm 通过能力接口访问宿主资源，运行边界清晰，但无法无条件兼容现有 Linux 工具链。
因此启动、资源和调度并不是独立参数，而是隔离边界在不同工程阶段的表现。