只跑被改动影响的任务：Vercel CI 进入 Beta，Agent 时代的 CI 开始按任务算账

一句话：CI 也要跟上 Agent 的出活速度

10 月 28 日，Vercel 宣布 Vercel CI 进入 Beta，所有套餐都可以用。它的核心主张只有一句：只跑被你这次改动真正影响到的任务，别的任务直接走缓存。一个改动只改了一行文案，就不该把整个仓库的测试、类型检查和 Lint 全跑一遍；一个 Agent 一天开了二十个拉取请求，也不该让第二十个请求排在十九个全量流水线后面等半天。

这个发布时间点不是偶然。Vercel 在官方博客里开门见山地写了判断：编码 Agent 正在开出比以往多得多的拉取请求，而每一个请求在能被审阅、能被合并之前都要先等 CI。也就是说，瓶颈已经从“写代码慢”变成了“等检查慢”。Vercel CI 就是冲着这个新瓶颈去的，它不是又一个通用 CI 厂商的翻版，而是一次把 CI 的触发单位从“整个工作流”改成“受影响的任务”的尝试。

先说结论：如果你已经在用 Turborepo，或者你的仓库本来就是单体仓库加多包结构，这次 Beta 值得立刻开一个分支试一试；如果你还在用手写 YAML 维护一套庞大的 CI 矩阵，Vercel CI 的吸引力在于它把配置收敛到一个你已经在维护的文件里；但如果你对构建缓存的正确性、Beta 阶段的稳定性有硬性要求，或者你的 CI 里有大量非 Turborepo 任务，那就先小范围试点，别急着把主分支的门禁整个换掉。下面把官方说法、实际用法和需要警惕的地方拆开讲。

官方到底发布了什么

根据 Vercel 官方博客《Introducing Vercel CI》，这次发布包含四个可以逐项核对的事实。第一，状态是 Beta，不是正式版（GA），但覆盖所有套餐，不只给付费大客户试用。第二，配置入口是 Turborepo 的 turbo.json，不需要再单独写一份 CI 工作流文件。第三，执行方式是“受影响的任务才跑，没变的任务走缓存”，每个要跑的任务跑在自己的机器上，依赖就绪就立刻启动。第四，观察入口有三个：Vercel 控制台、Vercel CLI 和 Vercel MCP，失败时可以直接定位到具体任务、查看被它阻塞的任务、打开日志，还能跨最近的运行记录搜索某个字符串，用来追踪一个时好时坏的测试。

官方给出的内部数据同样值得原样记录，不宜夸大也不宜忽略。Vercel 说，在它自己的仓库里，从 git push 到“CI 通过”的时间比以前快了 2 到 6 倍；Vercel CI 已经在它自己的仓库和私有 Beta 里累计完成了将近 800 万个任务。这两个数字都是 Vercel 自家环境下的结果，不是第三方实测，也不是对所有仓库的承诺。2 到 6 倍这个区间本身就说明了差异：任务之间依赖关系越稀疏、缓存命中率越高，加速越明显；反过来，如果每次改动都牵动全仓库的核心包，加速就会贴近区间下限。

正式版之前的路线图，官方也提前写清楚了三项：更强的可观测性、一个可以在推送代码之前就做分布式执行的 vc ci 命令、更细粒度的测试选择。换句话说，现在的 Beta 解决的是“跑得少、跑得快”，还没解决“在本地就能提前跑出和线上一样的结果”和“只跑受影响的单个测试用例”这两件更精细的事。评估时要按 Beta 的标准评估，别拿 GA 的想象去要求它。

用法其实只有一行：给任务打上 ci 标签

Vercel CI 的上手路径刻意做得很短。如果你已经在用 Turborepo，官方说法是不需要写单独的 CI 配置，只要在 turbo.json 里给想让 CI 跑的任务打上标签。官方博客给出的示例就是 lint 任务加一个标签，写法直观，改动量极小。如果你还没用 Turborepo，需要先加上 turbo.json 和 turbo 包，单包仓库也可以用，这一点官方明确写了，排除了“只有大型单体仓库才配用”的误解。

推送之后的发生顺序值得讲清楚，因为它决定了你排查问题时的思路。第一步，Vercel CI 根据改动判断哪些被打标签的任务需要跑；第二步，输入没有变化的任务直接从远程缓存（Remote Cache）取结果，默认就是开启的；第三步，剩下真正要跑的任务各自跑在独立的机器上，由 Vercel 的计算层 Hive 提供算力，依赖完成就启动，不必等整个批次排队；第四步，Vercel CI 会向 GitHub 拉取请求提交一个检查结果，你现有的分支保护规则可以像以前一样，凭这个结果拦截合并失败的请求。

日常排障的命令行入口也已经给了。vc ci ls 列出仓库的 CI 运行记录，vc ci inspect 加运行编号列出某次运行里的任务，vc ci logs 拉取某次运行的日志，还可以限定到某个任务和错误级别，例如只看 web 包测试任务的标准错误输出，vc ci grep 则可以在最近的运行日志里搜索一个字符串。这一套命令的真正价值不在语法本身，而在于它把“去控制台点来点去”和“让 Agent 自己去查 CI 为什么挂了”变成了同一条路：Agent 在终端里就能拿到结构化的失败信息，而不是把一整页日志粘贴回对话里再猜。

它和传统 CI 的根本区别：以任务为单位，而不是以工作流为单位

传统 CI 的默认逻辑是“一次推送，整套流程”。你在 YAML 里定义了若干个 job，推送触发后它们按依赖顺序跑，哪怕这次改动只动了一个文档文件，类型检查、单元测试、端到端测试也常常照跑不误。省时间的办法是手写路径过滤、手动拆 job、维护缓存键，这些配置会随着仓库变大而越来越像第二套构建系统，而且很容易和真实的任务依赖脱节。

Vercel CI 把判断依据换成了 Turborepo 本来就知道的东西：任务是什么、任务之间依赖谁、任务的输入变了没有。turbo.json 既是本地开发时跑任务的定义，也是 CI 时决定跑什么的定义，配置不再有两份，漂移的空间就小了。这也是 Vercel 敢说“没有工作流 YAML 需要维护”的底气：它不是把 YAML 藏起来了，而是把 CI 的决策外包给了你本地已经在用的任务图。

但这个设计也有一个硬边界：它只对 Turborepo 能理解的任务最有效。如果你的关键检查不在 turbo.json 里，例如一段部署前的自定义脚本、一个外部服务的安全扫描、一次需要特殊运行环境的集成测试，你仍然要想清楚这些任务由谁来跑、由谁来门禁。Vercel CI 不是要一次性吃掉你所有的 CI，它现阶段更像是在 Turborepo 任务这个子集上做到最快、最省。把这一点想清楚，试点范围就自然划出来了：先接管 lint、类型检查、单元测试这类标准任务，外部检查继续留在原有流水线里做补充门禁。

Agent 时代的 CI，拼的其实是反馈循环

为什么 Vercel 要在博客开头就强调 Agent？因为 Agent 改变了 CI 的负载形状。人类开发者一天推几次，每次推之前多少会在本地跑一遍；Agent 可以不知疲倦地推，推完就等 CI verdict 再决定下一步。一个 Agent 并行开十个任务，每个任务都要等 CI，CI 慢一分钟，Agent 的总等待就是十分钟量级的工作量被拖住。更麻烦的是，Agent 不会像人一样“感觉这次改动很小，应该很快”，它只会按 CI 结果行动，CI 越慢，Agent 的试错成本越高，整个开发循环就越像在排队等批复。

从这个角度看，“只跑受影响的任务”不只是一个省钱的技巧，而是一种让 CI 跟上 Agent 节奏的必要调整。远程缓存默认开启、每个任务独立机器、依赖就绪即启动，这三点合起来解决的是排队问题：没变的任务不占机器，要跑的任务不互相等，失败的任务可以单独定位。Vercel 把这套能力同时开放给控制台、CLI 和 MCP，也是同一个逻辑：人可以在界面上看，Agent 可以通过工具调用查，CI 结果不再是只给人看的网页，而是能进入 Agent 工作流的数据。

不过也要说一句冷静的话：CI 变快不会自动让 Agent 变好。Agent 仍然可能在 CI 通过之后提交逻辑错误的代码，仍然可能把测试写得只覆盖 happy path。CI 解决的是“多快知道结果”，不是“结果本身对不对”。把 CI 时间从二十分钟压到五分钟，省下来的是等待，不是思考；真正决定 Agent 产出质量的，仍然是任务拆分、测试设计和审阅标准。Vercel CI 值得试，但别把它当成 Agent 质量问题的万能药。

先试哪五步：一个保守又不浪费时间的试点方案

第一步，选一个已经在用 Turborepo 的仓库，最好是中等规模、任务依赖清晰的那一个，不要一上来就拿最核心、发布最频繁的仓库做试验。第二步，只给 lint 和类型检查这两个最标准、失败原因最容易定位的任务打上 ci 标签，跑一周，观察缓存命中情况和误报率。第三步，把单元测试接进来，同时保留原有 CI 作为对照，比较同一批拉取请求在两边的耗时和结果是否一致，重点看有没有“Vercel CI 通过了、老 CI 却挂了”的分歧，分歧就是缓存或任务划分有问题的信号。

第四步，让一个 Agent 任务真正走这条新链路：从 Agent 开分支、推送、等 CI、读 vc ci logs 定位失败、修复、再推送，完整跑通一次，确认 Agent 能独立读懂失败信息，而不是每次都要人去控制台翻译。第五步，再决定是否把分支保护规则里的必需检查切到 Vercel CI 的检查项上。切之前先确认一点：你的分支保护规则认不认 Vercel CI 提交的那个检查，认的话，失败拦截行为和以前是否完全一致。切门禁是最后一步，不是第一步。

试点期间建议记录四个数字：从推送到通过的中位时间、缓存命中率、失败定位平均耗时、以及“CI 通过但后续发现问题”的次数。前三个数字衡量它是不是真的更快、更好查，第四个数字衡量它是不是漏掉了本该拦住的问题。如果第四个数字上升，再快的 CI 也是负收益。

需要警惕的三件事

第一，缓存的正确性永远是这类产品的阿喀琉斯之踵。受影响分析依赖任务输入的定义是否完整：如果某个任务偷偷读了环境变量、读了仓库外的文件、依赖了某个没有声明的全局状态，缓存就可能把本该重跑的任务判定为“没变”。Turborepo 对此有输入声明机制，但机制再完善也抵不过一个不规范的任务定义。试点阶段遇到“本地能复现、CI 却通过”的怪事，先怀疑缓存和输入声明，别先怀疑代码。

第二，Beta 意味着行为和界面都可能变。官方路线图里提到的本地预执行和细粒度测试选择还没来，说明现在的产品形态还不是终态。把 Vercel CI 写进团队规范文档时，要写明“当前为 Beta，门禁切换需复核”，别写成永久承诺；同时关注它的 Changelog，后续 GA 时的计费、配额和行为变化都可能影响你的成本模型。

第三，平台绑定的问题要提前想好。Vercel CI 的任务图来自 Turborepo，这本身是开源工具，迁移成本相对低；但执行层 Hive、远程缓存、GitHub 检查集成、MCP 入口这些是 Vercel 平台的一部分。你的 CI 越依赖 Vercel 专属的观察和执行能力，未来要迁回通用 CI 就要多做一层适配。这不是反对使用它，而是提醒你在享受便利的同时，把任务定义保持在 turbo.json 这一层可移植的地方，别把关键逻辑写进只有 Vercel 才懂的角落。

给不同团队的采用建议：同一份发布，做法应该不一样

已经在用 Turborepo 的中大型团队，最划算的做法是把 Vercel CI 当作“现有任务图的加速器”来用，而不是当作一次 CI 迁移。你们的任务定义、依赖关系和缓存键本来就已经存在，接入成本主要是一次标签梳理：哪些任务值得进 CI、哪些任务只适合本地跑、哪些任务失败时必须拦截合并。梳理的过程本身就有价值，很多团队会在这一步发现早已没人维护的任务、重复跑两次的检查、以及本地和 CI 各跑一套的不一致。先把标签梳理干净，再谈加速数字，否则加速的可能是一套本来就臃肿的任务清单。

还没有用 Turborepo、但仓库已经是多包结构的小团队，要先算一笔账：引入 Turborepo 是为了解决本地开发的任务编排、缓存和并行问题，还是单纯为了试用 Vercel CI？如果是前者，Vercel CI 是顺带的红利，值得一起评估；如果只是后者，不妨先用现有的 CI 做一次“受影响分析”的手工模拟，例如给工作流加上路径过滤，看看能省多少时间，再决定要不要为一个 Beta 功能引入新的构建工具。工具链的每一次新增都有维护成本，Beta 功能的维护成本只会更高。

对独立开发者和小型副业项目来说，Vercel CI 的吸引力在另一个维度：你不需要再为一个小项目维护一套看起来很专业的 YAML。当 Agent 帮你一次开好几个分支、推好几个修复时，CI 能自动跳过没变的任务，意味着你不用再为“等 CI”而打断思路。但同样要提醒一句：小项目的 CI 失败原因往往更简单，Vercel CI 的排查工具再好，也替代不了你先看一眼失败任务本身的日志。工具链越自动化，越容易让人跳过“到底为什么失败”这一步，而这一步恰恰是小项目最不能省的。

对平台团队和 DevOps 负责人来说，评估重点应该放在治理层面：Vercel CI 的检查结果如何进入现有的合并门禁、审计日志和事故复盘流程？当一次发布出现问题，复盘时能不能完整还原“当时跑了哪些任务、哪些走了缓存、哪些被判定为不受影响”？如果这些问题的答案还不清楚，就不要急着把全组织的门禁都切过去。先让一两个团队跑通、把复盘模板补齐，再推广，推广的速度可以慢一点，但每一步都要可审计。

判断：值得试，但按 Beta 的方式试

Vercel CI 的价值主张是清晰且诚实的：它没有宣称要重写 CI 的全部，只是把“每次推送都全量跑”这个在 Agent 时代越来越贵的老默认，换成了“只跑受影响的任务”。2 到 6 倍的内部加速、将近 800 万个任务的 Beta 积累、一行标签的上手成本，这些数字和事实加在一起，足够让 Turborepo 用户认真对待这次发布。

但它的边界同样清晰：Beta、Turborepo 任务子集、缓存正确性依赖任务定义质量、GA 功能尚未齐全。对于已经在 Turborepo 生态里的团队，这是一次低成本的试验，值得用一个仓库、一周时间、四个数字去验证；对于还没有 Turborepo 的团队，先评估引入 Turborepo 本身的成本，再决定要不要为了 CI 而引入它，别为了追一个 Beta 功能而重构构建系统。

一句话收尾：CI 的竞赛已经从“谁的功能列表更长”变成了“谁能让 Agent 等得更少、错得更透明”。Vercel CI 在这个新赛道上交出了一份有具体机制、有内部数据、有明确待办事项的答卷，接下来该由每个团队用自己的仓库去验证这份答卷在自己手里能得几分。