Vercel Drives 发布：为 AI Agent 提供持久化存储

AI Agent 常常需要跨多次运行处理复杂任务，过程中可能切换到不同的工具、运行时或计算环境。问题在于：换环境之后，之前的工作文件怎么办？

Vercel 给出的答案是 Vercel Drives——一套让 Agent 文件独立于执行环境的持久化存储方案。目前该功能已在 Vercel Sandbox 上正式可用（GA）。

解决什么问题：Agent 的「搬家」困境

Agent 的工作往往不是一次性的。一个任务可能先在轻量环境中做数据预处理，再切换到配了 GPU 的环境跑模型，最后回到普通环境生成报告。如果每次换环境都要重新传输、重建工作区，效率损耗相当可观。

Vercel Drives 的思路很直接：把文件层从执行层剥离出来。Drive 是独立的持久化卷，Sandbox 只是挂载它。Agent 在新环境里挂载同一个 Drive，就能直接看到上一轮运行留下的所有文件——代码仓库、中间数据、生成结果，都在原地。

这个设计的关键在于解耦。文件不再绑定于某个 Sandbox 实例，而是作为一个可复用的资源存在。多个 Sandbox 可以同时挂载同一个 Drive，运行时切换也不需要做额外的数据迁移。

Vercel Sandbox 是 Vercel 提供的一次性隔离计算环境，用于安全运行不可信或短期代码。它在设计上是临时的：每次创建都会分配一个新的、干净的微虚拟机（microVM）实例，运行结束后即销毁。这种临时性是 Sandbox 的核心安全属性——它确保一个任务不会污染或影响下一个任务。但这也意味着 Sandbox 不保存任何运行状态。Drives 恰好填补了这块空白：把需要持久化的部分放到外挂在 Sandbox 之外的卷上，让临时环境与持久数据各司其职。

基本用法：创建、挂载、运行

使用流程分两步。先创建一个 Drive，然后在创建 Sandbox 时挂载它。

CLI 方式：

sandbox drives get-or-create agent-workspace
sandbox create --mount agent-workspace:/workspace

SDK 方式：

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

const drive = await Drive.getOrCreate({ name: 'agent-workspace' });
const sandbox = await Sandbox.create({
  mounts: { '/workspace': drive },
});
await sandbox.runCommand('git', ['clone', repoUrl, '/workspace/repo']);

挂载点下的内容——例子中是 /workspace——会持久保存在 Drive 上，其余部分属于 Sandbox 临时环境。下一个挂载该 Drive 的 Sandbox 会直接找到之前克隆的仓库和 Agent 写入的所有文件。

这种模式对需要多步骤、多环境协作的 Agent 工作流尤其友好。Agent 不需要关心底层换了什么运行时，工作区始终是一致的。

挂载（mount） 是把一个独立的持久化存储卷关联到某个文件系统路径上的操作。在 Vercel Drives 的场景里，--mount agent-workspace:/workspace 的含义就是：把名为 agent-workspace 的 Drive 挂载到 Sandbox 内部的 /workspace 目录。挂载点之下，所有读写操作实际上都落在 Drive 上；挂载点之外，则仍是 Sandbox 的本地临时存储。这实现了在同一文件系统树内，持久区与临时区的透明区隔——对 Agent 而言，只是读写普通文件路径，无需感知底层存储边界。

跨 Sandbox 共享与 Fork 机制

Drives 的能力不止于「接力」。它还支持多个 Sandbox 之间的状态共享和并行探索。

共享读取是其中一个典型场景。一个 Agent 在 Drive 上构建好数据集后，其他 Agent 可以挂载只读副本进行分析或生成报告，不需要重复构建。各自的结果保存在自己的空间里，互不干扰。

Fork 则面向需要并行试验的情况。Agent 可以 fork 一个 Drive，每个 fork 从原始内容出发，拥有独立的可写工作区。多个 Agent 可以同时尝试不同的数据变换方案，原始 Drive 不受影响，fork 之间也彼此隔离。需要注意的是，fork 不会合并回原始 Drive——这更像是一种「平行宇宙」式的探索机制，而非版本控制。

Fork 功能也已正式可用。

写时复制（copy-on-write） 是理解 Fork 机制的关键。Fork 一个 Drive 时，系统并不立即复制全部数据，而是让新 Drive 与原始 Drive 共享底层数据块，只有在某个 fork 实际写入某个数据块时，才把该块复制出来。这意味着 fork 操作接近 O(1) 成本，无论原始 Drive 有多大，都能瞬间完成。多个 fork 彼此隔离、又对原始数据有一致的只读视图，正是这种写时复制语义在存储层提供的保障。没有这一机制，并行探索不同数据变换方案的代价会随数据规模线性增长。

容量与可用性

Vercel Drives 面向 Vercel Sandbox 的所有套餐开放。默认容量为 1 TiB，Hobby 套餐为 1 GiB，最大可扩展至 16 TiB。配置方式、快照能力和具体限制可以查阅官方文档，GA 版本的变更细节在 changelog 中有完整记录。

Vercel 同时提供了一个 eve agent starter template，支持一键部署，方便开发者快速体验 Drives 与 Agent 的结合。

为什么这件事值得关注

Agent 基础设施正在从「能跑起来」走向「能持续跑下去」。持久化存储看似是一个底层能力，但它直接影响 Agent 能否处理长周期、多阶段的复杂任务。

Vercel 选择在 Sandbox 层面解决这个问题，而不是让开发者自己搭建文件同步逻辑，降低了构建可靠 Agent 系统的门槛。Fork 机制的加入也暗示了一个方向：未来 Agent 的并行协作和独立探索，可能需要存储层提供原生支持。

对于正在构建 Agent 应用的开发者来说，Drives 提供了一个值得评估的选项——尤其是在工作流涉及多环境切换或需要多个 Agent 协同处理同一份数据时。