夜雨聆风Views are my own.
这是 Stanford MS&E 435 系列的第八篇。前七篇沿价值链从底向上：芯片产能、推理工厂、能源与数据中心、企业端 Solow Paradox、递归自优化、后训练经济学、推理成本结构。
第七篇分析了推理基础设施的成本结构，这篇转向应用层的另一个价值捕获点：部署基础设施。讨论的核心问题是：
当写代码和部署代码的主体从人变成 Agent，基础设施的需求结构和竞争逻辑发生了什么变化？
第八课的嘉宾是 Guillermo Rauch，Vercel 创始人兼 CEO，Next.js 创造者。阿根廷长大，11 岁开始做远程 JavaScript 外包，高中辍学后移居旧金山创业。Vercel 当前估值 93 亿美元，ARR 3.4 亿美元，平台拥有 1700 万日活用户，日均处理 400 亿次请求、500 万次部署。其开源框架 Next.js 周下载量超过 3300 万次，是全球使用最广泛的 React 全栈框架。
Key Insights
一、软件形态演进——基础设施的消费者在变
Guillermo 一开始就讲了创立 Vercel 时的想法：全球大约有 2000 万 JavaScript 开发者能创建前端项目，如果给他们一个超级简单的部署工具，推代码就自动上线，自动扩容，永不宕机，这就是一个足够大的市场。
这个市场先后发生了两次大的变化。第一次是从个人开发者扩展到企业用户，像 Meta、Notion、Washington Post 这些公司把生产环境的 Web 应用跑在 Vercel 上，需要的不再只是“简单部署”，而是企业级的安全、合规、性能保障。第二次变化正在发生：消费者从人变成了 Agent。
编程这件事，本质就是一个不断降低准入门槛的过程。早年从大学里能接触大型机的少数人，到 coding bootcamp 三个月速成的开发者，再到今天任何人通过自然语言指挥 Agent 写代码。每一次变化背后都重新定义了“谁在使用基础设施”。
25 年 11 月 Anthropic 发布的 Claude Opus 4.5是这次变化的催化剂。在此之前，Coding Agent 的能力尚不足以可靠地完成“从零到部署”的全流程，而 Opus 4.5 跨过了这个门槛，成为一个转折点。
看一些数据。25 年 6 月，Vercel 平台上由 Agent 发起的部署（agent-led deployments）占总部署量的 5%；到 26 年 2 月，这个数字提升到了 21%，这意味着每五次部署就有一次是由 Agent 而不是人来发起的。
同一时期，Cursor 的 ARR 达到 20 亿美元，Anthropic 因为 Claude Code 的火爆 ARR 也迅速增长，全世界 Coding Agent 的使用量本身在爆发。而这些 Agent 在部署时的选择高度集中，一份 2026 年初的独立测试显示，Claude Code 在 86 次前端部署任务中全部选择了 Vercel。
上面这张图里的一系列数字再次证明了，写代码和部署代码的主体正迅速在从人变成 Agent。
二、需求结构变了——面向 Agent 的基础设施需要什么
传统云的设计过去都是围绕人类用户构建。Agent 的运行模式跟之前有非常大的差异：
差异1：响应模式从毫秒级请求-响应变成小时级流式生成。
传统云为“Request-Response”设计。比如之前 Amazon 经常提的一个案例是，页面加载每慢 100 毫秒，转化率降 1%。CDN、负载均衡、无状态函数等整个 Web 基础设施，都围绕“用户点一下，100 毫秒内返回结果”优化。
Agent 的时间尺度完全不同。随着各种 long-horizon task 越来越普遍，一开始是几秒钟，然后变成几分钟，然后变成几小时，甚至还有能跑一整天才输出结果。
像Lambda 的分钟级超时是为人类请求设计的，Agent 需要的是小时级的有状态执行环境。传统基础设施的计费模型、超时策略、状态管理全部围绕“短连接”的假设构建，而 Agent 的工作单元是小时，不是毫秒。
差异2： 分发层从静态资源缓存变成模型请求路由。
传统 CDN 做的事情就是把静态资源缓存到离用户最近的节点，减少延迟，核心逻辑是空间上的就近分发。
Vercel 的 AI Gateway 做的是语义层面的路由与调度，具体包括三件事：
语义缓存： 用户说一句“谢谢”，不需要激活 300 个 GPU，后台一个小模型就能回“不客气”。
故障切换：Claude 挂了切 Gemini，对用户透明。
成本路由：根据请求复杂度和开发者设定的预算约束，简单任务发便宜的小模型，复杂推理发贵的大模型。
格式路由：检测请求来源，人类浏览器返回 HTML，Agent 直接返回 Markdown。同一份内容，按消费者类型切换表示层。
差异3：计算单元从 EC2 变成 Sandbox。
EC2 的设计假设是：人写好代码，部署到一个长期运行的实例上。Sandbox 的设计假设完全不同：Agent 写代码，快速创建一个隔离环境执行，任务完成后销毁。
Guillermo 给了一个类比：公司给新员工的第一件事是发一台预装好软件的电脑，Sandbox 就是给 Agent 发的那台电脑。但这台电脑有安全问题，比如Agent 可能被钓鱼、被数据外泄、被 prompt injection。Vercel 正在围绕 Sandbox 构建一整套安全产品，Guillermo 预测“面向 Agent 的网络安全”会成为一个新的独立品类。
差异4： 容量天花板从人类程序员数量约束变为无上限。
传统云的算力需求被一个硬约束锁定，即全球程序员的数量。Agent 移除了这个约束。一个三个月前还不存在的 YC 公司，产品上线后部署量已经超出 Vercel 预设的流控上限。
三、价值分配变了——写代码便宜了，运行代码没有
“应用层”内部有两个价值捕获点：推理基础设施（模型与应用之间）和部署基础设施（应用与终端用户之间）。两者机制完全不同。
写代码的成本骤降，人力→token，且 token 成本仍以每年 10 倍速度下降，但运行代码的成本，如带宽、计算、全球分发等并没有同比下降，因此价值会从代码层转移到平台层。
Guillermo 提到一个案例，Vercel 内部两个人用 Agent 重建了 Salesforce 的界面层，不是取代数据库和工作流引擎，而是在其之上生成完全定制的展现层。传统 SaaS 为了通用性做的是“让最多客户满意”的标准化界面，而 Agent 可以为每个业务场景生成定制界面，且成本极低。
Is SaaS dead? 被消灭的可能只是标准化 UI 层，下面的底层系统记录仍然会长期存在——数据库、ACL、工作流引擎。前段时间 Salesforce 已经宣布把自己所有的服务都变成 headless 服务（MCP/CLI/API），这样就会锁定最核心的价值，而把价值锁在 UI 层的 SaaS 会被替代。
Guillermo 看空两类公司：drag and drop builders 和不提供程序化接口的 SaaS。他看多的是能被 Agent 即时消费的服务。而代码层已经商品化，平台层将开始更多地捕获价值。
四、选择机制——为什么是 Vercel
开发者选择云平台的决策路径大致是：品牌认知 → 销售接触 → POC 测试 → 采购审批 → 部署。这个路径里有大量人类特有的偏差——对品牌的信任、对切换成本的恐惧、对“code works on my machine”的安全感。
Agent 没有这些。Agent 选择基础设施的机制可以拆成三层。
第一层：训练数据中的代码模式密度。
LLM 的“世界模型”由预训练数据塑造的。Next.js 和 React 在 GitHub、Stack Overflow、技术博客中的代码密度极高，当用户让 Agent 创建一个 Web 应用，模型不需要“被说服”使用 Next.js，它训练数据里最密集的部署模式就长这样。
这就是 “code density for models”。Vercel 十年坚持做开源的决策，在人类开发者时代是“开发者关系”策略，在 Agent 时代变成了结构性竞争优势。
第二层：Local reasoning——可组合性作为 Agent 的硬约束。
LLM 的 context window 是稀缺资源。每迫使模型多读一个外部文件来理解当前组件的行为，就消耗一部分思考预算。Local reasoning 的本质是：把“理解这段代码”所需的全部信息压缩到模型已经能看到的 tokens 里。
举个例子。Tailwind 把样式内联到 HTML class，每个组件的视觉表现自包含、不依赖外部上下文。对人类这是审美问题——行太长，违反代码美学——但对 Agent 是生死线。React 的组件模型同理——props 进，JSX 出，边界清晰。Next.js 的文件路由同理——一个文件对应一个路由，不需要查阅全局路由配置。
整个技术栈的设计哲学是：让每一段代码在局部就能被完整理解。可组合性是 Agent 可扩展性的前提条件。
第三层：零摩擦部署——Agent 没有“留在本地”的偏差。
程序员有心理惯性：代码在本地跑通了就有安全感。Agent 没有这个偏差——给它一个零配置部署环境，它天然会去部署。Vercel 从第一天就消除部署摩擦：推代码，平台自动构建、部署。这个设计最初为了解放人类开发者，现在恰好是 Agent 的默认行为模式。
三层机制加起来，就是 HashiCorp 联合创始人 Mitchell Hashimoto 提出的“block economy”：想让 Agent 选择你的技术，你需要的不是更好的销售团队，而是更好的 building blocks——标准化的、自包含的、训练数据中密集存在的组件。
传统护城河靠切换成本和销售关系，Agent 时代的护城河靠你的技术在大模型“内生世界”中的位置。
这也解释了 Vercel 全新的获客模式：用户自己都不知道 Vercel 是什么，是 Agent 把他们带来的。有用户在 X 上给 Guillermo 发私信：“I don't even know what Vercel is. My agent took me here.”
域名是另一条入口——Agent 生成应用后用户想绑域名，DNS 配置引导他们到了 Vercel。早年押注让域名和 DNS 配置极简，这个决策在 Agent 时代获得了意外回报。
Vercel 不是被 commoditize 的应用层，而是让 commoditize 发生的平台层。
五、护城河是自强化的
Vercel 这个有利位置能持续多久？目前看领先优势在加速，而不是在缩小。
飞轮一：代码密度的正反馈。
Agent 用 Vercel 部署 → 产生更多基于 Next.js/React/shadcn 的代码 → 这些代码进入未来模型的训练数据 → 未来的 Agent 更可能默认选择 Vercel 的技术栈 → 更多部署。这是一个典型的数据网络效应，但发生在训练数据层面而非用户层面。
但飞轮有维护成本。训练数据是快照，不是实时流——产品迭代快于模型更新周期时，代码密度飞轮会放大过时信息。Vercel 内部已经遇到这个问题：模型至今仍会推荐已废弃数年的 Vercel Postgres，而非当前的 marketplace 方案。Vercel 的应对是 skills.sh——一套可被 Agent 在推理时按需加载的知识模块，本质上是对训练数据时滞的运行时补丁。飞轮越转越快，补丁机制就越不可或缺。
飞轮二：可靠性被编码进 Agent 选择偏好。
Agent 驱动的增长是突发的、无预警的、规模不可预测的。Vercel 在几个月内整体规模增长了三倍，日部署量自 1 月以来翻倍——几乎没有宕机。Sandbox 复用了十年积累的部署虚拟化原语，同一套基础设施既服务 Web 部署也服务 Agent 沙箱。
能承受需求冲击的平台，每一次冲击反而是一次机会，可靠性本身会被编码进 Agent 的选择偏好。反过来，一次宕机就可能让 Agent 永久切换到备选方案。
飞轮三：模块化复用带来的品类扩展速度。
Vercel 的全栈不是野心驱动的，是复用驱动的。AI Gateway 复用了 CDN 的全球网络和 Fluid Compute，Sandbox 复用了每次部署创建的虚拟化原语。十年积累的 Web 基础设施是火箭引擎，每个新品类只是换个喷嘴。边际成本极低，但每个新产品都在扩大 Agent 与平台的接触面。
逻辑与 AWS 从 EC2 扩展到 S3、RDS、Lambda 如出一辙。但区别在于，AWS 用了十五年，Vercel 在几个月内完成。
终局：Autonomous Cloud——基础设施自主运维。
Vercel 的最终愿景是：
Agent 不仅写代码、部署代码，还运维代码——自动配置、自动优化、自动提交 PR、自动测量转化提升。人未来只负责定义意图和验收结果，中间的全部环节由 Agent 和基础设施平台的闭环完成。
Vercel 内部更激进：平台本身正在变成 Agent——网站、Slack、Dashboard 里都嵌入了能代替用户执行操作的 Agent。不是“平台服务 Agent”，成了“平台即 Agent”。
这与第五篇建立的“递归自优化”框架一致：Agent 优化代码 → 代码运行得更好 → 产生更多数据 → Agent 基于数据进一步优化。
总结
Vercel 不是“赶上了 AI 浪潮”。Agent 形态的演进变化，让它十年前做的设计决策变成了结构性竞争优势：
开源优先带来训练数据中的代码密度，可组合性优先带来 Agent 可推理的技术栈，零摩擦部署带来 Agent 的默认行为路径。模块化架构让品类扩展的边际成本趋近于零，代码密度飞轮和可靠性飞轮让护城河不断加深。
谁能想到，花十年时间建造的一套设计哲学高度自洽的基础设施，突然就等到了 Agent 这个完美的消费者。
传统云的需求天花板是全球程序员的数量，面向 Agent 的基础设施没有这个天花板。天花板变了，所有基于旧天花板算出来的估值都得重算。
Enjoy!
