當工具越來越多：Vercel AI SDK Tool 的邊界與痛點

上一篇，我們已經實現了：你在 Next.js 裡寫幾個 tool(...)，把查時間、查天氣之類的函數包裝一下，就能讓模型自動呼叫這些能力。

只靠這一招，你已經可以做出不少實用的小東西：內部客服助手、知識庫問答、SaaS 裡的 AI 小功能。

那問題來了：如果你繼續往前走，會怎樣？

• 工具從 3 個，變成 30 個。

• 呼叫環境從「一個 Web 前端」，變成「Web + IDE 插件 + 內部 Agent」。

• 團隊從「你自己」，變成「三四個小組同時在寫工具」。

這時候，單靠「Vercel AI SDK Tool」這一層，就開始吃力了。這篇文章，我們不急著上 MCP，先把「純 Tool 架構」會遇到的問題攤開來講清楚。

1. 回顧：只有 Tool 的理想世界

先快速回顧一下「上一集」的模型：

• 你有一個 Next.js / Node.js 專案。

• 你用 Vercel AI SDK 裡的 tool(...) 去封裝業務函數，比如 getCurrentTime、getWeather。

• 在呼叫模型的時候，把這些 Tool 掛到 tools 參數上，模型就能按需呼叫。

從架構圖上看，大概是這樣一個扁平結構：

使用者 → Next.js API Route → Vercel AI SDK → 模型 模型 ←→ Tool（封裝了你的業務函數）

所有東西都在一個專案裡：

• Tool 直接呼叫你的資料庫、你的 HTTP API。

• 權限怎麼驗證、日誌怎麼打，完全由你這一個後端服務決定。

對一個「單應用、單團隊」的專案來說，這非常舒服：

• 改業務邏輯只改這一處。

• 只考慮一個部署單元。

• 除錯和觀測都在熟悉的環境裡做。

2. 第一層複雜度：工具數量暴漲帶來的維護壓力

我們先不引入「多個應用」「多個宿主」，只看同一個專案內部。

2.1 從「幾個工具」到「一堆工具」

想像一下你在做一個後台營運助手，大概會有這些 Tool：

• 工單相關：listTickets、getTicketDetail、updateTicketStatus…

• 使用者相關：getUserProfile、banUser、sendNotification…

• 訂單相關：getOrder、refundOrder、listRefundRequests…

• 報表相關：getDailyStats、exportReport…

每一個 Tool 本身不複雜，但加起來就是幾十個檔案：

• 每個 Tool 要定義參數 schema、描述、回傳值結構。

• 很多 Tool 底層都在調你現有的 REST / RPC / DB 邏輯。

從短期看，這沒什麼問題，Tool 就是你專案的「AI 層 API 閘道」。

2.2 程式碼開始出現三類「重複與分裂」

隨著工具數量上來，會出現三個微妙的問題：

1. 同一類業務能力被重複封裝

   • 你的老後端已經有一套「業務 API」，現在又在 Tool 層再封裝一遍。

   • 如果別的專案也要用這些能力，又得再封裝一次（在它們自己的 Tool 裡）。

2. 型別和驗證規則分散

   • 原本領域模型（訂單、工單、使用者）在後端已經有型別和驗證。

   • Tool 層又寫一遍 JSON Schema / Zod，很容易有一天出現「沒一起改」的問題。

3. 權限邏輯散落在多個 Tool 中

   • 你可能在每個 Tool 的 execute 裡做「目前使用者是否有權限操作這個訂單」之類的檢查。

   • 這看起來沒錯，但當幾十個 Tool 都做類似的檢查時，想全局收緊/放寬某個權限就會很不好改。

這個階段，純 Tool 架構還完全能扛住，只是維護體驗開始變差。你會開始想： 能不能把「工具層」變成一個更獨立、可複用的東西，而不是緊緊綁死在這專案裡？

這就是往 MCP 那個方向邁出的第一小步，但我們先不急。

3. 第二層複雜度：呼叫環境從一個變多個

再往前走一步：工具不只給你目前這個 Web 應用用，還想給別的宿主用。

3.1 多個宿主的典型場景

你可能會有這樣的需求組合：

• Web：營運後台裡有一個「AI 助手」面板，呼叫工具幫營運做查詢和操作。

• IDE 插件：工程師在開發環境裡用 Agent 查某個訂單/使用者的狀態，用的是同一套業務工具。

• 內部「總控台」：公司想做一個統一的 AI 控制台，能調各業務線的工具。

這三種宿主的共同點是： 都希望呼叫「同一套業務能力」。

如果你只用 Vercel AI SDK 的 Tool，每個宿主大概要做同樣的事情：

• 在各自專案裡寫一套 Tool 封裝。

• 各自處理認證、節流、審計。

• 各自維護 prompt，告訴模型「有哪些工具可以用」。

長期看，這會變成典型的「一堆孤島」：

• A 組的 Tool 和 B 組的 Tool 名字都叫 getUser，但行為不一定完全一樣。

• 權限策略在不同宿主不一致，有的地方放得嚴，有的地方放得鬆。

• 任意一個後端 API 改了回傳結構，你得通知所有專案改 Tool 封裝。

3.2 這其實是「缺少協定層」的問題

注意，這個問題已經超出了「某個 SDK 好不好用」的範疇，它更像是：

我們公司內部有沒有一個「統一的 AI 工具接入層」？ 還是說，每個專案都自己搞一套？

Vercel AI SDK 做得很好的一件事是：在「模型呼叫」這一段幫你統整了不同廠商的介面。 但它不負責回答「工具怎麼對外暴露，怎麼被不同宿主共享」，這就剛好留給 MCP 一類協定發揮空間。

4. 第三層複雜度：跨團隊協作與對外發布

再往上一個維度，你不只是「內部複用」，而是想把工具當成「產品」發布出去。

4.1 你想做的變成「工具平台」

比如你團隊開發了一套非常好用的：

• Git 倉庫管理工具（查 PR、合併、回滾等）。

• 訂單風控工具（檢測可疑訂單、發起人工複核）。

• 專案知識庫工具（跨多個系統查詢專案資訊）。

你會開始有這些訴求：

• 這個工具能不能讓別人也用？比如 IDE 插件、內部 Agent、甚至外部合作方。

• 能不能出一個「統一的介面文件」，而不是「你用 Next 就用這套 Tool，你用別的就看著辦」。

• 能不能有一個「工具市集」或者「倉庫」，別人可以直接安裝我們的工具，而不是從你專案裡翻程式碼。

這時候，「只是寫一些 Vercel AI SDK Tool」已經不夠了：

• Tool 更像是 SDK 層的封裝，緊貼具體執行環境（Node/Next/Vercel）。

• 你需要一個獨立出來的「工具協定層」，不綁定某個框架或 SDK。

Anthropic 提出的 Model Context Protocol（MCP），就是在這一層做文章：

• 它定義了「工具如何被描述和發現」、「Host 如何列出工具並呼叫」這整套機制。

• 工具實現側（MCP Server）可以是任何語言/框架。

• 宿主側（MCP Client / Host）可以是 IDE、桌面端、你的 Web 後端，甚至是另一個 Agent 系統。

你可以把它看成是：

• Tool：在一個具體專案裡寫的「函數級封裝」。

• MCP：在整個生態裡約定的「工具級協定」。

5. 站在 AI SDK 視角，具體有哪些「邊界」？

回到 Vercel AI SDK 這個具體產品，結合官方文件與社群討論，可以把「只靠 Tool」的邊界/痛點總結為幾類。

5.1 Tool 的適用範圍主要在「應用內部」

AI SDK 官方定位是：幫助你在 Next.js、Node.js 等環境裡快速構建 AI 應用和 Agent。 它的 Tool 抽象也主要圍繞這個目標設計：

• 非常適合直接封裝目前專案裡的 TypeScript / JavaScript 邏輯。

• 可以長時間綁定在這個程式碼庫裡，服務這一個應用。

但它並不是一個「對外標準」：

• 別的團隊或專案不知道你這裡的 Tool 定義長什麼樣，除非直接看程式碼。

• IDE/桌面用戶端/Agent 平台無法直接「發現和接入」你這套 Tool。

5.2 生態角度：每家 SDK 都有自己的 Tool 抽象

不僅是 Vercel AI SDK，LangChain、LlamaIndex、各種自研 Agent 框架都有自己的「工具定義」方式。

如果你只停留在 SDK 層（包括 AI SDK 的 Tool），你會發現：

• 每個框架定義工具的方式略有不同（API、參數宣告、生命週期）。

• 工具無法在框架之間直接複用；要嘛複製貼上，要嘛寫各種適配層。

• 一旦你想做「IDE 插件 + Web 應用 + CLI」三端統一使用同一套工具，就不得不「抽象到 SDK 之上」。

MCP 這種協定試圖解決的，就是這個「SDK 之上」的問題：讓工具變成一個可以跨框架、跨產品、跨公司的「公共語言」。

5.3 一些實踐反饋：當專案複雜時，你會自己補一層「平台」

社群裡已經有不少重度使用 Vercel AI SDK 的開發者在討論：

• 當專案變複雜時，會自己在 AI SDK 上再蓋一層「自訂的工具/訊息抽象」，而不是直接裸用 Tool。

• 例如：統一處理不同模型提供商的細節、補充更強的觀測能力、增強重試和限流、在 Tool 呼叫層做額外的決策邏輯等。

這本質上也是一種「協定化」趨勢： 只是這個協定目前還停留在「你所在組織內部」的層次，而 MCP 把它開放成了生態級標準。

6. 從 Tool 視角看 MCP：我們到底缺了哪一層？

我們可以用一個很實用的類比來總結一下前面的討論。

• 傳統 API 是為「人類開發者」設計的：

• 你知道有哪些 endpoint，有 Swagger 文件，有範例。

• 你在程式碼裡手寫呼叫順序、錯誤處理、重試邏輯。

• MCP 是為「AI 代理/助手」設計的：

• 模型本身不知道有哪些系統和能力可以用。

• MCP 把「工具列表、參數要求、預期輸出」以機器可理解的方式暴露出來。

• 模型可以問：「現在有哪些工具」「這個工具需要什麼參數」「我會得到什麼結果」。

站在 Vercel AI SDK Tool 的視角看：

• Tool 讓模型在一個應用內部可以聰明地呼叫你的函數。

• MCP 則試圖讓模型在整個生態裡聰明地發現並呼叫各種工具。

兩者不衝突，只是站的高度不同：

• Tool 偏「SDK 級 DX」：型別安全、Next.js 深度整合、前端體驗。

• MCP 偏「協定級互操作」：多宿主、多框架、多語言工具共享。

7. 為下一篇做鋪墊：我們會怎麼用 MCP？

這篇我們刻意沒有深入 MCP 的技術細節，只是從「Tool 用到頭了會怎樣」的角度，把它的動機講明白了：

• 當你只做一個 Web 應用時，Vercel AI SDK Tool 基本就夠用。

• 當你想跨多個宿主、多個團隊、多種框架複用同一套工具時，僅靠 Tool 不夠，你需要一個協定層。

• MCP 就是這樣一個協定：標準化「工具描述、發現和呼叫」這件事。

下一篇，我們會集中火力聊 MCP 本身：

• 把 MCP 中的 Host / Server / Client 概念講清楚。

• 畫一張「工具生態」架構圖，讓你知道它和 API / SDK 的關係。

• 用一個簡單例子展示「一個 MCP Server 大概長什麼樣」，但先不綁定具體語言/框架。