「一个 AI 智能体就是一个文件夹」Vercel 开源 Eve

今天打开 GitHub，刷到 Vercel 新开源的一个 agent 框架，叫 Eve。

我本来是没打算细看的。这两年 agent 框架多到我已经麻了，LangChain、AutoGPT、CrewAI、各种各样的 orchestrator，每一个都说自己重新定义了智能体开发。看多了就有种钝感，约等于每周都有人跟你说他发明了新的轮子，而你家车库里已经堆了二十个轮子，没一个能装上去跑。

但 Eve 的 README 第一屏有句话让我停了一下。

「一个 agent 就是一个文件夹。」

就这么一句。我盯着看了几秒，然后做了件平时很少做的事，把仓库 clone 下来，真的去 ls 了一眼它的示例目录。

好家伙，看完我有点想跟你唠唠。

先说我是干嘛的，免得后面聊到一些细节你觉得我在装。我日常的活儿，说人话就是给大模型搭脚手架，让模型能在真实环境里干活的那层工程，agent 的工具链、评测、调度、上下文怎么塞。所以「agent 框架」这种东西对我不是新闻概念，是我天天打交道、天天被坑的那个东西。正因为天天被坑，我对一个框架好不好用，有点过敏式的敏感。

回到 Eve。

你想想看，平时我们怎么定义一个 agent？

通常是这样的。你打开一个 Python 文件，import 一堆东西，然后开始 register。注册工具，注册记忆模块，注册路由逻辑，注册回调。一个稍微复杂点的 agent，光是把这些零件拼起来的胶水代码就能写两三百行。更糟的是，这些东西散落在代码各处，工具定义在这个文件，prompt 在那个 yaml，调度逻辑藏在某个 decorator 里。三个月后你自己回来看，都得花半天重新理一遍这玩意儿到底在干啥。

我跟你说，这种「一个 agent = 一坨注册代码 + 散装配置」的模式，是我最大的怨念之一。

Eve 的思路反过来了。它说，别注册了，文件系统本身就是你的接口。官方原话是 The filesystem is the authoring interface，文件系统就是创作界面。

我给你看一眼它一个 agent 长啥样，

agent/
├── agent.ts          模型和运行时配置（可选）
├── instructions.md   系统提示词，永远生效（必需）
├── tools/            模型能调用的函数
│   ├── run_sql.ts
│   └── post_chart.ts
├── skills/           按需加载的流程和知识
│   └── revenue-definitions.md
├── channels/         接到哪，HTTP、Slack、Discord
│   └── slack.ts
├── schedules/        定时自己跑
│   └── monday-summary.ts
└── subagents/        派活给子 agent
    └── investigator/

你不用看任何代码。光是这个目录树，你就已经知道这个 agent 是什么、能干什么、跑在哪、什么时候会自己动起来。

tools/ 里有 run_sql.ts 和 post_chart.ts，哦，这是个会查数据库、会发图表的 agent。channels/ 里有 slack.ts，哦，它接在 Slack 上。schedules/ 里有 monday-summary.ts，哦，它每周一会自己生成个总结。subagents/ 里有个 investigator，哦，碰到要深挖的活儿它会甩给一个专门的调查子 agent。

这套信息，你过去得读完整个代码库才能拼出来。现在 tree 一下就齐了。

我第一反应是，这不就是把约定优于配置（convention over configuration）这套老哲学，搬到 agent 上了吗。

对，就是这个。Rails 当年用这套思路干掉了 Java 那种到处写 XML 配置的繁琐，约定好目录结构和命名，框架自己去发现、去装配，你少写一大堆样板代码。Eve 干的是一模一样的事，只不过对象换成了 2026 年的 AI agent。文件在 build 的时候被自动发现（auto-discovered），你加一个工具就是往 tools/ 扔一个文件，不用回到某个中心文件里再 register 一行。官方管这叫 No boilerplate，没有样板代码。

棒棒的，这一下就戳到我了。

我们再往细里看一个工具长啥样。比如你要给 agent 加个查天气的能力，就在 tools/ 下建个文件，

import { defineTool } from "eve/tools";
import { z } from "zod";

export default defineTool({
  description: "Return mock weather data for a city.",
  inputSchema: z.object({ city: z.string().min(1) }),
  async execute({ city }) {
    return { city, condition: "Sunny", temperatureF: 72 };
  },
});

干净到有点过分。一个 description 告诉模型这工具干嘛，一个 zod schema 卡住输入，一个 execute 写实际逻辑。完事。你不需要去任何别的地方声明「我这里有个工具叫 get_weather」，文件在那儿，它就被发现了。

agent 本体更简单，

import { defineAgent } from "eve";

export default defineAgent({
  model: "anthropic/claude-sonnet-4.6",
});

模型那一行直接写 anthropic/claude-sonnet-4.6，它示例里还出现过 anthropic/claude-opus-4.8。框架号称 Works with any model, any MCP server，啥模型都行，啥 MCP server 都能接。这点挺关键的，没把你锁死在某一家。

启动也不墨迹，一行 npx eve@latest init my-agent 就给你拉个骨架，从零到跑起来官方说 under a minute，一分钟内。文档甚至直接塞在 node_modules/eve/docs 里，装完包文档就在本地，不用开浏览器翻。

聊到这你可能会想，那这不就是个把代码换成文件夹的语法糖嘛，花架子，中看不中用。

我一开始也这么怀疑。说真的，agent 框架圈最不缺的就是 demo 漂亮、上生产稀碎的东西。一个 agent 在你笔记本上跑通五分钟，跟它在真实流量里稳定跑五个月，中间隔着的不是一条河，是太平洋。

而恰恰是这块，让我对 Eve 多看了两眼。

它内置了六个生产级能力，我挨个跟你说，因为这才是真正干活的人会关心的部分。

第一个，持久执行（durable execution）。这个我必须展开讲，因为它是我日常踩坑最多的地方。

你想象一下，一个 agent 正在处理一个跑了二十分钟的长任务，调了五六个工具，中间还在等一个外部 API 回数据。这时候你的服务重启了，或者你刚好推了个新版本上线，进程没了。传统做法下，这个会话就死了，用户那边对话框一片寂静，你这边日志里只剩一句冷冰冰的 connection reset。

Eve 的做法是，每一次对话都是一个可持久化的 workflow，每一步都打 checkpoint（检查点，相当于游戏里的存档点）。会话可以暂停、可以在崩溃或者重新部署之后存活下来、然后从它停下的那一步继续往下走。底层是基于 Vercel 自己开源的 Workflow SDK 做的。

我看到这段是真的愣了一下。因为「agent 跑一半进程没了怎么续上」这个问题，我自己在工作里是手搓过解法的，超时看门狗、状态落库、失败重试、断点恢复，每一样都得自己写、自己调、自己半夜被告警叫起来 debug。现在人家直接把这套当成框架的地基给你铺好了。

第二个，沙箱计算（sandboxed compute）。Eve 把 agent 生成的代码当成不可信的东西来对待，每个 agent 都有自己独立的沙箱，去跑 shell 命令、执行脚本、读写文件。

这个设计我举双手赞成。模型生成的代码你敢直接在生产环境裸跑吗？我反正不敢。让模型自己写脚本自己执行，听着很酷，但凡你想到它可能 rm -rf 点什么，或者把你的环境变量打包发出去，你就笑不出来了。隔离是底线，把这个底线做进框架，是负责任的。

剩下四个我快一点。人机审批（human-in-the-loop approvals），在关键动作前插一道人工闸门，比如 agent 要发邮件、要花钱、要改数据库之前，先停下来等你点个头。子智能体（subagents），把任务派给专门的子 agent，复杂活儿拆开干。评测（evals），内置测试机制，让你能量化「我改了这版 prompt，到底是变好了还是变差了」，而不是靠感觉。还有安全连接（secure connections），托管你 agent 对外的连接。

你把这六个摆一起看，会发现 Eve 真正想解决的，根本不是「怎么定义一个 agent」，而是「怎么把一个 agent 安全、可靠、可恢复地放到生产里长期跑着」。前者是个玩具问题，后者才是要命的工程问题。

据 Vercel 官方博客的说法，这套东西是他们内部实际在用的框架，社交媒体上有人转述说 Vercel 内部跑着 100 多个 AI agent 用的就是这一套（这个数字是二手转述，我没法替你核实，姑且听之）。如果属实，那这就不是又一个实验室玩具，是从真实生产线上扒下来开源的。这两者的分量完全不一样。一个被真实流量、真实故障、真实 oncall 反复捶打过的框架，跟一个为了发 paper 或者刷 star 攒出来的框架，气质上是藏不住的。

The New Stack 给 Eve 的标题是 treats agents as directories，把 agent 当目录来对待。我觉得这个概括很到位，但还不够。它真正的野心是，把 agent 从「一段需要专家才能读懂的代码」，变成「一个产品经理 tree 一下都能看懂的文件夹」。

这件事的意义，可能比它表面看起来要大。

我一直觉得，一个技术范式真正成熟的标志，不是它变得多强，而是它变得多「无聊」、多「显然」。当年写网页要手搓一堆东西，后来变成约定好的目录结构往里填。当年部署要登服务器敲命令，后来变成 git push 完事。每一次「变无聊」，背后都是把一类专家才懂的复杂度，下沉成了所有人都能用的约定。

agent 现在可能正站在这个门槛上。

过去两年，做 agent 是一件需要你同时懂模型、懂工程、懂一堆框架黑话的事，门槛高得吓人。而 Eve 这种「一个 agent 就是一个文件夹」的设计，骨子里就是在尝试把这道门槛踩平。它在说，你不需要理解我背后那套 workflow 引擎、沙箱隔离、checkpoint 机制是怎么实现的，你只需要知道，工具放 tools/，技能放 skills/，定时任务放 schedules/。剩下的脏活累活，框架替你扛了。

当然，我得泼盆冷水，免得你觉得我在给 Vercel 打广告。

约定优于配置这套哲学，好处和坏处是一体两面的。约定省心，是因为它替你做了决定。可一旦你的需求长歪了，长到框架的约定之外，那种「我明明知道该怎么做，但框架不让我这么做」的憋屈，会比从零手搓还难受。Rails 当年被人吐槽得最多的，就是「你要么完全照它的方式来，要么处处跟它打架」。Eve 会不会有同样的问题，现在下结论太早，得真的拿它扛几个月生产流量才知道。

而且 evals、durable execution 这些东西，框架给你提供了能力，不等于你就自动拥有了可靠性。评测得你自己写，checkpoint 的粒度得你自己设计，沙箱的权限边界得你自己拿捏。工具把地基打好了，楼盖得歪不歪，还是看施工的人。这点我得说在前头，别指望装个包就上生产无忧，那是不存在的。

但即便如此，我还是愿意为这个方向鼓个掌。

写了这么些年代码，我越来越相信一件朴素的事，好的抽象，是把复杂留给自己，把简单交给别人。Eve 把 agent 那些最磨人的生产级难题（崩了怎么续、代码乱跑怎么隔离、改了 prompt 好没好怎么量化）吞进了框架内部，然后在外面给你留了一个干净到一眼能看懂的文件夹。

这让我想起 Unix 那条老到掉牙但永远正确的哲学，一切皆文件。键盘是文件，屏幕是文件，进程是文件，网络连接也是文件。把万物统一成一个最简单、最通用的抽象，于是整个系统变得可组合、可理解、可掌控。几十年过去，现在有人站出来说，agent 也是文件夹。

某种程度上，这是同一种信仰的延续。在一个什么都恨不得包装成黑盒、包装成「智能」、包装成你看不懂所以你得付费的时代，还有人愿意相信，最好的东西应该是透明的、是你 ls 一下就懂的。

我挺吃这一套的。

如果你最近也在折腾 agent，被各种框架的胶水代码和玄学配置搞得头大，真的建议你去 npx eve@latest init 跑一个骨架出来，哪怕就是 tree 一下看看它的目录长啥样。你不一定要用它，但那个「原来 agent 可以这么清爽」的瞬间，值回那一分钟。

Eve 的 GitHub 仓库在这，官方文档在这，发布的 changelog 在这。Apache-2.0 协议，放心用。

航行这么久，见过太多号称要颠覆一切的新大陆，最后发现是块画在海图上的幻岛。但偶尔，你也会撞见一座结构清晰、灯塔亮着、一眼就知道怎么靠岸的小岛。

Eve 给我的感觉，是后者。