在评估开源 AI 智能体沙箱时，团队应首先检查其真正的隔离边界、工作空间持久化模型、出口流量和软件包控制、密钥处理、可审计性，以及安全运行所需投入的运维工作。正确的选择并非寻找一个通用的优胜者，而是将沙箱模型与你的威胁模型、智能体工作负载、合规需求和工程能力相匹配。
什么是 AI 智能体沙箱？
AI 智能体沙箱是一种执行环境，智能体可以在其中运行代码、检查文件、自动化浏览器、调用工具或完成任务，而无需获得对宿主机或生产网络的广泛访问权限。它是模型推理与现实世界影响之间的边界。
这个边界之所以重要，是因为现代智能体所做的远不止编写文本。一个编码智能体可能需要克隆仓库、安装依赖、运行测试、开启预览端口以及提交拉取请求。一个浏览器或数据智能体可能需要执行脚本、保持状态、下载文件和捕获屏幕截图。这些操作需要一个运行时，而运行时需要控制。
在进行评估时，应区分四个层次：
| 层次 | 决定内容 | 重要性 |
|---|---|---|
| 智能体框架 | 模型如何规划、调用工具并对结果做出反应 | 好的框架不会自动创建安全的运行时 |
| 沙箱运行时 | 命令、文件、浏览器会话和进程运行的地方 | 这是主要的隔离和生命周期边界 |
| 策略层 | 沙箱可以读取、获取、安装、暴露或保留的内容 | 这决定了沙箱是否符合你的风险模型 |
| 审查层 | 运行后可用的日志、差异、工件和审批记录 | 这决定了人工能否验证发生的事件 |
自托管和开源选项可以让团队对这些层次拥有更多控制权。同时，它们也将更多的责任转移到了运营团队身上。
何时适合自托管？
当你的团队需要直接控制部署位置、网络路径、基础镜像、保留规则、日志系统或内部安全审查时，自托管是合理的。
当实际需求仅仅是“让智能体安全地运行代码”时，自托管的吸引力就降低了。在这种情况下，托管沙箱可能更容易运营，因为提供商会处理配置、扩展、运行时更新、可用性以及部分开发者体验。
当至少满足以下一个条件时，考虑使用自托管：
- 你的策略要求执行环境位于特定的云账户、VPC、区域或私有网络中。
- 你的智能体需要自定义基础镜像、内部包镜像、私有源系统或内部浏览器目标。
- 你的安全团队希望检查隔离栈、出口路径、保留模型和日志。
- 你们有足够的工程能力来修补运行时组件、监控滥用信号、轮换密钥和调试故障。
如果无法承担运维工作，默认应避免自托管。沙箱在演示时看起来很简单，因为单个容器或虚拟机就可以运行一条命令。生产环境则不同：你需要并发限制、资源配额、镜像清理、包缓存策略、网络策略、密钥范围界定、遥测、事件响应以及清晰的升级路径。
值得评估的开源沙箱选项
开源领域变化迅速，因此请将此视为一个阶段性参考，而非永久的功能矩阵。截至 2026 年 6 月 24 日，以下项目和工具是你在比较自托管或开源智能体沙箱路径时值得检查的有用示例。
| 选项 | 首先检查什么 | 自托管相关问题 |
|---|---|---|
| E2B | 开源沙箱/运行时组件、SDK、模板和基于 Firecracker 的沙箱定位 | 哪些部分是开源的，当前支持哪些部署模式，你的团队还需要做哪些运维工作？ |
| Daytona | 用于开发和 AI 智能体用例的工作空间和沙箱基础设施，包含开源仓库和自托管文档路径 | 它的工作空间模型、API 接口和部署架构是否匹配你的智能体工作负载和安全策略？ |
| OpenHands | 智能体平台，具有使用沙箱环境执行智能体操作的有文档记录的运行时架构 | 你是要采用整个智能体平台，还是只借用其运行时模式？ |
| SWE-ReX | 用于软件工程智能体研究和评估工作流的开源运行时接口 | 它的抽象层是否适合你的生产需求，还是主要用于受控的评估验证环境？ |
| Modal Sandbox | 托管式沙箱 API，而非开源自托管运行时 | 可作为 API 易用性、进程执行、文件系统和超时行为方面的对比参考，并非自托管选项 |
不要仅凭表格做选择。对于每个项目，请阅读当前文档，查看最新的发布说明，并使用你自己的工作负载运行一个小型概念验证。评估应回答：可以运行什么，哪些被隔离，哪些持久存在，哪些可以访问网络，哪些可以查看密钥，以及任务完成后留下了哪些证据。
隔离边界：容器、微虚拟机与全虚拟机
首要问题不是“它安全吗？”，而是“隔离边界是什么？”
容器因其快速、熟悉且易于围绕 Docker 镜像构建而具有吸引力。它们适用于可信的内部任务、类似 CI 的作业、短时分析以及威胁模型适中的开发工作流。但容器共享宿主机内核，因此处理不可信代码或多租户工作负载的团队需要评估内核暴露、seccomp/AppArmor 配置文件、用户命名空间、挂载卷、特权模式以及逃逸响应。
微虚拟机（例如 Firecracker 风格的隔离）在保持启动速度和密度接近容器工作流的同时，增加了更强的虚拟机边界。它们在智能体沙箱讨论中很常见，因为可以为每个会话提供独立的内核和更严格的资源边界。但这并不能消除对网络策略、密钥控制、补丁管理或主机加固的需求；它只是明确了运行时隔离层。
全虚拟机可能适用于更严格的企业环境、桌面自动化或需要更广泛操作系统表面的工作流。其代价是更重的启动、镜像管理和容量规划。
在自托管前，请提出以下问题：
| 检查项 | 要验证什么 |
|---|---|
| 内核边界 | 沙箱是与其他工作负载共享内核，还是每个会话拥有独立内核？ |
| 租户边界 | 两个客户会话是否会共享主机级资源、卷、缓存、浏览器配置文件或网络命名空间？ |
| 权限模型 | 沙箱是否运行特权容器、root 用户、挂载的 Docker 套接字或主机路径？ |
| 逃逸态势 | 内核、运行时、容器和虚拟机漏洞如何被修补和部署？ |
| 资源控制 | 是否对每个会话强制执行 CPU、内存、磁盘、进程数、打开文件数和运行时长的限制？ |
| 侧信道 | 你的风险模型是否需要缓解共享 CPU、缓存、磁盘或噪声邻居行为？ |
如果一个项目描述自己“隔离”，请继续阅读直到你了解其机制。
状态、文件与工作空间生命周期
即使沙箱是短命的，智能体工作也是状态化的。智能体可能创建文件、安装软件包、保留浏览器配置文件、运行后台进程或等待人工审查工件。你的沙箱需要一个清晰的工作空间模型。
从生命周期开始：
- 从基础镜像或模板创建沙箱。
- 挂载或克隆允许的工作空间。
- 在策略下运行设置命令。
- 让智能体执行命令、浏览器操作和文件操作。
- 提取输出：差异、日志、截图、报告或下载的文件。
- 停止、暂停、快照、归档或销毁沙箱。
关键点在于，持久化应该是有意为之的。持久化工作空间对于长时间运行的智能体、多步骤编码任务以及人在回路审查非常有用。但同样，如果清理不彻底，陈旧的凭据、缓存的依赖项、浏览器 cookie、生成的数据和部分工作结果可能会在会话之间泄露。
在自托管之前，需定义：
- 每个智能体任务是否获得一个全新的文件系统。
- 包缓存是共享的、作用域隔离的还是重建的。
- 浏览器配置文件是否在运行之间持久化。
- 用户上传的文件是被复制、挂载还是流式传输。
- 快照是否包含密钥、令牌、cookie 或内部日志。
- 日志和工件的保留时长。
- 谁可以重新打开一个已暂停的会话。
一个好的沙箱让默认生命周期变得平淡无奇。你应该能够解释任务开始前存在什么，任务期间改变了什么，以及清理后留下了什么。
网络、软件包与出口策略
网络访问是许多沙箱设计变得模糊的地方。智能体通常需要互联网，但“互联网访问”并非单一权限。
一个编码智能体可能需要包注册表、公共文档、Git 远程仓库和一个预览 URL。一个浏览器智能体可能需要一个测试应用程序、一个暂存 API 和截图存储。一个数据智能体可能需要对象存储、数据库副本或受限的 SaaS API。这些是不同的权限，具有不同的风险。
使用分类：
| 出口类型 | 典型需求 | 策略问题 |
|---|---|---|
| 包注册表 | npm、pip、apt、cargo、模型/工具依赖 |
注册表是否被列入白名单、缓存、扫描并记录？ |
| 公共网络 | 文档查找、浏览器任务、公共数据收集 | 是否允许任意浏览，是否进行代理、限速和审计？ |
| Git 访问 | 克隆仓库、推送分支、获取子模块 | 令牌是否尽可能为只读，并且作用域限定于当前任务？ |
| 内部 API | 暂存服务、测试应用、私有包镜像 | 访问是否按环境、服务、路由和凭据进行限制？ |
| 预览入口 | 人工审查本地 Web 应用或生成的报告 | 哪个端口被暴露，向谁暴露，暴露多长时间，使用什么认证？ |
| Webhook | 智能体回调、CI 事件、外部工具集成 | 沙箱能否向任意主机发送出站回调？ |
软件包策略需要特别关注。许多智能体任务在未安装依赖项时会失败，但安装包会带来安装后脚本、原生二进制文件、注册表篡改、误植域名风险以及长缓存生命周期。优先使用基于锁文件的安装、批准的注册表、短生命周期的令牌和安装日志。
对于自托管系统，还需决定谁负责 DNS 日志、代理配置、证书信任存储和网络事件响应。
密钥、日志与审计追踪
智能体沙箱不应成为模型轻易打印、复制或泄露原始凭据的地方。
最安全的模式是任务作用域访问。为沙箱提供完成任务所需的最小凭据，并在任务结束后移除它。一个编码任务可能需要一个只读的仓库令牌和一个拉取请求令牌。一个浏览器任务可能需要一个测试账户，而不是一个生产用户。一个数据任务可能需要一个临时的签名 URL，而不是一个长期有效的云凭据。
避免将密钥放在智能体可以随意读取的文件中。环境变量很方便，但许多调试命令会打印环境状态。如果平台支持代理操作，请使用它们：让沙箱执行一个狭窄的操作，而不将原始凭据暴露给模型循环。
日志记录应足够强大，以支持审查和事件响应：
- 请求、批准、拒绝和执行的命令。
- 工作目录、退出码、标准输出、标准错误、超时和资源使用情况。
- 任务产生的文件工件。
- 策略支持粒度下的网络目标。
- 包名称、版本、注册表和安装输出。
- 密钥编辑决策和编辑失败记录。
- 高风险操作的人工批准。
目标不是让审查者淹没在日志中，而是当智能体产生意外输出、依赖项变更或令牌疑似泄露时，能够重建发生了什么。
重置、快照与多租户风险
重置行为是一个生产环境特性，而非演示结束时的清理脚本。
临时沙箱更容易推理：创建、运行、提取工件、销毁。它们适用于短时间代码执行、一次性浏览器操作和评估任务。持久化沙箱有助于更长的工作流，但需要所有权、过期和审查控制。
快照和模板介于这些模型之间。它们可以通过保留已准备好的环境来加速启动，但也会保留快照内的一切。验证它们是否包含：
- 已安装的包和缓存。
- Shell 历史或进程状态。
- 浏览器 cookie、本地存储和下载文件。
- 临时文件和生成的输出。
- 凭据或配置文件。
- 来自先前任务的日志。
对于多租户系统，询问调度器如何放置工作负载，缓存是否共享，磁盘如何擦除，以及主机级资源如何监控。还要询问故障期间会发生什么。崩溃、超时或失去控制器的沙箱仍然需要清理和工件处理。
开发者访问与调试路径
自托管沙箱需要实用的调试方案。当智能体失败时，开发者需要知道问题是模型、工具调用、运行时、镜像、包镜像、网络路径还是目标应用程序。
有用的调试路径包括：
- 一种从相同基础镜像重放命令的方法。
- 命令执行和工具调用的结构化日志。
- 可下载的工件和截图。
- 明确的超时和资源限制错误。
- 当策略允许时，开发者以受控方式附加到实时会话。
- 版本化的模板或镜像，以便将失败与特定环境版本关联。
- 用户可见输出与内部运行时日志之间的清晰分离。
注意紧急访问。对实时沙箱的广泛 Shell 访问可能违反沙箱旨在执行的隔离假设。定义谁可以附加、他们可以看到什么、密钥是否被编辑以及访问如何记录。
Novita Agent Sandbox 的定位
Novita Agent Sandbox 是一个托管式智能体运行时，用于代码执行、浏览器自动化、计算机使用风格的工作流、数据分析、评估和长时间运行的智能体工作流。Novita Agent Sandbox 文档 描述了一个有状态的沙箱环境，提供了用于生命周期、命令、文件、浏览器会话和相关工作流原语的 SDK 和 CLI 路径。
因此，当你的团队希望获得智能体执行基础设施，而无需从第一天起承担全部自托管运维负担时，Novita 是一个值得评估的选择。
请保持边界清晰：
- 当部署控制、源码级定制或内部基础设施所有权是优先事项时，使用开源或自托管运行时。
- 当更快的采用、提供商管理的运行时运维和 API 优先的工作流比拥有每一层更重要时，使用托管沙箱。
- 无论哪种情况，都要根据你自己的策略评估隔离性、出口、包安装、密钥、日志、持久化和审查网关。
不要将任何提供商名称视为安全保证。将其视为一个仍需进行架构审查的运行时选择。
自托管检查清单
在将开源 AI 智能体沙箱投入生产之前，请使用此清单。
| 领域 | 投产前的最低问题 |
|---|---|
| 隔离性 | 边界是容器、微虚拟机、全虚拟机还是其他，并且对于该工作负载是否足够？ |
| 工作空间 | 每个任务是否从已知的文件系统状态开始，并且能否重置？ |
| 持久化 | 暂停、恢复、快照和保留是否明确而非意外？ |
| 网络 | 包获取、浏览、API 调用、Git、Webhook 和预览入口是否被分别控制？ |
| 软件包 | 锁文件、注册表、安装后脚本、原生二进制文件和缓存是否得到管理？ |
| 密钥 | 凭据是否任务作用域化、被编辑、轮换，并且对无关命令不可用？ |
| 日志 | 审查者能否重建命令、输出、文件更改、网络路径和批准记录？ |
| 多租户 | 主机共享、缓存共享、磁盘清理、配额和噪声邻居行为是否被理解？ |
| 调试 | 工程师能否在不绕过安全模型的情况下重现故障？ |
| 运维 | 谁负责修补镜像、运行时、内核、依赖项和沙箱控制器？ |
| 滥用控制 | 是否强制执行超时、资源限制、速率限制和终止路径？ |
| 退出路径 | 即使沙箱崩溃或超时，工件能否被导出和审查？ |
如果几个答案不明确，请将该项目保留在原型阶段。一个无法解释其边界的沙箱，尚未准备好大规模运行不可信的智能体工作。
常见问题解答
最好的开源 AI 智能体沙箱是什么？
没有适用于所有团队的唯一最佳开源 AI 智能体沙箱。正确的选择取决于你的隔离需求、部署模型、智能体工作负载、出口策略、持久化需求和运维能力。通过在每个候选运行时中运行你自己的任务来比较选项。
Docker 足够用于 AI 智能体沙箱吗？
Docker 对于可信的内部自动化、本地开发和类似 CI 的作业来说已经足够，但对于不可信代码或严格的多租户工作负载可能不足。在仅依赖容器之前，请检查内核共享、权限、挂载卷、网络访问、密钥和逃逸响应。
对于智能体工作负载，微虚拟机比容器更安全吗？
微虚拟机可以提供更强的隔离边界，因为每个沙箱可以运行在独立的内核上。但这并不能自动解决出口、软件包、密钥、日志记录、补丁管理或多租户运维问题。将微虚拟机视为架构的一部分，而非全部安全模型。
在自托管智能体沙箱之前，我应该测试什么？
测试一个真实的工作负载，该工作负载需要克隆或挂载文件、安装依赖项、运行命令、处理密钥、访问已批准的网络目标、生成工件、超时并重置。还要测试失败路径：软件包安装失败、浏览器崩溃、网络拒绝、资源限制以及控制器错误后的沙箱清理。
什么时候应该使用托管沙箱而不是自托管？
当你的团队希望获得智能体执行 API 和审查工件，而无需负责运行时修补、扩展、容量规划和基础设施运维时，使用托管沙箱。当部署控制或源码级定制的重要性足以证明相应工作量时，则选择自托管。
