夜雨聆风上一篇我们讲了一个很简单的故事： 你在 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 大概长什么样」，但先不绑定具体语言/框架。
从函数到 Tool：用 Vercel AI SDK 打开工具调用的大门
code-review-graph：让 AI 代码审查更精准、更省 Token
OpenClacky 入门指南：以最低 Token 成本构建本地 AI Agent 工作流
React Native 0.85：站在新架构上的一次“打磨版”升级
