#代理沙箱技术深度研究报告：从开源微虚拟机到托管式代码执行环境的全面解析

#1. 执行摘要

随着“代理式人工智能”（Agentic AI）从实验性的聊天机器人向具有自主推理、规划和工具执行能力的智能体演进，安全代码执行（Secure Code Execution, SCE）已从边缘的运维需求跃升为核心的架构支柱。与传统的微服务不同，AI 代理（Agent）的工作负载具有高度的动态性、不可预测性和潜在的敌意性——它们编写并执行任意代码以解决开放性问题。这种范式的转变迫使基础设施在三个相互冲突的目标之间寻求平衡：不仅要实现甚至超越虚拟机的隔离强度，还要具备容器般的毫秒级启动速度，同时必须完美兼容庞大且复杂的 Python 数据科学通过生态系统。

本研究报告旨在对当前市场上四种主流的开源沙箱技术——Microsandbox、Wasmtime、Firecracker 和 gVisor——进行详尽的、正交的、微观层面的技术解构，并将其与完全托管的商业化方案 Google Vertex AI Agent Engine Code Execution 进行深度对比。

通过对架构内部机制、内核级交互、安全边界设计以及运行时性能特征的深入剖析，本报告揭示了该领域明显的二元分化趋势。以 Firecracker 和 Microsandbox 为代表的“硬件虚拟化”阵营，利用 KVM 技术提供了兼容标准 Linux 二进制文件的强隔离环境，尽管管理开销较高，但却是运行重型数据科学负载（如 Pandas/NumPy）的理想选择。以 Wasmtime 为代表的“语言级隔离”阵营，提供了极致的冷启动速度和计算密度，但在支持依赖复杂 C 扩展的现代 AI 库方面仍面临巨大的工程挑战。gVisor 则作为“用户态内核”的桥梁，在不引入完整虚拟化开销的前提下增强了容器安全性，但不得不以牺牲系统调用（Syscall）性能为代价。

相比之下，Google Vertex AI 提供了一种“无服务器黑盒”模式：一个预装了科学计算库的密封沙箱。它虽然消除了运维复杂性，但其严格的约束（如 30 秒超时、网络封锁）使其更适用于短生命周期的无状态逻辑，而非长周期的复杂代理任务。

本报告将为构建下一代安全 AI 基础设施的架构师、安全研究员及工程负责人提供权威的决策依据。

#2. 引言：代理计算时代的信任危机与架构挑战

#2.1 从对话到行动：计算范式的代际跃迁

大型语言模型（LLM）的初期应用主要集中在文本生成与对话交互。然而，随着 Transformer 架构理解能力的提升，行业重心已迅速转向“代理”（Agents）。代理不再是被动的问答机器，而是能够感知环境、自主规划并执行操作的实体。在这一过程中，代码生成与执行（Code Generation & Execution）成为了代理与数字世界交互的通用接口。

当用户指令代理“分析这份财务报表中的异常交易”时，代理并不会在其神经网络权重中进行浮点运算，而是会编写一段 Python 脚本，调用 Pandas 库读取 CSV 文件，使用 Scikit-learn 进行离群点检测，并利用 Matplotlib 绘制图表。这种“将 LLM 作为编排器，将代码解释器作为执行器”的模式，极大地扩展了 AI 的能力边界。

#2.2 根本性的安全悖论

这种能力的跃升引入了一个根本性的安全悖论：

1. 不可信的代码源：在传统软件工程中，代码由受信任的开发人员编写，经过严格的代码审查和 CI/CD 测试。而在代理架构中，代码由概率性的模型实时生成。这些模型不仅可能产生幻觉（Hallucination），编写出包含无限循环或资源耗尽逻辑的错误代码，更可能遭受“提示注入攻击”（Prompt Injection）。攻击者可以通过精心设计的自然语言指令，诱导模型生成恶意代码，试图读取文件系统敏感数据（如 /etc/passwd）、扫描内网端口或发掘算力进行挖矿。
2. 执行环境的二律背反：为了使代理具有实用性，执行环境必须足够灵活，能够访问文件系统、网络和复杂的第三方库；但为了安全性，环境必须被严格限制，被视为“高危区域”。
3. 时效性与状态性的冲突：代理任务通常是突发性的。一个用户可能会连续发送十个请求，每个请求需要运行一段仅耗时 200 毫秒的脚本。如果沙箱的启动时间需要 10 秒（如传统虚拟机），则用户体验将完全崩溃。同时，复杂的分析任务可能需要多轮对话，要求沙箱能够维持内存状态或文件系统状态，这与无服务器架构的无状态原则相冲突。

#2.3 传统容器技术的局限性

为何不直接使用 Docker？虽然 Docker 容器在应用部署中无处不在，但其依赖于 Linux 内核的 cgroups 和 namespaces 进行隔离。容器进程实际上是宿主机内核上的一个受限进程。历史经验表明，容器逃逸（Container Escape）漏洞（如 Dirty COW, runc CVE-2019-5736）层出不穷。对于运行完全不可信代码的场景，共享内核模型被广泛认为防御纵深不足。

因此，行业开始转向更深层次的隔离技术，包括微虚拟机（MicroVM）、用户态内核（Userspace Kernel）和 WebAssembly（Wasm）。下文将对这些技术进行详尽的剖析。

#3. 开源沙箱技术深度剖析

本章将深入技术底层，解构 Microsandbox、Wasmtime、Firecracker 和 gVisor 的架构原理、实现细节及优劣势。

#3.1 Microsandbox (ZeroCore-AI)：微虚拟机的民主化实践

Microsandbox 是一个相对较新的开源项目，其核心愿景是降低硬件虚拟化技术的使用门槛，试图打造“微虚拟机领域的 Docker”。

#3.1.1 核心架构：libkrun 的嵌入式虚拟化

Microsandbox 的技术基石是 libkrun。与 QEMU 或 Firecracker 这种作为独立进程运行的虚拟机监视器（VMM）不同，libkrun 是一个动态链接库，它允许常规的用户态程序直接获得虚拟化能力 1。

• 进程级虚拟化（Process-as-a-VM）：当 Microsandbox 启动一个实例时，它并没有调用外部的 VMM 二进制文件，而是直接在当前进程的内存空间中实例化了一个虚拟机。在 Linux 平台上，它直接通过 ioctl 系统调用与 /dev/kvm 设备交互，利用内核的 KVM 模块（Kernel-based Virtual Machine）来管理 CPU 的虚拟化扩展（Intel VT-x 或 AMD-V）。这种设计极大地减少了进程间通信（IPC）的开销和上下文切换的成本。
• 直接内核引导（Direct Kernel Boot）：为了实现极速启动，Microsandbox 跳过了传统 BIOS/UEFI 的初始化阶段。它直接将精简版的 Linux 内核加载到客户机物理内存的起始位置，并将指令指针（Instruction Pointer）指向内核入口。据实测，这种机制使其能在 200 毫秒 内完成从启动到用户空间代码执行的全过程 1。

#3.1.2 开发者体验（DX）：OCI 镜像的嬗变

Microsandbox 最大的创新在于解决了 Firecracker 生态中最大的痛点——根文件系统（rootfs）的构建。

• OCI 兼容性：Firecracker 原生只接受原始的 ext4 文件系统镜像，这要求开发者使用特殊工具链构建镜像。而 Microsandbox 能够直接摄取标准的 OCI 容器镜像（即 Docker 镜像）。它在运行时动态地将容器镜像的层（Layers）转化为微虚拟机可识别的根文件系统。
• 这意味着什么？ 这意味着 AI 工程师可以继续使用他们熟悉的 Dockerfile（例如 FROM python:3.11-slim，然后 RUN pip install pandas）来定义代理的运行时环境，而 Microsandbox 会自动将其转化为一个具有硬件级隔离的微虚拟机。这种“容器的接口，虚拟机的内核”的设计，极大地降低了迁移成本 4。

#3.1.3 安全态势：硬件防线

• 攻击面分析：Microsandbox 的安全边界在于 CPU 的硬件虚拟化层和宿主机的 KVM 模块。即使恶意代码在沙箱内获得了 root 权限，并利用内核漏洞导致客户机内核崩溃（Kernel Panic），这种崩溃也被限制在虚拟机内部。攻击者要想影响宿主机，必须挖掘出极其罕见的 KVM 模块漏洞或 CPU 微架构漏洞（如严重的虚拟机逃逸漏洞），其难度远高于利用容器共享内核的漏洞 1。
• 隔离强度：它提供了“真·虚拟机级隔离”（True VM-level isolation）。每个沙箱都有自己独立的内核实例，这意味着沙箱内的系统调用（Syscall）由客户机内核处理，而非宿主机内核。这切断了攻击者直接通过恶意系统调用攻击宿主机内核的路径 7。

#3.1.4 局限性与现状

• 实验性质：项目文档明确指出其仍处于“实验性”阶段，可能存在破坏性变更 4。相比于经过 AWS 大规模生产环境验证的 Firecracker，Microsandbox 的稳定性尚待时间检验。
• 平台依赖：虽然支持 Linux (KVM) 和 macOS (Hypervisor.framework)，但在 Windows 上的支持仍处于计划阶段，且依赖于具体的硬件虚拟化特性，无法在不支持嵌套虚拟化的云主机实例中运行 9。

#3.2 Wasmtime (Bytecode Alliance)：语言级隔离的极致效能

Wasmtime 代表了另一条完全不同的技术路线：指令集架构（ISA）虚拟化。它不模拟硬件，而是提供一个安全的、与平台无关的字节码运行时。

#3.2.1 核心架构：Cranelift 与 JIT 编译

Wasmtime 是 WebAssembly (Wasm) 的独立运行时（Runtime）。

• 编译流水线：它使用 Cranelift 编译器（一个用 Rust 编写的代码生成器），将 Wasm 字节码即时（JIT）或提前（AOT）编译为宿主机的原生机器码（如 x86_64 指令）。Cranelift 专为速度和安全性设计，能够在毫秒级时间内生成优化的机器码 10。
• 线性内存模型（Linear Memory）：Wasm 的核心安全机制在于其内存模型。每个 Wasm 模块实例被分配一段连续的线性内存空间。Wasm 指令只能通过相对于该内存块的偏移量来访问数据。运行时（及硬件的内存保护单元）保证了任何越界访问都会立即触发陷阱（Trap），从而在数学上杜绝了缓冲区溢出攻击波及宿主机内存的可能性 11。

#3.2.2 组件模型（Component Model）与 WASI

• WASI (WebAssembly System Interface)：这是 Wasm 在浏览器之外运行的关键。WASI 定义了一套标准的系统接口（类似 POSIX），用于文件 I/O、网络访问等。Wasmtime 实现了这些接口，并充当了“守门人”的角色。沙箱内的代码不能随意调用 open()，只能调用 wasi_snapshot_preview1::path_open，且必须获得运行时的显式授权（Capability-based Security）。
• 组件模型：Wasmtime 正积极推进组件模型标准。这允许不同语言编写的模块（如 Rust 的逻辑 + Python 的胶水代码）通过高级类型接口（WIT）进行链接，而无需共享内存。这为构建模块化、极度轻量级的 AI 代理插件系统提供了理论基础 13。

#3.2.3 AI 场景下的“阿喀琉斯之踵”：Python 生态支持

尽管 Wasmtime 在启动速度（微秒级）和资源密度上无出其右，但在 AI 代理场景中，它面临一个巨大的障碍：Python 数据科学栈的兼容性。

• 解释器的双重开销：要在 Wasmtime 中运行 Python，必须将 CPython 解释器本身编译为 Wasm。工具如 componentize-py 可以将 Python 应用打包成 Wasm 组件。这意味着实际上是在一个虚拟机（Wasm）中运行另一个虚拟机（CPython），这会带来显著的性能开销，尽管 JIT 可以缓解一部分 13。
• C 扩展的噩梦：这是最致命的问题。AI 代理的核心依赖库——NumPy、Pandas、Scikit-learn——并非纯 Python 代码。它们底层大量使用了 C、C++ 甚至 Fortran 编写的代码，直接调用操作系统底层的线程、内存映射（mmap）和特定的硬件指令（如 AVX/SIMD）来加速矩阵运算。
  • 将这些库移植到 WASI 环境极其困难。虽然浏览器端的 Pyodide 项目取得了一定成功，但在服务器端的 WASI 环境中，许多底层系统接口（如复杂的信号处理、动态链接库加载 dlopen）尚未完全标准化或实现。
  • 现状是：虽然你可以运行纯 Python 代码，但一旦代码中包含 import pandas 或 import numpy，在标准的 Wasmtime 环境中极大概率会失败，或者需要极其复杂的交叉编译工程来构建自定义的 Wasm 二进制文件 15。

#3.3 Firecracker (AWS)：无服务器计算的工业标准

Firecracker 是 AWS 为了解决 Lambda 和 Fargate 服务的多租户隔离问题而专门构建的微虚拟机监视器（MicroVMM）。它是该领域的“黄金标准”。

#3.3.1 核心架构：极简主义哲学

Firecracker 的设计哲学是“为特定任务做减法”。

• 设备模型的精简：通用的 QEMU 模拟了数百种传统设备（如软盘控制器、PCI 总线、传统显卡），代码量高达数百万行，攻击面巨大。Firecracker 仅由约 5 万行 Rust 代码组成，只提供了运行现代 Linux 内核所需的最低限度设备：
  • virtio-net：网络虚拟化。
  • virtio-block：磁盘 I/O 虚拟化。
  • virtio-vsock：宿主机与客户机通信的套接字。
  • 一个串行控制台（Serial Console）和一个仅用于重启的键盘控制器 18。
• REST API 控制：Firecracker 进程启动后，并不直接引导虚拟机，而是监听一个 Unix 套接字。外部编排系统通过向该套接字发送 JSON 格式的指令（配置 CPU 数量、内存大小、磁盘镜像路径等），最后发送 InstanceStart 指令来启动虚拟机。这种设计使其非常适合被自动化脚本集成。

#3.3.2 安全态势：纵深防御（Defense in Depth）

Firecracker 的安全性不仅仅依赖于 KVM，还引入了一个名为 jailer 的外部包装器。

• Jailer 机制：在 Firecracker 主进程启动之前，jailer 会对其进行一系列严苛的限制：
  1. Chroot：将进程根目录锁定在一个空文件夹中，使其无法访问宿主机文件系统。
  2. Cgroups & Namespaces：将进程隔离在独立的网络和 PID 命名空间中，并限制其资源使用。
  3. Seccomp 过滤器：这是最关键的一环。jailer 会加载一个极其严格的 BPF 过滤器，只允许 Firecracker 进程调用极少数（约 20-30 个）必要的宿主机系统调用。任何偏离预期的系统调用都会导致进程立即被内核杀灭。这意味着即使攻击者在 Firecracker 进程中实现了代码执行（VMM 逃逸），也几乎无法对宿主机内核发起进一步攻击 18。
• 侧信道防御：Firecracker 支持在虚拟机之间通过 CPU 特性（如禁用超线程 SMT）来缓解 Spectre、Meltdown 等微架构侧信道攻击，但这会显著降低 CPU 密度 22。

#3.3.3 性能与运维门槛

• 启动速度：Firecracker 宣称约 125ms 的启动时间。这在虚拟机领域是惊人的，但相比进程级启动仍有差距。这个时间主要消耗在 Linux 内核的初始化上。
• 极高的运维门槛：Firecracker 不懂 Docker。它不接受容器镜像。它需要一个原始的 ext4 文件系统镜像文件作为 rootfs，并且需要一个未压缩的 Linux 内核二进制文件（vmlinux）。这意味着如果你想用 Firecracker 运行一个 AI 代理，你需要自己构建构建流水线，将 Docker 镜像解压、展平并制作成 ext4 文件系统。这种复杂性导致了像 Microsandbox 和 Kata Containers 这类封装工具的出现 21。

#3.4 gVisor (Google)：用户态内核的这种妥协

gVisor 是 Google 为其云服务（如 GKE Sandbox, Cloud Run）开发的核心隔离技术。它代表了第三种路径：系统调用拦截与模拟。

#3.4.1 核心架构：Sentry 与 Gofer

gVisor 不虚拟化硬件，也不仅仅是过滤系统调用，它实际上在用户态重新实现了一个 Linux 内核。

• Sentry（哨兵）：这是 gVisor 的核心组件，一个用 Go 语言编写的内核。当沙箱内的应用程序（如 Python）发起系统调用（如 read、fork、socket）时，gVisor 会拦截这些调用。注意，它不会将这些调用透传给宿主机 Linux 内核，而是由 Sentry 内部的逻辑来处理。Sentry 维护了自己的进程表、内存映射表和虚拟文件系统。
• 拦截机制（Platform）：gVisor 支持多种拦截后端。
  • ptrace：传统的调试接口，兼容性好但性能极差。
  • KVM：利用 KVM 的虚拟化功能将沙箱作为 Guest 运行（Ring 0），主要为了更高效地捕获系统调用，而非运行完整 OS。
  • Systrap：一种较新的机制，利用 seccomp 过滤器捕获系统调用并将其重定向到 Sentry，性能优于 ptrace 23。
• Gofer：为了安全起见，Sentry 甚至不直接访问文件系统。它通过 9P 协议与一个独立的进程 Gofer 通信，由 Gofer 代表它进行实际的文件 I/O 操作。

#3.4.2 安全态势：攻击面隐藏

• 内核隔离：由于应用程序直接交互的是 Sentry（Go 代码）而非宿主机内核（C 代码），攻击者无法利用宿主机 Linux 内核中成百上千的潜在漏洞。Sentry 是用内存安全的 Go 语言编写的，天然免疫缓冲区溢出等内存破坏类漏洞。
• 多层防御：gVisor 自身通常还运行在非特权的容器中，受 seccomp 保护。这构成了“应用 -> Sentry -> Gofer -> 宿主机内核”的多层防御体系 25。

#3.4.3 性能代价与兼容性

• 系统调用开销（Syscall Overhead）：这是 gVisor 的主要痛点。每次系统调用都需要在用户态和内核态之间进行复杂的上下文切换和消息传递。对于计算密集型任务（如矩阵乘法），影响不大；但对于 I/O 密集型任务（如 pip install 安装大量小文件，或高并发网络请求），gVisor 的性能可能比原生容器下降 50% 甚至更多 27。
• GPU 支持（nvproxy）：gVisor 通过 nvproxy 机制支持 NVIDIA GPU。但这并不是直通（Passthrough），而是代理了 GPU 驱动的 ioctl 调用。这意味着它只能支持特定版本的驱动和特定的 CUDA 功能子集，更新滞后，且无法支持所有视频编解码功能 29。

#4. Google Vertex AI Agent Engine Code Execution：托管式服务的黑盒解析

与上述 DIY 的开源组件不同，Google Vertex AI 提供的是一种 Serverless 的、完全托管的“黑盒”服务。

#4.1 隐含架构推断

虽然 Google 未公开其底层实现，但根据其行为特征（启动延迟、隔离特性），可以推断其底层极有可能运行在 Google 的 Borg 集群管理系统之上，利用 gVisor 或类似 Firecracker 的微虚拟机技术，并结合了大规模的预热池（Pre-warmed Pools）技术来实现亚秒级响应 31。

#4.2 服务边界与限制（Guardrails）

作为托管服务，Google 设定了严格的边界以保障多租户的安全性和资源公平性：

• 30 秒硬性超时：这是最关键的限制。代码执行时间被严格限制在 30 秒内。这直接否定了使用该服务进行模型训练、大规模数据清洗或长时间模拟的可能性。它仅适用于轻量级的逻辑处理和即时分析 32。
• 网络隔离（默认断网）：出于防范数据泄露（Data Exfiltration）和僵尸网络风险的考虑，沙箱默认无法访问外网。用户不能在代码中执行 requests.get('https://external-api.com')，也不能动态 pip install 外部库。所有数据输入必须通过上下文或文件上传进行 33。
• 文件系统限制：支持内存级的文件 I/O（通常限制在 100MB 以内）。虽然会话（Session）可以保持最长 14 天的状态（变量和文件），但单个文件的处理能力有限 35。

#4.3 “电池内置”（Batteries-Included）环境

为了缓解无法联网安装库的限制，Google 在镜像中预装了极其丰富的数据科学全家桶。

• 预装清单：包括但不限于 numpy, pandas, scikit-learn, matplotlib, scipy, seaborn 等。这覆盖了 95% 的常规数据分析需求。这意味着代理生成的代码可以直接 import pandas 而无需任何配置 34。
• VPC-SC 集成：对于企业用户，它支持 VPC Service Controls。这意味着可以将代码执行环境置于企业的安全边界内，防止数据流向未授权的 Google 资源，这是开源自建方案难以企及的合规性优势 38。

#5. 正交对比分析 (Orthogonal Analysis)

本章将通过五个正交的维度，对上述技术进行矩阵式对比。

#5.1 维度一：隔离机制与安全边界 (Isolation & Security)

深度洞察：

• Firecracker 和 Microsandbox 处于隔离金字塔的顶端。硬件虚拟化提供的物理地址隔离是目前公认的最强防线。
• gVisor 提供了比原生容器强得多的隔离，但理论上仍存在 Sentry 逻辑漏洞导致穿透的可能，尽管其使用 Go 语言极大地降低了这种风险。
• Wasmtime 的安全性依赖于数学证明和编译器实现的正确性。近期的 CVE-2025-62711 漏洞表明，即使是内存安全的运行时也可能存在导致宿主机崩溃的 Bug 39。

#5.2 维度二：性能动力学 (Performance Dynamics)

深度洞察：

• Wasmtime 是密度之王。如果你的代理任务是纯计算逻辑（如复杂的数学公式解析），Wasmtime 可以在单机上运行数万个实例。
• gVisor 是 I/O 的短板。如果代理任务涉及解压大型 zip 文件或频繁的小文件读写，gVisor 的性能衰减会非常明显。
• Firecracker 是平衡点。125ms 的启动延迟对于人类用户来说几乎不可感知，且其运行时性能几乎没有损耗。

#5.3 维度三：生态兼容性 (Ecosystem Compatibility) —— "Python 困境"

这是 AI 代理场景中最具决定性的维度。

深度洞察：

• Wasmtime 的死穴：尽管 WebAssembly 前景广阔，但目前它无法直接运行依赖 C/Fortran 扩展的 Python 库（如 Pandas, NumPy）。在服务器端 WASI 环境中，缺乏对动态链接和底层 OS 原语的完整支持。这意味着你不能简单地 pip install pandas。你必须使用极其复杂的工具链将 NumPy 静态链接编译进 Wasm 二进制文件，这在工程上极具挑战且不仅难以维护。
• VM 的胜利：Firecracker, Microsandbox 和 gVisor 运行的是标准的 Linux 环境。它们可以无缝加载 PyPI 上预编译的 .whl 文件。对于数据科学代理，这是决定性的优势。

#5.4 维度四：运维复杂度 (Operational Complexity)

• Firecracker (极高)：需要内核编译、Rootfs 制作、网络 TAP 设备配置、API 调用。不适合直接面向开发者。
• Wasmtime (高)：需要将所有代码编译为 Wasm。对于 Python，需要使用 componentize-py 等工具链进行打包，调试困难。
• Microsandbox (中)：提供了类似 Docker 的 CLI 体验，封装了底层虚拟化的复杂性。
• gVisor (中)：通过 runsc 与 Docker/K8s 集成，对运维透明，但需要配置节点运行时。
• Vertex AI (零)：API 调用即用。无需管理镜像、服务器或网络。

#6. 形象直观的类比分析

为了更直观地理解这些技术的差异，我们引入“酒店住宿”的隐喻：

1. Firecracker / Microsandbox（独栋小木屋）：
   • 场景：你被分配到酒店主楼外的一间独立小木屋。
   • 隔离：你拥有独立的墙壁、屋顶和水电设施（独立内核）。如果你在屋里放火，火势因为物理距离（硬件虚拟化）无法蔓延到主楼。
   • 体验：你需要走一段路才能进屋（启动时间约 100ms）。
   • 区别：Firecracker 像是一个只有图纸的木屋，你需要自己买木头搭建；Microsandbox 像是一个全自动的预制房，一键下单即可入住。
2. gVisor（带翻译的套房）：
   • 场景：你住在酒店主楼的房间里，但你不能直接和服务员说话。
   • 隔离：门口站着一位私人翻译官（Sentry）。当你需要点餐（系统调用）时，你告诉翻译官，翻译官检查你的请求是否合规，然后替你跑腿去厨房拿。
   • 体验：如果你的话很多（高频系统调用），翻译官来回跑腿会很慢（性能开销）。但因为你不直接接触酒店设施，所以很难破坏酒店。
3. Wasmtime（高科技拘束衣）：
   • 场景：你坐在酒店大堂，但身上穿着一件数学级精密的拘束衣（内存安全）。
   • 隔离：你的思维可以转得飞快（CPU 速度），但你的手脚被死死锁住，物理上无法触碰任何东西。
   • 体验：你瞬间就能坐下开始思考（微秒级启动）。
   • 痛点：你想穿上一件厚重的大衣（Pandas 库），但因为拘束衣的存在，大衣根本穿不进去（兼容性问题）。
4. Vertex AI Code Execution（全自动贩卖机）：
   • 场景：你甚至不需要进房间。你站在一台机器前，把钱和需求（代码）塞进投币口。
   • 隔离：机器内部在坚固的黑盒中处理。
   • 体验：完全省心。但你只能买机器里有的东西（预装库），而且如果你操作超过 30 秒，机器就会自动断电吞币。

#7. 战略建议与未来展望

#7.1 选型决策矩阵

#7.2 关键缺失环节：Microsandbox 的战略价值

分析表明，市场在“易用性”和“兼容性”之间存在断层。Firecracker 虽然强大但难用；Wasmtime 虽然快但不支持 Pandas。Microsandbox 恰好填补了这一空白：它让开发者像使用 Docker 一样使用 MicroVM，同时保留了对 Python 生态的完整支持。对于希望自建安全代理执行环境但缺乏大规模内核工程团队的企业，Microsandbox 是目前最具潜力的开源选择。

#7.3 未来展望

• Wasm 组件模型的成熟：一旦 WASI-NN（神经网络接口）和组件模型成熟，Wasm 可能会通过标准接口调用宿主机的 Pandas/PyTorch 能力，从而解决兼容性问题。这可能在 2-3 年内发生。
• 混合运行时（Hybrid Runtimes）：未来的代理平台可能会采用混合架构：对于简单的逻辑路由使用 Wasm（毫秒级、低成本），对于复杂的数据分析自动升级到 Firecracker/Microsandbox 实例。
• GPU 虚拟化的突破：目前所有微虚拟机方案在 GPU 支持上都较弱（Firecracker 不支持 GPU 直通）。随着 AI 代理对本地推理需求的增加，支持 GPU 动态挂载的微虚拟机（如基于 vfio-user 的技术）将成为下一个竞争高地。

#8. 结论

在为 AI 代理构建代码执行基础设施时，并不存在“银弹”。Google Vertex AI 提供了最便捷的入门路径，但其严格的限制可能会阻碍复杂应用的发展。对于追求极致性能和安全性的自建平台，Firecracker 是工业界的基石，而 Microsandbox 则为开发者提供了更友好的入口。Wasmtime 虽然代表了计算的未来，但在 Python 数据科学生态完全适配 WASI 之前，它暂时只能作为特定轻量级任务的补充，而非通用数据代理的核心引擎。

架构师应根据业务对隔离性（绝对安全 vs 相对安全）、时延（毫秒级 vs 秒级）及生态依赖（是否必须 Pandas）的权重，在上述技术栈中做出理性的权衡。

#Works cited

1. AI Sandboxes: Daytona vs microsandbox - Pixeljets, accessed January 7, 2026, https://pixeljets.com/blog/ai-sandboxes-daytona-vs-microsandbox/?utm_source=seoca
2. [question] Goals/non-goals in comparison to firecracker/firecracker-containerd · Issue #12 · containers/libkrun - GitHub, accessed January 7, 2026, https://github.com/containers/libkrun/issues/12
3. containers/libkrun: A dynamic library providing Virtualization-based process isolation capabilities - GitHub, accessed January 7, 2026, https://github.com/containers/libkrun
4. zerocore-ai/microsandbox: opensource self-hosted ... - GitHub, accessed January 7, 2026, https://github.com/zerocore-ai/microsandbox
5. Monocore - Lib.rs, accessed January 7, 2026, https://lib.rs/crates/monocore
6. Microsandbox: Solving the Code Execution Security Dilemma | by Simardeep Singh, accessed January 7, 2026, https://medium.com/@simardeep.oberoi/microsandbox-solving-the-code-execution-security-dilemma-4e3ea9138ef8
7. Enhancing Container Security with gVisor: A Deeper Look into Application Kernel Isolation | by Gitesh Wadhwa | Medium, accessed January 7, 2026, https://medium.com/@GiteshWadhwa/enhancing-container-security-with-gvisor-a-deeper-look-into-application-kernel-isolation-585af4652781
8. A field guide to sandboxes for AI - Luis Cardoso, accessed January 7, 2026, https://www.luiscardoso.dev/blog/sandboxes-for-ai
9. Releases · zerocore-ai/microsandbox - GitHub, accessed January 7, 2026, https://github.com/microsandbox/microsandbox/releases
10. Wasmtime, accessed January 7, 2026, https://wasmtime.dev/
11. Exploring and Exploiting the Resource Isolation Attack Surface of WebAssembly Containers - USENIX, accessed January 7, 2026, https://www.usenix.org/system/files/usenixsecurity25-yu-zhaofeng.pdf
12. WebAssembly and Security: a review - arXiv, accessed January 7, 2026, https://arxiv.org/html/2407.12297v1
13. Python - The WebAssembly Component Model, accessed January 7, 2026, https://component-model.bytecodealliance.org/language-support/python.html
14. Python, Wasm, and Componentize-Py - Fermyon, accessed January 7, 2026, https://www.fermyon.com/blog/python-wasm-componentize-py
15. Python on the Edge: Fast, sandboxed, and powered by WebAssembly - Wasmer, accessed January 7, 2026, https://wasmer.io/posts/python-on-the-edge-powered-by-webassembly
16. How stable do you think the WASM ecosystem is going to be? : r/rust - Reddit, accessed January 7, 2026, https://www.reddit.com/r/rust/comments/1pxoqpn/how_stable_do_you_think_the_wasm_ecosystem_is/
17. Python on the Edge: Fast, sandboxed, and powered by WebAssembly - Reddit, accessed January 7, 2026, https://www.reddit.com/r/Python/comments/1nqajjt/python_on_the_edge_fast_sandboxed_and_powered_by/
18. firecracker-microvm/firecracker: Secure and fast microVMs for serverless computing. - GitHub, accessed January 7, 2026, https://github.com/firecracker-microvm/firecracker
19. How AWS's Firecracker virtual machines work - Amazon Science, accessed January 7, 2026, https://www.amazon.science/blog/how-awss-firecracker-virtual-machines-work
20. Firecracker: Lightweight Virtualization for Serverless Applications - USENIX, accessed January 7, 2026, https://www.usenix.org/system/files/nsdi20-paper-agache.pdf
21. Firecracker vs QEMU — E2B Blog, accessed January 7, 2026, https://e2b.dev/blog/firecracker-vs-qemu
22. Microarchitectural Security of AWS Firecracker VMM for Serverless Cloud Platforms - arXiv, accessed January 7, 2026, https://arxiv.org/pdf/2311.15999
23. google/gvisor: Application Kernel for Containers - GitHub, accessed January 7, 2026, https://github.com/google/gvisor
24. Production guide - gVisor, accessed January 7, 2026, https://gvisor.dev/docs/user_guide/production/
25. What is gVisor?, accessed January 7, 2026, https://gvisor.dev/docs/
26. Security Model - gVisor, accessed January 7, 2026, https://gvisor.dev/docs/architecture_guide/security/
27. Security Without Sacrifice: Edera Performance Benchmarking, accessed January 7, 2026, https://edera.dev/stories/security-without-sacrifice-edera-performance-benchmarking
28. A Functional and Performance Benchmark of Lightweight Virtualization Platforms for Edge Computing - Biblio, accessed January 7, 2026, https://backoffice.biblio.ugent.be/download/8769638/8769643
29. nvproxy: Support GPU capability segmentation · Issue #10856 · google/gvisor - GitHub, accessed January 7, 2026, https://github.com/google/gvisor/issues/10856
30. GPU Support - gVisor, accessed January 7, 2026, https://gvisor.dev/docs/user_guide/gpu/
31. Introducing Code Execution: The code sandbox for your agents on Vertex AI Agent Engine, accessed January 7, 2026, https://discuss.google.dev/t/introducing-code-execution-the-code-sandbox-for-your-agents-on-vertex-ai-agent-engine/264336
32. Code execution | Generative AI on Vertex AI - Google Cloud Documentation, accessed January 7, 2026, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/code-execution
33. Vertex Ai Agent Engine: ConnectTimeoutError to outbound URLs - Custom ML & MLOps, accessed January 7, 2026, https://discuss.google.dev/t/vertex-ai-agent-engine-connecttimeouterror-to-outbound-urls/194141
34. Gemini 2.0 Deep Dive: Code Execution - Google Developers Blog, accessed January 7, 2026, https://developers.googleblog.com/gemini-20-deep-dive-code-execution/
35. Code Execution troubleshooting | Vertex AI Agent Builder | Google ..., accessed January 7, 2026, https://docs.cloud.google.com/agent-builder/agent-engine/troubleshooting/code-execution
36. Code Execution with Agent Engine - Agent Development Kit - Google, accessed January 7, 2026, https://google.github.io/adk-docs/tools/google-cloud/code-exec-agent-engine/
37. Code execution | Gemini API - Google AI for Developers, accessed January 7, 2026, https://ai.google.dev/gemini-api/docs/code-execution
38. Vertex AI Agent Engine overview - Google Cloud Documentation, accessed January 7, 2026, https://docs.cloud.google.com/agent-builder/agent-engine/overview
39. CVE-2025-62711 Detail - NVD, accessed January 7, 2026, https://nvd.nist.gov/vuln/detail/CVE-2025-62711
40. CVE-2025-62711 Impact, Exploitability, and Mitigation Steps | Wiz, accessed January 7, 2026, https://www.wiz.io/vulnerability-database/cve/cve-2025-62711