影片筆記：Agent版Next.js来了？文件系统即Agent！拆解 eve

一句話總結

Resend 發布開源 Agent 框架 EVE，定位為「Agent 領域的 Next.js」，透過「文件系統優先」的設計理念，將目錄結構直接映射為 Agent 行為，並內建生產級基建（如持久化、沙箱隔離、人工審批），旨在解決當前 Agent 開發中狀態管理困難、安全隔離不足及基建重複造輪子的痛點。

核心重點

市場定位與痛點：

• 當前 Agent 框架（如 LangChain, AutoGen, MetaGPT, CrewAI）眾多，但生產環境面臨狀態丟失、安全隔離不足、基建重複（80% 時間處理持久化、審批、對接）等問題。
• EVE 類比 Next.js 出現前的 Web 開發，提供工程化解決方案。

核心設計：文件系統優先 (File System First)：

• 目錄即 Agent：目錄結構直接定義 Agent 行為。
• Agent.ts：配置模型。
• Instructions.md：系統提示詞。
• Tools/：放置 TypeScript 文件，文件名即工具名，自動發現並暴露給模型。
• Skills/：放置 Markdown 文件，定義業務規則或技能（如收入定義），模型按需加載。
• 優勢：消除「意大利麵條代碼」，降低認知負擔，結構直觀。

生產級基建內建：

• 持久化執行 (Checkpointed Workflow)：基於 Workflow SDK，記錄每一步操作。已完成步驟不重跑，崩潰或部署後可從確認步驟繼續。遇到人工審批或等待消息時，Session 暫停，不消耗計算資源。需注意 Tool 執行中斷開可能重跑，外部系統調用需做好冪等設計。
• 安全與沙箱隔離：Agent 生成和執行的代碼（Shell 命令、腳本、文件讀寫）放入獨立 Sandbox。開發者定義的 Tools 運行在應用 Runtime 中，可通過 ctx.getsandbox 調用沙箱。支援多種 Sandbox 後端（生產環境使用 versail sandbox，本地開發可使用 darker micro sandbox 或純 Bash）。
• 極簡 Human-in-the-loop 與多渠道分發：在 Tool 定義中加一行 needs approval 判斷（如 SQL 查詢超過 50GB 時暫停等待確認）。核心邏輯不變，通過 channels 目錄下的文件（如 slack.ts, discord.ts）接入不同平台，實現「Write once, run anywhere」。
• 定時任務：在 schedules 目錄下使用 Cron 表達式觸發同一個 Agent。

框架定位與開源屬性：

• EVE 的「重」在於兜底易出 Bug 的基建層，釋放開發者精力思考業務邏輯。
• 完全開源，基於 Apache 2.0 許可證。可自定義 Sandbox 後端和渠道集成。
• 將大模型包裝為可靠的工程組件，Agent 不再是腳本，而是具備穩定、安全、可追溯的工程系統。

實際應用案例與實踐：

• 電商客服 Agent 案例：傳統框架需自行處理數據庫連接、狀態管理等，耗時數週；EVE 框架僅需在 tools、channels、schedules 寫對應文件，耗時數天，自動處理基建。
• Resend 內部實踐：生產環境運行 100+ 基於 EVE 的 Agent，包括 D0 數據分析 Agent、銷售線索 Agent (Athena)、銷售 Cockpit、Vertex 支持 Agent、Draft0 內容 Agent、Vluo Agent 等，驗證了持久化、沙箱隔離、人工審批及多渠道能力。

未來趨勢與最佳實踐：

• 模型能力提升導致業務邏輯複雜化，多 Agent 編排（主 Agent 帶子 Agent）成為常態。
• 當前處於 Public Preview 階段，API 和行為在 GA 前可能變化。
• 最佳實踐：

寫好 Instructions：清晰、具體、有約束，避免空泛描述。

精心設計 Tools：單一職責，輸入輸出清晰，使用 Zod 定義 Schema。

利用 Skills：通過 Markdown 文件教導 Agent 做事。

充分利用 Human-in-the-loop：對重要操作加審批流。

監控與追蹤：利用 EVE 生成的詳細 Open Telemetry 追蹤信息，定期審查日誌。

詳細大綱

一、 背景與痛點：當前 Agent 開發的困境

• 市場現狀：市面上已有大量 Agent 框架（如 LangChain, AutoGen, MetaGPT, CrewAI），但 Resend 提出 EVE 為「Agent 領域的 Next.js」。
• 生產環境挑戰：
• 狀態管理：長期運行的 Agent 面臨網絡中斷、狀態丟失、對話歷史遺失等問題。
• 安全隔離：AI 生成的代碼（如 Shell 命令 rm -rf）不能直接運行在業務服務器上，需解決責任歸屬與隔離問題。
• 基建重複：開發者需花費 80% 時間處理持久化、審批流、企業內部系統對接（Slack, 釘釘等），而非核心業務邏輯。
• 類比：如同 Next.js 出現前的 Web 開發，團隊各自拼湊路由、打包工具和狀態管理。

二、 EVE 的核心設計理念：文件系統優先

• 目錄即 Agent：
• Agent.ts：配置模型。
• Instructions.md：系統提示詞（System Prompt）。
• Tools/ 目錄：放置 TypeScript 文件，文件名即工具名，構建時自動發現並暴露給模型，無需額外註冊。
• Skills/ 目錄：放置 Markdown 文件，定義業務規則或技能（如收入定義），模型按需加載。
• 優勢：消除「意大利麵條代碼」，降低團隊協作認知負擔，新人上手快，結構直觀。

三、 生產級基建內建

• 持久化執行（Checkpointed Workflow）：
• 基於 Workflow SDK，每一步操作被記錄。
• 已完成步驟不重跑，崩潰或部署後可從確認步驟繼續。
• 遇到人工審批或等待消息時，Session 暫停，不消耗計算資源。
• 注意事項：若 Tool 執行中被斷開可能重跑，因此外部系統調用需做好冪等設計或加入人工審批以保證數據一致性。
• 安全與沙箱隔離：
• Agent 生成和執行的代碼放入獨立 Sandbox（包括 Shell 命令、腳本、文件讀寫）。
• 開發者定義的 Tools 運行在應用 Runtime 中，可通過 ctx.getsandbox 調用沙箱。
• 安全邊界依賴：窄工具設計 + 權限控制 + 審批 + 冪等設計。
• 支援多種 Sandbox 後端：生產環境使用 versail sandbox，本地開發可使用 darker micro sandbox 或純 Bash。
• 極簡 Human-in-the-loop 與多渠道分發：
• 人工審批：在 Tool 定義中加一行 needs approval 判斷（如 SQL 查詢超過 50GB 時暫停等待確認）。
• 多渠道接入：核心邏輯不變，通過 channels 目錄下的文件（如 slack.ts, discord.ts）接入不同平台，實現「Write once, run anywhere」。
• 定時任務：在 schedules 目錄下使用 Cron 表達式觸發同一個 Agent。

四、 框架定位與開源屬性

• 重與輕的辯證：EVE 的「重」在於兜底易出 Bug 的基建層，釋放開發者精力思考業務邏輯。
• 非黑盒：完全開源，基於 Apache 2.0 許可證。
• 可自定義 Sandbox 後端（寫自己的適配器）。
• 可自定義渠道集成（用 Define Channel 自己寫）。
• 認知升級：Agent 不再是腳本，而是具備穩定、安全、可追溯的工程系統。EVE 將大模型包裝為可靠的工程組件。

五、 實際應用案例與實踐

• 電商客服 Agent 案例：
• 傳統框架：需自行處理數據庫連接、狀態管理、渠道適配、定時任務、錯誤恢復，耗時數週。
• EVE 框架：僅需在 tools 寫查詢與退款函數（加審批標記），在 channels 加文件，在 schedules 加定時任務，耗時數天，自動處理基建。
• Resend 內部實踐：
• 生產環境運行 100+ 基於 EVE 的 Agent。
• 具體應用：D0 數據分析 Agent（每月處理 3 萬+ 問題）、銷售線索 Agent (Athena)、銷售 Cockpit、Vertex 支持 Agent、Draft0 內容 Agent、Vluo Agent 等。
• 驗證了持久化、沙箱隔離、人工審批及多渠道能力。

六、 未來趨勢與最佳實踐

• 未來趨勢：模型能力提升導致業務邏輯複雜化，多 Agent 編排（主 Agent 帶子 Agent）成為常態。EVE 的「約定優於配置」模式提供參考方向。
• 當前狀態：Public Preview 階段，API 和行為在 GA 前可能變化。
• 最佳實踐建議：

寫好 Instructions：清晰、具體、有約束，避免空泛描述（如「你是有幫助的助手」），應定義具體角色和工作原則。

精心設計 Tools：單一職責，輸入輸出清晰，使用 Zod 定義 Schema。

利用 Skills：通過 Markdown 文件教導 Agent 做事（如寫 SQL 時避免 N+1 查詢）。

充分利用 Human-in-the-loop：對重要操作加審批流，提高安全性與用戶信任。

監控與追蹤：利用 EVE 生成的詳細 Open Telemetry 追蹤信息，定期審查日誌以發現問題。

工具 / 模型 / 名詞整理

• 框架/產品：
• EVE (Resend 發布的開源 Agent 框架)
• Next.js (被類比對象)
• LangChain
• AutoGen
• MetaGPT
• CrewAI
• Workflow SDK
• versail sandbox (生產環境沙箱後端)
• darker micro sandbox (本地開發沙箱後端)
• Open Telemetry (追蹤系統)
• 技術/標準：
• Apache 2.0 (許可證)
• TypeScript
• Zod (輸入 Schema 定義工具)
• Cron 表達式 (定時任務觸發)
• 平台/渠道：
• Slack
• Discord
• 釘釘 (DingTalk)
• Webchat
• 內部應用名稱 (Resend)：
• D0 數據分析 Agent
• Athena 銷售線索 Agent
• Sales Cockpit
• Vertex 支持 Agent
• Draft0 內容 Agent
• Vluo Agent

操作流程整理

初始化 Agent 結構：

• 創建 Agent.ts 配置模型。
• 創建 Instructions.md 撰寫系統提示詞。

定義工具 (Tools)：

• 在 Tools/ 目錄下創建 TypeScript 文件。
• 文件名即工具名（如 query_orders.ts, process_refund.ts）。
• 在 Tool 定義中可加入 needs approval 標記（如 SQL 查詢超過 50GB 時暫停等待確認）。
• 使用 Zod 定義輸入 Schema。

定義技能 (Skills)：

• 在 Skills/ 目錄下創建 Markdown 文件（如 Revenue Definitions.md, Howto write good sequel md）。
• 定義業務規則或技能，模型按需加載。

配置渠道 (Channels)：

• 在 channels 目錄下創建文件（如 slack.ts, discord.ts）接入不同平台。

配置定時任務 (Schedules)：

• 在 schedules 目錄下使用 Cron 表達式觸發同一個 Agent。

運行與監控：

• 生產環境使用 versail sandbox，本地開發可使用 darker micro sandbox 或純 Bash。
• 通過 ctx.getsandbox 調用沙箱執行代碼。
• 利用 EVE 生成的詳細 Open Telemetry 追蹤信息，定期審查日誌。

值得注意的限制或風險

Tool 執行中斷重跑風險：若 Tool 執行中被斷開可能重跑，因此外部系統調用需做好冪等設計或加入人工審批以保證數據一致性。

API 穩定性：當前處於 Public Preview 階段，API 和行為在 GA 前可能變化。

安全邊界依賴：安全邊界依賴窄工具設計、權限控制、審批及冪等設計，需開發者自行確保。

模型不確定性：雖有工程化包裝，但底層大模型仍存在不確定性，需通過清晰的 Instructions 和 Skills 進行約束。

逐字稿辨識疑點

• Resell / Rissel：逐字稿中交替出現「Resend」、「Resell」、「Rissel」，根據上下文應指同一公司，但需查證正確英文名稱（疑為 Resend）。
• NextDNJs / Nextdngs：逐字稿中出現「NextDNJs」和「Nextdngs」，疑為口誤或聽寫錯誤，應指「Next.js」。
• RM RF：逐字稿中出現「RM RF」，疑為 Shell 命令 rm -rf 的聽寫錯誤。
• Zo 的定義：逐字稿中出現「Zo 的定義輸入 Schema」，疑為「Zod 的定義」或類似工具名的聽寫錯誤。
• Deal 個 Markdown：逐字稿中出現「在 Skills 目錄下 Deal 個 Markdown」，疑為「放一個」或「寫一個」的口誤。
• Revenue Definitions.md：具體文件名，保留原樣。
• Query orderts：逐字稿中出現「tools query orderts」，疑為「query_orders.ts」或類似文件名的聽寫錯誤。
• Process 下劃線 refund ts：逐字稿中出現「tools process 下劃線 refund ts」，疑為「process_refund.ts」的聽寫錯誤。
• Schedules：逐字稿中出現「在 schedule s 目錄下」，疑為「schedules」目錄。
• Chrome 表達式：逐字稿中出現「用 chrome 表達式觸發」，疑為「Cron 表達式」的聽寫錯誤。
• Scammer：逐字稿中出現「用 zod 定義 scammer」，疑為「Schema」的聽寫錯誤。
• Howto write good sequel md：具體技能文件名，保留原樣。
• 為什麼叫 QQ：講者自我介紹，保留原樣。

可延伸追問

EVE 框架如何處理多 Agent 編排中的狀態共享與衝突解決？

在生產環境中，versail sandbox 的具體性能指標與成本結構為何？

對於非 TypeScript 生態的開發者，EVE 的學習曲線與適配難度如何？

EVE 的持久化機制在面對極高併發寫入時的擴展性如何？

人工審批（Human-in-the-loop）的介面與流程是否支援自定義 UI 或第三方審批系統？