Vercel 给 agent 安了个家：Drives 管文件、Daemons 管后台活

一句话先说清

Vercel 在 2026 年 10 月 15 日的 Ship 大会上同时推出了两样东西：Drives 正式可用（GA），Daemons 进入公开测试（public beta）。一句话概括它们的关系：Drives 解决的是“agent 的文件去哪了”，Daemons 解决的是“agent 的活谁在后台接着干”。前者是给 agent 的持久工作区，后者是给 agent 后台任务的常驻工人。两样东西单独看都不算颠覆，但合在一起看，Vercel 想讲的故事就很清楚了——它不再只想当你的前端托管商，而是想当 agent 后端安家的地方。

Drives 到底是什么

先从一个所有用过 Vercel Sandbox 的人都会遇到的问题说起：沙箱是一次性的。你在沙箱里克隆了一个仓库、生成了一批数据、让 agent 跑了一下午，沙箱一停，这些文件就没了。下一次再开沙箱，一切从头来过。Drives 就是用来打破这个循环的：它把 agent 的文件从执行环境里剥离出来，变成一块可以独立存在的持久存储，沙箱只是临时挂载它、读写它，沙箱停了，文件还在。

官方给出的用法非常直观。命令行里先创建一块盘，再挂载创建沙箱：先用 get-or-create 拿到一块名叫 agent-workspace 的盘，再用 --mount 把它挂到沙箱的 /workspace 目录下。SDK 的写法也一样：先拿到 Drive 对象，再在创建 Sandbox 时把 /workspace 指向这块盘。关键规则只有一条：挂载点之下的东西会持久化，挂载点之外的东西仍然属于沙箱、随沙箱消失。下一个挂载同一块盘的沙箱，会在原地找到上一个沙箱留下的仓库和其他文件，不需要重新传输、重新克隆、重新生成。

这个规则听起来简单，但它改变的是 agent 工作流的默认假设。以前，agent 的每一次运行都是无状态的，状态要靠外部数据库、对象存储或者人工传文件来维持；现在，文件本身就可以是状态。agent 可以在不同的沙箱、不同的运行时、不同的算力配置之间换环境，而工作区保持不动。这对长任务尤其重要：第一阶段用一个环境做数据准备，第二阶段换一个环境做分析，第三阶段再换一个环境做验证，中间不需要把文件倒来倒去。

Drives 的三种用法：独占、共享、分叉

官方文档里 Drives 的用法可以归纳为三种，每种对应不同的协作模式。第一种是独占续跑：同一个 agent 在不同时间挂载同一块盘，接着上次的进度继续干。这是 Drives 最基础的用法，也是“持久工作区”这个名字的直接含义。第二种是只读共享：一个 agent 在盘上建好数据集，其他 agent 以只读方式挂载同一块盘，用这些文件做分析或生成报告，但把自己的结果写到别处，不污染原始数据。这种模式的好处是数据集只需要建一次，所有下游任务都可以复用，代价是只读挂载的 agent 不能顺手改掉上游数据——这既是限制，也是保护。

第三种是分叉（fork）：从一块盘分叉出一个独立的可写副本，每个分叉从原盘的内容出发，但之后的修改互不影响。官方明确说了：分叉不会合并回原盘。这个限制必须在设计工作流时就考虑进去——分叉适合“并行试几种做法、最后人工挑一个”的场景，不适合“多人同时改同一份数据、最后自动合并”的场景。如果你需要合并语义，Drives 不是你要的工具，你需要的是版本控制或者数据库事务。把分叉当成分支来用没问题，把分叉当成合并来用，一定会失望。

容量方面，官方给出的数字是：默认 1 TiB，Hobby 档 1 GiB，最高可到 16 TiB。对个人项目来说，1 GiB 的 Hobby 额度其实很容易被一个稍大的仓库加一批生成文件吃掉，所以 Hobby 用户要格外注意：不要把构建产物、缓存、模型权重一股脑写进挂载点，挂载点应该只放“值得持久化的工作成果”，而不是“所有中间文件”。

Daemons 到底是什么

如果说 Drives 是“文件住在哪”，Daemons 就是“活由谁在没人看的时候干”。Vercel 的函数（Functions）是请求驱动的：有请求才醒，没请求就睡。但很多后台任务根本没有请求可答——消费队列里的消息、跑定时批处理、监听数据库变更、作为自托管 CI Runner 去轮询任务。过去这些任务在 Vercel 上没有一个名正言顺的家，开发者要么自己搭一台常驻服务器，要么把任务拆成一次次函数调用来模拟常驻。Daemons 就是 Vercel 给这类任务的正式答案：一个长期运行的进程，从队列、数据库或第三方系统里拉取任务并执行，不需要 HTTP 服务器。

官方列出的适用场景很具体，值得逐条看。第一类是队列消费者：Vercel Queues 的轮询模式、Celery、BullMQ、RabbitMQ、Kafka，都是“等活上门”的模式。第二类是长时间轮询的工作器：Temporal 或 Cadence 的工作器，本身就是靠长轮询拿任务的。第三类是自托管 CI Runner：为 GitHub Actions、GitLab、CircleCI 轮询任务，不需要开放入站连接——这一点对企业内网场景尤其重要，因为很多公司的 CI Runner 不能、也不应该对外暴露端口。

实现上，Daemons 是跑在 Fluid 计算上的容器，和你的应用部署在同一个项目里。Vercel 负责构建镜像，并按你在每个区域配置的实例数维持运行，实例退出或崩溃时自动重启。配置方式是在项目根目录的配置文件里加一个 daemons 条目，指定工作目录、入口、命令和每个区域的实例数；连接信息放在生产环境变量里；部署到生产环境后，实例随即启动，输出出现在项目的日志里。CPU 和内存指标则需要 Observability Plus 才能看到——这是一个需要提前知道的成本细节：基础的日志免费看，细粒度的资源指标是付费档功能。

Drives + Daemons 合在一起意味着什么

单独看，Drives 和 Daemons 各自解决一个老问题；合在一起看，它们拼出的是“agent 后端”的完整拼图。想象一个典型的 agent 应用：用户发起一个长任务，Daemons 在后台接单并持续执行，执行过程中产生的文件写在 Drives 上；任务中途换环境、换运行时、甚至崩溃重启，文件都在盘上，不需要重做；多个并行 agent 可以只读共享同一份数据，也可以分叉出去各自探索，最后人工挑出最好的结果。这个链条里，Drives 是状态层，Daemons 是执行层，沙箱是临时的计算层，三层各司其职。

这里必须划清一个容易混淆的边界：Drives 不是之前报道过的 Vercel 开源项目 durable-harness。那是一个第三方开源包，解决的是 agent 执行器崩溃后“从断点续跑、不重复烧 token”的问题，属于执行器的容错机制；而 Drives 是 Vercel 平台的持久存储，属于基础设施。两者可以配合使用，但不是同一个东西，也不能互相替代。同样，Drives 也不是数据库：它存的是文件，不是带事务、索引和查询语言的结构化数据。需要事务语义的地方，仍然应该用数据库；需要“文件原样保留、换环境接着用”的地方，才是 Drives 的主场。

另一个边界是 Daemons 与 Vercel Workflows、Queues 的关系。Queues 负责“任务排队”，Workflows 负责“多步骤编排”，Daemons 负责“长期运行的执行者”。三者是互补的，不是竞争的：一个常见的组合是 Queues 收任务、Daemons 消费任务、Drives 保存任务产物。如果你已经在用 Workflows 做编排，Daemons 并不会取代它，而是给那些“无法被拆成有限步骤、必须一直跑着”的任务一个落脚点。

公开测试期的注意事项

Daemons 目前还是公开测试（public beta），这个身份自带三条注意事项。第一，公开测试期间的功能细节、定价和限制都可能变化，不要把生产核心链路的全部赌注都押在一个测试功能上，至少要留一条回退路径（比如可以切回自托管 Runner 的方案）。第二，根据第三方报道，当前测试版仅限生产部署，这意味着开发预览环境的行为可能与生产不一致，测试时要以生产部署为准。第三，Daemons 的输出目前只体现在项目日志里，细粒度的 CPU/内存指标需要付费的 Observability Plus——如果你的后台任务有资源预算，提前规划好这部分成本，不要等到任务把实例跑满了才发现看不到指标。

Drives 这边虽然是正式可用，但也有两个使用纪律值得提前立好。第一，挂载点的卫生：只把值得持久化的东西写进挂载点，构建缓存、临时文件、大模型权重一律不要进盘，否则 1 GiB 的 Hobby 额度会很快见底，而 1 TiB 的默认额度也会被无意义的中间文件蚕食。第二，分叉的纪律：分叉之前先想清楚“最后谁来挑结果、挑完怎么处理其他分叉”，因为分叉不会自动合并，没有这个决策，分叉越多，最后的人工整理成本越高。

判断：Vercel 在下一盘什么棋

把 Ship 2026 的其他发布放在一起看，Drives 和 Daemons 的位置就更清楚了：同一场大会上，Python 正式可用、容器运行时扩展、AI Gateway 增加预算与 Token Pass、企业版 BYOC 落地——所有这些发布的共同方向，都是让 Vercel 从“前端托管”走向“完整应用后端”。Drives 和 Daemons 是其中最贴近 agent 开发者的一环：它们回答的是“我的 agent 应用跑起来之后，文件放哪、后台任务谁来跑”这两个最实际的问题。

对 vibe 开发者来说，最务实的态度是分两步走。第一步，先用 Drives 解决一个你已经在痛的问题：比如让你的 agent 在多次运行之间不再重复克隆仓库、重复生成数据集，先把“持久工作区”这个收益拿到手。第二步，再评估 Daemons 是否值得引入：只有当你确实有“必须长期运行、无法拆成请求”的后台任务时，Daemons 才是答案；如果你的后台任务都能拆成队列 + 函数调用，那就没必要为了用新功能而用新功能。工具的价值不在于它有多新，而在于它是否正好卡在你工作流的缺口上——Drives 和 Daemons 各自卡住的缺口，都是真实存在的，但不是每个项目都有这两个缺口。

落地清单

想试 Drives：先建一块测试盘，挂载到沙箱里，验证“沙箱停了、文件还在”这个基本承诺；再试一次只读共享和一次分叉，确认分叉不合并的语义符合你的预期；最后检查挂载点里有没有不该持久化的缓存和构建产物。想试 Daemons：先从一个非关键的队列消费者或 CI Runner 开始，部署到生产环境验证实例维持与重启行为；确认日志是否满足你的排障需求，并评估 Observability Plus 是否必要；同时准备好回退方案，以防测试期的行为变化。两件事都做完，你对“agent 后端安家在 Vercel”这个命题，才会有一个基于自己项目的答案，而不是基于发布会演讲的答案。

三种不适合的场景：别为了用而用

Drives 不适合的第一种场景，是需要强事务和查询的数据。盘上存的是文件，没有数据库的事务、索引和查询语言。如果你的 agent 需要“找出所有状态为待处理、金额大于 100 的订单”，正确工具是数据库查询，而不是把几千个文件从盘上读出来自己过滤。把数据库该干的活交给文件系统，换来的只会是越来越慢的扫描和越来越难维护的临时脚本。判断标准很简单：你的数据需不需要“按条件查”？需要，就用数据库；只需要“原样取回”，才用盘。

不适合的第二种场景，是需要多人实时合并的协作。分叉不会合并回原盘，这句话的潜台词是：Vercel 不打算替你解决合并冲突。如果你和同事同时改同一份设计稿、同一份代码库，最后需要一份合并结果，Drives 给不了你这个能力，你需要的是 Git 这样的版本控制，或者带事务的数据库。分叉的正确用法是“并行探索、人工二选一”，而不是“并行编辑、自动合一”。在立项时就把这个决策写下来，比事后发现分叉合并不了再返工要便宜得多。

Daemons 不适合的场景，是可以被干净拆成请求和队列的任务。如果你的后台任务本身就是“收到一条消息、处理完、返回结果”，那么队列加函数的组合已经够用，引入一个长期运行的进程反而增加了运维面：实例数、重启策略、日志采集、资源指标，每一项都是成本。Daemons 的真正主场，是那些“无法被拆成有限步骤”的任务：需要一直轮询的 CI Runner、需要长连接的协议工作器、需要持续监听的流处理。只有当你发现“拆成函数调用”这个方案本身就在制造麻烦时，Daemons 才值得引入。

成本与容量：一张事先算好的账

Drives 的容量账要按“值得持久化的数据”来算，而不是按“所有数据”来算。一个典型的 agent 工作区里，真正值得持久化的往往只有三类：源代码仓库、agent 生成的数据集和分析结果、以及任务的中间产物里那些“重做成本很高”的部分。构建缓存、依赖安装目录、临时下载文件、大模型权重，这些都不应该进盘。Hobby 档 1 GiB 的额度听起来小，但如果只放上述三类，对很多个人项目来说是够用的；反过来，如果把什么都往盘里写，1 TiB 也一样会被吃光。容量管理的第一原则不是“盘够不够大”，而是“什么东西配进盘”。

Daemons 的成本账则要分三部分看：计算本身、日志与指标、以及回退方案的成本。计算部分取决于你配置的实例数和区域数，实例数乘以运行时间就是基本盘；日志部分目前包含在项目日志里，但细粒度的 CPU 和内存指标需要 Observability Plus，这是一笔需要单独评估的订阅成本；回退方案的成本最容易被忽略——如果测试期的 Daemons 行为发生变化，你需要一条能立刻切回自托管 Runner 的路径，这条路径的搭建和演练本身也是成本。把这三部分都写进预算，再决定 Daemons 是不是你的答案。

最后是一个组织层面的提醒：Drives 和 Daemons 都是“平台能力”，不是“业务功能”。它们的收益不会直接出现在用户面前，而是体现在开发效率、任务可靠性和运维成本上。这意味着立项时很难用“用户会不会喜欢”来论证，而应该用“我们现在为缺失这两个能力付出了多少隐性成本”来论证：每周重复克隆仓库花了多少时间？后台任务因为没有常驻工人而失败了多少次？把这些隐性成本量化出来，Drives 和 Daemons 的立项才会从“追新功能”变成“解决已知问题”。