这份 AI 代理沙箱 FAQ 解答了开发者在运行代理生成代码之前通常会问到的实际安全问题：隔离是如何工作的，代理拥有哪些网络访问权限，文件和会话状态存放在哪里，以及如何处理密钥、审计日志、合规性和成本。如果你是沙箱新手，请先阅读 什么是 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 的沙箱提供了 VM 风格的边界，而没有传统 VM 的全部开销：启动延迟设计得很快，设备模型最小化以减少攻击面，并且客户机与主机内核在设计上隔离。实际含义是，客户机中的内核漏洞不会自动影响主机或其他客户机，而在共享内核的容器模型中则可能影响。请参阅 用于 AI 代理沙箱的 Firecracker，了解 microVM 边界在哪些方面有帮助，以及在哪些方面不能解决全部问题。
每个代理、每个用户还是每个任务对应一个沙箱？
这取决于平台以及应用程序的设计方式。对于多租户应用，最安全的模式是每个代理运行或每个任务对应一个独立的沙箱环境——这意味着每个用户的会话拥有自己的进程树、文件系统、网络命名空间和凭证范围。跨用户或跨不相关任务共享沙箱是生产代理应用中最常见的状态泄漏来源。在评估平台时，请验证并发会话是否在文件系统、进程和网络级别上隔离，而不仅仅是在 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 代理沙箱定价模型：按会话、计算、存储和出站 了解每个定价维度的详细分解。
会话时间、计算和出站如何在成本中相互作用？
对于大多数工作负载，计算时间占主导地位。一个 10 分钟的使用 1 个 vCPU 的编码会话的成本高于典型费率下的 1 GB 出站流量。但这种相互作用对于特定工作负载很重要：下载大型训练数据集的数据代理将产生远远超过计算成本的出站费用。在 LLM 轮次之间保持会话打开的浏览器代理，如果未启用自动暂停，将累积空闲计算成本。实际的做法是在承诺使用某个平台之前，根据您的实际工作负载概况估算每个维度。Novita 代理沙箱根据实际 vCPU 和内存使用量按秒计费，没有按会话的启动费；截至 2026 年中，1 个 vCPU 的价格为 $0.0000098/秒。（来源：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 部署，这解决了最常见的企业数据驻留和网络隔离要求。在做出架构决策之前，请在 产品文档 中验证当前的合规认证和可用的配置选项。
