每日突破性工具推薦｜eve

今日推薦：eve

類型： AI Agent Framework／Durable Agent Runtime／Sandboxed Agent Infrastructure／TypeScript Framework
開發者： Vercel
首次公開預覽： 2026 年 6 月 17 日
主要語言： TypeScript + Markdown
授權： Apache-2.0
目前狀態： Beta／Public Preview，API 與行為仍可能在 GA 前調整

突破性：9.6 / 10｜架構創新：9.7 / 10｜Production 完整度：9.5 / 10｜Developer Experience：9.6 / 10｜目前成熟度：8.1 / 10｜生態潛力：9.8 / 10

今天推薦 eve。它不是因為 Agent Framework 這個類別缺少選擇，而是因為它提出了一個相當清楚、而且有機會改變 Agent 專案組織方式的核心抽象：

Agent 本身就是一個目錄，Filesystem 就是 Authoring API。

典型專案直接長成：

agent/
├── agent.ts
├── instructions.md
├── tools/
├── skills/
├── channels/
├── connections/
├── sandbox/
├── subagents/
└── schedules/

也就是說，eve 不要求你先理解一大套 Graph DSL、Registry、Dependency Injection 或 Runtime Builder。指令放在 Markdown、Tool 放在 TypeScript、子代理放在子目錄、排程放在 schedules；Framework 再把這些檔案編譯成一個可以長時間執行、暫停、恢復、部署與觀測的 Agent Runtime。

這個設計看起來簡單，但背後其實代表一個很重要的方向：Agent Framework 正從「提供 Agent Loop API」走向「定義 Agent Application Shape」。

一、工具定位與適用情境

eve 的定位不是單純的 LLM SDK，也不是只處理 Tool Calling 的 Agent Library。它更接近一套完整的 Backend Agent Framework，把 Agent 從開發到 Production 需要的基礎設施一起納入。

它處理的核心問題包括：

• Agent instruction 與 skill 的組織方式
• Typed tools
• Durable conversations
• Human-in-the-loop approval
• Sandboxed code execution
• Subagents
• Multi-channel delivery
• Schedules
• Tracing / OpenTelemetry
• Evals
• Deployment
• Self-hosting adapter

因此最適合的不是「一次性問答 Bot」，而是：

一個 Agent
↓
可能執行幾分鐘、幾小時甚至更久
↓
會呼叫真實工具
↓
可能需要人工批准
↓
需要跨 Crash / Deploy 保留執行狀態
↓
最後還要能測試、Trace、部署

這種 Production Agent。

二、突破性重點：Filesystem-first Agent Framework

大多數 Agent Framework 的 Authoring Model 是：

Application Code
↓
createAgent(...)
↓
registerTool(...)
↓
registerMemory(...)
↓
registerWorkflow(...)

也就是能力主要存在於程式碼與 Runtime Configuration 中。

eve 則反過來：

Filesystem
↓
Framework Discovery
↓
Compile
↓
Runtime

例如：

instructions.md

就是 Always-on System Instruction；

tools/get_weather.ts

檔名直接成為 Tool Name；

skills/revenue-analysis.md

就是可按需載入的 Skill；

channels/slack.ts

就是 Slack Channel；

subagents/investigator/

就是獨立 Specialist Agent。

這帶來一個很實際的好處：Agent 的能力可以直接被 Git、Code Review、Diff、IDE、Coding Agent 理解。

不需要先執行 Application 才知道 Agent 到底有哪些能力。

三、核心架構：Channel、Harness、Runtime 分離

eve 的架構不是把所有事情塞進單一 Agent Loop。

概念上可以理解成：

Incoming Message
      │
      ↓
   Channel
      │
      ↓
   Harness
      │
      ↓
   Runtime
      │
      ├── Durable Workflow
      ├── Tool Execution
      ├── Sandbox
      ├── Approval
      └── Streaming

其中：

• Channel：處理 HTTP、Slack、Discord、Chat surface 等輸入與輸出。
• Harness：負責一次 AI 工作單位，包含 Model、Tool、Skill 與 Agent 行為。
• Runtime：負責狀態、Durability、Workflow、Streaming 與長時間執行。

這種分層的價值是：

Transport
≠
Agent Reasoning
≠
Execution Durability

因此同一 Agent 可以掛到不同 Channel，而不需要重寫核心 Agent Logic。

四、Durable execution 是預設能力，而不是外掛

一般 Agent：

Model
↓
Tool A
↓
Tool B
↓
等待使用者
↓
Process Crash

如果沒有額外實作 Checkpoint，工作就可能消失。

eve 則把每段 Conversation 當成 Durable Workflow。

Conversation
↓
Checkpointed Step
↓
Tool Call
↓
Checkpointed Step
↓
Wait / Approval
↓
Suspend
↓
Resume

所以 Agent 可以：

• 等幾分鐘
• 等幾個小時
• 等人工核准
• 遇到 Deploy
• 遇到 Process Restart

之後繼續執行。

這個能力建立在 Vercel Workflow SDK 上，但 eve 把它直接提升成 Agent Framework 的預設語意。

五、這和一般 WorkflowAgent 最大的差別

你也可以直接使用 AI SDK 的 WorkflowAgent 來建立 Durable Agent。

差異在於：

WorkflowAgent
=
Durable Agent Primitive

而：

eve
=
Durable Agent Application Framework

WorkflowAgent 解的是：

如何讓 Agent Loop Durable

eve 再往上一層處理：

專案結構
Tool discovery
Skills
Sandbox
Channels
Subagents
Schedules
Tracing
Evals
Deployment

所以如果只需要一個可恢復的 Tool Loop，WorkflowAgent 更輕；如果需要完整 Agent Application Lifecycle，eve 更完整。

六、Sandbox 是 Framework 的 First-class Primitive

這是 eve 很重要的一點。

現在 Agent 越來越常做：

寫程式
執行 Bash
處理檔案
跑 Python
分析資料

而這些 code 很可能是 Model 即時生成的。

直接執行：

Agent-generated Code
↓
Application Process

風險非常高。

eve 的模型則是：

Agent Harness
      │
      ↓
Sandbox Adapter
      │
      ↓
Isolated Environment
      │
      ├── bash
      ├── files
      └── scripts

Production 可以使用 Vercel Sandbox；Local 可以使用 Docker、microsandbox 或其他 SandboxBackend。

所以 Sandbox 並不是特定 Vendor API，而是一個可替換 Backend。

七、這使 Agent 能安全取得「電腦」而不只是 Tool List

傳統 Tool Agent：

Tools:
- query_database
- search_docs
- calculate

Agent 能做的事情完全由預先定義的 Function 決定。

eve 則額外給 Agent：

Filesystem
Shell
Runtime

因此當沒有預先存在的 Tool 時，Agent 可以自己：

寫 Python
↓
執行
↓
產生結果

例如資料分析、轉換 CSV、產生圖表、建立一次性 Script。

這讓 Agent Capability 從：

Known Tools

擴張成：

Known Tools
+
General Compute

而 Sandbox 則負責把這種能力限制在安全邊界中。

八、Human-in-the-loop 與 Durable Runtime 是同一套模型

很多 Framework 把 Approval 當 UI feature：

Agent
↓
ask user
↓
等 response

但真正 Production 問題是：等待期間 Agent Process 怎麼辦？

eve 的模式是：

Tool Call
↓
Approval Required
↓
Workflow Suspend
↓
Process 可以消失
↓
Human Approves
↓
Resume

因此 Approval 不是 Session Memory 技巧，而是真正 Durable Runtime Primitive。

這很適合：

• merge PR
• deploy production
• 發送郵件
• 修改資料
• 金流操作
• 發布內容

這些不可逆 Action。

九、Subagent 的設計非常乾淨

在 eve 中，Subagent 仍然是同樣的目錄結構：

subagents/
└── investigator/
    ├── agent.ts
    ├── instructions.md
    └── tools/

Parent Agent 把它當成一個 Tool 呼叫。

重要的是 Child Agent：

• 有自己的 Context Window
• 有自己的 Instructions
• 可以有不同 Model
• 只取得授予它的 Tools
• 完成後把結果交還 Parent

這種模型避免所有角色共享同一個巨大 Context。

十、Skills 用 Markdown 處理「按需知識」

Agent 常見問題是 System Prompt 越堆越大。

例如：

Always-on Prompt
├── Revenue rules
├── Support rules
├── Security rules
├── Writing style
└── Deployment playbook

即使某次工作只需要其中一項，其他內容仍會進 Context。

eve 的 Skills：

skills/
├── revenue.md
├── deploy.md
└── support.md

只在需要時載入。

所以 Context Pattern 變成：

Small Core Instructions
+
Relevant Skill

而不是：

Everything in System Prompt

這對長期 Agent 的 Context 成本與可維護性都很重要。

十一、Multi-channel 不是後加 Integration

同一個 Agent 可以透過：

Web
Slack
Discord
Teams
API
Cron

等 Channel 使用。

架構是：

              Agent
                │
      ┌─────────┼─────────┐
      ↓         ↓         ↓
    Slack      Web       API

而不是每個 Channel 都重新包一層 Agent。

2026 年 7 月之後，eve 又加入 Chat SDK channel，可以直接利用 Chat SDK Adapter 接 Facebook Messenger、WhatsApp、Resend 等 Surface。

這對需要「同一個 Agent 多介面交付」的產品非常實用。

十二、Tracing 與 Evals 被當作 Agent Framework 的核心

Agent 出錯最大的問題是：

最後答案錯了

但原因可能是：

Prompt
Tool selection
Tool output
Sandbox command
Context
Subagent
Model

任何一層。

eve 每個 Run 都會產生 Trace，並使用標準 OpenTelemetry。

所以可以匯出到：

• Datadog
• Honeycomb
• Jaeger
• Braintrust
• Arize
• 其他 OTel Backend

同時 Evals 也是 Project File，可以檢查：

Agent 是否完成
是否呼叫某個 Tool
答案是否包含特定條件

並直接跑在 CI。

這代表 Prompt Change 可以和 Code Change 一樣被 Regression Test。

十三、Filesystem-first 對 AI Coding Agent 特別友善

這可能是 eve 最具長期影響力的部分。

Coding Agent 很擅長理解：

目錄
檔案
Markdown
TypeScript
Git Diff

但比較不擅長理解隱藏在 Dashboard、Database 或 Runtime Registry 裡的 Agent Configuration。

eve 把能力全部放回 Repository：

instructions.md
skills/
tools/
channels/
subagents/

因此 Coding Agent 可以：

讀 Repo
↓
理解 Agent
↓
新增 Skill
↓
新增 Tool
↓
跑 Eval
↓
Commit Diff

整個 Agent Development Lifecycle 都落在既有 Software Engineering Workflow 中。

十四、eve vs LangGraph

LangGraph 的中心抽象是：

Graph
↓
Nodes
↓
Edges
↓
State

它特別適合明確 Workflow、State Machine 與複雜 Branching。

而 eve 的核心抽象是：

Agent Directory
↓
Framework Compilation
↓
Durable Runtime

所以：

需要精確控制工作流程圖
→ LangGraph

想建立長期存在、可部署的 Agent Application
→ eve

eve 的優勢在「完整 Runtime 與 Application Shape」，LangGraph 的優勢在「顯式 orchestration」。

十五、eve vs Mastra

Mastra 是成熟度相當高的 TypeScript Agent Framework，提供 Agent、Workflow、Memory、RAG、Evals、Observability 等功能。

兩者最大的差異在 Authoring Philosophy。

Mastra：

Code-first Framework API

eve：

Filesystem-first Framework

Mastra 更適合需要大量程式化組合與 App integration 的專案；eve 則在「Agent 是可讀目錄、Runtime 自動組裝」這一點更加 opinionated。

十六、eve vs OpenAI Agents SDK

Agents SDK 更像：

Agent Primitive Library

重點是：

• Agent
• Tools
• Handoff
• Guardrail
• Tracing

它的優勢是薄、直接、容易嵌入既有 Application。

eve 則把：

Durability
Sandbox
Channels
Schedules
Evals
Deployment

一起納入 Framework。

因此：

只需要 Agent Logic
→ Agents SDK

需要 Agent Application Platform
→ eve

十七、eve vs Golem 類 Durable Runtime

Golem 類 Runtime 更底層，主要解：

Durable Execution
Exactly-once
WASM Isolation
Actor-style Runtime

而 eve 是更高一層：

Agent Project
↓
Framework
↓
Workflow Runtime / Sandbox

所以 Golem 是 Runtime-first；eve 是 Agent Framework-first。

如果需要極強的 execution semantics、跨語言 WASM runtime，Golem 類架構更底層；如果目標是 TypeScript 團隊快速建立 Production Agent，eve 更直接。

十八、主要優勢

1. Agent 專案非常容易理解

不用先學大量 Framework DSL，直接看目錄就知道 Agent 有什麼能力。

2. Durable by default

長時間工作、等待人類、Crash、Deploy 不需要自己拼 Checkpoint Infrastructure。

3. Sandbox 是 First-class

Agent-generated code 不必直接執行在 Application Runtime。

4. Production 能力整合度高

Durability、Approvals、Tracing、Evals、Channels、Schedules 都是同一 Framework。

5. Git-native

Prompt、Skill、Tool、Subagent 都可 Review、Diff、Rollback。

6. Coding Agent 友善

Framework Documentation 甚至直接隨 npm package 分發，Coding Agent 可以從 node_modules/eve/docs 讀取當前版本文件。

7. 可以 Self-host

官方目前已提供 Self-hosting Guide；Build 後會產生 Nitro Node Server，可以自行選擇 Workflow storage 與 Sandbox backend。

十九、缺點與限制

1. 仍是 Beta

這是目前最大的限制。

官方明確表示 Framework、API、Documentation 與 Behavior 在 GA 前仍可能調整。

因此現在不適合把大量 Mission-critical Agent Infrastructure 完全鎖死在現有 API 上。

2. Opinionated Framework

Filesystem-first 很乾淨，但也代表你要接受 eve 定義的 Project Shape。

如果團隊偏好：

全部由 Code 動態產生

或需要非常特殊的 Runtime Composition，會覺得限制較多。

3. Vercel 上體驗最好

雖然可以 Self-host，但 Vercel 部署可以直接利用：

• Sandbox
• Workflow
• AI Gateway
• Connect
• Observability

Self-host 時則需要自行準備對應 Infrastructure。

所以：

Portable
≠
Self-hosting 零成本

4. Self-host Runtime 仍較新

官方 Self-hosting 文件已存在，並有 Postgres Workflow World、Docker Sandbox 等參考實作，但這一塊明顯比 Vercel-managed path 更年輕。

如果要 High Availability、多租戶與嚴格 Production SLO，仍需要自行設計完整部署架構。

5. 不適合每一種 Agent

如果只是：

POST /chat
↓
LLM
↓
2 個 Tools
↓
Response

eve 可能過重。

AI SDK、OpenAI Agents SDK、Pydantic AI 等工具會更簡潔。

二十、適合哪些使用者或專案

特別適合：

• TypeScript Agent 團隊
• 長時間執行 Agent
• Coding Agent
• Data / Research Agent
• Internal Enterprise Agent
• Slack / Discord / Web 多 Channel Agent
• 需要 Human Approval 的 Agent
• 會執行生成程式碼的 Agent
• 需要 Evals + CI 的 Agent
• 希望 Agent Configuration 完全 Git-native 的團隊
• 想降低 Workflow、Sandbox、Tracing 拼裝成本的團隊

尤其是：

Agent 已經從 Demo
進入 Production Software

之後，eve 的價值會快速增加。

二十一、不適合哪些使用者或專案

目前不建議優先使用：

• 單純 Chatbot
• 簡單 RAG
• 一次性 API Tool Calling
• 非 TypeScript 團隊
• 需要非常精細 Graph DSL 的 Workflow
• 不需要 Durable Execution
• 完全不能接受 Beta API Change
• Self-host Infrastructure 不想自行維運的企業

二十二、為什麼今天值得推薦

eve 在 2026 年 6 月才正式公開，但目前已經快速形成一個相當完整的 Agent Application Framework：

Filesystem Authoring
+
Durable Workflow
+
Sandbox
+
Human Approval
+
Subagents
+
Channels
+
Schedules
+
Tracing
+
Evals

更重要的是，它背後的抽象非常清楚：

Agent 不只是一次 Model Call，而是一個需要被版本控制、測試、部署、觀測與長期執行的 Software Application。

因此 Framework 應該像 Web Framework 一樣，定義一個可預期的 Application Shape。

這也是 eve 最有潛力的地方。

簡短結論

如果 LangGraph 代表的是「把 Agent Workflow 變成 Graph」，Mastra 代表「把 TypeScript AI Application 能力整合到一套 Framework」，那 eve 更像是在嘗試建立：

Next.js for Agents

不是因為 API 長得像 Next.js，而是因為它試圖讓 Developer 只要遵循一個清楚的 Project Structure，就自動取得 Production Runtime 所需要的基礎能力。

目前最大的風險仍是 Beta API 穩定度與 Self-hosting 成熟度；但若它能把 1.0、第三方 Sandbox/Channel/Connection 生態與 Self-host Production Story 補完整，eve 很可能成為 TypeScript Agent 領域裡最具代表性的 Application Framework 之一。

現階段建議：

新 Agent PoC
→ 強烈值得試

Production Internal Agent
→ 值得評估

長時間 / Approval / Sandbox Agent
→ 非常適合

既有簡單 Chatbot
→ 不必為了 eve 重寫

Mission-critical Agent Platform
→ 可 PoC，但仍應等待 API 更穩定