Vercel Sandbox Drive 实战：让 AI 编程工作区跨沙箱持久化

Vercel Sandbox Drive 怎么用：先看结论

先用 Drive.getOrCreate() 创建一次 Drive，再通过 /data 这样的绝对路径把它传给 Sandbox.create()，并把所有需要长期保留的文件放在该路径下。另一个沙箱申请读写权限前，必须先停止第一个沙箱。需要并行测试或评审时，改为挂载 drive.snapshot()；这些读取方拿到的是冻结视图，之后的写入不会同步过去。

与其把 Drive 理解成某台机器里更大的硬盘，不如把它看成一间可拆卸的项目资料室。沙箱是临时进场的团队和工位；Drive 则是上锁的储物间，团队离开后仍然保留，还能接到下一间工位上。

Vercel 给 Drive 列出的典型用途包括代理工作区、磁盘记忆、依赖树、数据集、模型和构建产物。还有一位早期用户反馈，为每个代理配置独立 Drive 后，重新连接时可以跳过依赖重装。真正值得验证的收益是减少环境准备，而不只是增加存储空间。

搭建一个可持久化的工作区

先准备一个 Vercel 项目并在本地完成身份验证。Vercel 建议本地开发使用 OIDC token。vercel env pull 会把开发环境 token 写入 .env.local，该 token 会在 12 小时后过期。外部 CI 系统则可以使用团队 ID、项目 ID 和 access token。

发布时的稳定 npm 版本是 @vercel/sandbox 3.5.0。部分较旧的 Vercel SDK 文档仍写着私测，并建议使用 beta 渠道；但当前的 Drive 概念文档和九月 23 日发布公告明确说明，Drive 已面向上述三个套餐进入公测。

npm install @vercel/sandbox@3.5.0
npx vercel link
npx vercel env pull

下面创建一个 Drive，将其挂载后写入标记文件和一个小型缓存；随后停止该沙箱，再从新沙箱读取这两个文件：

import { Drive, Sandbox } from '@vercel/sandbox';

const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
  region: 'iad1',
});

const first = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

await first.runCommand('bash', [
  '-lc',
  "mkdir -p /data/.cache/demo && printf 'ready\\n' > /data/marker.txt && printf 'cached\\n' > /data/.cache/demo/package.txt",
]);
await first.stop();

const next = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

const check = await next.runCommand('bash', [
  '-lc',
  'cat /data/marker.txt /data/.cache/demo/package.txt',
]);
console.log(await check.stdout());
await next.stop();

persistent: false 让这个示例只聚焦 Drive。持久化沙箱有自己基于快照的恢复机制，而 Drive 是独立目录，可以在不同沙箱之间移动。若既需要可复用的基础环境，又需要单独演进的项目目录，也可以把两者组合使用。

上线前必须跑通的四项验证

顺利跑通基本流程，只能证明数据确实持久化。下面四项验证，才会告诉你多个任务同时访问同一工作区时，整个设计是否按预期运行。

1. 验证更换沙箱后工作区仍然存在

在 /data 下写入标记文件和缓存，停止写入方，然后用同一个 Drive 创建另一个沙箱，再从 /data 读取这些文件。第一个沙箱中其他路径下的文件，不能作为 Drive 持久化的证据。

为自己的任务记录四段耗时：首次创建沙箱、首次安装依赖、首次停止沙箱，以及创建新沙箱并复用缓存。真正有价值的指标，是第二次运行节省了多少准备时间。Drive 即使保住了文件，但如果没有缩短真实任务耗时，依然可能更方便，却并未改变计算预算。

2. 验证旧读取方始终停留在旧版本

先写入初始标记并停止写入方，然后通过 mounts: { '/data': workspace.snapshot() } 创建读取方，并让它持续运行。再在另一个沙箱中以读写方式挂载 Drive，替换标记并停止写入方。原有读取方仍应返回最初的标记，因为它在挂载时就固定了视图。要看到更新后的内容，需要新建一个快照读取方。

正确的心智模型是照片，而不是实时镜像。调用 snapshot() 定义的是只读挂载；读取方沙箱挂载时，时间点视图才会建立。另外，Drive 至少要先写入一次才能挂载快照。尚未写入的 Drive 会返回 drive_not_initialized。

3. 验证第二个写入方会被拒绝

保持一个读写沙箱运行，再尝试用同一个 Drive 创建另一个读写沙箱。Vercel 同一时间只允许一个读写挂载。不要把这个预期中的失败变成无休止重试。应在写入方前增加租约或队列，让当前占用方正常停止；需要定位挂载关系时，可使用 Drive.list() 或 currentSandboxName。

当前查阅的 Vercel 文档没有为第二写入方场景给出稳定错误码。应把沙箱创建失败本身视为接口约定，不要让生产逻辑依赖猜测出来的错误字符串。

4. 验证主区域一致

在 iad1 创建 Drive，然后尝试把它挂载到主区域为 sfo1 的沙箱。Vercel 文档将这种不匹配定义为 drive_region_mismatch。Drive 创建后不能更改区域；如果对同一个名称调用 getOrCreate()，却传入不同区域或最大容量，也会产生 conflict 错误。

即便 iad1 是默认值，也应在两个对象上明确设置区域。显式配置可以避免项目默认值日后变更，把一次普通重启变成区域错误。

完成一次性测试后，停止所有写入方和读取方，通过 Drive.list() 或 currentSandboxName 确认 Drive 已解除挂载，再调用 await workspace.delete()。删除会永久移除文件；只要仍有沙箱挂载，Vercel 就会拒绝删除。

账单由四类独立成本构成

Drive 存储不会替代沙箱计算费用，而是在已有计算计费项旁增加三项存储相关计费。在 iad1，当前公开费率如下：

不同区域的费率不一样。从互联网下载 npm 包和 Git 仓库等内容不收取下载流量费，但安装过程使用的 CPU 和预配内存仍会计费。这正是依赖缓存可能划算的原因：它减少的是重复准备工作，而不是下载流量。

下面是一个适用于 Pro 或 Enterprise 的规划示例，并非基准测试。把 10 GB 依赖树存满一个月，费用为 $0.50；在 100 次运行中完整读取它，相当于 1,000 GB 逻辑读取，费用为 $1.50；一次性写入 10 GB 则需 $0.04。仅 Drive 部分合计 $2.04，尚未计入计算、内存、传输或后续写入。

Vercel 自己的定价示例显示，在 iad1 以 100% CPU 利用率运行一项五分钟、2-vCPU、4 GB 的 AI 代码验证任务，费用约为 $0.03。不要假设 Drive 能省下全部金额。应测量它真正消除的安装阶段，再把节省的计算成本和人工等待时间，与 Drive 的存储、读取和写入账单比较。

Hobby 包含 15 GB Drive 存储，以及每月各 30 GB 的读取与写入额度。与此同时，单个 Hobby Drive 的默认上限是 1 GiB。Hobby 不收取超额费用：超过配额后，系统会暂停创建新沙箱。付费套餐若省略 maxSize，Drive 默认上限为 1 TiB，并且默认配额最高可配置到 16 TiB。

七类适用场景：按受益程度排序

1. 面向回访项目的 AI 编程代理产品

为每个代理工作区分配独立 Drive，把仓库、生成文件、任务笔记和包缓存都放在挂载路径下；下一轮任务再将其接入新沙箱。产品团队无需在每次沙箱生命周期结束后重建同一工作区，用户也不必为了延续上下文而让计算资源一直运行。

这是最有价值的场景，因为重启频率和重复准备会持续叠加。单写入者规则也很适合“每个工作区只有一个活跃代理”的模式，而预览和测试可以使用冻结读取方。

2. 反复安装同一套依赖的构建团队

由受控写入方填充一个 Drive，后续任务再以只读快照挂载依赖树。团队把反复安装的 CPU 成本和等待时间，换成一份存储副本及读取费用。当依赖体积较大、变更频率低于任务运行频率，并且缓存路径能与源码树隔离时，这种方案最划算。

3. 多代理评审流水线

让一个协调代理写入候选仓库，再把安全评审、测试、代码检查和文档检查分发到多个快照读取方。所有评审方都从相同状态开始，也无法修改共享源码。限制也很明确：如果某个评审方需要协调代理之后的修改，就必须用新快照重新创建。

4. 重复使用预处理数据集的数据团队

由一个写入方下载、规范化并索引数据集，再把快照挂载到短生命周期的分析沙箱中。高成本的准备工作只做一次，并发读取方则拿到一致的输入。它适合可重复的评估任务，却不适合所有读取方都希望就地实时更新的数据集。

5. 跨多个会话积累文件的研究代理

把引文、提取文本、中间表格和本地搜索索引保存在 Drive 上。新沙箱可以从这个目录继续工作，不必再次抓取并索引同一批来源。它的价值在于提供可复现的工作材料；风险则是没有独立备份或溯源系统，却把这些文件当作持久可信的数据。

6. 面向低频任务的模型或工具链缓存

预先把模型权重、编译器或其他大体积输入写入 Drive，只在任务到来时启动计算资源。首次缓存未命中时，Vercel 需要从持久存储取数，读取可能较慢；之后缓存命中的读取则以 NVMe 速度运行。当维持空闲计算资源的成本高于保存已用字节的存储费用时，这种模式更划算。

7. 支持学生项目续接的培训平台

为每个项目分配一个 Drive，每次学习会话挂载到新沙箱，结束后再解除挂载。学生的文件得以保留，平台则能释放计算资源。单写入者限制有助于避免两个活跃会话同时编辑同一项目，但产品仍需自行设计身份、备份和保留策略。

两款值得开发的产品

搜索量只能说明需求信号，不能预测收入。真正值得问的是：这项能力能否替一个已经在寻找解决方案的群体，消除足够棘手的工作。

首选：代理工作区租约协调服务

搭建一个小型控制平面，将每个代理或用户项目映射到一个 Drive，发放带时限的单写入者租约，为测试和预览创建冻结读取沙箱，并展示区域、挂载与删除状态。开发编程代理的团队会愿意为这层协调能力付费，因为底层存储原语不会替他们判断写入权限该归谁。

美国关键词数据显示，“ai powered coding agent”每月约有 8,100 次搜索，且带有商业意图。相邻市场已经接受平台型账单：E2B 的 Pro 套餐标价为每月 $150，另收用量费，多日持久会话则属于其定制 Enterprise 层级。这并非直接价格对比，但足以说明购买代理基础设施的团队具备可信预算。

最小可售版本需要包含 Drive 与工作区的映射、带过期机制的写入队列、快照读取方创建、用量视图和安全清理。难点在于壁垒：Vercel 或代理框架很容易吸收一个轻量封装。因此，产品必须提供运营策略、审计历史、恢复能力和供应商可移植性，而不只是给 getOrCreate() 换一个更好看的按钮。

面向云开发环境的热启动层

把仓库模板、Drive 支持的依赖路径、缓存预热器、显式区域策略，以及环境准备前后的遥测数据打包给平台团队。它卖的是现有 Vercel 技术栈中的冷启动缩短方案，而不是一套完整开发环境。

美国关键词数据显示，“cloud integrated development environment”每月约有 1,900 次搜索，CPC 为 $9.03。这样的付费搜索价值说明，各家厂商正在争夺这批受众。MVP 可以保持聚焦：先支持 Node 和 pnpm、单一区域、单一缓存策略，并用仪表盘分别展示存储、读取、写入、Active CPU 和内存。

问题仍然是边界。Drive 只提供一个持久化目录，并不包含 IDE、密钥管理、协作、镜像管理、备份或跨区域复制。如果产品只靠这一项原语就承诺完整云工作站，最终会让买家失望。

这些限制会直接影响架构设计

• 单写入者意味着单一所有者。 所有修改必须串行执行。快照读取方适合扇出任务，不适合协同编辑。
• 读取视图是冻结的。 正在运行的读取方永远看不到之后的写入；要获取新内容，需用新快照重新创建。
• 第一次快照前必须先写入。 启动读取沙箱之前，先初始化 Drive。
• 主区域必须一致。 Drive 固定在一个区域且无法迁移，区域应显式设置。
• 一个沙箱最多有四个挂载点。 每个路径都必须是绝对路径，挂载路径之间不能重叠。
• Drive 并不等于整台机器。 完整环境应使用沙箱快照；需要独立演进的目录才使用 Drive。
• 冷读取可能更慢。 缓存命中的读取和写入以 NVMe 速度运行，持久存储缓存未命中则不会。
• 删除不可恢复。 Vercel 将 drive.delete() 描述为永久删除。不要让 Drive 成为唯一备份。

目前文档之间还有一处冲突。九月 23 日的发布公告称，挂载 Drive 的沙箱不能使用故障转移区域；日期为九月 22 日的区域文档却称，故障转移可以跨区域加载 Drive，只是读取延迟会更高。在 Vercel 消除这组矛盾前，架构上应把 Drive 故障转移视为不受支持，并在真正依赖它之前重新测试。

如果任务只需要在单次运行中增加临时空间，Drive 并不是首选。请阅读配套指南：如何用 Vercel Sandbox 更大的临时磁盘处理大型代理任务，不要把持久化引入设计。

下周一就做这件事

下周选择一个频繁重启的代理工作流，只把项目文件和依赖缓存放到一个 Drive，坚持单写入者模式，并完成上面的四项验证。分别记录优化前后的准备时间，以及 Drive 存储、读取、写入、Active CPU 和内存。只有当更快的重启速度值得额外存储账单和协调规则时，再扩大使用范围。

如果你希望设计并监测一套可用于生产环境的持久化代理工作区，我可以帮助你构建 AI 生产系统。