Vercel 開源 eve：把 Agent 框架做成檔案系統

在 Production 環境上跑 Agent，最頭痛的往往不是 Prompt 寫得不夠精準，而是 State（狀態）怎麼保存？任務跑一半 Network 斷線或重開機，有沒有辦法 Resume？多個 Agent 協作時，程式碼要怎麼拆才不會變成一坨義大利麵？Vercel 最近開源的 eve (The Framework for Building Agents)，給出了一個很不一樣的答案：Filesystem-first (檔案系統優先)。

它的思路很直覺：不要把 Agent 的能力全部揉進一個超大的 Configuration 檔案裡，而是把每個能力拆回專案的實體目錄。你只要看一下專案結構，就知道這個 Agent 能做什麼、怎麼跑、哪些模組可以擴充。

官方 Repo 把它定義為 The Framework for Building Agents，不過 README 也特別說明：eve 目前仍處於 Beta 階段，框架結構、API 設計與運作行為在正式發布前都還有可能調整。

eve 在解什麼問題？

大部分的 Agent 框架一開始寫起來都很像 Demo：

• 能在 Terminal 裡對話。
• 能呼叫簡單的 Tool。
• 能打個 API 接外部服務。

但如果真的要在專案裡落地，問題很快就會浮現：

• Session 的 State 怎麼持久化？
• 任務中途斷掉，要怎麼從中斷點恢復？
• Tool 執行時，中間的進度如何 Real-time Stream 給前端？
• Human-in-the-loop (人工審核) 的關卡要插在哪裡？
• 怎麼同時接 Slack、Discord 和 Web API？
• 複雜的大任務如何拆解成 Sub-tasks？

eve 想解的就是這些維運痛點。它不打算教你怎麼寫更漂亮的 Prompt，而是直接提供一個可持久化、可恢復、可追蹤的 Agent Runtime。

檔案系統就是你的開發者介面

eve 最有辨識度的特色，就是把 Agent 的能力直接與檔案路徑綁定。

一個典型的專案目錄大概長這樣：

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

這是 eve 專案的標準目錄結構，它將 Agent 的 System Prompt、自訂 Tools 與子任務的 Subagents 分門別類放在不同的資料夾中，讓開發人員光看樹狀圖就能掌握 Agent 的所有能力邊界。

• instructions.md：存放全域生效的 System Prompt。
• agent.ts：用來載入 LLM Provider、定義模型參數與設定 Runtime。
• tools/：存放強型別的 Tools 實作。
• skills/：存放特定任務流程的說明文件，只在需要時延遲載入。
• channels/：定義跟外界溝通的 Entrypoints（如 HTTP、Slack、Telegram）。
• sandbox/：受保護的安全沙箱環境。
• subagents/：放可委派的子 Agent (Subagents) 設定。

這種設計的好處是：目錄結構本身就是你的 Spec 文件。你不用翻找複雜的程式碼或資料庫設定，看一眼 Git 樹狀圖就知道這個 Agent 有多少料。

內建一組實用的 Runtime 工具

eve 不只是幫你包一個 Tool-calling loop，它本身就內建了許多開箱即用的工具：

• 檔案操作：bash、read_file、write_file、glob、grep。
• 網路檢索：web_search。
• 任務追蹤：todo。
• 互動引導：ask_question。
• 任務委派：agent (用來呼叫子任務)。
• 按需載入：load_skill。

這意味著你只要把 Runtime 起起來，它就已經具備了修改程式碼、檢索網頁與向人類發問的能力。

在這之中，我認為有三個架構設計非常關鍵：

1. Durable Sessions (持久化會話)

eve 把每次互動都當成一個長週期的 Session，而不是單次的 Request-Response。它引入了 continuationToken 與 sessionId 機制。你可以隨時中斷 Agent 的執行，或是把它丟到背景排程，等到拿到人類審核的 Token 後，再 Resume 繼續往下跑，完全不需要每次都從頭執行一遍。

2. Lazy-loaded Skills (技能延遲載入)

把一堆 SOP 流程硬塞進 Prompt 不僅浪費 Context Token，還容易讓模型失焦。在 eve 裡，skills/ 目錄下的文件只有在 Agent 判斷需要時，才會透過 load_skill 載入到 Context 中。

3. Subagents as First-Class Citizens

eve 將 Subagents 視為一等公民。你可以把複雜的大型 Workflow 拆給不同的 Subagents，每個 Subagent 都能有自己專屬的 Prompt、Tools、獨立的 Sandbox 甚至自己底下的子 Agent。比如讓 A 負責看 Code 做 Research，B 負責改 Code，C 負責跑 Linter 與 Test，最後由 A 來彙整輸出。這種分工方式比單一 Agent 扛全部工作要穩健得多。

多元 Channel 整合

eve 把 Channel 視為核心概念。除了預設的 HTTP API 入口，它還支援原生對接：

• Slack
• Discord
• Telegram
• Teams
• Twilio
• GitHub / Linear

這代表它不只想做網頁聊天機器人，而是能直接潛入你現有的開發工具鏈。同一個 Agent，可以透過 Web API 呼叫，也可以在 GitHub PR 下面留 comment 被觸發，或者在 Slack 頻道裡被 @，底層共享的都是同一套 Session 狀態與工具集。

快速起步

要在本機跑起來其實蠻快的，直接在 Terminal 下指令：

npx eve@latest init my-agent

這行指令會透過 npx 直接下載並執行 eve 的腳本，自動幫你在 my-agent 目錄下起一個乾淨的 Agent 專案，並安裝好 Node 依賴套件。

最簡設定只需要 agent/instructions.md 和 agent/agent.ts 這兩個檔案。目前官方的預設模型是 anthropic/claude-sonnet-4.6，並且 Node.js 環境要求在 Node 24 以上。如果是透過 AI Gateway 呼叫，要記得填入 AI_GATEWAY_API_KEY；直接呼叫 provider 則需要填入對應的 API Key。

軟體工程的視角

如果用一句話來定位 eve：它正努力把 Agent 從「隨性調整的 Prompt + Tool」轉化為「可被版本控制與維護的軟體專案」。

當我們把 Agent 搬上線時，最怕的就是黑盒子與失控。eve 把這些行為、權限、工具與子 Agent，通通對應到實體檔案與資料夾，讓團隊能透過 Git 來審查 Agent 的改動。它回答了一個目前 AI 應用開發最核心的問題：當 Agent 逐漸變得複雜時，底層的軟體架構到底該長什麼樣？

Vercel 的答案很明確，就是檔案系統。

參考來源

• vercel/eve GitHub repo
• eve README
• Introduction Docs
• Getting Started Docs
• Tools Overview
• Subagents Docs