Vercel Eve：把 Agent 做成"文件系统优先"的开源框架
阅读时间: 大约 8 分钟
Vercel Eve：把 Agent 做成”文件系统优先”的开源框架
2026 年中，Vercel 在官方博客发布了开源 Agent 框架 eve，目标只有一句话：让”构建一个 Agent”这件事，像当年用 Next.js 写 Web 一样直接。Vercel 自己的定位相当直白——他们认为今天的 Agent 开发现状，相当于 Web 框架出现之前的石器时代：每个团队都在手写同一套持久化、沙箱、鉴权、可观测性的”管道工程”，而且这些代码无法在不同项目间复用。eve 就是把这套重复劳动抽象成框架的产物。本文基于 Vercel 官方发布博客与文档，对其设计与取舍做一次梳理。
一、核心抽象：一个 Agent 就是一个目录
eve 最有辨识度的设计是文件系统优先（filesystem-first）。官方给的示例是一个”数据分析师 Agent”，其目录结构如下：
agent/
├── agent.ts # 这个 Agent 用什么模型
├── instructions.md # 它是谁、按什么规矩行事
├── tools/
│ ├── run_sql.ts # 它能做什么
│ └── post_chart.ts
├── skills/
│ └── revenue-definitions.md # 它懂什么业务知识
├── subagents/
│ └── investigator/ # 它能委派谁
├── channels/ # 它部署到 Slack / Discord 等什么面
└── schedules/ # 它何时自动触发每个文件只描述 Agent 的一个侧面。开发者”扫一眼目录树”就能知道这个 Agent 是什么、能干什么、住在哪、何时自动行动。模型配置浓缩为一行：
import { defineAgent } from "eve";
export default defineAgent({ model: "anthropic/claude-opus-4.8" });instructions.md 则直接作为系统提示词，被 eve 自动拼接到每一次模型调用之前。官方称这种方式省去了”样板代码与管道维护”，开发者只需专注写 Agent 真正要做的事。
二、生产级能力：框架自带，而非自己拼装
Vercel 强调：Agent 是要在生产环境跑起来的，而生产所需的能力 eve 全部内置。可核对的官方能力清单如下：
| 能力 | 官方描述 | 工程含义 |
|---|---|---|
| 持久化执行（Durable execution） | 每轮对话都是一个持久化工作流，每一步都做检查点 | 会话可暂停、在崩溃或部署后从断点精确恢复 |
| 沙箱计算（Sandboxed compute） | Agent 生成的代码被视为不可信，隔离在独立沙箱中 | shell 命令、脚本、文件读写不污染宿主运行时 |
| 人工审批（Human-in-the-loop） | 任意动作可配置为需要人批准 | Agent 无限期挂起等待，且等待期间不消耗资源 |
| MCP / OpenAPI 连接 | 一个连接就是一个文件，指向 MCP server 或带 OpenAPI 文档的 API | 框架自动发现远端工具、代理鉴权 |
| 可观测与评估 | 内置 OpenTelemetry 追踪与评估框架 | 会话级 trace、Eval 开箱即用 |
连接鉴权是其中设计得较细的一环：eve 通过 defineMcpClientConnection 声明一个指向 Linear 等 MCP server 的连接，框架会自动发现远端工具、把工具列表交给模型、并代理鉴权——模型自始至终看不到连接的 URL 与凭据；交互式 OAuth 与 token 刷新由 Vercel Connect 处理。
三、背景动机：从 v0 到”人人都在造 Agent”
官方在博客中解释了做 eve 的动因：Vercel 自己做了多年 Agent，其中之一就是 v0。但当编码 Agent 让”造一个 Agent”变成任何人都能做的事之后，大家都在造。Vercel 内部由此发布了数百个 Agent 与内部应用，表面上是生产力革命，底下却是每个团队都在重建同一套管道，且无法跨用例沉淀。eve 的判断是：每一代软件，都是在足够多人”用笨办法把同一件事做过一遍”之后，才催生出它的抽象层——Agent 现在正处于这个时点。
四、评测与方法论的批判
需要清醒看待官方宣传口径的两点 nuance：
- “像 Next.js 一样”是类比而非性能证据。官方并未给出基准跑分、延迟或成本数据，Next.js 式的体验目前是设计目标，而非已被独立验证的事实。是否真的降低了 Agent 构建成本，仍需社区在真实项目中检验。
- 示例模型版本号是营销口径。官方
defineAgent({ model: "anthropic/claude-opus-4.8" })仅为示意，并不代表 eve 与该模型有深度绑定，也不代表默认推荐该模型；模型选择应按自身负载评估。
五、优势与局限
优势：
- 约定优于配置：目录即接口，新加入者读目录树即可理解 Agent，降低团队协作成本；
- 生产能力开箱即用：持久化、沙箱、审批、MCP、OTel、Eval 一体化，避免了自己拼装这些横切关注点；
- 安全默认值：Agent 代码隔离执行、凭据对模型不可见，符合最小权限原则。
局限：
- 与 Vercel 平台绑定较深：连接鉴权依赖 Vercel Connect、模型 fallback 走 AI Gateway。这意味着它能否成为跨厂商的事实标准，取决于社区接受度——这一点官方并未回避；
- 框架仍处早期：数百个内部 Agent 的经验是优势，但对外是全新开源项目，生态、文档完整性与第三方工具支持尚在建设；
- 文件系统优先有边界：对习惯了代码式编排（graph、状态机）的复杂多 Agent 流程，目录约定未必比显式编排更灵活。
六、适合谁用
- 已经在用 Vercel / AI Gateway 技术栈的团队：迁移成本最低，能直接吃到一体化红利；
- 需要快速把”一次性 Agent”沉淀为可维护项目的团队：目录约定让 Agent 从脚本进化为工程资产；
- 对持久化、审批、可观测性有硬性要求的生产 Agent 场景。
而对追求厂商中立、或需要高度定制编排逻辑的团队，建议先小规模试点，再决定是否押注。