Vercel 把 AI 沙箱启动从 40 秒砍到 1 秒内：会写代码的 Agent，终于不用先陪你读秒了
这两年大家聊 AI 编程，最爱盯着看的通常都是模型能力：
- 会不会写更多代码
- 会不会自己修 bug
- 会不会自动跑任务
- 会不会像个全能队友一样接活
但真把这些东西放进日常开发流程里，你很快就会发现一个很接地气的事实：
Agent 再聪明，只要环境起不来、状态接不上、恢复太慢，它就还是会把你的节奏拖成 PPT。
所以我看到 Vercel 这篇关于 Sandbox snapshots 的优化日志，反而觉得这类文章比很多“AI 又更强了”的发布更值得看。因为它讲的不是概念，而是一个所有做 AI 开发工具的人迟早都得面对的问题：
当 Agent 真开始频繁创建、暂停、恢复开发环境，启动速度本身就会变成产品体验的命门。
Vercel 这次到底做了什么
Vercel 说得很直接：他们先把 Sandbox 的文件系统快照功能做稳，确保不会丢数据、不会快照失败。结果稳定性解决后，新的痛点马上冒出来了——p75 的快照恢复时间超过 40 秒。
40 秒听起来不算天塌，但放到开发工作流里就很折磨。
因为这不是那种“第一次部署等一下也还行”的 40 秒，而是你在频繁创建、恢复、切换沙箱时不断重复遭遇的 40 秒。只要这种等待变成日常动作，用户对 Agent 的耐心就会迅速蒸发。
Vercel 这次主要做了三件事：
- 并行下载快照分片
- 并行解压快照内容
- 增加本地磁盘缓存，直接缓存解压后的镜像
结果也很硬：
- p75 从 40 秒降到 1 秒内
- p95 从 50 秒降到 5 秒
- 常用基础快照命中缓存后，恢复几乎只剩启动 microVM 和容器的时间
这不是“跑分好看一点”的级别，而是直接改变了工具有没有资格进入高频工作流。
真正的重点，不是压缩算法，而是 AI 工具开始补基础设施课
我觉得这篇最值得琢磨的，不是哪段代码怎么并行，而是它释放出的行业信号。
过去一阵子，很多 AI 编程产品都在拼前台能力：
- 谁的 agent 更会写
- 谁能跑更长的任务
- 谁能接更多工具
- 谁的 demo 更像“自动软件工程师”
但只要产品真的开始承载真实开发任务，底层基础设施迟早会跳出来打脸。
因为用户感知到的效率，从来不只取决于模型输出速度，还取决于：
- 环境多久能拉起来
- 上次任务的状态能不能接着用
- 文件系统能不能快速恢复
- 冷启动是不是每次都像重开一台新机器
说白了，AI 编程体验正在从“拼脑子”进入“拼肌肉和血管”的阶段。
模型像大脑，当然重要；但沙箱、缓存、状态恢复、执行环境这些东西，才是让大脑能不能顺畅干活的神经系统。
为什么快照恢复会变成关键瓶颈
如果你只是偶尔开一个云端环境，40 秒也许还能忍。
但 Agent 工作流不是这么运转的。现在很多 AI 开发工具都在往这个方向走：
- 给每个任务拉一个隔离环境
- 任务停下来以后保存现场
- 下次继续时恢复同一个文件系统状态
- 多个任务并行跑，再把结果交回主工作区
一旦工作流变成这样，快照恢复就不再是边角功能，而是主路径上的核心动作。
这时候，恢复慢的后果不是“用户多等一会儿”，而是整条链路都会开始不顺：
- 人不想频繁切任务
- Agent 不适合短平快试错
- 长任务也会因为恢复成本太高而变得笨重
- 所谓自动持久化，体验上却像半自动卡顿化
Vercel 这次提到 Automatic Persistence，意思也很明确：当你停止一个命名沙箱后，系统自动快照；恢复时再自动拉起。这个功能要想成立，前提不是“能恢复”，而是恢复得足够快，快到用户不会意识到自己刚经历了一次恢复。
这其实很像产品设计里的一个老道理：
真正好用的基础设施，最好别让用户明显感觉到它存在。
如果每次恢复都得让人看着转圈，那这个功能技术上成立，产品上也还是半残。
Vercel 这套优化为什么有效
从工程上看，这次优化并不神秘，但很扎实。
1）把顺序下载改成并行下载
原本是整份 .vhs 快照文件从 S3 单线程拉下来，等下载完再处理。快照动不动几百 MB 到几个 GB，这种串行流程天然就慢。
Vercel 改成用 range request 并行拉分片，本质上是把带宽吃满。官方给出的结果是下载速度提升 2 到 5 倍。
2）把顺序解压改成并行解压
下载完还不够，解压也曾经是单线程的。VHS 格式里有多个 frame，于是他们改成一个 decoder 加多个解压 goroutine。
这一步又带来 2 到 4 倍 的提速。
3）连中间盘都少落，直接流式解压
更狠的一步，是把 S3 的 range 请求流直接喂给解压流程，不再先完整落盘，再从中间文件继续处理。这样少了一层 I/O 和等待，又把整体恢复时间继续往下压。
4）终于把本地缓存补上了
最有喜感的一段，是 Vercel 自己承认：他们之前其实压根没做快路径缓存。
这就很真实。很多系统一开始都先保正确，性能债往后拖。等功能真的跑起来，才发现“每次都走冷路径”简直是在拿用户耐心做压力测试。
后来他们在本地 NVMe 上做 LRU 缓存，而且缓存的不是压缩包，而是已经解压好的 .img。这样缓存命中就能直接跳过下载和解压两个最贵的步骤。
他们提到大多数客户都会反复复用同一个基础快照，因此缓存命中率能到 95%。这就解释了为什么最终体验能从“明显等待”变成“几乎瞬间恢复”。
这对 AI 开发工具意味着什么
我觉得这件事真正值得开发者抄作业的，不只是并行下载这些细节，而是产品思路：
当 Agent 频繁参与执行时，‘状态恢复速度’会变成和‘模型响应速度’同等级的重要指标。
很多团队现在做 AI 工具时，还很容易把环境层当后台实现细节。其实不是。
对用户来说，他感受到的是一个完整闭环：
- 我发任务
- 环境起来
- Agent 接着上次状态干活
- 结果回来
只要其中一个环节慢得离谱，用户就不会觉得这是“系统架构问题”，只会直接给出一个更朴素的评价：
这玩意儿不顺手。
而“不顺手”在工具市场里，往往比“功能少一点”更致命。
这也提醒了所有做 Agent 的人：不要只顾着堆能力
现在不少 AI 产品有个共同毛病：前台能力疯狂扩张，后台耐力建设明显跟不上。
能做的事情越来越多，结果：
- 启动环境慢
- 上下文切换慢
- 任务恢复慢
- 失败重试成本高
- 一并行就更乱
最后就会出现一种很微妙的讽刺：
Agent 理论上替你省时间，实际上却在每次等待里把时间偷偷拿回去。
所以我很认同这类基础设施优化的价值。它不花哨，但它决定了 Agent 能不能从 demo 走向高频生产环境。
如果说上一阶段大家在证明“AI 能写代码”，那下一阶段更现实的问题就是：
AI 写代码之前，能不能先把工作台自己利索地站起来。
我的判断
Vercel 这次的信号很清楚：AI 编程工具的竞争，已经开始往底层体验下沉。
以后真正拉开差距的，不只是模型排行榜，不只是 agent 能不能 autonomous，更是这些更少被拿来做发布会 headline 的指标：
- 环境恢复要多快
- 状态迁移要多顺
- 缓存命中怎么做
- 冷启动怎么压
- 并行任务会不会把系统拖死
这些东西看起来没那么性感，但它们才决定用户会不会把 Agent 当成日常工具，而不是偶尔试玩的演示品。
Vercel 把沙箱恢复从 40 秒压到 1 秒内，表面上是在修性能，实际上是在回答一个更大的问题：
当 AI 开始接管越来越多开发动作，基础设施有没有资格跟上这种频率。
至少这次，他们给出的答案还挺像样。
因为会写代码的 Agent 当然重要。
但说到底，开发者更想要的，还是一个别让人站在原地陪它读秒的 Agent。