Vercel CEO：Agent 正在跟模型解耦，生产环境已是多模型路由的天下

Rauch 的判断：Agent 不再绑死一个模型

7 月 6 日，Vercel CEO Guillermo Rauch 在接受 TechCrunch 采访时抛出了一个观点：Agent 正在跟底层模型解耦，未来的生产系统都会是"多模型路由"的形态。原话很直接——"当你为生产环境做优化的时候，你开始只看 price/performance"。

这不是一句情怀话。放在 2024 年，大家还在争"到底选 GPT-4 还是 Claude"；到了 2026 年年中，这个问题的答案已经变成"都要，还得会切"。Rauch 讲这话的底气来自 Vercel 5 月发布的 production index 报告：高流量团队在生产里平均跑 35 个以上 distinct models，agentic 请求已经占到 token 总流量的 59%（6 个月翻了一倍），而 AI Gateway 的 fallback 机制"救回来"约 3.5% 的请求。

3.5% 听起来不多，但换算成一个日调用量千万级的产品，就是三十多万次原本会失败的推理被兜住。这不是可选项，这是 SLA。

为什么"解耦"是必然的

把时间线拉回来看，Agent 早期基本是"一个 Agent = 一个模型"的绑定关系。LangChain、AutoGPT 那波产物，本质上是围绕 GPT-4 的能力边界写的 prompt 工程 + 工具调用胶水。模型换了，prompt 全得重写，function calling 的 schema 也得跟着改。

2026 年这套玩法已经不成立了，原因很朴素：

• 价格差距被拉大了。同一类任务，Haiku 类小模型和 Opus 类大模型的单 token 成本能差一到两个数量级。让 Opus 去做意图分类，纯烧钱。
• 能力分化开始明显。写代码看 Claude，长上下文检索看 Gemini，中文和数学看 DeepSeek 和 Qwen，多模态看 GPT。没有一个模型在所有维度都是最优解。
• 可用性问题真实存在。任何一家供应商都会挂，OpenAI 挂过、Anthropic 挂过、Google 挂过。生产环境不能把命交给单一 endpoint。
• 模型迭代速度太快。每两三个月就有新版本，绑死一个模型意味着你永远在追赶别人。

Rauch 说 "price/performance"，其实就是承认：模型这一层，正在快速商品化。Agent 的价值不在模型本身，而在于怎么编排、怎么调度、怎么在失败时优雅降级。

AI Gateway 的产品逻辑

Vercel 的 AI Gateway 就是冲着这个趋势去的。它的设计有几个点值得开发者注意：

不加价的透传。Gateway 不在 token 单价上抽成，按上游 list price 直接透传。这是聪明的定位——如果 Gateway 靠 token markup 赚钱，那客户迟早会绕开你直连；只有把价值锚定在路由逻辑上，才是可持续的。

路由决策而不是模型服务。Gateway 负责的是 fallback、retry、load balancing，不是自己训模型。这跟传统 CDN 的哲学是一样的——我不生产内容，我只是内容的搬运工。

统一 API 面向上百个模型。开发者写一次代码，切换模型只改一个参数。这个能力放在两年前是"锦上添花"，放在今天是"生死线"。

顺带一提，同类的做法 OpenAI Hub（openai-hub.com）也在做——一个 Key 调 GPT、Claude、Gemini、DeepSeek 全家桶，兼容 OpenAI 格式，国内直连。对于国内团队来说，网络层的稳定性甚至比路由算法本身还重要。

从 production index 数据看行业变化

再回到那份 production index 报告，几个数字值得展开：

平均 35 个 distinct models

这个数字第一眼看有点吓人。一个团队为什么需要 35 个模型？拆开来看合理：

• 主力模型 3-5 个：不同任务类型的默认选择
• 降级备胎 5-10 个：主力挂了之后按优先级 fallback
• 专项模型 10+ 个：embedding、rerank、图像、语音、代码补全，每个都是独立 endpoint
• 实验版本 5-10 个：A/B 测试、beta 版本、fine-tuned 私有模型

加起来 35 个不算多。这也解释了为什么"手动管理模型清单"这条路走不通——量级已经超出了 Excel 表格能维护的范畴。

Agentic 请求占 59%

这个数字比"35 个模型"更劲爆。半年前这个比例大概是 30%，现在已经过半。这意味着：

• 单次会话变长。传统 chat 是一问一答，agentic 是自主执行多步。
• token 消耗结构变了。工具调用的中间结果、思维链、self-reflection 都在烧 token。
• 失败成本变高。Agent 跑到第 8 步挂了，前 7 步的钱就白花了。这也是为什么 fallback 变得关键。

3.5% 的 fallback 救回率

这个数据反过来说，如果不做 fallback，你的 SLA 天花板就是 96.5%——这在任何 to B 场景里都是灾难。

Eve 框架：Agent 层的约定

除了 Gateway，Vercel 6 月中旬还开源了 Agent 框架 Eve，思路很清晰："一个文件夹就是一个 Agent"。这不是文字游戏，它是在告诉你：Agent 应该像 Next.js 的 pages 目录那样，有明确的约定，可以直接进入生产环境。

Eve 里有几个设计对得起"生产级"三个字：

• 默认沙箱隔离。模型生成的命令和代码被当作不可信输入，本地跑 Docker/microsandbox，部署到 Vercel 走 Vercel Sandbox，业务逻辑不用改。
• instructions.md 作为契约。默认一行示例，但你可以往里塞几百行行为准则。这跟 Cursor 的 rules、Claude 的 CLAUDE.md 是同一路思路——上下文即代码。
• 模型不绑定。Eve 本身不预设你用哪家模型，配合 AI Gateway 就能自然做到多模型路由。

把 Eve 和 AI Gateway 放在一起看，Vercel 的策略就很清楚了：在 Agent 层做标准（框架 + 约定），在模型层做抽象（网关 + 路由），两层解耦但配套使用。

Vercel Agent：Agent 也要有"运维"

还有一个容易被忽略的产品叫 Vercel Agent，定位是"Agent 的 SRE"。它自己会去看流量、追踪 trace、检查告警，发现问题主动分析并给出修复建议。

这背后的判断是：当 Agent 大规模进入生产，运维复杂度会指数级上升。传统 APM 工具是给人看的，Agent 系统的 trace 里全是模型输出、工具调用、状态转移，人肉排查的效率跟不上。所以要用 Agent 来管 Agent。

这一步 Vercel 走得挺快，也很符合它一贯的产品哲学——把"最佳实践"产品化，而不是留给用户自己拼。

开发者应该怎么调整

如果你现在正在做 Agent 相关的项目，Rauch 这套判断值得放进技术选型里：

1. 别把 Agent 代码和特定模型的 SDK 绑死。用 OpenAI 兼容格式做抽象层，任何时候都能切。
2. fallback 逻辑要写进主链路，不是异常处理。主模型 5xx、429、超时都得有明确的降级路径。
3. 模型选择做成配置化，最好按任务类型分层。分类任务用小模型，推理任务用大模型，别一把梭。
4. 观测数据要打全。每次调用记录：模型、latency、token 消耗、是否 fallback、最终结果质量。没有数据就没有优化。
5. 不要低估网络层。国内团队尤其如此，一个稳定的接入点比省几个点的价格重要得多。

一句话总结

Rauch 说的其实是一件正在发生的事，不是预言：模型层商品化，Agent 层标准化，中间靠路由粘合。谁能在这三层里把生产级细节做扎实，谁就能吃到下一波红利。

单模型时代结束了。