HeyBinyang

当工具越来越多：Vercel AI SDK Tool 的边界与痛点

·技术·visibility3 阅读 ·AI·MCP

上一篇， 我们已经实现了： 你在 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 大概长什么样」，但先不绑定具体语言/框架。

分享

XRedditFacebookInstagramLinkedIn