AI 智能体沙箱将生成的代码与主机系统隔离，但具体细节——隔离如何工作、智能体拥有怎样的网络访问权限、文件存放位置、密钥如何处理——各实现方案之间差异很大。本常见问题解答将最常见的问题整合到一篇参考文档中，并附上各领域更深入文章的链接。如果你刚接触沙箱，请先阅读 什么是 AI 智能体沙箱？ 了解隔离模型、出站和快照的基础知识。如果你在选择提供商，请参阅 2026 年最佳 AI 智能体沙箱 或 E2B 与 Daytona 评估指南。
为何要对 AI 智能体进行沙箱隔离
为什么团队要为 AI 智能体使用专用沙箱？
AI 智能体与传统软件有一个关键区别：它们运行的代码并非由人类编写并在执行前经过审查。LLM 动态生成指令、选择工具、安装包和发起 API 调用——其方式常常是应用程序开发者事先无法枚举的。沙箱提供了一个运行时强制层，能够包含这些操作的后果，无需预先批准每一个可能的行为。没有沙箱，一个行为异常或被操纵的智能体可能会影响主机系统、相邻工作负载或外部基础设施。有了沙箱，最坏情况的爆炸半径被限定在隔离环境内，会话结束后可以丢弃该环境。
什么是 AI 智能体代码执行？
AI 智能体代码执行是 LLM 的决定变为计算机实际指令的运行时阶段。智能体接收任务、进行推理、生成代码或工具调用，执行层运行这些操作并将结果返回给智能体。沙箱是此执行阶段的标准基础设施层：它提供智能体所需的计算、文件系统和网络环境，同时将该环境与一切其他环境隔离。“模型推理 → 执行层运行 → 结果反馈给模型”的循环不断重复，直到智能体完成任务。
沙箱隔离与仅在容器中运行智能体有何不同？
容器增加了文件系统和网络命名空间隔离，但同一主机上的所有容器共享操作系统内核。对于运行来自不可信输入的 LLM 生成代码的 AI 智能体，通过共享漏洞实现的内核级逃逸可能会影响相邻工作负载。专用的 AI 智能体沙箱通常会添加一个 microVM 边界：智能体的代码在轻量级虚拟机内运行，拥有自己的客户机内核，因此即使客户机内核遭到利用，也不会影响主机。实际权衡是少量额外的冷启动开销（对于基于 Firecracker 的平台，通常在 500 毫秒以下）。完整对比请参见隔离模型部分。
沙箱隔离模型
AI 智能体沙箱中的“隔离”是什么意思？
隔离意味着智能体的代码、文件、进程和网络访问被限制在一个有边界的环境中，无法影响主机系统或其他租户。实践中，隔离是一个谱系：进程级隔离使用操作系统原语（命名空间、cgroups、seccomp）限制系统调用和资源访问；容器隔离增加了文件系统和网络命名空间边界；microVM 隔离则将工作负载封装在具有自己客户机内核的轻量级虚拟机中。每向上一个层次，边界强度增加，代价是增加一些启动开销和操作复杂性。有关所有隔离维度的全面概述，请参阅什么是 AI 智能体沙箱？。有关详细的评估框架，请参阅 适用于 AI 智能体沙箱的 Firecracker。
Docker 足以运行智能体生成的代码吗？
容器提供了可重复的镜像和良好的资源控制，但同一主机上的所有容器共享主机内核。内核漏洞或绕过 seccomp 过滤器的系统调用可能会影响其他工作负载。对于运行可信或接近可信代码的低风险、短期任务，如果在正确加固的情况下（无特权模式、最小能力、未挂载 Docker 套接字、尽可能只读根文件系统），容器通常足够。对于可能安装包、生成子进程或调用任意 shell 命令的不可信 AI 生成代码，值得评估更强的边界。答案取决于你的实际威胁模型。有关各隔离级别的验证清单，请参阅 AI 生成代码沙箱：生产应用要求。
容器和 microVM 隔离之间的区别是什么？
关键区别在于内核边界。容器共享主机内核；microVM 在轻量级虚拟机内各自运行一个客户机内核，由硬件虚拟化（KVM）支持。使用 Firecracker 等技术的基于 microVM 的沙箱提供了虚拟机风格的边界，而没有传统虚拟机的全部开销：启动延迟设计得很快，设备模型最小化以减少攻击面，并且客户机与主机内核在设计上是隔离的。实际影响是，客户机内核的利用不会自动影响主机或其他客户机，而在共享内核的容器模型中则可能。有关 microVM 边界在何处有帮助以及不能解决全部问题的内容，请参阅 适用于 AI 智能体沙箱的 Firecracker。
沙箱是每个智能体、每个用户还是每个任务一个？
这取决于平台以及应用程序的设计方式。对于多租户应用程序，最安全的模式是每个智能体运行或每个任务有一个隔离的沙箱环境——意味着每个用户的会话拥有自己的进程树、文件系统、网络命名空间和凭证作用域。跨用户或跨不相关任务共享沙箱是生产智能体应用程序中最常见的状态泄漏来源。评估平台时，确认并发会话在文件系统、进程和网络级别是隔离的，而不仅仅是在 API 路由级别。有关按会话隔离的清单，请参阅 AI 生成代码沙箱：生产应用要求。
沙箱出站和网络策略
AI 智能体是否可以从沙箱发起出站网络调用？
这取决于沙箱的出站策略。默认情况下，许多沙箱允许出站连接，这对于网络研究、API 调用和包安装很方便。对于运行不可信代码的生产工作负载，默认开放出站存在风险：受损或行为异常的智能体可以泄露数据、访问内部元数据服务或从任意 URL 拉取意外代码。更强的生产姿态是默认拒绝出站，并附有明确允许的目的地列表。无论选择何种策略，都应该是明确的并进行日志记录。关于如何评估网络控制，请参见 适用于 AI 智能体沙箱的 Firecracker。
沙箱中的 DNS 如何控制？
DNS 是出站策略中常见的空白：对 HTTP 目标的允许列表不会自动限制 DNS 解析。能够解析任意域名的智能体可以推断网络拓扑、探测内部名称，甚至在 HTTP 被阻止时使用 DNS 作为侧信道。为了保持出站策略的一致性，DNS 解析应统一处理——要么指向一个尊重允许列表的内部解析器，要么将解析限制在批准的域名。向你的沙箱提供商确认 DNS 与更广泛的出站策略之间的关系。
在网络受限会话期间如何控制包获取？
包安装是网络操作。如果出站被限制为允许列表，该允许列表必须包含智能体合法需要的包注册表，或者沙箱应在可信网络内提供拉取缓存。拉取缓存的额外好处是作为检查点：你可以查看获取了哪些包，捕获意外依赖，并减少冗余出站。有些团队对于可重现性比灵活性更重要的工作负载使用预制的沙箱模板，这完全消除了运行时包获取。关于管理运行时安装的更多内容，请参见包安装部分。
文件访问和主机文件系统
沙箱化智能体拥有哪些文件访问权限？
沙箱化智能体应仅能访问显式挂载到其工作空间中的文件。对于编码智能体，这可能是检出的仓库和工作目录（用于生成制品）。对于数据分析智能体，这可能是上传的 CSV 文件和输出文件夹。智能体不应能够访问主机文件系统、其他租户的工作空间、应用服务器的密钥或挂载路径之外的系统目录。良好做法是将源材料挂载为只读，并为生成的制品提供一个单独的读写输出目录。关于如何为每个工具限定文件系统挂载范围，请参见 MCP 服务器沙箱：具有文件系统、密钥和网络控制的隔离 MCP 服务器。
是否可以从沙箱内部访问主机文件系统？
不应该。正确配置的沙箱——容器或 microVM——将智能体的视图限制为仅其自己的客户文件系统。从沙箱内部访问主机文件系统是一种配置失败，而非预期行为。破坏此边界的常见错误包括挂载宽泛的目录（如开发者主目录或 /）、在容器中使用特权模式、或将 Docker 套接字挂载到沙箱中。在评估平台或构建自己的平台时，验证挂载了什么、根文件系统权限是什么，以及符号链接逃逸或存档提取技巧是否能够达到预期工作空间之外的路径。
会话结束后文件会怎样？
对于临时会话，工作目录和所有生成的文件在会话终止时被销毁。这是代码补全、评估运行以及任何可重现性比连续性更重要的任务的正确默认行为。对于持久工作空间（长时间运行的编码智能体、迭代开发会话），文件可以在会话内的多次执行调用之间存活，并且如果平台支持工作空间持久化或快照，则可能在会话结束后保留。需要回答的关键问题是：谁拥有保留的工作空间，何时清理它，以及一个用户的工作空间是否会泄漏给另一个用户？有关持久化模型清单，请见 AI 生成代码沙箱：生产应用要求。
会话状态和持久化
沙箱会话是有状态的还是临时性的？
两种模式都存在，并为不同的工作负载服务。临时会话为每个任务从干净的基线启动——没有累积的包、文件或历史记录。它们更易于推理，非常适合评估运行或一次性代码执行。有状态会话在多次执行调用之间保留文件、已安装的包、shell 历史记录和环境状态，这对于多步编码智能体、交互式数据分析和长时间运行的工作流是必需的。大多数生产平台都支持两者。权衡在于，有状态会话需要明确的清理策略和更仔细的租户隔离。
在托管沙箱中状态保留多长时间？
会话持续时间因平台和计划而异。一些提供商设置默认会话超时（通常为 60 分钟到 24 小时），之后会话终止，除非持久化到快照或外部存储，否则状态丢失。长时间运行的智能体工作流——在 LLM 调用之间可能暂停数分钟或数小时的会话——需要一个支持会话暂停和恢复或自动暂停的平台，以避免为空闲时间计费，同时保留状态。验证最大会话长度以及超时时进行中的状态会发生什么。Novita 智能体沙箱支持最长 24 小时的会话，并记录了用于管理空闲时间的暂停/自动恢复功能。有关功能对比，请参见 Novita 沙箱：与 E2B Pro 无缝兼容的高性价比替代方案。
会话可以暂停和恢复吗？
一些平台支持暂停和恢复，会话被挂起到磁盘，之后可以从相同状态重启。这对于在步骤间等待 LLM 响应的智能体、对昂贵工作负载进行速率限制以及跨多次用户交互的会话非常有用。需要验证的关键事项包括：暂停的会话可以保持挂起多长时间，暂停期间持有的网络连接会发生什么，以及在会话启动时注入的凭证在恢复后是否仍然有效或需要刷新。
沙箱状态可以被快照并重用吗？
模板和快照是相关但不同的概念。模板是预构建的基线环境——运行时、工具、批准的包——新会话从中启动。快照捕获运行中会话的当前状态，并将其用作未来会话的起点。模板减少了每会话的启动开销，并确保所有智能体从一致、受管控的基线启动。快照对于保留部分工作或热启动迭代作业很有用。两者都需要治理：谁可以创建它们，谁可以读取它们，它们属于哪个租户，以及如何进行版本控制。
包安装和运行时依赖
智能体可以在运行时安装包吗？
大多数沙箱环境默认允许运行时包安装（pip install、npm install、apt-get 等），因为许多智能体工作负载需要它们。问题不在于是否允许安装，而在于每次安装是否受管控。不受管控的包安装是沙箱中风险最高的操作之一：它们在运行时将外部代码拉入执行环境，可以包含执行任意命令的安装后脚本，并可能引入供应链风险。
什么策略管理运行时包安装？
生产包策略通常包含注册表允许列表（仅从批准的包注册表或镜像获取）、拉取缓存（在代码执行前检查进入的内容）、安装日志记录（记录每次安装的包名、版本、源和结果）以及可选的离线模式（将依赖预构建到模板中，并对可重现性重要的评估管道禁止运行时安装）。正确的策略取决于工作负载：帮助开发者调试代码的编码智能体可能需要灵活的包访问；自动评估管道可能应在冻结的环境中运行。有关实际实现示例，请参见 使用沙箱化 Python 和控制包访问构建 AI 数据分析师。
密钥和凭证处理
沙箱中如何处理密钥和凭证？
密钥应窄注入——仅注入特定任务所需的凭证，并且仅在该会话期间有效。常见的反模式是将包含所有 API 密钥的宽泛环境文件挂载到每个会话中；这意味着任何会话如果被入侵，都可以访问该文件中的每个凭证。应首选短期的、限定于任务的令牌，并优先使用注入机制（环境变量或挂载文件）而非硬编码。对于最敏感的凭证，运行时密钥 API（仅向显式授权的进程提供值）比所有进程都可用的平面环境变量提供更强的隔离。
模型可以看到注入沙箱的环境变量吗？
如果环境变量被注入到智能体代码运行的进程中，那么是的。默认情况下，环境变量对同一会话中的所有进程可见。模型无法直接从其上下文窗口读取它们，但在沙箱内执行的生成代码可以通过 os.environ、process.env 或等效方式读取它们。这就是窄作用域重要的原因：仅注入任务所需的凭证，并首选短期令牌，以便泄露的凭证只有有限的有效窗口。编辑是应用程序的责任：如果秘密可能出现在错误消息或打印语句中，则默认不要记录完整的标准输出。
会话结束时密钥会发生什么？
环境变量和挂载的密钥文件应在会话拆卸时清理。如果平台跨会话保留状态（快照、持久卷），请验证写入文件系统或由凭证提供者缓存的凭证是否也被清理或轮换。可恢复快照中的过期凭证是一种风险——会话拆卸后，快照不应保留仅对原始会话持续时间有效的令牌。
审计日志和可观测性
沙箱中记录了哪些事件？
有用的沙箱审计记录包括：会话创建和拆卸（会话 ID、租户、模板版本、资源分配、持续时间）、执行事件（运行的代码或命令类别、开始/结束时间、退出状态）、包安装（名称、版本、源、结果）、出站网络联系（域名、IP、端口）、从特定路径读取或写入的文件，以及清理结果。目标是使智能体行为事后可重建，同时避免审计日志成为第二个密钥存储。原始客户文件、完整命令输出和完整提示通常不属于审计日志，除非你的保留和访问控制专门为此类数据设计。
谁可以访问审计日志？
审计日志的访问控制应限定于操作员，并在相关情况下限定于租户。在多租户平台中，一个租户的审计记录不应被其他租户看到。对于合规敏感型部署，审计跟踪必须是防篡改的，保留所需期限，并按需可供授权审查者（安全团队、合规官）访问。询问你的沙箱提供商默认提供哪些日志保留期限，日志能否导出到你自己的 SIEM 或存储，以及保护日志数据的访问控制是什么。
合规性和安全审查
在生产中使用沙箱前需要进行哪些合规性审查？
具体要求取决于你的行业和司法管辖区，但任何生产智能体系统的标准问题包括：哪些数据进入沙箱（该数据是否受 GDPR、HIPAA、SOC 2 或其他框架约束），沙箱托管在何处以及是否满足数据驻留要求，隔离模型是什么以及能否向审计师记录，凭证如何管理和轮换，以及审计跟踪是什么。大多数安全审查还会询问生成的代码是否可能超出预期范围触及生产数据库、内部管理界面或客户数据。这些是架构控制，而不仅仅是供应商认证。
安全团队在评估 AI 智能体沙箱时应问哪些问题？
安全审查的实用评估清单：
- 隔离： 边界是什么——进程、容器还是 microVM？每个智能体会话在文件系统、进程和网络级别是否隔离？
- 出站： 默认出站策略是什么？出站目的地能否被列入允许列表？DNS 如何控制？
- 密钥： 凭证如何注入？是否限定于任务？会话拆卸时是否清理？
- 审计： 记录了哪些事件？谁可以访问日志？保留期限是多少？
- 数据驻留： 沙箱托管在何处？部署是否能限定到特定云区域或账户？
- 合规状态： 提供商是否持有相关认证（SOC 2、ISO 27001）？他们的共享责任模型是什么？
- 网络可达性： 沙箱能否访问内部元数据服务、私有 API 或其他租户的资源？如何防止横向移动？
将这些视为需要评估的问题，而非任何单一供应商自动满足的要求。供应商文档中的安全和合规声明应针对当前产品文档进行验证，而非仅凭表面判断。对于有监管或合同要求的团队，请由安全团队在生产部署前完成审查，而非之后。
何时需要 BYOC（自带云）或 VPC 部署？
数据驻留要求、网络安全策略或禁止数据离开特定云账户的监管限制是团队选择 BYOC 或 VPC 部署而非共享托管服务的主要原因。在您自己的 AWS 或 GCP VPC 内部运行沙箱意味着执行环境位于您的网络边界内，您云账户的访问控制适用，并且沙箱的出站可以由您现有的网络策略管理。权衡在于操作责任：您负责基础设施管理、补丁和扩展。Novita 智能体沙箱记录了作为 BYOC 部署到 AWS 或 GCP 账户的功能，用于满足这些要求的团队。在 Novita 智能体沙箱文档 中验证当前的可用性和配置选项。
沙箱定价和成本驱动因素
什么驱动沙箱成本？
沙箱成本通常是计算时间（按秒或分钟计费的 vCPU 和内存）、会话开销（某些平台上的按会话启动费用）、超出包含免费层的持久存储以及出站数据传输（出站流量）的组合。每项的相对权重取决于您的工作负载：短会话代码解释器主要是计算成本；下载大文件的浏览器自动化智能体可能产生大量出站流量；持久编码工作空间会累积存储成本。空闲时间处理是主要区别因素——具有自动暂停功能的平台在沙箱等待 LLM 响应时停止计费，这可以显著降低交互式工作流的成本。有关每个定价轴的详细分解，请参阅 AI 智能体沙箱定价模型：按会话、计算、存储和出站。
会话时间、计算和出站如何在成本中相互作用？
对于大多数工作负载，计算时间占主导地位。1 vCPU 上的 10 分钟编码会话比典型费率下 1 GB 出站流量的成本更高。但互动对于特定工作负载很重要：下载大型训练数据集的数据智能体将产生远超计算成本的出站费用。在 LLM 轮次之间保持会话打开的浏览器智能体，如果未启用自动暂停，将累积空闲计算。实际方法是在承诺某个平台之前，根据您的实际工作负载概况估算每个维度。Novita 智能体沙箱根据实际 vCPU 和内存使用量按秒计费，无按会话启动费用；截至 2026 年中期，1 vCPU 价格为 $0.0000098/s。（来源：Novita AI 定价页面，已在已发布文档中验证。在预算规划前请始终核实当前费率。）
自托管与托管 AI 智能体沙箱
团队何时应自托管而不是使用托管沙箱？
自托管（运行您自己的沙箱基础设施，通常基于 Firecracker 或类似的 microVM 层）在以下情况下有意义：数据驻留或网络安全策略禁止使用第三方托管服务；工作负载量足够高，以至于托管服务成本超过运行您自己基础设施的操作成本；或者团队已有平台工程能力，并希望对隔离模型、镜像治理和网络策略拥有完全控制。自托管比看起来更难：管理内核、根文件系统、镜像、快照、速率限制器、指标、清理和多租户隔离是实际工作。有关操作范围的内容，请参阅 适用于 AI 智能体沙箱的 Firecracker。
何时托管沙箱更合理？
对于大多数构建编码智能体、数据分析工具、浏览器自动化工作流或评估管道的团队来说，托管沙箱是通向生产的更快路径。平台处理基础设施配置、安全加固、镜像更新、扩展和生命周期管理。团队专注于智能体架构，而不是沙箱内部细节。成本比较不仅仅是云计算的费率：还要考虑构建和维护隔离层所需的工程时间、记录合规性所需的工作，以及发生意外事件时的应急响应。对于没有专用平台工程能力的团队，托管服务通常更快投入生产，并保持较低的总拥有成本。有关比较托管与自托管总成本的框架，请参阅 AI 智能体沙箱定价模型。
团队在评估托管沙箱提供商时应问哪些问题？
除标题价格外的实际评估问题：
- 每个会话的隔离模型是什么（microVM、容器、进程）？
- 默认和可配置的出站策略是什么？
- 存在哪些包安装治理选项？
- 密钥如何注入和清理？
- 哪些审计日志数据可用以及如何访问？
- 在您所需层级下的会话长度和并发限制是什么？
- 提供商是否支持 BYOC 或 VPC 部署？
- 暂停/恢复行为是什么，以及如何影响计费？
- 启动延迟在规模下如何表现（热池、快照、冷启动）？
安全运行不可信代码
如何在生产中安全运行 AI 生成的代码？
基线是：不要在您的主机上运行 LLM 生成的代码。将所有执行路由到提供文件系统、进程和网络隔离的沙箱。除此之外，五项实践会产生重大影响：（1）明确设置出站策略——默认拒绝并附带允许列表比默认开放更安全；（2）窄化密钥范围——仅注入当前任务所需的凭证；（3）治理包安装——允许从批准的注册表安装，或对可重现工作负载使用预构建镜像；（4）在内核或虚拟机监控程序级别进行日志记录，而非信任应用层日志；（5）设置资源限制——CPU、内存、磁盘和挂钟超时——以防止失控的智能体影响相邻会话。有关完整的评估清单，请参阅AI 沙箱执行代码的安全性如何？。
是否有开源 AI 智能体沙箱？
有。Daytona 在 AGPL 许可下开源并支持自托管部署。E2B 的核心 SDK 是开源的，但托管运行时基础设施不是。如果你想从头构建自己的沙箱，最常见的方法是使用 Firecracker（AWS 开发，Apache 2.0 许可）作为 microVM 运行时，并搭配自己的镜像管理、编排和生命周期控制。自托管意味着承担托管服务抽象出来的操作范围：内核管理、根文件系统治理、速率限制、快照存储、清理策略和多租户隔离。有关该范围在实际中是什么样子的内容，请参阅 适用于 AI 智能体沙箱的 Firecracker。
什么是托管 AI 沙箱平台？
托管 AI 沙箱平台是一种将沙箱基础设施作为 API 提供的云服务：你调用 SDK，沙箱被配置并返回就绪状态，平台处理底层的计算、网络、镜像管理和生命周期。Novita 智能体沙箱、E2B 和 Daytona 的托管模式都是例子。替代方案是自托管，你自行配置和操作沙箱基础设施。对于任何托管平台，关键问题是：它使用什么隔离模型，可配置的出站策略是什么，BYOC 或 VPC 部署是否可用，以及对于你预期的工作负载，按秒计费的价格是多少。请参阅 2026 年最佳 AI 智能体沙箱 获取结构化比较。
什么是适合企业使用的 AI 智能体沙箱？
企业 AI 智能体沙箱的要求通常超出开发者聚焦的托管服务默认提供的范围。常见要求包括：BYOC 或 VPC 部署（沙箱在您的云账户内运行，而非共享第三方租户）；SOC 2 或 ISO 27001 认证；可配置的出站策略和审计日志导出到 SIEM；使用短期令牌的会话级凭证限定；以及限制智能体工作负载执行位置的数据驻留控制。Novita 智能体沙箱 支持在您自己的 AWS 或 GCP VPC 内 BYOC 部署，这解决了最常见的企业数据驻留和网络隔离要求。在进行架构决策之前，请在产品文档中验证当前的合规认证和可用配置选项。
