跨国深谈← 返回←把智能体从「桌上的宠物」搬进云端：Vercel 开源框架 Eve

把智能体从「桌上的宠物」搬进云端：Vercel 开源框架 Eve

关联

人物 Andrew Barba · Shar Dara · Kevin Ball

公司 Vercel

概念 Eve · DZero · 智能体 · 评估 · 技能 · MCP · 沙箱 · 记忆 · 工作流 · 无服务器函数 · Next.js · 子智能体 · 权限

这一集聊的是 Vercel 新开源的云原生智能体框架 Eve。两位主角都来自 Vercel：Andrew Barba 是技术团队成员，Char Dara 是 Eve 的产品负责人，两人此前曾一起领导 Vercel 的计费团队，今年二月开始做 Eve。

主持人 Kevin Ball 的第一个问题就戳中要害：现在的智能体大多是「一人一进程」——你在自己电脑上跑一个 Claude Code、Codex 之类的东西。可一旦智能体要服务一个企业，成千上万个请求同时到达，每个会话都要隔离、持久、可恢复，这套本地模式就撑不住了 。

Andrew 用一个例子说明「云原生」到底意味着什么：拿一个 OpenClaw 和一个 Eve 智能体，让一千个人在同一时刻发提示词——OpenClaw 会垮，Eve 会横向扩展、快速并行拉起这些 harness（承载模型、连接工具的运行壳），会话互相隔离、可恢复、可重试，背后一整套机制兜底。它既能做万人企业的内部智能体，也能支撑一家把智能体当主产品的 B2C 公司 。

Eve 是怎么来的：从内部数据智能体 DZero 长出来的框架

Eve 并非凭空设计。Vercel 内部最早的全员智能体是一个叫 DZero 的数据智能体——你问它「有多少月活用户」，它靠一整层语义文件（Markdown、YAML 规范文件）来理解各种缩写和术语的含义。

团队发现：把 DZero 稳定跑在 Vercel 上要手工搭一大堆系统，而 DZero 下面这一大层，之后每个智能体都会需要；同时 DZero 的功能大部分本来就来自文本文件 。于是有了两个激进的决定：一，用声明式文件系统定义智能体；二，最初干脆「没有代码」——Eve 纯粹是英文、Markdown、文本文件。

所以 Eve 的形态 literally 就是一个目录。最简单的 Eve 智能体可以只是一个 instructions.md 文件——放进一个指令文件，你就得到一个按原始训练状态运行、云端托管的前沿模型，团队自嘲称之为「盒装 ChatGPT」。你写的配置会编译成一个 manifest（清单文件），本质是基础设施即代码：加了 skills 就配沙箱，定义了 schedules 就配定时事件基础设施，平台只供给你实际用到的东西。

核心原语：instructions、skills、tools、connections、channels

Andrew 逐一拆解了 Eve 的构建块。instructions 是智能体的身份；skills 是「渐进式披露」机制——你只给模型一个「何时该用」的提示，模型擅长判断自己什么时候需要进一步了解某件事，再自己去拉取额外上下文，DZero 有大约 90% 都是 skills ；tools 用于跑确定性代码、从外部拉确定性数据，比如 Postgres 数据库或 OpenAPI 连接；connections 是 tools 的特化版，专用于 MCP（一种让模型接入外部工具服务的协议），丢进去一个 MCP URL 就自动暴露那些工具。

再往上是 channels——智能体的所有调用入口。默认是一个 HTTP 路由，接 Next.js 应用用的就是它；更有意思的是 Slack、Teams、GitHub 这类渠道，Eve 支持这些平台的所有第一方事件，并给出带倾向性的默认交互方式 。还有 sub-agents（子智能体），最简单的用途是上下文管理——把不想塞爆父智能体的大任务分出去独立处理再汇报；但在 Vercel 内部它被玩出了组织结构：整个团队拥有一个子智能体，比如 DZero 本身就是另一个智能体的子智能体、由数据团队拥有，还有一个懂 Eve 全部构建知识的 help Eve 智能体，全公司都能调用 。

Evals 做成一等公民，测试套件本身就是一整套 evals

Char 特别兴奋的一点是 evals（评测）在 Eve 里是一等公民原语。Eve 支持两类：偏确定性的——发一个查询、断言某个工具被调用了，比如天气智能体收到「天气如何」就该调用 Get Weather；以及 LLM as judge——让模型对响应打分，比如 DZero 可以对生成的 SQL 做评分，确认它查的是正确的表 。Eve 里的 eval 就是一个 define eval 函数，拿到一个测试函数接口，能通过 prompt 启动轮次、触发 human in the loop，等于智能体的完整编程接口。

最能说明问题的是他们自己的用法：Eve 仓库的测试套件就是一整套 evals——他们用自己的 eval 框架测试 Eve 本身，「这基本上就是我们敢于一天多次发布新版本的信心来源」。

主持人 KBall 追问了一个前沿方向：能不能把 evals 从「护栏」（确保所信为真）推进到「把 prompt 变成优化函数」——用 evals 定义期望结果，再让模型在循环里迭代演化智能体。Andrew 坦言没从这个角度想过，但给了个实践性的答案：因为 Eve 包内附带了对 LLM 友好的文档并「提示」你该用 evals 测试，如果你用编码智能体来构建 Eve 智能体，它迭代时就会自己写并运行 evals；他没见过它先写 eval 再写实现，但「你应该能拿到非常接近那个的东西」。

这里还有个普适经验：模型训练数据里的框架版本都是旧的，而 Eve 对模型来说完全不存在，所以他们花大力气让包自带 LLM 友好文档，还把 changelog 打进包里——智能体发现自己用的是 0.2 版、changelog 已经到 0.5，就直接看 diff。对一个 pre-1.0、每周都在破坏兼容性的框架，这是让用户升级时「不发火」的主要手段 。

权限与安全：多层设计，连「看得到什么」都能按人切换

因为一开始就瞄准企业市场，权限在很早就内置了。频道层先解决「你是谁」——Slack 场景下就是工作区 ID 加用户 ID；你在 Eve 里写代码的任何地方都拿到一个 context 对象，告诉你这一轮的当前用户是谁、发起这一轮的用户是谁——两者可以不是同一个人，不同的人可以在不同时间跟进 。更细一层是工具审批：你只需声明某个工具「总是要求审批」，审批消息会以人机协同的形式渲染在调用来源的渠道上——从 Slack 进来就在 Slack 里渲染，从 SMS 进来就是另一种形态；提问的人、请求审批的人、给审批的人都可以不是同一个人，怎么处理由你写代码决定。

最有意思也最难的一层是「怎么看得到该看的」：DZero 能访问 Vercel 的整个数据湖，CEO Guillermo 能查的数据我未必该查。Eve 为此提供了一个叫 DefineDynamic 的高级 API，可以根据当前调用者动态解析出不同的工具集、连接集——我是发起人时就字面意义上不暴露某个工具 。Andrew 承认连 Vercel 自己都还没完全解决这层问题。

谁在用：从挠自己的痒处开始

Char 介绍了采用情况：最初瞄准企业是因为需求都来自那里，加上「挠自己的痒处」——Vercel 内部所有智能体都跑在 Eve 上，现在有数百个。发布后很快有数千外部用户采用，不止企业客户，hobby 和 pro 用户都有，用例从企业自动化业务职能，一直到爱好者周末搭一个 iMessage 多人游戏智能体 。

职能分布最初偏工程，后来 go-to-market 团队把所有东西都搬上了 Eve，市场部用它做内容创作和社交媒体自动化，产品团队把文档喂给智能体回答内外部问题、有时直接在 Slack 上分享给客户。非工程团队用法上浮出三种模式：最常见的对话式智能体（主要走 Slack，Vercel 是一家 Slack 公司）；后台智能体（跑报告然后发到 Slack 或邮件）；以及智能体驱动的 web 应用——前端是普通应用，背后由智能体驱动，GTM 团队是这种的大用户 。应用侧的真实例子：一个开源 CRM，用户添加线索的姓名和邮箱后，后台智能体自己去研究线索并完成整个流程；还有一个 AI 音乐制作工具，你设定节拍、智能体与你在站点上协作完成音乐 。

基础设施：会话即工作流，15 分钟超时怎么跑出无限时长

云端规模化最硬核的部分在这。Eve 构建在 Vercel 的 workflow 之上——Andrew 说这基本上是他们版本的 Temporal（一个把长流程做成可持久化、可恢复的工作流的系统）。建模方式是：单个工作流就是单个 Eve 会话，每个会话与其他会话完全隔离；一千个会话和一个会话对你来说不该有区别，「云应该替你做这件事」。

一个巧妙的细节：Eve 跑在无服务器函数上，而这类函数历来有 15 分钟超时，智能体显然会跑得更久。Eve 的解法是——每次调用一个工具，就切换到另一个函数继续这个工作流，因为每次工具调用本来就是一个同步中断点。今天他们实际上为每一个步骤都切换新函数，只要工作流足够快，你感觉不到，智能体因此可以实际无限期运行下去 。

与 Next.js 的整合是明确主张：Next 有 pages 目录和新的 app 目录，Eve 的 agent 目录被设计成「必须开箱即用」，可以就放在你的 Next.js 应用旁边；但也可以独立部署、通过 HTTP 连接——Eve 返回一个持久化流，能驱动任何 UI。他们内部对它的定位很干脆：「EVE 是一个后端框架，不是前端框架」。发消息时还可以指定输出 schema，Eve 会生成一个 SubmitResult 工具来验证 schema，产出不符就回提示让模型重做，于是你可以「用智能体方式生成」UI 需要的那种形状的数据。

记忆与自我进化：Andrew 当前最大的工作

持久化记忆是 Andrew 说自己「现在正在做的最大的一件事」，全部以 PR 形式开放。设计上是一个一等公民的 Memory 目录，里面可定义多个记忆槽位（slot）：比如一个全局槽位、一个只属于你个人的槽位、甚至频道加用户的槽位，智能体据此有多个记忆库可读写。关键护栏是确定性：经典反例是你几乎永远不想要一个接收用户 ID 作为参数的工具调用——你不想让智能体去「猜」用户 ID；绑定到记忆槽位的工具把身份在底层注入函数调用，它就猜不错了 。

暴露机制采用了 provider（提供者）模式：Eve 确定性地调用三个函数——recall（回忆）、save（保存）和 tools——provider 想怎么做完全随意。随框架发布的文件 provider 极简：recall 把记忆文件整个作为上下文返回，save 完全不实现，工具只有「添加记忆」和「遗忘记忆」，改动后重新存到 blob 存储。

而第三方 SuperMemory 这类 provider 形态完全不同：它们可能不暴露任何工具，而是在确定性的 save 时机拿走消息历史、自己跑一个智能体流程决定存什么，recall 也是基于入站消息做智能体检索 。recall 在循环每一轮都会被调用，还在 compaction（上下文压缩）之后再次调用——因为压缩不保证保留你的记忆，像 SuperMemory 可以检查压缩后的内容决定是否重新注入。默认注入方式是追加 user 角色（避免打破提示词缓存），也可改成 system 角色，代价是每次增删都打破缓存。

自我进化则是另一条路：不像 Hermes 那类可以就地改自己代码再重启的东西，Eve 选择深度依托 Git——做一个可定义的编码子智能体，给它配好带代码库的沙箱和提示词，目标实际上是「让它对自身开 PR」。主持人和 Andrew 都认可这个模型的好处：监督级别完全由你配置——想让它自行合并就建自动化，想全走重度人工审查也一样配置。

愿景与边界

Andrew 的愿景是一条设计原则：「我们要押注模型会变得更聪明」。他们见过很多智能体框架纵向膨胀、代码越来越多、最后变成一堆确定性工作流 API、不太像智能体了；Eve 反向选择横向走——给模型提供更多东西（目录结构、skills、文档），让它自己做对决策 。

Char 的说法更激进：「创建公司就是在构建智能体」。EVE 比你的公司注册证书更根本——智能体早于你的网站、域名甚至公司注册；你从智能体开始，它逐步为你构建软件工厂，包括完整的软件开发生命周期，你的工作是微调那座工厂，而 EVE 有望成为公司未来的大脑 。

主持人立刻追问了 lock-in 问题。Andrew 回应：已有客户在 Kubernetes 上甚至自己的硬件上跑 Eve，靠的是 workflow 里「world」的抽象——只要能为你的基础设施定义一个 world（他们自己测试就跑 Postgres world、本地 world 等多种），就能自托管。记忆、自我进化这类能力的关键是尽早定好适配器契约——比如动态调度在 Vercel 上是一等公民，但自托管得自己引入实现——不能等它在 Vercel 上跑通之后才事后补 。

开源贡献模式上还有个真实的尴尬：测试套件要调用模型、真实部署项目、用一堆密钥，所以外部贡献的 PR 没法直接跑测试——他们得小心拉进沙箱确认无恶意，再以合著者名义用自己账号重新提交才能跑。他们内部甚至有 Eve 智能体每天分析这些 PR、挑出该接纳的。而整个 EVE 团队从三月到七月中旬其实只有两个人全职，刚又招了四人，现在工程侧约六人 。

本集带走

• 一个 instructions.md 就是一个智能体：Eve 用目录结构声明式定义智能体，配置编译成基础设施即代码，加 skills 得沙箱、加 schedules 得定时事件——平台只供给你用到的。
• skills 是渐进式披露：不用把所有上下文塞给模型，只给「何时该用」的提示，模型自己决定何时深入拉取；DZero 九成内容都是 skills。
• evals 当测试套件用：Eve 用自己的 eval 框架测 Eve，一天多次发版靠它兜底；确定性断言（工具被调用）+ LLM as judge（给 SQL 打分）两级都要有。
• 会话即工作流：每个会话对应一个可持久化、可恢复的工作流；靠「每次工具调用切换新函数」绕过无服务器 15 分钟超时，智能体可无限期运行。
• 权限分层做：频道层认身份、context 对象区分提问者与发起者、工具审批随渠道渲染、DefineDynamic 按调用者切换工具集——核心原则是把权限做成智能体之下的确定性层，别让模型猜用户 ID。
• 记忆用 provider 模式解耦：Eve 只确定性调用 recall/save/tools 三个钩子，简单文件 provider 和 SuperMemory 式的服务端智能体检索可以共存；默认追加注入以免打破提示词缓存。
• 自我进化走 Git 开 PR：智能体改自己靠编码子智能体对自身仓库开 PR，监督级别（自合并到全人工审查）由你配置。
• 押模型变聪明，不押框架变厚：框架横向走（给模型更多材料），避免长成满是确定性的工作流 API。

一个经典的例子是：你几乎永远不想要一个接收用户 ID 作为输入的工具调用。
So the classic example is you almost never want a tool call that takes in a user ID, for example.
—— Andrew Barba · [41:20]

对我来说，Eve 背后很早期的一条原则就是：我们要押注模型会变得更聪明。
Yeah, for me, I mean, one of the very early principles behind Eve was we’re going to bet on the models getting smarter.
—— Andrew Barba · [48:00]

我们见过的很多其他智能体框架是纵向扩展的——代码看起来越堆越多。
I think a lot of other agent frameworks that we had seen, they scaled vertically where they just appeared to get more and more code.
—— Andrew Barba · [48:11]

所以这个想法是：Eve 比你的公司注册证书更根本。
So the idea is that EVE is more fundamental than your certificate of incorporation.
—— Shar Dara · [49:03]

你的智能体早于你的网站、你的域名，甚至早于注册公司。
So your agent predates your websites, your domain name, and even incorporating the company.
—— Shar Dara · [49:09]