很多團隊已經做出第一個 AI 代理（AI agent），真正卡住的是第二、第三個：每個專案都要重做狀態保存、工具註冊、權限、沙箱、頻道整合、觀測與評測。Vercel Eve 的新聞點就在這裡。Vercel 在 2026-06-17 推出 Eve，官方稱它是用來建置、執行與擴展代理（building/running/scaling agents）的開源代理框架（agent framework），而且 Vercel 內部也用它執行自家代理。
先給結論：Eve 值得工程團隊試，但不要把它當成「換個套件就能上正式環境（production）」的捷徑。它最有價值的地方，是把代理需要的檔案結構、持久執行（durable execution）、沙箱運算（sandboxed compute）、人工核准（human-in-the-loop approvals）、頻道、追蹤與評測放進同一套 TypeScript 專案慣例。對已經在 Vercel 技術棧（stack）上做 agent 的團隊，這會比從零拼執行環境更可控。
先回答：誰該今天就試 Eve？
| 團隊狀態 | 建議動作 | 原因 |
|---|---|---|
| 已經有 AI agent demo，準備接 Slack、GitHub、資料庫或內部工具 | 先開一個受控 PoC | Eve 的目錄慣例、核准、沙箱、評測，比自己拼代理迴圈（agent loop）更容易審查。 |
| 正在用 Vercel Workflows、Sandbox、AI Gateway 做長任務代理 | 把 Eve 當成上層框架評估 | 它把底層執行環境能力包成較完整的 agent 專案形狀，可和既有 Vercel agent stack 對齊。 |
| 只需要單回合聊天、簡單工具呼叫或客服 FAQ | 先用較輕的 AI SDK / Chat SDK / RAG 流程 | Eve 的持久 session、頻道、評測會增加工程面積。 |
| 有嚴格資料、權限、產業合規要求的企業 | 先做安全評估，不要直接接正式系統 | 代理可以執行工具、寫程式、接資料服務，權限、稽核與人審流程必須先設好。 |
Eve 的定位比較接近「正式代理（production agent）專案框架」。如果你的問題只是把模型接進頁面，它可能太重；如果你的問題是 agent 會跨工具、跨頻道、跨部署版本持續工作，它開始有意義。
Eve 的核心形狀：一個代理就是一個目錄
Vercel 的範例把 Eve agent 寫成這樣：
agent/
agent.ts
instructions.md
tools/
skills/
subagents/
channels/
schedules/這個設計的重點，是讓代理的模型設定、系統提示、工具、技能、子代理、頻道與排程都落在檔案系統裡。整齊只是表面；對工程團隊來說，真正價值是所有變更都可以被 Git、code review、CI 與回滾流程處理。
官方 README 也把 Eve 描述成「以檔案系統為作者介面（filesystem-first）」的持久代理框架。最小啟動方式是：
npx eve@latest init my-agent如果要加進既有專案，官方範例也提到可用 npm install eve@latest，再補 agent/agent.ts、agent/instructions.md 與工具檔。npm registry 在本文查核時顯示 eve package，描述為持久後端 AI 代理的 filesystem-first framework，license 欄位為 Apache-2.0；官方發布文則直接稱 Eve 是開源框架。
它補的是正式代理的哪些缺口？
Vercel 發布文列出的重點可以分成六類。
| 能力 | Eve 怎麼處理 | 導入時要驗證什麼 |
|---|---|---|
| 持久執行 | 每個 conversation 是 checkpointed workflow，可暫停、部署後續跑、從中斷處恢復。 | 長任務中斷、重試、版本切換時，狀態是否可預期。 |
| 沙箱 | agent 產生或執行的程式碼放在獨立 sandbox；部署時接 Vercel Sandbox，本機可用 Docker、microsandbox 或 just-bash adapter。 | 檔案讀寫、shell 指令、網路存取與祕密金鑰邊界。 |
| 人工核准 | tool 可設定 needsApproval，高成本查詢或破壞性動作可暫停等待人審。 | 哪些工具永遠需要核准，核准紀錄是否可稽核。 |
| 連接與權限 | connection file 可指向 MCP server 或 OpenAPI API，Vercel Connect 處理 OAuth consent 與 token refresh。 | 模型是否看不到 URL / credentials，使用者權限是否正確下放。 |
| 頻道 | HTTP API 預設存在，官方列出 Slack、Discord、Teams、Telegram、Twilio、GitHub、Linear 等 channel adapter。 | 同一個 session 在不同頻道切換時，權限與上下文是否一致。 |
| 追蹤與評測 | 每次 run 產生 OpenTelemetry trace；eval 可在本機或 CI 跑。 | 評測是否真的覆蓋核心任務，trace 是否能追到工具輸入輸出。 |
把這些能力組在一起，Eve 讓 agent 從單次模型呼叫走向可部署、可測、可回滾、可觀測的軟體系統。這也能接上 Mason 之前整理的 Agent Development Lifecycle：Build、Test、Deploy、Monitor 與 Governance 到最後都需要落進 repo 和部署流程。
費用、授權與部署邊界怎麼看？
Eve 的授權與成本要分開看。
- 框架本身：GitHub / npm metadata 在本文查核時顯示 Apache-2.0 license，README 也寫明 Eve 仍在 beta terms 下。開發者可以先把它視為開源框架加 public preview 產品，而非已完全穩定的長期 API。
- 部署平台：官方發布文寫到 launch 時 Eve deploys to Vercel，其他平台支援在路上；沙箱部署會接 Vercel Sandbox。若你的公司不能把 agent runtime 放在 Vercel，需要先確認 adapter、資料位置與合規要求。
- 模型與服務成本：Eve 可透過 AI Gateway 設 provider fallback，也可接 MCP / API 工具。實際費用會來自模型 token、sandbox 執行時間、Vercel runtime、外部 API、資料倉儲查詢與 OAuth 服務；Eve package 只是其中一層。
對採購或平台團隊來說，比較安全的問法是：Eve 能不能降低我們維護 agent runtime 的工程成本，同時讓風險、測試與觀測更清楚。若只是把 demo 包成正式產品，成本很可能從程式碼搬到權限、資料、評測與維運。
7 天試跑清單：先證明它管得住代理
不要第一天就把 Eve 接到正式資料庫或客戶系統。比較穩的節奏是先做一個可回滾、可觀測、低風險的內部代理。
- 第 1 天：跑通 scaffold。用
npx eve@latest init my-agent建專案，確認 dev server、terminal UI 與 HTTP API 可用。 - 第 2 天：寫最小工具。用
defineTool建一個只讀、無副作用的工具，例如查假資料或讀測試檔，確定 input schema 與錯誤處理。 - 第 3 天：加上核准規則。把高成本或敏感工具設成需要 approval，測等待、拒絕、核准後續跑是否穩定。
- 第 4 天：檢查沙箱邊界。讓 agent 寫並執行一段小程式，確認它不能碰不該碰的檔案、環境變數與網路位置。
- 第 5 天：補 eval。為最常見任務寫評測，至少檢查有沒有呼叫正確工具、是否遵守 instructions、失敗時會不會亂猜。
- 第 6 天：接一個低風險頻道。先接內部 Slack 測試頻道或 HTTP client，觀察 session、approval UI 與權限流。
- 第 7 天：部署與回滾演練。推一個 preview deployment，跑 eval / typecheck / 人工試用，再演練 rollback 與 trace 查錯。
如果這 7 天只能證明它「會回答」，還不能放進正式流程。至少要看到：權限邊界可審查、工具副作用被限制、eval 能擋回歸、trace 能還原失敗、部署回滾不會讓長任務卡死。
和既有 Vercel agent stack 怎麼分工？
你可以把 Eve 放在 Vercel agent stack 的較上層：
- AI SDK / AI Gateway：處理模型呼叫、provider fallback、成本與模型路由。
- Workflows：處理長任務狀態、retry、checkpoint 與排程。
- Sandbox：隔離 agent 產生或執行的程式碼。
- Eve：把 agent 的 instructions、tools、skills、channels、schedules、evals 與上述 runtime 能力組成一個可維護專案。
如果你已經在看 Vercel durable AI code agent 的三層架構，Eve 可以視為更完整的專案框架候選。若你正在評估程式碼執行邊界，也應該搭配 Vercel Sandbox 與 AI Gateway provider allowlist 的治理設計一起看。
導入前的風險清單
Eve 讓 agent 比較容易成為 production software，也代表它會更快碰到 production risk。導入前至少回答這幾題：
- 哪些工具只讀、哪些可寫、哪些需要永久禁用？
- 人工核准是誰按、在哪個頻道按、紀錄保存多久？
- 模型 provider fallback 會不會繞過公司的資料或區域要求？
- MCP server、OpenAPI connection 與 OAuth token 的權限是否跟使用者一致？
- sandbox 能否限制 shell、檔案、網路與 secret 存取？
- eval 是部署前門檻，還是只有 demo 時跑一次？
- 長任務遇到 deploy、rollback、timeout、工具失敗時，使用者會看到什麼？
這些問題比「Eve 有沒有更多 adapter」更重要。代理框架的價值，最後會落在能不能讓錯誤被限制、被觀測、被回滾。
參考來源
結論
Vercel Eve 的重要性在於，Vercel 把代理的檔案結構、持久執行、沙箱、人工核准、頻道、追蹤與評測包成同一套框架。這正好對準很多團隊從 demo 走向內部產品時會遇到的執行環境與治理成本。
Mason 的建議是先試、慢接、強驗證。用 7 天把最小代理跑通，證明工具邊界、approval、sandbox、eval、trace、部署與回滾都可控，再考慮接正式資料或客戶工作流。若你的需求仍停留在單回合聊天或簡單工具呼叫，先用較輕的 AI SDK / workflow；等真的需要跨頻道、長任務與可稽核代理，再把 Eve 放進候選清單。