背景代理的良好沙箱要素

在构建和运营 @DevDeputies 的过程中，我评估了许多沙箱平台，并为其中几个实现了适配器。

对于 Deputies 而言，一个好的沙箱是一个可恢复的执行环境：它能够运行真实的仓库，暴露至少一个受控的入口路径，在暂停期间保留状态，并且能够可靠地重新连接。

ComputeSDK 基准测试是更广泛的参考，可用于比较沙箱平台。本文是更聚焦于 Deputies 的版本：在决定一个沙箱平台是否适合后台代理时，哪些因素最重要。

Deputies 所期望的形态

在代码层面，这些需求收敛成一个简洁的 Deputies 沙箱提供者适配器接口。适配器是 Deputies 对底层沙箱平台的封装。它需要能够创建、重连、健康检查和销毁沙箱。它返回的句柄需要包含工作区路径、命令执行、文件系统访问以及能力标志。

简化后的接口如下所示：

这个简洁的接口隐藏了大部分复杂性，但只有当底层沙箱具备以下属性时，它才能良好工作。

能运行真实工作负载

最重要的是，沙箱能够运行人们实际拥有的项目类型。

对于通用提供者，理想情况下应是一个真正的虚拟机。至少，它需要能够运行容器。一个有用的后台代理不应在遇到期望 Docker Compose、本地数据库、Playwright 浏览器或嵌套开发服务的仓库时就崩溃。对于 ML 或 GPU 密集型工作负载，支持 GPU 的沙箱也很重要。如果用户要求代理调试一个失败的集成测试或复现一个 ML 工作负载，沙箱应该能够运行与开发者在本地运行时相同类型的工作负载。

隔离也很重要，尽管 Deputies 通常部署在团队的可信环境中。标准容器对于这种部署模式可能已经足够，而基于 gVisor 或微虚拟机的隔离则提供了额外的纵深防御。

注意： 也存在例外。Deputies 中基于容器的 Docker 和 Kubernetes 提供者并非旨在成为通用的托管沙箱产品；它们为希望将代理执行路径置于自己已有基础设施内的团队解锁了特定的部署场景。

提供控制平面可达的入口

Deputies 控制平面需要一条网络路径通往沙箱内的进程。

技术上，这意味着控制平面能够向沙箱内监听的进程发起 HTTP 请求、WebSocket 升级以及长连接。私有网络路由是最理想的；提供者管理的公共 URL 在有认证的情况下也能工作。

预览环境曾是 Deputies 最受请求的功能之一，现在也是用得最多的功能之一。控制平面将流量从最终用户代理到沙箱中，用户获得一个 Deputies URL。

提供者无需直接暴露每个预览服务。一条通往沙箱入口点的受控路径就足够了，因为 Deputies 可以通过桥接进程（它在沙箱内运行的辅助程序）代理到代理启动的任何本地端口。

注意： 为每个预览服务提供直接的提供者 URL 听起来很方便，但这会使预览体验依赖于提供者。那些需要验证受信任主机、允许的来源、回调 URL 或 Cookie 域的应用程序，需要针对每个沙箱提供者的 URL 形态进行处理。通过 Deputies 代理预览，这些应用只需信任 Deputies 主机即可。

拥有利于代理的经济模式

成本很重要，但不仅仅是廉价的每小时虚拟机价格。

后台代理可能高强度运行几分钟，然后等待人工输入数小时，之后再恢复。当定价模式与之匹配时，提供者会更有吸引力：活跃计算可以停止，状态能够持久化，轻负载会话的计费不应与繁忙会话相同。

Sandbox Prices 在比较基准提供者定价时很有参考价值。举例说明，一个沙箱大小的计算环境如果持续运行满 24 小时的成本如下：

选项假设24小时成本DaytonaDaytona 定价列出 $0.0504/vCPU-hour + 0.0162/GiB-hour，按全时长计费~3.97EC2AWS EC2 按需定价，标准共享租赁 c7i.large，2 vCPU / 4 GiB~2.04HetznerHetzner Cloud 定价 CPX22，2 共享 vCPU / 4 GiB，€0.0320/hour~0.90自有裸金属~$2,000 服务器三年摊销，32 vCPU / 64 GiB，打包为十六个 2 vCPU / 4 GiB 沙箱，不含电力、网络和运维~每个沙箱 $0.11

具体数字会有变化，但权衡关系是稳定的。现代托管沙箱提供者成本更高，因为它们为你处理了更多的沙箱产品工作。原始计算可以更便宜，但你需要自己负责镜像准备、隔离、网络、状态保持、清理和容量管理。

100% 计算成本是一个有用的输入，但它并不能说明全部情况。后台代理会话通常包含较长的空闲期，此时代理正在等待人工审查、回复或给出下一步指令。

保留状态，停止计算

能够在保留文件系统状态的同时停止沙箱，是降低成本的主要杠杆之一。代理应该能够保持工作树、依赖缓存、生成的文件、日志以及其他有用的上下文，而无需在等待人工期间一直为活跃计算付费。

以 Daytona 列出的存储价格 $0.000108/GiB-hour 为例，即使对于一个包含 10 GiB 工作区状态的一天会话，差异也非常大：

计算活跃时长假设一天的大致成本100%2 vCPU / 4 GiB 计算 24h + 10 GiB 存储 24h~4.0025%2 vCPU / 4 GiB 计算活跃 6h + 10 GiB 存储 24h~1.0210%2 vCPU / 4 GiB 计算活跃 2.4h + 10 GiB 存储 24h~0.420%10 GiB 存储 24h~0.03

如果经济性不佳，产品就会被推向激进清理、短保留窗口或其他损害用户体验的策略。

此外，沙箱计算并不总是最大的开销项。对于许多代理工作负载，模型推理的成本可能超过代理运行的环境，因此沙箱定价需要作为每个有用会话总成本的一部分来评估。

运营稳定

这应该是基本要求，但值得明确指出：沙箱需要可靠。

它们应该可预测地启动，干净地重连，报告有用的健康状态，并在极少发生故障时足够明确，以便控制平面能够恢复。提供者还需要在请求沙箱时有真实的可用容量。如果会话随机消失、启动时挂起、因容量不可用而失败、丢失状态或无法清理，那么基于其上构建的每个产品功能都会变得不稳定。

对于 Deputies，这包括可预测的创建/连接/销毁行为、稳定的提供者 ID、能够区分启动中、已停止和丢失的健康状态，以及无需手动在提供者控制台点击操作的清理语义。

使用标准镜像/模板定义

环境定义应使用标准制品。

对于 Deputies，强烈偏好是 Dockerfile 或 OCI 镜像。这使 Deputies 能够像管理其他基础设施一样管理沙箱镜像，使用标准构建工具，并在不同提供者之间共享相同的基础环境。

这一偏好似乎也引起了许多评估沙箱的人的共鸣；截至本文撰写时，这条推文有 179 个赞和 2.15 万次查看：

Sid Palas@sidpalas·Jun 8
亲爱的沙箱提供者们，
请允许我通过 OCI 镜像/Dockerfile 来定义我的环境。
我不想使用你们自定义的 SDK 来定义我的镜像/模板。
此致，
所有人
259 179 21K

提供者不一定非要直接将该镜像作为容器运行。基于虚拟机的提供者可能会将镜像转换为其原生格式，或者在虚拟机内运行容器，同时使其感觉像宿主机环境。重要的是环境定义从标准制品开始。

提供者特定的模板并非自动不好，但每一种自定义模板语言、构建钩子和镜像格式都会成为需要维护的一件额外事务。当设置路径看起来像团队已经理解的容器工作流时，沙箱提供者会更具吸引力。

启动足够快

快速启动并非最基础的要求，但它对感知质量有巨大的影响。

即使工作将持续几分钟，等待沙箱本身出现的时间超过大约五秒就会让人感觉糟糕。这个阈值是主观的，有些人可能会合理地说五秒已经太慢。对于 Deputies，关键是产品应在几秒内显示可见的进度，这样用户就可以在代理继续工作的同时继续前进。

超过那个点，产品就需要采用缓解策略，如温池、预创建环境或提供者特定的缓存。

这些策略可以奏效，Deputies 最终可能会为某些提供者实现它们，但最佳版本仍然简单：创建沙箱，快速获得可用环境，让代理开始做有用的事情。

有用，而非必需

以下是提供者的有用特性，但不是 Deputies 支持的必要条件。

• 原生执行和文件系统 API。 在好的时候很有用，尤其对于简单的集成。并非必需，因为 Deputies 可以在沙箱内运行其桥接进程。

• 提供者管理的自动停止和保活。 作为防止孤立资源的额外保护层很有用。Deputies 自行管理生命周期策略，但提供者端的空闲定时器是一个有用的后备措施。

• 内置预览认证。 存在时很好。并非强制，因为 Deputies 可以在预览流量前加上自己的认证层。

• 流式日志。 在运维上有用，但代理命令输出已经通过运行器传递，因此这不是 Deputies 首先优化的方面。

结论

没有一个通用的“最佳”沙箱提供者。

正确的答案取决于工作负载、信任边界、预期的会话生命周期以及产品希望拥有多少基础设施。一个具有出色人体工程学的托管提供者可能是某个部署的正确选择。一个基于容器的提供者运行在团队自己的 Kubernetes 集群内，可能是另一个部署的正确选择。如果成本节省证明了额外运维面的合理性，那么更便宜的原始计算选项也可能有意义。

这就是为什么 Deputies 将沙箱提供者视为一个接口，而不是押注于单个运行时。关键在于保持产品期望稳定，同时允许执行后端随着权衡变化而改变。