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 最显眼的设计：一个目录就是一个 Agent
Eve 的第一个特点是 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 产品化。
Durable：Agent 不应该害怕重启
普通聊天接口通常是一问一答，请求结束，任务也就结束了。
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 遇到需要人工确认的动作时，工作流可以暂停；用户批准或拒绝后，再从当前状态继续。
