Next.js on KnightLi的博客

Vercel AI SDK 是什麼？TypeScript 開發者構建 AI 應用的統一工具包

Sun, 17 May 2026 23:07:38 +0800

vercel/ai 是 Vercel 維護的開源 AI SDK。

它的定位很明確：為 TypeScript 開發者提供一套統一工具，用來構建 AI 應用和 AI Agent。它來自 Next.js 背後的團隊，但並不只服務於 Next.js，也支援 React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 等執行環境。

專案地址：https://github.com/vercel/ai

如果你正在做聊天應用、AI 寫作工具、RAG 應用、帶工具呼叫的 Agent、串流輸出介面，或者想把多個模型供應商接到同一個應用裡，Vercel AI SDK 是一個值得關注的基礎庫。

它解決的核心問題

現在做 AI 應用，最大的麻煩之一不是「能不能呼叫模型」，而是不同模型供應商的介面、串流輸出、工具呼叫、錯誤處理和前端狀態管理都不一樣。

例如：

OpenAI 有自己的 SDK 和回應格式。
Anthropic 有自己的訊息結構。
Google、xAI、Mistral、DeepSeek、Groq 等也各有差異。
串流輸出需要處理 chunk。
工具呼叫需要處理模型發起的結構化請求。
前端聊天 UI 還要管理訊息、載入狀態、取消、重試和錯誤顯示。

如果每個供應商都手寫一套適配層，專案會很快變複雜。

Vercel AI SDK 的思路是把這些差異收斂到統一 API 後面。開發者用一套介面寫應用，再透過 Provider 接入不同模型。

統一 Provider 架構

Vercel AI SDK 的一個核心特點，是 provider-agnostic，也就是不綁定單一模型廠商。

它可以透過統一 API 存取 OpenAI、Anthropic、Google 等模型提供方。專案 README 還提到，預設情況下 AI SDK 會使用 Vercel AI Gateway，讓開發者更容易存取多個主流 provider。

這對工程專案很實用。

因為很多 AI 產品最終都不會只依賴一個模型：

有的任務適合強推理模型。
有的任務適合便宜快速模型。
有的任務需要多模態。
有的任務需要長上下文。
有的任務需要本地或私有部署模型。

統一 Provider 架構讓應用更容易做模型切換、灰度測試、成本控制和備援方案。

串流輸出是前端體驗的關鍵

AI 應用和傳統 API 最大的體驗差異之一，是回應可能很長。

如果使用者每次都要等完整回答返回，聊天工具、寫作工具和程式碼助手會顯得很慢。串流輸出可以讓文字逐步顯示，使用者更早看到結果。

Vercel AI SDK 對串流生成做了比較完整的封裝。開發者不需要從零處理底層事件流，而是可以使用 SDK 提供的生成和串流介面，把模型輸出接到前端 UI。

這對 Next.js / React 應用尤其方便。

一個 AI 聊天介面看起來簡單，但實際要處理：

訊息列表。
使用者輸入。
伺服器請求。
串流 token 顯示。
載入狀態。
錯誤狀態。
中止生成。
重新生成。

這些都是 AI SDK 試圖幫開發者減少重複勞動的地方。

工具呼叫和 Agent 場景

隨著 AI 應用從「聊天」走向「做事」，工具呼叫變得越來越重要。

模型不只是輸出自然語言，還可能需要呼叫外部函式：

查資料庫。
搜尋文件。
呼叫業務 API。
讀取訂單狀態。
生成圖表。
建立日曆事件。
修改專案檔案。

Vercel AI SDK 支援工具呼叫相關能力，讓開發者可以定義工具、參數和執行邏輯，再讓模型在合適時機請求呼叫。

這也是它從「聊天 UI SDK」擴展到「AI 應用和 Agent 工具包」的關鍵。

不過，工具呼叫不是加上去就萬事大吉。真實專案還要考慮：

參數校驗。
權限邊界。
工具呼叫日誌。
冪等性。
超時和重試。
人工確認。
敏感操作限制。

AI SDK 可以幫助處理介面和流程，但安全邊界仍然需要開發者自己設計。

UI 整合能力

Vercel AI SDK 對前端框架比較友好。

它不僅提供核心生成 API，也圍繞聊天、補全、訊息狀態和串流 UI 做了封裝。對於使用 Next.js 和 React 的團隊來說，這能減少很多樣板程式碼。

但它並不只適合 Vercel 部署。

如果你的專案本身是 TypeScript 技術棧，或者後端執行在 Node.js 環境，AI SDK 仍然可以作為模型呼叫和串流處理層來使用。是否部署在 Vercel，取決於你的應用架構、團隊習慣和基礎設施選擇。

Skill for Coding Agents

vercel/ai README 裡還有一個有趣的建議：如果你使用 Claude Code、Cursor 等 coding agent，可以把 AI SDK skill 加到倉庫裡。

範例命令是：

`1`	`npx skills add vercel/ai`

這說明 Vercel 已經意識到，AI SDK 的使用者不只是人類開發者，也包括 coding agent。

當 agent 修改使用 AI SDK 的專案時，如果倉庫裡有專門的 skill，它可以更好地理解 SDK 約定、常見 API、專案結構和最佳實踐，減少亂寫程式碼的機率。

這個方向很值得注意。

未來開源專案可能不只提供 README 和 docs，還會提供給 AI coding agent 使用的結構化技能說明。對複雜 SDK 來說，這會變成新的開發者體驗入口。

適合哪些專案

Vercel AI SDK 適合這幾類場景：

基於 Next.js / React 的 AI 聊天應用。
需要串流輸出的寫作、問答、客服和程式碼助手。
需要接入多個模型 provider 的 AI 產品。
想快速構建 RAG 或文件問答原型的團隊。
需要工具呼叫、函式呼叫或輕量 Agent 能力的應用。
已經使用 TypeScript / Node.js 技術棧的團隊。

它尤其適合前端和全端開發者。因為很多 AI 應用的難點不只是模型呼叫，而是如何把模型輸出變成穩定、流暢、可互動的產品體驗。

不適合什麼場景

如果你的專案主要是 Python 後端、深度學習訓練、模型微調或底層推理服務，Vercel AI SDK 可能不是核心工具。

它更偏應用層，而不是模型訓練框架。

如果你需要的是：

自己訓練模型。
管理 GPU 推理叢集。
做底層 batch inference。
深度控制 tokenizer、KV cache、量化和推理引擎。

那更應該看 PyTorch、vLLM、SGLang、TensorRT-LLM、llama.cpp 或雲端廠商推理服務。

Vercel AI SDK 更像「把模型能力接進產品」的應用開發層。

使用時要注意什麼

第一，不要把統一 API 理解成完全無差異。

不同模型 provider 的能力、上下文長度、工具呼叫格式、串流細節、錯誤類型和計費方式仍然不同。統一 SDK 能減少工程摩擦，但不能消除模型差異。

第二，要控制成本。

AI 應用一旦上線，串流聊天、重試、工具呼叫、RAG 檢索和多模型 fallback 都可能增加呼叫成本。需要做限流、快取、日誌和預算監控。

第三，要處理安全邊界。

如果模型能呼叫工具，就必須限制工具能做什麼。不要讓模型直接執行高風險操作，也不要把密鑰、資料庫寫入權限和生產環境操作裸露給模型。

第四，要保留可觀測性。

AI 應用出問題時，不能只看前端錯誤。你需要知道使用者輸入、模型選擇、工具呼叫、回應時間、token 消耗、錯誤類型和最終輸出。

小結

vercel/ai 不是一個新的模型，也不是單純的聊天元件。

它更像 TypeScript AI 應用開發的基礎設施：統一 Provider、串流輸出、工具呼叫、前端狀態管理和 agent 場景，都被放進一個開源 SDK 裡。

對已經使用 Next.js、React、TypeScript、Node.js 的團隊來說，它可以顯著降低從「模型 API 能跑」到「產品體驗可用」的工程成本。

但它也不是萬能層。模型選擇、權限設計、成本控制、日誌監控和業務安全，仍然需要開發者自己負責。

如果你想做 AI 應用，而不是訓練模型，Vercel AI SDK 是一個值得先試的工具包。

參考資料

Next.js 高危 SSRF 漏洞 CVE-2026-44578：影響範圍與升級建議

Sun, 17 May 2026 17:27:13 +0800

Next.js 在 2026 年 5 月揭露了一個高危 SSRF 漏洞：CVE-2026-44578。

根據 GitHub / Vercel 安全公告 GHSA-c4j6-fc7j-m34r 和 NVD 記錄，這個漏洞影響自託管的 Next.js 應用，前提是應用使用內建 Node.js server，且暴露在可接收惡意 WebSocket upgrade 請求的網路環境中。攻擊者可能讓伺服器代理請求到任意內部或外部位址，進而暴露內部服務或雲端 metadata 端點。

Vercel 託管部署不受影響。修復版本是 15.5.16 和 16.2.5。

先說結論

如果你在自己的伺服器、容器、Kubernetes、ECS、VPS、裸機或 PaaS 上自託管 Next.js，需要優先檢查。

受影響範圍：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

不受影響或風險較低的情況：

部署在 Vercel 平台上的應用。
已升級到 15.5.16、16.2.5 或更高版本。
沒有使用內建 Node.js server 暴露服務的場景。
反向代理或負載平衡已阻斷不需要的 WebSocket upgrade 請求，且出站存取也做了限制。

建議處置順序：

先確認生產環境實際執行的 next 版本。
自託管應用盡快升級到修復版本。
暫時無法升級時，在反向代理或負載平衡層阻斷不需要的 WebSocket upgrade。
限制應用伺服器存取雲端 metadata、內網管理面和敏感內部服務。
排查近期異常 WebSocket upgrade 請求和內部存取日誌。

漏洞是什麼

CVE-2026-44578 是一個 Server-Side Request Forgery，也就是 SSRF 漏洞。

SSRF 的核心風險是：攻擊者不直接存取內部系統，而是誘導你的伺服器替他發請求。伺服器通常位於更靠近內網、雲平台和內部服務的位置，所以一旦被當成代理使用，可能存取到外部攻擊者本來碰不到的資源。

這次 Next.js 的問題出在 WebSocket upgrade 處理路徑。安全公告稱，自託管應用如果使用內建 Node.js server，攻擊者可以透過特製 WebSocket upgrade 請求，讓伺服器代理存取任意內部或外部目的地。

風險點包括：

內網 HTTP 服務。
管理後台。
雲端 metadata 位址。
容器或叢集內部服務。
只允許伺服器存取的內部 API。

這個漏洞的 CVSS v3.1 評分為 8.6 High，向量是：

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

這意味著攻擊面在網路側，攻擊複雜度低，不需要權限，也不需要使用者互動，主要影響機密性。

為什麼自託管更危險

這次公告明確提到：Vercel-hosted deployments are not affected。

真正需要重點關注的是自託管部署。原因很簡單：自託管應用的網路環境千差萬別，有些直接暴露 origin server，有些在 Nginx、Traefik、Ingress、Cloudflare、ALB 或自建閘道後面，有些運行在雲主機、容器網路或 Kubernetes 叢集裡。

如果這些環境沒有限制出站存取，Next.js 程序可能看得到：

169.254.169.254 這類雲端 metadata 位址。
內網 IP 段。
只在 VPC 內暴露的服務。
Redis、Elasticsearch、Prometheus、Grafana 等內部元件。
Kubernetes Service、Pod 或管理端點。

所以 SSRF 的危險不只在 Next.js 本身，而在它所在網路裡能存取什麼。

如何判斷是否受影響

第一步，看 next 版本。

在專案目錄裡執行：

`1`	`npm ls next`

或：

`1`	`pnpm why next`

也可以直接查看：

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

如果版本落在下面範圍，就需要處理：

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

第二步，看部署方式。

重點關注這些情況：

使用 next start 運行生產服務。
使用自訂 Node.js server 承載 Next.js。
Docker 映像裡直接啟動 Next.js server。
Kubernetes / ECS / VPS / 裸機自託管。
反向代理後面仍然直接暴露 Next.js origin。
應用所在網路能存取內部服務或雲端 metadata。

如果應用部署在 Vercel，按官方公告不受這個漏洞影響。但依然建議保持 Next.js 版本更新，因為同一批版本裡可能還修復了其他問題。

應該升級到什麼版本

官方修復版本是：

15.5.16
16.2.5

升級示例：

`1`	`npm install next@15.5.16`

或如果使用 16.x：

`1`	`npm install next@16.2.5`

pnpm：

`1`	`pnpm add next@15.5.16`

或：

`1`	`pnpm add next@16.2.5`

升級後重新建置並發布：

1
2

npm run build
npm run start

或按你的 CI/CD 流程重新建置 Docker 映像並發布。

如果你的專案鎖定在 14.x 或 15.x，不建議為了修漏洞倉促跨大版本到 16.x。更穩妥的做法是先升級到 15.5.16 這一修復線，完成測試和發布後，再規劃大版本升級。

臨時緩解措施

如果暫時不能升級，安全公告給出的核心思路是：不要把 origin server 直接暴露給不可信網路；如果不需要 WebSocket upgrade，就在反向代理或負載平衡層阻斷；同時盡量限制 origin 的出站存取。

可以考慮這些緩解方向：

不直接暴露 Next.js origin server。
在 Nginx、Ingress、ALB、Cloudflare 等入口層過濾不需要的 WebSocket upgrade。
如果業務不使用 WebSocket，直接拒絕帶有 upgrade 語義的請求。
對應用伺服器做 egress 限制，禁止存取雲端 metadata 位址和敏感內網段。
用雲平台能力啟用更安全的 metadata 存取模式，例如要求 token 的 metadata 服務。
對管理後台、資料庫、快取、監控系統增加認證和網路隔離。

注意，反向代理規則只是臨時緩解，不應該替代升級。框架漏洞最終仍然要透過修復版本解決。

維運排查重點

這個漏洞主要影響機密性，所以排查重點是「有沒有被用來存取內部資源」。

建議關注：

Web 存取日誌中異常的 Upgrade、Connection、Host、路徑和來源 IP。
反向代理或負載平衡日誌中異常的 WebSocket upgrade 請求。
Next.js 服務附近的異常出站連線。
雲端 metadata 服務存取日誌或憑證使用記錄。
內網管理服務、監控系統、快取、搜尋服務的異常存取。
IAM 臨時憑證、存取金鑰、token 是否有異常調用。
容器或主機上是否出現異常程序、下載行為或橫向移動跡象。

如果懷疑被利用，建議按外洩場景處理：

保留日誌和現場。
輪換可能暴露的雲端憑證、API key、資料庫密碼和 session secret。
檢查雲帳號最近的 API 調用。
檢查內網服務存取記錄。
重建受影響容器或主機。
複查出站存取策略和 metadata 保護。

這和 React/Next.js RCE 不是一回事

容易混淆的一點是，CVE-2026-44578 是 Next.js WebSocket upgrade SSRF，不是之前 React Server Components 相關的 RCE。

它的核心影響是讓伺服器向攻擊者指定的內部或外部位址發請求，主要風險是資訊外洩和內部資源探測。

而 React Server Components 相關 RCE 則屬於程式碼執行風險，攻擊後果和修復範圍不同。

所以排查時不要只看「Next.js 有漏洞」這個大標題，要把具體 CVE、影響版本、部署模式和修復版本對應起來。

哪些團隊要優先處理

優先級最高的是這些環境：

自託管 Next.js 生產站點。
運行在雲主機、容器、Kubernetes 或內網環境。
應用伺服器可以存取雲端 metadata 服務。
應用伺服器能存取內部管理後台、資料庫、快取或監控系統。
直接暴露 next start origin server。
使用老版本 next，且升級流程不清晰。

優先級相對較低的是：

完全部署在 Vercel 的應用。
已升級到修復版本的應用。
origin server 不直接暴露，且入口層已經阻斷不需要的 WebSocket upgrade。
出站網路嚴格受控，無法存取敏感內網資源。

但「優先級較低」不等於可以不升級。Next.js 是高頻暴露元件，框架版本長期落後會疊加更多風險。

給開發團隊的檢查清單

可以按下面清單處理：

確認所有倉庫的 next 版本。
查出所有自託管部署，不只看 Vercel 專案。
標記使用 next start 或內建 Node.js server 的服務。
升級到 15.5.16、16.2.5 或更高版本。
重新建置並發布生產映像。
在入口層阻斷不需要的 WebSocket upgrade。
限制應用伺服器存取雲端 metadata 和敏感內網段。
檢查近期異常 upgrade 請求和出站存取。
輪換疑似暴露的憑證。
把 Next.js 安全更新納入依賴更新流程。

總結

CVE-2026-44578 是一個需要認真處理的 Next.js 高危 SSRF 漏洞。

它不影響 Vercel 託管部署，但影響範圍覆蓋大量自託管 Next.js 應用：13.4.13 到 15.5.16 之前，以及 16.0.0 到 16.2.5 之前。漏洞觸發點在 WebSocket upgrade 處理路徑，攻擊者可能讓伺服器代理存取內部或外部位址，進而暴露內網服務或雲端 metadata 端點。

最直接的修復方式是升級到 15.5.16 或 16.2.5。臨時緩解則是不要直接暴露 origin server，阻斷不需要的 WebSocket upgrade，並限制應用伺服器的出站存取。

對維運團隊來說，重點不是只看 CVE 分數，而是看你的 Next.js 服務所在網路能存取什麼。SSRF 的真實風險，往往取決於伺服器背後有哪些內網資源和雲權限。

參考連結：