Vercel 的智能体化轨迹：部署触发占比半年内从不到 3% 冲过半，v0 API 同期改造成基础设施入口

截至 2026 年 9 月，Vercel 平台超过一半的部署由编码智能体发起。同年 8 月，它又把 v0 应用构建智能体开放成可编程 API。更大的变化在于，智能体已不只在编辑器里补代码，它已经能触发构建、拿到预览、检查结果并调用部署。CIO/CTO 原来相信的“生产部署仍天然由人发起”需要修改，因为 Vercel 这个系统级入口的多数部署已由机器触发；但“发起部署”仍不等于“批准上线”，两层权力必须分开看。

主轴很清楚：Vercel 先把部署做成可编程、可回滚的确定性入口，再把构建工具、权限和运行环境改成智能体可调用的部件。部署占比的跃升，是这套架构被机器实际使用后的结果，不是一个孤立的 AI 功能数字。

超过 50% 改变了部署的默认发起方

部署数据先改变了对智能体工作边界的判断。

Vercel 在 4 月披露，之前三个月的平台周部署量翻倍，其中编码智能体带动了增长；当时超过 30% 的部署由智能体发起，比六个月前提高约十倍。Vercel 是提供网页应用构建、预览和部署服务的云平台。该页面后来补充，截至 9 月，这一比例已超过 50%。同一批数据还显示，由编码智能体部署的项目，调用 AI 推理服务的概率是人工部署项目的 20 倍。机器不只替人提交普通网页，它大量部署的本身也是 AI 应用和其他智能体。

这里存在一处必须保留的时间口径差异。RedMonk 在 9 月写成“1 月不到 3%，6 月过半”。Vercel 的一手页面给出的序列则是“约 2025 年 10 月不到 3%，2026 年 4 月超过 30%，9 月超过 50%”。两条序列都支持占比快速跨过半数，却不能混用月份计算增速。更稳妥的结论应收窄为：不到一年，智能体由边缘触发方变成了多数触发方。

这个比例也不能直接等同于“智能体自主决定了多数生产发布”。Vercel 把 Git 提交、CLI、Deploy Hook 和 REST API 都定义为创建部署的方法。每次部署都会生成一个独立 URL，其中既有 Preview，也有 Production。Preview 是供检查改动的预览部署，Production 是面向正式用户的生产部署。公开数据没有拆出环境、项目数、部署次数或重复重试，也没有说明如何识别“由智能体发起”。它证明的是部署入口的调用主体变了，尚不能证明人类已经退出合并、生产晋级或业务验收。

v0 把一次对话改造成可嵌入的交付链

产品时间线解释了为什么机器能成为多数触发方。

Vercel 早年的路线是让基础设施由应用代码推导：一次 Git 提交就自动构建，并给每个提交或拉取请求生成预览 URL。这个设计原本减少了开发者配置服务器的工作，如今也替智能体消除了网页控制台、手工 Terraform 和口头交接。Terraform 是用代码声明和管理云基础设施的工具。代码、构建和可访问 URL 之间已有稳定接口，模型只需调用它们。

2026 年 4 月，Vercel 把这条路线明确命名为面向智能体的基础设施，并列出 CLI、API、MCP 和 Git 集成。MCP 是让智能体以统一方式调用外部工具和数据的协议。编码智能体可以生成代码、开 PR、取得预览 URL、验证结果，再触发部署。PR 是提交代码改动并请求审查与合并的记录。6 月，Vercel 发布内部使用的 eve 框架，把持久执行、沙箱、人工批准、子智能体和评测装进同一套运行结构；公司随后披露，它在内部运行 100 多个智能体。其数据分析智能体 d0 已有 45% 的问题来自其他智能体，而非员工，说明机器调用机器并不限于外部部署流量。

8 月 5 日的新 v0 API 又把应用构建器从交互界面拆成了无界面服务。调用方发出提示后，v0 会在隔离工作区读写并运行文件，启动开发服务器，再返回可嵌入的预览 URL。脚本、CI、Webhook 或上层智能体可以继续修改同一个应用，并用一次 API 调用部署到 Vercel。v0 不再只是一位人类打开网页后使用的助手，它成了另一套产品或智能体可以编排的构建能力。

这条时间线支持“公司主动校准产品”这一判断，却不能证明 v0 API 导致部署占比过半。

• 占比在 4 月已经超过 30%，早于 8 月新版 API；
• Vercel 也没有公开 API 调用量或其中转化为生产部署的比例。

两者更像同一方向的供需信号：已有部署流量显示机器在使用入口，公司随后继续缩短机器从提示到运行应用的路径。

Netlify 与 Railway 同样打开机器入口，Vercel 多了一条采用率证据

同期比较表明，产品改造是平台行业的共同动作，过半占比仍是 Vercel 特有的公开证据。

三家公司都在减少账号创建、控制台点击和凭证搬运，但披露深度不同。

Netlify 把这种产品要求称为 Agent Experience，并用匿名部署解决智能体没有现成人类账号的问题。Railway 则把部署、日志、环境变量、回滚和分批发布做成智能体可调用工具。它们证明“为机器重写入口”并非 Vercel 的孤例，也说明直接对手已经看见同一个摩擦点。然而，没有同口径分母，就无法判断 Vercel 的过半来自整个行业的普遍迁移，还是来自其客户结构、Git 自动部署机制及 AI 原生项目占比。

Vercel 还多了一项关键证据：它已经公开观察到调用主体改变。对金融机构的平台团队，架构问题随之从“要不要给工程师配编码助手”变成“哪些部署入口会被机器高频调用，以及身份、预算、审计和回滚是否跟得上”。企业真正需要迁移的是变更控制的执行层，范围远大于一款 IDE 插件。

观察点：触发权已交给机器，放行权仍应单独计量

最强反证来自 Vercel 自己的权限设计。

Vercel Agent 在生产环境中以独立身份运行，默认只读；它可以自动调查日志、指标和部署，提出修复方案，但写代码、回滚或修改配置需要人批准一份权限计划。平台还允许设置 Deployment Checks，在生产构建完成后，只有安全检查通过才对终端用户发布。Vercel 的产品选择本身承认，高频机器执行与最终生产授权不是同一件事。

这并不推翻“智能体已成为多数部署触发方”，反而划清了企业采用的现实边界。机器适合反复创建隔离部署、运行测试、读取日志和修复失败，因为这些动作可回滚、可追踪，也能用策略限制；面向客户的流量切换、敏感配置变更和事故回滚，则需要独立身份、最小权限和明确批准。若把两层混成一个“自动部署率”，数字会夸大自主程度，也会掩盖控制面尚未完成的部分。

接下来应看三个可证伪指标。Vercel 是否按 Preview 与 Production 分拆触发比例，9 月后的占比是否稳定高于 50%，以及 v0 API 是否公布调用量与生产转化率。若过半主要由预览、失败重试或少数 AI 原生项目贡献，中心判断应收窄为“机器主导开发验证流量”。只有同类平台也披露接近的生产数据，而且人工批准率持续下降，部署入口的默认使用者才真正完成行业级更替。