Vercel CEO Guillermo Rauch 论模型与智能体分离的战役

Vercel CEO Guillermo Rauch在最近的采访中提出,模型和智能体需要解耦。这对亚洲开发者特别重要,因为亚洲的模型生态多元化,成本敏感,延迟考量也不同。

Share
Editorial illustration: A chess board mid-game with two distinct pieces separated to opposite sides—one piece isolated on an — MonstarX

Vercel CEO Guillermo Rauch 论模型与智能体分离的战役

每天600万次部署。其中一半由编码智能体触发。每24小时有1万亿个token流经Vercel的基础设施。当Guillermo Rauch谈论生产环境中的AI时,他不是在理论化——他是在读取实时遥测数据。在Vercel ShipNYC大会后的最近一次TechCrunch采访中,Rauch提出了一个尖锐的论点,触及AI基础设施发展方向的核心:模型和智能体需要解耦,最先理解这一点的开发者将构建真正能在生产环境中存活的系统。

这场对话的影响远超Vercel自身的路线图。对于亚洲的开发者——快速交付、紧密关注成本,并日益为不同于硅谷节奏的市场构建AI原生产品——Rauch的框架为当下的智能体架构思考提供了实用的视角。

发生了什么

"Vercel CEO Guillermo Rauch论模型与智能体分离的战役"不仅仅是一个吸引眼球的标题。它描述了一个真实的架构张力,Rauch表示,一旦Vercel超越原型阶段并开始在自己的组织内大规模运行智能体,这种张力就变得显而易见。

根据TechCrunch采访,去年是关于原型设计的——"释放智能体,每个人都可以构建"。Vercel在整个公司范围内有机地部署了数百个智能体并快速学习。艰难的教训来自于这些智能体进入生产环境时。Rauch的核心洞察是:当你为生产环境优化时,你立即开始关注性价比。这迫使大多数团队在原型阶段跳过的一个问题——模型和智能体逻辑真的应该捆绑在一起吗?

将它们分离的理由很直接。智能体是一个循环:它感知上下文,决定采取行动,执行它,然后重复。模型只是该循环内的推理组件。当它们紧密耦合时——当你的智能体本质上是围绕一个特定模型API的包装器时——你失去了随着格局变化而交换模型、按任务类型优化成本或在不重写智能体逻辑的情况下路由到更便宜、更快的模型来处理更简单子任务的能力。

Vercel的AI网关现在每天处理超过1万亿个token,是这个问题的部分答案。它位于智能体和模型之间,抽象化模型层,使智能体逻辑保持可移植性。Rauch的立场是,像Vercel这样的平台公司现在与主要实验室处于直接对立——正是因为实验室有结构性激励来保持模型和智能体的捆绑——锁定对token收入有利。平台公司有相反的激励:可移植性和可组合性使开发者留在平台上,无论哪个模型赢得下一个基准测试周期。

这是一场真正重要的结构性战役,它正在开发者现在做出的基础设施决策中展开。

为什么这对亚洲很重要

亚洲的AI开发者生态与模型vs智能体张力的关系具有西方评论经常忽视的特殊性。东南亚、韩国、日本和印度的开发者不是只在OpenAI或Anthropic上构建。这里的模型格局是真正多元的——阿里巴巴的Qwen系列、DeepSeek、百度的ERNIE,以及日益增长的为区域语言微调的开源权重模型都在竞争生产工作负载。这不是弱点。如果你的智能体架构从一开始就为模型可移植性构建,这实际上是结构性优势。

成本敏感性是另一个因素。在雅加达或胡志明市构建AI原生产品的初创公司的边际假设与旧金山B轮公司不同。当Rauch谈论"性价比"作为生产中的主要关注点时,这在亚洲引起了不同的共鸣——它不是一个好的优化,通常是可行业务和在推理成本上烧钱直到找到产品市场契合度之间的区别。

还有延迟维度。通过基于美国的模型端点路由智能体调用为亚洲的最终用户引入了真实的延迟。一个清晰分离智能体编排和模型选择的架构使得路由到区域部署的模型变得容易得多——无论是Alibaba Cloud上的Qwen部署、本地提供商上的DeepSeek端点,还是在你自己的基础设施上运行的开源权重模型。Rauch的框架应用于亚洲背景,不仅仅是关于成本——它是关于构建对你服务的用户实际表现良好的系统。

对于在MonstarX(亚洲AI原生开发平台)上构建的创始人来说,这个架构原则直接映射到你今天应该如何思考你的智能体堆栈。那些将模型依赖硬编码到智能体逻辑中的团队正在积累技术债务,当更好、更便宜或更快的模型可用时,这将很难解开——在亚洲的模型格局中,这发生的周期比大多数人预期的要短。

这对开发者意味着什么

Rauch论点的实际含义是智能体架构值得与任何其他分布式系统相同的设计规范。以下是具体思考方式。

将模型视为基础设施,而非身份。你的智能体的价值在于其编排逻辑、内存管理、工具使用和分解任务的能力。这些都不应该与你调用的模型纠缠在一起。在你的智能体循环和模型调用之间定义一个清晰的接口——即使你今天只使用一个模型。

这个的最小版本看起来像是在单个函数后面抽象你的模型调用:

async function callModel(prompt, options = {}) {
  const { model = process.env.DEFAULT_MODEL, temperature = 0.2 } = options;
  return await modelGateway.complete({ prompt, model, temperature });
}

那个单一的抽象层意味着从GPT-4o交换到Qwen-Max再到DeepSeek-V3是一个配置更改,而不是重构。这听起来很明显,但现在正在编写的大多数智能体代码库都不这样做——它们直接调用OpenAI SDK,到处都是,模型名称硬编码。

从一开始就为多模型路由设计。你的智能体中并非每个子任务都需要相同的模型。文档摘要步骤可能在较小、更快的模型上便宜运行。复杂的推理步骤可能需要前沿模型。如果你的智能体逻辑与模型层解耦,你可以按任务类型路由而无需重写任何内容。这是Vercel的AI网关发挥作用的地方——它是完全为这种大规模路由而设计的基础设施。

监控每个智能体步骤的token成本,而不仅仅是每个会话。当你将模型与智能体分离时,你获得了之前没有的可观察性。你可以看到你的智能体循环中哪些步骤消耗最多token,哪些模型调用相对于其成本返回低质量输出,以及在哪里可以替换更便宜的模型而不降低最终结果。这是Rauch描述的"性价比"优化——只有在架构分离存在后才可能。

以不同的方式思考失败模式。紧密耦合的模型-智能体系统在模型API宕机或限流时完全失败。解耦系统可以回退到替代模型、优雅降级或排队任务。对于服务真实用户的生产系统来说,这种差异至关重要。