大家好，感谢出席。我是Andrew，Vercel的软件主管，今天我来谈谈我们在Vercel是如何解决智能体构建问题的。作为软件主管，我负责内部工程、外部实验的混合工作，通常处于前沿阵地，构建新的库、框架和技术。对于那些不了解Vercel的人来说：
Vercel构建了生成式基础设施，让人们能够构建未来。我们从Web世界起步，帮助人们部署网站和Web应用，而无需担心那些不会让应用程序变得更好的基础设施。它可以轻松扩展到百万级别并缩放到零，但我们看到人们想要构建的东西正在发生变化。
你们知道，人们最初开始构建页面，但现在我们看到他们希望构建智能体（Agents）。我们也踏上了类似的旅程，旨在让人们更容易地构建智能体和智能体应用程序。我们构建了名为AIDK的东西：
因此，你不再需要切换300到400行特定于提供者的代码，只需切换一行代码即可。我们为所有这些不同的提供者提供了相同的底层模型接口。我们构建了许多其他工具，以简化模型回退、安全代码执行的功能；在空闲和等待响应时提供更好的定价；以及增强耐用性和可恢复性。
我今天要谈谈大约一年前我进行的一项疯狂实验，这项实验导致了Vercel内部智能体的爆发式增长，并促成了我们最近构建的一个非常酷的功能。
这是1980年的事。在我出生之前，比尔·盖茨曾说过这样一句话：“我想象着每台办公桌和每个家庭里都会有一台电脑。”你知道，那在当时可能相当反主流，而今天看来这似乎是非常正常的事情。我和首席技术官有过这样的想法：
你知道吗？与其说每台办公桌上有一台电脑，我们是否有可能在每张办公桌上都有一个智能体呢？
如今，我们主要只在编码和技术工作负载中使用智能体，但我们开始看到它们扩展到设计、产品管理和其他垂直领域。这大概是一年前的事了，所以我说我算是这个领域的早期探索者，但那时还是Sonnet 4模型，其复杂程度远不如今天。我试图实际探索这一点，看看我们能做些什么。
我去拜访了Vercel各个职能部门的人——市场、销售、财务和法律，问他们：“你们工作中最讨厌的是什么？”我听到的最具说服力的用例来自数据团队。
他们的团队在增长，虽然是一个非常精简的团队，但Vercel的增长速度更快。你们知道，他们拥有来自客户、分析指标和销售的大量数据。他们必须不断聚合这些数据，并使其可供自己使用。
在这个时间点，如果你想想数据科学家 ever 需要做什么：每当市场或销售部门的人对某个客户或产品有疑问时，数据科学团队就必须放下手头的一切工作，编写查询语句，处理数据进行分析，然后带着一些关于下一步行动的建议回来。
这对生产力造成了极大的损害。你知道的，数据团队不想放下所有工作整天只写查询语句。所以我与我们的数据副总裁合作，试图为他们构建一种更好的运作方式。
如果你想想如果要用AI解决问题，你做的第一件事可能只是构建一个巨大的超级提示词（Mega Prompt）。你知道的，就是有一个问题，你把它输入给大语言模型，让它回答，就这样。
你知道这就是第一版的样子。老实说，我让他们导出了Snowflake数据库的模式结构（schema dump）。我将它粘贴到系统提示词中，加上一个问题，然后当模型生成SQL时，我实际上手动复制粘贴了那段代码并自己运行它。
你知道我只是想看看今天的模型在给定一些合理结构的情况下，是否足够好以编写有效的SQL。我说这给了我们一点信心：
你知道今天的模型并不是那么好，但也许我们可以利用工程手段或改善其上下文环境，提供一些更好的护栏来让我们更好地运作。
所以如果你想想数据科学家在接到问题时实际上需要做什么：他们需要处理问题，可能需要探索语义层并实际弄清楚连接模式是什么。他们将会去执行SQL查询。
如果SQL没有执行成功或者成本太高，他们可能会回去再做一次。最终他们会进行报告，包括可视化数据，也许写一些段落，也许做一些回顾，或者做其他事情。
所以如果你想想这些不同的阶段，我和数据副总裁试着坐下来将这些映射到特定的智能体工作负载中。
因此这个数据科学智能体的第二版被称为D0（Data Agent 0）。从现在开始我将引用D0。当你问一个问题时，我们有一个查询智能体将问题传递给规划智能体，然后由执行智能体等依次处理。
如果你将所有这些链接在一起，你实际上会得到看起来像这样的结构：每个智能体都有一个非常专用的系统提示词，专注于它所做的功能，工具范围也严格限定在该函数上。
例如在这里你可以看到，对于第一个智能体，规划智能体拥有读取实体YAML和搜索模式（schemas）的工具。因此它只会使用这些能力，直到它有答案传递给规划智能体，然后传给SQL智能体，最后到报告环节。
这变得更好了。你知道我们得以摆脱手动复制粘贴SQL并回来报告的麻烦。现在它实际上在执行从问题到答案的端到端循环。
但我们开始在这套架构中遇到了一些瓶颈。在这个时间点，我们得出结论：你知道你实际上需要的是一个拥有所有超级上下文的单一智能体，让它自行管理其记忆。
你知道这大约是我们意识到希望智能体能够回顾它所做的事情、进行反思并弄清楚到达这一步的步骤的时候。
使用之前的模型，你可能已经注意到下一个智能体唯一得到的只是摘要和之前所做工作的一小段片段。
而现在你可以想象你有一个超级智能体，它在内部自行管理其状态。在某些时候它在进行规划，某些时候在构建，某些时候在执行，某些时候在报告。
这大致就是它的样子：你知道你有一个大的AI调用，也许最大
步骤100，并赋予它根据执行旅程中的位置来管理自身状态的能力。因此你可以看到类似的工具和相似的形态，但最棒的部分在于：如果在执行或加入过程中遇到错误，它可以返回并探索更多细节，或者去阅读更多内容以找出自己做错了什么。在这个阶段，我们对手头的系统相当有信心，并实际上将其扩展到了少数几位受信任的成员手中。你知道的，这是一个非常强大的工具，我们真的不想把它交给错误的人或处理关键工作负载的人员。
因此它只落到了少数人手中，而最初的反馈是“太糟糕了”。我们原以为自己在烹饪佳肴，认为这个系统能解决30%的评估问题，但我们无法预料到被提出的某些问题。为了花费更多时间手动映射这些场景，这似乎不是一个可扩展的方法。随后Claude Code和Opus 4.5发布了。更准确地说，是Opus 4.5发布后，与极其强大的Claude Code相辅相成。
你知道的，它们解锁了“文件系统智能体”的概念。我们在旁边惊叹道：与之前相比，Claude Code和Opus 4.5基本上就是AGI（通用人工智能）。它几乎能回答我们的所有问题，甚至毫不迟疑。相比之下我们之前手工打造的智能体就显得逊色得多。当我们试图退一步思考哪里做错了，以及为什么现在的方案如此出色时，我们意识到最大的突破在于它仅仅是一个文件系统。
你知道的，它的工具集非常精简：列出文件、读取文件、运行Bash命令。为了我们的数据智能体用例，我们额外提供了一些工具。但最关键的是它能够使用那些经过良好训练的智能体所熟悉的工具，并能够在需要时进行探索和编写工作。你知道的，我们没有给它提供一套非常规定性的工具。它更像是被允许自由探索并涌现出行为模式。
因此我们学到了，其实真的只需要使用文件系统即可。我们从Claude Code中看到了学习成果，鉴于它仅在本地执行且如此强大，我们尝试以一种非常类似Claude Code的方式重新构建它。你知道的，现在它将在沙箱中运行。该沙箱会将整个语义层转储进去。智能体能够获取Bash权限，读取文件、写入文件等，以弄清楚它需要什么；我们只需在上面添加少量工具以确保它能完成所有Vercel特定的操作。
这实际上是迄今为止最大的突破。从单一智能体到Claude Code SDK，再到通用的文件系统智能体的飞跃——特别是针对我们的用例进行了微调或专门构建的智能体——是一次惊人的跨越。在这个阶段，我们准备将其向Vercel的更多人员开放。此时评估分数基本翻了一番。我写了这段内容，这基本上就是它的样子：非常简单。你只需给它一个Bash工具。
我们在npm上有一个名为“bash-tool”的便捷助手，你可以将其附加到沙箱中。你还可以将文件附加到沙箱供其读取、写入和执行。在这次启示之后，当我看到我们通过了之前未能通过的大量问题时，我写了一篇精彩的博文。它实际上今天已经上线了。在我撰写这篇文章的那一周，它贡献了我们Vercel.com网站70%的流量。所以你知道的，这是一篇爆款文章。
在此之后，合乎逻辑的下一步是找出我们常见的用例。那时我们已经解开了对Salesforce的限制（原文cell应为salesforce或类似内部系统，此处结合语境译为解除限制/放开），每天收到数千个查询请求。人们想要获取各种数据，从客户指标、销售指标到数字指标和NPM下载量。事实证明，许多查询在形状上是相同的：你知道的，聚合的方式有限，查找产品的方法有限，获取账单信息的方式也有限。
因此我们实际上有一个定期作业，它提取最近的查询并试图将其提炼为“技能”（Skill）。目前我们大约有100种技能，涵盖了从聚合到查找特定人员具体数据的各种操作。我们发现这非常有效，因为如果你想想看，每次新的智能体运行都基本上是从零开始。你知道的，除了语义层和系统提示外，没有预先建立的上下文。
但有了技能，它就已经具备了大量的背景知识，这些知识此前已经被处理过。这基本上就是它的样子：与之前非常相似，但包含一个“skills”文件夹实际上非常强大。我们还在Vercel构建了名为Skills CLI的工具，这是查找智能体技能并自行运行它们的流行方式。我说这一切是因为这段旅程是许多人偶尔会遇到的：你从简单的东西开始，逐渐增加复杂性，最终达到可以部署到生产环境的系统。
我告诉你这些是因为在构建这个智能体的每一步中，Vercel的某位员工都对智能体感到好奇，他们尝试分叉我的DZero智能体并构建自己的版本。在每一步中，我们都找到了一种以前未知的更好方法来做事。我们不禁在想：如果今天的人们能够直接从最后的洞察开始，而不必仅仅从简单的提示词或从头重新发明最佳原则起步，那会怎样？
因此我们实际上在想：如果我们为智能体构建一个“Next.js”呢。对于那些不知道的人，Next.js是Vercel开发的一个流行Web框架，它发明了这种“文件系统定义的架构基础设施”的概念。你不必担心东西放在哪里；只需要按照正确的约定编写文件，它会自动声明它们应该放置的位置。你的页面去CDN，无服务器函数去那里，缓存放在中间。
我们认为构建智能体也应该这么简单：你只需要创建一个skills文件夹、一个tools文件夹和一个channels（渠道）文件夹，然后能够轻松声明这些内容。框架应该确切地知道如何从中创建一个智能体。这就是为什么两周前我们发布了Eve（注：此处可能指代Vercel的新框架或产品，原文为Eve）。Eve是一个智能体框架，就像Next.js之于Web开发一样用于智能体：从使用示例模板开始非常容易，就能拥有一个完全就绪的智能体。
并且能够添加你自己的自定义知识、自己的自定义工具，甚至集成到你熟悉的渠道中。
这大致就是我们认为 Agent 实际呈现的样子。Agent 拥有运行时和通道，在运行时中具备持久化能力，并希望在隔离环境中运行任务。它需要能够调用不同的模型，并保持连接状态。我们构建 Eve 时充分考虑了开源理念，你可以接入自己的开源适配器来支持 PostgreSQL、OpenAI 的响应 API、Docker 以及其他连接器。
同时，我们在 Vercel 上部署也极其简便。这里唯一的区别在于所有组件均使用我们多年来开发的 Vercel 产品，以简化这些体验的构建。包括用于持久化的 Vercel Workflows、用于安全执行的沙箱环境，以及我们刚刚发布以简化生成短期 OIDC 连接令牌的 Vercel Connect。
在构建 Eve 的过程中，我们重写了整个 D0ero Agent 的代码结构，消除了后台复杂的逻辑。文件系统非常简洁：包含一系列系统指令、几个技能（Skills）和工具，易于组合成真正的 Agent 并进行迭代。两周前在伦敦活动正式发布前，我们已向部分 Beta 客户提供了此版本。
与我们紧密合作的 Aura 公司利用 Eve 从头重建了其类似 Mini Claw 的 Agent，用于测试用户的服务。它会访问网站、安装并试用服务。相比使用现成的云代码，他们取得了巨大成功：步骤更少、成功率更高且洞察更优。
将 Eve 部署到 Vercel 后，开箱即用地获得可观测性。你可以查看所有 Agent 运行记录、工具调用及每一步骤，还能看到预估成本和潜在优化建议。今天即可在 eve.dev 开始使用：克隆代码、启动模板、轻松部署，或按需自托管。
我提及此事是希望出现更多针对特定业务场景的 Agent。在构建 Ezero 之前，我们测试了许多行业初创公司开发的垂直领域 Agent（如专门处理 Snowflake 查询的）。我们发现，优秀的关键在于拥有大量特定公司的知识。
以 Vercel 为例，作为 Web 公司，我们深知何时查询什么内容以及数据间的关联。现成的 Agent 虽好，但若想榨取最大价值，应构建自有 Agent 并融入尽可能多的公司特定知识。目前我们在 Vercel 拥有约 20 个通过产品市场契合度（PMF）验证的 Agent。
这些应用涵盖从营销复盘确定联络对象，到法务审查新谈判时的合同红线，再到数据科学 Agent 协助查询。这证明了我们一直深受 Agent 赋能：所有工具都大幅节省了时间，数据团队生产力空前提高。
他们有更多时间去优化 Snowflake 性能、添加缺失的数据源，填补因忙于写查询而忽略的空白。我认为对于任何规模的公司而言，现在自动化那些不想做或耗时过多的事情从未如此简单。HR、财务和销售等领域均可通过 Agent 实现部分自动化，而 Eve 今日是构建此类 Agent 的最佳方式。
这是我的社交媒体账号。感谢大家的聆听与到来，我是 Andrew，如果会后想交流随时找我。