Vercel CI 上线：让代码代理的 PR 等待时间缩短 2-6 倍

从“全量流水线”到“按需计算”：Vercel CI 的核心机制

我见过不少团队被 CI 拖垮。一个编码代理在一小时内推了七八个 PR，每个 PR 都在 CI 队列里排队，谁都在等那个绿色的勾。Vercel 在 2026 年 2 月 3 日发布的 Vercel CI Beta 想解决的就是这个。官方博客说得直白：旧 CI 每次 push 都跑完整工作流，哪怕只是改了一行字 来源：Vercel 官方博客。新方案只跑受代码变更影响的任务，计算资源按需启动，跟 Fluid Compute 随流量伸缩的方式一脉相承 来源：Vercel 官方博客。

核心依赖是 Turborepo。Vercel CI 读 turbo.json 来理解任务和依赖关系，如果你已经在用 Turborepo，不用写额外的 CI 配置 来源：Vercel 官方博客。配置很简单，在 turbo.json 里给任务加个 "tags": ["ci"]，比如 {"tasks":{"lint":{"tags":["ci"]}}}，Vercel CI 就会接管这个任务 来源：Vercel 官方博客。没上 Turborepo 的项目，官方说加个 turbo.json 和 turbo 包就行，单包仓库同样适用 来源：Vercel 官方博客。

推代码之后，系统根据变更内容动态决定哪些任务要跑。输入没变的任务从 Remote Cache 直接读结果，剩下每个任务在独立机器上跑，依赖完成就开始 来源：Vercel 官方博客。官方强调不需要维护 workflow YAML，避免 CI 配置和 turbo.json 之间产生漂移，Remote Cache 默认开 来源：Vercel 官方博客。我理解这一步是把 Turborepo 的依赖图从构建工具变成 CI 调度的基础，任务级增量执行不再是单纯靠 Git 变更检测。

量化收益与反直觉发现：代理频繁推代码反而加速了等待

Vercel 内部实践数据说，git push 到 CI passed 的时间比之前快 2 到 6 倍 来源：Vercel 官方博客。这个数字我没法独立核实，只能注明是官方口径。但收益背后的逻辑说得通：编码代理开的 PR 比以往多得多，传统 CI 每次 push 都跑全量工作流，一行改动也逃不掉，所以代理推得越频繁，等待越长 来源：Vercel 官方博客。

反直觉的地方在这。代理频繁推代码，传统 CI 等待时间线性增长；Vercel CI 因为只跑受影响任务，等待时间反而随代理活动增加而缩短 来源：Vercel 官方博客。这解释了他们为什么敢说 CI 现在“与我们的编码代理保持同步” 来源：Vercel 官方博客。内部已经把这套系统当成代理工作流的支撑，不是锦上添花。

我的判断是，这个收益的核心在于把计算粒度从“整个仓库”降到“单个任务”。代理推代码的频率再高，多数任务输入没变，从缓存取结果。等 CI 的时间被压缩了，代理的循环才能转得更快。这可能是 Vercel 把 CI 和代理产品绑在一起的原因，CI 加速直接服务代理产生的海量 PR 来源：Vercel 官方博客。

多源交叉验证：与主流 CI 方案及 Vercel 既有产品的对比

Vercel CI 的增量任务执行和 Fluid Compute 的按需伸缩理念一致，共享“只计算所需”的原则 来源：Vercel 官方博客。跟 GitHub Actions 这类传统 CI 比，Vercel CI 不用 workflow YAML，靠 turbo.json 的 tags 声明任务，减少配置漂移 来源：Vercel 官方博客。这个差异我认同，YAML 文件和构建配置分开维护，改一处漏一处的情况太常见了。

Remote Cache 默认开启意味着首次构建后结果可复用，和 Turborepo 已有的远程缓存机制兼容，没有重新造轮子 来源：Vercel 官方博客。Vercel 此前已有 Vercel Agent 与 AI SDK 等代理相关产品，CI 加速直接服务于这些代理产生的 PR 来源：Vercel 官方博客。

但我得说点冷水。公告发到 Hacker News 后 1 小时，只有 1 个积分、0 条评论 来源：HN。没有第三方独立验证数据，社区还在观望。官方博客说得再好，等真实项目跑过几个月再说。我不确定 2 到 6 倍这个数字在不同规模仓库里能复现多少，目前只能信一半。

原文：

Vercel CI · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月29日