Agent 运行时隔离：Docker、Firecracker、VM Sandbox 怎么选

一、为什么 Docker 不够

多份 Agent 安全实践与 OWASP GenAI 风险讨论都把不受信代码执行视为高风险场景，建议将 LLM 生成代码放入隔离执行环境。Docker 是大多数团队的第一反应——但它恰好也是最容易被误用的方案。

标准 Docker 容器（runc 运行时）的隔离机制是 Linux namespaces + cgroups。这个机制的核心问题是：容器与宿主机共享同一个 Linux 内核。命名空间提供了进程、网络、文件系统的视图隔离，但它们不是安全边界——它们是管理边界。

「Docker 容器不是虚拟机。它们是共享内核的进程包装器。」

这意味着什么？任何一个内核漏洞（CVE）都可以让容器内的恶意代码突破到宿主机。2019 年，AWS Lambda 团队用数据证明了这一点：QEMU 有 140 万行代码、上百个模拟设备、持续爆出 CVE。他们用 Firecracker——50,000 行 Rust 代码的极简 VMM——替换了 QEMU。AWS 的选择传递了一个清晰的信息：对于执行不受信代码的场景，即使是在云厂商内部，共享内核的容器也不够。

Docker 自己也承认了这一点。2026 年 4 月，Docker 推出 Docker Sandboxes 产品——Docker Sandboxes 使用 microVM 隔离、独立网络和每沙箱独立 Docker Engine。

这是本文要建立的第一个认知：Docker 是一个优秀的打包和分发工具，但它的默认运行时（runc）不是 Agent 代码执行的安全边界。对于 AI Agent 场景——Agent 可能被提示词注入诱导执行任意代码——我们需要更强的隔离。

Agent 执行的安全链条回顾

在本系列的第一篇（Agent 代码沙箱设计）中，我们构建了五层沙箱边界——从进程隔离到网络隔离。在第二篇（Agent 工具权限控制）中，我们定义了 Agent 能用什么工具。在第三篇（Agent 命令执行安全）中，我们实现了一个 Policy Engine 来审查每一条命令。这三层都是在同一个运行时环境内做管控。

本文回答的是下一个层面的问题：这个运行时环境本身应该用什么技术来隔离？当 Policy Engine 放行了一条命令，当 Agent 在沙箱内执行了代码，这个沙箱的底层隔离边界到底有多硬？是共享宿主机内核的容器边界，还是独立的硬件虚拟化边界？

二、隔离光谱：从 WASM 到完整 VM

运行时隔离不是一个二元选择（隔离 vs 不隔离），而是一个连续的光谱——从极轻量的语言级沙箱到完整的硬件虚拟化，每个层级在启动速度、内存开销和安全强度之间做出不同的取舍。

六种隔离技术速览

（数据来源：Zylos Research 2026-04 系统对比；NumaVM 2026-03 Firecracker 端到端基准测试；NextKick Labs 2026-01 Firecracker vs Docker 安全对比。）

注意：下表数字来自公开论文、厂商文档和第三方基准测试，适合作为量级参考；真实延迟和开销会随宿主机硬件、内核版本、镜像大小、存储层、网络模型和负载类型变化。

从光谱看关键分界线

这个光谱上有两条关键分界线：

第一条分界线：共享内核 vs 独立内核。Docker (runc) 在线的左侧——它共享宿主机内核。WASM 和 V8 Isolates 虽然在安全等级上比 Docker 更高（它们不直接暴露 Linux 系统调用），但它们的能力范围也极窄——WASM 不能执行 Shell 命令，不能访问文件系统（除非显式授权）。gVisor、Firecracker 和 Kata 在线的右侧——它们都提供了某种形式的独立内核边界。这是 Agent 生产部署的基线要求。

第二条分界线：软件拦截 vs 硬件隔离。gVisor 通过软件（用户态 Go 程序 Sentry）拦截系统调用，Firecracker 和 Kata 则依赖硬件虚拟化（Intel VT-x / AMD-V）。软件拦截更灵活、开销更小，但攻击面在软件层（Sentry 本身可能被利用）；硬件隔离是更强的边界，但需要 KVM 支持和额外的内存开销。

为什么 WASM 和 V8 Isolates 在最左端？

WASM（WebAssembly）和 V8 Isolates 提供了最高性能的隔离——启动时间亚毫秒级，内存开销不到 1MB。但它们的能力范围严重受限：WASM 模块无法直接执行系统调用，所有外部交互（文件系统、网络）都需要通过 WASI 接口显式授权。这使得它们非常适合纯计算沙箱——例如 Agent 调用一个 Python 函数做数学运算或 JSON 处理——但不适合需要完整 Linux 执行环境的 Agent 工具调用。

对于需要 Shell 命令、pip 安装、Git 操作等完整 Linux 能力的 Agent 场景，WASM 太窄了。我们需要的是：在保留完整 Linux 能力的同时，提供比 Docker 更强的隔离。这就是 gVisor 和 Firecracker 的位置。

三、微虚拟机实战：Firecracker 与 Kata Containers

如果只能从技术栈中选一个「甜点」位置——既有 VM 级别的隔离强度，又有接近容器的启动速度——那答案就是微虚拟机（microVM）。Firecracker 是这个品类的定义者，Kata Containers 是它的 Kubernetes 原生表亲。

Firecracker：50,000 行 Rust 的极简主义

AWS 在 2018 年发布 Firecracker 的动机很直接：Lambda 需要同时运行成千上万个租户的函数，QEMU 太重（140 万行代码、上百个模拟设备、持续爆出 CVE），但 Docker 共享内核又不能满足多租户隔离。Firecracker 的设计哲学是：只做创建 microVM 必需的极少数事情，其他一律砍掉。

这体现在几个硬数字上：

• 50,000 行 Rust 代码（QEMU 的 4%），攻击面极小
• 仅 3 个虚拟设备：virtio-block（块存储）、virtio-net（网络）、serial console（串行控制台）——对比 QEMU 的上百个
• 每 microVM 一个独立 VMM 进程——没有共享 daemon，单点故障不波及其他实例
• 每秒 150 个 microVM 创建（单宿主机），冷启动 ~125ms
• VMM 进程仅 ~5MB 内存，支持 20× 超分（测试），10× 超分（生产）

Firecracker 安全架构：双重同心环

Firecracker 的安全设计可以理解为两个同心环：

                  ┌──────────────────────────────────┐
                  │           外层：CPU 硬件边界         │
                  │   Intel VT-x / AMD-V 虚拟化扩展     │
                  │   任何 VM 逃逸都需要先攻破硬件边界    │
                  │  ┌────────────────────────────┐   │
                  │  │   内层：Jailer 沙箱          │   │
                  │  │   • chroot 隔离文件系统      │   │
                  │  │   • seccomp 限制 24 个系统调用│   │
                  │  │   • cgroup 资源限制          │   │
                  │  │   • 独立网络命名空间          │   │
                  │  └────────────────────────────┘   │
                  └──────────────────────────────────┘

外层是 CPU 硬件虚拟化——这是同一个 CPU 上不同 VM 之间的物理隔离。内层是 Jailer——一个 Firecracker 自带的二次沙箱进程，它通过 chroot、seccomp（仅允许 24 个系统调用）、cgroup 进一步限制 VMM 进程本身。即使攻击者突破了 microVM 的边界，还需要再穿过 Jailer 的隔离才能触达宿主机。

这种双重隔离的哲学来自 AWS 的 Lambda 运维经验。Lambda 每月处理数万亿次函数调用，Firecracker 的多租户隔离经过了超大规模验证。

现实世界的采用

（数据来源：E2B GitHub & 文档 2023–2026；AWS Compute Blog 2025-08；Docker Blog 2026-04-16。）

Kata Containers：Kubernetes 原生的 VM 级隔离

如果说 Firecracker 是「在 Lambda 场景中诞生的微虚拟机」，Kata Containers 就是「在 Kubernetes 生态中生长的安全容器」。Kata 的核心设计是：每个容器运行在一个专用的轻量级 VM 中，但对外暴露标准的 OCI 接口。对于 Kubernetes 来说，Kata 只是另一个 RuntimeClass——你可以用同样的 Pod spec，切换到不同的隔离级别。

# Kubernetes RuntimeClass 三级隔离策略
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: isolated        # gVisor — 中等隔离
handler: runsc
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: highly-isolated # Kata — 强隔离
handler: kata

Kata 3.0（2025–2026）是一次重大重写——从 Go 转向 Rust，性能提升显著。Kata 3.x 生态中可以使用 QEMU、Cloud Hypervisor、Firecracker、Dragonball 等后端；部分发行版和云厂商方案使用 Dragonball 做深度优化。

• 相比 Kata 2.0：开销减少 90%，启动速度提升 3×，密度提升 10×
• 支持多种 VMM 后端：QEMU、Cloud Hypervisor、Firecracker、Dragonball
• 内置 GPU 直通支持——这是 Firecracker 不具备的能力

Kata 的独特价值在于它弥合了「容器生态」和「VM 隔离」之间的鸿沟。如果你已经在 Kubernetes 上运行 Agent 工作负载，Kata 是升级隔离的最平滑路径——只需更改 RuntimeClass。

Firecracker vs Kata：怎么选？

选型原则：自建 Agent 沙箱平台 → Firecracker；已有 Kubernetes → Kata Containers。如果两者都要——例如需要 Kubernetes 生态但想要 Firecracker 的极致性能——Kata 可以使用 Firecracker 作为 VMM 后端（Kata + Firecracker 组合）。

四、gVisor：用户态内核的权衡艺术

gVisor 走了一条独特的路——它不在硬件层面做隔离（不像 Firecracker 用 KVM），也不在系统调用层面做过滤（不像 seccomp 在内核入口点拦截），而是在用户态实现了一个完整的 Linux 内核。

Sentry：用户态的系统调用拦截器

gVisor 的核心组件叫 Sentry——一个用 Go 语言编写的用户态内核。当一个在 gVisor 沙箱中运行的进程发起系统调用时：

1. 进程发起系统调用（如 openat）
2. 内核 seccomp 将系统调用重定向到 Sentry（用户态进程）
3. Sentry 在自己的内存空间中处理系统调用——验证参数、检查权限、执行逻辑
4. Sentry 通过一个受限的系统调用集合向宿主机内核发出真正需要的操作

关键：沙箱内的应用永远不能直接向宿主机内核发起系统调用。所有的系统调用都由 Sentry 在用户态代理执行。这意味着即使沙箱内的应用触发了一个内核 CVE，这个 CVE 需要宿主机内核执行恶意操作——但攻击者根本到达不了宿主机内核，他们只能到达 Sentry。

平台模式：Systrap vs KVM

gVisor 提供两种平台模式：

gVisor 的性能特征：非对称开销

gVisor 的性能开销不是均匀分布的——它在计算和 I/O 上表现出显著的不对称性（数据来自 Zylos Research 2026-04 和 Safeguard.sh 2023-12）：

• 纯计算（CPU-bound）：开销 <5%，接近原生性能。Sentry 只在实际触发系统调用时才介入。
• 文件 I/O：开销 10–30%。原因：每个文件操作都经过「沙箱进程 → Sentry → Gofer（文件代理进程）→ 宿主机文件系统」的路径，比直接系统调用多了 2 个用户态往返。
• 网络 I/O：吞吐量下降 20–40%。原因：Sentry 实现了自己的 TCP/IP 栈（基于 Google 的 netstack），而不是使用宿主机的网络栈。
• 系统调用密集型负载：性能下降 2–5×。原因：每个系统调用都需要在 Sentry 中上下文切换和处理。

这意味着：gVisor 是计算密集型 Agent 的最佳性价比选择（如模型推理、数据处理），但对于需要大量文件 I/O 的 Agent（如代码编译、大规模文件处理），I/O 开销可能成为瓶颈。

如果需要 GPU，请先验证当前平台支持情况。gVisor 有 GPU 支持文档，Kata 也有 GPU 直通路径；Firecracker 通常不是 GPU 直通的默认选择。

gVisor 的系统调用覆盖率

gVisor 的一个实际限制是：它只实现了约 200 个 Linux 系统调用（约占完整 Linux 内核的 70%）。大多数 Agent 工作负载只用到其中的一小部分，但某些特定场景可能碰到未实现的系统调用：

• ✅ 良好支持：文件操作（openat, read, write, close）、进程管理（fork, execve, wait4）、网络（socket, connect, sendto）
• ⚠️ 部分支持：某些 ioctl 子命令、高级网络特性
• ❌ 不支持：内核模块操作（init_module）、硬件直接访问（iopl）、某些特殊的文件系统操作

实际影响：绝大多数 Python/Node.js/Go Agent 工作负载在 gVisor 上运行良好。第三方逆向分析曾观察到 OpenAI Code Interpreter 环境中存在 gVisor 痕迹。

gVisor 安全模型：深度防御中的一道墙

从安全角度看，gVisor 提供的不是最硬的边界（硬件虚拟化），而是最窄的攻击面：

• 应用程序不能直接调用宿主机内核——所有系统调用由 Sentry 代理
• Sentry 是纯用户态 Go 程序——内存安全的语言，避免了 C 语言的缓冲区溢出类漏洞
• Gofer（文件代理）以最小权限运行——只能访问白名单目录
• 即使 Sentry 被攻破，攻击者仍然在 seccomp 沙箱内——有限的系统调用集合

gVisor 的定位是：比 Docker 强一个数量级，比 Firecracker 轻一个数量级。它适合的场景是：你需要比「共享宿主机内核」更强的隔离，但你的基础设施不支持 KVM（如某些云环境、CI 平台），或者你需要 GPU 支持。

五、Agent 运行时的集成模式

选定了隔离技术之后，下一个工程问题是：Agent 的工具调用如何接入隔离运行时？当 LLM 决定调用一个工具（如执行 Python 代码或 Shell 命令），实际的执行应该发生在隔离沙箱内。这个「接过去」的过程有五种主要模式。

五种集成模式对比

模式一：API 托管（E2B 模式）

这是最省心的方案：使用托管的沙箱服务。Agent 框架通过 API 创建沙箱、执行代码、获取结果。E2B 是这个模式的代表——它提供 Python/TypeScript SDK，Agent 只需一行 sandbox.run_code(code)，底层是 Firecracker microVM。

# E2B API 模式——Agent 代码示例
from e2b import Sandbox

# 创建一个 Firecracker microVM 沙箱（~80-200ms）
sandbox = Sandbox.create(template="python-3.12")

# Agent 生成的代码在隔离 microVM 中执行
result = sandbox.run_code("""
import os
import subprocess
# 即使在沙箱内执行危险操作，也无法影响宿主机
subprocess.run(["ls", "-la"])
print(os.getcwd())
""")

print(result.logs)  # 只能获取 stdout/stderr
sandbox.close()     # microVM 自动销毁

这种模式的优点明显——零运维、快速集成、已经过大规模验证（E2B 是 OpenAI Agents SDK 文档列出的托管沙箱客户端/提供商之一）。代价是每次调用增加 50–100ms 的网络 RTT，且在沙箱内产生的数据需要通过 API 传回。

模式二：gRPC sidecar（自建 Firecracker）

如果你需要自建沙箱平台（出于合规、成本或定制需求），gRPC sidecar 模式提供了低延迟的本地 Firecracker 集成。架构如下：

┌──────────────────────────────────────────────────────┐
│                    宿主机                              │
│  ┌─────────────┐    gRPC     ┌─────────────────────┐ │
│  │ Agent 进程   │ ←─────────→ │ Sandbox Daemon      │ │
│  │ (Python/Go) │  (localhost) │ (管理 microVM 生命周期)│ │
│  └─────────────┘             │ ┌─────────────────┐ │ │
│                               │ │ Firecracker VMM │ │ │
│                               │ │  ┌───────────┐  │ │ │
│                               │ │  │ microVM   │  │ │ │
│                               │ │  │ (Agent 代码)│  │ │ │
│                               │ │  └───────────┘  │ │ │
│                               │ └─────────────────┘ │ │
│                               └─────────────────────┘ │
└──────────────────────────────────────────────────────┘

Sandbox Daemon 维护一个预热的 microVM 池（warm pool）以消除冷启动延迟。当一个 Agent 请求执行代码时，Daemon 从池中取出一个已启动的 microVM，注入代码，执行，返回结果，然后将 microVM 归还池中或销毁重建。

Abhishek Dadwal 在 2026 年 1 月的实战报告中验证了这种模式的性能：通过 VM 池化，单次请求延迟从 8,700ms 降至 500ms——17 倍提升。配合 goroutine 并发池（10 个并发 worker），可以达到每秒处理数十个 Agent 代码执行请求的吞吐量。

模式三：OCI runtime（Kubernetes 原生）

如果你的 Agent 基础设施已经运行在 Kubernetes 上，OCI runtime 模式是最自然的集成方式。Google 的 kubernetes-sigs/agent-sandbox 控制器（2025 年 11 月发布）将这种模式产品化了：

apiVersion: agentsandbox.io/v1alpha1
kind: SandboxTemplate
metadata:
  name: python-agent
spec:
  runtimeClass: kata       # 或 runsc (gVisor)
  image: python:3.12-slim
  resources:
    cpu: "1"
    memory: "512Mi"
---
apiVersion: agentsandbox.io/v1alpha1
kind: WarmPool
metadata:
  name: agent-warm-pool
spec:
  templateRef: python-agent
  minSize: 5              # 始终保持 5 个预热沙箱
  maxSize: 20

Agent 框架通过 sandbox.run() API 请求执行，底层控制器从 WarmPool 中取出预热的 Pod，注入代码，执行，返回结果。这种模式的优势是：完全融入 Kubernetes 生态——监控、日志、资源限制、扩缩容都使用原生 K8s 机制。

模式四：vsock（零网络暴露）

Firecracker 独特的 vsock（virtio socket）机制允许宿主机和客户机之间建立一条不经过网络栈的内核级通信通道。传统的 TCP/IP 通信在宿主机-客户机之间需要经过虚拟网卡、网络命名空间和网络策略——vsock 完全绕过了这些。

安全价值：vsock 不创建网络接口，因此即使 microVM 内的 Agent 尝试进行网络扫描或出站连接，它无法通过 vsock 进行（vsock 是严格的点对点通道）。宿主机端可以精确控制通过 vsock 接收和发送的内容。

OpenAI 的 Harness/Sandbox 分离模式

OpenAI Agents SDK 提出了一个值得单独讨论的架构概念：harness（控制面）与 sandbox（计算面）的分离。

• Harness：控制面——LLM 调用、工具路由、用户审批、安全策略评估。这是「聪明的部分」。
• Sandbox：计算面——代码执行、文件操作、Shell 命令。这是「可能危险的部分」。

关键设计决策：凭证作为运行时配置注入 sandbox，而不是作为提示词内容。这意味着即使攻击者通过提示词注入读取了 Agent 的上下文（系统提示词、对话历史），他们也无法获取 API 密钥或数据库密码——这些信息只在 sandbox 创建时通过环境变量注入，不在提示词中。

这是一个重要的安全模式：将凭证通道与数据通道分离。数据通道（提示词、LLM 输出、工具调用参数）可能被攻击者观测或操纵；凭证通道（环境变量注入、secret manager 挂载）是单向的、不可读的。

六、大规模性能权衡

「隔离越强，性能越差」——这是大多数人对安全技术的直觉。在 Agent 运行时隔离场景中，这个直觉大致正确，但幅度可能比你想的小很多。

冷启动延迟的真实构成

冷启动是隔离技术的核心性能指标——它决定了 Agent 从「决定执行代码」到「代码开始运行」之间的等待时间。但「冷启动」在不同技术中意味着完全不同的事情：

（数据来源：NumaVM 2026-03 Firecracker 端到端基准测试；arXiv:2602.15214 Docker 启动分析；NextKick Labs 2026-01；Alibaba Cloud Kata 3.0 发布公告。）

一个重要的纠正：Docker 的实际冷启动

很多人认为 Docker 容器是「瞬间启动」的（~10ms）。这是对的——但只对了一小部分。arXiv:2602.15214 的研究首次系统分解了 Docker 容器的启动延迟：内核命名空间创建只需要 8–10ms（不到总时间的 1.5%）。真正的瓶颈是存储层操作——镜像层的挂载和文件系统准备占用了 300–800ms。

这意味着：从用户角度看，Docker 容器的实际冷启动和 Firecracker microVM 的冷启动（~125ms + 快照加载）在总体验上并没有数量级的差异。Firecracker 快照恢复（176ms）甚至可能快于某些 Docker 镜像的冷启动。

预热池：消除冷启动的银弹

预热池（warm pool）是解决冷启动问题的最有效技术——预先启动一组沙箱实例，当 Agent 请求到来时直接分配一个已运行的实例。其效果显著：

• AWS Lambda SnapStart：Java 函数冷启动从 6,100ms 降至 1,400ms（4.4× 提升）；对于 Firecracker 微虚拟机，快照恢复仅需 176ms（其中快照加载仅 25ms，通过 mmap 实现）
• VM 池化（Abhishek Dadwal 2026-01）：单次请求延迟从 8,700ms 降至 500ms（17× 提升）
• Google GKE Agent Sandbox：通过 SandboxTemplate + WarmPool，实现亚秒级沙箱分发

实例密度：内存是真正的瓶颈

选择隔离技术时，一个容易被忽略的因素是实例密度——单台宿主机上能同时运行多少个沙箱。这直接决定了基础设施成本。NextKick Labs 在 2026 年 1 月的实测数据（80GB 宿主机内存）：

关键发现：Firecracker 的实例密度几乎与 Docker 相当（1,778 vs 2,000）。Kata 3.0 通过 Dragonball VMM 将密度提升了一倍（485 → 1,000）。对于 AI Agent 工作负载来说，这意味着：使用 Firecracker 相比 Docker 不会显著增加基础设施成本。

什么时候性能开销不值得？

隔离不是免费的。以下场景中，额外的隔离开销可能不值得：

• 纯文本 Agent（无工具调用）：如果 Agent 不执行代码、不调用 Shell、不访问文件系统，隔离的多余开销是浪费。Docker + seccomp 足够了。
• 受信代码执行：如果 Agent 只执行团队自己编写的、经过 Code Review 的代码（如内部自动化脚本），Docker + 强化 seccomp + dropped capabilities 就能提供充分保护。
• I/O 密集型批处理：如果 Agent 的核心工作是文件处理（如大规模 ETL），gVisor 的 10–30% I/O 开销可能成为瓶颈。此时容器（无 I/O 开销）或 Firecracker（~3–11% CPU 开销，I/O 接近原生）更合适。
• 亚 10ms 延迟要求：如果 Agent 的执行延迟必须低于 10ms，只有 WASM 或容器能满足。但注意：大多数 Agent 场景中，LLM 推理延迟（数百毫秒到数秒）远远大于沙箱启动延迟。

七、决策框架：按风险等级选隔离

经过前六章的技术分析，最终的问题回到了工程决策上：我的 Agent 应该用哪种隔离？这不是一个技术问题，而是一个风险匹配问题。以下框架将 Agent 的能力场景映射到推荐的隔离方案。

风险等级 × 能力场景

七条决策规则

以下是七条硬性决策规则——每一条都直接对应一个「是/否」判断，帮助你在具体场景中快速定位：

1. 代码是 LLM 生成的吗？→ 是：至少 gVisor；生产多租户场景用 Firecracker。绝不要用裸 Docker。
2. 租户是否共享基础设施？→ 是：需要独立内核边界 → Firecracker 或 Kata。
3. 是否需要 GPU 直通？→ 是：排除 Firecracker → gVisor（2024–2025 新增 GPU 支持）或 Kata。
4. Kubernetes 是否为编排层？→ 是：使用 kubernetes-sigs/agent-sandbox 控制器；通过 RuntimeClass 切换 Kata 或 gVisor。
5. 是否需要亚 10ms 启动？→ 是：容器或 WASM；Firecracker 快照恢复仍需要 ~176ms。
6. 负载是否计算密集型且 I/O 较少？→ 是：gVisor 提供最佳的「性能-隔离比」。
7. 是否有合规审计要求？→ 是：VM 边界（Firecracker/Kata）是可被审计员理解和验证的标准隔离。

决策树

                         ┌─────────────────────────┐
                         │  Agent 是否执行代码？      │
                         └───────────┬─────────────┘
                         No          │          Yes
                         ▼           │           ▼
                  ┌──────────┐       │    ┌──────────────────┐
                  │ Docker + │       │    │ 代码来源？        │
                  │ seccomp  │       │    └────────┬─────────┘
                  └──────────┘       │    LLM 生成  │  人工编写
                                     │    ┌─────────┘  ┌──────────┐
                                     │    ▼            ▼          │
                                     │ ┌────────┐  ┌──────────┐   │
                                     │ │ 是否    │  │ Docker + │   │
                                     │ │ 多租户？│  │ 强化配置  │   │
                                     │ └──┬──┬──┘  └──────────┘   │
                                     │ 是│  │否                     │
                                     │  ▼  ▼                       │
                                     │ ┌────────┐ ┌──────────┐     │
                                     │ │Firecrkr│ │ 需要 GPU？│     │
                                     │ │或 Kata │ └──┬──┬────┘     │
                                     │ └────────┘  是│  │否        │
                                     │              ▼  ▼           │
                                     │        ┌──────┐ ┌────────┐  │
                                     │        │gVisor│ │Firecrkr│  │
                                     │        │或Kata│ │或 gVisor│  │
                                     │        └──────┘ └────────┘  │
                                     └─────────────────────────────┘

开源工具速查

阿里云安全沙箱：Kata 3.0 的实践验证

阿里云容器服务 ACK 的安全沙箱运行时（基于 Kata Containers + Dragonball VMM）提供了经过大规模验证的生产数据：相比社区 Kata 2.0，阿里云安全沙箱 v2 实现了90% 的开销降低、3 倍启动速度提升、10 倍密度提升。这证明了：通过正确的 VMM 选择（Dragonball 替代 QEMU）和深度优化，微虚拟机隔离可以在大规模生产环境中达到与容器接近的效率。

常见问题

下一步阅读

📚 相关阅读

• Agent 代码沙箱设计：从进程隔离到网络隔离的五层边界架构
• Agent 工具权限控制：RBAC、ABAC 与审批流设计
• Agent 命令执行安全：Shell、文件系统、网络访问的风险边界
• Agent 错误恢复与自愈：当 Agent 搞砸了怎么办