一个目录一个 Agent，Vercel Eve 的这套架构设计太舒服了！

Eve 值得关注但不是因为它又提供了一种调用大模型和 Tool Calling 的写法。它真正有意思的地方是把 Durable Workflow、Sandbox、人工审批、子 Agent、渠道接入、Tracing 和 Evals 这些过去需要开发者自己拼装的能力收进了一个文件系统优先的框架里。换句话说Eve 想解决的不是怎么让模型多思考几轮而是怎么把一个已经能工作的 Agent变成可以部署、可以暂停恢复、可以控制权限、可以观察和评测的生产系统这两个问题看起来很像工程量却完全不在一个级别。Agent Demo 很多真正能上线的却不多现在做一个 Agent Demo 已经不难了。写一个系统提示词准备几个工具调用模型让它在「思考—调用工具—读取结果—继续思考」之间循环一个能查数据、搜网页或者操作文件的 Agent 很快就能跑起来。但只要准备把它放进真实业务问题马上就来了一个任务跑了半小时中途进程重启怎么办Agent 等用户批准时连接要一直挂着吗模型生成的脚本敢不敢直接在应用服务器上执行查询日志可以自动做回滚生产版本是不是也能自动做同一个 Agent 要接 Web、Slack 和 API是不是每个入口都要重写一套Agent 做错以后怎么知道它当时看到了什么、调用了什么工具改了一句 instructions怎么确认旧能力没有悄悄退化这些问题没有一个能靠「再优化一下 Prompt」解决。过去大家通常要自己把模型 SDK、工作流引擎、任务队列、状态存储、沙箱、OAuth、审批页面、日志系统和评测框架拼起来。Demo 的代码可能只有几百行包住它的生产基础设施却很容易膨胀成另一个项目。这正是 Eve 选择切入的位置。Vercel 在发布文章中把 Eve 称为一个用于构建、运行和扩展 Agent 的开源框架并列出了 durable execution、sandboxed compute、human-in-the-loop approvals、subagents 和 evals 等内置能力。这份能力清单透露了一个很明确的信号Vercel 并不满足于提供一次模型调用它想把 Agent 的整个运行环境一起定义下来。Eve 最显眼的设计一个目录就是一个 AgentEve 的第一个特点是 filesystem-first。一个典型项目大致长这样my-agent/ └── agent/ ├── agent.ts # 模型与运行时配置 ├── instructions.md # 始终生效的系统指令 ├── tools/ # Agent 可以调用的类型化工具 ├── skills/ # 按需加载的操作手册 ├── subagents/ # 可委派任务的子 Agent ├── channels/ # HTTP、Slack、Discord 等入口 └── schedules/ # 定时任务最小的 Eve Agent甚至可以从一份instructions.md开始。需要选择模型时增加agent.ts需要调用业务接口时在tools/中增加 TypeScript 文件需要一套可复用的操作流程时写进skills/需要接入 Slack就增加一个 channel 文件。这个设计看起来不花哨却很符合工程直觉。Agent 的角色、工具、技能和入口都落在普通文件里意味着它们可以进入 Git 做版本管理通过 Pull Request 审查看到 instructions 修改前后的 diff对不同版本建立 Preview 环境出问题时回滚到上一个提交。Eve 官方说「The filesystem is the authoring interface」。翻成更直白的话就是不要再把 Agent 藏在某个控制台的一堆配置项里把它当成一个正常的软件项目来管理。这也是它和很多低代码 Agent 平台最不一样的地方。它不是用来替代 AI SDK 的看到这里可能有人会问Vercel 已经有 AI SDK为什么还要再做一个 Eve我的理解是两者解决的问题层次不同。Vercel AI SDK 更像底层开发工具帮助应用调用不同模型、处理流式输出、生成结构化数据以及完成 Tool Calling。Eve 则站在更外面一层。它假设 Agent 不只会调用一次模型而是一个可能运行很久、调用真实系统、等待人类输入、跨多个渠道工作的完整应用。可以粗略地理解成层次主要解决的问题模型与 AI SDK怎么调用模型、流式输出和工具Agent Loop怎么观察、行动、获得反馈并继续Eve这个 Agent 如何持久运行、安全执行、接入业务并进入生产Eve 底层本身也在使用 Vercel 的 AI Gateway、Workflow、Sandbox 和 Connect 等能力。它不是推翻现有 AI 开发栈而是把这些原语组合成一个约定更完整的 Agent 框架。如果借用最近比较流行的说法Eve 的重点不只是 Agent Loop更接近一套生产级 Agent Harness。模型负责推理但模型之外还需要状态、权限、工具、执行环境、反馈、审计和验证。Eve 想把这层 Harness 产品化。DurableAgent 不应该害怕重启普通聊天接口通常是一问一答请求结束任务也就结束了。Agent 却经常不是这样。它可能需要等待一个慢查询可能要让用户补充材料也可能在执行危险操作前等待审批。一次任务持续几个小时甚至几天并不奇怪。如果把这种任务绑在一个普通 HTTP 请求上超时、断线和进程重启迟早会找上门。Eve 的做法是把每段会话作为一个 durable workflow 运行。工作流步骤会被 checkpoint任务等待消息时可以暂停收到新消息后从原来的位置恢复。按照官方介绍即使中间发生崩溃或重新部署会话也可以继续推进。这项能力没有生成式 UI 那么吸睛却可能是 Eve 最重要的生产特性之一。因为真实 Agent 的核心问题从来不是能不能循环而是这个循环能不能在失败、等待和发布过程中保持正确状态。当然durable 也不是免费的魔法。工具有没有副作用、恢复后会不会重复执行、操作是否幂等仍然需要开发者设计。框架能保存执行状态却不能替业务代码决定「这笔退款到底能不能再调用一次」。Sandbox给 Agent 一台电脑但别让它住进应用服务器很多复杂任务无法提前准备好所有工具。比如让 Agent 分析一份陌生日志它可能临时写一段 Python让它处理 CSV它可能生成一个聚合脚本让它检查项目它可能执行 grep、测试命令或构建工具。真实计算环境能明显扩大 Agent 的能力边界也会同时扩大风险边界。模型生成的命令和代码应该被视为不可信输入。如果直接放进应用运行时执行一次错误的路径判断、依赖安装或者文件删除都可能把 Agent 问题变成生产事故。Eve 为每个 Agent 提供隔离沙箱。本地开发可以使用 Docker、microsandbox 或 just-bash 等适配器部署到 Vercel 后执行环境可以切换到 Vercel Sandbox而不需要改写 Agent 的业务逻辑。我很喜欢这个设计背后的态度不是禁止 Agent 写代码而是默认它写出的代码不值得信任。这是生产 Agent 应该具备的基本安全观。Approvals成熟的 Agent 要知道什么时候停手Agent 能调用工具不代表每个工具都应该自动执行。查询订单和取消订单不是一回事查看部署记录和回滚生产版本也不是一回事。Eve 内置了 human-in-the-loop approval。Agent 遇到需要人工确认的动作时工作流可以暂停用户批准或拒绝后再从当前状态继续。更重要的是审批不只存在于某个专用后台。Eve 的 channel 可以把审批映射到实际交互界面例如在 Slack 中显示按钮。这会迫使开发者认真回答一个问题Agent 的自动化边界究竟画在哪里一个实用的起点是读取与分析操作可以自动执行会修改外部系统的操作需要审批删除数据、回滚生产和大额付费等高风险操作需要更严格确认。真正成熟的 Agent不是什么都敢做而是知道什么时候必须停下来等人。