Vercel Sandbox 扩容至 64 GB：大型 Agent 任务如何改单机运行

这次更新的价值，不只在“64 GB”这个数字。过去会撞上 Vercel Sandbox 32 GB 上限的仓库任务，现在有机会在一台机器内直接跑完，不必再删减内容、拆成多段，或迁往其他环境。

2026 年 9 月 11 日，Vercel 将每个 Sandbox 的默认工作存储从 32 GB 翻倍至 64 GB。

Vercel Sandbox 单机工作空间翻倍

Vercel Sandbox 是一台隔离的 Linux microVM，也就是拥有独立内核、文件系统和网络的小型虚拟机。你可以把代码仓库交给它，让 Agent 修改代码、安装依赖、运行测试、完成构建，再将结果取出。

这些环节共用同一块本地磁盘。依赖树开始写入时，检出的仓库还在；构建缓存、编译产物和临时文件也可能同时存在。最终产物也许很小，但生成过程中短暂需要的空间可能大得多。

这次发布改变的正是这个峰值。Vercel 现在为 Sandbox 提供 64 GB 工作存储，取代原来的 32 GB：增加 32 GB，容量正好翻倍。使用 Vercel Managed Image、自定义镜像，以及已弃用 runtime 属性创建的 Sandbox 都包含在内。

这部分空间是 Sandbox 内部的工作容量，并不是新增的数据库或对象存储配额。Vercel 将其称为临时 NVMe 存储。如果文件需要在任务结束后保留，持久化仍然是另一项独立决策。

真正要判断的是：一个任务能否完整装下

真正值得长期追问的，不是“Vercel 的磁盘上限是多少”，而是“整个任务能否在一个 Sandbox 内运行，无需特别清理或中途交接”。

可以先做一笔简单的工作空间预算：

峰值工作空间 = 仓库与检出内容 + 已安装依赖 + 构建产物 + 临时数据峰值

任务运行时应测量空间占用的最高点，不要根据最终 zip 文件的大小估算。软件包解压、编译、测试夹具、浏览器二进制文件、缓存和落盘数据可能只重叠几分钟，但任务能否完成，恰恰取决于这几分钟。

Vercel 的当前定价与配额把各类存储拆成了不同的预算项：

这个区别会改变成本计算。工作磁盘翻倍，并不意味着计算费率也翻倍。按照 Vercel 当前的 iad1 示例，一个使用 4 个 vCPU、8 GB 内存并以满 CPU 运行的 30 分钟构建与测试任务，费用约为 $0.34。

如果大型任务运行时间更长，或需要更多 CPU 和内存，费用仍可能上升。下载软件包、代码仓库、产物和数据集等内容免费，但从 Sandbox 向外发送数据需要付费。

真正可能因文件增多而新增存储账单的是持久化。假设一次运行用满并保留了新增的 32 GB 整整一个月，按价目表计算，每个快照月的费用为 32 × $0.08 = $2.56。这只是计算示例，并不代表费用会自动产生。非持久化任务只要导出结果并丢弃工作空间，就不会产生这项快照费用。

哪些人能真正用上这部分空间

维护大型 monorepo 的资深工程师

仓库、依赖图和构建输出无法同时装进原来的上限时，资深工程师可能不得不裁剪软件包、删除测试夹具，或把一次构建拆开执行。

如果实测峰值现在能装进可用的 64 GB 文件系统，团队就可以重新把检出、安装、测试和构建放回同一个任务。收益体现在运维层面：交接更少、半成品更少，构建失败时也只有一个重试点。

这并不代表 Vercel 会自动成为最合适的 Sandbox 提供商。如果仍在选择执行层，可以参考更全面的 AI Agent 代码沙箱对比，其中涵盖隔离与计费的取舍。这次发布改变的只有 Vercel 的磁盘边界。

运行仓库修复任务的 Agent 平台工程师

代码 Agent 工作时往往会不断占用更多存储。它会克隆仓库、安装工具、修改文件、运行测试套件，再打包结果。如果 Agent 尝试了几条不同路径，还可能留下缓存和中间输出。

新增的 32 GB 让整套流程更有机会在一个 Sandbox 内完成，也可能省掉一次磁盘已满后的重试，或从 Agent 工作流中移除专门的清理工具。前提是磁盘确实是原来的故障点；如果任务受限于内存、CPU、网络策略或会话时长，更大的文件系统不会带来帮助。

转换任务需要落盘的数据工程师

数据工程师在排序、连接或展开下载的数据时，可以把本地文件系统当作临时空间。磁盘增大后，这些临时工作更可能留在本地完成，不必提前拆分任务或挂载远程存储。

输出依然必须安排好去向：把需要保留的结果复制出去，写入合适的对象存储；如果后续运行还要使用同一目录，则挂载 Drive。64 GB 临时磁盘的价值，恰恰在于用完即可丢弃。把它当永久存储，会混淆两类任务，也会混淆两种账单。

仍在使用 runtime 的团队

9 月 11 日的发布说明明确指出，使用已弃用 runtime 属性配置的 Sandbox 也包含在此次更新中。现有代码无需迁移镜像，就应该能获得更大的磁盘。

不过，平台当前的发展方向仍然是镜像。从 Sandbox SDK 版本 3 开始，如果 Sandbox 既未指定 runtime，也未指定 image，就会使用 vercel/sandbox/universal:latest。托管镜像每晚更新；需要可复现构建时，固定 digest 可以获得不可变的环境。

调整工作流前，先测一个有代表性的任务

这次发布抬高了上限，却不会告诉你自己的镜像和任务究竟还有多少空间。在删除清理步骤，或把拆开的构建重新合并之前，先测一次真实运行。

1. 1

   选择一个足以验证决策的任务

   选择一个近期因磁盘耗尽而失败的任务，或者一个目前仅为避开旧上限才被拆分的任务。使用与生产路径相同的仓库、lockfile、构建命令和输入数据。演示用的小仓库回答不了这个业务问题。

2. 2

   启动一个全新的镜像型 Sandbox

   使用当前 CLI 和镜像路径，结果更容易复现。下面的命令遵循 Vercel 文档中的 Sandbox CLI 流程，并关闭持久化，避免这次测量自动创建快照。

   npm i -g sandbox
   sandbox login
   sandbox create --name workspace-check --image vercel/sandbox/node:24 --timeout 30m --non-persistent
   
   tar -czf app.tgz -C ./my-app .
   sandbox copy ./app.tgz workspace-check:/tmp/app.tgz
   sandbox exec workspace-check -- sh -c "mkdir -p /app && tar -xzf /tmp/app.tgz -C /app"

3. 3

   记录每个阶段的存储占用

   在检出完成后、依赖安装后、构建最繁重的阶段（如果能捕捉到），以及产物完成后分别检查磁盘。请把 .next 和 dist 换成项目实际使用的输出路径。

   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm install
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm run build
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'

   df -h / 显示 Sandbox 还剩多少空间，du 各行则说明工作空间的哪些部分正在消耗容量。如果只在最终构建结束后查看，就可能错过峰值。

4. 4

   去掉旧的绕行方案，重试一次

   如果测得的最高占用始终没有超过报告的可用空间，就去掉依赖裁剪或拆分构建的交接步骤，用同一个任务再试一次。记录是否成功、总耗时、Active CPU、已配置内存、传输量，以及是否创建了快照或 Drive 存储，随后停止 Sandbox。

   sandbox stop workspace-check

这次扩容解决不了什么

磁盘更大，不等于内存、CPU 或时间更多。Sandbox 会话的默认时长仍是 5 分钟。Hobby 会话最长可运行 45 分钟，Pro 和 Enterprise 会话最长可运行 24 小时。

这次发布也不能保证所有低于 64 GB 的工作负载都能顺利装下。启动镜像本身会占用一部分文件系统，而 Vercel 每晚发布更新时，滚动镜像标签也可能发生变化。启动后应检查实际可用空间；如果同一构建每次都必须从完全相同的环境开始，请固定镜像 digest。

如果任务需要持久、共享的数据，请使用 Drive 或其他持久化存储。如果任务所需工作空间超过 Sandbox 报告的容量，就继续拆分任务，把大型临时数据集移到挂载存储，或者换到其他环境运行。新上限改变的是临界点，并没有改变这些选项本身。

周一该做什么

如果真实的仓库、Agent 或数据任务曾撞上旧磁盘边界，或者仅为避开它而保留了清理代码，本周就值得行动。如果还没测过峰值，先别动：凭猜测取消一套有效的拆分方案，只会让下一次故障晚一点出现。若任务本来就远低于旧容量，或者真正瓶颈是 CPU、内存、网络访问、会话时长或持久化存储，则此次更新与你无关。

周一选一个有代表性的任务，在全新的 64 GB 镜像型 Sandbox 中按上文测量，再去掉旧的存储绕行方案重试一次。只有实测任务顺利完成，才保留更简单的单任务路径。

想继续看到这类用直白语言拆解、真正改变运营账本的更新，欢迎订阅邮件通讯。