说到先说我的判断，

Eve 可以关注。但不是因为它又提供了一种调用大模型和 Tool Calling 的写法。

它真正有意思的地方。是把 Durable Workflow、Sandbox、人工审批、子 Agent、渠道接入、Tracing 和 Evals 这些过去需要开发者自己拼装的能力，收进了一个文件程序优先的框架里。

换个角度Eve 想解决的不是：

而是的观点是。

这两个问题，看起来很像，工程量却完全不在一个级别。

Agent Demo 很多，真正能上线的却不多

现在做一个 Agent Demo 已经不难了。写一个程序提示词，准备几个工具，调用模型，让它在「思考—调用工具—读取结果—继续思考」之间循环。一个能查数据、搜网页或者操作文件的 Agent 很快就能跑起来。

但只要准备把它放进真实业务，问题马上就来了：

• 一个任务跑了半小时中途进程重启怎么办？
• Agent 等使用者批准时连接要一直挂着吗？
• 模型生成的脚本，敢不敢直接在应用服务器上执行？
• 查询日志可以自动做，回滚生产版本是不是也能自动做？
• 同一个 Agent 要接 Web、Slack 和 API，是不是每个入口都要重写一套？
• Agent 做错以后怎么知道它当时看到了什么、调用了什么工具？老实说，
• 改了一句 instructions。怎么确认旧能力没有悄悄退化？

这些问题没有一个能靠「再调整一下 Prompt」解决。怎么说呢，

过去大家通常要自己把模型 SDK、工作流引擎、任务队列、状态存储、沙箱、OAuth、审批页面、日志程序和评测框架拼起来。Demo 的代码可能只有几百行，包住它的生产基础设施却很容易膨胀成另一个项目。

这正是 Eve 选择切入的位置。

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 文件。

This design looks simple but aligns perfectly with engineering intuition.

• The role,tools,skills。and entrypoints are all ordinary files.
• You can version m in Git,review via Pull Requests,see diffs on instruction changes.
• Create preview environments per version;rollback on failure.

Eve 官方说「The filesystem is authoring interface」。翻成更直白的话就是：不要再把 Agent 藏在某个控制台的一堆配置项里把它当成正常的软件项目来管理。

它不是用来替代 AI SDK 的

I think Vercel AI SDK and Eve operate at different layers.

层次	主要解决的问题
模型与 AI SDK	如何调用不同模型并处理流式输出和工具调用
Agent Loop	如何观察行动并获得反馈继续循环
Eve	持久运行、安全执行而且可投入生产

Durable：Agent 不应该害怕重启

Durable Workflow 基础设施解释

普通聊天接口通常是一问一答，请求结束后任务也就结束。

Agent 却经常不是这样——可能等待慢查询。也可能让使用者补充材料，还可能在执行危险操作前等待审批。一次任务持续数小时甚至数天并不少见。

如果把这种长时间任务绑在普通 HTTP 请求上，就会遇到超时、中断或进程重启等挑战。

Eve 把每段会话作为 durable workflow 运行。工作流步骤会被 checkpoint；不过，当任务处于等待状态时可以暂停，到达新消息后从原位置恢复。即使中间崩溃或重新部署，会话仍可继续推进。

这项能力虽然不如 UI 那般吸睛。却可能是 Eve 最关键且最实用的一层——主要问题往往不是“循环是否可行”，而是“循环是否能在失败或等待中保持正确状态”。当然这也要求你考虑工具副作用和幂等性；框架只能保存状态，而不能决定业务逻辑是否应 执行退款等敏感操作。

Sandbox：为 Agent 提供隔离计算环境，而非直接跑到应用服务器

很多复杂任务无法提前准备好所有工具。例如让 Agent 分析陌生日志，它可能临时写 Python；让它处理 CSV，它可能生成聚合脚本；让它检查项目，它可能执行 grep 或建立命令。这些都扩大了能力边界，也放大了风险边界。

模型生成命令和代码应视为不可信输入。如果直接放到应用运行时执行，一条错误方法判断或依赖安装都可能导致生产事故。 说起来，

Eve 为每个 Agent 提供沙箱隔离。本地开发可使用 Docker / microsandbox / just-bash 等适配器；部署到 Vercel 时可以切换到 Vercel Sandbox，而无需改动业务逻辑。

我喜欢这个设计背后的态度： "不是禁止代码生成。而是假设其输出不可信任".

Approvals：成熟 Agents 必须知道何时停手

Agent 能够调用工具，但并非所有工具都该自动执行。例如查询订单与取消订单不同；查看部署记录与回滚生产版本亦不同。Eve 内置 human‑in‑‑loop approval。当遇到需要人工确认动作时工作流暂停；不过，使用者批准或拒绝后再从当前状态继续。审批可以映射到实际交互界面例如 Slack 按钮，让审批成为自然交互的一部分。这迫使开发者认真回答：

"Agent 的自动化边界究竟画在哪里?"

Subagents：不仅仅是“团队”概念

子 Agents 本质上也是目录，可以拥有自己的 instructions、tools 和 sandbox。主代理将其作为工具调用，在干净上下文中完成子任务，再将结果交回主代理。

子 Agents 的价值体现在两点：

• 拆分复杂任务以获得更清晰边界;
• 为不同子任务使用专属上下文与最小权限工具，从而减少风险与冲突。

Channels,Tracing 与 Evals——部署之后才是真正开始

默认提供 HTTP API。可通过 channel adapter 接入 Slack / Discord / Teams / Telegram / GitHub / Linear 等入口，同一份代理逻辑即可服务多个渠道，而非为每个聊天工具重写一次业务流程。

连接外部程序借助 Vercel Connect 自动处理 OAuth 授权与 token 刷新，让模型隐藏凭据细节。

每次模型呼叫还有沙箱命令均可被追踪。在 Vercel 上可通过 “Agent Runs” 页面查看完整会话过程。

最终评测——instructions 与技能文件都是代码库中的文件，一次无害修改也可能改变行为。Eve 提供评测功能，可在本地测试。也可集成 CI，把行为回归挡在发布之前。

Vercel 在产品页给出的类比很大胆：“像 Next.js 对 Web App 所做的一样”，但这次面向 Agents。Next.js 并未发明 React 或 SSR，而是把路由／建立／渲染／数据获取／部署等常见问题包装成约定好的框架。同理，Eve 将反复出现于所有 Agents 项目的结构固定下来——但目前仍处于 娱乐a 阶段。官方 README 明确提示框架与 API 会变化，需要时间验证环境规模及稳定性。至于更准确的是，Eve 已提出一种非常符合 Vercel 风格且实用的大纲。但是否成为领域规则，还取决于社区采纳情况。其实，

• 长期运行且需暂停恢复;
• 需运行脚本或处理文件;
• 集成 GitHub / Slack / Linear 等团队协作网站;
• 存在必须人工确认高风险动作;说起来，
• 想用 Git+Preview+CI 管理代理变更;话说回来，
• 已有 Vercel 技术栈。并愿意尝试 娱乐a API.

若仅想给现有接口添加一次简单问答，则直接使用 AI SDK 更轻便。不依赖私有化部署或已有成熟工作流网站，不宜急速搬迁主要业务至此新框架。

我们将围绕“帮助维护 SpringForAll 社区内容”展开，用 Eve 从零搭建一支 AI 内容维护团队。利用目录设计，每个岗位对应单独目录，多目录组成团队。至于第一阶段目标，

1. Create minimal working Eve agent & define role & boundaries;
2. Able to switch 娱乐ween own OpenAI-compatible provider outside AI Gateway;
3. Shoot skills for topic selection,drafting & review workflow;
4. Add researcher,writer。reviewer subagents to split responsibilities;
5. Create sandbox workspace for notes & drafts avoiding pollution of definition code.

该阶段不会连接公众号/GitHub/database，也不会自动发布内容。后续根据学习调整 Tools/Schedules/Evals 与 Vercel 部署方向进行迭代。下一篇我们先招聘第一位员工：“用单目录 + instructions + 本地对话创建 SpringForAll 的 AI 内容维护助手。”

• 从Vercel来看，Introducing eve
• Eve 产品页
• Eve GitHub 仓库

---