又冒出一个AI Agent框架。但这次，Vercel 交出的 Eve 走了一条很少有人走的路——它把代理的全部配置、指令、工具、技能、子代理、通信渠道、定时任务，统统塞进了一套文件系统。你不需要写注册代码，不用手动拼接胶水层，只需要按约定的目录结构丢一堆 Markdown、TypeScript 文件上去，构建阶段框架就能自动发现它们，让代理“活”起来。这种以文件系统为核心的架构，像给开发者递了一本填色本，每一页都是一个功能，填好即用。
细看 Eve 的设计，有几个点藏着明显的产品算计。第一，它拒绝让你凭空继承一堆抽象类。代理的行为靠 Markdown 指令定义，工具是 TypeScript 文件，可复用的知识封装成 skill 目录，子代理独占一个子目录。构建时，Eve 自动扫描并暴露这些资源，开发者的手离开了注册和装配的代码。第二，一个代理同时挂载 Slack、Discord、Teams、Telegram、GitHub 甚至 HTTP API，却不用改动核心实现——所有渠道适配在通信层解决，这种解耦方式显然吸取了消息机器人维护的教训。
生产场景不可绕过的三个坑，Eve 一并给出内置解法：持久化执行、沙箱隔离、人工审批。每个对话会话存为持久的工作流，可以中断、容忍故障，甚至熬过一次部署，再从最后完成的步骤恢复。代理生成的代码一律跑在隔离沙箱里，本地开发可以用 Docker，生产直接切到 Vercel Sandbox。而一旦需要人工确认，审批流直接嵌在工作流步骤里，不用外挂。这种闷声把 infra 做进框架的脾气，确实能省掉不少自建轮子的痛苦。
集成层也摊得很开。Eve 一发布就带着 Slack、GitHub、Snowflake、Salesforce、Notion、Linear 等连接器，底层靠开放 API 规范（OpenAPI）和 Model Context Protocol 服务器挂接外部服务。更彻底的是，你只要写好自定义适配器，想接哪个服务都行。这意味着代理不再是一座信息孤岛，而是可以钻进工单系统读上下文、在数据仓库里跑查询、在聊天频道里回消息的那种“员工”。
可观测性这块，Eve 没有另搞一套私有标准，直接上了 OpenTelemetry。每一次模型调用、工具调用、沙箱命令执行，都生成一条 trace，能导出到已有的监控平台，也能在 Vercel 自己的可观测界面里查看。配合 eval 评测套件，你可以在本地或 CI 管道里验证代理行为，再部署上线。这背后的逻辑很清楚：生产级代理，如果没有可复现、可度量的质量检查，就是盲飞。
子代理和定时任务的组合拳则把自动化往前推了一步。开发者可以给专门的任务建独立子代理，自带指令、工具和运行环境，父代理只负责分派任务、回收结果。配合基于 cron 表达式的定时触发，代理就能周期性地自动做数据分析、客服应答、内容审核这类重复劳动。Vercel 自己已内部跑着上百个生产代理，覆盖分析、客服、销售运营、内容审看等场景，显然已经把 Eve 当成了自己的干粮。
严格来说，Eve 没有发明新范式，它就是重新排列了那些已知的基础件，但排列的方式恰恰瞄准了今天 AI Agent 落地的死穴：从原型到生产，中间要补太多基础设施。文件系统即架构这件事，让团队内的非核心开发者也能快速看懂代理的构成，协作边界变得像代码仓库一样清晰。而这次的公开发布，Vercel 还配了一条 CLI 脚手架，一条命令就能初始化一个新代理项目。
热门跟贴