Vercel eve：当 Agent 不再是代码，而是一个目录

2026 年 6 月 17 日，Vercel 发布了开源 Agent 框架 eve。不是又一个"更好的 LangChain"，而是一种完全不同的 Agent 构建思路。

TL;DR

1. 问题：Agent 框架的"千层饼"困境

2025 年是 Agent 框架爆发年。LangGraph、CrewAI、OpenAI Agents SDK、Google ADK、Anthropic Agent SDK……每个框架都试图解决同一个问题：让 Agent 开发更快、更可靠。

但它们有一个共同的起点假设：Agent 是代码。

LangGraph 把 Agent 定义为状态图（StateGraph），CrewAI 把 Agent 定义为角色对象，OpenAI SDK 把 Agent 定义为模型调用链。这些抽象各有道理，但都带来一个结果：你必须"读代码"才能理解一个 Agent 是什么、能做什么、部署在哪里。

Vercel 内部在 2025 年就经历了这个痛苦——他们构建了上百个 Agent，每个都有自己的状态管理方式、凭证管理方式、日志格式。看起来是生产力革命，实际上每个团队都在重复造轮子。

eve 的起点假设不同：Agent 应该像网站一样，"看一眼就知道它是什么"。

2. 核心差异：文件系统即 API

2.1 主流框架：显式注册

# LangGraph
from langgraph.prebuilt import create_react_agent
agent = create_react_agent(model, tools=[sql_tool, chart_tool])
 
# CrewAI
agent = Agent(
    role="data_analyst",
    goal="回答团队数据问题",
    tools=[sql_tool, chart_tool]
)
 
# OpenAI Agents SDK
agent = Agent(
    name="data_analyst",
    instructions="你是高级数据分析师...",
    tools=[sql_tool, chart_tool]
)

每个框架都有自己的注册语法。工具要 import，要传参，要手动维护列表。Agent 的能力清单散落在代码各处。

2.2 eve：隐式发现

agent/
├── agent.ts              # 配置模型（一行代码）
├── instructions.md       # 系统 prompt
├── tools/
│   ├── run_sql.ts        # 文件名 = 工具名
│   └── post_chart.ts
├── skills/
│   └── revenue-definitions.md  # 按需加载的知识
├── channels/
│   └── slack.ts
└── schedules/
    └── monday-summary.ts

没有 add_tool()，没有 register()，没有 import 列表。把 run_sql.ts 放进 tools/ 目录，eve 在构建时自动发现并注册它。文件名就是工具名，目录位置就是能力类型。

这和 Next.js 的哲学一脉相承：约定优于配置。Next.js 让文件夹=路由，eve 让文件=Agent 能力。

2.3 为什么这很重要？

文件系统是人类最熟悉的"数据库"。我们管理文档用文件夹，管理代码用目录，管理知识也用目录。eve 把这个直觉搬到了 Agent 构建中。

3. 生产是内置的，不是外挂的

3.1 其他框架的"生产拼装"

以 LangGraph 为例，构建一个生产级 Agent 你需要：

核心框架（LangGraph）
  + 部署方案（LangServe / 自建 FastAPI）
  + 状态持久化（Redis / PostgreSQL）
  + 沙箱（自建 Docker / 云函数）
  + 可观测性（LangSmith 或接入 OpenTelemetry）
  + 人工审批（自建审批流）
  + 评估框架（LangSmith evals 或自建）

每一层都是一个技术决策，每一层都需要集成和维护。

3.2 eve 的"开箱即生产"

eve 把以下能力全部内置为框架原语：

这不是"我们帮你接好了这些工具"，而是这些能力是 Agent 的一等组成部分，和工具、技能、渠道并列。

3.3 一个具体例子：Human-in-the-loop

// agent/tools/run_sql.ts
export default defineTool({
  description: "Run a read-only SQL query against the warehouse.",
  inputSchema: z.object({ sql: z.string() }),
  
  // 一个字段，决定是否需要人工审批
  needsApproval: ({ toolInput }) => estimateScanGb(toolInput.sql) > 50,
  
  async execute({ sql }) {
    const { columns, rows } = await runReadOnlySql(sql);
    return { columns, rows: rows.slice(0, 500) };
  },
});

其他框架做同样的事情需要：定义审批中间件 → 注册到 Agent 循环 → 实现暂停/恢复机制 → 对接通知渠道。eve 只需要一个布尔表达式。

4. 渠道是一等公民，不是事后接入

4.1 传统做法

1. 构建 Agent 核心逻辑
2. Agent 能跑了
3. 想接 Slack → 写 Slack 适配器
4. 想接 Discord → 再写一个适配器
5. 每个渠道都是独立集成项目

4.2 eve 的做法

agent/channels/
├── http.ts        # 默认自带
├── slack.ts       # eve channels add slack（一行命令生成）
├── discord.ts     # eve channels add discord
└── telegram.ts

而且 session 可以跨渠道迁移——在 Slack 问的问题，可以到 web 界面继续。HTTP webhook 触发的事件可以打开 Slack 调查线程。

思路差异：其他框架把 Agent 当成"住在某个 IM 里的 bot"，eve 把 Agent 当成"存在于任何用户所在的地方的服务"。

5. 更深层的设计哲学差异

5.1 Agent 的"本体论"不同

这不是"谁更好"的问题，而是起点假设不同，导致整套抽象体系不同。

LangGraph 的起点是"如何建模 Agent 的推理过程"，所以它的核心是图。CrewAI 的起点是"如何模拟团队协作"，所以它的核心是角色。eve 的起点是"如何让 Agent 像网站一样可维护"，所以它的核心是文件系统。

5.2 对"开发者体验"的理解不同

其他框架的 DX 焦点：写代码时的体验。类型提示、IDE 补全、流式输出。

eve 的 DX 焦点：理解、维护、协作时的体验。看目录知道 Agent 能力，看 diff 知道改了什么，看 trace 知道发生了什么。

这是两种不同层次的 DX。前者优化的是"写出第一个 Agent"，后者优化的是"维护第一百个 Agent"。

5.3 对"生产"的理解不同

其他框架："我们帮你构建 Agent，生产部署是你的事"。

eve："Agent 本身就是生产软件，框架应该从第一天就为生产设计"。

体现在：

• 部署：不是"部署到你的服务器"，而是 vercel deploy，和 Next.js 项目一样
• 版本控制：Agent 的每个组件都在 Git 里，prompt 变更是 commit，有 diff、有 review、有 history
• 回滚：Vercel 的 instant rollback 直接适用
• CI/CD：eve eval 作为部署门禁，回归检测在 CI 里完成

6. Vercel 的内部实践

eve 不是纸上谈兵，Vercel 自己已经在生产环境跑了一百多个 Agent：

这些 Agent 从不同的技术栈迁移到 eve 后，共享同一套工具、同一套约定、同一套可观测性。一百个 Agent 用和一个 Agent 相同的方式运行。

7. 局限性和适用场景

局限性

适用场景

• 已经在用 Vercel 的团队：部署零摩擦
• 需要多渠道 Agent 的产品：渠道是一等公民
• Agent 数量多、需要统一管理：文件约定天然适合 monorepo
• 重视工程规范的团队：Git-native、CI/CD、trace 全内置

不太适合的场景

• 纯 Python 数据科学团队：TypeScript 门槛
• 快速原型验证：CrewAI 可能更快
• 深度定制 Agent 推理流程：LangGraph 的图模型更灵活
• 不想绑定云平台：Hermes 自托管更自由

8. 和 Hermes 的对比

作为日常使用的 Agent 框架，Hermes 和 eve 有不少设计共鸣：

两者的核心差异：Hermes 是"我的 AI 助手"，eve 是"我们的 Agent 产品"。前者强调个人效率，后者强调团队协作和生产可靠性。

9. 总结

eve 的真正创新不在于它做了什么新功能，而在于它重新定义了"Agent 是什么"：

• 不是代码对象，而是文件目录
• 不是工作流图，而是软件产品
• 不是 AI 实验，而是生产服务
• 不是一个框架，而是一种工程约定

这和 web 开发的历史遥相呼应。在框架出现之前，每个网站都是手写 HTML + CGI 脚本。Next.js 的出现不只是"更好的工具"，而是**"网站应该长这样"的约定**。eve 对 Agent 领域做的事情，可能就是 Next.js 对 web 做过的事情。

当然，eve 还在 beta，还有很多局限。但它的设计方向值得所有 Agent 开发者关注——当 Agent 从实验走向生产，我们需要的不只是更好的 API，而是更好的工程范式。

参考链接：

• eve 官方文档
• GitHub 仓库
• Vercel 博客：Introducing eve