AI SDK：把模型供應商抽象成一層 TypeScript 介面
The AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents
秒懂
- 它是什麼？
- vercel/ai 提供統一的 generateText、ToolLoopAgent 與 UI hook，讓同一段程式碼可以換模型、換框架。判斷重點在於你願不願意接受預設走 Vercel AI Gateway，以及能不能跟上它每週多次的版本節奏。
- 適合誰用？
- 若你的產品是 TypeScript 前端專案，需要在同一份程式碼裡切換 OpenAI、Anthropic、Google 等模型，並且接受預設經由 Vercel AI Gateway 呼叫，AI SDK 省下的樣板碼很直接。若你的團隊必須自建推論閘道、以非 Node 執行環境為主，或無法承受每週多次的版本更新，這個套件會變成負擔。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的問題：模型供應商介面各自為政
在 AI SDK 出現之前，同一個對話功能要接三家模型，就得寫三套請求格式、三套串流解析、三套錯誤型別。切換模型的成本高到多數團隊乾脆綁死一家。這個專案把呼叫端收斂成一組函式，README 的說法是「provider-agnostic TypeScript toolkit」，目標受眾是使用 Next.js、React、Svelte、Vue、Angular 這類前端框架，執行環境為 Node.js 的開發者。
它同時處理兩個層次。第一層是伺服器端的模型呼叫，統一在 generateText 這類函式底下；第二層是前端與伺服器之間的串流與工具呼叫狀態，交給 @ai-sdk/react 這類框架套件。兩層都做，是它與單純的 API wrapper 最大的差別。
兩條呼叫路徑：Gateway 字串與直連供應商套件
README 給的第一個範例是把模型寫成字串：model: 'anthropic/claude-opus-4.6'，或 'openai/gpt-5.4'、'google/gemini-3-flash'。這種寫法預設經過 Vercel AI Gateway，官方說法是「give you access to all major providers out of the box」。也就是說，開箱即用的代價是流量預設走 Vercel 的閘道。
第二條路是安裝 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google，然後用 anthropic('claude-opus-4-6') 這種形式傳入模型物件。README 的註解把兩種寫法並列，字串給 Gateway、函式呼叫給直連。這個切換點是評估時最該先確認的事：你的金鑰、計費與資料落地要求，決定你能不能接受第一條路。
值得注意的是兩邊的模型識別字不同。Gateway 字串用點號（claude-opus-4.6），供應商套件用連字號（claude-opus-4-6）。文件沒有解釋這個差異的原因，但遷移時貼錯就會直接失敗。
結構化輸出：schema 交給 Zod，型別由推導取得
generateText 搭配 Output.object 時，schema 用 Zod 定義，範例是一份食譜物件，內含 name、ingredients 陣列（每項有 name 與 amount）、steps 字串陣列。回傳值從 text 換成 output。
這個設計把「模型回傳自由文字、你再自己想辦法解析」的流程，改成由 SDK 依 schema 約束並驗證。對需要穩定欄位的表單填寫、資料抽取場景，這比在 prompt 裡反覆叮嚀 JSON 格式可靠。但 README 沒有交代驗證失敗時的重試策略或錯誤型別，這一段在正式使用前必須自己從 API Reference 補齊，不能假設它會自動重試。
ToolLoopAgent：把工具迴圈包成一個類別
代理的部分由 ToolLoopAgent 承擔。README 的 shell 範例傳入 model、system 提示，以及一個 tools 物件，裡面用 openai.tools.localShell 包住 execute 函式；execute 內再呼叫外部沙箱執行命令，取回 stdout。
這裡的架構重點是：SDK 負責「模型要求呼叫工具、執行、把結果餵回模型」這個迴圈，工具本身的實作完全在你手上。範例註解寫著 getSandbox() 對應 Vercel Sandbox，但那只是一個佔位函式，任何能回傳 stdout 的沙箱都可以替換。
圖像生成的範例展示了同一套機制的另一面：openai.tools.imageGeneration 帶 partialImages: 3，前端用 UIToolInvocation 型別，依 invocation.state 在 'input-available' 與 'output-available' 之間切換畫面。工具呼叫的中間狀態因此變成 UI 可渲染的資料，而不是黑箱。
UI 層的資料流：從 agent 檔案到 useChat
README 給了一條完整的 Next.js App Router 路徑。先在 @/agent/image-generation-agent.ts 匯出 agent 與 InferAgentUIMessage 推導出的訊息型別；接著在 @/app/api/chat/route.ts 用 createAgentUIStreamResponse 把 agent 與 messages 包成 POST 回應；最後在 'use client' 的頁面用 useChat<ImageGenerationAgentMessage>() 取得 messages、status、sendMessage。
渲染時走 message.parts，依 part.type 分岔：'text' 直接輸出文字，'tool-generateImage' 交給自訂元件。這個 parts 陣列的設計意味著訊息不再只是字串，而是文字與工具呼叫交錯的序列。
狀態管理也反映在 UI 上：輸入框的 disabled 綁定 status !== 'ready'。這行程式碼背後是一套串流狀態機，文件沒有在 README 展開，實作前需要查 API Reference 確認各狀態的轉換時機。
安裝與執行環境的硬性門檻
README 明寫需要 Node.js 22+ 與 npm 或其它套件管理器。主套件是 npm install ai，前端 hook 另外裝，例如 npm install @ai-sdk/react，供應商直連則裝 @ai-sdk/openai、@ai-sdk/anthropic、@ai-sdk/google。
README 另外建議使用 Claude Code 或 Cursor 這類編碼代理時，在專案中加入 AI SDK skill，指令是 npx skills add vercel/ai。這是把套件知識餵給代理的做法，不是執行期依賴。
Node.js 22+ 這個門檻比多數前端專案現行的版本高。若你的 CI 或部署環境還停在 20，升級節點會是採用前的前置工作，而不是裝完套件就能跑。
版本節奏與授權狀態這兩個現實問題
release 清單顯示同一天內發佈了 ai@7.0.95、ai@6.0.279、ai@5.0.254。三個主版本同時維護，且各自持續出修補版，代表這個專案對舊版並不放生，但也代表變更頻率高。鎖定版本並在升級前讀 release notes，是使用這個套件的基本紀律。
授權欄位在倉庫資訊中是 NOASSERTION，也就是 GitHub 無法自動判定為標準授權條款。README 沒有提到授權內容。要在商業產品中使用，必須自行到倉庫根目錄確認實際的 LICENSE 檔案內容，這不是可以靠推測帶過的事項，本文也不對其法律效果做判斷。
另外，README 的社群段落只指向 Vercel Community 的 AI SDK 分類，沒有列出其他支援管道。若你的團隊需要商業等級的支援承諾，這裡沒有對應資訊。
什麼情況下該選別的方案
如果你的團隊已經自建推論閘道，或在非 Node 環境（例如 Python 服務、邊緣 runtime）為主，這個套件的價值會大幅下降。它的抽象建立在 TypeScript 與 Node.js 22+ 之上，跨語言重用並不成立。
以 Python 為主的後端可以直接使用各家供應商官方 SDK，或採用 LiteLLM 這類同為多供應商抽象的函式庫。差別在於 AI SDK 把前端 hook 與工具呼叫狀態一起納入範圍，而 LiteLLM 聚焦在伺服器端的統一呼叫與代理。反過來說，若你只需要伺服器端呼叫、不需要 React 或 Svelte 的串流整合，AI SDK 的 UI 模組對你就是多餘的依賴。
還有一種情況要避開：如果你的產品必須完全掌控請求路徑、不能經過第三方閘道，那預設的模型字串寫法就不適用，必須改走 @ai-sdk/* 直連套件，並自行確認每家的金鑰管理與配額行為。
維護成本落在誰身上
使用這個套件的長期成本有兩塊。第一塊是版本跟進：三個主版本並行維護，升級路徑需要你持續讀 release notes，尤其當你同時使用 UI hook 與 agent 時，兩層的變更可能不同步。
第二塊是抽象洩漏。工具迴圈、串流狀態、schema 驗證這些機制，SDK 只提供骨架，沙箱、儲存、錯誤處理仍由你實作。README 的 shell 範例用註解標出 getSandbox()，實際要接哪個執行環境並沒有預設答案。
相對地，這個套件確實把「換模型」從重寫請求層降級為改一行字串或換一個函式呼叫。對模型選型還在變動的早期產品，這個交換是划算的；對模型已經固定、只需要穩定呼叫的系統，抽象的維護成本可能高於它省下的程式碼。
編輯結論
若你的產品是 TypeScript 前端專案，需要在同一份程式碼裡切換 OpenAI、Anthropic、Google 等模型，並且接受預設經由 Vercel AI Gateway 呼叫，AI SDK 省下的樣板碼很直接。若你的團隊必須自建推論閘道、以非 Node 執行環境為主，或無法承受每週多次的版本更新，這個套件會變成負擔。動手前先確認三件事：Node.js 是否為 22 以上、模型字串走 Gateway 還是自裝 @ai-sdk/* 供應商套件、以及 Output.object 的 schema 驗證失敗時你的錯誤處理路徑。
社群筆記