AI Agent 沙箱全景（2026）

博途PLC工程智能体 | AI智能体博途网关 | 梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 逆向生成程序块文档 | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI

一年前，大多数 agent 框架在本地子进程或一次性 Docker 容器中执行生成的代码。2026 年，沙箱技术已经形成了一个真实的市场，以及一个专门为 agent 构建的、快速增长的沙箱即服务平台生态系统。本文是对这一全景的综述。

但它带着一个论点，因为这个全景很容易被误读。"沙箱"这个词隐藏了两个截然不同的安全问题，而几乎所有人只在解决第一个。

• 遏制（Containment）：agent 能否逃离其环境并伤害宿主？
• 证明（Proof）：你能否证明 agent 实际做了什么？

遏制是一个已解决的、竞争激烈的市场。证明则是一个开放的研究前沿。在我们浏览这个领域时，请记住这一区别，因为它解释了真正的差距在哪里。

1、遏制光谱

遏制关乎一个简单的问题：

如果一个 AI agent 编写并运行恶意或有缺陷的代码，该代码能否逃离其沙箱并影响宿主机？

沙箱技术之间的主要区别在于 agent 与其他工作负载共享底层机器的程度。

最简单的思考方式是：

共享越多 → 越轻越快，但边界越弱。

共享越少 → 隔离越强，但开销越大。

以下是主要方法，大致从较轻到较强的隔离。

1.1 系统级沙箱

这是最轻的方法。

你不是为 agent 创建一台单独的机器，而是使用操作系统已内置的功能来限制进程能看到什么、能做什么。

例如：

• 命名空间（Namespaces） 可以隐藏文件系统、进程、网络等的部分内容。
• cgroups 可以限制 CPU 和内存使用。
• seccomp 可以限制进程被允许请求哪些操作系统操作。
• Linux 上的 Landlock 和 macOS 上的 Seatbelt 可以限制对文件和其他资源的访问。

可以把它想象成对一个进程施加限制，而它仍然生活在你的机器内部。它速度快，开销很小。缺点很重要：agent 最终仍然依赖宿主操作系统的内核。 如果该边界存在严重漏洞，隔离可能会被打破。这是一些编码 agent 直接使用的轻量级沙箱方式。

1.2 Docker 和标准容器

Docker 使这种方法更容易使用。容器将应用程序与其依赖项打包在一起，并使用命名空间和 cgroups 等 Linux 隔离机制来限制它。

容器速度极快、广为人知且受到广泛支持。但有一个问题：普通容器没有自己的内核。 容器和宿主共享宿主的 Linux 内核。当你信任你运行的代码时，这通常是完全合理的。但 AI agent 改变了威胁模型。

如果一个 agent 正在生成你并不完全信任的任意代码，你必须问："我真的想让不可信的、AI 生成的代码共享我的内核吗？"

这就是更强的沙箱技术存在的原因。

1.3 gVisor

gVisor 走了一条有趣的中间路线。

gVisor 不允许应用程序直接与宿主内核对话，而是在应用程序和真实内核之间放置一个用户空间内核。

你可以把它想象成一个保安：

Agent → gVisor → 宿主内核

Agent 请求 gVisor 执行操作系统操作，gVisor 在与宿主交互之前决定什么是被允许的。这减少了不可信应用程序可以直接交互的宿主内核的数量。结果是比普通容器更强的隔离，而没有运行单独虚拟机的全部开销。

1.4 Kata Containers / Sysbox

这些方法更进一步。它们试图在保持容器便利性的同时，在下面提供更强的隔离边界。

例如，Kata Containers 在轻量级虚拟机内运行容器。从开发者的角度来看，你仍然可以使用熟悉的容器工具。但在下面，工作负载与宿主的分离要强得多。

这使得 Kata 和类似技术在普通容器不够用、但完整传统虚拟机又显得太重时非常有用。

1.5 MicroVM

这是我们遇到的用于运行真正不可信代码的最强且最广泛使用的方法。

microVM 本质上是一台非常小的虚拟机。工作负载不是共享宿主的内核，而是获得自己的内核。

现在的结构看起来更像：Agent → microVM → 虚拟机监控器 → 宿主

虚拟机监控器和硬件虚拟化提供了沙箱与宿主之间的边界。这是 Firecracker 和 Cloud Hypervisor 等技术使用的方法。

Firecracker 由 AWS 为 Lambda 和 Fargate 等工作负载开发。它旨在使虚拟机比传统虚拟机轻得多、启动快得多。

这种组合对 AI agent 尤其有吸引力，因为 agent 可能在单个任务中创建和销毁许多执行环境。你获得了接近虚拟机级别的隔离，而无需支付传统虚拟机的全部成本。当一个 AI 沙箱产品说它提供**"每个沙箱内核级隔离"**时，它通常指的就是这种架构。

1.6 WebAssembly

WebAssembly（Wasm）采取了不同的方法。

你不是给 agent 一个完整的 Linux 环境，而是在一个小型、可移植的运行时内运行代码。代码只能访问运行时明确授予它的能力。

例如，你可能允许一个工具：

• 读取特定文件
• 发出特定的网络请求
• 执行计算

但不给它对机器其余部分的通用访问权限。这使得 Wasm 极其轻量和快速。

权衡在于，Wasm 不是与 microVM 相同意义上的通用 Linux 环境。这使得它对于定义良好的工具和函数特别有趣，而不是期望完整操作系统的任意 agent 工作负载。随着 agent 架构越来越多地将任务分解为定义良好的工具，Wasm 值得关注。

1.7 V8 isolate

V8 isolate 是一种更轻量的方法。它们是 Cloudflare Workers 等平台背后的隔离机制。多个工作负载可以在同一个运行时进程内运行，同时彼此分离。这为你提供了极快的启动速度和极低的开销。但边界比虚拟机薄，并且与 JavaScript/V8 运行时模型绑定。

因此，V8 isolate 最好被视为一种不同的权衡，而不是"最强到最弱"阶梯上的又一级。你放弃了一些隔离深度，以换取极低的延迟和成本。

1.9 全景

记住这一切最简单的方式是：

系统沙箱 → 容器 → gVisor → microVM

当你向右移动时，通常会获得 agent 与宿主之间更强的边界，但你也在资源和启动时间上付出更多。

Wasm 和 V8 isolate 略有不同：它们通过限制执行环境本身而不是提供完整的虚拟化机器来实现非常轻量的隔离。

因此，重要的问题不是：

"哪个沙箱最好？"

而是：

"这个工作负载实际上需要多少隔离？"

对于受信任的代码，容器可能绰绰有余。对于 AI agent 编写的任意代码，你可能需要一个更强的边界。

这把我们带到了全景的下一部分：将这些底层技术打包成开发者实际可以使用的产品。

2、生态系统的思维模型

2026 年全景中最令人困惑的是产品的数量。一个精选的 agent 沙箱列表现在有数十个条目——E2B、Modal、Daytona、Vercel Sandbox、Sprites、Cognitora、AgentSphere、Runloop、Microsandbox、Arrakis、Flintlock、Volant、Landrun，等等。作为一个列表来读，它就是噪音。理解它的方式是停止看产品，而是看它们下面是什么。

让我们通过不同的视角来看待它们。

2.1 视角一：下面是什么隔离原语？

这些产品几乎没有一个是自己发明隔离的。它们是在少数底层原语之上打包的、编排的和开发者体验——与第一部分相同的原语。按该原语对整个领域进行排序，这几十个产品会折叠成五个家族：

microVM 家族（自己的内核，硬件支持）。 所有基于 Firecracker 或类似 microVM 监控器构建的东西：强隔离，每个沙箱自己的内核，快速启动。这是最大也是增长最快的家族——许多"AI 沙箱"产品在底层是一个托管的 Firecracker 集群，上面套一个 SDK。当一个平台宣传"每个沙箱内核级隔离"时，这就是它所指的。

容器家族（共享内核，可选升级）。 基于 Docker 和标准命名空间/cgroups 构建的产品。快速且熟悉，默认共享宿主内核，有几个提供升级路径（Kata、Sysbox），当工作负载需要更强的分离时，将共享内核换为轻量级虚拟机。"默认容器，按需更强"的模式。

用户空间内核家族（gVisor）。 将 gVisor 放在工作负载和宿主内核之间的产品——隔离光谱的中间地带，比普通容器更强，但没有虚拟机的全部重量。

系统原语家族（完全没有虚拟机）。 直接构建在 Landlock、seccomp 或 Seatbelt 之上的轻量级工具：它们限制宿主上的进程，而不是给它一个单独的环境。开销最小，边界较粗，没有虚拟化。大多数本地的、开发者运行的 agent 沙箱都属于这个家族。

语言运行时家族（进程内）。 构建在 WebAssembly 运行时或 V8/Deno isolate 之上的沙箱：工作负载在字节码或 JavaScript 虚拟机内运行，只有明确授予的能力。极其轻量、可移植、启动快，但受语言和运行时限制，而不是通用 Linux 环境——最适合范围明确的工具执行。

澄清的洞察：市场的表观复杂性大约是五个隔离原语加上许多包装器。 一旦你知道一个产品建立在哪个原语上，你已经知道了它的隔离强度、大致的冷启动概况和开销。

2.2 视角二：产品占据技术栈的哪一层？

产品如此之多的第二个原因是它们生活在不同的层，高层的产品建立在低层的产品之上。从底层向上：

• 原语 —— 原始的隔离技术（Firecracker、gVisor、Landlock、Wasmtime）。与其说是你"使用"的产品，不如说是其他一切建立在其上的基础。Linux cgroups、Firecracker 和 gVisor 就是这方面的例子。
• 生命周期和编排 —— 管理沙箱集群的工具：创建、调度、快照、销毁。microVM 生命周期管理器和 Kubernetes 原生的 agent 沙箱控制器就在这里。它们将原语变成你可以大规模运行的东西。Flintlock 和 Volan 就是这方面的例子。
• 托管平台 —— 原语加编排加 SDK 加托管，作为服务出售。大多数人说的"AI 沙箱"指的就是这一层：你调用 API，得到一个隔离环境。这里的竞争在于冷启动、会话限制、有状态性、GPU 访问和定价模式。E2B 和 Daytona 就是这方面的例子。
• 聚合器和抽象层 —— 在多个托管平台之上的单一 API，因此你可以针对一个接口，并在下面更换沙箱。它们的存在本身就是市场已经成熟到需要兼容层的标志。VibeKit 和 ComputeSDK 就是这方面的例子。

将两个视角放在一起，全景就变成了一个网格而不是一个列表：一个轴上是少数几个原语，另一个轴上是少数几个技术栈层，每个产品落在一个单元格中。托管平台是"原语 X，打包在服务层"；聚合器是"多个平台之上的层"；生命周期工具是"原语 X，编排层"。这四十个产品是几个想法，在不同的层重复，并包裹在不同的开发者体验中。

2.3 当你实际选择时

对于选择一个的团队来说，第三个更实用的视角会接管：哪个约束占主导？冷启动延迟（在每轮启动新沙箱的 agent 循环中会复合）、会话时长（有些上限为几分钟，有些无限制运行）、GPU 访问（只有部分家族提供）、有状态性（检查点/恢复正迅速成为基本要求）、定价模式（墙钟时间与活跃 CPU 计费，这可能会为模型绑定的工作负载反转成本排名），以及自托管与云（数据敏感或合规要求部署的硬性要求）。但请注意这些轴中的每一个都关于什么：遏制的性能、成本和便利性。这把我们带到了重点。

3、agent 运行时实际上如何沙箱化

调查平台是一回事；看看流行的 agent 运行时开箱即用做什么是另一回事。这个模式是有启发性的：它们落在遏制光谱的不同点上，而且默认情况下，它们都没有解决证明问题。

Claude Code 内置了原生沙箱，使用系统级原语强制执行文件系统和网络隔离，减少了持续权限提示的需要。在宿主机上，它使用轻量级的按命令沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap）。它还提供更强的层级：基于 Docker 的 microVM 沙箱，以及一种 web 模式，其中每个会话在带有允许列表的网络代理后面的隔离托管虚拟机中运行。因此它跨越了从按命令的系统沙箱到 microVM 的光谱。

OpenAI Codex CLI 使用系统原生原语而不是虚拟机进行沙箱化：macOS 上的 Seatbelt，Linux 上的 Landlock 加 seccomp（通过 bubblewrap），默认禁用网络，写入限制在工作区内。就其本身而言很强，但它是系统调用级别的而不是内核分离的——比 microVM 更粗，没有虚拟化开销。

OpenClaw（一个自托管 agent）使沙箱化成为可选的且基于容器的：它可以在 Docker 容器内运行工具以减小爆炸半径，提供 SSH 和 OpenShell 后端，但如果沙箱化关闭，工具就在宿主上运行。它自己的文档坦诚地承认这"不是一个完美的安全边界"，但确实实质性地限制了文件系统和进程访问。

Hermes 提供最广泛的后端选择——本地、Docker、SSH、Singularity、Modal、Daytona、Vercel Sandbox——从宿主执行（无隔离）一直到通过托管平台获得的 gVisor 和 microVM 级隔离。在其最简单的本地模式下，它在宿主上以完全访问权限运行，这就是为什么存在第三方"笼子"包来将其路由到容器中。

共同点：这些运行时在不同的强度和默认值下解决了遏制问题，然后就止步了。 它们中的每一个都能以或多或少的严格程度告诉你 agent 无法逃逸。但默认情况下，它们中的任何一个都无法向第三方证明 agent 在盒子内实际做了什么。

4、证明前沿

这是"哪个沙箱最快"的比较所跳过的那一半全景，也是有趣的问题现在所在的地方。

遏制回答了一个关于伤害的问题：agent 无法到达宿主。证明回答了一个关于证据的问题：可验证地向我展示运行了什么。两者是正交的。Firecracker microVM 为你提供了出色的遏制，但不产生其内部发生了什么的密码学证明。两者是用不同的工具构建的，而证明工具要不成熟得多。

这里也有一个阶梯，从最弱到最强的证据：

审计日志。 你记录 agent 的行动。必要，但这是"相信我"的证据：日志的可信度取决于日志基础设施和操作它的人。日志可能不完整、被篡改或伪造，而且其中没有任何东西证明它们反映了实际执行的内容。

证明（TEEs）。 可信执行环境——Intel TDX、AMD SEV-SNP、AWS Nitro Enclaves，以及越来越多的 NVIDIA 机密计算 GPU——在硬件隔离的飞地内运行代码，并可以产生密码学证明：一个签名声明，表明特定的、未修改的二进制文件在未被破坏的环境中运行。远程方可以在不信任操作员的情况下验证这一点，只信任芯片供应商的硅和签名密钥。这是目前可验证 agent 计算最实用的路径，机密计算硬件已经成熟到证明推理在操作上可行，包括通过机密 GPU 运行更大的模型。限制是真实的：你信任硬件供应商，存在侧信道风险，而且 TEE 会忠实地证明它被给予的任何代码——它证明的是环境，而不是意图。

可验证执行（zkVM 和零知识证明）。 最强的形式：一个密码学证明，表明特定计算产生了特定结果，任何人都可以验证，只信任数学而不是任何硬件供应商。zkVM 如 RISC Zero 和 Succinct 的 SP1 可以用这种方式证明通用计算。问题在于成本：证明完整的 LLM 前向传播仍然比运行它慢许多个数量级——基准测试显示，到 2026 年，它大约是原生推理的 10,000 到 100,000 倍。因此，零知识证明目前对于短的、高价值的检查是现实的——策略合规决策、最终结算状态、小工具的输出——而不是用于证明实时的十亿参数推理。

基于可复现性的重放。 在"相信我"的日志和昂贵的密码学之间，存在一条务实的中间路径，即使没有特殊硬件也可以工作——这是云托管 LLM API 的主要情况。你记录 agent 声明的模型、输入和配置，然后在记录的输入上重新执行并比较输出。这是对硬件保证的概率性、纯软件近似，置信度随着验证预算的增加而提高。它不如证明或 attestation 强大，但它现在就可以在普通基础设施上部署。

前沿在移动。最近的研究开始将"agent 做了什么的证明"视为一个独立于隔离和简单日志的一流问题——关于可验证执行跟踪的工作，以及将不仅功能正确性、还有授权、所采取的路径、持久影响和可重放性绑定到单个可验证对象的执行证明方案。这项工作中反复出现的洞察是发人深省且重要的：TEE 会忠实地执行它被给予的任何东西，日志会忠实地记录它被告知的任何东西，证明会忠实地证明被计算的任何东西——但它们中的任何一个，单独地，都不能验证该行动是被授权的或意图是合法的。执行证明是必要的，但仍不充分。

5、结束语

2026 年的沙箱全景，在遏制方面，是真正已解决且真正有竞争的。如果你的问题是"运行不可信的 agent 代码而不让它伤害宿主"，那么在整个隔离光谱上，从系统原语到 microVM，你都有大量好选择，可以作为开源或一行 SDK 使用，精确到毫秒地进行基准测试。选择你的工作负载在强度与开销曲线上的点，然后继续前进。

证明方面是该领域尚年轻、有趣的基础设施问题仍然存在的地方。证明实用但受硬件限制且信任供应商；可验证执行强大但对完整推理来说仍然太贵；可复现性重放可以部署但只是概率性的。而且在所有这些之上，坐落着没有任何原语能单独回答的更难的问题：不仅仅是运行了什么，而是它是否被允许运行。

随着我们将更多权力交给 agent——转移资金、更改数据、部署代码、做出以后会有人被要求辩护的决定——问题悄然发生了转变。遏制告诉我们 agent 不能做什么。证明告诉我们它实际做了什么。今天，几乎所有的基础设施，以及几乎所有的注意力，都在第一个上。

第二个才是重要的那个。

原文链接：The AI Agent Sandbox Landscape in 2026

汇智网翻译整理，转载请标明出处