Vercel 從部署網站和 Web App 起家，現在把一部分力氣放到 agent 框架 eve。Andrew Qu 先前做過 MCP library 和 skills.sh，後來把 v0 裡處理 agent 的做法收斂到 eve。v0 這類 vibe-coding 產品在建自己的 agent 時，碰到模型與 provider 切換、fallback、執行可恢復等雜事。這些問題堆在一起，就會卡住產品化。eve 像是把踩過的原語收成一套預設做法。
Agent 需要另一套開發習慣，原因在輸出不夠穩定。Web App 通常可先定好路由、狀態和畫面，agent 會依上下文、工具回應和模型判斷改變下一步。基礎設施可能還是部署、觀測與權限控管那一套，但資料流已經不同。一次 run 可能跨很久，途中要讀寫檔案、呼叫工具、壓縮上下文，失敗後還要接回來。filesystem agent、skills、compaction、subagents 才會被拉進框架。
自動化的邊界要看任務形狀#
適合交給 agent 的工作常見於企業內部流程，例如合約 redline 的第一版、行銷回顧、找出可聯絡對象、替資料庫寫查詢。這些工作重複，卻又不能只靠固定規則跑完，系統得看情境決定下一步。合約修改和資料查詢都有錯誤成本，agent 產出的第一版不能直接等同於完成品。
回饋週期應該跟任務風險綁在一起。輸出樣子明確、錯誤容易檢查的任務，可以讓 loop 跑久一點。牽涉精準工程變更或需要人工判斷的工作，就要在中途把人拉回來。這裡處理的是責任邊界，介面偏好只佔一小部分。誰批准工具執行、誰檢查結果、誰承擔壞資料寫入，系統設計時要先定下來。
沙箱在這裡浮出來。agent 需要跑程式碼、處理長時間工作，又不能把主環境的檔案、憑證和網路權限全部交出去。可觀測性與 evals 也不能只當附加報表，它們是事後追錯的入口。在 Vercel 的部署路徑裡，eve 會帶有 observability 和 evaluations；導入時仍要確認記錄粒度、敏感資料遮罩和失敗重試策略。
技能與網站都要給 agent 讀#
skills 會被放進架構，是因為模型知識會過期。Vercel 舉的例子是模型仍可能建議已停用的 Vercel Postgres，而現在產品方向已經移到 marketplace。skill 的作用是把最新產品狀態包成 agent 可按需讀取的知識，先把模型導回目前做法。這不能取代文件清理。舊內容沒有標註、搜尋結果還在導流，agent 仍可能拿到壞線索。
網站也開始分成兩種消費者。人看視覺頁面，agent 需要結構化、少噪音的版本。Vercel 已經在偵測 agent request 時直接回 Markdown，避免讓模型解析為瀏覽器設計的 HTML。工程含意很直接。視覺頁、Markdown、技能與產品實際狀態要對得起來，否則只是把同一份過期資訊換成更容易被 agent 吃下去的格式。
下一題是團隊如何共享 agent 開發脈絡。個人提示技巧、前端調整手法、工具使用慣例，如果只留在個人聊天記錄裡，其他人很難重用。多人協作的 agent 開發，需要把這些 context 變成可版本化、可審查、可淘汰的材料。這比把平台包成一個漂亮入口更麻煩，但維護責任也比較落地。