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