他們把 AI agent 定義成一個資料夾，然後賭模型會越來越聰明
TL;DR
- 一千個人同時對同一個 agent 丟 prompt，本機跑的那種 agent 會直接趴掉。EVE 的整個設計出發點就是這個場景。
- 在 EVE 裡，一個 agent 就是一個資料夾。最小可運作版本只要一個
instructions.md，其他能力靠固定命名的子目錄疊上去。 - 這些檔案會編譯成一份 manifest，平台再照著 manifest 開對應的基礎設施。你有寫 skills 才給你 sandbox，你有排程才給你排程系統。
- evals（評測）在 EVE 裡是一等公民，連 EVE 自己的測試套件都是用 evals 寫的，這是他們敢一天出好幾版的底氣。
- 記憶跟自我進化的做法很克制：agent 要改自己，是去開一個 PR，你決定要不要合。
- 產品負責人丟了一句很大的話：「開公司就是建 agent」，agent 會比你的網域名稱跟公司登記還早存在。這句話值得討論，但也該打點折。
這集在講什麼
這集是 2026 年 9 月 17 日播出的 Software Engineering Daily。這是一個做了十幾年的老牌軟體工程訪談節目，每集找一個在做特定系統的人來把細節挖乾淨，風格偏工程實作，不太談商業敘事。這集主持人是 Kevin Ball，Mento 的工程副總，自己也帶工程師做教練。
來賓兩位都來自 Vercel（就是做 Next.js 跟那個部署平台的公司）。Andrew Barba 是 Vercel 的 Member of Technical Staff，有趣的是他先當 Vercel 的客戶，2020 年就是他們最早一批企業客戶之一，進公司後做過 CDN、邊緣網路、防火牆這類底層系統，後來跑去做 billing。Shar Dara 是 EVE 的產品負責人，進 Vercel 之前在 Stripe 做訂閱與商品目錄，更早自己創過一家 no-code 訂閱計費公司 Billflow。兩個人是在 billing 團隊認識的，今年二月才轉過去想「怎麼把 agent 部署到 Vercel」這件事。
EVE 是他們做出來的答案，六月在倫敦的 Ship 活動上發表，Apache 2.0 開源，程式碼在 GitHub 上。
一千個人同時送 prompt 會怎樣
先講一個很具體的對照。你現在手上跑的 agent，不管是 Claude Code、Codex 還是自己架的 OpenClaw，本質上都是一個人對一個 agent，一個 session 從頭聊到尾。很多人為了跑這個還特地買一台 Mac Mini 放在桌上。
Andrew 給的測試方法很直接：讓一千個人在同一秒送出 prompt，看會發生什麼。
本機那種跑法，答案是死掉。EVE 的答案是水平展開，一千個 session 各自隔離、各自持久化，中間有重試、有錯誤處理、有中斷恢復。這就是他們說的 cloud native。
這個差別聽起來像是規模問題，其實是產品型態問題。如果 agent 是你個人的助理，本機跑完全夠用。如果 agent 是一家一萬人公司的內部工具，或者你的主要產品本身就是一個 agent，那底下要墊的東西就完全不同了。這也是之前寫過的 AI Agent 從 demo 跨到 production 那道溝最實際的一面：卡住的往往不是模型不夠聰明。
EVE 的起點是 Vercel 內部一個叫 D0 的資料 agent。全公司的人都在用它問資料問題。但為了讓 D0 能穩定跑在 Vercel 上，團隊包了一大堆自己手刻的東西：serverless function、sandbox、workflow 各種產品都要自己接。Andrew 的觀察是，D0 底下那一整層，未來每一個 agent 都會需要。那乾脆把它抽出來。
agent 就是一個資料夾
第二個觀察更有意思。他們回頭看 D0 到底是什麼，發現這個 agent 的功能有極高比例來自 markdown 檔跟 YAML 檔。D0 做的事情主要是提供一個語意層，告訴模型「月活躍用戶」這個詞在公司內部是什麼意思、不同部門用的縮寫各自代表什麼。這一整層本質上就是在教模型講公司內部的話。
所以他們一開始採取了一個很極端的立場：EVE 不要寫程式，純英文的 markdown 檔案就好。
實際做出來的東西是一個資料夾，最小的 EVE agent 真的就是一個 instructions.md。丟進去，你就有一個掛著前沿模型、跑在雲上的東西。Andrew 自己的形容是「盒裝版的 ChatGPT」。
再往上疊的話，各個子目錄分工是這樣：
| 目錄 | 作用 | 備註 |
|---|---|---|
| instructions | agent 的身分與行為準則 | 最小可運作單位，只要這個就能跑 |
| skills | 漸進式揭露的知識包 | D0 有九成內容是 skills |
| tools | 確定性的程式，接資料庫或外部 API | 要跑到真實資料就靠這個 |
| connections | tools 的特化版本，主要給 MCP | 丟一個 URL 進去，工具自動暴露出來 |
| channels | 觸發入口，Slack、Teams、GitHub、HTTP | 沒有入口 agent 就不會動 |
| sub-agents | 把大任務切出去，也用來切組織權責 | 內部是整個團隊擁有一個 sub-agent |
| evals | 評測 | 下面單獨講 |
這些檔案最後會編譯成一份 manifest，manifest 就是 infrastructure as code（基礎設施即程式碼，用檔案描述你要開哪些機器跟服務）。你有 skills，平台就給你一個 sandbox；你定義了排程，才給你排程用的事件系統。用多少開多少。
熟悉 Next.js 的人看到這裡應該會笑，這根本是當年 pages 目錄那套慣例優先的思路搬到 agent 上。Vercel 很擅長這件事：先定義一組約束，然後在約束之上自動推導出該開什麼資源。
sub-agents 那段我覺得被低估了。表面上它解的是 context 管理，把會撐爆母 agent 的大任務丟出去做完再回報。但 Vercel 內部實際的用法是組織設計：資料團隊擁有 D0，D0 是另一個 agent 的 sub-agent；另外還有一個「懂怎麼寫 EVE」的 agent，全公司都能叫它。這已經不是技術分層，是把公司的權責結構寫成了目錄結構。
純英文的理想，被權限打破了
當他們開始認真處理權限，那個「完全不寫程式」的立場就守不住了。
權限有好幾層。最外面那層是 channel：你從 Slack 進來，身分就是工作區 ID 加上 Slack 使用者 ID。EVE 從第一天就是多人設計，每一段你能寫程式的地方都有一個 context 物件，告訴你這一輪的當前使用者是誰、這一輪是誰發起的。這兩個人可以不是同一個。
再進一層是 agent 能不能動手。EVE 有 tool approvals，你標記某個工具一定要人工核可，它就會在對應的 channel 上長出一個 human in the loop（人類介入確認）的訊息。從 Slack 進來就用 Slack 的方式問，從簡訊進來就用簡訊的方式問。誰問問題、誰批准、這兩個人能不能是同一個，全部交給你自己寫。
最麻煩的是第三層：你能看到什麼。D0 接的是 Vercel 整個資料湖。Vercel 執行長 Guillermo 問一個問題，跟 Andrew 問同一個問題，能看到的東西應該不一樣。EVE 的解法叫 defineDynamic，按照當前呼叫者去解析要給哪一組工具跟連線。極端情況下，某個工具在你呼叫時根本不會出現。
你永遠不會想要一個吃 user ID 當參數的工具呼叫。
這句話是 Andrew 在講記憶設計時說的，但它其實是整個權限哲學的總結：任何跟身分有關的東西都不能讓模型自己猜，要在模型底下那一層用確定性的程式綁死。模型只負責說「我要這個」，是誰的、能不能拿，由框架決定。
所以 EVE 最後還是變成一個 code-first 的框架。有趣的是這個轉向並不是失敗，反而讓我更信任它。一個宣稱全部用英文就能搞定的 agent 框架，通常只是還沒碰到真的企業需求。
連自己的測試套件都是 evals
evals 這件事大家都在講，但真正做起來比想像中難很多。EVE 分成兩種。
第一種偏確定性：你送一個查詢，檢查某個工具有沒有被呼叫。做一個天氣 agent，使用者問天氣，你就確認 get_weather 有被叫到。不是百分之百可靠（模型就是有可能不叫），但寫起來很直觀。
第二種是 LLM as judge，用模型去評分模型。D0 就用這個來檢查生成出來的 SQL 有沒有查對資料表。
真正讓我覺得他們是認真的，是這句：EVE 的測試套件本身就是一整套 evals。他們用自己的 eval 框架測自己，這就是他們敢一天出好幾版的底氣。
主持人在這裡追問了一個我也很好奇的方向：現在的 evals 本質上是護欄，是非確定性版本的單元測試。有沒有可能反過來，把 evals 當成最佳化的目標函數，讓 AI 自己迭代 prompt 直到通過？
Andrew 的回答挺誠實的，他沒這樣想過，但實際上已經在發生：用 coding agent 去寫 EVE agent 的時候，它會自己寫 evals、自己跑。原因是 EVE 的文件裡有暗示「測 EVE 要用 evals」，coding agent 讀到就照做了。他沒看過它先寫 eval 再寫實作，但覺得你認真 prompt 應該逼得出來。
把文件寫給 AI 看
這段延伸出一個現在越來越多框架在做的事：文件不只寫給人看，要寫給 coding agent 看。
Vercel 在 Next.js 上吃過這個虧，模型訓練資料裡的 Next 版本永遠比實際落後好幾代。EVE 更慘，對模型來說它根本不存在。
他們的做法有兩個。一是 package 裡附 agents.md 指向文件。二是把 changelog（版本變更紀錄）也包進 package 裡。第二個比第一個有用得多：agent 會知道自己現在是 0.2 版、最新是 0.5 版，然後只去讀中間的差異，不用從頭學一遍。
EVE 現在還在 1.0 之前，每週都在改壞東西。沒有這份 changelog，使用者升級一次就要翻一次臉。
至於文件本身要不要做漸進式揭露，Andrew 說幾乎沒特別優化，因為現在的 coding agent 已經很懂「這個目錄裡有一堆檔案，我不要全部掃」。挑一個合理的資料夾結構就夠了。
記憶與自我進化：用 PR 當煞車
記憶功能是 Andrew 現在手上最大的工作，程式碼都在開著的 PR 裡。
設計是一個 memory 目錄，裡面切成不同的 slot。你可以有一個全工作區共用的記憶，也可以有只屬於你個人的，甚至只屬於某個 Slack 頻道加某個人的組合。切 slot 的目的回到前面那句：讓模型不可能撈錯人的記憶，因為它根本沒機會指定。
實作上 EVE 只確定性地呼叫三個函式：recall、save、tools，剩下交給 provider 決定。內建的檔案 provider 很陽春，recall 就把整個檔案塞進 context，save 完全不實作，工具只有「加一條記憶」跟「忘掉一條記憶」。但這套介面留了空間給更聰明的 provider，像 Super Memory 那種服務可以完全不暴露工具，改成在 save 的時候自己跑一套流程決定要記什麼，recall 的時候再根據當下的訊息去做語意檢索。
有個細節很實務：recall 不只在每一輪開始時呼叫，compaction（對話壓縮）之後還要再叫一次，因為壓縮不保證會留下你的記憶。而記憶預設是用 user 角色附加在訊息後面，不是塞進 system prompt，因為改 system prompt 會把 prompt cache 打掉。這種細節就是省錢跟燒錢的分界。關於記憶跟檢索的取捨，MongoDB 的 Pete Johnson 講過更完整的一輪，兩邊對照著看很有意思。
自我進化的部分我最喜歡。像 Hermes 那類 agent 可以直接改自己的程式再重啟，EVE 選了另一條路：你定義一個 coding sub-agent，它想改自己的時候，就開一個 PR 針對自己的程式庫。
這個設計的漂亮之處在於，監督的強度完全由你決定。你要它自動合併？寫個自動化就好。你要每一行都人工審？照原本的流程審。agent 的自我修改被塞進了你公司本來就有的程式碼審查制度裡，不需要發明新的治理機制。
「開公司就是建 agent」該信幾分
底層基礎設施的部分講得很硬。EVE 建在 workflow 上（Vercel 自己那套類 Temporal 的持久化工作流），一個 session 對一個 workflow。serverless function 歷史上有十五分鐘的執行上限，但 agent 動不動跑更久，所以他們每呼叫一次工具就跳到另一個 function 繼續跑同一個 workflow。反正工具呼叫本來就是一個同步的斷點，順勢換台機器，agent 就能無限跑下去。
使用情境上，Shar 說他們原本鎖定企業，結果上線沒多久就看到幾千個使用者跑進來，很多是 hobby 方案的個人用戶，有人週末做了一個 iMessage 的多人 agent。內部則有幾百個 agent 在跑，一開始是工程團隊，後來 go-to-market 團隊整組搬上來，行銷用來自動化內容跟社群，產品團隊把文件餵給 agent 去回答問題，有時候直接在 Slack 上分享給客戶。
歸納起來使用者做的東西大概三類：掛在 Slack 上的對話型 agent、跑報表然後發訊息的背景型 agent、以及前台是網頁應用但後面由 agent 驅動的產品。第三類有兩個例子很生動：一個開源 CRM，你只填姓名跟 email，背景 agent 自己去查這個潛在客戶把資料補完；還有一個 AI 音樂工具，你設定節奏，agent 跟你一起把曲子做完。
這類「協作式介面」現在確實還很少人做好。大部分所謂的 AI 功能，不是塞一個聊天框，就是非同步生一份報告。真正跟你一起在同一份文件上工作的，體驗都還很粗糙。
最後兩位各講了願景。Andrew 的比較技術：EVE 從第一天就賭模型會越來越聰明。他觀察其他 agent 框架都是垂直加厚，程式越寫越多、確定性越來越高，到最後看起來已經不像 agent，比較像一套 workflow API。EVE 選水平展開，多給模型一些東西，讓模型自己決定怎麼用。
這個賭注是整個框架最核心的判斷，也是最大的風險。賭對了，模型每升一級 EVE 就自動變強一次。賭錯了，那些垂直加厚的框架才是對的。關於 harness 這一層到底在做什麼、跟模型的分工怎麼切，之前整理過一篇把模型、agent、harness 三個詞分乾淨的文章可以對照。
Shar 的版本野心大很多：「開公司就是建 agent」。他說 EVE 比你的公司登記還要基礎，agent 會早於你的網站、網域名稱跟公司成立，你先有 agent，agent 再幫你長出整條軟體開發流程，而你的工作變成調校這座工廠。
老實說這句話我聽的時候有點想笑。它太像一家公司在替自己的產品找歷史定位。但如果只看「公司的隱性知識應該被寫成可執行的檔案」這一層，其實不算誇張。D0 有九成是 skills 這件事本身就是證據：那些 skills 講白了就是把公司裡口耳相傳的東西寫下來。這件事就算沒有 AI 也該做，只是以前做完沒人看。
一個很少人講的開源難題
最後有個細節值得單獨拎出來。
EVE 開源了，也想收外部貢獻，但他們卡住了：測試套件會真的打模型、真的部署專案到 Vercel，用到一堆密鑰。所以外部 PR 根本沒辦法直接跑 CI。他們現在的做法是小心翼翼拉進 sandbox 檢查有沒有惡意程式，確認沒問題再用自己的帳號重新 commit、掛上共同作者，才能跑測試。
這是 AI 時代開源專案的新結構性問題。以前的測試跑一次幾乎零成本，現在你的測試套件本身就是一張帳單，而且是一個對外開放的攻擊面。他們自己也用 EVE agent 每天分析這些 PR 挑該合的進來，但流程明顯還沒理順。
順帶一提，EVE 從三月到七月中只有兩個人全職做，最近才加到六個人。
如果你正在把 agent 從自己的筆電往公司裡推，這集值得聽完整版，很多細節我只能挑重點講。技術選擇可以之後再爭論，但「一千個人同時送 prompt」這個壓力測試，現在就可以拿去問你手上的架構一遍。
這類 podcast 筆記我每天都在整理，訂閱 wilsonhuang.xyz 就不用自己一集一集聽。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件