當部署者變成機器：Vercel 提出的「Agentic Infrastructure」是什麼？

過去幾個月，如果你有留意 AI 工具的動態，大概會發現一個現象：程式碼不再只是人寫的。

根據 Vercel 的數據，每週部署次數在三個月內翻倍，而超過 30% 的部署現在是由 coding agent 發起的，比六個月前成長了 1000%。其中 Claude Code 佔了 75%，Lovable 和 v0 各約 6%，Cursor 則是 1.5%。

這不是一個小眾趨勢。當軟體的最終「行動者」從人類轉為機器，底層的基礎設施勢必也得跟著改變。Vercel 在最新的部落格文章中把這個新需求稱為 Agentic Infrastructure，並且拆成三個層面來討論。

第一層：給 coding agent 部署的基礎設施

當一個 coding agent 寫完一段功能，它需要一個地方來執行、測試、驗證結果——說到底，它需要一個 URL。如果從程式碼到可運行的系統之間，還得手動操作 Terraform 或點擊雲端主控台的按鈕，那自動化的迴圈就斷了。

Vercel 認為，不可變部署（immutable deployments）、每個 commit 都產生的預覽 URL、以及即時回滾，這些不再只是開發者體驗的加分項，而是機器驅動開發的必要條件。

透過 CLI、API、MCP 伺服器以及 git 整合，coding agent 可以產生程式碼、開 PR、拿到預覽 URL、驗證輸出、然後直接上線——全程不需要人類介入。

傳統的 serverless 工作負載需要函式、快取、以及邊緣端的短暫請求。但 agent 的工作負載形狀完全不同：它們需要長時間執行、多步驟編排、模型路由、成本控制、沙箱執行程式碼、以及防範濫用。

Vercel 把他們為 AI 打造的各種元件整合成一個統一平台，類似他們過去為 serverless 做的事：

AI SDK：提供統一的介面來跨框架與供應商建構 AI 應用，最新版本（AI SDK 6）加入了 agent 抽象層，讓開發者定義一次 agent 就能在不同介面與工作流程中重複使用。
Chat SDK：讓 agent 可以透過單一程式碼庫在數十個聊天應用與平台上運作。
AI Gateway：提供單一端點給數百個模型，並內建預算、監控、路由、重試與備援機制。
Fluid compute：專為 AI 工作負載的特殊形狀設計，同時處理延遲、並發與閒置等待。
Workflows 與 Queues：讓 agent 可以暫停、恢復、重試、維持狀態，以及卸載背景工作。
Sandbox：提供隔離的執行環境給不受信任的程式碼。
Observability：讓團隊可以追蹤 agent 在做什麼、哪裡出錯。

這些元件單獨看都很有用，但 Vercel 強調的是把它們放進同一個系統，共用上下文——程式碼、模型呼叫、執行時期行為。這個共享的上下文，正是讓基礎設施本身變成 agent 的關鍵。

傳統的基礎設施是單向的：程式碼進去、日誌出來，然後人類讀日誌來修程式碼。但當平台擁有跨所有層級的即時可見度，agent 就不只是監控生產環境，還能自主回應。

舉例來說，當某個關鍵路由出現延遲高峰，或某個模型供應商開始掉請求，Vercel 的平台不會等人類發現。它會調查異常、查詢 observability 資料、讀取日誌、檢查原始碼、進行根本原因分析，並在隔離的沙箱中審查建議的修復方案。

目前這個流程仍然需要人類核准。但隨著時間，平台會承擔更多維運負擔——不是因為要取代開發者，而是因為它擁有足夠的上下文來代表開發者行動。

如果你正在建構 AI 產品，Vercel 這篇文章點出了一個值得思考的轉折：基礎設施的設計邏輯正在從「服務人類操作者」轉向「服務機器操作者」。

這不代表人類角色消失，而是人類的工作從「手動部署與除錯」變成「定義意圖與設定邊界」。當 agent 可以自主寫程式、部署、甚至診斷問題，你需要的平台必須能讓 agent 以程式化、確定性的方式與之互動，而不是提供一個漂亮但只能給人點擊的 UI。

當然，Vercel 有自己的商業立場——他們正在把這些能力整合進自己的平台。但他們提出的三層架構（給 agent 部署的基礎設施、用來建構 agent 的基礎設施、本身具有 agent 能力的基礎設施）是一個有用的思考框架，幫助我們理解接下來幾年基礎設施會怎麼演化。

如果你現在正在挑選平台或設計系統，不妨問自己一個問題：如果明天你的 agent 要自主部署一個修復，它能不能順利完成，還是會卡在一個需要人類點擊的步驟上？

本文由 AI 協助自上述來源整理，經人工審核後發布。