摘要： 把 agent 做成 demo 不難：挑一個模型、掛上幾個 tools、套個聊天介面就收工。可一旦要進 production，麻煩立刻排隊上門——模型供應商可能隨時中斷服務，長任務會在跑到第九步時斷線，不受信任的程式碼得先找個地方隔離執行，而這個 agent 到頭來還得串得上 Slack、GitHub 與企業的資料系統。
把 agent 做成 demo 不難：挑一個模型、掛上幾個 tools、套個聊天介面就收工。可一旦要進 production，麻煩立刻排隊上門——模型供應商可能隨時中斷服務，長任務會在跑到第九步時斷線，不受信任的程式碼得先找個地方隔離執行，而這個 agent 到頭來還得串得上 Slack、GitHub 與企業的資料系統。
Vercel 於 6 月 17 日推出的 Agent Stack，正是把這串難題收攏成三項核心能力：連接 models、執行多步 workflows、連接 data and tools。官方把話說得很白：它交付的是打造與部署 production-grade agents 所需的整套 building blocks——你既不被任何單一 vendor 綁住，也不用親手從零疊出一層抽象。
三層架構，六項產品各守一位
| 層 | 產品 | 對應難題 |
|---|---|---|
| Connect to models | AI SDK、AI Gateway | 任何 model 都能用同一個介面呼叫；數百個 models 交由單一 endpoint 路由 |
| Execute workflows | Workflow SDK、Vercel Sandbox | 長任務具備耐久性；每個 agent 分得一台隔離 VM |
| Connect to data and tools | Vercel Connect、Chat SDK | 以短效權限觸及內部系統；agent 進駐使用者所在的 apps |
一層配兩項產品的對稱並非湊數——每層都是「介面」加「平台」的組合：AI SDK 擔任介面，AI Gateway 擔任平台；執行由 Workflow SDK 定義，運算由 Sandbox 供應；權限歸 Connect，送達歸 Chat SDK。
第一層 Connect to models：AI SDK 搭配 AI Gateway
agent 要呼叫任何 model，走 AI SDK 提供的那一個介面即可；數百個 models 之間的分流，則由 AI Gateway 以單一 endpoint 統一處理。官方替 Gateway 取的稱呼是「CDN for tokens」：它建立在 Vercel 營運十年以上的全球網路上，所有呼叫都經過同一個 endpoint，哪家 provider 出狀況就自動 failover，cost 與 usage 更是跨所有 provider 一併追蹤。
計價方式值得多看一眼：Gateway 只收 provider 的原價、零 markup，keys 還能用自己的。對採多模型架構的團隊而言，路由層因此不會變成成本中心；真正剩下的風險，只有選錯了昂貴的模型。
實際樣貌可從案例看出：不動產科技公司 SERHANT 靠單一 key 就運轉三個模型——市場分析交給 Claude、行銷文案交給 GPT、圖像生成交給 Gemini。模型層抽象最實在的好處在這裡現形：以任務為準的路由，無須遷就任何一家供應商的帳號設計。
不過，別把統一介面誤當成路由策略。分類這種事交給便宜模型沒問題，高風險決策卻未必撐得住；Gateway 的職責是連線與切換，品質標準仍然要團隊自己訂。
第二層 Execute workflows：Workflow SDK 搭配 Vercel Sandbox
有了 Workflow SDK，agent runs 就能 durable：job 的每一步都會 checkpoint、state 隨之保存、失敗自動 retry；若得等人核可、碰上回應遲緩的 API 或 webhook，也可以先 pause，之後從最後成功的那一步續跑，不必歸零重來。對一跑就是數小時的任務來說，模型費用與外部副作用會不會付上兩次，就看這一層。
官方提出的數字案例是創作平台 FLORA：creative agent 以 Workflow SDK 為底，光一個 creative session 就能把工作 fan out 到超過 50 個 image models，每一步都持久化，失敗就重試。
另一半由 Vercel Sandbox 承接：每個 agent 分得一台 microVM——一部功能完整的 Linux 電腦，擁有自己的 filesystem 與 kernel，也支援 Docker，並和 host 及其他 sandbox 彼此隔離。安全設計的核心放在憑證：直到 agent 的程式碼實際呼叫服務那一刻，credentials 才會注入；服務用得到，raw token 卻始終不會進到 agent 眼裡。官方還點出：Vercel 能撐起十億次 preview deployments、每天六百萬次 builds，靠的正是同一個 primitive——這道隔離層是把既有基礎設施再拿出來用，不是新造的行銷話術。
idempotency 這個老問題仍在：付款、寄信等外部副作用，保存狀態是 workflow 的本分，去重不是；動手 retry 之前，操作鍵要定義清楚，稽核記錄也一樣不能省。
第三層 Connect to data and tools：Vercel Connect 搭配 Chat SDK
本波更新最晚問世的是 Vercel Connect（public beta）：每個系統接一次就好，此後 agent 為各個 task 鑄造 short-lived token，scope 僅限明確授與的 permissions——刻意有別於傳統那種長效又寬權限的 token。Slack、GitHub、Snowflake、Salesforce、Notion 與 Linear 皆為內建支援，其他服務則經由 OAuth 或 API 接入。
送達難題歸 Chat SDK 管：憑一份單一 codebase，agent 就能進駐使用者早已在用的 apps。案例 NanoClaw：同一個 agent 的觸角橫跨超過 12 個 channels，對話從 Slack 接著往 GitHub 或 Linear 走，context 一路接續不斷。
貫穿這層的主軸，是權限多了時間這個維度：token 生命夠短、scope 界線夠清楚，敏感操作才可能在 audit log 裡被逐筆追蹤。整合的系統愈多，這條原則的分量愈重。
eve：三層收進同一個目錄
官方為不想親手逐層接線的團隊備了 eve：這個 opinionated 的 open-source framework，把 Agent Stack 的三層整併進單一目錄。
agent/
agent.ts # 跑在哪個 model
instructions.md # 它是誰
tools/ # 它能做什麼
skills/ # 它知道什麼
subagents/ # 它委派給誰
channels/ # 它住在哪裡
schedules/ # 它何時自己行動durability、sandbox、approvals、delivery 在底層已經接妥，團隊要產出的只有 agent 本身：instructions 以 markdown 撰寫，tools 以 TypeScript 實作。eve 眼下同樣是 public beta。
取捨，以及 builder 檢查表
六件套集中於同一平台，對已在 Vercel 上的團隊省下可觀的接線工夫；付出的代價，則是觀測、狀態與部署設定被更深地綁進同一個環境。把供應商風險放在心上的團隊，可以將 eve 開源視為對沖：三層介面起碼有一份搬得走的參考實作。
就算六項產品一項都不採用，Agent Stack 仍可當作一張檢查清單：
- 模型層：更換模型能不能只動一行？provider 掛掉時有 failover 嗎？
- 執行層：長任務在第 N 步斷掉，接得回第 N 步嗎？不受信任的程式碼該安置在何處執行？
- 連接層：給外部系統的 token，是短效的，還是長效又寬權限的？敏感操作是否筆筆可稽核？
三層、六個問題——答不上來的那一格，就是下一筆該投資的缺口。