Vercel Drives 正式 GA：为 Sandbox 带来持久化存储

Vercel 宣布 Drives 正式面向 Vercel Sandbox 全面可用，覆盖 Hobby、Pro 与 Enterprise 三个版本。这标志着 Vercel 在运行 AI Agent 与代码沙箱时，终于补上了「持久化存储」这块关键拼图。

Drives 解决了什么问题

此前 Sandbox 的典型痛点是：沙箱停止后，内部文件随之消失。每一次运行都要从零准备依赖、数据集或中间产物。Drives 的定位很明确——它是一块持久化存储，可作为目录挂载到 Sandbox 中，文件在沙箱停止后依然保留，后续运行或其他 Sandbox 只要挂载同一个 Drive 就能直接访问。

官方给出两类主要用法：其一是保存 Agent 的工作区或基于文件的记忆，让模型跨运行保留状态；其二是把数据集、模型权重、依赖和构建产物跨沙箱共享。这两点直指当前 AI Agent 落地时最常见的基础设施缺口。

代码为什么这么短

从官方示例看，挂载逻辑被压缩到极简：通过 @vercel/sandbox 中的 Drive.get({ name: 'base-drive' }) 获取 Drive，再在 Sandbox.create 时把它挂到 /data 目录即可。这里有意思的是 API 设计——持久化能力被收进 Sandbox 的 mounts 参数，而不是单独的存储 SDK，开发者无需学习新的存储抽象。

这种「挂载即用」的形态，与容器生态里熟悉的 Volume 挂载非常接近，迁移成本低。

Fork：并行 Worker 的隔离方案

Drives 还支持 Fork（分叉）：把一块 Drive 复制成独立的可写 Drive。Fork 会继承源 Drive 的数据、区域和最大容量，但此后各自存储自己的改动。

官方代码示例正是这个场景——从 base-drive 派生出 worker-0、worker-1 两个 Fork，分别挂载进独立 Sandbox，运行结束后再删除 Fork。这样多个并行 Worker 可以从同一份保存好的工作区出发，各自的修改互不影响，也不会污染原始 Drive。

对跑批量任务、并行评测或分布式 Agent 的团队来说，Fork 把「共享初始状态 + 隔离写入」这件事做成了两行 API。

**写时复制（Copy-on-Write）**是 Fork 机制背后的关键设计思路。在传统方案里，复制一块存储往往意味着完整拷贝所有数据，成本随数据量线性增长；而 CoW 让分叉出的 Drive 在初始阶段只保留一个指向源数据的轻量引用，只有当某个 Fork 真正修改文件时，才会把被改动的数据块单独复制出来。这意味着无论源 Drive 多大，Fork 的创建都接近瞬时完成，且多个 Worker 共享的只读部分不会重复占用空间。理解这一点有助于判断 Drives 的适用边界：Fork 适合“从同一份初始工作区出发、各自产生不同结果”的场景，而非需要在分叉后持续写入大量新数据的高写入负载。

对 AI Agent 基础设施意味着什么

Drives 的价值不止于「文件不丢」。它把 Agent 的记忆与工作区从易失的执行环境里抽离出来，变成一个可复用、可分叉的资源，这与当前 Agent 架构从「一次性调用」走向「长期运行」的趋势一致。

需要说明的是，以上分析基于官方发布信息与示例代码，实际性能表现、并发上限与跨区域行为仍需在真实负载中验证。Drives 文档已经公开，建议团队先在小规模并行 Worker 场景中试用，再决定是否作为核心存储层。

**Agent 记忆（Agent Memory）**通常被分为短期与长期两类。短期记忆是单次会话内的上下文，随会话结束而消失；长期记忆则需要在多次运行之间保留，常见实现包括向量数据库、外部键值存储，或直接落盘为文件。Drives 走的是“文件即记忆”的路线——Agent 把工作区、笔记、中间产物写成普通文件，下一次运行挂载同一 Drive 即可读取，无需引入额外的记忆服务。这对以代码操作为核心的编程 Agent 尤其自然，因为它们本就通过文件系统与外界交互。不过文件形态的记忆在检索效率、并发写入一致性上不如专用数据库，规模化场景下仍需评估。