博客Vercel 平台 30% 部署已由 AI 编程工具发起，6 个月增长 1000%。当最后操作者从人变成机器，基础设施假设需要重写。本文拆解三层框架与企业落地路线。
Vercel 平台 2026 年 4 月公布了一组数据：平台上 30% 的部署由 AI 编程工具发起，6 个月前这个数字是 3%，增长 1000%。其中 Claude Code 占 75%，Lovable 和 v0 合占 6%，Cursor 仅 1.5%。更值得注意的细节是——这些自动化部署的项目调用 AI 推理的概率是人工部署项目的 20 倍。机器在写「会调用 AI 的软件」，在用代码构建更多的智能体。
这组数据来自 Vercel 官方博客，随后他们提出了一个新概念：Agentic Infrastructure。一个月的观察期后回头看，这个框架的核心不在于 Vercel 的产品矩阵，而在于它宣告了一个基础设施假设的失效——「最后操作者是人」这个前提，正在被改写。
过去五十年，基础设施设计有一条默认前提：最终操作者是人。有人去配置服务器，有人点部署按钮，有人看日志做排障。CI/CD 管道的终点是人做 approve，监控告警的接收方是人做响应，权限体系的边界是人做审计。
当 30% 的部署由机器发起、且这个比例在半年内翻了 10 倍时，这条前提已经开始崩塌。不是因为 AI 编程工具比人更聪明，而是因为它们的操作模式和故障特征跟人类开发者完全不同：
如果一个企业的 CI/CD 管道、预览环境、监控体系都假设「最后是人看一眼再上线」，那么当 30% 以上的流量绕过这个假设时，整个交付链条的可靠性就失去了基础。
Vercel 将这套新架构定义为三层演进。它的价值在于可以脱离任何单一厂商的产品做通用解读：
这是最直接的一层。当 AI 写完代码后，它需要把代码部署到某个地方做验证——预览环境、沙箱、临时数据库。这层的核心要求不是「功能多」，而是零摩擦：机器不需要学习你的内部部署流程，不需要申请权限，不需要等待审批。
具体来说，第一层需要具备：Git 原生的分支-预览映射（每个分支自动生成独立预览 URL）、沙箱化的运行时（可以安全地跑不信任代码）、以及可编程的部署接口（SDK 或 CLI，不是网页控制台）。
这一层是智能体本身的「生产线」——AI SDK、模型网关、推理算力调度、向量数据库、工具调用运行时。关键决策点不是选哪个框架，而是模型调用的治理边界画在哪里。
举例：当系统在一个任务循环里连续调用 GPT-5 50 次，其中 30 次是重复的相似错误重试，基础设施层能不能识别这种模式并介入——降级到便宜模型、缓存重复查询、直接熔断？第二层决定的不只是「能不能跑起来」，而是「跑起来的成本是否可控」。
这是最具前瞻性的一层：基础设施不再只是被操作的对象，而是自身成为自主系统——自主监控、根因分析、自动修复。当自动部署失败时，不是发告警等人来看，而是诊断模块自动抓日志、定位错误、回滚或重试。
Vercel 在这一层的布局包括 AI SDK 的 observability 能力和 Fluid Compute 的弹性调度。如果企业用的是自建基础设施，第三层的起点通常是：把现有的监控数据（Prometheus、OpenTelemetry、日志）接入一个可以自主查询和推理的诊断模块，让它先做好「诊断建议」这一步。
搞清楚了每层是什么，下一个问题是：你们团队在每一层覆盖了多少？缺口在哪？ 以下评估矩阵给出了每层的核心能力项和自建成本估算：
| 层级 | 核心能力项 | 自建估算 | 采购成熟度 | 建议 |
|---|---|---|---|---|
| 第一层：部署目标 | Git-预览自动映射、沙箱运行时、可编程部署 API | 2–3 人月（Kubernetes + Knative） | 高（Vercel/Netlify/Cloudflare） | 优先采购，自建 ROI 低 |
| 第二层：智能体运行时 | 模型网关、推理调度、工具运行时、成本熔断 | 4–8 人月（自研网关 + 调度） | 中（SDK 成熟，治理层分散） | 核心治理自建，推理走 API |
| 第三层：基础设施智能化 | 自主监控、根因分析、自动修复 | 6–12 人月（RAG + 诊断系统 + 运维知识库） | 低（各家都在早期） | 从诊断模块起步，不追求全自动 |
一个快速判断法则：如果你们团队在第二层的「模型调用治理」上还处于「开发者自己绑信用卡、月底财务拉账单」的阶段，那优先事项应该是先建一个统一的 AI Gateway——这是我们在多个交付项目里反复验证过的结论。关于更宏观的 AI 应用开发路径选择，可参考三条路径的选型决策框架。
以下来自优码云团队在交付过程中踩过的坑。这些内容只有在真实的「把 AI 编程工具接进企业 CI/CD 管道」时才会暴露。
一开始我们的流程是：AI 生成代码 → 自动创建 PR → 人工 review → 合并。跑了两周就撑不住了——工具一天能提 15–20 个 PR，每个 review 需要 20–30 分钟，一个高级工程师全天 review 也跟不上。
后来改成了分层 review 机制：第一层是自动化闸门（类型检查、lint、单元测试覆盖率 ≥ 80%、安全扫描），机器的 PR 必须全部通过才能进入人工 review。第二层才是人工，但人工只看架构决策和安全性，不再逐行读代码。效果：人工 review 量从每天 15+ 降到 3–5 个，缺陷逃逸率没有上升——因为大部分 AI 生成代码的低级错误（import 不存在的模块、参数类型不匹配）被自动化闸门拦住了。
关键参数：TypeScript strict mode + ESLint 推荐规则 + Jest coverage threshold 80%，三个闸门的误杀率约 5%，即 20 个 PR 里有 1 个被误拦需人工放行。这个成本可以接受。
AI 编程工具最自然的验证方式是把代码部署到预览环境，然后对着预览 URL 做功能验证。但在企业内网环境中，预览 URL 通常无法访问内部服务——私有 npm registry、内网 API、VPN 后的数据库。
我们的解决方案不是在工具侧加 VPN（安全团队不会同意），而是把预览环境部署到跟 staging 同一个 VPC 内，让预览实例可以访问内网服务。同时，对工具暴露的不是原始预览 URL，而是一个内网代理地址——它看到的 URL 是 https://preview-{slug}.internal.example.com，实际解析到 VPC 内的预览实例。
代价：维护一个内部 DNS 和反向代理层，约 1 人周初始配置 + 每月 2 小时维护。对于每天 50+ 次自动部署的团队，这个代价比每次人工介入低得多。
这是最容易被低估的坑。AI 编程工具的工作模式是「生成 → 测试 → 失败 → 重试」循环。一次前端组件生成任务中，工具可能在 15 分钟内调用 Claude API 30–40 次。如果它卡在某个边界条件上反复重试（比如响应式布局在特定断点下溢出，反复改 CSS 再测试），单次会话的 API 成本可能从预期的 $2–3 飙升到 $80–150。
我们一开始做了成本监控面板 + Slack 告警，以为「人看到就手动停」。实际告警发出时成本已经超了，因为机器的重试速度远快于人的响应速度。
最终方案是硬熔断：每个会话分配一个 token 预算（默认 $10），在 AI Gateway 层实时计数。消耗到 80% 时自动切换到便宜模型（如 Claude Haiku 替代 Claude Opus），消耗到 100% 时直接终止会话。这个机制上线后，单次异常会话的成本峰值从 $150 降到了 $12（刚好在 $10 预算 + 20% 溢出区间内）。
以下是按时间窗划分的具体动作，假设团队已经在使用 AI 编程工具且部署频率在上升：
说清楚「什么时候不该做」比说「什么时候该做」更重要。
如果你所在团队 AI 编程工具的部署占比低于 10%（即超过 90% 的部署仍是人手动触发），或者团队总人数不到 10 人，这套三层架构目前不是你的优先级。你现阶段更应该投入的是：
基础设施升级是自动化渗透率达到临界点后的自然需求，不是靠追概念追出来的。Vercel 之所以能在这个时间点提出这个方向，是因为他们平台上 AI 编程工具的部署占比已达 30% 且仍在快速增长。对于大多数企业来说，先用好工具，再谈工具需要什么样的基础设施——顺序不能反。
（关于如何评估 AI 智能体交付团队的质量，可参考我们的七个硬指标评估框架，里面给出了具体的面试追问问题和打分权重。）
不是。AI Agent 平台（如 Dify、Coze、LangGraph）解决的是「怎么构建和编排智能体」的问题——属于第二层的一部分。本文讨论的框架范围更大，包括部署目标层（第一层）、运行时治理层（第二层）、以及基础设施自身的智能化（第三层）。可以理解为：AI Agent 平台是第二层中的一个组件，不是全部。
MCP（Model Context Protocol）解决的是智能体与外部工具/数据源之间的标准化连接问题。在本文的三层框架里，MCP 处于第二层和第一层之间——它让系统能按统一协议访问不同的部署目标、数据库和 API。如果你的企业计划让多个系统跨平台协作，MCP 值得关注，但目前协议仍在快速迭代中。
不看团队规模，看自动化部署占比。如果你们 5 个人的团队每天由 AI 编程工具发起的部署超过 10 次，且人工 review 已成为瓶颈，就该考虑第一层和第二层的基础建设。反之，如果工具还没用起来，先推工具渗透率。
如果需求只是统一 API key 管理和基础限流，用现成的（如 LiteLLM、Portkey）足够。如果需要做 token 预算硬熔断、按项目/用户维度的成本归因、以及模型降级策略，建议自建——这部分逻辑和企业的成本控制策略强耦合，通用方案很难覆盖。