摘要： Vercel 統計顯示，超過 30% 每週部署由 coding agent 啟動，其中 Claude Code 占 agent 發起部署的 75%。文章以三層架構描述 Agentic Infrastructure：給 agent 部署的基礎設施、建構 agent 的平台，以及能主動調查異常的基礎設施。
部署的主角換成了機器：看懂 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、核對輸出、然後直接發布上線——整段流程不需要任何人類插手。
第二層：給人用來建構與運行 agent 的基礎設施
傳統 serverless 工作負載面對的是函式、快取，以及邊緣端生命週期極短的請求；agent 的工作負載卻是另一種形狀：要能長時間運行、做多步驟編排、進行模型路由、控制成本、在沙箱裡執行程式碼，還得擋住濫用行為。
Vercel 把自家為 AI 陸續打造的元件收攏到同一個平台，做法類似他們當年整合 serverless 的那一次：
- AI SDK：以統一介面跨框架、跨供應商打造 AI 應用；最新的 AI SDK 6 加入了 agent 抽象層，開發者只要定義一次，就能在不同介面與工作流程之間重複使用。
- Chat SDK：憑一份程式碼庫，就讓 agent 進駐數十個聊天應用與平台。
- AI Gateway：用單一端點串起數百個模型，並內建預算、監控、路由、重試與備援機制。
- Fluid compute：為 AI 工作負載的獨特形狀而生，同時照應延遲、並發與閒置等待。
- Workflows 與 Queues：讓 agent 可以暫停、恢復、重試、保存狀態，並把背景工作卸載出去。
- Sandbox：替不受信任的程式碼準備隔離的執行環境。
- Observability：讓團隊看得見 agent 正在做什麼、又在哪裡出了差錯。
這些元件拆開來各自都有價值，Vercel 真正強調的卻是把它們放進同一套系統、共用同一份上下文——程式碼、模型呼叫、執行時期行為都涵蓋在內。正是這份共享的上下文，成為基礎設施蛻變為 agent 的關鍵。
第三層：基礎設施自身就具備 agent 能力
過往的基礎設施只有單向通道：程式碼送進去、日誌吐出來，再由人類讀完日誌回頭改程式碼。但只要平台能即時看穿所有層級的動態，agent 就不再只是監控生產環境，還能自己出手應對。
例如某條關鍵路由的延遲突然飆高，或某家模型供應商開始漏接請求，Vercel 的平台不會坐等人類發現。它會調查這起異常、查詢 observability 資料、翻閱日誌、檢視原始碼、執行根本原因分析，再把建議的修復放進隔離沙箱裡審查。
眼下這套流程仍須人類核可。但隨著時間推移，平台會扛起愈來愈多的維運重擔——不是為了取代開發者，而是因為它握有足夠的上下文，能夠代表開發者行動。
對產品 builder 而言，這代表什麼
如果你正在打造 AI 產品，Vercel 這篇文章等於點出一個轉折：基礎設施的設計思維，正從「伺候人類操作者」轉向「伺候機器操作者」。
這不代表人的位置會被抽掉，而是人的職責從「親手部署、親自除錯」挪到「界定意圖、畫出邊界」。當 agent 能夠自主寫程式、完成部署、甚至診斷故障，你需要的平台就必須容許 agent 以程式化、確定性的方式跟它互動，而不是只給一個漂亮、卻專供人類點擊的介面。
當然，Vercel 有自己的商業盤算——這些能力終究會被整合進他們的平台。不過他們提出的三層架構（給 agent 部署的基礎設施、用來建構 agent 的基礎設施、本身就具備 agent 能力的基礎設施）確實是個好用的思考框架，讓我們得以預想未來幾年基礎設施會怎麼演化。
假如此刻你正在選平台、或設計自己的系統，不妨拿這個問題問問自己：假如明天你的 agent 得自行部署一個修復，它能一路走完嗎？還是會卡在某個非得由人類點擊的步驟前？