Vercel 把造 Agent 这件事，又走了一遍造网站的老路

Vercel 最早解决的问题是帮人把网站发布到互联网上，不用自己管服务器扩容缩容。Andrew Qu 是 Vercel 的软件负责人，他在 AI Engineer World’s Fair 2026 主舞台的分享里说，公司现在想把这套本事搬到 Agent 身上，换的是能自己跑起来的智能体。

原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 06:30:15 开始）

模型供应商这堵墙，先拆了再说

Andrew 开场讲的第一件事是 AI SDK。以前想换一个模型供应商，得改 300 到 400 行供应商专属代码。今天在 Vercel 内部，换供应商是改一行。AI SDK 把不同厂商的模型接口收成同一套，模型可以随便换，代码不用跟着重写。

这件事听着朴素，但换算成工程量就有意思了：一个团队原本要为”换个模型试试”专门排一次重构任务，现在变成改一个配置项。Vercel 顺手把模型 fallback、代码安全执行、请求空闲时的计费优化、断点续跑这些也做成了标配能力。用 harness engineering 圈子的话说，这些都算”harness”。凡是不属于模型本身、但决定 agent 好不好用的那套系统，沙箱、工具、记忆、重试逻辑都算在内。AI SDK 干的事，就是把这层从每个团队自己手搓，变成平台白送。

从超级 prompt 到超级 agent，真实用户都不买账

Andrew 讲了他一年前开始的一次内部实验：给公司数据团队做一个 agent。背景很实际：Vercel 的数据团队人少，公司却涨得更快，市场、销售一有客户或产品问题就得让数据团队现写 SQL、跑、出报告，团队疲于奔命。

第一版极简：把 Snowflake 的表结构整个塞进 system prompt，模型生成 SQL 后他自己手动复制粘贴执行。这一步只是想验证模型能不能写出可用的 SQL，结论是勉强能，但需要更好的上下文和护栏。

第二版叫 D0：拆成查询、规划、执行等多个 agent 串联，每个 agent 只有一个窄提示词和几个限定工具，比如规划 agent 只给”读实体 YAML”和”搜索 schema”两个工具。这一步跑通了端到端闭环，不用再手动搬运 SQL。

但很快撞墙，团队又转向另一个极端：一个装着全部上下文的超级 agent，自己管理状态，能回溯自己做过什么。最多跑 100 步，内部自行判断当前在规划、构建、执行还是报告阶段。信心满满地放给几个信任的同事试用，反馈是”awful”。难听地说，真实用户提出的问题花样太多，团队自以为做对了，实际大概只答对了三成。三成是什么概念：等于每问三个问题错两个，这种命中率放进生产环境等于没法用，团队这才意识到，指望靠手工穷举场景来堵漏洞，压根撑不住规模。

Claude Code 的顿悟：别管它怎么用，给它文件系统就够了

转折点是 Claude Code 和 Opus 4.5 出现。团队试用后的第一反应是”这跟 AGI 差不多”。同样的问题，几乎不打磕巴就答对了。复盘之后发现关键不在模型本身，而在工具集：Claude Code 给的工具极简，列文件、读文件、跑 bash，仅此而已，剩下全靠模型自己探索该怎么做，团队没有替它规定死板流程，反而让”涌现行为”跑出来了。

于是团队把 D0 重写成沙箱里跑的文件系统 agent：把整个语义层扔进沙箱，agent 自己 grep、bash、读写文件，只在上面加几个 Vercel 专属工具补个缺。这一次 eval 分数直接翻倍，从原来大约三成蹿到六成左右。模型没换，换的只是工具怎么给、上下文怎么摆——卡脖子的常常不是模型，是包在模型外面那层设计。

Andrew 后来把这段经历写成一篇博客，发布当周贡献了 vercel.com 大约七成的访问量。侧面说明”怎么让 agent 好用”这件事，市场比想象中更饥渴。

100 个 skill，是被重复问题攒出来的

agent 放开给全公司用之后，每天涌进上千条查询：客户指标、销售数据、npm 下载量等等。团队发现这些问题其实翻来覆去就那几种形状：无非是聚合、查产品、查账单。于是他们做了个定时任务，把最近的高频查询自动蒸馏成”skill”，现在大概积累了 100 个。

这么做的好处是每次新开一个 agent 会话不用从零开始。没有 skill 之前，agent 每次只带着语义层和系统提示词起步；有了 skill，它一上来就带着别人已经趟过的经验。团队还顺手做了个叫 Skillsh 的小工具，专门用来找别人写好的 agent skill 并直接跑。技能负责攒经验，框架负责跑起来，两者分开之后，框架能越做越薄，技能能越攒越厚。

Eve：agent 界的 Next.js

Vercel 意识到，每次有人对造 agent 感兴趣，都得从头 fork 一遍 D0 重新摸索，没人能直接接手上一轮的最新经验。于是他们把这条路走成了一个框架，就是两周前刚在伦敦发布的 Eve。

类比很直白：Next.js 让开发者不用关心页面该部署到哪、缓存该放哪，只要按约定写文件，框架自动归位。Eve 想让造 agent 也这么简单：建一个 skills 文件夹、一个 tools 文件夹、一个 channels 文件夹，框架就知道怎么把它们拼成一个能跑的 agent。Eve 本身开源，可以接自己的 Postgres、OpenAI responses API、Docker 等适配器，部署到 Vercel 则直接复用公司已有的产品：Workflows 管断点续跑，Sandbox 管安全执行，新发布的 Connect 负责短时 OIDC 令牌。

团队顺手用 Eve 把 D0 整个重写了一遍，文件结构从原来层层叠叠的内部实现，变成几个系统指令、几个 skill、几个工具，改起来轻松很多。合作方 Aura 拿 Eve 重建了自己的产品测试 agent（会去访问网站、装上、试用），对比直接套用现成的 Claude Code，步骤更少、成功率更高。部署到 Vercel 后自带可观测面板，能看到每次运行、每个工具调用、每一步耗时和预估成本。想试的话，直接去 eve.dev 拿模板自己部署或者自托管。

自己的护城河，是公司专属的那部分知识

Andrew 提到，在做 D0 之前，团队试用过不少融资雄厚的垂直 agent 创业公司的产品，比如专门帮你把 Snowflake 查询做成 agent 的那类工具。用下来的结论是：这类现成 agent 上手是好用的，但真正让 agent 好使的，是大量公司专属知识。Vercel 是一家做网站和 web 产品的公司，agent 得懂什么时候该查什么、什么东西链接到什么，这部分知识买不到，只能自己攒。

现在 Vercel 内部大概有 20 个真正有产品市场匹配度的 agent，横跨市场部门的复盘分析、法务第一次给合同划红线、还有 Andrew 自己的数据科学 agent。数据团队因此腾出手做以前没空做的事，比如优化 Snowflake 性能、补齐缺失的数据源，不用再整天写查询。

这场分享在 Day 3 的位置

这是 Day 3（官方口径 Day 4，最后一天）Harness Engineering 赛道的第 14 场，前一场 Kay Malcolm 讲”没有数据库就没有记忆、没有记忆就没有 harness”，紧接着后一场 Philipp Schmid 讲”skill、YAML 和文件系统怎么替代了写 Python”——三场连在一起，正好从三个不同切口讲同一件事：agent 的可靠性到底该往哪儿使劲。

Andrew 这场的独特之处在于站在”平台方”的角度：前面几场大多讲一个团队自己怎么设计好 agent，是单点视角；他讲的是 Vercel 作为基础设施提供商，怎么把这套摸索经验打包成别人可以直接拿去用的框架。这和 Vercel 自己的历史路径完全对得上——先帮人部署网页不用管服务器，现在帮人部署 agent 不用管 harness。

我的看法

Andrew 这场最值钱的不是 Eve 这个产品本身，是他复盘的那条弯路：多 agent 流水线不管用，换成一个装着全部上下文的超级 agent 也不管用，真正管用的是把工具收窄到几乎没有约束、让模型自己探索。这条经验跟”巨型全权 agent 不可控，应该做范围清晰、能被证明做过事的 worker”这类批评其实是一回事的两面：Vercel 是从”工具太多、约束太死”这一侧撞的墙，结论却殊途同归——agent 要么范围收窄、要么工具收窄，笼统地堆能力只会让它更难伺候。

延伸一句：Vercel 这次”模型没换、只改工具和上下文，eval 就翻倍”的实证，跟我另外读到的一份字节跳动内部对照实验结论一致：900 次测试里模型和框架都固定不变，只补上下文工程和架构约束，可交付性就从四五十分做到八十分。两边行业不同、场景也不同，却在说同一件事：把上下文工程和架构约束这些”脏活”做扎实，投入产出比常常比干等一个更强的模型更高。这也是 Eve 把 skills/tools/channels 拆成独立文件夹的原因，技能负责攒经验，交给团队自己沉淀，框架只管把它们跑起来，越薄越好。

如果你也在给团队内部业务做 agent，这次分享给的实用提示是：先别急着设计一堆专用工具和分步流水线，试试给模型一个沙箱、几个通用工具（读写文件、跑命令）够不够用；真出现重复的查询模式，再把它蒸馏成 skill 沉淀下来；一上来就想穷举所有场景，大概率是白费功夫。