Vercel eve 与智能体的形状

Vercel 在 2026 年 6 月 17 日的 Ship London 上发布了 eve，一个用于构建 AI 智能体的开源框架。它的核心主张是：智能体就是一个目录。指令、工具、技能、渠道、定时任务，全部是文件系统里的一棵树，框架读取这棵树，校验清单，然后运行结果。

发布稿里的原话是"Next.js for agents"。这是同一家公司在用自己最成功的产品做对比。这个类比值得认真对待，原因也正是如此。但同样值得审视，因为上线一个智能体最难的部分，通常不是框架能解决的部分。

这篇文章拆解 eve 真正改变了什么、它刻意留给构建团队去做的部分，以及 Senrok 在内部是如何思考是否采用它的。

eve 要解决的问题

过去三年里，几乎所有智能体框架都长得差不多。引入一个库，实例化一个 agent 类，把工具注册成被装饰的函数，再写一些胶水代码来持久化状态、重试工具调用、暴露日志，最后把它包装成一个长跑进程部署出去。"智能体"存在于运行时。你找不到一个规范的文件，可以指着它说"这就是那个智能体"。

这种做法在第一个智能体上是工作的。第二个智能体开始，同样的脚手架再次出现，只是略有不同。等到第三个、第四个智能体的时候，公司里每个团队都在维护自己那一份持久化执行、沙箱、审批、追踪的实现。这些实现没有一份可以复用。脚手架是一样的，但实现没有一份是共享的。

eve 的主张是：这些脚手架已经收敛到可以标准化的程度。结构是一样的，与智能体做什么无关，所以框架可以拥有这个结构，让团队专注于智能体执行的实际工作。这就是这个赌注。

智能体就是目录

eve 里最与众不同的选择，是文件系统优先的模型。没有一个庞大的配置对象。智能体就是目录，每种能力都有一个明确的归宿。

agent/
  agent.ts                  # 模型 + 运行时配置
  instructions.md           # 系统提示词、人格
  tools/                    # 每个 .ts 文件是一个工具
  skills/                   # 按需加载的 markdown 剧本
  subagents/                # 可委派的子智能体
  channels/                 # Slack、Discord、HTTP 等
  schedules/                # cron 风格的触发器
  connections/              # MCP、OpenAPI、OAuth 接入
  sandbox/                  # 每个智能体独立的运行时

最小可运行的智能体只需要两个文件：一个模型声明和一个系统提示词。

import { defineAgent } from "eve";
 
export default defineAgent({
  model: "anthropic/claude-opus-4.8",
});

# Identity
 
你是一名高级数据分析师，负责回答团队的数据问题。
 
- 能算出精确数字就不要含糊。如果可以算，就直接算。
- 任何报告的数字都要说明背后的假设（时间范围、过滤条件、粒度）。
- 优先使用可用的工具，不要猜。如果数据答不上来，就直说。

要增加一项能力，就是在正确的文件夹里放一个文件。工具是一段有类型的 TypeScript 文件，技能是一份 markdown 剧本，渠道是一个适配器，定时任务是一个 cron 表达式加一个处理函数。没有单独的注册步骤。目录就是契约。

import { defineTool } from "eve/tools";
import { z } from "zod";
import { runReadOnlySql } from "../lib/sample-db";
 
export default defineTool({
  description: "对 orders 和 customers 表执行只读 SQL 查询。",
  inputSchema: z.object({
    sql: z.string().describe("一条只读的 SELECT 语句。"),
  }),
  async execute({ sql }) {
    const { columns, rows } = await runReadOnlySql(sql);
    return { columns, rows: rows.slice(0, 500), truncated: rows.length > 500 };
  },
});

超越审美，这件事为什么重要

"文件系统优先"看起来像是一个组织上的偏好，但它的影响比这深得多。

智能体变得可 diff

对智能体的修改是一个 commit，而不是埋在 Python 模块里的代码变更。一个团队可以以一行 PR 的形式审查"这个智能体现在可以访问 delete-customer 工具了"。工具描述、系统提示词、周一报表的新定时任务，全部和代码库一起被版本化。这就是让 package.json 和 package-lock.json 成为可能的那个性质，也是让一个前端 PR 可以顺带捎上一个智能体变更的那个性质。

技能变得可导入

技能就是一个 markdown 文件。一个团队可以把 refunds.md 从一个智能体复制到另一个，可以 fork 一个第三方智能体然后改三个文件，也可以发布一个技能库，直接放进任何 eve 项目。复用的单位是文件，不是代码依赖。

团队之间的约定可以传承

当公司里每个智能体都长成同样的形状时，相同的运维工具就能作用于所有这些智能体。同一个 trace 查看器，同一个 eval 运行器，同一条部署流水线。第二个智能体的成本远低于第一个，第十个的成本还会更低。这是这个赌注里影响最深远的部分。

eve 自带了什么

一个框架的价值，等于它吸收了多少生产关注点。下面是 eve 声称开箱即要处理的事项，以及每件事背后的工程现实。

持久化会话

每个会话都是一个持久化工作流，每一步都打了检查点。一个会话可以暂停，扛过一次崩溃或部署，从它停下的位置精确恢复。在底层，eve 使用开源的 Workflow SDK 来保证会话可恢复、幂等、防崩溃。

这件事从零开始构建是真的难。大多数尝试的团队最终都会在 Postgres、一个队列和一大堆 try/catch 之上写一个状态机。把它内建起来，是对工程表面积的实质性缩减。

沙箱化算力

智能体生成的代码应当被当作不可信输入处理。eve 把它完全排除在应用运行时之外：每个智能体都拥有自己的沙箱，一个隔离的环境用于 shell 命令、脚本和文件操作，运行在与控制智能体的宿主不同的安全上下文里。

默认后端在生产环境是 Vercel Sandbox，本地开发用 Docker、microsandbox 或 just-bash。适配器模式意味着团队不会被锁定在单一供应商上。

对于一个还没有处理过"能跑 bash 的智能体的安全审查"的团队来说，这是最能让人睡个好觉的部分。对于已经在生产环境跑智能体的团队来说，本地开发的故事才是让框架在日常工作中真正可用的那部分。

人机协同审批

任何工具都可以被配置为需要审批，智能体会在这里暂停并等待 —— 必要的话可以无限期地等下去，不消耗算力。一旦获批，eve 从它停下的位置继续往下走。

import { defineTool } from "eve/tools";
import { z } from "zod";
import { runReadOnlySql, estimateScanGb } from "../lib/sample-db";
 
export default defineTool({
  description: "对数仓执行只读 SQL 查询。",
  inputSchema: z.object({ sql: z.string() }),
  needsApproval: ({ toolInput }) => estimateScanGb(toolInput.sql) > 50,
  async execute({ sql }) {
    return runReadOnlySql(sql);
  },
});

语义是准确的。审批是工具的一个属性，而不是一个独立的工作流构件。智能体不需要知道它的哪些工具需要审核。框架在那些需要的地方暂停，把请求呈现给运维，等 webhook 到了再恢复。

这与 Senrok 对审核节点的看法一致：它们应该出现在不可逆的节点上，应该由明确定义的条件触发，不应该不必要地阻塞工作流。eve 把这三件事的机制都内建了。

子智能体

子智能体就是同一种形状，再深一层。subagents/ 下的一个目录，有自己的指令、工具和沙箱。父智能体调用它的方式与调用一个工具完全相同，子智能体从一个干净上下文窗口启动，只携带被授予的工具。

import { defineAgent } from "eve";
 
export default defineAgent({
  description: "在分析师汇报之前，先调查数据中的异常。",
  model: "anthropic/claude-opus-4.8",
});

这是把复杂智能体拆成可维护小块的正确原语。风险和任何多智能体系统一样：父与子可能在某个步骤由谁负责的问题上看法不一致，失败模式并不总是显而易见的。清晰的形状有帮助，但不能消除设计上的功夫。

追踪与评估

每次运行都会产生一个 trace。每一个模型调用和工具调用按顺序出现，连同输入输出，再到智能体在沙箱里执行的命令。这些 span 是标准的 OpenTelemetry，可以导出到任何追踪服务 —— Braintrist、Raindrop、Arize、Honeycomb、Datadog 或 Jaeger。评估（eval）是带评分的测试套件，可以在本地跑，也可以接入 CI。

import { defineEval } from "eve/evals";
import { includes } from "eve/evals/expect";
 
export default defineEval({
  description: "分析师按照团队规则回答营收问题。",
  async test(t) {
    await t.send("上周的营收是多少？");
    t.completed();
    t.calledTool("run_sql");
    t.check(t.reply, includes("扣减退款后"));
  },
});

这是框架中回本最快的部分。追踪把"智能体做了件奇怪的事"变成一个有输入、输出和时序的具体 span。评估把一次提示词的改动从赌博变成一道 CI 门禁。

eve 刻意没有解决的部分

框架对自己的边界是坦诚的，但值得把采用之后仍然留在团队工作清单上的事明确列出来。

编排策略仍然是你的事

eve 提供了循环、持久化、沙箱、审批机制。它不决定 哪些 工具存在、何时 智能体应该升级处理、什么 在你具体的工作流里算低置信度答案。这些策略写在你写的工具里、你写的指令里、以及你为模型设定的边界上。一个没有在策略上投入的团队采用 eve 之后，最终会得到一个跑得快、追踪得好、行为却很糟糕的智能体。

模型仍然是那个模型

eve 通过 Vercel AI Gateway 路由，这意味着跨供应商的回退、重试和可观测性都得到了处理。它不能把一个非确定性的模型变得确定。本系列文章里关于智能体系统的每一个假设仍然成立：模型有时会出错，系统需要能检测到这一点，恢复路径不能依赖模型永远不出错。

集成仍然是那份工作

eve 在发布时为 Slack、GitHub、Snowflake、Salesforce、Notion 和 Linear 提供了连接器，再加上一个通用的 MCP 和 OpenAPI 桥接，覆盖其它所有服务。框架会发现工具并代理鉴权。但它不会替你写业务逻辑。run_sql 工具仍然需要知道哪条 Postgres 连接字符串是合适的、允许智能体查询哪些表，以及如何以一种框架无法推断的方式强制行级安全。

智能体周围的系统仍然是那个系统

Vercel 说有 100 多个自家智能体跑在 eve 上，框架是让它们一致的原因。让它们正确的，仍然是构建它们的团队的工作：它们读取的数据层、它们强制执行的权限、它们要求的人工介入节点，以及在用户察觉之前捕获回归的 eval 套件。eve 缩减了一致性的成本，没有取代工程。

思考是否采用它

评估 eve 的正确方式，取决于你已经拥有的智能体团队类型。

你正在上线你的第一个智能体

eve 是一个合理的默认。本地优先的开发循环很快，生产端的故事已经被照顾到了，项目的形状和工作的形状是一致的。框架足够有主见，你可以少花时间在脚手架上，把更多时间放在智能体真正的工作上。选错框架的代价很低，因为项目还小。

你在生产环境已经有两三个智能体

这是最有趣的情形。你已经有了 eve 提供的绝大部分脚手架，但它们分散在三个不同的代码库里，由三个不同的团队维护，没有一份是一致的。eve 不是一个免费的迁移。它是一个整合的机会，而这种迁移最有价值的时候，是你决心把整个舰队迁过来、而不是同时维护两套系统。为这次迁移规划一个季度，而不是一个 sprint。

你在评估自建 vs 复用的决策

eve 是开源且可自托管的，在这个相关意义上它更接近"自建"而不是"复用"。你拥有部署、升级路径和运维风险。这个赌注是：跨智能体的标准化值得超过失去的灵活性。对于一家拥有三个或更多内部智能体的公司，这个赌注通常是划算的。对于一家只拥有一个智能体的公司，在第二个智能体出现之前就学习这套框架的认知开销，很难说得过去。

你已经在严肃规模上运行智能体

到了一定体量，被锁定的担心会变成现实。框架是 Apache-2.0 的，Workflow SDK 是开源的，AI Gateway 是托管服务。沙箱的运行时适配器意味着底层算力是可替换的。这些都不改变以后迁移出这个框架的成本。但它们确实把那个成本限制在了一个可量化的范围内 —— eve 不是一个有围墙的花园，一个有决心的团队可以替换它的任何一个部分。

这对智能体生态意味着什么

eve 有意思的地方不是框架本身，而是它指向的方向。

第一波智能体框架，是给开发者提供可以调用的原语。LangGraph 给你一张图，CrewAI 给你角色，OpenAI 的 SDK 给你工具调用。它们是你引入的库。

第二波是给团队提供一种形状。智能体是一个目录。工具是一个文件。技能是一份 markdown 文件。框架读取这棵树，校验清单，然后运行结果。复用的单位是文件，审查的单位是 PR。运行的单位是目录，一致性的单位是形状。

这就是 Next.js 在 Web 上做成的事。它不是构建网站的唯一方式，但是它让一家公司里一百个小前端读起来像一个代码库。如果 eve 对智能体做成了同样的事，胜出的智能体不会是最聪明的那些，而是那些让团队能用第一个的成本交付第十个的那些。

我们在用它做什么

在 Senrok，我们为那些工作流具有真实后果的公司构建生产级智能体系统：核保、合规审查、内部请求路由、客服运营。我们的模式是 Sense · Reason · Rock 循环，在每一个不可逆的节点都有确定性检查和人工介入节点。

我们用评估任何一个新框架的方式来评估 eve：不是看它能不能跑一个 demo，而是看它能不能在我们客户关心的运维条件下撑得住。持久化会话、沙箱、审批原语、OpenTelemetry 导出，这几样直接对应我们已经具备的生产要求。文件系统优先的模型改变了团队如何在一段智能体的生命周期里协作，而这正是大部分长期成本所在。

诚实的答案是：我们还不知道 eve 会不会成为我们智能体项目标准化的那个框架。我们知道的是，它要解决的问题 —— 同样的脚手架在每个团队里重新构建 —— 是我们过去三年一直在手工解决的同一个问题。如果这个框架在真实负载下站得住，是否采用它的答案就是显然的。我们正在关注早期的生产部署，一旦有来自直接运维经验的结论，会再写一篇。