Vercel首席软件官复盘：智能体构建从多智能体到文件系统的进化

在AI Engineer大会上，Vercel首席软件官（Chief of Software）Andrew分享了过去一年他在Vercel内部推动的一场"智能体爆发"实验。从最初一个复制粘贴SQL的巨型提示词，到最终开源的智能体框架EVE，这段历程几乎踩遍了当下所有构建智能体的坑，也揭示了一条越来越清晰的最佳实践路径。

从"每台桌上一台电脑"到"每台桌上一个智能体"

1980年，比尔·盖茨曾设想"每张桌子、每个家庭都有一台电脑"。Andrew和Vercel的CTO在大约一年前提出了一个类比性的问题：能否让每张桌子上都有一个智能体（an agent on every desk）？

在当时（Sonnet 4的时代，模型能力远不如今天）这是个相当超前的想法。今天智能体主要用于编程和技术工作负载，但设计、产品管理等垂直领域也开始出现应用。为了验证这个方向，Andrew走访了Vercel的市场、销售、财务、法务等团队，问他们"最讨厌自己工作的哪一部分"。最有说服力的场景来自数据团队——这是一个精简但增长压力巨大的团队，Vercel的增长速度远超他们处理数据的能力。每当市场或销售有关于客户、产品的数据问题，数据科学家就得放下手头一切，写查询、跑分析、给建议，严重拖累了整体生产力。

三次架构演进：巨型提示词、多智能体、单体记忆管理

第一版的做法非常朴素：把Snowflake的schema导出，粘贴进系统提示词，加上问题，让模型生成SQL，然后Andrew自己手动复制粘贴去执行。这个粗糙的实验带来了初步信心——今天的模型虽不完美，但在有一定结构的上下文下，能写出可用的SQL。关键在于把周围的"上下文工程"做好，给它更多护栏。

第二版被称为D0，也是后文反复提及的项目代号。Andrew和数据VP把数据科学家的工作拆解成明确的阶段：处理问题、探索语义层与join模式、执行SQL、失败或成本过高则重试、最终报告与可视化。他们据此设计了链式的多智能体架构——查询智能体、规划智能体、执行智能体等依次串联，每个智能体有专属的系统提示词和精确限定的工具（例如规划智能体只有read entity YAML和search schemas两个工具）。

这一版实现了从问题到答案的端到端闭环，但很快撞墙。团队意识到多智能体的致命问题在于：下游智能体只能拿到上游的摘要和一小段片段，信息在传递中大量流失。于是第三版转向"单一巨型智能体"——一个AI调用，max steps设为100，让它自己管理内部状态，在规划、构建、执行、报告之间切换，并能回看自己做过的事、反思纠错。当执行或join出错时，它可以退回去读更多、探索更多。

链式多智能体架构（Chain-of-Agents）是当前智能体系统设计的主流范式之一：将复杂任务分解为多个专职子智能体，每个子智能体只处理流程中的特定阶段，通过"上下文摘要传递"衔接上下游。这种设计的优势是职责清晰、便于调试，每个节点的工具集可以被精确约束，降低模型"越权操作"的风险。但其核心缺陷正如文中所揭示的——每次交接都会压缩上下文，原始信息逐层损耗，到达末端智能体时已所剩无几。这与人类组织中"信息在层级间传递时失真"的现象高度类似。单体智能体（Monolithic Agent）则是另一极：把所有推理步骤交给同一个模型调用，通过大token窗口保留完整历史，让模型可以回溯任意早期状态。代价是成本更高、单次调用延迟更长，且更难对某一环节单独优化。两种架构之间的取舍，本质上是"信息完整性"与"系统模块化"之间的权衡，目前业界尚无通用最优解。

被Cloud Code与Opus 4.5"降维打击"

团队对单体版本相当自信，评估集通过率约30%，于是小范围发给了几位可信同事试用。结果反馈是"糟透了"——真实用户提出的问题远超他们手动映射的场景，而继续人工穷举场景显然无法规模化。

转折点是Cloud Code与Opus 4.5的发布。Andrew直言，相比他们手工打造的智能体，"Cloud Code加Opus 4.5基本就是AGI"，几乎能不假思索地回答大部分问题。当他们复盘"自己到底做错了什么"时，得出了核心结论：最大的解锁是文件系统。Cloud Code只有极简的工具集——list file、read file、run bash——却没有给出高度规定性的工具，而是让模型自由探索、涌现行为。这些恰恰是智能体被充分训练过的能力。

文件系统智能体：评估分数直接翻倍

基于这个洞察，团队用"Cloud Code式"的思路重建了D0：让智能体运行在沙箱中，把整个语义层导入沙箱，智能体通过bash、read file、write file自由探索，再"撒上"几个Vercel特有的工具。这一步是"史上最大的解锁"，评估分数直接翻倍。实现却异常简单——用npm上的bash tool helper挂载一个沙箱，把文件放进去让它读写执行即可。

随后Andrew写了一篇复盘博客，发布当周贡献了Vercel.com 70%的流量。接下来的优化是"技能"（skills）：他们发现每天数千次查询在形态上高度重复——聚合、产品查找、账单信息就那么几种写法。于是设置了一个定期任务，把最近的查询蒸馏成技能，目前已积累约100个技能。每次新的智能体运行不再从零开始，而是带着已沉淀的上下文知识起步。Vercel还为此推出了Skills SH工具，用于查找和运行智能体技能。

这里的"评估集通过率"（evals pass rate）是衡量智能体质量的核心工程指标。Evals（评估集）通常由一组有标准答案或可自动评分的测试用例构成，涵盖典型输入、边界情况和已知失败场景。与传统软件的单元测试类似，evals让团队能在每次改动后量化回归或提升。在智能体开发中，因为模型输出具有不确定性，evals的设计尤为重要——既要覆盖"正确性"（如SQL能否执行、结果是否准确），也要覆盖"鲁棒性"（如面对模糊问题时是否会幻觉）。文中从约30%通过率翻倍至约60%的跃升，对应的是架构层面的系统性改变而非微调，说明文件系统赋予模型"自由探索"能力所带来的增益是结构性的，而非边际优化。

EVE：面向智能体的"Next.js"

Andrew指出一个反复出现的现象：在构建D0的每个阶段，都有Vercel同事"智能体好奇"，fork他的代码去搭自己的智能体，而每一步都存在当时未知的更优解法。这促使团队思考——能否让人们直接从最后的洞察出发，而不必每次从简单提示词或第一性原理重新发明？

答案是两周前发布的开源框架EVE，定位为"面向智能体的Next.js"。正如Next.js用文件系统约定自动声明基础设施，EVE让开发者只需创建skills文件夹、tools文件夹、channels文件夹，框架就知道如何组装成一个智能体。

EVE的智能体模型包含runtime和channels：runtime负责持久性、隔离执行环境、模型调用和连接。框架以开源为核心设计，可插入Postgres、OpenAI Responses API、Docker等自有适配器，同时也能便捷部署到Vercel，配套Vercel Workflows（持久性）、Sandbox（安全执行）和新发布的Vercel Connect（生成短时OIDC令牌用于连接）。团队用EVE重写了整个D0，最终的文件结构非常简洁——一堆系统指令、几个技能、几个工具。

OIDC（OpenID Connect）是建立在OAuth 2.0之上的身份认证协议，广泛用于服务间的短时令牌授权。文中提到的"短时OIDC令牌"（short-lived OIDC token）是云原生安全实践中的重要概念：相比长期有效的API密钥，短时令牌在泄露后的爆炸半径极小，且可绑定到特定工作负载和时间窗口，极大降低了智能体访问外部服务时的安全风险。Vercel Connect通过在每次智能体运行时动态签发令牌、运行结束后自动失效，将安全性内置到框架层，开发者无需手动管理凭证轮转。这也是企业级智能体框架区别于个人Demo的重要维度之一——可观测性、隔离执行环境与最小权限令牌，共同构成生产就绪的安全基线。

垂直智能体的真正壁垒：公司特定知识

在正式发布前，EVE已交给部分Beta客户测试。合作伙伴Aura用EVE从零重建了一个类似"迷你Claude"的智能体，用于自动访问网站、安装并测试服务，相比现成的Cloud Code，取得了更少步骤、更高成功率和更好洞察的效果。部署到Vercel后还自带可观测性，可查看每次运行、每个工具调用、每一步以及预估成本和优化建议。

Andrew强调一个核心观点：现成的垂直智能体（比如专门跑Snowflake查询的）很好用、值得尝试，但真正让智能体出色的是大量公司特定知识。Vercel作为一家Web公司，深知客户网站属性之间的关联、何时该查什么，这些是通用工具难以复制的。目前Vercel内部已有约20个达到PMF的智能体，覆盖市场复盘、销售触达、法务合同初次红线批注到数据查询等场景，数据团队因此得以腾出时间去优化Snowflake性能、接入新数据源。他建议各种规模的公司都去尝试构建自己的智能体，把尽可能多的公司知识灌进去，而EVE正是当下最好的选择之一。开发者可在eve.dev获取模板起步。