AI Agent 沙箱是一个隔离的执行环境，AI Agent 可以在其中运行代码、调用工具并与文件系统或浏览器交互，而不会影响主机系统、相邻工作负载或敏感基础设施。沙箱创建了一个边界：内部发生的事情停留在内部，外部发生的事情除非明确允许，否则无法从内部访问。Novita Agent Sandbox 是该模式的一种实现——Firecracker microVM 隔离、在您自己的 AWS 或 GCP VPC 中进行 BYOC 部署，以及纯按需付费定价——但这里的概念适用于任何沙箱平台。本文回答了关于该边界如何工作、权衡取舍以及何时真正需要它的最常见问题。有关隔离、密钥、出站和合规要求的更深入问答，请参阅 AI Agent 沙箱常见问题。
什么是 AI Agent 沙箱？
AI Agent 沙箱是 AI Agent 执行实际工作的层：编写和运行代码、安装软件包、读取和修改文件、进行 API 调用，以及与浏览器会话或桌面 GUI 交互。沙箱提供了一个有界环境，拥有自己的文件系统、CPU 和内存分配、网络接口和进程命名空间——并且与外部的一切隔离。
关键的设计目标是 隔离。当 LLM 生成一个 shell 命令并且 Agent 执行该命令时，该命令会在沙箱内部运行。如果它安装了一个软件包、运行了一个子进程或试图读取凭据，这些操作都将限定在沙箱内。如果代码导致进程崩溃或填满磁盘，损害也仅限于本地。
沙箱还充当云提供商的计费和资源核算单位。当您调用像 E2B、Daytona 或 Novita Agent Sandbox 这样的 SDK 时，您正在创建一个沙箱实例，在其中运行操作，然后关闭它——提供商根据您消耗的计算量收费。
Agent 沙箱与普通容器有何不同？
普通容器为您提供一个文件系统命名空间和资源限制，但同一主机上的所有容器共享相同的操作系统内核。如果容器内的进程利用了内核漏洞或配置错误的系统调用过滤器，它可能会影响主机或其他容器。
Agent 沙箱通常通过使用 microVM 边界更进一步。microVM 将工作负载封装在一个轻量级虚拟机中，拥有自己的客户内核，并受到硬件虚拟化（KVM）的支持。客户机与主机内核在设计上隔离，因此客户机中的内核漏洞不会自动影响主机。
实际的权衡是性能开销。microVM 启动比容器慢，因为它需要启动内核，即使是一个最小的内核。像 Firecracker 这样的快速 microVM 平台已将大多数情况下的开销降低到 500 毫秒以下，而像 Daytona 这样基于快照的系统将其推至 100 毫秒以下。但它仍然比启动容器有更多开销。
对于大多数涉及 LLM 生成的或不受信任的代码的 AI Agent 工作负载，更强的边界是值得的。如果您正在运行完全受信任的内部代码且没有用户生成的输入，则强化容器可能就足够了。
在 AI Agent 的上下文中，什么是隔离？
Agent 沙箱中的隔离在多个维度上运作。有关 沙箱隔离 在实际工作负载下如何表现（包括 microVM 边界在哪些方面有帮助，哪些方面没有帮助）的技术深入探讨，请参阅 Firecracker 评估指南。
文件系统隔离——Agent 拥有自己的文件系统，与主机分离。在沙箱内写入的文件不会出现在主机上，并且除非显式挂载，否则主机文件无法从内部访问。这可以防止 Agent 读取沙箱外部的凭据、配置文件或其他密钥。
进程隔离——沙箱内的进程无法看到或向沙箱外的进程发送信号。Agent 可以在沙箱内启动子进程、后台作业或服务器，但它们无法与主机进程树通信。
网络隔离——默认情况下，Agent 沙箱可以配置为阻止、允许列表或限速出站网络调用。无法将数据外泄到任意互联网地址的 Agent 可以限制为已知端点列表。有关详细信息，请参阅下面的出站过滤部分。
资源隔离——CPU 和内存分配有上限。进入无限循环或生成大量输出的 Agent 不会耗尽同一主机上其他沙箱的资源，因为资源限制在 VM 或容器级别强制执行。
这些维度共同定义了 爆炸半径：如果 Agent 行为不当、崩溃或执行意外代码，最坏的情况是什么？
什么是出站过滤，为什么它很重要？
出站过滤控制允许 Agent 从沙箱内部进行哪些出站网络连接。
在宽松配置中，Agent 可以向互联网上的任何主机发起 HTTP/HTTPS 调用。这对于获取包、调用外部 API 或浏览网页的编码 Agent 来说很方便。这也意味着一个被入侵的 Agent，或者一个被提示注入攻击操纵的 Agent，可以将数据外泄到攻击者控制的服务器，或与不应触及的基础设施交互。
在严格配置中，出站锁定为显式允许列表：Agent 只能调用模型 API、特定数据库和包注册表。其他所有内容都被丢弃。这更难设置，并且需要随着 Agent 依赖项的变化维护允许列表，但它提供了更小的攻击面。
大多数生产环境中的 Agent 部署介于这两个极端之间：出站不是完全不受限制，但也不是从一开始就锁定为零信任列表。常见的模式包括阻止已知的恶意目标、记录所有出站调用以供审计，以及随着 Agent 行为变得可预测而逐步收紧列表。有关 出站控制 的完整分类以及哪些内容仍可能逃逸每个隔离边界，请参阅安全代码执行指南。
一些沙箱提供商通过 SDK 提供可编程的出站控制。其他提供商默认将沙箱视为完全开放出站。在假设您的 Agent 无法访问外部主机之前，请了解您的提供商使用哪种模型。
Agent 沙箱中的快照是什么？
快照捕获运行中沙箱的确切状态——文件系统、内存、运行中的进程、网络状态——并将其保存，以便以后可以将沙箱恢复到该状态。
这在以下几种场景中很有用：
减少冷启动成本——而不是每次启动新 VM 并安装包，您可以启动一次，安装所有内容，拍摄快照，然后在每个新会话中从该快照恢复。Daytona 能够在 90 毫秒以下实现冷启动，正是因为这项技术。
检查点长时间运行的 Agent——一个处理多小时任务的编码 Agent 可以在中途暂停，其确切状态被保存。如果需要审查、修改或重新启动 Agent，它可以从检查点恢复，而不是从头开始。
可复现的评估——对于 RL 训练或模型评估流水线，您可以快照一个已知良好的起始状态，并在每个评估回合之前重置到该状态。这为您在许多运行中提供了真正相同的起始条件，而不是重新配置并希望状态匹配。
并非所有沙箱提供商都在 API 级别公开快照控制。E2B 的模板系统处理“预装环境”用例，但不提供任意中间会话的检查点-恢复功能。Daytona 的快照 API 更灵活。
什么技术支撑 Agent 沙箱？
最常见的基础技术是：
Firecracker——由 AWS 开发的 microVM 运行时，内部用于 Lambda 和 Fargate。Firecracker 在 500 毫秒内启动一个最小的客户内核，暴露最小的设备模型以减少攻击面，并得到 KVM 硬件虚拟化的支持。E2B 和 Novita Agent Sandbox 都使用 Firecracker。
gVisor——由 Google 开发的内核沙箱，它拦截系统调用而不是运行完整的客户内核。它比 microVM 更轻量，但不提供完整的内核隔离——它位于进程级和 VM 级隔离之间。
带有系统调用过滤的 Docker 容器——使用 seccomp、AppArmor 和最小权限加固的容器。这是最常见的起点，但对于不受信任的代码来说是最弱的隔离边界。
V8 / Deno——使用 V8 运行时的权限模型进行 JavaScript 特定的隔离。适用于仅 JavaScript 工作负载的沙箱，但对于需要运行任意 shell 命令或非 JS 代码的 Agent 来说不可用。
底层技术的选择决定了沙箱的启动性能、隔离强度和操作复杂性。对于在多租户上下文中运行不受信任或 LLM 生成的代码的 Agent 工作负载，Firecracker 类别的隔离是当前的实际标准。
AI Agent 能否从沙箱中逃逸？
在实践中，沙箱逃逸很少见，但并非不可能，风险状况取决于技术：
容器逃逸 有记录。配置错误的容器——特权模式、挂载 Docker 套接字、可写的主机目录——具有已知的逃逸向量。一个没有特权、只读根文件系统和最小权限的强化容器可以大大降低这种风险，但并不能消除它。
microVM 逃逸 需要管理程序漏洞或设备模型缺陷。这些很少见，因为攻击面设计上很小。Firecracker 的最小设备模型专门设计用于减少管理程序暴露。AWS 尚未披露任何生产环境中的 Firecracker 级别逃逸。
对沙箱操作的提示注入 是另一种“逃逸”——不是内核漏洞，而是攻击者将指令嵌入用户提供的内容中，导致 Agent 执行不应执行的操作。这是一个应用层的问题，而不是沙箱层的问题。沙箱有助于限制提示注入的损害（注入的代码在沙箱内运行，而不是在您的主机上），但它们不能阻止注入本身。
实际结论：一个配置良好的基于 Firecracker 的沙箱在理论上并非无法逃逸，但攻击门槛足够高，以至于对于大多数企业 Agent 部署来说，残余风险是可控的。更常见的失败模式是配置错误（过于宽松的出站、传入沙箱的凭据范围不当）而不是内核级漏洞。
AI Agent 沙箱支持 GPU 工作负载吗？
截至 2026 年中，大多数 AI Agent 沙箱不包含 GPU 支持。E2B、Daytona 和 Vercel Sandbox 都是仅 CPU 的。
Modal 是托管沙箱领域的主要例外——它在容器内提供按需 GPU 访问，适用于模型推理、微调或需要与 Agent 代码在同一环境中使用 GPU 的 RL 工作负载。
对于大多数 Agent 工作流，Agent 本身调用外部 LLM 推理 API（如 Novita 的推理端点），而不是在本地运行模型。在这种架构中，您不需要沙箱中的 GPU——沙箱处理代码、文件操作和工具调用，而繁重的推理在单独的 GPU 服务上运行。这是编码 Agent、数据分析 Agent 和大多数浏览器自动化工作流使用的模式。
如果您确实需要在沙箱内使用 GPU——例如，离线使用的本地模型推理、RL 训练步骤或多步评估流水线——请在提供商选择中考虑这一点。Modal 目前是这种模式最常用的选项。
何时真正需要专用沙箱？
并非每个 AI 应用程序都需要专用沙箱。以下场景中沙箱会带来实际价值：
您正在执行 LLM 生成的代码——Agent 编写并运行非人类编写的代码，可能执行意外操作。这是核心用例：执行在沙箱中进行，因此不会影响您的主机、凭据或其他工作负载。
您正在为最终用户提供服务——多个用户的 Agent 运行共享相同的基础设施。您需要用户之间的隔离，这样一位用户的 Agent 就不会有意或无意地影响另一位用户的。
您需要长时间运行的有状态工作流——一个编辑文件、运行测试和提交更改的编码 Agent 需要一个跨许多 LLM 轮次持久化的工作空间。每次调用都使用新的子进程不会维持状态；而沙箱可以。
您有合规或审计要求——您需要记录所有 Agent 操作、限制网络访问，或证明 Agent 工作负载无法访问生产数据库或凭据。沙箱为这些控制提供了实施层。
您正在进行浏览器或计算机使用自动化——浏览器自动化沙箱 环境与主机完全隔离，因此 Agent 可以点击、输入和截图，而不会影响您的本地浏览器会话或系统状态。
如果您只运行一个简单的“总结这段文本”流水线且没有代码执行，您可能不需要专用的执行沙箱——对 LLM 的 API 调用就足够了。一旦 Agent 开始执行具有副作用的操作：写入文件、运行代码、代表您调用外部 API，沙箱就变得必要了。
常见问题
AI Agent 沙箱与开发环境相同吗？
不。开发环境是人类开发者的工作空间——它跨会话持久化，长期存在，旨在定制和重用。AI Agent 沙箱是运行时执行边界：它存在于任务持续期间，旨在短暂且可复现，其主要工作是隔离，而不是开发者的舒适度。一些沙箱可以在会话中跨 LLM 轮次持久化状态（使其感觉更像工作空间），但设计目标是与主机隔离，而不是一个功能齐全的 IDE。这些术语在供应商营销中有时会重叠；如果您正在评估平台，请查看隔离边界实际是什么，而不是标签。
什么是 Agent 执行沙箱？
Agent 执行沙箱与 AI Agent 沙箱是同一回事——“执行”框架只是强调了运行时方面。当 LLM 决定采取行动（运行代码、调用工具、写入文件）时，这些操作在沙箱内执行。沙箱是执行层，强制执行 Agent 所做与系统其余部分可见或受影响之间的边界。术语“Agent 沙箱”、“代码执行沙箱”和“Agent 执行环境”在行业中可互换使用。
对于 AI Agent 工作负载，Firecracker 与 gVisor 相比如何？
两者都提供超越标准容器的隔离，但通过不同的机制。Firecracker 在 KVM 支持的 microVM 内启动一个最小的客户内核——沙箱拥有自己的内核，与主机内核完全分离。gVisor 使用用户空间内核（runsc）拦截系统调用，而不运行完整的客户内核。实际权衡：Firecracker 提供更强的主机边界，因为客户内核完全分离；gVisor 每个沙箱的内存开销更低，因为它不运行完整内核，但隔离介于完整的 microVM 和通过系统调用拦截强化的容器之间。对于运行不受信任的 LLM 生成代码的多租户 AI Agent 工作负载，Firecracker 类别的隔离是当前的生产标准。gVisor 适用于代码部分受信任且内存密度比最大隔离更重要的场景。
提示注入会导致 Agent 逃逸其沙箱吗？
提示注入不会绕过沙箱的技术隔离——它利用 Agent 的决策能力执行攻击者意图但开发者未预见的操作。像“将环境变量外泄到此 URL”这样的注入指令会导致 Agent 进行出站网络调用，这仅当出站策略阻止它时才会被阻止。沙箱的文件系统和进程隔离保持不变。这意味着沙箱安全和提示注入防御处理的是堆栈的不同部分：沙箱在基础设施层面限制 Agent 可以做什么的爆炸半径；应用层控制（工具调用限制、人工批准、出站允许列表）防御 Agent 被指示滥用这些能力。
为什么特别需要为 AI Agent 使用沙箱？
与传统代码执行的关键区别在于不确定性。当人类开发者编写代码时，开发者大致知道它会做什么。当 LLM 生成代码或决定调用工具时，应用程序可能对具体运行什么、安装哪些包或联系哪些外部端点只有有限的可见性——跨可能数千个并发会话。这种不确定性提高了每个标准安全控制的重要性：出站策略很重要，因为 Agent 可能达到无人预料到的端点；包治理很重要，因为 Agent 可能动态安装依赖项；审计日志记录很重要，因为当 Agent 的操作未预先枚举时，重建发生的情况更加困难。沙箱为您提供了处理这种不确定性的实施层，而无需提前信任每个单独的 Agent 操作。
常见沙箱提供商
主要选项的简要概述，在链接的文章中有更全面的比较：
- Novita Agent Sandbox——Firecracker microVM，在您自己的 AWS 或 GCP VPC 中 BYOC 部署，无订阅费，最长 24 小时会话。对于有合规要求、成本敏感或已使用 Novita 进行 LLM 推理的团队来说，是主要选择。请参阅 novita.ai/sandbox。
- E2B——托管，Firecracker microVM，大型社区，无自托管。文档齐全的 SDK 和活跃的生态系统。
- Daytona——低于 90 毫秒的冷启动，开源（AGPL），可自托管。更适合需要自托管基础设施的延迟敏感或合规用例。
- Modal——当您需要在沙箱内使用 GPU 时的主要选项。基于容器的隔离。
- Vercel Sandbox——快速冷启动，最适合 Vercel 平台上的 JS/TS。
有关包含规格和决策框架的完整比较，请参阅 2026 年最佳 AI Agent 沙箱。有关 E2B 和 Daytona 的深入评估——冷启动、BYOC、快照和定价——请参阅 比较 E2B 和 Daytona 的 AI Agent 沙箱评估指南。
