编程Agent收到“修复这个项目”的请求后，会安装依赖、修改文件、运行测试，甚至启动浏览器检查页面。模型只负责提出下一步动作，真正执行的是进程、文件系统和网络。于是三个问题必须回答：谁来运行代码，代码能访问哪些资源，下次继续任务时能恢复什么状态。Sandbox就是为这三个问题提供受约束的执行环境，并为复用、恢复和回收建立规则。

先分清三个层次

选型时最容易混淆的是：Agent与执行环境的关系、底层隔离机制、上层产品与管理平台。这三层各自独立，不能用一个“支持沙箱”的勾选项概括。

Sandbox as a tool：Agent控制循环运行在应用服务中，需要执行代码时通过API把命令交给沙箱，接收退出码和输出。Agent可以连续调用同一个沙箱，文件、后台服务和工作区跨多次工具调用保留，因此同样支持长任务和持久工作区。它适合已有Agent服务、只想增加隔离执行能力的应用。身份和权限检查可集中在执行服务中，但Agent产生的命令与参数仍需按不可信输入处理。

Agent in sandbox：把Agent程序、命令行工具和工作区一起放入沙箱。外部系统创建会话、传入任务，Agent在内部读取文件、调用工具、执行命令。它适合运行完整编程Agent、第三方Agent程序，或依赖本地进程与工具配置的工作流。Agent可以调用外部模型API，并不要求把模型权重放进沙箱；平台仍要在沙箱外保留管理接口、权限策略和凭证代理。

需要区分通用概念与具体项目。Kubernetes SIG Apps下的agent-sandbox提供Sandbox自定义资源与控制器，管理有状态的单实例工作负载，底层隔离通过RuntimeClass交给gVisor、Kata等运行时。它解决的是沙箱如何被创建、分配和管理，而不是隔离机制本身。

底层隔离：从系统调用路径看差异

同一段Python调用write()，不同运行时首先接住系统调用的组件不同：普通容器直接进入宿主Linux内核；gVisor先由用户态的Sentry应用内核处理，再按需使用受约束的宿主接口；microVM中普通系统调用由Guest内核处理，只有访问虚拟设备时才进入虚拟化I/O路径。microVM不会把每个write()都变成一次Firecracker管理API请求。

普通容器（runc为代表）：namespace划分进程、挂载和网络可见范围，cgroup管理资源，capabilities、seccomp限制权限和接口，应用仍使用宿主内核。它适合来源可控的内部任务、常规服务和开发环境，能沿用成熟镜像与调度流程。若平台要接收互不信任用户的任意代码，共享内核就是必须纳入评估的攻击面；单独设置CPU、内存限额解决不了内核隔离和业务越权。

gVisor：Sentry在用户态实现Linux系统调用接口，应用请求先由Sentry处理，并非原样转发给宿主。它减少了应用直接接触宿主内核接口的机会，同时带来接口兼容性和不同负载下的性能取舍。适合保留容器工作流、且应用依赖的系统调用、文件和网络行为都能通过验证的场景。不能笼统认为它一定比microVM快，或只是“多加了一层syscall过滤”。

Kata：把容器工作负载运行在轻量VM内并接入容器管理器。在Kubernetes中，VM隔离通常对应Pod Sandbox；同一Pod内多个容器可能共享一台VM和Guest内核，因此把两个租户放进同一个Pod不会自动获得两个独立VM边界。

Firecracker：运行在Linux/KVM上的VMM，提供精简虚拟设备模型和VM管理接口。独立Guest内核与硬件虚拟化构成执行边界，宿主上的VMM进程还需要降权、seccomp、jailer等约束。Kata可以使用不同VMM，Firecracker是可选后端；OpenSandbox的安全运行时指南提供了通过kata-fc RuntimeClass使用Kata+Firecracker的配置。采用前需确认发行版本的设备、存储和运行时支持，Firecracker的底层能力也不意味着上层API已暴露同样的快照与恢复功能。

按实际需求选择：来源可控的内部任务优先普通容器，重点收紧进程权限与挂载范围；执行不可信代码且希望保留容器工作流，评估gVisor并验证兼容性与开销；Kubernetes工作负载明确需要独立Guest内核，选Kata加合适VMM；自建microVM执行平台、需要控制启动恢复与实例管理，直接选Firecracker，同时承担镜像、网络、状态和控制面的实现责任。这些路径可以并存，但应由可信平台按任务策略分配运行时，需要VM隔离的任务不能因节点配置缺失悄悄回退到普通容器。

产品层：托管与自托管的取舍

底层运行时回答“代码如何隔离”，产品还要回答“如何创建环境、操作文件、暴露服务、限制外联、保存状态”。同样采用Firecracker的服务，使用体验和状态语义仍可能不同。

重要说明：以下托管产品的底层隔离实现与状态能力，主要来自社区资料及所引官方文档的转述，尚未经本审核独立核验。具体能力、限制和承诺请以对应官方文档为准。社区资料只能证明相关说法被表达过，不能替代官方确认。

据社区资料及所引官方文档称，托管产品的大致情况如下：E2B被描述为每个sandbox使用独立Firecracker microVM，适合需要暂停后恢复文件系统与内存状态的通用隔离执行环境；Vercel Sandbox被描述为基于Firecracker microVM，适合已使用Vercel、希望把命令、文件、网络和身份集成放进现有工作流的应用；Deno Sandbox被描述为基于Firecracker microVM，适合使用Deno Deploy或特别关注出站策略与凭证代理的场景；Modal Sandboxes被描述为使用gVisor，另有完整VM运行时（当前标为Beta），适合已有Modal计算流程、需要真实Linux内核功能时再评估VM路径；Daytona被描述为按Sandbox Class区分容器、Linux VM等，需要开发工作区、运行中状态分支或暂停恢复时重点评估VM类别；Cloudflare Sandbox SDK被描述为提供Container接口，所引社区资料称每个sandbox独立VM，但未明确VMM名称，适合已有Workers、Durable Objects和R2的应用。

需要强调：以上均为社区资料与所引官方文档的转述，不是本审核独立核验的官方承诺。托管产品中底层VMM通常由服务商选择，用户实际能控制的是实例类别、镜像、资源、网络策略和生命周期接口。即使两家都被社区资料描述为使用Firecracker，也要分别向官方确认实例最长运行时间、持久化范围、区域和恢复限制。

自托管方面，OpenSandbox提供沙箱创建、命令执行、文件操作等接口，适配Docker、Kubernetes等后端，适合需要自己部署、应用侧尽量复用同一套SDK的场景；真实隔离方式取决于后端和安全运行时配置。Kubernetes SIG Agent Sandbox的Sandbox、Template、Claim与WarmPool抽象更贴近已有Kubernetes、希望用声明式资源管理独立会话、持久存储和预热池的需求，底层运行时通过RuntimeClass配置。AIO Sandbox把浏览器、Shell、文件操作、MCP、VSCode等放进一个Docker容器，浏览器下载文件后Shell可直接读取同一工作区，适合需要完整Agent工作环境的场景，具体隔离边界由承载它的运行时决定。注意：工具装在哪里与Agent控制循环装在哪里是两个独立决定，AIO Sandbox不必然对应Agent in sandbox。

状态管理：四种能力保存的东西不同

假设Agent已装好依赖、启动开发服务器、内存里维护一个Python对象，暂停一小时后继续。不同保存方式能恢复的东西并不一样：文件系统快照/目录备份保存指定时刻的文件内容，恢复后进程通常需要重启；持久Volume跨实例生命周期保留数据，但能读到数据不等于恢复了进程、连接或对话上下文；内存检查点/VM状态快照保存运行中的内存和相关执行状态，必须配套处理磁盘一致性、恢复兼容性和外部连接；Fork从某个状态创建独立分支，要确认包含哪些状态，以及磁盘写入、身份和外部操作是否独立。

产品命名并不统一，以下描述同样来自社区资料与所引官方文档的转述，需以官方文档为准。据所引资料称，Deno的Snapshot是从Volume生成的只读镜像；Cloudflare的备份接口保存指定目录到R2；Vercel的持久沙箱文档描述了停止时保存、恢复时加载文件系统的过程。这些能力都不能仅凭名字推导为“内存里的Python对象还在”。据所引资料称，Daytona的容器类别在stop后保留文件系统但清空内存，VM类别提供保留内存的暂停恢复与分支能力；Modal分别提供文件系统和内存快照，其内存快照仍标为Alpha并有额外限制。

即使直接使用Firecracker，状态也需要平台协调：Firecracker生成Guest内存和VM状态文件，磁盘文件由调用方另行管理；恢复后网络连接不保证存活，原有vsock连接会断开。可恢复的VM状态、可恢复的应用状态和可恢复的业务流程，是三个需要衔接的层次。还有一个容易忽略的边界：快照覆盖不到整个外部世界。如果Agent在快照后创建了外部工单，恢复到旧状态不会撤销工单。重试仍需使用幂等键或查询已有结果，分支执行也要使用独立身份，避免两个分支重复产生同一业务副作用。

安全边界：凭证、授权与网络

Agent可能运行在独立microVM中，但如果平台把长期云密钥交给它，再允许任意外联，代码仍可利用这些合法通道访问外部资源。VM边界保护宿主，业务授权决定任务能对外做什么。

凭证管理上，一个具体设计是把凭证留在沙箱外：沙箱发起受限请求，外部代理核验任务身份、目标服务和操作，再注入凭证。据所引资料称，Deno Sandbox的秘密替换机制展示了这种路径：沙箱中看到占位符，访问获准目标时才由外部机制替换为真实秘密。该描述来自社区资料转述，具体机制请以官方文档为准。

业务授权上，允许访问某个域名仍不足以表达业务权限。任务获准访问代码托管服务，不代表它可以删除任意仓库。工具代理还应检查资源归属、动作和参数，并在任务取消或身份过期后拒绝新的操作。Firecracker自身也明确把网络流量过滤留给宿主层处理。

网络能力应拆开比较：执行API负责发命令，Ingress负责让外部访问沙箱里的服务，Egress策略负责控制沙箱向外连接。这三个方向的鉴权、端口和协议范围不同，一个“支持网络”的勾选项无法表达差异。

落地检查清单

以多用户编程助手为例：应用已有Agent服务，需要执行任意生成代码并保存每次会话的工作区。可以先采用sandbox as a tool，让每个会话获得独立执行环境，身份和业务授权由沙箱外服务负责。希望用托管服务，从E2B、Vercel、Deno等与现有应用栈匹配的产品中评估，但务必以官方文档核验其隔离实现与状态能力；要在自己的Kubernetes集群运行，可选OpenSandbox或Kubernetes SIG Agent Sandbox作为管理入口，再依据隔离要求配置运行时。Firecracker适合需要microVM边界且设备能力满足负载的方案：Kata+Firecracker保留容器管理接口，直接使用Firecracker则能更细地控制VM创建、恢复和宿主资源。两条路径都要验证从“请求创建”到“第一条有效命令完成”的延迟、完整实例内存成本，以及失败后的回收和恢复行为。需要运行第三方Agent程序或隔离Agent自身依赖时，改用Agent in sandbox，工作区是否持久、进程是否恢复、能否访问外部工具，继续由明确的接口和策略决定。

Agent的位置决定哪些进程进入隔离范围，运行时决定如何建立边界，平台决定环境如何被使用和管理。按这三个问题逐层选择，就能解释每个项目的价值，也能看清仍需自行实现和验证的部分。