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；單一 endpoint 路由數百個 models |
| 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
AI SDK 給 agent 一個介面呼叫任何 model；AI Gateway 從單一 endpoint 路由數百個 models。官方把 Gateway 稱為「CDN for tokens」：跑在 Vercel 經營超過十年的全球網路上，每次呼叫走同一個 endpoint，provider 故障時自動 failover，並跨所有 provider 追蹤 cost 與 usage。
計價結構值得注意：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、Docker 支援與 kernel，與 host 及其他 sandbox 隔離。安全設計的重點在憑證：credentials 只在 agent 的程式碼呼叫服務時才注入，agent 拿得到服務，但永遠看不到 raw token。官方並稱這是 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 是短效還是長效寬權限？敏感操作能否逐筆稽核？
三層六個問題，答不出來的那一格，就是下一個該投資的缺口。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。